Internetweite Instabilität im Routing durch BGP-Verarbeitungsfehler

 (blog.benjojo.co.uk)
1 Punkte von GN⁺ 2025-05-29 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Fehler bei der Verarbeitung von BGP-Nachrichten verursachte am 20. Mai 2025 massive Routing-Instabilität und bei einigen Netzwerken Unterbrechungen der Internetverbindung
  • Auslöser war ein fehlerhaftes BGP Prefix-SID-Attribut, das bei wichtigen BGP-Implementierungen (insbesondere JunOS und Arista EOS) außergewöhnliche Reaktionen hervorrief
  • Einige Transit-Carrier, darunter Hutchison und Starcloud, leiteten die auslösende Nachricht weiter und vergrößerten so die Auswirkungen
  • Der Vorfall führte in mehr als rund 100 Netzwerken zu einer großen Zahl von BGP-Session-Resets und Instabilität
  • Der Vorfall unterstreicht Schwachstellen bei der fehlertoleranten BGP-Verarbeitung je nach Vendor und den Bedarf an Verbesserungen

27. Mai 2025

Weltweite Instabilität des Internet-Routings durch einen BGP-Verarbeitungsfehler

Am Dienstag, dem 20. Mai 2025, um 7 Uhr UTC verbreitete sich eine BGP-Nachricht, die bei zwei wichtigen BGP-Implementierungen, die häufig für die Verarbeitung von Internet-Traffic eingesetzt werden, ein unerwartetes Verhalten auslöste.

Dadurch wurden zahlreiche „BGP-Sessions für die Internet-Konnektivität“ automatisch beendet, was von begrenzter Routing-Instabilität bis hin zur vorübergehenden Unterbrechung der Konnektivität in einigen Netzwerken reichte.

Die problematische BGP-Nachricht

  • Die Analyse der von bgp.tools gesammelten Sessions zeigt, dass die auslösende BGP-Update-Nachricht äußerlich normal wirkte, intern jedoch ein beschädigtes BGP Prefix-SID-Attribut enthielt, dessen Daten mit 0x00 gefüllt waren
  • Die meisten BGP-Implementierungen (IOS-XR, Nokia SR-OS) filtern dies gemäß RFC7606 (BGP Error Handling) korrekt, doch bei der Interaktion zwischen JunOS und Arista EOS trat ein Problem auf
    • JunOS behält die beschädigte Nachricht bei und leitet sie weiter, während Arista EOS beim Empfang der Nachricht die BGP-Session zurücksetzt
  • In Umgebungen, in denen Juniper-Hardware (JunOS) stark verbreitet ist und mit Arista EOS verbunden wird, sind Unterbrechungen des Internetzugangs von bis zu etwa 10 Minuten möglich

Wer die problematische Nachricht aussendete

  • Die Analyse des bgp.tools-Archivs für diesen Zeitraum zeigt, dass mehrere AS-Origin beteiligt waren

  • Das deutet darauf hin, dass nicht das Netzwerk, das das Prefix erzeugte, sondern ein Transit-Carrier auf dem Übertragungsweg das fehlerhafte Attribut eingefügt hat

  • Mit dem Vorfall in Verbindung gebrachte wichtige AS sind:

    • AS9304 (Hutchison Global Communications Limited)
    • AS135338 (Starcloud Information Limited)
    • AS151326 (DCConnect Communication Pte. Ltd.)
    • AS138077 (PT Abhinawa Sumberdaya Asia)

  • Laut den Daten von bgp.tools ist es sehr wahrscheinlich, dass Starcloud (AS135338) oder Hutchison (AS9304) das Attribut tatsächlich hinzugefügt haben

  • Zu den repräsentativen Prefixes, über die sich das Attribut verbreitete, gehören 156.230.0.0/16 und 138.113.116.0/24

  • Da Hutchison/AS9304 mit zahlreichen Internet Exchanges (IX) verbunden ist, wurde die Nachricht auch an Route-Server weitergeleitet, die bird verwenden

  • Bird unterstützt BGP SID nicht und leitete die Nachricht ohne Filterung an zahlreiche IX weiter, was die netzweite Verwirrung weiter verschärfte

