Zusammenfassung

  • Cloudflare berichtete über zwei voneinander unabhängige Routingereignisse am 27. Juni 2024. AS267613 kündigte ab 18:51 UTC das Präfix 1.1.1.1/32 an; AS262504 leakte ab 18:52 UTC das Präfix 1.1.1.0/24 über AS1031.
  • Die /32-Ursprungsankündigung und das /24-Route-Leak dürfen weder technisch noch bei der Verantwortungszuordnung zusammengeführt werden. Sie durchliefen unterschiedliche Prüfgrenzen und konnten unterschiedliche Gegenmaßnahmen erfordern.
  • Cloudflare zufolge akzeptierte ein nicht namentlich genanntes Tier-One-Netz die /32-Route als remotely triggered blackhole route. Diese Aussage erlaubt keine Rekonstruktion der privaten Filter- oder Community-Konfiguration dieses Netzes.
  • Beim /24-Leak blieb Cloudflares AS13335 der richtige Ursprung. Eine RPKI-Origin-Validierung konnte deshalb einen zulässigen Ursprung erkennen, obwohl die Weitergabe über den beobachteten AS-Pfad nicht autorisiert war.
  • RPKI und ROAs beantworten vor allem die Frage, welches AS ein Präfix originieren darf und welche maximale Präfixlänge gedeckt ist. Sie bestätigen nicht sämtliche Beziehungen zwischen den AS-Nummern eines vollständigen Pfades.
  • Cloudflare eröffnete nach eigener Darstellung um 20:03 UTC einen Vorfall und verzeichnete die vollständige Behebung des /24-Leaks am 28. Juni um 02:28 UTC.
  • Die berichteten Auswirkungen bestanden in fehlender Erreichbarkeit von 1.1.1.1 oder erhöhter Latenz für einen Teil der Nutzer. Die verfügbaren Belege tragen nicht die Aussage eines weltweiten DNS-Ausfalls.
  • APNIC bewertete das Ereignis als nicht global sichtbar und im Verhältnis zur gesamten Internetnutzerschaft wahrscheinlich marginal. Internet Society Pulse verwendete eine weiter gefasste Sprache für Beobachtungen in Netzen und Ländern. Beide Aussagen müssen ihrer jeweiligen Quelle zugeordnet bleiben.
  • RouteViews und RIPE RIS bewahren Beobachtungen über sichtbare Routen und ihre Verbreitung. Sie autorisieren keine Route, konfigurieren keine Filter und beweisen nicht jeden tatsächlichen Weiterleitungsweg.
  • Verantwortung folgt der praktisch ausgeübten Kontrolle: über Origination, Kundenexporte, Providerannahme, Route-Server- oder Transitverbreitung, Blackhole-Autorisierung, Überwachung, Eindämmung und verifizierten Rückzug.

Zwei Routingereignisse statt einer vereinfachten Ausfallerzählung

Die Adresse 1.1.1.1 ist weithin als Zugangspunkt zu Cloudflares öffentlichem DNS-Resolver bekannt. Gerade diese Bekanntheit verführt dazu, eine Störung vorschnell als ein einziges, globales DNS-Ereignis zu erzählen. Die technische Evidenz verlangt jedoch eine engere und präzisere Darstellung. Am 27. Juni 2024 traten zwei verschiedene BGP-Ereignisse auf, die denselben Adressraum berührten, aber nicht denselben Ursprung, dieselbe Präfixlänge oder denselben Kontrollpfad hatten.

Cloudflare schrieb, AS267613 habe um 18:51 UTC begonnen, 1.1.1.1/32 zu originieren. Das war eine besonders spezifische Route zu genau einer IPv4-Adresse. Nach Cloudflares Darstellung war diese Ankündigung RPKI-invalid und für die normale globale Weiterleitung keine zulässige Ankündigung. Dass ein solches Präfix dennoch in einem bestimmten betrieblichen Kontext akzeptiert werden kann, hängt mit Blackhole-Verfahren zusammen: Manche Netze gestatten sehr spezifische Routen, wenn eine vereinbarte Community oder ein vergleichbares Signal sie ausdrücklich als Anweisung zum Verwerfen von Verkehr kennzeichnet.

Nur eine Minute später, um 18:52 UTC, begann laut Cloudflare ein zweites Ereignis. AS262504 leakte 1.1.1.0/24 über AS1031. Dieser Vorgang betraf nicht nur die einzelne Hostadresse als /32, sondern das gesamte /24-Präfix. Außerdem war die zentrale Validierungsfrage eine andere: Der beobachtete Ursprung blieb Cloudflares AS13335. Der Fehler lag demnach nicht in einem falschen Origin-AS, sondern in der nicht autorisierten Weitergabe des Pfades.

