BGP-Verarbeitungsfehler verursacht Instabilität im Internet-Routing

 (blog.benjojo.co.uk)
1 Punkte von GN⁺ 2025-05-29 | 1 Kommentare | Auf WhatsApp teilen
  • Eine am 20. Mai 2025 um 07:00 UTC verbreitete beschädigte BGP-Nachricht löste in zwei wichtigen Implementierungen unerwartetes Verhalten aus: Viele mit dem Internet verbundene BGP-Sessions wurden zurückgesetzt, und in einigen Netzwerken kam es zu Routing-Instabilität oder kurzen Verbindungsverlusten
  • Das problematische Update enthielt ein BGP Prefix-SID Attribute, das in Internet-BGP-Updates normalerweise nicht zu erwarten ist, und war beschädigt: Die internen Daten bestanden vollständig aus 0x00
  • IOS-XR/Nokia SR-OS mit Fehler-Toleranz nach RFC7606 filterten es heraus, JunOS leitete es jedoch weiter und Arista EOS setzte die Session zurück; betroffen sein konnten dadurch Arista-Nutzer, die an JunOS-basierte Transit-Carrier angebunden waren
  • In den Beobachtungen von bgp.tools tauchten AS9304, AS135338, AS151326 und AS138077 wiederholt auf; wahrscheinlich wurde das fehlerhafte Attribut von Starcloud AS135338 oder Hutchison AS9304 hinzugefügt
  • Während des Vorfalls stieg die über 10 Sekunden gemittelte Nachrichtenrate des Route Collectors von bgp.tools von üblichen 20.000–30.000 pro Sekunde auf über 150.000/s und zeigte damit, dass Unterschiede in der BGP-Fehlerbehandlung die Stabilität realer Internet-Routen beeinträchtigen können

BGP-Update-Vorfall vom 20. Mai 2025

  • Eine am Dienstag, dem 20. Mai 2025, um 07:00 UTC verbreitete BGP-Nachricht verursachte unerwartetes Verhalten in zwei wichtigen BGP-Implementierungen, die häufig für die Weiterleitung von Internet-Traffic eingesetzt werden
  • Die Auswirkungen breiteten sich aus, als viele mit dem Internet verbundene BGP-Sessions automatisch beendet wurden
    • In einigen Netzwerken wurde Routing-Instabilität festgestellt
    • Im schlimmsten Fall kann es zu kurzen Verbindungsverlusten gekommen sein

Die problematische BGP-Nachricht

  • Das in den an bgp.tools gelieferten Sessions beobachtete Update war ein relativ gewöhnliches BGP Update für ein /16, enthielt jedoch das problematische BGP Prefix-SID Attribute
  • Dieses Attribut war aus zwei Gründen gefährlich
    • Es ist ein Attribut, das in BGP-Updates der Internet-Tabelle nicht zu erwarten ist
    • Es war ein beschädigtes Attribut, dessen interne Daten vollständig aus 0x00 bestanden
  • Die meisten Implementierungen wie IOS-XR/Nokia SR-OS filtern es korrekt heraus und verursachen keine Probleme, wenn „BGP error tolerance“ auf Basis von RFC7606 konfiguriert ist
  • Bei der Kombination aus JunOS und Arista EOS zeigte sich ein anderes Ergebnis
    • JunOS leitete die beschädigte Nachricht weiter
    • Arista-EOS-Geräte setzten die Session zurück, wenn sie diese Nachricht erhielten, die offenbar von JunOS-Geräten kam
  • Da viele Internet-Transit-Carrier Juniper-Hardware mit JunOS einsetzen, könnten Netzwerke, die Arista EOS betreiben und an JunOS-basierte Upstream-Transit-Carrier-Router angebunden sind, zeitweise den Internetzugang verloren haben
    • Die Dauer wird auf bis zu etwa 10 Minuten geschätzt

Kandidaten-AS, die das fehlerhafte Attribut hinzugefügt haben könnten

  • Eine Filterung des bgp.tools-Archivs für den betreffenden Zeitraum deutet darauf hin, dass mehrere Origin-AS an dem Vorfall beteiligt waren
  • Das legt nahe, dass das Attribut möglicherweise nicht vom Netzwerk hinzugefügt wurde, aus dem das Prefix stammt, sondern von einem zwischengeschalteten Carrier auf dem Weg ins breitere Internet
  • In den problematischen Nachrichten tauchten wiederholt die folgenden vier Kandidaten auf
    • AS9304 — Hutchison Global Communications Limited
    • AS135338 — Starcloud Information Limited
    • AS151326 — DCConnect Communication Pte. Ltd.
    • AS138077 — PT Abhinawa Sumberdaya Asia
  • bgp.tools beobachtete betroffene Prefixes auf dem Pfad […] 151326 138077 […] ohne das fehlerhafte BGP-Attribut
    • Daher ist es wahrscheinlich, dass das fehlerhafte Attribut von Starcloud AS135338 oder Hutchison AS9304 hinzugefügt wurde
  • Einige der in Updates mit diesem Attribut beobachteten Prefixes waren:
    • 156.230.0.0/16
    • 138.113.116.0/24
    • 163.171.102.0/24
    • 163.171.103.0/24
    • 163.171.104.0/24

