Zusammenfassung

  • LACNIC eröffnet seinen Beitrag vom 28. Juli mit einem fehlerhaften BGP-Prefix-SID-Attribut, Code 40, das am 20. Mai 2025 beobachtet wurde; binnen zehn Sekunden sollen mehr als 150.000 Updates aufgetreten sein.
  • Der Bericht sagt, Cisco IOS-XR und Nokia SR OS hätten das Attribut verworfen, Junos habe es weitergegeben, Arista EOS Sitzungen zurückgesetzt und mehrere IXP-Routenserver hätten es transportiert.
  • RFC 8669 verlangt, ein syntaktisch fehlerhaftes Prefix-SID-Attribut zu verwerfen und den Fehler zu protokollieren. Die Norm nennt jedoch weder das installierte Release noch die aktive Fehlertoleranz oder geerbte Nachbarkonfiguration.
  • Eine öffentliche Konformitätsmatrix sollte dieselben bereinigten UPDATE-Bytes mit Plattform, Release, wirksamer Konfiguration, Beziehungsgrenze, Aktion, ausgehenden Bytes und Routenauswirkung verbinden. Der Herstellername allein ist zu grob.

Drei Verben für dasselbe UPDATE

LACNIC veröffentlichte am 28. Juli einen bemerkenswert konkreten Beitrag zur Routingsicherheit. Er beginnt nicht mit dem üblichen Paar aus Präfix-Hijack und Route Leak, sondern mit einer BGP-Nachricht, deren Ursprung durchaus autorisiert sein kann und deren Pfadattribut trotzdem verschiedene Implementierungen auseinanderlaufen lässt. Am 20. Mai 2025 wurde demnach ein beschädigtes Prefix-SID-Attribut beobachtet. Prefix-SID ist optional und transitiv; IANA hat ihm den Attributcode 40 zugewiesen.

Der geschilderte Pfad war heterogen. Cisco IOS-XR und Nokia SR OS entfernten das fehlerhafte Attribut und arbeiteten weiter. Junos transportierte die Nachricht unverändert. Arista-Geräte setzten beim Empfang BGP-Sitzungen zurück. Routenserver an mehreren Internetknoten reichten das Attribut weiter. In einem Zehn-Sekunden-Fenster, so der Beitrag, entstanden mehr als 150.000 Updates; Routen mehrerer namentlich genannter Netze flackerten. Für Arista wird ergänzt, das Verhalten sei ab EOS 4.28.11 geändert worden.

Diese Gegenüberstellung leistet etwas Wichtiges. Sie trennt eine fehlerhafte Attributverarbeitung von der Frage, ob ein Ursprung durch RPKI autorisiert ist. Eine gültige ROA kann die Kombination aus Präfix und Ursprungs-AS bestätigen. Sie garantiert nicht, dass jeder Parser entlang des Pfads ein optional-transitives Objekt gleich behandelt.

Doch zwischen dem nützlichen Befund und einer wiederholbaren Aussage fehlt eine Spalte. Cisco, Nokia, Juniper und Arista sind Hersteller beziehungsweise Produktfamilien, keine vollständigen Betriebszustände. Ein Netzteam erfährt aus dem Namen nicht, welche Software lief, ob eine RFC-7606-Option aktiv war, welche Einstellung aus Peer-Gruppe oder Template geerbt wurde und ob das UPDATE an einer Kunden-, Transit-, Peer- oder Routenservergrenze ankam.

Die Norm ist bestimmt, der Einsatz bedingt

RFC 8669 formuliert die Fehlerbehandlung für Prefix-SID präzise. Das Attribut besteht aus TLVs. Ist das Attribut zu kurz, hat ein TLV eine unzulässige Länge oder ragt ein TLV über das Attributende hinaus, muss der empfangende BGP-Sprecher das Attribut verwerfen und den Fehler protokollieren. Die vorgeschriebene Handlung verweist auf Attribute discard aus RFC 7606.

Das ist die Sollreaktion einer konformen Implementierung unter den einschlägigen Bedingungen. Es ist kein Inventar dessen, was auf allen installierten Routern geschieht. Ein Fix kann nur in bestimmten Release-Zweigen vorhanden sein. Die tolerantere UPDATE-Behandlung kann konfigurierbar sein. Ein Nachbar kann eine geerbte Einstellung erhalten, die von der sichtbaren Grundkonfiguration abweicht.

Die zeitnahe Analyse von Ben Cox bewahrt deshalb eine wesentliche Einschränkung: IOS XR und SR OS hätten das problematische Objekt gefiltert, sofern die Systeme für RFC-7606-Fehlertoleranz konfiguriert gewesen seien. LACNIC verdichtet dies zu dem Satz, beide Plattformen hätten getan, was RFC 7606 vorsehe. Beide Fassungen können denselben beobachteten Ausgang beschreiben; nur die erste verrät, dass Konfiguration Teil des Nachweises sein kann.

Das ist kein Vorwurf gegen technische Verdichtung. Ein aktueller Bericht muss lesbar bleiben, und ein Produktionsvorfall hinterlässt selten ein perfektes Laborprotokoll. Sinnvoll ist nicht, die klare Aussage in allgemeiner Vorsicht aufzulösen. Sinnvoll ist, die fehlenden Bedingungen nachzuliefern.

Die öffentliche NANOG-Diskussion zeigt den Bedarf. Teilnehmer verbanden das Verhalten mit Arista-Bug 899981 und nannten korrigierte Releases in vier EOS-Zweigen: 4.28.11, 4.29.8, 4.30.6 und 4.31.2. Zugleich fragten sie, ob die Änderung für genau die Nachricht dieses Tages das sauberste Ergebnis geliefert hätte. Eine spätere Arista-Präsentation auf dem JANOG 57 wiederholt Herstellervergleich und Fixliste. Das ist belastbarer Betriebskontext, aber noch kein kontrollierter Replay desselben Inputs über alle vier Plattformfamilien.