Diese Unterscheidung ist keine sprachliche Feinheit. Sie bestimmt, welche Schutzmaßnahmen überhaupt greifen können. Eine Origin-Validierung kann einen ungültigen Ursprung oder eine nicht gedeckte Präfixlänge erkennen. Sie kann jedoch nicht allein entscheiden, ob ein autorisiertes Origin-AS über eine bestimmte Folge von Kunden-, Provider-, Peer-, Route-Server- oder Transitbeziehungen verbreitet werden durfte. Wer beide Ereignisse unter dem allgemeinen Etikett „BGP-Hijacking“ zusammenfasst, verdeckt genau jene unterschiedlichen Kontrollflächen, die für die Verantwortungsfrage entscheidend sind.

Es gibt in den eingefrorenen Fakten keinen Nachweis für böswillige Absicht. Ebenso wenig beweisen sie Fahrlässigkeit, Rechtswidrigkeit, Verschleierung oder eine bestimmte rechtliche Haftung. Die belastbare Frage lautet deshalb nicht, welches Motiv einer beteiligten Stelle unterstellt werden könnte. Sie lautet, welche Stelle an welchem Übergang die tatsächliche Möglichkeit hatte, eine Ankündigung zu verhindern, zurückzuweisen, einzugrenzen, zu erkennen oder zurückzuziehen.

Chronologie und belastbare Zeitgrenzen

Zeitpunkt Belegbare Entwicklung Erforderliche Einordnung
27. Juni 2024, 18:51 UTC Cloudflare zufolge begann AS267613 mit der Ankündigung von 1.1.1.1/32. Eigenständiges /32-Origin-Ereignis; nicht mit dem späteren /24-Leak vermischen.
27. Juni 2024, 18:52 UTC Cloudflare zufolge leakte AS262504 1.1.1.0/24 über AS1031. Eigenständiges Pfad- und Exportproblem mit AS13335 als richtigem Ursprung.
27. Juni 2024, 20:03 UTC Cloudflare eröffnete nach eigener Darstellung einen Incident. Beginn der formal berichteten Reaktion, nicht zwingend Beginn aller internen Beobachtungen.
28. Juni 2024, 02:28 UTC Cloudflare verzeichnete die vollständige Behebung des /24-Leaks. Bezieht sich ausdrücklich auf die Auflösung des /24-Leaks und darf nicht pauschal auf jeden Aspekt des /32-Ereignisses übertragen werden.

Die Zeitangaben stammen aus Cloudflares Darstellung. Sie sind wichtig, weil sie eine betriebliche Reaktionskette messbar machen: erste berichtete Ankündigung, zweite berichtete Ankündigung, formale Vorfalleröffnung und bestätigte Behebung des /24-Leaks. Gleichzeitig setzen sie der Interpretation Grenzen. Aus der Zeitspanne zwischen 18:51 UTC und 20:03 UTC lässt sich ohne zusätzliche interne Evidenz weder ableiten, wann welches Team erstmals ein Signal sah, noch weshalb eine bestimmte Eskalation zu einem bestimmten Zeitpunkt erfolgte.

Auch die Auflösung um 02:28 UTC darf nicht überdehnt werden. Cloudflare ordnete diesen Zeitpunkt der vollständigen Behebung des Route Leaks zu. Daraus folgt nicht automatisch, dass jede zuvor beobachtete Weiterleitungsentscheidung in jedem Netz exakt zur selben Sekunde verschwunden war. BGP-Zustand wird dezentral verarbeitet. Router können Aktualisierungen zu unterschiedlichen Zeiten empfangen und auswählen; Monitoringpunkte erfassen nur ihre jeweilige Sicht.

Eine belastbare Wiederherstellungsaussage benötigt deshalb mehrere Belegarten: den Rückzug beziehungsweise die Korrektur der Route, die Stabilisierung der beobachteten Pfade, wiederhergestellte Dienstmessungen und eine ausreichend breite Kontrolle gegen verbliebene Fehlanzeigen.

Warum die /32-Ankündigung technisch außergewöhnlich war

BGP verteilt Erreichbarkeitsinformationen zwischen autonomen Systemen. Ein Router betrachtet dabei nicht einfach eine globale Wahrheit, sondern die Routen, die ihm seine Nachbarn anbieten, seine lokalen Richtlinien und die daraus ausgewählte beste Route. Für die tatsächliche Weiterleitung gilt grundsätzlich die längste passende Präfixübereinstimmung. Eine Route zu 1.1.1.1/32 ist spezifischer als eine Route zu 1.1.1.0/24. Wenn beide in einer Weiterleitungstabelle installiert sind, kann der /32-Eintrag den Verkehr zur einzelnen Adresse 1.1.1.1 von der breiteren /24-Route abziehen.

In der üblichen globalen IPv4-Routingpraxis werden Präfixe spezifischer als /24 häufig verworfen oder nicht allgemein weiterverbreitet. Das ist jedoch keine universelle physikalische Schranke. Betreiber können Ausnahmen definieren, insbesondere für kontrollierte DDoS-Abwehr. Bei RTBH kündigt eine autorisierte Stelle ein eng gefasstes Präfix zusammen mit einem vereinbarten Blackhole-Signal an. Das empfangende Netz richtet den betreffenden Verkehr dann auf eine Verwerfungsschnittstelle oder einen funktional gleichwertigen Nullpfad.

