Zusammenfassung

  • Cloudflare zufolge entfernte eine am 22. Januar 2026 zusammengeführte Bereinigung veraltete Verweise auf lokale Präfixlisten des Standorts Bogotá. In einer generierten IPv6-Exportrichtlinie blieb jedoch ein Term mit route-type internal und der Aktion accept bestehen.
  • Mit dem letzten engen Auswahlkriterium verschwand nicht der ganze Term, sondern nur seine letzte präzise Begrenzung. Die resultierende Konfiguration blieb syntaktisch verwendbar, konnte aber eine wesentlich größere Menge intern verfügbarer Routen für den Export auswählen.
  • Die Automatisierung spielte die Konfiguration um 20:25 UTC auf einem Router in Miami aus. Cloudflare begrenzte die öffentliche Auswirkung auf 25 Minuten und ausschließlich auf IPv6.
  • Cloudflare berichtete über Überlastung zwischen Miami und Atlanta, höhere Latenz, erhöhte Verluste bei einem Teil des Kundenverkehrs sowie das Verwerfen von nicht für nachgelagerte Netze bestimmtem Verkehr. Das verworfene Volumen habe in der Spitze etwa 12 Gbit/s erreicht.
  • Eine sichere Exportrichtlinie muss nicht nur Präfix und Ursprung, sondern auch die erlaubte Beziehung eines Pfades berücksichtigen. Von Peers, Providern, Kunden und dem eigenen Netz stammende Routen brauchen jeweils unabhängige Beziehungskontrollen.
  • Eine Ein-Router-Freigabe ist erst dann ein belastbarer Canary, wenn sie vor der Aussendung die Differenz der Routenmengen und des nachbarschaftsspezifischen Adj-RIB-Out prüft und bei einer Beziehungsverletzung automatisch abbricht.
  • RPKI-Origin-Validierung hätte eine solche Beziehungspanne nicht zwangsläufig verhindert: Der Ursprung der von Cloudflare beschriebenen Meta-Routen blieb AS32934. Die Frage war nicht nur, ob der Ursprung autorisiert war, sondern ob der weitere Exportpfad zulässig war.
  • Öffentliche RIPEstat-Daten bestätigen die Sichtbarkeit des auffälligen AS-Pfades außerhalb von Cloudflare. Sie beweisen weder die interne Konfiguration noch Verkehrsschäden, den vollständigen Präfixumfang oder die kommerziellen Beziehungen zwischen allen beteiligten Netzen.
  • Wiederherstellung verlangt eine doppelte Korrektur: auf dem laufenden Router und in der erzeugenden Quelle. Dazu gehören das Anhalten der Automatisierung, die externe Bestätigung der Rücknahmen und eine namentlich zugewiesene Verantwortung für die Wiederfreigabe.

Ein eng begrenzter Vorfall mit weitreichender Kontrollfrage

Der Vorfall vom 22. Januar 2026 war nach der Darstellung Cloudflares kein Problem eines falschen Routenursprungs. Er war auch kein bloßer Ausfall einer Cloud-Anwendung. Im Mittelpunkt stand die BGP-Exportrichtlinie eines einzelnen Edge-Routers in Miami: Eine automatisiert erzeugte Konfiguration erlaubte diesem Router, IPv6-Routen weiterzugeben, die das Netz von anderen Parteien gelernt hatte und die nicht in diese Richtung exportiert werden sollten.

Damit berührt der Vorfall eine der grundlegenden Verantwortungsfragen automatisierter Netzwerke. Was genau wird bei einer Änderung freigegeben? Der Quelltext, die Absicht der Änderung, die vom Generator erzeugte Konfiguration oder die konkrete Menge von Routen, die ein Router danach an jeden einzelnen Nachbarn ankündigen kann?

Diese Ebenen sind nicht austauschbar. Eine kleine und nachvollziehbar wirkende Änderung im Repository kann eine große semantische Veränderung in der erzeugten Policy auslösen. Eine syntaktisch gültige Konfiguration kann betrieblich falsch sein. Eine laufende Policy kann wiederum andere Routen auswählen, als ein Prüfer anhand eines Textvergleichs erwartet hat. Selbst die Information, welche Routen im lokalen BGP-Bestand vorhanden sind, sagt noch nicht, welche davon tatsächlich pro Nachbar exportiert und als BGP-Update ausgesendet wurden.

Cloudflare beschrieb die Ursache als Folge einer Bereinigung nach Infrastrukturarbeiten in Bogotá. Veraltete Verweise auf standortlokale Präfixlisten sollten entfernt werden. Das ist als Wartungsziel zunächst eng: Referenzen auf nicht mehr benötigte lokale Objekte verschwinden. Die entscheidende Wirkung trat jedoch im generierten Ergebnis ein. Nachdem die Präfixlistenbedingung entfernt worden war, blieb ein Term bestehen, der weiterhin route-type internal prüfte und anschließend accept ausführte.

