Cloudflare veröffentlichte eine Analyse zur Verbreitung des RFC 9234-Standards, der zur Begrenzung von Routing-Leaks im BGP-Protokoll eingesetzt wird. Grundlage waren Daten aus Austausch-Sitzungen mit seinen Netzwerken sowie Tests, bei denen Test-Routen über das Internet angekündigt wurden. Das Unternehmen stellte fest, dass 67 Netzwerke das Attribut Only to Customer beziehungsweise OTC zu den von ihnen direkt gesendeten Routen hinzufügten. Gleichzeitig entdeckte es, dass mehrere Netzwerke dieses Attribut beim Weiterleiten der Routen entfernten, wodurch die Fähigkeit kompatibler Netzwerke geschwächt wird, Leaks zu erkennen und zurückzuweisen.
BGP-Leaks treten auf, wenn ein Netzwerk eine Route, die es von einem Provider oder Peer gelernt hat, an einen anderen Provider oder Peer ankündigt – entgegen den geschäftlichen Beziehungen und der angenommenen hierarchischen Struktur der Internet-Routen. Dadurch kann der Datenverkehr über ein Netzwerk geleitet werden, das nicht auf seine Aufnahme vorbereitet oder überhaupt nicht zu seiner Weiterleitung berechtigt ist. Mögliche Folgen sind eine höhere Latenz, Paketverluste oder umfangreichere Ausfälle.
Übertragung der Leak-Präventionsregeln in das Protokoll
Herkömmliche Schutzmechanismen verpflichten jeden Betreiber dazu, manuelle Richtlinien einzurichten, etwa Präfixfilter und aus IRR-Datenbanken abgeleitete Richtlinien. Dafür muss die Beziehung jeder BGP-Sitzung genau definiert werden. RFC 9234 schlägt vor, einen Teil dieser Last in das Protokoll selbst zu verlagern – durch zwei Komponenten: BGP Roles und das OTC-Attribut.
BGP Roles legen die Art der Beziehung zwischen den Nachbarn einer eBGP-Sitzung fest, etwa Provider, Customer und Peer sowie RS und RS-Client, die mit Route-Servern an Internetknoten verbunden sind. Wenn die von beiden Seiten angegebenen Rollen nicht kompatibel sind, wird die Sitzung mit einer Benachrichtigung über einen Role Mismatch zurückgewiesen, anstatt fortgesetzt zu werden, bis der Fehler später als tatsächlicher Leak sichtbar wird. Bei einer teilweisen Einführung kann die Sitzung funktionieren, wenn nur eine Seite eine Rolle sendet – sofern der Betreiber nicht den strikten Modus aktiviert hat, der Sitzungen ablehnt, bei denen die Gegenstelle keine Rolle ankündigt.
Das OTC-Attribut speichert die Nummer des autonomen Systems, das es erstmals hinzugefügt hat, wenn die Route nicht mehr aufwärts durch die Hierarchie läuft, sondern zu Kunden weitergeleitet wird. Sobald es vorhanden ist, sollte die Route nicht an einen Provider, Peer oder Route-Server weitergegeben werden. Ein kompatibler Router kann außerdem eine Route mit OTC ablehnen, wenn sie über eine Beziehung eingeht, die dies nicht zulässt. Dadurch wird die Prävention nach der Konfiguration der Rollen automatisch, anstatt ausschließlich von einer für jede Sitzung manuell erstellten Richtlinie abzuhängen.
Was hat Cloudflare tatsächlich gemessen?
Cloudflare nutzte BMP-Daten seiner Router und überwachte drei Monate lang den von direkten Nachbarn empfangenen OTC-Wert. Ein Netzwerk wurde als potenziell konform betrachtet, wenn der Wert des Attributs mit der autonomen Systemnummer des Nachbarn übereinstimmte. Diese Methode verringert die Unklarheit, die bei der Analyse von Routen entsteht, die mehrere Netzwerke durchlaufen haben. Die Messungen zeigten 67 autonome Systeme, die OTC hinzufügten. Dabei wurde festgestellt, dass Route-Server neue Funktionen möglicherweise schneller übernehmen und dass einige von Einzelpersonen betriebene Netzwerke in den Ergebnissen auffällig häufig vertreten waren.
Eine Analyse öffentlicher RIB-Daten von RouteViews und RIPE RIS ergab vorsichtigere Ergebnisse. Nach dem Versuch, Netzwerke zu unterscheiden, die OTC beim Senden hinzufügen, von solchen, die beim Empfang einen fehlenden Wert ergänzen, identifizierte Cloudflare 18 Netzwerke, die das Attribut wahrscheinlich hinzufügen, sowie 20 Netzwerke, die es wahrscheinlich ergänzen. Unter Einbeziehung der Ergebnisse der direkten Nachbarn kam das Unternehmen auf 36 Netzwerke, die wahrscheinlich RFC 9234 entsprechen. Cloudflare betont, dass die Methodik Netzwerke mit einer begrenzten Zahl von Routen oder Nachbarn möglicherweise nicht erfasst.
Netzwerke, die OTC entfernten
Cloudflare testete die Verbreitung von OTC, indem es von seinen Austauschstandorten aus ein IPv4- und ein IPv6-Präfix ankündigte, die den Wert 13335 trugen. Anschließend analysierte das Unternehmen BGP-Nachrichten während der Ankündigung und des Rückzugs anhand von Daten aus RIPE RIS und RouteViews sowie lokalen BMP-Daten. In der ersten Phase identifizierte Cloudflare sechs autonome Systeme, die das Attribut entfernten, darunter die beiden Tier-1-Netzwerke GTT, AS3257 und Arelion, AS1299. Eine weiterführende Analyse der längeren Routen führte zur Identifizierung von neun weiteren Netzwerken, die OTC entfernten.
In dem Test fehlte das Attribut bei 33,1 % der IPv4-AS_PATHs und bei 17 % der IPv6-Routen. GTT oder Arelion oder beide erschienen in 96,6 % der IPv4-Routen, die OTC verloren hatten, sowie in 92,9 % der IPv6-Routen; den größten Anteil der Fälle hatte Arelion. Bei der Untersuchung der Routen, deren nächster Hop eines der beiden Netzwerke war, stellte Cloudflare fest, dass GTT das Attribut durchgehend entfernte, während Arelion es bei 71,4 % der IPv4-Routen und 40,7 % der IPv6-Routen in der betreffenden Stichprobe entfernte.
Cloudflare erklärte, dass beide Netzwerke bestätigt hätten, dass die Entfernung von OTC zu defensiven Praktiken gehörte, die nach Vorfällen im Zusammenhang mit der Verarbeitung von BGP-Fehlern entstanden waren. Den veröffentlichten Ergebnissen zufolge entfernten die Konfigurationen von GTT das Attribut weiterhin, während Arelion nach der Kontaktaufnahme mit Cloudflare begann, es beizubehalten. Dies wurde durch eine spätere Analyse der Testrouten bestätigt.
Was ändert sich praktisch für Netzwerkbetreiber?
Die Ergebnisse zeigen, dass die Einführung von RFC 9234 nicht nur von der Unterstützung der Funktion durch Router abhängt, sondern auch davon, dass zwischengeschaltete Netzwerke das optionale transitive Attribut weiterhin weitergeben. Die Entfernung von OTC in einem zentral gelegenen Netzwerk kann ein kompatibles Netzwerk, das mehrere Hops dahinter liegt, daran hindern, einen Leak zu erkennen, der hätte verhindert werden können.
Cloudflare weist darauf hin, dass Junos OS und Junos OS Evolved RFC 9234 unterstützen und dass die Unterstützung für Cisco IOS XR für Version 26.4.1 vorgesehen war. Andere Implementierungen wurden in der Übersicht aufgeführt, ohne dass ein vollständiger Unterstützungsstatus angegeben wurde, darunter Arista EOS, Nokia SR OS, Huawei, Extreme SLX-OS, RouterOS, BIRD, OpenBGPD, FRR, ArcOS, GoBGP und ExaBGP. Das Unternehmen empfiehlt Betreibern, die über die Funktion verfügen, BGP-Rollen schrittweise während Wartungsfenstern zu konfigurieren, da ihre Anwendung einen Neustart der BGP-Sitzungen erfordert. Cloudflare hat außerdem damit begonnen, die Konfigurationen schrittweise über seine weltweite Infrastruktur auszurollen, und plant, Daten zur Einführung im Routing-Bereich von Cloudflare Radar bereitzustellen.