Der Zweck ist defensiv: schädlichen oder überlastenden Verkehr möglichst nahe an seinem Eintrittspunkt zu stoppen, bevor er eine Verbindung oder Zielinfrastruktur überwältigt.

Cloudflare berichtete, ein nicht benanntes Tier-One-Netz habe die von AS267613 ausgehende /32-Ankündigung als RTBH akzeptiert. Dadurch wurde Verkehr, der dieser Entscheidung folgte, verworfen. Die belastbare Aussage endet dort. Die öffentlichen Fakten identifizieren das Tier-One-Netz nicht. Sie zeigen weder dessen vollständige Community-Konfiguration noch alle Kundenbeziehungen, Importfilter, internen Schutzmechanismen oder Entscheidungsgründe. Eine vermeintliche Rekonstruktion dieser privaten Umsetzung wäre Spekulation.

Das Problem ist daher nicht, dass RTBH grundsätzlich illegitim wäre. Ohne RTBH müssten Betreiber bei Angriffen möglicherweise langsamere oder gröbere Eingriffe nutzen. Der kritische Punkt ist die Autorisierung einer destruktiven Anweisung. Wer darf für welches Präfix eine Blackhole-Route senden? Muss das Präfix dem Kunden gehören oder von ihm nachweisbar betrieben werden? Welche Präfixlängen werden akzeptiert? Darf das Signal nur innerhalb eines Netzes wirken oder an weitere Nachbarn exportiert werden? Welche Communities sind erlaubt? Wie wird der Auftrag protokolliert?

Wer darf ihn zurücknehmen, und wie wird der tatsächliche Rückzug bestätigt?

Eine sichere RTBH-Regel muss diese Fragen als zusammenhängende Kontrollkette behandeln. Eine Community allein ist kein ausreichender Eigentums- oder Autorisierungsnachweis. Ebenso wenig genügt eine passende Kundenbeziehung, wenn der Kunde für das angeforderte Präfix keine Berechtigung besitzt. Besonders riskant wäre eine Regel, die sehr spezifische Blackhole-Routen von einem Nachbarn annimmt, ohne Kundenpräfix, Präfixlänge, Richtung und Geltungsbereich gemeinsam zu prüfen. Da die Wirkung beabsichtigt destruktiv ist, müssen die Annahmebedingungen enger sein als bei einer gewöhnlichen Route.

Warum das /24-Leak eine andere Prüfgrenze offenlegte

Beim /24-Ereignis bestand die Schwierigkeit gerade darin, dass der Ursprung nach Cloudflares Darstellung weiterhin korrekt war. AS13335 blieb am Ende des AS-Pfades das Origin-AS für 1.1.1.0/24. Eine ROA kann belegen, dass dieses AS das Präfix bis zu einer bestimmten Länge originieren darf. Eine RPKI-Origin-Validierung kann die empfangene Route dementsprechend als „valid“ einstufen, sofern Präfix, Ursprung und erlaubte Maximallänge übereinstimmen.

„Origin-valid“ bedeutet aber nicht „vollständig autorisierter Pfad“. Die Validierung beantwortet nicht, ob AS262504 die Route an AS1031 exportieren durfte, ob AS1031 sie in der beobachteten Richtung akzeptieren und weitergeben sollte oder ob spätere Netze die wirtschaftlichen und betrieblichen Beziehungen des Pfades korrekt interpretierten. Sie signiert keine vollständige Kette zwischen allen autonomen Systemen. Wer RPKI als Beweis für die Autorisierung jedes Zwischenverhältnisses beschreibt, überschätzt die Reichweite des Verfahrens.

Ein Route Leak entsteht typischerweise dort, wo eine Route über eine Beziehung oder in eine Richtung weitergegeben wird, für die sie nicht bestimmt war. Die RFC-Klassifikation liefert dafür Protokoll- und Betriebskontext. Die entscheidende praktische Frage bleibt jedoch lokal: Welche Exportregel hätte die Weitergabe am ausgehenden Rand verhindern müssen, und welche Importregel hätte sie am nächsten Rand zurückweisen können?

Eine Kundenroute, die an einen Provider gesendet werden darf, ist nicht automatisch eine Route, die aus jeder anderen Beziehung übernommen und an alle weiteren Nachbarn verbreitet werden sollte. Provider, Kunden und Peers haben unterschiedliche Erwartungen darüber, welche Erreichbarkeit sie austauschen. Route Server an Internetknoten erleichtern den multilateralen Austausch, entfernen aber nicht die Verantwortung für saubere Import- und Exportrichtlinien. Transitnetze können eine fehlerhafte Route weiter tragen oder sie an einer korrekt konfigurierten Grenze stoppen.

RFC 7454 beschreibt bewährte BGP-Sicherheitspraktiken, RFC 8212 unterstreicht die Bedeutung expliziter Import- und Exportrichtlinien, und RFC 9234 führt BGP-Rollen sowie das Only-to-Customer-Attribut als Mittel gegen bestimmte Leak-Klassen ein. Diese Standards definieren verfügbare Schutzmechanismen und sinnvolle Voreinstellungen. Sie beweisen nicht, dass ein bestimmtes beteiligtes Netz die jeweilige Maßnahme am 27. Juni 2024 eingerichtet, korrekt angewendet oder rechtzeitig aktualisiert hatte.