Nach Cloudflares Darstellung erfasste route-type internal nicht nur lokal erzeugte oder für den Export eindeutig bestimmte Routen, sondern auch nicht extern gelernte Routen einschließlich über iBGP verfügbarer Routen. Damit konnte die verbliebene Regel intern weitergereichte IPv6-Routen akzeptieren. Die letzte enge Bedingung war verschwunden, die exportierende Autorität der Regel dagegen nicht.

Der Vorfall ist deshalb ein Test für die semantische Sicherheit von Richtliniengeneratoren. Ein System, das nur feststellt, dass der Quelltext kompiliert, die Konfiguration gerendert werden kann und der Router sie akzeptiert, prüft nicht die eigentliche Risikofrage: Welche zusätzlichen Routen darf dieser Term nach der Änderung an welchen Nachbarn weitergeben?

Chronologie: Von der Repository-Änderung bis zur Wiederfreigabe

Cloudflare nennt für den 22. Januar 2026 eine präzise Abfolge. Die auslösende Repository-Änderung wurde demnach um 19:52 UTC zusammengeführt. Zwischen diesem Zeitpunkt und der späteren Router-Ausführung bestand bereits ein wichtiger Kontrollpunkt: Der Quellzustand war geändert, die potenziell problematische Wirkung aber noch nicht im öffentlichen Routing sichtbar.

Um 20:25 UTC führte die Automatisierung die Änderung auf einem Router in Miami aus. Cloudflare setzt den Beginn der Auswirkungen auf denselben Zeitpunkt. Der Umfang der Ausspielung auf zunächst einen Router begrenzte zwar die Zahl der unmittelbar veränderten Geräte, verhinderte aber nicht, dass dieser eine Router unerwünschte BGP-Ankündigungen an externe Nachbarn abgab.

Das ist ein wesentlicher Unterschied zwischen einer gestuften Ausrollung und einem sicheren Canary. Eine gestufte Ausrollung begrenzt zunächst die Anzahl veränderter Systeme. Ein sicherer Canary begrenzt zusätzlich, was das erste System nach außen tun darf. Wenn der Router bereits bei der ersten Stufe unzulässige Routen exportiert, kann ein einzelnes Gerät ausreichend sein, um externe Pfade zu verändern und Verkehr anzuziehen.

Cloudflare zufolge begann die Untersuchung um 20:40 UTC, also 15 Minuten nach Beginn der Auswirkung. Um 20:44 wurde der Vorgang als Incident eingestuft beziehungsweise entsprechend eskaliert. Diese vier Minuten markieren den Übergang von einer technischen Untersuchung zu einer formalen Störungsbehandlung.

Um 20:50 griff ein Operator manuell ein. Cloudflare berichtet, dass die Router-Policy zurückgesetzt und die Automatisierung angehalten wurde. Das beendete nach der veröffentlichten Zeitgrenze die 25-minütige öffentliche Auswirkung. Die manuelle Korrektur am Router war für die unmittelbare Eindämmung entscheidend, löste aber noch nicht das gesamte Zustandsproblem: Im Repository bestand weiterhin die Änderung, aus der die fehlerhafte Konfiguration erneut hätte erzeugt werden können.

Die Repository-Änderung wurde laut Cloudflare um 21:47 zurückgenommen. Erst damit waren laufender Zustand und erzeugende Quelle wieder aufeinander ausgerichtet. Um 22:07 beurteilten die Betreiber die Automatisierung als wieder funktionsfähig. Um 22:40 wurde sie erneut freigegeben.

Die Zeitachse enthält somit mindestens drei unterschiedliche Wiederherstellungsmarken. Um 20:50 wurde die unmittelbare Auswirkung durch einen manuellen Eingriff begrenzt. Um 21:47 wurde der Quellzustand korrigiert. Um 22:40 wurde die zuvor pausierte Automatisierung wieder in Betrieb genommen. Wer nur den ersten Zeitpunkt als „behoben“ erfasst, übersieht das Risiko einer erneuten Ausspielung aus einer weiterhin fehlerhaften Quelle. Wer nur die letzte Wiederfreigabe betrachtet, verwischt dagegen die deutlich frühere Eindämmung des sichtbaren Routingproblems.