Was ist BGP Prefix-SID?

  • Das BGP Prefix-SID-Attribut sollte normalerweise nur in internen BGP-Sessions verwendet werden und dient dazu, innerhalb eines einzelnen Netzwerks Pfade zu einem Ziel zu definieren (RFC8669)
  • Dass dieses Attribut in die globale Routing-Tabelle gelangte, könnte daran liegen, dass eine externe BGP-Session wie eine interne Session konfiguriert war

Betroffene

  • Eine genaue Identifizierung der Betroffenen ist schwierig, aber Probleme wurden in rund 100 Netzwerken bestätigt, die nach der ersten BGP-Nachricht massive Fluktuationen (Churn) zeigten
  • Normalerweise sammeln die Route-Collector von bgp.tools 20.000 bis 30.000 Nachrichten pro Sekunde, doch zum Zeitpunkt des Vorfalls wurden im 10-Sekunden-Durchschnitt mehr als 150.000 Einträge registriert
  • Das ist ein Signal dafür, dass es auf breiter Front zu schwerwiegenden Störungen in Internetpfaden gekommen ist

Verantwortung der Vendoren und Erkenntnisse

  • Die grundlegende Ursache ist nicht sicher geklärt, doch die internetweite Verbreitung fehlerhafter Nachrichten zeigt, dass bestehende Probleme bei der BGP-Fehlerbehandlung ein reales Risiko darstellen
  • Andere Vendoren filterten das problematische Attribut, doch Juniper ließ es indirekt passieren und leitete es an Arista-Geräte weiter, was wegen unzureichender fehlertoleranter BGP-Logik Session-Resets auslöste
  • Auch in der offiziellen Dokumentation von JunOS wird ausdrücklich erwähnt, dass „nicht die gesamte Nachricht geprüft wird“
  • Durch dieses Design verhindert JunOS zwar das Risiko eines Remote-Session-Resets auf dem eigenen System, kann aber problematische Nachrichten an andere Peers oder Kunden weiterreichen