Die /24-Route macht deshalb sichtbar, warum mehrere Schutzschichten erforderlich sind. Origin-Validierung prüft den Ursprung. Präfix- und Kundenfilter prüfen, was ein bestimmter Nachbar ankündigen darf. Beziehungsbewusste Regeln prüfen, in welche Richtung eine Route exportiert werden darf. BGP-Rollen und OTC-Signale können zusätzliche Informationen über zulässige Weitergabe liefern. Monitoring erkennt, wenn die resultierende Sicht trotzdem von der erwarteten Topologie abweicht. Keine einzelne Schicht ersetzt alle anderen.

Register, ROAs und laufende Routerkonfiguration

Die Zuteilung und Registrierung von Nummernressourcen schafft einen unverzichtbaren Nachweisrahmen. Präfixinhaber, Ursprungsberechtigungen und zugehörige Sicherheitsmetadaten geben Netzen eine Grundlage, um Richtlinien zu bauen und Vorfälle nachträglich zu untersuchen. Im Fall von 1.1.1.0/24 helfen die APNIC-Unterlagen und die RPKI-Daten dabei, die erwartete Ressourcenzuordnung sowie die zulässige Origination einzuordnen.

Diese Belege handeln jedoch nicht selbst. Ein Registereintrag meldet sich nicht an einem Router an. Eine ROA installiert keinen Importfilter. Ein korrekter Datensatz zwingt kein Transitnetz, RPKI-invalid Routen zu verwerfen. Ebenso erkennt ein Register nicht automatisch, dass ein origin-valider Pfad über eine unerwartete Beziehung weitergegeben wurde.

Die Trennung zwischen Beleg und laufender Kontrolle ist für die Verantwortung zentral. Die für Ressourcen zuständige Stelle muss Datensätze korrekt, aktuell und sicher pflegen. Der Präfixinhaber muss eine passende ROA erstellen und deren Maximallänge sorgfältig wählen. Ein Netzbetreiber muss die Validierungsdaten zuverlässig beziehen, Fehlerzustände handhaben und eine durchsetzbare Richtlinie festlegen. Kunden- und Peerfilter benötigen konkrete Präfix- und AS-Zuordnungen. Änderungen an diesen Listen müssen rechtzeitig und nachvollziehbar erfolgen.

Daraus folgt eine doppelte Verantwortung. Schlechte oder veraltete Registerdaten schwächen die Basis betrieblicher Entscheidungen. Korrekte Registerdaten entschuldigen aber keine fehlenden Filter. Umgekehrt können hervorragende Filter einen falschen Ressourcendatensatz nicht zuverlässig kompensieren. Belastbarkeit entsteht nur, wenn Dokumentation und laufende Konfiguration miteinander abgeglichen werden.

Begrenzte Aussagen über die Auswirkungen

Cloudflare berichtete, dass betroffene Nutzer 1.1.1.1 nicht erreichen konnten oder hohe Latenz erlebten. Diese Formulierung beschreibt reale Dienstbeeinträchtigungen, aber keine globale Vollstörung. Sie lässt offen, welcher Anteil der Nutzer betroffen war, wie viele Anfragen verloren gingen, welche Anwendungen auf alternative Resolver auswichen und welche Geografien welche der beiden Routen tatsächlich auswählten.

APNIC schrieb in seiner unabhängigen technischen Analyse, das Ereignis sei nicht global sichtbar gewesen und seine Auswirkungen seien im Verhältnis zur gesamten Internetnutzerschaft wahrscheinlich marginal gewesen. Diese Bewertung muss APNIC zugeschrieben werden. Sie darf weder zu „niemand war betroffen“ abgeschwächt noch zu einer weltweiten Krise ausgeweitet werden.

Internet Society Pulse verwendete eine breitere Beobachtungssprache mit Blick auf Sichtbarkeit über zahlreiche Netze und Länder. Auch diese Reichweitenbeschreibung bleibt eine attribuierte Beobachtung. Sie ist nicht automatisch ein Widerspruch zu APNIC: Routingkollektoren können eine Ankündigung an vielen Punkten sehen, obwohl nur ein begrenzter Teil der Nutzerpfade sie auswählt. Sichtbarkeit einer Route, Auswahl als beste Route, Installation in der Weiterleitungstabelle und tatsächlich messbare Dienstbeeinträchtigung sind vier verschiedene Ebenen.

Die Fakten belegen weder die genaue verlorene Verkehrsmenge noch eine vollständige geografische Karte. Sie nennen keine belastbare Kundenzahl. Sie beweisen auch nicht jeden Propagationspfad oder jedes Weiterleitungsergebnis. Ein AS-Pfad, der an einem Kollektor sichtbar ist, zeigt, dass die Route an diesem Beobachtungspunkt angekommen ist. Er beweist nicht, dass alle Router des betreffenden Netzes dieselbe Entscheidung trafen oder dass jeder Nutzerverkehr über diesen Pfad lief.