Cloudflare begrenzte den öffentlichen Einfluss auf IPv6 und auf 25 Minuten. Diese Aussage definiert den offengelegten Umfang, beweist aber nicht automatisch, wie jede interne Kontrollschicht zwischen IPv4 und IPv6 getrennt war. Aus der Tatsache, dass Cloudflare nur IPv6-Auswirkungen meldete, lässt sich keine vollständige Architektur der Adressfamilientrennung, der Generatoren oder der zugrunde liegenden Routerkonfiguration ableiten.

Die berichteten Auswirkungen und ihre Zuordnungsgrenze

Cloudflare berichtete, dass unerwünschte Routen in Miami zu einer Überlastung zwischen Miami und Atlanta führten. Nach Angaben des Unternehmens stiegen auf den betroffenen Verbindungen die Latenzen, und ein Teil des Cloudflare-Kundenverkehrs erlitt erhöhte Verluste. Router-Firewallfilter hätten Verkehr verworfen, der nicht für nachgelagerte Netze bestimmt war. Das verworfene Verkehrsvolumen habe in der Spitze etwa 12 Gbit/s erreicht.

Jede dieser Messgrößen bleibt eine Cloudflare zugeschriebene Angabe. Die öffentliche Dokumentation bietet keinen unabhängigen vollständigen Verkehrsmitschnitt, aus dem sich Umfang, betroffene Kunden, wirtschaftlicher Schaden oder private interne Pfade rekonstruieren ließen. Ebenso lässt sich aus den veröffentlichten Daten weder eine Gesamtzahl betroffener Kunden noch eine vollständige Liste aller berührten Präfixe ableiten.

Die Größenordnung von etwa 12 Gbit/s ist betrieblich relevant, darf aber nicht mit einem vollständigen Maß des Gesamtschadens gleichgesetzt werden. Verworfenes Volumen, erhöhte Latenz, Paketverlust und veränderte BGP-Sichtbarkeit sind unterschiedliche Messdimensionen. Ein einzelner Wert beantwortet nicht automatisch, wie viele Anwendungen beeinträchtigt waren, wie lange jede Verbindung betroffen blieb oder welche Gegenmaßnahmen in einzelnen Netzen wirkten.

Auch die Bezeichnung des Ereignisses muss präzise bleiben. Der veröffentlichte Sachstand beschreibt eine automatisierungsbedingte Routing-Fehlkonfiguration und ein daraus entstandenes Routenleck. Er liefert keinen Beleg für einen Cyberangriff, eine böswillige Handlung, eine Übernahme fremder Präfixe oder eine absichtliche falsche Ursprungsankündigung. Der von Cloudflare beschriebene Ursprung der betroffenen Meta-Routen blieb Meta AS32934.

Wie die Exportregel ihre Begrenzung verlor

BGP-Exportrichtlinien entscheiden, welche im Router verfügbaren Routen einem bestimmten externen Nachbarn angeboten werden. Ein Policy-Term verbindet typischerweise mehrere Bedingungen mit einer Aktion. Bedingungen können etwa Präfixlisten, Communities, Routenursprung, Adressfamilie, Nachbargruppe oder Beziehungsklasse betreffen. Erst wenn die vorgesehenen Bedingungen erfüllt sind, soll eine Aktion wie accept greifen.

Im Cloudflare-Fall sollte eine Bereinigung Verweise auf nicht mehr benötigte Präfixlisten entfernen. Das Risiko entstand nicht dadurch, dass ein neuer, offensichtlich großzügiger Exportterm hinzugefügt wurde. Es entstand dadurch, dass eine vorhandene Regel nach dem Löschen ihres letzten engen Prädikats weiterbestand.

Vor der Änderung konnte eine Präfixlistenbedingung die Auswahl auf eine ausdrücklich definierte Routengruppe beschränken. Nach ihrem Wegfall blieb nach Cloudflares Darstellung route-type internal. Zusammen mit accept bildete dies weiterhin eine ausführbare Entscheidung. Die Regel war nicht leer im syntaktischen Sinn. Sie war vielmehr unterbestimmt im betrieblichen Sinn: Sie enthielt noch genug Struktur, um gültig zu sein, aber nicht mehr genug Einschränkungen, um die beabsichtigte Exportmenge zu begrenzen.

Genau hier versagt eine reine Syntaxprüfung. Der Router kann eine Konfiguration akzeptieren, obwohl sie mehr Routen exportiert als vorgesehen. Auch ein Generator kann technisch korrekt arbeiten, indem er aus seinen Eingaben deterministisch eine gültige Konfiguration erzeugt. Wenn die Eingabemodellierung nicht festlegt, dass ein Term ohne seine letzte Präfix- oder Beziehungsbedingung verworfen, deaktiviert oder ausdrücklich abgelehnt werden muss, kann „korrekte Generierung“ dennoch zu einem falschen Netzverhalten führen.