Fazit

  • Der Vorfall war zwar nur von kurzer Dauer, deutet aber darauf hin, dass die Folgen bei größerer Ausbreitung deutlich schwerwiegender sein könnten

  • Da Dienste zunehmend IP-zentriert werden, reichen die Auswirkungen von Internetstörungen potenziell weit über den bloßen Ausfall des E-Mail-Zugangs für Verbraucher hinaus und können sich auf fehlgeschlagene TV-Übertragungen oder nicht erreichbare Notrufdienste ausweiten

  • Dadurch besteht realistisch sogar das Risiko tatsächlicher Personenschäden, was die Notwendigkeit einer verlässlichen fehlertoleranten BGP-Implementierung bei allen Vendoren unterstreicht

  • Es wird auf die Möglichkeit für Netzwerkbetreiber hingewiesen, an der Analyse der bgp.tools-Daten mitzuwirken (Link vorhanden)

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-29
Hacker-News-Kommentare

  • Im Allgemeinen gilt das Prinzip „be liberal in what you accept, and conservative in what you send“ als Standardansatz.

    • Es gibt Optionen, beschädigte Nachrichten herauszufiltern (drop, Filter), nur die Attribute zu ignorieren und weiterzuleiten (break) oder die Verbindung selbst zu trennen (wie bei Arista).

    • Ich halte die vierte Option (die Arista-Methode) für ein wirklich schwer akzeptables Verhalten.

    • Die dritte (Juniper) ist ebenfalls nicht wünschenswert, aber aus meiner Sicht kein fataler Fehler.

    • Edit: Nach erneutem Lesen war Arista nicht die vierte, sondern die zweite Option (Verbindungsabbruch).

    • Man hat die Verbindung einfach als ungültig behandelt und geschlossen; aus Sicht der User Experience ist das keine besonders gute Entscheidung, aber noch akzeptabel.

    • RFC 7606 (Revised Error Handling for BGP UPDATE Messages) existiert bereits und legt konkret fest, wie mit beschädigten Nachrichten umzugehen ist.

      • Die häufigste Methode ist treat-as-withdraw (so behandeln, als wäre die Route zurückgezogen worden).
      • Wenn man eine beschädigte Nachricht einfach ignoriert, bleibt der vorherige Zustand bestehen, obwohl er tatsächlich nicht mehr gültig ist.

    • Das Prinzip „liberal empfangen, konservativ senden“ ist genau das, was als „robustness principle“ oder „Postel’s Law“ bezeichnet wird.

      • Dieses Prinzip stammt aus den frühen Tagen des Internets in den 1980er- und 1990er-Jahren.
      • Inzwischen ist in der Branche weithin anerkannt, dass dies eine falsche Denkweise war.
      • Dieses Prinzip hat zu Protokollverkrustung und unzähligen Sicherheitsproblemen geführt.

    • Es gab im gesamten Netzwerk Probleme, weil sich die Eigenschaften von BGP ausnutzen ließen und lokale Geräte ihnen unbekannte Attribute einfach weiterreichen konnten.

      • Inzwischen erleben wir die Realität, in der die Nachteile dieser „Funktion“ sichtbar werden.

    • Auch der Autor weist in seinem Beitrag auf diesen Punkt hin.

      • Diese „Funktion“ wirkt wie eine überraschend schlechte Idee, weil das System dadurch Daten, die es nicht versteht, unkritisch weiterleitet.
      • Andererseits konnten sich dank dieser Funktion neue Features wie Large Communities schnell verbreiten, und sie hat die Einführung neuer BGP-Funktionen ermöglicht.

    • Ich stimme diesem Ansatz nicht zu.

      • Es ist viel besser, sowohl bei dem, was man annimmt, als auch bei dem, was man ausgibt, streng und explizit zu sein.

  • Ich erinnere mich noch gut daran, wie wir wie verrückt damit beschäftigt waren, den Bug CVE-2023-4481 netzwerkweit zu patchen.

    • Solche Bugs werden auch in Zukunft ein echter Albtraum bleiben.
    • Aufgrund der Art, wie BGP entworfen und implementiert ist, befürchte ich, dass es sehr lange dauern wird, solche Verhaltensweisen zu korrigieren.

  • Ich habe früher einmal BGP-Funktionen bei einem Hersteller von Telekommunikationsgeräten entwickelt (das ist allerdings ziemlich lange her).

    • Ich halte BGP immer noch für viel zu komplex.

    • Es kommen ständig neue Features hinzu, und die Vendoren implementieren immer wieder nach Standards oder Drafts.

    • Da BGP offenbar niemals verschwinden wird, fühlt es sich so an, als würden solche Bugs immer wieder auftreten.

      • Früher haben Provider wie AT&T und Vendoren wie Juniper oder Cisco BGP aggressiv für MPLS- und VPN-Funktionen eingesetzt, wodurch das System in tiefe Komplexität geraten ist.
        • Es war übermäßig komplex, aber einige haben damit viel Geld verdient.

  • HGC Global Communications Limited (umbenannt von Hutchison Global Communications Limited, abgekürzt HGC) ist ein Internetdienstanbieter aus Hongkong.

  • Es wirkt so, als wäre BGP deutlich stabiler, wenn sich die verschiedenen Hardware-Vendoren bei solchen Themen stärker auf Standards einigen würden.

    • Ich frage mich, ob das eigentliche Problem darin liegt, dass die Vendoren Standardisierung vermeiden, um Kunden an sich zu binden (Lock-in).
    • Vorab: Mein Verständnis von BGP ist eher oberflächlich.

  • Vielleicht geht es nur mir so, aber ich hatte von BGP noch nie gehört, bevor ich hörte, dass es irgendein Problem verursacht hat.

    • Es ist wie TCP/IP ein essenzielles Protokoll des Internets, aber während ich TCP/IP in Schule, Beruf und Büchern oft begegnet bin, kam BGP nie vor.
    • Mit TCP/IP kann man zu Hause üben und lernen, aber bei BGP habe ich keine Ahnung, wie man damit „zu Hause herumspielen“ könnte.

      • Mich würde interessieren, welche Möglichkeiten es gibt, BGP zu Hause praktisch auszuprobieren.

      • Man kann einen echten Router mit BGP-Implementierung verwenden (unter den günstigeren Geräten etwa Mikrotik) oder eine Open-Source-Implementierung einsetzen.

        • Dazu gehören bird und das sehr populäre FRR (Free Range Routing).
        • Man kann zwei Docker-Container starten, eine BGP-Session zwischen ihnen aufbauen und statische Routen propagieren lassen.
        • Falls du ein Tutorial suchst: Der Guide unter diesem Link ist gut aufbereitet und lässt sich mit freier Software nachvollziehen.

      • DN42 ist ein Spielplatz, auf dem man Routing-Technologien praktisch üben kann.

        • Allerdings muss man dafür Zeit investieren; als lockerer Einstieg eignet es sich nicht.
        • Ich befasse mich zwar recht viel mit Networking, aber WAN-Routing finde ich trotzdem noch verwirrend.
        • GNS3 ist am einfachsten, um jede Art von Netzwerktechnologie praktisch auszuprobieren.
        • DN42-Wiki

      • In meinem Bachelor-Netzwerkkurs wurde BGP nicht behandelt, aber im Master haben wir BGP gelernt.

        • Wir haben damals ein Python-Paket verwendet, mit dem sich mehrere AS simulieren ließen, aber ich erinnere mich nicht mehr an den genauen Namen.

      • In meinem Bachelor-Netzwerkkurs wurde BGP nur kurz an der Tafel erwähnt.

        • Für BGP-Übungen kann man Netzwerksimulatoren nutzen, so wie es auch der Autor getan hat.
        • In unserem Kurs haben wir einen Simulator namens gini verwendet; das war ein Programm, das von einem Doktoranden unseres Professors entwickelt wurde.
        • Das vom Autor verwendete gns3 ist wie ein auf Cisco fokussiertes ns3.
        • ns3 wirkte schwierig, weil es sehr viel zu lernen gab.
        • gini hat eine einfachere Oberfläche, ist aber leistungsschwächer.
        • Infos zum gini-Projekt
        • GNS3-Dokumentation

      • Es fühlt sich so an, als könne man BGP nur dann wirklich „üben“, wenn man ein großes Netzwerk verwaltet, das mit echtem Internetverkehr verbunden ist.

        • Zu Hause kann man im Grunde nur mit Netzwerksimulatoren daran herumprobieren.

  • Auch andere Vendoren hatten in der Vergangenheit ähnliche Bugs wie im Artikel beschrieben.

  • Auf unserem IOS-XR-Chassis haben wir ebenfalls einmal ein ähnliches Paket empfangen.

    • Gleichzeitig gab es auch viele BGP-Routenankündigungen.

    • Ich weiß nicht genau, welches Upstream-Gerät es war.

    • Das hat mich auf die Frage gebracht, ob das BGP-Protokoll überhaupt ordentlich per Fuzzing getestet wird.

    • Vielleicht traut sich niemand, absichtlich Störungen zu erzeugen, weil es ein so wichtiges Protokoll ist.

    • Einen Fuzzer für BGP zu schreiben wäre wahrscheinlich einfach, aber die Crash-Diagnose könnte extrem schwierig sein.

      • (Autor des Beitrags)

  • Man fragt sich, ob es außer dem Internet-Backbone noch ein anderes System gibt, das so riesig ist und in dem sich so viel zufällige Komplexität angesammelt hat.

  • Angesichts der Auswirkungen solcher Bugs überrascht es mich, dass es offenbar kein Konsortium gibt, das so etwas wie eine Interoperabilitäts-Test-Suite betreibt.

    • Oder vielleicht gibt es ein solches Konsortium doch, und dieses Problem lag einfach außerhalb des Testumfangs.
    • Es scheint naheliegend, mit einem Fuzzer oder anderen automatisierten Verfahren verschiedenste Testfälle zu erzeugen, um alle möglichen Paketfehler abzudecken und die Coverage zu erhöhen.
    • Selbst wenn die Laufzeit mehrere Tage beträgt.
    • Der Autor des Artikels hat tatsächlich selbst einen Fuzzer gebaut und benutzt und ist dabei mehrfach auf ähnliche Probleme gestoßen.
    • Es wirkt merkwürdig, dass Vendoren an solch wichtiger Forschung nicht aktiver interessiert sind.