Gerade bei einer bekannten Resolveradresse sollte die Wirkung nicht nur mit einem einzigen globalen Prozentsatz beschrieben werden. Eine insgesamt kleine Reichweite kann für einzelne Netze, Regionen oder Anwendungen spürbar sein. Umgekehrt macht eine Sichtbarkeit in vielen Kontrollpunkten aus einer begrenzten Nutzerauswirkung keinen weltweiten Ausfall. Verantwortungsvolle Analyse hält beide Ebenen auseinander.

Beobachtung ist nicht Autorisierung

RouteViews und RIPE RIS sammeln BGP-Informationen aus verschiedenen Perspektiven. Ihre Daten sind für die Rekonstruktion wertvoll, weil sie zeigen können, wann ein Präfix an einem Beobachtungspunkt erschien, welche AS-Pfade dort sichtbar waren und wann ein Rückzug oder eine Pfadänderung ankam. Mehrere Kollektoren helfen, die Reichweite einer Ankündigung besser einzugrenzen und Einzelbeobachtungen zu überprüfen.

Kollektoren sind jedoch keine Routingbehörden. Sie entscheiden nicht, wem ein Präfix gehört. Sie genehmigen keinen Export. Sie setzen keine RPKI-Richtlinie in fremden Routern durch. Sie verhindern kein Route Leak und keine unzulässige Blackhole-Anweisung. Ihre Rolle besteht im Erhalt von Beobachtungen.

Diese Begrenzung betrifft auch die Beweiskraft. Kollektoren sehen die BGP-Sicht ihrer angebundenen Peers, nicht jeden Router und nicht jedes Datenpaket. Fehlende Sichtbarkeit beweist daher nicht sicher, dass eine Route nirgendwo existierte. Sichtbarkeit beweist wiederum nicht, dass sie überall verwendet wurde. Für die Folgenabschätzung müssen Kontrollplane-Daten mit aktiven Erreichbarkeits-, Latenz- und gegebenenfalls DNS-Messungen kombiniert werden.

Die Trennung von Beobachtung und Autorisierung verhindert zwei Fehlzuweisungen. Erstens kann einem Kollektor nicht angelastet werden, eine Route nicht gestoppt zu haben; er besitzt diese Kontrolle nicht. Zweitens darf ein Netzbetreiber das Vorhandensein öffentlicher Kollektordaten nicht als Ersatz für eigenes Monitoring behandeln. Wer eine kritische Adresse betreibt oder Routen für Kunden annimmt, benötigt eine betriebsnahe Sicht auf die eigenen Präfixe, Nachbarn und Richtlinien.

Kontrollflächen entlang der Propagationskette

Die Verantwortungszuordnung beginnt am Punkt der Origination. Das AS, das eine Route erzeugt, kontrolliert die lokale Netzwerkkonfiguration, über die sie entsteht. Dazu gehören zulässige Präfixlisten, Prozesse zur Änderung von BGP-Ankündigungen, Zugriffskontrollen und die Prüfung, ob ein sehr spezifisches Präfix nur für einen eng begrenzten Zweck erzeugt werden darf.

Die nächste Kontrollfläche liegt am Kundenrand. Ein Provider, der von einem Kunden Routen annimmt, kann festlegen, welche Präfixe dieser Kunde ankündigen darf. Bei RTBH muss zusätzlich geprüft werden, ob der Kunde für genau dieses Präfix eine Verwerfung anfordern darf. Präfixlänge, Community, Nachbaridentität, Kundenbeziehung und Geltungsbereich müssen gemeinsam passen.

Für das /24-Leak befindet sich eine zentrale Kontrollfläche beim Export durch AS262504. Dort hätten beziehungs- und richtungsbewusste Regeln die Weitergabe einer Route verhindern können, sofern die betriebliche Beziehung und die erwarteten Routen korrekt abgebildet waren. Eine weitere Kontrollfläche lag bei der Annahme und Weitergabe über AS1031, wie sie Cloudflare berichtete. Die öffentliche Evidenz ermöglicht allerdings keine vollständige Aussage darüber, welche konkrete Konfiguration an welchem Gerät fehlte oder versagte.

Route Server und Transitnetze besitzen ihrerseits praktische Kontrolle über Annahme und Weitergabe. Ein Route Server kann Richtlinien unterstützen und Teilnehmerinformationen verteilen, doch die genaue Sicherheitswirkung hängt von seiner Einrichtung und den Importregeln der Teilnehmer ab. Transitnetze können RPKI-invalid Ursprünge verwerfen, Kundenpräfixe begrenzen, AS-Pfade prüfen und beziehungswidrige Exporte blockieren. Der bloße Status als großer Provider beweist weder eine bestimmte Umsetzung noch deren Fehlen.