Ein belastbarer Generator braucht daher Invarianten, die über Syntax hinausgehen. Ein akzeptierender Exportterm darf nicht allein deshalb weiterbestehen, weil noch irgendein allgemeines Prädikat vorhanden ist. Das System muss wissen, welche Bedingungen sicherheitsrelevant sind. Wenn eine Änderung die letzte Präfixbegrenzung, die letzte vertrauenswürdige Community, den letzten Nachbarschaftsfilter oder die letzte Beziehungseinschränkung entfernt, sollte sie einen semantischen Fehler auslösen.

Die Prüfung sollte außerdem nicht nur fragen, ob ein Term „leer“ geworden ist. Auch ein nicht leerer Term kann gefährlich erweitert sein. Entscheidend ist die Differenz der Routenmenge: Welche Routen erfüllten die Regel vor der Änderung, welche danach, und welche neuen Exporte entstehen für jeden Nachbarn?

Neun getrennte Beweisebenen

Eine nachvollziehbare Änderungskontrolle muss mehrere Zustände getrennt erhalten. Sie bilden gemeinsam eine Beweiskette, dürfen aber nicht ineinander aufgelöst werden.

Die erste Ebene ist die Quellabsicht. Sie beschreibt, welches betriebliche Ziel die Änderung verfolgt. Im vorliegenden Fall war das die Entfernung veralteter Bogotá-bezogener Präfixlistenreferenzen. Diese Absicht erklärt den Anlass, beweist aber nicht die Wirkung.

Die zweite Ebene ist die gerenderte Kandidaten-Policy. Sie zeigt, was der Generator aus der Änderung erzeugt hat. Hier muss sichtbar werden, ob ein Term nach dem Wegfall seiner engen Bedingung mit route-type internal und accept fortbesteht.

Die dritte Ebene ist die tatsächlich laufende Policy auf dem Router. Kandidat und laufender Zustand können sich durch Ausspielungsfehler, lokale Abweichungen, nicht übernommene Teile oder manuelle Eingriffe unterscheiden. Deshalb reicht weder das Repository noch eine offline gerenderte Datei als Beweis für den aktiven Zustand.

Die vierte Ebene ist die Loc-RIB, also die lokal für BGP-Auswahl verfügbaren beziehungsweise ausgewählten Routen. Sie beantwortet, welche Pfade der Router intern kennt. Sie beantwortet noch nicht, was er an einen bestimmten Nachbarn exportiert.

Die fünfte Ebene ist das jeweilige Adj-RIB-Out. Für jeden Nachbarn muss nachvollziehbar sein, welche Routen nach Anwendung der Exportpolicy zur Ankündigung vorgesehen sind. Gerade hier wird die Beziehung zwischen Route und Empfänger konkret.

Die sechste Ebene sind die tatsächlich erzeugten und ausgesendeten BGP-Updates. Ein berechneter Adj-RIB-Out-Zustand und die über die Sitzung emittierten Änderungen sind eng verbunden, aber für forensische Nachweise nicht dasselbe. Zeitpunkte, Rücknahmen und Sitzungsereignisse müssen erhalten bleiben.

Die siebte Ebene ist der Zustand von Routing Information Base und Forwarding Information Base. Eine BGP-Ankündigung verändert die externe Pfadsicht; die Weiterleitung des tatsächlich ankommenden Verkehrs hängt zusätzlich von den installierten Weiterleitungsentscheidungen und Filtern ab.

Die achte Ebene besteht aus Verkehrs-, Latenz-, Verlust- und Verwerfungsdaten. Sie zeigt betriebliche Auswirkungen, beweist aber für sich genommen nicht, welcher Generator-Term die Ursache war.

Die neunte Ebene sind externe Beobachtungen durch Route Collectors und andere Netze. Sie können bestätigen, dass ein Pfad außerhalb des eigenen autonomen Systems sichtbar war. Sie können jedoch weder den privaten Quelltext noch die interne Policy-Auswertung ersetzen.

Eine verantwortbare Freigabe verknüpft diese Ebenen mit Zeitstempeln und einer eindeutigen Änderungsidentität. Der entscheidende Nachweis lautet dann nicht lediglich: „Die Konfiguration wurde erfolgreich angewendet.“ Er lautet: „Die beabsichtigte Änderung erzeugte diese Kandidaten-Policy, veränderte diese nachbarschaftsspezifischen Exporte, blieb innerhalb eines festgelegten Beziehungskorridors und führte zu keinen unerwarteten externen Ankündigungen.“

Beziehungspolitik statt bloßer Präfixgültigkeit