Ausbreitung über Internet Exchanges

  • Der Vorfall wurde größer, weil Hutchison/AS9304 an vielen Internet Exchanges angeschlossen war
  • Die problematischen Nachrichten wurden an IX Route Server gesendet, die in der Regel bird ausführen
  • Bird unterstützt BGP SID nicht, konnte die Nachrichten daher nicht filtern und verteilte sie unverändert über mehrere Multi-Terabit-Internet-Exchanges
  • Dadurch breitete sich die Störung über Internet-Transit-Sessions hinaus in einen größeren Bereich aus

Charakter des BGP Prefix-SID

  • Das BGP Prefix-SID Attribute sollte normalerweise nur in internen BGP-Sessions sichtbar sein
  • Der in RFC8669 definierte Zweck besteht darin, innerhalb eines einzelnen Netzwerks festzulegen, welchen Pfad Traffic zu einem Ziel nehmen soll
  • Dass dieses Attribut in die globale Routing-Tabelle gelangte, könnte daran liegen, dass externe BGP-Sessions wie interne Sessions konfiguriert waren

Betroffene Netzwerke und Beobachtungsdaten

  • Es ist schwer, eindeutig zu bestimmen, wer genau betroffen war; anhand eines im Verhältnis zur Netzwerkgröße sehr hohen Churns direkt nach der ersten problematischen BGP-Nachricht wurden jedoch rund 100 Netzwerke als betroffen gezählt
  • Beispiele mit hoher Zuverlässigkeit sind:
  • Im Normalbetrieb sammelt der Route Collector von bgp.tools etwa 20.000–30.000 Nachrichten pro Sekunde
  • Während dieses Vorfalls lag die über 10 Sekunden gemittelte Nachrichtenrate deutlich über 150.000/s
    • Das deutet darauf hin, dass es bei vielen Internet-Routen erhebliche Störungen gab

Unterschiede in der Fehlerbehandlung je nach Anbieter

  • Auch wenn die eigentliche Ursache oder der tatsächliche Auslöser nicht vollständig klar ist, zeigt die Tatsache, dass die fehlerhafte Nachricht im Internetmaßstab verbreitet wurde, die Risiken der BGP-Fehlerbehandlung
  • Andere Anbieter erkannten das fehlerhafte Attribut und unterdrückten die Route Announcement, Juniper leitete sie jedoch an Peers weiter
  • Nachdem die Nachricht Arista-Geräte erreicht hatte, führte fehlender oder fehlerhafter BGP-error-tolerance-Code zu Session-Resets
  • Die JunOS-Dokumentation zur BGP error tolerance von Juniper erklärt, dass JunOS nicht alle Teile einer Nachricht prüft
  • Dieses Verhalten führte dazu, dass JunOS selbst remote ausgelöste Session-Resets vermied, dieselbe Nachricht aber an andere Peers oder Kunden weitergab

Betriebliche Folgen

  • Dieser Outage war kurz, hätte aber größere Auswirkungen haben können
  • Da immer mehr Dienste IP-basiert werden, kann der Umfang von Internetausfällen über nicht erreichbare E-Mails hinausgehen
    • Ausfall von TV-Übertragungen
    • Störungen bei Notrufdiensten
  • Solche Bugs erhöhen die Wahrscheinlichkeit, dass in der realen Welt Menschen zu Schaden kommen oder Schäden verschlimmert werden
  • Netzwerkbetreiber mit vollständiger Routing-Tabelle können bgp.tools Datenfeeds bereitstellen und so beim Debugging künftiger Vorfälle helfen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-29