Das nicht genannte Tier-One-Netz hatte laut Cloudflares Bericht praktische Kontrolle über die Annahme der /32-Ankündigung als RTBH. Seine Verantwortung wäre auf die konkret kontrollierbaren Fragen begrenzt: War der sendende Nachbar zur Blackhole-Anforderung berechtigt? War das angeforderte Präfix ihm zugeordnet? Entsprach die Länge der Richtlinie? Wurde der Wirkungsbereich begrenzt? Gab es Protokollierung und einen kontrollierten Rückzug? Ohne interne Daten lässt sich nicht beantworten, wie diese Prüfungen tatsächlich gestaltet waren.

Der Präfixinhaber und die RPKI-Betreiber kontrollieren die Qualität der Ursprungsnachweise. Ihre Aufgabe ist es, korrekte Autorisierungsdaten bereitzustellen und Änderungen sicher zu verwalten. Sie kontrollieren dagegen nicht die gesamte Weitergabe nach einem korrekten Ursprung.

Cloudflare kontrolliert schließlich die Überwachung seiner Präfixe und Dienste, die Eskalation zu Peering- und Transitpartnern, die Kommunikation des Vorfalls und die Verifikation der Wiederherstellung. Cloudflare kontrolliert nicht fremde Router. Dennoch kann ein Betreiber einer kritischen öffentlichen Adresse Alarmregeln, Kontakte, vorbereitete Reaktionswege und externe Beobachtungspunkte so organisieren, dass Fehlrouten schneller erkannt und eingegrenzt werden.

Prävention: unterschiedliche Kontrollen für unterschiedliche Fehler

Eine wirksame Präventionsstrategie darf die beiden Ereignisse nicht mit derselben Einzelmaßnahme beantworten. Gegen die /32-Ursprungsankündigung ist eine konsequente Origin-Validierung besonders relevant. Wenn eine Route wegen eines nicht autorisierten Ursprungs oder einer nicht gedeckten Maximallänge RPKI-invalid ist, kann eine entsprechende Importregel ihre normale Annahme verhindern.

Bei Blackhole-Routen genügt das allein jedoch nicht. Manche betriebliche Verfahren behandeln sehr spezifische Präfixe bewusst anders. Deshalb muss die RTBH-Autorisierung unabhängig abgesichert sein. Nur festgelegte Kunden dürfen Blackhole-Signale senden. Das Präfix muss einer genehmigten Kundenliste entsprechen. Die zulässige Länge muss begrenzt sein. Die Community darf nur die vorgesehene lokale oder vertraglich bestimmte Wirkung auslösen. Ein Export an weitere Netze darf nicht zufällig aus einer lokalen Abwehrmaßnahme eine größere Erreichbarkeitsstörung machen.

Für das /24-Leak ist Origin-Validierung notwendig, aber nicht hinreichend. Da AS13335 als richtiger Ursprung erhalten blieb, musste eine zusätzliche Richtlinie die unerlaubte Weitergabe erkennen. Hier greifen explizite Import- und Exportregeln, Kundenpräfixfilter, AS-Pfadfilter, BGP-Rollen und gegebenenfalls OTC-Signale.

RFC 8212 unterstützt das Prinzip, dass ohne ausdrücklich konfigurierte Richtlinie keine Routen zwischen externen BGP-Nachbarn ausgetauscht werden sollten. Dieses „Default Reject“-Prinzip verringert die Gefahr, dass eine neue Sitzung oder unvollständige Konfiguration versehentlich die vollständige Routingtabelle exportiert. Es schützt aber nur, wenn Richtlinien tatsächlich präzise definiert, gepflegt und getestet werden.

RFC 9234 schafft mit Rollen und Only-to-Customer zusätzliche Möglichkeiten, unerwartete Pfade zu erkennen oder zu verhindern. Auch hier bleibt die Wirkung von der realen Einführung auf beiden Seiten einer Beziehung abhängig. Ein Standardtext verändert keinen laufenden Router, solange Betreiber ihn nicht in unterstützte Software, Konfiguration, Tests und Änderungsprozesse überführen.

Prävention benötigt außerdem Änderungsdisziplin. Präfixlisten und Kundenbeziehungen ändern sich. Eine statische Liste kann veralten und dann entweder legitime Routen blockieren oder nicht mehr berechtigte Routen zulassen. Aktualisierungen müssen aus belastbaren Ressourcendaten abgeleitet, vor Aktivierung geprüft, versioniert und nach der Aktivierung beobachtet werden.

Erkennung: vom Alarm zur unterscheidbaren Diagnose

Gutes Monitoring muss nicht nur melden, dass 1.1.1.1 schlechter erreichbar ist. Es muss dabei helfen, zwischen einer /32-Ursprungsanomalie, einem /24-Pfad-Leak, einem Dienstfehler und einem regionalen Transportproblem zu unterscheiden.

Für die /32-Ankündigung sind Alarme auf neue, spezifischere Präfixe entscheidend. Eine Warnung sollte Präfix, Ursprung, RPKI-Status, sichtbare Nachbarn, Communities und erste Beobachtungspunkte enthalten. Ein ungewöhnliches /32-Präfix für eine global bekannte IPv4-Adresse verdient hohe Priorität, insbesondere wenn der Ursprung nicht autorisiert ist.

