Hallo, mein Name ist Alexander Azimov. Bei Yandex entwickle ich verschiedene Überwachungssysteme sowie die Architektur von Transportnetzwerken. Aber heute werden wir über das BGP-Protokoll sprechen.
Vor einer Woche hat Yandex ROV (Route Origin Validation) an den Schnittstellen zu allen Peering-Partnern sowie Verkehrsaustauschpunkten aktiviert. Lesen Sie weiter unten, warum dies getan wurde und wie sich dies auf die Interaktion mit Telekommunikationsbetreibern auswirkt.
BGP und was daran falsch ist
Sie wissen wahrscheinlich, dass BGP als Interdomänen-Routing-Protokoll konzipiert wurde. Im Laufe der Zeit konnte jedoch die Zahl der Anwendungsfälle wachsen: Heute hat sich BGP dank zahlreicher Erweiterungen zu einem Nachrichtenbus entwickelt, der Aufgaben vom Betreiber-VPN bis zum mittlerweile modischen SD-WAN abdeckt und sogar Anwendung als gefunden hat ein Transport für einen SDN-ähnlichen Controller, der den Distanzvektor BGP in etwas Ähnliches wie das Links-SAT-Protokoll umwandelt.
Fig. 1.
Warum wurde (und erhält) BGP so viele Anwendungen? Es gibt zwei Hauptgründe:
- BGP ist das einzige Protokoll, das zwischen autonomen Systemen (AS) funktioniert;
- BGP unterstützt Attribute im TLV-Format (Typ-Länge-Wert). Ja, das Protokoll ist damit nicht allein, aber da es an den Schnittstellen zwischen Telekommunikationsbetreibern nichts zu ersetzen gibt, erweist es sich immer als rentabler, ein weiteres Funktionselement daran anzuschließen, als ein zusätzliches Routing-Protokoll zu unterstützen.
Was stimmt nicht mit ihm? Kurz gesagt, das Protokoll verfügt nicht über integrierte Mechanismen zur Überprüfung der Richtigkeit der empfangenen Informationen. Das heißt, BGP ist ein A-priori-Vertrauensprotokoll: Wenn Sie der Welt mitteilen möchten, dass Sie jetzt das Netzwerk von Rostelecom, MTS oder Yandex besitzen, dann bitte!
IRRDB-basierter Filter – das Beste vom Schlechtesten
Es stellt sich die Frage: Warum funktioniert das Internet in einer solchen Situation noch? Ja, es funktioniert die meiste Zeit, aber gleichzeitig explodiert es regelmäßig und macht ganze nationale Segmente unzugänglich. Obwohl auch die Hackeraktivität im BGP zunimmt, werden die meisten Anomalien immer noch durch Fehler verursacht. Das diesjährige Beispiel ist in Weißrussland, wodurch ein erheblicher Teil des Internets für MegaFon-Benutzer eine halbe Stunde lang unzugänglich wurde. Ein anderes Beispiel - hat eines der größten CDN-Netzwerke der Welt kaputt gemacht.
Reis. 2. Abfangen des Datenverkehrs durch Cloudflare
Aber warum kommt es dennoch alle sechs Monate zu solchen Anomalien und nicht jeden Tag? Denn Netzbetreiber nutzen externe Datenbanken mit Routing-Informationen, um zu überprüfen, was sie von BGP-Nachbarn erhalten. Es gibt viele solcher Datenbanken, einige davon werden von Registraren verwaltet (RIPE, APNIC, ARIN, AFRINIC), einige sind unabhängige Anbieter (die bekannteste ist RADB) und es gibt auch eine ganze Reihe von Registraren im Besitz großer Unternehmen (Level3). , NTT usw.). Diesen Datenbanken ist es zu verdanken, dass das domänenübergreifende Routing die relative Stabilität seines Betriebs aufrechterhält.
Es gibt jedoch Nuancen. Routing-Informationen werden anhand von ROUTE-OBJECTS- und AS-SET-Objekten überprüft. Und wenn die erste Klasse eine Autorisierung für einen Teil der IRRDB impliziert, dann gibt es für die zweite Klasse keine Autorisierung als Klasse. Das heißt, jeder kann jeden zu seinen Sets hinzufügen und so die Filter der Upstream-Anbieter umgehen. Darüber hinaus ist die Eindeutigkeit der AS-SET-Benennung zwischen verschiedenen IRR-Basen nicht gewährleistet, was zu überraschenden Effekten mit einem plötzlichen Konnektivitätsverlust für den Telekommunikationsbetreiber führen kann, der seinerseits nichts geändert hat.
Eine zusätzliche Herausforderung ist das Nutzungsverhalten von AS-SET. Hier gibt es zwei Punkte:
- Wenn ein Betreiber einen neuen Kunden erhält, fügt er ihn seinem AS-SET hinzu, entfernt ihn jedoch fast nie;
- Die Filter selbst werden nur an den Schnittstellen zu Clients konfiguriert.
Infolgedessen besteht das moderne Format von BGP-Filtern aus einer schrittweisen Verschlechterung der Filter an den Schnittstellen zu Clients und einem a priori Vertrauen in das, was von Peering-Partnern und IP-Transitanbietern kommt.
Was ersetzt Präfixfilter auf Basis von AS-SET? Das Interessanteste ist, dass kurzfristig nichts passiert. Es entstehen jedoch zusätzliche Mechanismen, die die Arbeit von IRRDB-basierten Filtern ergänzen, und zuallererst ist dies natürlich RPKI.
RPKI
Vereinfacht kann man sich die RPKI-Architektur als verteilte Datenbank vorstellen, deren Datensätze kryptografisch verifiziert werden können. Im Fall von ROA (Route Object Authorization) ist der Unterzeichner der Eigentümer des Adressraums und der Datensatz selbst ist ein Triple (Präfix, ASN, maximale Länge). Im Wesentlichen setzt dieser Eintrag Folgendes voraus: Der Besitzer des $prefix-Adressraums hat die AS-Nummer $asn autorisiert, Präfixe mit einer Länge anzukündigen, die nicht größer als $max_length ist. Und Router können mithilfe des RPKI-Cache das Paar auf Konformität überprüfen Präfix – erster Sprecher auf dem Weg.
Abbildung 3. RPKI-Architektur
ROA-Objekte sind schon seit geraumer Zeit standardisiert, doch bis vor kurzem befanden sie sich tatsächlich nur auf dem Papier im IETF-Journal. Meiner Meinung nach klingt der Grund dafür beängstigend – schlechtes Marketing. Nach Abschluss der Standardisierung bestand der Anreiz darin, dass ROA vor BGP-Hijacking schützte – was nicht stimmte. Angreifer können ROA-basierte Filter leicht umgehen, indem sie am Anfang des Pfads die richtige AC-Nummer einfügen. Und sobald diese Erkenntnis kam, war der nächste logische Schritt, auf den Einsatz von ROA zu verzichten. Und warum brauchen wir wirklich Technologie, wenn sie nicht funktioniert?
Warum ist es an der Zeit, Ihre Meinung zu ändern? Denn das ist nicht die ganze Wahrheit. ROA schützt nicht vor Hackeraktivitäten in BGP, aber schützt vor unbeabsichtigten Verkehrsdiebstählen, zum Beispiel durch statische Lecks in BGP, die immer häufiger auftreten. Außerdem kann ROV im Gegensatz zu IRR-basierten Filtern nicht nur an den Schnittstellen zu Clients, sondern auch an den Schnittstellen zu Peers und Upstream-Anbietern eingesetzt werden. Das heißt, mit der Einführung von RPKI verschwindet das A-priori-Vertrauen allmählich aus BGP.
Mittlerweile wird die ROA-basierte Routenprüfung von wichtigen Akteuren schrittweise umgesetzt: Der größte europäische IX verwirft bereits falsche Routen; unter den Tier-1-Betreibern ist AT&T hervorzuheben, das Filter an den Schnittstellen zu seinen Peering-Partnern aktiviert hat. Auch die größten Content-Anbieter nähern sich dem Projekt. Und Dutzende mittelständischer Verkehrsbetriebe haben es bereits stillschweigend umgesetzt, ohne jemandem etwas davon zu sagen. Warum implementieren all diese Betreiber RPKI? Die Antwort ist einfach: Ihren ausgehenden Datenverkehr vor den Fehlern anderer zu schützen. Aus diesem Grund ist Yandex eines der ersten Unternehmen in der Russischen Föderation, das ROV am Rande seines Netzwerks integriert.
Was wird als nächstes passieren?
Wir haben jetzt die Überprüfung von Routing-Informationen an den Schnittstellen zu Verkehrsaustauschpunkten und privaten Peerings aktiviert. In naher Zukunft wird die Verifizierung auch bei Upstream-Traffic-Anbietern ermöglicht.
Welchen Unterschied macht das für Sie? Wenn Sie die Sicherheit der Datenverkehrsweiterleitung zwischen Ihrem Netzwerk und Yandex erhöhen möchten, empfehlen wir:
- Signieren Sie Ihren Adressraum - es ist einfach, dauert durchschnittlich 5-10 Minuten. Dies schützt unsere Konnektivität für den Fall, dass jemand unabsichtlich Ihren Adressraum stiehlt (und das wird definitiv früher oder später passieren).
- Installieren Sie einen der Open-Source-RPKI-Caches (, ) und die Routenprüfung an der Netzwerkgrenze aktivieren – dies wird mehr Zeit in Anspruch nehmen, aber auch hier keine technischen Schwierigkeiten verursachen.
Yandex unterstützt auch die Entwicklung eines Filtersystems basierend auf dem neuen RPKI-Objekt – (Autonome Systemanbieterautorisierung). Auf ASPA- und ROA-Objekten basierende Filter können nicht nur „undichte“ AS-SETs ersetzen, sondern auch die Probleme von MiTM-Angriffen mithilfe von BGP beheben.
Ich werde in einem Monat auf der Next Hop-Konferenz ausführlich über ASPA sprechen. Dort werden auch Kollegen von Netflix, Facebook, Dropbox, Juniper, Mellanox und Yandex sprechen. Wenn Sie sich für den Netzwerk-Stack und seine zukünftige Entwicklung interessieren, kommen Sie vorbei .
Source: habr.com