Meinungen auf Hacker News

  • Der Standardansatz lautet, beim Empfangen großzügig und beim Senden streng zu sein.
    Die Optionen sind: fehlerhafte Nachrichten filtern, sie verwerfen, fehlerhafte Attribute ignorieren, aber weiterleiten, oder wegen fehlerhafter Attribute kaputtgehen. Wirklich schwer akzeptabel ist meiner Ansicht nach nur Variante 4, also das Arista-Verhalten. Variante 3, das Juniper-Verhalten, ist zwar nicht wünschenswert, aber nicht fatal.
    Beim erneuten Lesen scheint Arista nicht Variante 4, sondern eher Variante 2 gewesen zu sein; es ist offenbar nicht komplett abgestürzt, sondern hat die Verbindung als fehlerhaft betrachtet und geschlossen. Aus Nutzersicht ist das nicht gut, aber in der Debatte noch eher vertretbar.

    • Es gibt bereits RFC 7606 (Revised Error Handling for BGP UPDATE Messages), der detailliert festlegt, wie fehlerhafte BGP-Nachrichten zu behandeln sind.
      Die gängigste Methode ist treat-as-withdraw: Ein Update zur Routenankündigung wird so behandelt, als würde die zuvor angekündigte Route zurückgezogen. Eine fehlerhafte Nachricht einfach zu verwerfen ist nicht richtig, weil man dadurch einen alten Zustand beibehält, der nicht mehr gültig ist.
    • Was hier umformuliert wurde, ist das sogenannte Robustheitsprinzip, also Postels Gesetz.
      Das ist eine Idee aus der Frühgeschichte des Internets der 1980er- und 1990er-Jahre, die heute weithin als falscher Ansatz gilt, weil sie zur Verhärtung von Protokollen und zu zahlreichen Sicherheitsproblemen geführt hat.
    • Das Problem ist, dass Menschen im gesamten Netzwerk ausgenutzt haben, dass BGP auch unbekannte Attribute weiterleitet, die lokale Geräte nicht verstehen.
      Inzwischen hängen viele Systeme von diesem Verhalten ab, und man bekommt nun die Nachteile dieses „Features“ zu spüren.
    • In dem verlinkten Artikel spricht der Autor denselben Punkt an.
      Oberflächlich betrachtet wirkt dieses „Feature“ wie eine sehr schlechte Idee, weil unbekannte Informationen blind über Systeme verbreitet werden, die die Auswirkungen der weitergeleiteten Informationen nicht verstehen. Andererseits könnte man auch sagen, dass genau dieses Feature Dinge wie Large Communities schneller breit ausrollen ließ und die Bereitstellung neuer BGP-Funktionen überhaupt erst möglich gemacht hat.
    • Diesem Ansatz stimme ich nicht zu. Ich halte es für besser, sowohl beim Empfangen als auch beim Senden sehr strikt zu sein.

  • Ich erinnere mich noch daran, wie wir wie verrückt durch das gesamte Netzwerk gerannt sind, um CVE-2023-4481 zu beheben.
    Solche Bugs sind wirklich ein Albtraum in der Behandlung, und wegen der Art, wie BGP entworfen und implementiert wurde, wird es sehr lange dauern, dieses Verhalten zu korrigieren.

  • Vor Jahrzehnten habe ich bei einem Telekommunikationsausrüster BGP-Funktionen entwickelt.
    Ich halte BGP immer noch für viel zu komplex, und die Leute fügen weiter neue Funktionen hinzu, während Hersteller weiterhin auf Basis von RFC-Standards oder Entwürfen implementieren.
    Es sieht nicht so aus, als würde BGP abgeschafft, daher werden solche Bugs wohl auch künftig immer wieder gefunden werden.

    • Es gab definitiv eine Zeit, in der AT&T zusammen mit Juniper und Cisco BGP durch MPLS- und VPN-bezogene Funktionen in einen völlig komplexen Bereich gedrängt hat.
      Für mich persönlich war das erschreckend komplex, aber für irgendwen war es profitabel.

  • HGC Global Communications Limited ist ein Internetanbieter aus Hongkong, der früher als Hutchison Global Communications Limited bekannt war.
    https://en.wikipedia.org/wiki/HGC_Global_Communications

  • Auch unsere IOS-XR-Chassis haben einige dieser Pakete erhalten, und das fiel zeitlich mit einer hohen Zahl von BGP-Routenankündigungen zusammen. Welche Geräte unser Upstream nutzt, weiß ich ehrlich gesagt nicht.
    Ich frage mich, ob das BGP-Protokoll ordentlich gefuzzt wird. Vielleicht ist es ein Bereich, der so wichtig ist, dass alle Angst haben, ihn absichtlich kaputtzumachen.
    Einen BGP-Fuzzer zu schreiben könnte einfach sein, aber die Ursache eines Crashs zu diagnostizieren dürfte sehr schwierig sein.

  • Ich glaube, ich hatte BGP nie gelernt, bevor ich davon hörte, dass es Probleme verursacht. Obwohl es wie TCP/IP für das Internet unverzichtbar ist: TCP/IP lernt man an der Uni, begegnet ihm im Berufsleben und liest viele Bücher darüber, aber BGP ist mir an Uni, Arbeitsplatz und in Büchern fast nie begegnet.
    TCP/IP kann man zu Hause mit Spielzeugprojekten „ausprobieren“ und dabei lernen, aber bei BGP weiß ich nicht, wie man das anstellen soll. Wie lernt man BGP zu Hause?

    • Man kauft einen Router mit BGP-Implementierung. Es gibt günstige Geräte wie Mikrotik, und es gibt Open-Source-Implementierungen.
      Im Artikel kommt bird vor, und eine weitere sehr beliebte Implementierung ist FRR (Free Range Routing). Zwei Docker-Container zu starten, zwischen ihnen eine BGP-Session aufzubauen und zum Beispiel intern konfigurierte statische Routen zu propagieren, ist sehr einfach.
      Wenn du geführte Tutorials magst, ist https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ ziemlich gut und geht auch auf etwas fortgeschrittenere Themen ein. Alles, was man zum Mitmachen braucht, ist freie Software.
    • DN42[1] bietet eine Spielwiese, auf der man Routing-Techniken ausprobieren kann. Wenn du nicht viel Zeit investieren willst, würde ich nicht empfehlen, dort tief einzusteigen. Selbst wenn man recht vertraut mit Networking ist, bleibt WAN-Routing ziemlich verwirrend.
      Der einfachste Weg, praktische Erfahrung mit irgendeiner Networking-Technik zu sammeln, ist vermutlich GNS3.
      [1]: https://wiki.dn42.us/home
    • BGP ist wie internationale Schifffahrt. Die Welt braucht es unbedingt, damit sie funktioniert, aber die meisten Menschen müssen nicht direkt damit interagieren.
      Eine Möglichkeit zum Experimentieren ist so etwas: https://www.eve-ng.net/
      Eine andere Möglichkeit ist, ein paar virtuelle Maschinen mit mehreren Netzwerkinterfaces zu erstellen, dazwischen ein Netzwerk aufzubauen und einen BGP-Routing-Daemon zu verwenden.
      https://bird.network.cz/
      https://www.nongnu.org/quagga/
      Solche Dinge gibt es.
    • In meinem Networking-Kurs im Bachelor wurde BGP nicht behandelt, im Networking-Kurs im Master dagegen schon.
      Wir nutzten ein Python-Paket, um mehrere AS zu simulieren, aber ich weiß nicht mehr, welches Paket es war.
    • In meinem Netzwerk-Kurs im Bachelor wurde BGP ein wenig behandelt, aber nur als Erklärung an der Tafel.
      Um mit BGP zu experimentieren, kann man wie der Autor dieses Artikels einen Netzwerksimulator verwenden. Im Kurs nutzten wir gini[1], das wohl von einem Doktoranden des Professors gebaut worden war, und der Autor scheint gns3 zu verwenden, das wie eine Cisco-spezifische Version von ns3 aussieht. ns3 habe ich einmal ausprobiert, aber die Lernkurve war steil. Der gini-Simulator hat eine einfachere Benutzeroberfläche, ist aber vermutlich weniger leistungsfähig.
      [1] https://citelab.github.io/gini5/
      [2] https://docs.gns3.com/docs/

  • Es sieht so aus, als wäre BGP deutlich stabiler gewesen, wenn sich mehrere Hardwareanbieter auf eine Standardmethode zur Behandlung solcher Dinge geeinigt hätten.
    Liegt das eigentliche Problem darin, dass jeder Anbieter Lock-in-Effekte will und deshalb nicht standardisiert?
    Allerdings ist mein Verständnis von BGP oberflächlich und dürftig; ich bin kein Experte.

  • Angesichts der Auswirkungen solcher Bugs ist es erstaunlich, dass es kein Konsortium mit einer Interoperabilitäts-Testsuite gibt.
    Vielleicht gibt es eines, aber genau dieses Problem war nicht in der Testsuite. Dann ist es wiederum erstaunlich, dass man nicht per Fuzzer oder maschineller Generierung alle möglichen Paketfehler durchsucht und daraus Testfälle erstellt. Es wäre doch in Ordnung, wenn die Suite Stunden oder Tage zur Ausführung bräuchte.
    Der Autor dieses Artikels hat einen Fuzzer mit gewisser Abdeckung gebaut und scheint schon früher auf ähnliche Probleme gestoßen zu sein. Es ist überraschend, dass die Anbieter diese Arbeit nicht aktiv aufgreifen.

  • Mehrere Anbieter hatten diesen Bug in der Vergangenheit: https://www.kb.cert.org/vuls/id/347067
    Es gab CVE-2023-4481 (Juniper), CVE-2023-38802 (FRR), CVE-2023-38283 (OpenBGPd) und CVE-2023-40457 (EXOS).
    Arista war damals nicht betroffen.

  • Ich frage mich, ob es etwas gibt, das in Größe und zufälliger Komplexität so byzantinisch verflochten ist wie die Internet-Infrastruktur.