Für das /24-Leak muss das Monitoring trotz eines gültigen Ursprungs anschlagen können. Nützlich sind unerwartete AS-Pfadfolgen, neue Upstreambeziehungen, Änderungen der Pfadlänge, Sichtbarkeit in ungewöhnlichen Regionen und Abweichungen von bekannten Exportmustern. Ein ausschließlich auf „valid“, „invalid“ und „not found“ basierendes RPKI-Dashboard würde dieses Problem nicht vollständig erfassen.

Dienstseitige Messungen ergänzen die Routingdaten. Erreichbarkeitstests zu 1.1.1.1, Latenz, Paketverlust und DNS-Antwortverhalten aus unabhängigen Netzen zeigen, ob eine sichtbare Routingänderung Nutzerauswirkungen erzeugt. Dabei muss berücksichtigt werden, dass alternative Pfade, Caches und Resolverkonfigurationen die wahrgenommene Wirkung verändern können.

Ein Alarm ist noch keine Diagnose. Die erste Reaktion sollte beide Präfixe getrennt verfolgen. Für 1.1.1.1/32 sind Ursprung, RPKI-Zustand und mögliche Blackhole-Signale zu prüfen. Für 1.1.1.0/24 sind Ursprung und vollständige sichtbare Pfadfolgen zu vergleichen. Werden beide Ereignisse in einem Ticket ohne getrennte Zustände geführt, besteht das Risiko, dass der Rückzug des einen fälschlich als Behebung des anderen gilt.

Eindämmung: Wirkung stoppen, ohne Evidenz zu verlieren

Die schnellste Eindämmungsmaßnahme hängt davon ab, wer tatsächlich handeln kann. Das originierende AS kann eine unzulässige Route zurückziehen. Ein direkt angebundener Provider kann sie am Kundenrand verwerfen. Ein Transitnetz kann Import- oder Exportfilter aktualisieren. Ein Route-Server-Betreiber kann im Rahmen seiner technischen und vertraglichen Möglichkeiten eine problematische Sitzung oder Weitergabe begrenzen. Der Präfixinhaber kann betroffene Partner mit überprüfbaren Ressourcendaten und erwarteten Pfaden versorgen.

Bei einer unzulässigen /32-Blackhole-Wirkung ist der engste sichere Eingriff die Beendigung der fehlerhaften Akzeptanz oder Origination, nicht die pauschale Abschaltung legitimer RTBH-Funktionen. Eine grobe Maßnahme könnte den aktuellen Fehler stoppen, zugleich aber den DDoS-Schutz anderer Kunden beeinträchtigen. Die Korrektur sollte deshalb Präfix, Nachbar, Community und Reichweite möglichst genau adressieren.

Beim /24-Leak kann ein Netz den unerwarteten Pfad zurückweisen, ohne Cloudflares legitime Origination über andere Pfade zu blockieren. Ein Filter, der lediglich das Präfix vollständig sperrt, würde das Schutzproblem in einen neuen Erreichbarkeitsfehler verwandeln. Die notwendige Präzision unterstreicht, weshalb vorbereitete Kunden- und Beziehungsdaten so wichtig sind.

Während der Eindämmung müssen Beobachtungen erhalten bleiben. Relevante BGP-Updates, RPKI-Zustände, Konfigurationsänderungen, Zeitstempel, Kontaktverläufe und Dienstmessungen sollten gesichert werden. Das Ziel ist nicht nur eine spätere Schuldzuweisung. Ohne erhaltene Evidenz lässt sich kaum prüfen, ob der Eingriff die richtige Route traf, ob Nebenwirkungen entstanden oder ob dieselbe Schwäche weiterhin an einer anderen Grenze besteht.

Wiederherstellung und verifizierter Rückzug

Ein BGP-Rückzug ist eine notwendige, aber nicht allein ausreichende Wiederherstellungsbedingung. Zuerst muss bestätigt werden, dass die fehlerhafte Route am Ursprung beziehungsweise an der verantwortlichen Exportgrenze nicht mehr erzeugt wird. Danach ist zu prüfen, ob sie aus relevanten Beobachtungspunkten verschwindet und ob erwartete legitime Pfade wieder ausgewählt werden.

Bei der /32-Ankündigung sollte die Verifikation ausdrücklich nach verbleibender Sichtbarkeit von 1.1.1.1/32 suchen. Eine wieder sichtbare /24-Route beweist nicht, dass der spezifischere Eintrag überall verschwunden ist. Bei dem /24-Leak ist umgekehrt der Pfad zu untersuchen: Die Existenz von 1.1.1.0/24 bleibt normal, wenn er mit einem zulässigen Pfad von AS13335 verbreitet wird. Entscheidend ist das Verschwinden der nicht autorisierten Weitergabe, nicht des legitimen Präfixes.

Anschließend müssen Dienstmessungen die Rückkehr der Erreichbarkeit bestätigen. Dafür sind mehrere externe Perspektiven nötig. Ein erfolgreicher Test aus Cloudflares eigenem Netz beweist nicht, dass externe Netze bereits konvergiert haben. Ein einzelner öffentlicher Messpunkt reicht ebenso wenig.