Cloudflare beschrieb unter anderem von Meta AS32934 über eine Peer-Beziehung gelernte IPv6-Routen, die Cloudflare AS13335 in Richtung des Transitproviders AS3356 ankündigte. Das veröffentlichte Beispiel betrifft 2a03:2880:f077::/48 und enthält den Pfad 64112 22850 174 3356 13335 32934.

Die AS-Folge ist ein öffentlich beobachtbares Signal, aber kein vollständiges Vertragsregister. Aus einem AS-Pfad allein lassen sich nicht alle privaten kommerziellen Bedingungen, Sondervereinbarungen oder internen Topologiedetails beweisen. Die von Cloudflare selbst beschriebene Peer-zu-Provider-Weitergabe liefert jedoch den für die Analyse maßgeblichen Beziehungsrahmen.

Exportkontrolle muss vier Herkunftsklassen voneinander trennen. Von Kunden gelernte Routen dürfen häufig an Peers und Provider weitergegeben werden, weil der Betreiber für seine Kunden Erreichbarkeit bereitstellt. Von einem Peer gelernte Routen sollen normalerweise nicht an einen anderen Peer oder einen Provider exportiert werden. Von einem Provider gelernte Routen sollen typischerweise nicht an andere Provider oder Peers weitergegeben werden. Eigenständig originierte Routen benötigen wiederum einen eindeutigen internen Herkunfts- und Autorisierungsnachweis.

Diese Regeln dürfen nicht nur implizit aus Präfixlisten hervorgehen. Eine Route kann ein bekanntes Präfix und einen autorisierten Ursprung besitzen und dennoch über eine unzulässige Beziehung weitergegeben werden. Deshalb braucht jeder Export mindestens zwei voneinander unabhängige Fragen: Ist diese Route hinsichtlich Präfix und Ursprung zulässig? Und ist ihre Weitergabe von dieser Herkunftsbeziehung an genau diese Zielbeziehung zulässig?

Lokale Communities können diese Herkunft markieren. Sie sind nützlich, wenn ihre Bedeutung eindeutig, ihre Setzung vertrauenswürdig und ihre Erhaltung kontrolliert ist. Sie sind jedoch kein universeller Beweis. Eine Community kann fehlen, falsch gesetzt, beim Import nicht bereinigt oder auf einem unerwarteten Pfad verändert worden sein. Eine sichere Exportpolicy sollte deshalb nicht allein auf ein einzelnes Metadatenelement vertrauen, wenn zusätzliche Nachbar-, Präfix- oder Rollenkontrollen möglich sind.

Cloudflare ordnete den Vorfall einer Mischung aus Type 3 und Type 4 nach RFC 7908 zu. Vereinfacht betreffen diese Kategorien die unzulässige Weitergabe von Routen zwischen verschiedenen Beziehungsklassen, darunter Provider- beziehungsweise Peerpfade. Die genaue Klassifizierung stammt von Cloudflare. Sie unterstreicht, dass nicht der Ursprung der Route, sondern die unzulässige Weiterverbreitung zwischen Beziehungen das Kernproblem war.

Warum ein Ein-Router-Canary vor der Aussendung prüfen muss

Die Ausführung auf zunächst einem Router zeigt, dass eine kleine Gerätemenge allein nicht genügt. Ein Router am Rand eines großen Netzes kann externe BGP-Sichtbarkeit und Verkehrspfade beeinflussen. Ein Canary muss daher nicht nur beobachten, ob das Gerät erreichbar bleibt, die Konfiguration annimmt oder BGP-Sitzungen bestehen bleiben.

Vor der Emission sollte der Canary die vollständige Differenz der Routenmengen berechnen. Dazu gehört die Zahl neu exportierbarer Präfixe, die Verteilung nach Adressfamilie, Herkunftsklasse, Ursprung, Nachbarschaftsrolle und Policy-Term. Jede Ausweitung braucht eine erklärte Erwartung.

Noch wichtiger ist der Vergleich des Adj-RIB-Out pro Nachbar. Eine globale Aussage wie „Die Anzahl der BGP-Routen änderte sich nur geringfügig“ kann eine entscheidende relationale Abweichung verdecken. Schon eine einzelne Peer-Route, die erstmals einem Provider angeboten wird, verletzt die erwartete Beziehungspolitik, auch wenn die Gesamtzahl der Routen im Router nahezu gleich bleibt.

Der automatische Abbruch darf deshalb nicht erst bei einer hohen Routenzahl oder ungewöhnlichem Verkehrsvolumen reagieren. Beziehungskontrollen müssen qualitativ fail-closed arbeiten. Wenn eine Peer- oder Providerroute in einem nicht erlaubten Adj-RIB-Out erscheint, sollte die Ausspielung vor der externen Aussendung stoppen. Wo eine vollständige Vorabemulation technisch nicht möglich ist, kann eine abgeschirmte Sitzung, eine nicht weiterverteilende Testumgebung oder ein strikt begrenzter Exportpfad als zusätzliche Barriere dienen.

