Cloudflare hat eine Analyse zur Verbreitung des Standards RFC 9234 veröffentlicht, der zur Begrenzung von Routing-Leaks im BGP-Protokoll eingesetzt wird. Grundlage waren Daten aus Peering-Sitzungen mit ihren Netzwerken sowie Tests, bei denen Test-Routen im Internet angekündigt wurden. Das Unternehmen stellte fest, dass 67 Netzwerke den Routen, die sie direkt versenden, das Attribut Only to Customer beziehungsweise OTC hinzufügten. Gleichzeitig entdeckte es, dass eine Reihe von Netzwerken dieses Attribut beim Weiterleiten der Routen entfernte. Dadurch wird die Fähigkeit kompatibler Netzwerke geschwächt, Leaks zu erkennen und zurückzuweisen.
BGP-Leaks treten auf, wenn ein Netzwerk eine Route, die es von einem Provider oder Peer gelernt hat, entgegen den geschäftlichen Beziehungen und der angenommenen hierarchischen Struktur von Internet-Routen an einen anderen Provider oder Peer ankündigt. Dies kann dazu führen, dass Datenverkehr über ein Netzwerk geleitet wird, das nicht darauf ausgelegt oder überhaupt nicht dazu berechtigt ist, ihn weiterzuleiten. Mögliche Folgen sind eine höhere Latenz, Paketverluste oder umfassendere Ausfälle.
Verhinderungsregeln gegen Leaks in das Protokoll verlagern
Herkömmliche Schutzmechanismen verlangen von jedem Betreiber, manuelle Richtlinien einzurichten, etwa Präfixfilter und aus IRR-Datenbanken abgeleitete Policies. Dafür muss die Beziehung jeder BGP-Sitzung genau definiert werden. RFC 9234 schlägt vor, einen Teil dieser Belastung 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 in einer eBGP-Sitzung fest, etwa Provider, Customer und Peer sowie RS und RS-Client, die mit Route-Servern an Internet Exchange Points verbunden sind. Wenn die von beiden Seiten angegebenen Rollen nicht miteinander vereinbar sind, wird die Sitzung mit einer Benachrichtigung über einen Role Mismatch abgelehnt, anstatt fortgesetzt zu werden, bis der Fehler später als tatsächlicher Leak sichtbar wird. Bei einer teilweise erfolgten 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, in 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 weiterläuft, sondern zu Kunden übertragen wird. Sobald das Attribut vorhanden ist, sollte die Route nicht mehr an einen Provider, Peer oder Route-Server weitergegeben werden. Außerdem kann ein kompatibler Router eine Route mit OTC ablehnen, wenn sie aus einer Beziehung eintrifft, die dies nicht zulässt. Dadurch wird die Prävention nach der Konfiguration der Rollen automatisch, statt ausschließlich auf einer vom Betreiber für jede Sitzung verfassten Policy zu beruhen.
Was hat Cloudflare tatsächlich gemessen?
Cloudflare verwendete BMP-Daten ihrer Router und beobachtete über drei Monate den von direkten Nachbarn empfangenen OTC-Wert. Ein Netzwerk wurde als möglicher konformer Teilnehmer betrachtet, wenn der Wert des Attributs mit der AS-Nummer 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ügen. Dabei wurde festgestellt, dass Route-Server neue Funktionen möglicherweise schneller übernehmen und dass von Einzelpersonen betriebene Netzwerke in den Ergebnissen einen bemerkenswerten Anteil ausmachten.
Die Analyse öffentlicher RIB-Daten von RouteViews und RIPE RIS lieferte dagegen 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, und 20 Netzwerke, die es wahrscheinlich ergänzen. Zusammen mit den Ergebnissen der direkten Nachbarn kam das Unternehmen auf 36 Netzwerke, die wahrscheinlich mit RFC 9234 konform sind. 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 Exchange-Standorten 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 mithilfe von Daten aus RIPE RIS und RouteViews sowie lokalen BMP-Daten. In der ersten Phase identifizierte es sechs autonome Systeme, die das Attribut entfernten, darunter die beiden Tier-1-Netzwerke GTT, AS3257 und Arelion, AS1299. Eine weiterführende Analyse längerer Pfade 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, Arelion oder beide erschienen in 96,6 % der IPv4-Routen, bei denen OTC verloren gegangen war, und in 92,9 % der IPv6-Routen. Dabei entfiel der größte Teil der Fälle auf Arelion. Bei der Untersuchung von Routen, deren nächster Hop eines der beiden Netzwerke war, stellte Cloudflare fest, dass GTT das Attribut durchgehend entfernte, während Arelion es in 71,4 % der IPv4-Routen und 40,7 % der IPv6-Routen der betreffenden Stichprobe entfernte.
Cloudflare zufolge bestätigten beide Netzwerke, dass die Entfernung von OTC Bestandteil defensiver Praktiken war, die nach Vorfällen im Zusammenhang mit der Verarbeitung von BGP-Fehlern entstanden waren. Den veröffentlichten Ergebnissen zufolge entfernten die Einstellungen 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 überprüft.
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 transitive Attribut weiterhin optional weiterleiten. Die Entfernung von OTC in einem zentral positionierten 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 Tabelle des Unternehmens aufgeführt, ohne dass ein vollständiger Supportstatus angegeben wurde. Dazu gehören 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 ein Zurücksetzen der BGP-Sitzungen erfordert. Cloudflare hat außerdem damit begonnen, die Einstellungen schrittweise in seiner globalen Flotte bereitzustellen, und plant, Daten zur Einführung im Routing-Bereich von Cloudflare Radar verfügbar zu machen.