Cloudflares Zeitpunkt 02:28 UTC am 28. Juni bezeichnet die vollständige Auflösung des /24-Leaks in der eigenen Vorfalldarstellung. Eine solide Abschlussprüfung würde diesen Zeitpunkt mit Kollektorsicht, Partnerbestätigungen und Dienstmessungen abgleichen. Abweichungen wären nicht automatisch ein Widerspruch; sie könnten aus unterschiedlichen Beobachtungsfenstern entstehen. Sie müssten jedoch dokumentiert werden.

Nach der technischen Wiederherstellung folgt die Kontrollkorrektur. Ein einmaliger manueller Rückzug verhindert keine Wiederholung. Die betroffene Stelle muss die Ursache der zulässigen Origination, Annahme oder Weitergabe beseitigen, die geänderte Regel testen und einen erneuten Fehlversuch kontrolliert simulieren. Erst wenn derselbe fehlerhafte Input zuverlässig abgewiesen wird, ist aus einer Reaktion eine dauerhafte Schutzmaßnahme geworden.

Verantwortungsmatrix

Phase Praktische Kontrollstelle Kontrollierbare Handlung Erforderlicher Nachweis
Prävention der /32-Origination AS267613 und sein administrativer Rand Nur autorisierte Präfixe und Zwecke zur Origination zulassen Konfigurationshistorie, Präfixfreigabe, Zugriffs- und Änderungsprotokolle
Annahme der /32-Route Direkter Provider und das von Cloudflare erwähnte, nicht benannte Tier-One-Netz RPKI-Zustand, Kundenpräfix, Präfixlänge, RTBH-Berechtigung und Geltungsbereich prüfen Importregel, Kundenautorisierung, Community-Richtlinie und Entscheidungsprotokoll
Prävention des /24-Leaks AS262504 Beziehungswidrigen Export von 1.1.1.0/24 verhindern Exportregel, Nachbarrolle und Konfigurationsänderungen
Annahme und Weitergabe des /24-Pfades AS1031 sowie nachfolgende Route-Server- oder Transitgrenzen Kunden-, Pfad- und Rollenregeln anwenden Import- und Exportentscheidung je Sitzung
Ursprungsnachweis Präfixinhaber und RPKI-Verantwortliche Korrekte ROA mit passender Ursprungserlaubnis und Maximallänge pflegen Register- und ROA-Historie
Beobachtung Cloudflare, RouteViews, RIPE RIS und andere Messstellen Ankündigungen, Rückzüge, Pfade und Dienstwirkung zeitlich erfassen Rohbeobachtungen mit Zeitstempeln und Perspektive
Eindämmung Originierendes, empfangendes oder propagierendes Netz Fehlerhafte Route präzise zurückziehen oder blockieren Änderungszeitpunkt, betroffene Sitzung und Vorher-nachher-Zustand
Wiederherstellung Cloudflare und beteiligte Netzpartner Legitimen Pfad und Dienstzugang aus mehreren Netzen bestätigen BGP-Sicht, Erreichbarkeit, Latenz und DNS-Messungen
Dauerhafte Korrektur Jede Stelle an der tatsächlich versagenden Grenze Regel so ändern, dass derselbe Input künftig fail-closed behandelt wird Testfall, Freigabe, aktive Regel und erneuter Negativtest

Diese Matrix verteilt Verantwortung nicht nach öffentlicher Sichtbarkeit oder Unternehmensgröße, sondern nach nachweisbarer Kontrolle. Ein Präfixinhaber verantwortet die Qualität seiner Autorisierungsdaten und das Monitoring seines Dienstes, nicht die Konfiguration jedes fremden Routers. Ein Kollektor verantwortet die Integrität seiner Beobachtungen, nicht die Annahmepolitik eines Transitnetzes. Ein Provider verantwortet die Routen, die er gemäß seinen Kunden- und Peerbeziehungen annimmt und weitergibt.

Daraus folgt auch, dass Verantwortung geteilt sein kann, ohne diffus zu werden. Eine unzulässige Route kann an mehreren Grenzen gestoppt werden. Das originierende Netz besitzt die erste Verhinderungsmöglichkeit. Der direkte Provider besitzt eine zweite. Nachfolgende Netze besitzen weitere Annahme- und Exportgrenzen. Der Dienstbetreiber besitzt Erkennungs- und Eskalationskontrollen. Für jede Stelle ist separat zu fragen, welche Information verfügbar war, welche Regel möglich war und ob sie tatsächlich wirkte.

Die öffentliche Evidenz genügt nicht, um jede dieser Fragen für jedes beteiligte Netz abschließend zu beantworten. Sie genügt aber, um die richtigen Belege zu verlangen. Genau darin liegt der Wert einer kontrollorientierten Analyse: Sie ersetzt Spekulation über Motive durch überprüfbare Fragen über Origination, Autorisierung, Annahme, Weitergabe, Beobachtung und Rückzug.