Ein sinnvoller Canary-Korridor enthält mindestens eine erwartete Obergrenze für neue und entfernte Präfixe, erlaubte Ursprungsklassen, erlaubte Herkunfts- und Zielbeziehungen, erlaubte Communities, erwartete AS-Pfadmerkmale sowie einen festen Zeitraum für die Beobachtung. Die Entscheidung über eine weitere Ausrollung sollte erst fallen, wenn interne Zustände und externe Sichtbarkeit zusammenpassen.

Verkehrstelemetrie bleibt dabei ein nachgelagerter Schutz. Sie kann Überlastung, Latenz oder Verwerfungen erkennen, doch dann ist eine unerwünschte Ankündigung möglicherweise bereits wirksam. Ein routingsemantischer Canary muss früher ansetzen: an der Frage, was das Netz gleich exportieren wird.

RPKI prüft den Ursprung, nicht automatisch die Beziehung

RPKI und Route Origin Validation beantworten eine engere Frage: Ist ein bestimmtes autonomes System nach den veröffentlichten Route Origin Authorizations berechtigt, ein Präfix zu originieren? Die einschlägigen RFCs beschreiben die Infrastruktur, die Validierung und die betriebliche Behandlung solcher Ursprungsinformationen.

Im beschriebenen Vorfall blieben die Meta-Routen nach Cloudflares Darstellung mit AS32934 als Ursprung sichtbar. Eine Route kann daher hinsichtlich ihres Ursprungs gültig sein und dennoch auf einem nicht vorgesehenen Peer-zu-Provider-Pfad zirkulieren. RPKI-Origin-Validierung allein würde eine solche Route nicht zwangsläufig als ungültig kennzeichnen.

Das ist kein Versagen von RPKI, sondern eine Grenze seines Anwendungsbereichs. Ursprungsauthentisierung und Beziehungspolitik lösen unterschiedliche Probleme. Eine ROA kann bestätigen, dass AS32934 ein Präfix originieren darf. Sie erklärt nicht automatisch, ob AS13335 dieses Präfix, nachdem es von einem Peer gelernt wurde, an AS3356 weitergeben durfte.

RFC 9234 adressiert Beziehungseigenschaften direkter. BGP Roles ermöglichen es Nachbarn, ihre Rollen für eine Sitzung auszuhandeln. Das Only-to-Customer-Attribut, OTC, kann Informationen über die erlaubte Weitergabe transportieren und bestimmte Leaks erkennen oder verhindern helfen. Diese Mechanismen schaffen eine zusätzliche, von einer lokalen Präfixliste getrennte Kontrollschicht.

Ihre Erwähnung darf jedoch nicht mit einem Nachweis tatsächlicher Nutzung verwechselt werden. Cloudflare erklärte, die Unterstützung entsprechender Mechanismen durch Anbieter prüfen zu wollen. Das ist eine angekündigte Richtung, kein Beweis für eine spätere vollständige Bereitstellung oder Wirksamkeit.

Dasselbe gilt für vertrauenswürdige Communities und zusätzliche Filter. Cloudflare nannte Community-basierte Schutzmaßnahmen, Prüfungen auf leere oder fehlerhafte Policy-Terme in CI/CD und verbesserte Früherkennung als Abhilferichtungen. Diese Maßnahmen sind fachlich geeignet, verschiedene Fehlerklassen zu begrenzen. Aus der Ankündigung allein folgt aber nicht, wann, wo und mit welcher Abdeckung sie umgesetzt wurden.

MANRS beschreibt operative Filterpraktiken und die Verantwortung, fehlerhafte Ankündigungen zu verhindern. Das Material kann einen Maßstab für gute Praxis liefern, ist aber keine private Prüfung der Cloudflare-Infrastruktur.

ASPA zielt auf die Validierung von Providerbeziehungen und damit auf einen weiteren Teil der Pfadsemantik. Die herangezogene ASPA-Arbeit befindet sich in Entwicklung. Sie darf weder als flächendeckend eingesetzter Standard noch als nachgewiesene Kontrolle dieses Vorfalls dargestellt werden. RPKI-Origin-Validierung, BGP Roles und OTC, Communities, externe Filter und ASPA ergänzen sich; keiner dieser Ansätze darf pauschal als Ersatz für die anderen behandelt werden.

Öffentliche Sammlerdaten: Starker Sichtbarkeitsbeleg, begrenzte Kausalität