Eine Update-Rate ist keine Schadenszählung

Mehr als 150.000 ist eine starke Zahl, weil sie Verstärkung sichtbar macht. Sie darf ihre Einheit jedoch nicht verlieren. Beschrieben wird die an einem Collector beobachtete Update-Rate, gemittelt über zehn Sekunden. Gemeint sind nicht 150.000 einzigartige Routen, Sitzungen, Router, Netze oder Ausfälle.

Auch die im Zusammenhang genannten Netze — darunter Starlink, Disney, Zscaler und ByteDance — sind keine Geräteliste. Wenn ihre Routen in einer verteilten Kontrollebene flappen, beweist das weder ein installiertes Arista-Release noch den Empfang derselben Bytes vom selben Nachbarn oder dieselbe Auswirkung auf Dienste. Es sind Beobachtungen aus bestimmten Blickpunkten, keine Vollerhebung der Betroffenen.

Die Herkunft bleibt ebenfalls begrenzt. Die Quellen sprechen von einem AS im asiatisch-pazifischen Raum und nennen plausible unbeabsichtigte Wege zum Fehler, darunter Fehlkonfiguration, doppelte Automatisierung oder Softwaredefekt. Böswillige Absicht ist nicht belegt. Eine wissenschaftliche Angriffsklasse macht dieses konkrete Ereignis nicht automatisch zu einem Angriff.

Gerade diese Grenzen erhöhen den praktischen Wert. Sie zeigen, welche Beweismittel beim nächsten Mal erhalten bleiben müssen.

Aus Logos muss eine Prüfmatrix werden

LACNIC kann aus der Episode ein wiederverwendbares Betriebsinstrument machen, ohne Kontrolle über Hersteller-Code oder Mitgliedsnetze zu behaupten. Das geeignete öffentliche Objekt wäre eine versionierte Konformitätsmatrix, gespeist aus einem bereinigten Replay desselben fehlerhaften UPDATEs.

Jede Zeile beginnt mit einem unveränderlichen Hash der Eingabebytes und einer Version des Testvektors. Sie hält Code 40, Flags, deklarierte Attributlänge und den genauen TLV-Fehler fest. Es folgen Plattform, exaktes Software-Release, zugehörige Fehlerkennung und die wirksame Fehlerbehandlung nach Vererbung aus Gruppen-, Template- und Nachbareinstellungen.

Die Beziehung gehört in eine eigene Spalte. Eine Implementierung kann an einer internen Sitzung anders handeln als gegenüber einem Kunden, Transitlieferanten, settlement-free Peer oder IXP-Routenserver. Auch „Routenserver“ ist kein einheitliches Produkt und keine einheitliche Filterrichtlinie.

Die Ausgangsspalten nennen den tatsächlichen Vorgang: Sitzungsreset, Deaktivierung einer Adressfamilie, treat-as-withdraw, Attribute discard, Annahme oder eine andere definierte Handlung. Wurde die Nachricht weitergesendet, gehört der Hash der bereinigten Ausgangsbytes dazu. Wurde sie nicht gesendet, wird auch das ausdrücklich festgehalten. Anschließend wird die Aktion mit Sitzungszustand und kontrollierter Routenwirkung in Adj-RIB-In, Loc-RIB und Weiterleitungstabelle verknüpft.

Dafür müssen keine Peer-IP, kein Kundenname, kein Zugangsschlüssel, keine private Topologie und kein Produktionskonfigurationsdump veröffentlicht werden. Rohmitschnitte dürfen zugangsgeschützt bleiben; öffentlich reichen Testvektor, Methode, aggregiertes Ergebnis, Verluststatus, Korrekturhistorie und Wiederholungsdatum.

Eine solche Aufzeichnung trennt auch Zuständigkeiten. RFC-Autoren bestimmen die geforderte Aktion. Hersteller implementieren und korrigieren Parser. Betreiber wählen Releases und Richtlinien. Routenserverbetreiber entscheiden, welche Attribute ihre Dienstgrenze passieren. LACNICs Rolle ist enger und legitim: den regionalen Forschungsbefund verständlich bewahren und eine reproduzierbare Methode anbieten.

Was die Belege nicht tragen

Die Quellen sagen nicht, LACNIC habe das UPDATE erzeugt, einen betroffenen Routenserver betrieben oder das Ereignis verhindern können. Sie liefern keinen vollständigen Satz betroffener Sitzungen, keine gemessene Nutzerpopulation und keinen Beleg für einen einzigen globalen Ausfall. Sie beweisen auch keine zeitlosen Standardwerte eines Herstellers.

Ebenso wenig verkleinert das Ereignis RPKI in seinem tatsächlichen Geltungsbereich. Origin Validation beantwortet, ob ein Präfix-Ursprungs-Paar von einer gültigen Autorisierung gedeckt ist. Sie prüft nicht jedes optional-transitive Pfadattribut auf Parserverträglichkeit. Die zweite Aufgabe in die erste hineinzulesen, würde zwei verschiedene Kontrollen vermischen.

Die Nachricht lautet daher nicht, Kryptografie habe versagt. Neu ist, dass eine moderne Routingsicherheitsanalyse eine Stelle offenlegt, an der betriebliche Evidenz weiterhin lokal, releaseabhängig und konfigurationsabhängig ist. LACNIC hat die Verben geliefert. Der nächste Bericht sollte die Bedingungen liefern, unter denen jedes Verb wahr war.

Sources