Die eingefrorene RIPEstat-BGPlay-Abfrage betrachtete das Präfix 2a03:2880:f077::/48 im Zeitraum von 20:24 bis 20:52 UTC. Sie lieferte den Status ok und 1.548 Ereignisse. In 1.440 dieser Ereignisse enthielt der Pfad sowohl AS13335 als auch AS32934.

Diese Zahlen sind ein unabhängiger Beleg dafür, dass die betreffende AS-Kombination während des begrenzten Zeitfensters in öffentlichen Routingdaten sichtbar war. Der Abfragebeginn liegt eine Minute vor Cloudflares angegebenem Auswirkungsbeginn; das Ende liegt zwei Minuten nach der gemeldeten manuellen Eindämmung. Damit erfasst das Fenster den zentralen Zeitraum, ohne daraus allein jede einzelne Ursache oder Wirkung ableiten zu können.

Route Collectors empfangen BGP-Sichten von ihren jeweiligen Peers. Ihre Beobachtungen hängen von Standort, Peering, Auswahlpfaden und Erfassungsbedingungen ab. Sie bilden weder jeden Internetpfad noch jede interne Route ab. Die 1.548 Ereignisse sind deshalb keine Zahl betroffener Präfixe, Kunden, Pakete oder Router. Auch die 1.440 Ereignisse mit beiden AS-Nummern sind keine Messung des Verkehrsvolumens.

Die Daten beweisen ferner nicht, welcher konkrete Policy-Term auf einem privaten Router aktiv war. Sie können nicht feststellen, ob ein Generator eine Bedingung entfernte, wann ein Operator eine Datei betrachtete oder welche internen Alarmgrenzen bestanden. Für diese Aussagen bleibt Cloudflares Incident-Bericht die zugeordnete Quelle.

Ebenso wenig beweisen die Sammlerdaten die von Cloudflare berichtete Überlastung zwischen Miami und Atlanta, die erhöhten Verluste, höhere Latenz oder das verworfene Spitzenvolumen von etwa 12 Gbit/s. Öffentliche BGP-Daten und interne Verkehrsmetriken sind verschiedene Beweisebenen.

Ihre Stärke liegt in einer anderen Funktion: Sie können zeigen, dass eine interne Exportentscheidung das autonome System verlassen hat und von außen beobachtet wurde. Damit sind sie für Freigabe und Wiederherstellung wertvoll. Ein Betreiber kann erwartete interne Exporte mit externen Beobachtungen vergleichen und nach einem Rollback prüfen, ob die unerwünschten Pfade tatsächlich zurückgenommen wurden.

RFC 8212 und die Grenze der bloßen Policy-Existenz

RFC 8212 stärkt das Prinzip, dass externe BGP-Verbreitung nicht ohne ausdrücklich konfigurierte Import- und Exportrichtlinien stattfinden soll. Dieses fail-closed Grundmodell ist für Verantwortlichkeit wichtig: Eine Sitzung soll nicht allein durch ihr Bestehen unbeschränkt Routen austauschen.

Der Cloudflare-Fall macht jedoch eine zweite Ebene sichtbar. Die Existenz einer Exportrichtlinie beweist nicht ihre semantische Richtigkeit. Eine Policy kann vorhanden, syntaktisch gültig und dennoch zu weit sein. Das System braucht daher sowohl eine Anforderung an die Existenz als auch eine Prüfung der tatsächlich erlaubten Routenmengen.

RFC 4271 liefert die Grundlage für BGP-Entscheidungen und die verschiedenen Routinginformationszustände. Für die operative Kontrolle folgt daraus, dass eine Route in der lokalen BGP-Sicht nicht automatisch einer Exportberechtigung entspricht. Erst die nachbarschaftsspezifische Policy entscheidet, was angeboten wird.

RFC 7454 beschreibt betriebliche Sicherheitspraktiken, einschließlich Filterung. RFC 7908 liefert die Terminologie für Routenlecks. RFC 9234 ergänzt Rollen- und OTC-Mechanismen. Gemeinsam definieren diese Texte technische Modelle und Kontrollmöglichkeiten. Sie können aber nicht beweisen, welche privaten Funktionen Cloudflare am 22. Januar 2026 einsetzte oder später implementierte.

Wiederherstellung muss Router und Quelle korrigieren

Die manuelle Rücknahme auf dem Miami-Router war der schnellste Weg, die akute Auswirkung einzugrenzen. Sie genügte jedoch nicht als dauerhafte Wiederherstellung. Solange die erzeugende Quelle die problematische Änderung enthielt und die Automatisierung später wieder anlaufen sollte, bestand ein Risiko der erneuten Erzeugung oder Ausspielung.

Ein vollständiger Rollback muss daher zwei Zustände korrigieren. Erstens den laufenden Routerzustand: Die unerwünschte Policy muss entfernt oder durch die vorherige sichere Version ersetzt werden. Zweitens den Quellzustand: Repository, Generatorparameter und abhängige Artefakte müssen wieder eine sichere Konfiguration erzeugen.

Während diese Zustände auseinanderliegen, sollte die Automatisierung pausiert bleiben. Andernfalls kann ein automatischer Lauf den manuellen Fix überschreiben. Die Pause ist keine bloße administrative Handlung, sondern eine technische Barriere gegen Zustandsdrift.

Vor der Wiederfreigabe sollte der Betreiber die neu gerenderte Konfiguration mit dem erwarteten Quellzustand verbinden, die Route-Set- und Adj-RIB-Out-Differenzen erneut prüfen und sicherstellen, dass keine verbotene Beziehungsweitergabe mehr möglich ist. Danach müssen die Rücknahmen auch außerhalb des eigenen Netzes sichtbar werden. Externe Sammler sind dafür kein perfektes Vollbild, aber ein wichtiges unabhängiges Signal.

Die Freigabe der Automatisierung braucht eine benannte Eigentümerschaft. Es muss klar sein, wer bestätigt, dass der Routerzustand korrigiert ist, wer den Quellfix verantwortet, wer die externe Rücknahme prüft und wer die Wiederaufnahme genehmigt. Der öffentliche Bericht benennt nicht sämtliche individuellen Entscheidungsträger; daraus dürfen keine Spekulationen über interne Verantwortungsverteilung oder Schuld abgeleitet werden.

Ein praktischer Verantwortlichkeitsmaßstab für Routing-Automatisierung

Der Kernmaßstab ist nicht, ob Automatisierung eingesetzt wurde. Automatisierung kann Konsistenz verbessern, manuelle Fehler reduzieren und große Netze beherrschbar machen. Die relevante Frage lautet, ob das System beweisen kann, dass eine scheinbar verengende Bereinigung keine Exportbefugnis ausweitet.

Vor einer Freigabe sollte jede Änderung eine eindeutig formulierte Absicht besitzen. Eine Aussage wie „veraltete Präfixlistenreferenzen entfernen“ muss mit erwarteten semantischen Folgen verbunden sein: keine zusätzlichen exportierten Präfixe, keine neue Herkunftsklasse und keine Änderung der Peer-, Provider- oder Kundenbeziehungen.

Der Generator sollte anschließend die vollständige Kandidaten-Policy erzeugen und sicherheitsrelevante Terme markieren. Verliert ein akzeptierender Term seine letzte enge Präfix-, Community- oder Beziehungsbedingung, muss die Prüfung fehlschlagen. Gleiches gilt, wenn die verbleibenden Bedingungen eine größere Route-Set-Auswahl ermöglichen als der freigegebene Korridor.

Danach muss eine Routensimulation oder ein äquivalenter Preflight die Match-Menge jedes geänderten Terms bestimmen. Die Ausgabe sollte nicht nur eine Anzahl enthalten, sondern Ursprung, Herkunftsnachbar, Beziehungsklasse, Adressfamilie und vorgesehenen Exportnachbarn.

Der nächste Schritt ist die nachbarschaftsspezifische Adj-RIB-Out-Differenz. Jede neue Route muss auf eine konkrete Erlaubnis zurückgeführt werden können. „Das Präfix ist gültig“ reicht nicht. Die Weitergabe muss auch für die Kombination aus gelernter und exportierter Beziehung zulässig sein.

Ein Ein-Router-Canary muss mit automatischen Abbruchbedingungen beginnen. Eine unerwartete Peer-zu-Provider-, Provider-zu-Peer- oder Peer-zu-Peer-Weitergabe sollte unabhängig von der Gesamtzahl der Präfixe zum Stopp führen. Volumen-, Latenz- oder Verlustschwellen dienen als zusätzliche Sicherung, nicht als erste Verteidigungslinie.

Nach der kontrollierten Aktivierung sollten interne BGP-Updates, RIB/FIB-Zustände, Verkehrsmetriken und externe Sammlerdaten zeitlich korreliert werden. Differenzen zwischen erwarteter und beobachteter Sicht müssen die Ausrollung anhalten.

Schließlich muss der Rollback denselben Beweisstandard erfüllen wie die Einführung. Es reicht nicht, eine alte Konfiguration einzuspielen. Der Betreiber muss nachweisen, dass die Quelländerung rückgängig gemacht, die Automation kontrolliert pausiert, die unerwünschten Ankündigungen zurückgenommen und die externen Pfade bereinigt wurden.