Zusammenfassung

  • Öffentliche Routinganalysen brachten Vodafone Idea AS55410 mit einer sehr großen Menge ungewöhnlicher Routenursprünge am 16. April 2021 in Verbindung.
  • Catchpoint berichtete, dass AS55410 um 13:48:58 GMT als Ursprung von mehr als 34.000 Netzen erschien.
  • Catchpoint beobachtete am RIPE-RIS-Kollektor rrc00 zwischen 13:45 und 15:00 GMT ungefähr 225.000 BGP-Update-Nachrichten; diese Messung ist keine vollständige Sicht auf das gesamte Internet.
  • MANRS bezifferte den normalen Umfang auf 824 Routen und beschrieb mehr als 31.000 zusätzliche Ankündigungen. Diese separat erhobenen Werte dürfen nicht mit der Catchpoint-Zählung verschmolzen werden.
  • Die Verantwortung beginnt bei den Ursprungs- und Exportkontrollen des Quellnetzes, endet dort aber nicht: Upstream-Filterung, Präfixautorisierung, Maximum-Prefix-Grenzen, Origin Validation und kontrollierte Weitergabe bestimmen die mögliche Ausbreitung.
  • RPKI-basierte Origin Validation kann einen ungültigen, durch eine ROA abgedeckten Ursprung ablehnen, validiert jedoch weder den vollständigen AS-Pfad noch nicht abgedeckte Präfixe.
  • RIPE RIS und RouteViews bewahren Beobachtungen ausgewählter Peers auf. Sie autorisieren keine Route und beweisen nicht, dass jedes Netz denselben Pfad ausgewählt hat.
  • Öffentliche Belege zeigen eine erhebliche Routinganomalie, aber weder eine böswillige Absicht noch Fahrlässigkeit, Rechtswidrigkeit, private Routerkonfigurationen oder eine dauerhafte Nachbesserung.
  • Verantwortlichkeit sollte der tatsächlichen Kontrollkette folgen: Ursprung, Export, Annahme durch den Kunden-Upstream, Weitergabe, Erkennung, Eindämmung, verifizierter Rückzug und dauerhaft belegbare Reparatur.

Das Ereignis und seine belastbare Grenze

Der untersuchte Vorfall begann am 16. April 2021 im öffentlichen BGP-Beobachtungsraum. Analysen brachten AS55410, das Vodafone Idea zugeordnet wurde, mit einer außergewöhnlich großen Zahl von Ursprungsankündigungen in Verbindung. Die verfügbaren Quellen erlauben eine Rekonstruktion dessen, was bestimmte Beobachter zu bestimmten Zeitpunkten sahen. Sie liefern jedoch keinen vollständigen Mitschnitt aller Router, aller Peering-Verbindungen oder aller Weiterleitungsentscheidungen des Internets.

Diese Grenze ist entscheidend. BGP verteilt Erreichbarkeitsinformationen zwischen autonomen Systemen. Ein Routenkollektor erhält nur die Ansichten der Peers, die ihm Daten liefern. Eine sichtbare Ankündigung belegt deshalb, dass sie einen bestimmten Beobachtungspunkt erreicht hat. Sie beweist nicht automatisch, dass jedes Netz die Route akzeptierte, sie zum bevorzugten Pfad machte oder Datenverkehr darüber weiterleitete. Ebenso kann ein Präfix in einer Analyse als ungewöhnlich erscheinen, ohne dass jeder Dienst innerhalb dieses Präfixes überall unerreichbar geworden sein muss.

Catchpoint berichtete einen präzisen Zeitpunkt: Um 13:48:58 GMT sei AS55410 als Ursprung von mehr als 34.000 Netzen erschienen. Zahl, Einheit, Zeitpunkt und Urheber dieser Aussage gehören zusammen. Es handelt sich um eine von Catchpoint veröffentlichte Beobachtung, nicht um eine universelle Zählung aller damaligen globalen Routingtabellen. Eine Darstellung als „mehr als 34.000 von Catchpoint beobachtete Netze“ wahrt diese Beweisgrenze; eine Darstellung als unbestrittene Gesamtzahl aller tatsächlich umgeleiteten Präfixe würde sie überschreiten.

Für den Zeitraum von 13:45 bis 15:00 GMT beschrieb Catchpoint am RIPE-RIS-Kollektor rrc00 ungefähr 225.000 BGP-Update-Nachrichten. Updates umfassen Änderungen des beobachteten Routingzustands, darunter Ankündigungen und Rückzüge. Die Zahl ist daher kein Zähler eindeutig betroffener Präfixe, Nutzer oder Unternehmen. Sie beschreibt die Menge der vom genannten Kollektor in diesem Intervall erfassten Kontrollnachrichten, wie Catchpoint sie ausgewertet hat.

Catchpoint berichtete außerdem, dass 64 von 73 Peers des betrachteten Kollektors mindestens ein betroffenes Netz erhielten. Auch dieses Verhältnis ist an rrc00 und an die dort sichtbaren Peers gebunden. Es belegt eine breite Verteilung innerhalb dieser Beobachtungsperspektive, aber keine identische Annahme oder Pfadauswahl durch alle Internetbetreiber. Die übrigen neun Peers dürfen umgekehrt nicht pauschal als vollständig geschützt gelten: Aus der Abwesenheit einer Route in einer bestimmten Kollektoransicht folgt nicht, dass kein anderer Router desselben Betreibers sie gesehen oder anders behandelt hat.

Nach der Catchpoint-Darstellung wurden die meisten ungewöhnlichen Routen nach ungefähr einer Stunde entfernt. „Ungefähr“ und „die meisten“ sind dabei tragende Einschränkungen. Daraus lässt sich weder ein einheitlicher Endzeitpunkt für alle Präfixe noch eine identische Störungsdauer für jedes Netz ableiten. Rückzüge verbreiten sich ebenfalls schrittweise. Verschiedene Router können Änderungen zu unterschiedlichen Zeitpunkten empfangen, verarbeiten und in ihre Pfadauswahl übernehmen.

Catchpoint verband die Auswirkungen mit mehr als 3.500 Unternehmen. Auch diese Zahl bleibt eine veröffentlicherspezifische Abschätzung und kein vollständiges Verzeichnis aller betroffenen Organisationen oder Endnutzer. Sie darf nicht in eine exakte Zahl ausgefallener Unternehmen umgedeutet werden. Ein Unternehmen kann mehrere Präfixe, Provider, Standorte und Ausweichpfade besitzen; umgekehrt kann eine einzelne Routingänderung viele nachgelagerte Dienste berühren. Die öffentliche Quellenlage belegt weder für jede Organisation dieselbe Dauer noch denselben Paketverlust, dieselbe Unerreichbarkeit oder denselben wirtschaftlichen Schaden.

Drei Begriffe, die nicht dasselbe bedeuten

Die Berichterstattung verwendete unterschiedliche Begriffe für den Vorfall. Der Titel dieses Artikels spricht von einem Routing-Leak. MANRS bezeichnete das Ereignis in seiner eigenen Analyse als großen BGP-Hijack. The Register fasste es journalistisch als Vorfall mit mehr als 30.000 „bogus prefixes“, also falschen oder unberechtigten Präfixankündigungen, zusammen. Diese Formulierungen beschreiben überlappende Aspekte, sind aber keine austauschbaren technischen oder rechtlichen Feststellungen.

Ein Route Leak bezeichnet typischerweise die Weitergabe von Routinginformationen über eine Grenze hinweg, über die sie nach der vorgesehenen Geschäfts- oder Topologiebeziehung nicht verbreitet werden sollten. Eine Origin Misannouncement liegt vor, wenn ein autonomes System als Ursprung eines Präfixes erscheint, obwohl dieser Ursprung nicht vorgesehen oder nicht autorisiert ist. Ein Hijack beschreibt die unberechtigte Übernahme oder Anziehung von Erreichbarkeit und kann in manchen Verwendungen auch unbeabsichtigte Ereignisse umfassen.

Die Alltagssprache verbindet „Hijack“ häufig mit Absicht; diese Absicht folgt aber nicht allein aus einem beobachteten BGP-Update.

RFC 7908 bietet eine Taxonomie für Route Leaks, doch eine Taxonomie ersetzt keine Ereignisforensik. Um einen konkreten Leak-Typ sicher zu bestimmen, wären belastbare Informationen über Beziehungen, lokale Präferenzen, Exportregeln und den tatsächlichen AS-Pfad erforderlich. Die öffentlichen Beobachtungen stützen die Feststellung einer großflächigen Routinganomalie und ungewöhnlicher Ursprünge. Sie belegen nicht das Motiv hinter der Konfiguration oder Ankündigung.

Deshalb darf der Vorfall nicht als nachgewiesener böswilliger Angriff beschrieben werden. Ebenso wenig beweisen die Quellen Fahrlässigkeit, bewusste Verschleierung, Rechtswidrigkeit oder eine bestimmte rechtliche Haftung. Technische Verantwortlichkeit fragt, wer eine wirksame Kontrolle besaß und was diese Kontrolle leisten konnte. Sie ist nicht dasselbe wie die Feststellung persönlicher Schuld oder juristischer Verantwortlichkeit.

Die getrennte MANRS-Zählung

MANRS veröffentlichte eine eigenständige Analyse. Danach kündigte AS55410 normalerweise 824 Routen an und gab während des Ereignisses mehr als 31.000 zusätzliche Routen bekannt. Diese Zählung muss getrennt von der Catchpoint-Angabe über mehr als 34.000 Netze bleiben. Abweichungen können aus Zeitpunkt, Datenquelle, Aggregation, Präfixdefinition, Beobachterauswahl oder Auswertungsmethode entstehen. Ohne eine gemeinsame Rohdatenauswertung wäre es methodisch falsch, die Zahlen zu addieren, zu mitteln oder eine von ihnen als Korrektur der anderen zu behandeln.

MANRS schrieb die in seiner Analyse beobachtete Ausbreitung Bharti Airtel AS9498 zu. Zugleich stellte MANRS fest, dass andere identifizierte Upstreams nicht denselben Routensatz weitergaben. Diese Aussage ist wichtig, weil sie die Rolle der Annahme- und Exportkontrollen im Upstream sichtbar macht. Sie darf aber nicht in die Behauptung verwandelt werden, jede einzelne anomale Route sei ausschließlich über AS9498 gelaufen oder die privaten Konfigurationen aller anderen Upstreams seien vollständig bekannt.

Der Unterschied zwischen den beobachteten Upstreams spricht gerade gegen eine monokausale Darstellung. Wenn mehrere Nachbarn dieselben oder ähnliche Kundensignale unterschiedlich behandeln, wird die Richtlinie an der Netzgrenze zu einer eigenständigen Kontrollfläche. Das entschuldigt den Ursprung nicht. Es zeigt vielmehr, dass ein Fehler am Ursprung und seine globale Reichweite zwei miteinander verbundene, aber getrennt kontrollierbare Vorgänge sind.

Wie eine Ursprungsankündigung Reichweite gewinnt

BGP ist das Protokoll, mit dem autonome Systeme Erreichbarkeitsinformationen austauschen. RFC 4271 beschreibt das grundlegende Modell: Ein Router empfängt Routen, bewertet sie nach Richtlinien und Attributen, wählt einen Pfad und kann diesen an Nachbarn weitergeben. Das Protokoll selbst enthält keine universelle Instanz, die jede Ankündigung vorab als „wahr“ oder „falsch“ bestätigt. Vertrauen entsteht aus Beziehungen, Filtern, Registrierungsdaten, kryptografischen Ursprungsaussagen und lokal durchgesetzten Regeln.

Am Anfang der untersuchten Kontrollkette stand die Fähigkeit von AS55410, Routen zu erzeugen oder an externe Nachbarn zu exportieren. Das Quellnetz kontrollierte seine Routerkonfiguration, die Erstellung von Netzwerkankündigungen, die Freigabe der exportierbaren Präfixe und die Änderungskontrolle. Eine belastbare Ausgangskontrolle hätte die tatsächlich erlaubte Präfixmenge aus einer autoritativen internen Quelle ableiten und unerwartete Abweichungen blockieren können.

Ein statischer Filter allein ist nicht automatisch ausreichend. Präfixbestände ändern sich, Kunden kommen hinzu, Ressourcen werden übertragen, und legitime spezifischere Routen können erforderlich sein. Deshalb muss die erlaubte Menge aktuell, eindeutig und nachvollziehbar gepflegt werden. Ein zu enger Filter kann legitime Erreichbarkeit verhindern; ein zu weiter Filter verliert seine Schutzwirkung. Verantwortlichkeit verlangt daher nicht nur „einen Filter“, sondern auch einen kontrollierten Prozess für dessen Datenquelle, Freigabe, Aktualisierung, Prüfung und Rücknahme.

Nach dem Export entscheidet der Upstream, welche Kundenrouten er akzeptiert. Diese Grenze ist besonders wirksam, weil ein Provider die vereinbarte Präfixmenge seines direkten Kunden kennen oder aus vereinbarten Quellen ableiten kann. Ein Kundenpräfixfilter kann Ankündigungen ablehnen, die außerhalb dieser Menge liegen. Maximum-Prefix-Grenzen können eine Sitzung begrenzen oder alarmieren, wenn die Zahl empfangener Präfixe plötzlich weit über den erwarteten Umfang steigt.

Die MANRS-Angabe von normalerweise 824 Routen gegenüber mehr als 31.000 zusätzlichen Routen illustriert, weshalb mengenbasierte Kontrollen relevant sind. Sie beweist aber nicht, welche Schwelle ein bestimmter Provider konfiguriert hatte oder ob eine solche Kontrolle ausgelöst wurde. Eine Maximum-Prefix-Regel ist zudem kein semantischer Eigentumsnachweis: Ein Kunde könnte innerhalb einer hohen erlaubten Obergrenze falsche Präfixe ankündigen. Deshalb sollte sie mit einer autorisierten Präfixliste und weiteren Prüfungen kombiniert werden.

Hat ein Upstream eine Route akzeptiert, folgt eine zweite Entscheidung: Darf sie an andere Kunden, Peers oder Provider weitergegeben werden? Import- und Exportkontrolle sind getrennte Schritte. Ein Netz kann eine Route intern kennen, ohne sie global zu verbreiten. Umgekehrt kann eine zu großzügige Weitergaberegel die Reichweite eines bereits akzeptierten Fehlers vergrößern. Verantwortlichkeit umfasst daher sowohl die Kundenannahme als auch den anschließenden Export nach Nachbarrolle.

RFC 8212 unterstreicht den Sicherheitswert expliziter Import- und Exportrichtlinien. Der Grundgedanke ist Fail-Closed: Fehlt eine ausdrückliche Richtlinie, soll nicht stillschweigend alles akzeptiert und weitergegeben werden. RFC 7454 beschreibt betriebliche Empfehlungen für BGP-Sicherheit und Filterung. Beide Dokumente zeigen verfügbare Kontrollmöglichkeiten. Sie beweisen nicht, dass Vodafone Idea, Bharti Airtel oder ein anderer genannter Betreiber diese Möglichkeiten im April 2021 vollständig, teilweise oder gar nicht eingesetzt hatte.

RFC 9234 definiert BGP-Rollen und das Only-to-Customer-Attribut, kurz OTC. Solche Mechanismen können Beziehungen ausdrücklicher machen und unerwartete Weitergabe begrenzen. Auch hier gilt: Die Existenz eines Standards ist kein Nachweis seiner damaligen Implementierung. Für das Ereignis lässt sich nur sagen, dass rollenbewusste Import- und Exportpolitik eine relevante Kontrollklasse darstellt. Ob sie auf den konkreten Sitzungen verfügbar, aktiviert oder korrekt gepflegt war, bleibt in den vorliegenden öffentlichen Quellen offen.

Was RPKI leisten kann – und was nicht

RPKI stellt kryptografisch abgesicherte Aussagen über die zulässige Ursprung-AS-Nummer für ein Präfix bereit. Eine Route Origin Authorization, kurz ROA, verbindet einen Ressourcenbereich mit einem oder mehreren erlaubten Ursprüngen und einer maximal zulässigen Präfixlänge. Router oder vorgeschaltete Validierungssysteme können empfangene Routen daraufhin als valid, invalid oder not found einordnen.

RFC 6811 und RFC 8893 beschreiben Terminologie und Einsatz von RPKI-basierter Origin Validation. Ist eine anomale Route von einer passenden ROA abgedeckt und stimmt der beobachtete Ursprung nicht mit der Autorisierung überein, kann die Route als invalid bewertet werden. Eine lokale Richtlinie kann solche Routen ablehnen oder geringer priorisieren. Das ist eine konkrete Schutzfläche gegen bestimmte falsche Ursprungsankündigungen.

Origin Validation bestätigt jedoch nicht den gesamten AS-Pfad. Eine Route kann einen erlaubten Ursprung besitzen und trotzdem über eine unerwartete oder unerwünschte Beziehung weitergegeben werden. Ebenso erhält ein Präfix ohne passende ROA den Zustand not found; daraus folgt nicht automatisch, dass die Route legitim oder illegitim ist. RPKI schützt deshalb nicht sämtliche unbedeckten Präfixe und ersetzt weder Kundenfilter noch rollenbasierte Exportpolitik.

Auch ein technisch gültiger RPKI-Zustand ist keine Verfügbarkeitsgarantie. Ein Router kann eine Route trotz Bewertung nach lokaler Richtlinie behandeln, und verschiedene Betreiber können verschiedene Konsequenzen festlegen. Caches, Synchronisation, Konfigurationsfehler und Ausfallmodi beeinflussen die tatsächliche Durchsetzung. Der relevante Beweis ist nicht nur, dass eine ROA existierte, sondern dass die zuständige Netzgrenze aktuelle Validierungsdaten bezog und eine nachvollziehbare Regel auf das Ergebnis anwendete.

Die Quellen belegen nicht vollständig, welche betroffenen Präfixe am 16. April 2021 durch ROAs abgedeckt waren, welchen Validierungszustand jeder Beobachter sah oder wie einzelne Router mit einem invaliden Zustand umgingen. Daraus folgt eine klare Grenze: RPKI ist ein wichtiger Präventions- und Beweisbaustein, aber keine nachträgliche Universalantwort auf jedes Detail dieses Ereignisses.

Register, IRR und die Wirklichkeit auf dem Router

ASN- und Präfixregister schaffen Zuordnung, Eindeutigkeit und historische Nachvollziehbarkeit. IRR-Route-Objekte können ausdrücken, welches autonome System ein Präfix ankündigen soll. ROAs können einen Ursprung kryptografisch autorisieren. Diese Ebenen helfen Betreibern, Filter zu erzeugen, Änderungen zu prüfen und widersprüchliche Angaben zu erkennen.

Keine dieser Aufzeichnungen konfiguriert jedoch von selbst einen Router. Ein korrekter Datensatz bleibt operativ wirkungslos, wenn er nicht rechtzeitig abgerufen, geprüft und in eine durchsetzbare Richtlinie überführt wird. Ein veralteter oder zu weit gefasster Datensatz kann umgekehrt falsches Vertrauen erzeugen. Die operative Frage lautet deshalb stets: Welche Datenquelle speiste welchen Filter, wann wurde sie aktualisiert, und wie reagierte das Netz auf Abweichungen?

Aktuelle Ansichten von CAIDA ASRank, CIDR Report und RIPE Stat können Kontext zu AS55410, seinen Ressourcen oder seiner beobachteten Topologie liefern. Sie dürfen nicht als perfekte Momentaufnahme des 16. April 2021 behandelt werden. Beziehungen und Präfixbestände können sich seitdem verändert haben; aktuelle APIs können außerdem andere Datenquellen und Aggregationsregeln verwenden. Ihr Wert liegt in der Einordnung und Nachprüfbarkeit, nicht in einer rückwirkend vollständigen Rekonstruktion privater Routingzustände.

Eine belastbare Untersuchung müsste historische Datensätze mit eindeutigen Zeitstempeln verwenden und offenlegen, aus welcher Sicht sie stammen. Selbst dann blieben private Sitzungsrichtlinien, verworfene Updates und interne Pfadauswahl häufig unsichtbar. Öffentliche Register beantworten, was eingetragen oder autorisiert war. Sie beantworten nicht vollständig, was jeder Router tatsächlich akzeptierte oder weiterleitete.

RIPE RIS und RouteViews als Beobachter

RIPE RIS und RouteViews sammeln BGP-Informationen von teilnehmenden Peers. Sie sind für Forschung und Störungsanalyse besonders wertvoll, weil sie zeitlich geordnete Ansichten bewahren. Aus mehreren Beobachtungspunkten lassen sich Beginn, Ausbreitung und Rückzug einer Anomalie näherungsweise vergleichen.

Ein Kollektor ist aber kein Kontrollpunkt im Pfad. Er genehmigt keine Route, setzt keine Kundenvereinbarung durch und zwingt keinen Betreiber zur Auswahl eines bestimmten Pfades. Seine Daten zeigen, was der jeweilige Peer an den Kollektor lieferte. Exportfilter in Richtung des Kollektors, Topologie, lokale Präferenz und Sitzungsumfang begrenzen die sichtbare Perspektive.

Deshalb beweist die Sichtbarkeit einer Route bei rrc00 nicht, dass jedes autonome System sie als besten Pfad verwendete. Genauso beweist die Nicht-Sichtbarkeit bei einem bestimmten Peer nicht, dass der Betreiber die Route an keiner anderen Stelle kannte. Collector-Daten sind Beobachtungsbelege, keine globale Abstimmung über Wahrheit oder Legitimität.

Der stärkste Einsatz solcher Daten liegt im Vergleich: Wann erschien eine Route erstmals? Welche Peers zeigten sie? Wie veränderte sich der AS-Pfad? Wann erschienen Rückzüge oder Ersatzrouten? Welche Beobachtungen blieben nach der mutmaßlichen Eindämmung übrig? Diese Fragen machen aus Kollektoren ein Instrument für zeitliche Rechenschaft, ohne ihnen eine Autorität zuzuschreiben, die sie nicht besitzen.

Auswirkungen ohne Überdehnung

Die öffentliche Berichterstattung beschreibt eine weitreichende Anomalie. Catchpoint verband sie mit mehr als 3.500 Unternehmen und beobachtete eine große Anzahl von Updates sowie eine breite Verteilung unter den betrachteten Peers. The Register fasste die Größenordnung als mehr als 30.000 falsche Präfixe zusammen. Diese Aussagen begründen eine ernsthafte Untersuchung der betrieblichen Auswirkungen.

Sie belegen jedoch keinen vollständigen Katalog betroffener Nutzer, Standorte oder Dienste. Ein ungewöhnlicher Ursprung kann Datenverkehr anziehen, in eine Sackgasse führen, über einen ungeeigneten Pfad transportieren oder ohne sichtbare Wirkung bleiben, wenn andere Netze die Route verwerfen. Ob und wie stark ein Ziel beeinträchtigt wird, hängt unter anderem von Präfixlänge, lokaler Präferenz, konkurrierenden Routen, Filterung und dem Standort des beobachtenden Netzes ab.

Daher wäre die Behauptung falsch, jedes angekündigte Präfix sei überall unerreichbar geworden. Ebenso unbelegt wäre die Aussage, jede Organisation habe dieselbe Ausfallzeit oder denselben Verlust erlebt. Die Quellen liefern auch keinen exakten finanziellen Schaden und keine vollständige Zahl betroffener Endnutzer.

Die belastbare Kernaussage liegt auf der Kontroll­ebene: Eine sehr große Menge ungewöhnlicher Ursprungsinformationen erreichte zahlreiche beobachtete Netze. Einige davon verbreiteten die Informationen weiter. Dieser Kontrollzustand allein ist relevant, weil er zeigt, dass fehlerhafte Routinginformationen mehrere unabhängige Grenzen passieren konnten.

Prävention am Ursprung

Die erste Präventionslinie befindet sich im Quellnetz. Eine Organisation, die Präfixe ankündigt, sollte eine explizite Sollmenge pflegen: welche Präfixe, welche Präfixlängen, welche Ursprung-AS-Nummer und welche externen Nachbarn sind für den jeweiligen Dienst erlaubt? Änderungen an dieser Menge benötigen nachvollziehbare Freigabe, technische Prüfung und einen Rücknahmeplan.

Automatisierte Konfigurationsgenerierung kann Tippfehler reduzieren, vergrößert aber bei einer falschen Datenquelle den möglichen Schadensradius. Deshalb sind unabhängige Plausibilitätsprüfungen notwendig. Ein Export, der plötzlich nicht Hunderte, sondern Zehntausende zusätzliche Routen umfasst, sollte vor oder unmittelbar nach der Aktivierung eine harte Abweichung auslösen.

Sinnvolle Kontrollen umfassen Präfix- und Längenlisten, Peer-spezifische Exportregeln, Schutz vor unerwarteter Redistribution, Staging- oder Vergleichsprüfungen und eine klare Trennung zwischen internen Routinginformationen und dem, was extern angekündigt werden darf. Keine einzelne Maßnahme deckt alle Fehlerklassen ab. Entscheidend ist die Verbindung aus autoritativer Sollmenge, expliziter Richtlinie und unmittelbarer Beobachtung des tatsächlich ausgesendeten Zustands.

Die Verantwortung des Ursprungsnetzes umfasst auch das Beweismaterial. Konfigurationsänderungen, Freigaben, generierte Richtlinien, BGP-Sitzungsprotokolle und Alarme sollten so aufbewahrt werden, dass später festgestellt werden kann, wann eine Abweichung entstand und welcher Rücknahmeschritt wirkte. Ohne diese Spuren bleibt selbst eine schnelle Korrektur schwer verifizierbar.

Prävention beim Upstream

Ein direkter Upstream kennt seine Kundenbeziehung und besitzt deshalb eine besondere Möglichkeit zur Begrenzung. Er kann eine erlaubte Präfixmenge vereinbaren, aus geprüften Quellen ableiten und an der Kundensitzung durchsetzen. Ankündigungen außerhalb dieser Menge können verworfen werden, bevor sie andere Teile des Internets erreichen.

Maximum-Prefix-Grenzen ergänzen diese Prüfung. Sie sollten zur normalen Größenordnung des Kunden passen und genügend Raum für legitime Änderungen lassen, ohne einen Sprung um mehrere Größenordnungen stillschweigend zu akzeptieren. Eine Grenze kann die Sitzung beenden, neue Präfixe zurückweisen oder zumindest einen dringenden Alarm erzeugen. Die gewählte Reaktion muss das Risiko einer versehentlichen Kundentrennung gegen den möglichen globalen Schaden abwägen.

RPKI Origin Validation bietet eine weitere unabhängige Sicht. Ein Upstream kann ungültige, abgedeckte Ursprünge ablehnen, selbst wenn ein anderer Filter zu weit gefasst ist. IRR-basierte Filter können zusätzliche Präfix-Ursprung-Beziehungen abbilden. Beide Datenquellen benötigen jedoch Pflege, Aktualität und einen nachvollziehbaren Umgang mit Konflikten.

Schließlich muss der Upstream die Weitergabe kontrollieren. Eine akzeptierte Kundenroute sollte nicht automatisch über jede Beziehung exportiert werden. Rollen, Geschäftsbeziehungen und explizite Exportrichtlinien begrenzen die Reichweite. MANRS’ Beobachtung, dass andere identifizierte Upstreams nicht denselben Routensatz verbreiteten, unterstreicht die Relevanz dieser Netzgrenze, ohne die private Ursache für das unterschiedliche Verhalten abschließend zu erklären.

Erkennung: Die eigene Außenansicht zählt

Ein Betreiber sollte nicht nur überwachen, was seine Router intern anzeigen. Er muss auch prüfen, wie externe Beobachter seine Präfixe und AS-Nummern sehen. Interne Telemetrie kann bestätigen, welche Updates erzeugt oder empfangen wurden. Externe Kollektoren und Monitoringdienste zeigen, ob diese Informationen tatsächlich über andere Netze sichtbar wurden.

Wichtige Signale sind ein plötzlicher Anstieg der angekündigten Präfixzahl, neue Ursprünge für bekannte Ressourcen, unerwartete spezifischere Routen, neue AS-Pfade, RPKI-invalid-Zustände und eine ungewöhnliche Update-Rate. Zusätzlich sollte ein Kunden-Upstream den Abstand zwischen erwarteter und empfangener Präfixmenge überwachen.

Ein Alarm ist nur dann eine Kontrolle, wenn Zuständigkeit und Reaktionszeit geklärt sind. Tausende Warnungen ohne Priorisierung können dieselbe Wirkung haben wie kein Alarm. Ereignisse mit einem Sprung um mehrere Größenordnungen sollten automatisch eine höhere Stufe erhalten, weil jede Minute zusätzlicher Weitergabe den Kreis beobachtender und möglicherweise auswählender Netze vergrößern kann.

Auch die Korrelation mehrerer Ansichten ist wichtig. Interne Logs, RPKI-Zustände, IRR- und Registerinformationen sowie RIPE-RIS- oder RouteViews-Daten beantworten unterschiedliche Fragen. Stimmen sie nicht überein, ist die Abweichung selbst ein Untersuchungsgegenstand und kein Grund, eine Ebene vorschnell zur alleinigen Wahrheit zu erklären.

Eindämmung und verifizierter Rückzug

Die erste Eindämmungsmaßnahme besteht darin, die weitere Erzeugung oder den Export der anomalen Routen zu stoppen. Das kann eine Rücknahme der fehlerhaften Änderung, eine enger gefasste Exportregel oder eine kontrollierte Deaktivierung der betroffenen Sitzung erfordern. Welche Maßnahme angemessen ist, hängt von der Konfiguration ab, die öffentlich nicht bekannt ist.

Parallel können Upstreams die betroffene Kundenpräfixmenge begrenzen oder konkrete Ankündigungen verwerfen. Nachgelagerte Netze können ungültige oder unerwartete Routen entfernen. Koordination zwischen NOC-Teams ist wesentlich, weil die Korrektur am Ursprung nicht garantiert, dass jeder externe Router den Rückzug bereits verarbeitet hat.

RFC 7999 beschreibt eine weithin bekannte Blackhole-Community als allgemeinen Mechanismus, mit dem Verkehr für bestimmte Ziele verworfen werden kann. Das ist relevanter Kontext für Routingkontrollen, aber keine Quelle belegt, dass diese Community bei diesem Ereignis verwendet wurde. Eine Blackhole-Signalisierung wäre zudem keine allgemeine Lösung für eine massenhafte falsche Ursprungsankündigung: Sie beeinflusst Datenverkehr zu markierten Präfixen und muss streng gegen Missbrauch und unbeabsichtigten Verlust abgesichert sein.

Ein Rückzug gilt nicht allein deshalb als abgeschlossen, weil ein lokaler Router keine anomale Route mehr zeigt. Verifikation verlangt externe Stichproben: Sind die ungewöhnlichen Ursprünge bei mehreren Kollektoren verschwunden? Erscheinen wieder die erwarteten Pfade? Bleiben einzelne spezifischere Routen bestehen? Treffen neue Updates ein? Der operative Abschluss sollte den Zeitpunkt der lokalen Korrektur vom Zeitpunkt der beobachteten globalen Beruhigung unterscheiden.

Wiederherstellung und dauerhafte Reparatur

Wiederherstellung bedeutet zunächst, stabile und erwartete Erreichbarkeit zurückzugewinnen. Danach beginnt die schwierigere Frage, ob die auslösende Kontrolllücke tatsächlich geschlossen wurde. Eine einmalige Konfigurationskorrektur kann den sichtbaren Vorfall beenden, ohne den zugrunde liegenden Prozess zu verbessern.

Eine dauerhafte Reparatur müsste mindestens die autorisierte Präfixmenge, den Ursprung der fehlerhaften Konfiguration, die Freigabewege, die Upstream-Filter, die Alarmkette und die externe Verifikation untersuchen. Wenn Automatisierung beteiligt war, muss geklärt werden, ob eine falsche Eingabe, eine fehlende Begrenzung oder ein unzureichender Vergleich zwischen geplantem und erzeugtem Zustand vorlag.

Bei Upstreams wäre zu prüfen, warum eine außergewöhnliche Präfixmenge akzeptiert oder weitergegeben werden konnte, sofern dies in den jeweiligen Beobachtungen geschah. Mögliche Kategorien sind eine zu weite Kundenliste, eine fehlende Maximum-Prefix-Grenze, veraltete Autorisierungsdaten, nicht durchgesetzte Origin Validation oder eine zu großzügige Exportrichtlinie. Die öffentlichen Quellen beweisen keine dieser konkreten Ursachen; sie definieren lediglich überprüfbare Fragen.

Keine der verwendeten Quellen belegt eine vollständige, dauerhafte Nachbesserung durch Vodafone Idea, Bharti Airtel oder ein anderes benanntes Netz. Ebenso fehlt ein öffentlicher Nachweis darüber, welche privaten Routerregeln vor oder nach dem Ereignis galten. Verantwortliche Berichterstattung muss diese Lücke sichtbar lassen, anstatt eine nachträgliche Verbesserung zu unterstellen.

Verantwortlichkeit entlang der Kontrollkette

Verantwortlichkeit sollte nach praktischer Kontrolle geordnet werden. Das Quellnetz kontrolliert, welche Routen es erzeugt und exportiert. Der direkte Upstream kontrolliert, welche Kundenrouten er akzeptiert. Weitere Provider und Peers kontrollieren ihre eigene Importauswahl und Weitergabe. Präfixinhaber kontrollieren die Qualität ihrer ROAs und Registrierungsdaten. Monitoringbetreiber und Routenkollektoren kontrollieren Beobachtung und Aufbewahrung, aber nicht die Weiterleitung selbst.

Phase Praktische Kontrolle Belastbarer Nachweis
Ursprung Autorisierte Präfixmenge, Origin- und Exportregeln, Änderungskontrolle Konfigurationsstand, Freigabe, erzeugte Updates, Zeitstempel
Kundenannahme Präfixautorisierung, Längenfilter, Maximum-Prefix, Origin Validation Aktive Richtlinie, Datenquelle, Alarm- und Verwerfungsprotokolle
Weitergabe Rollen- und beziehungsbezogene Exportregeln Peer-spezifische Exportentscheidung, sichtbare Nachbarpfade
Erkennung Interne und externe Abweichungsüberwachung Alarmzeit, Kollektorsicht, RPKI- und Präfixvergleich
Eindämmung Stoppen, Filtern, Koordinieren Änderungszeit, Sitzungs- oder Filteraktion, Kommunikationsprotokoll
Rückzug Entfernung der anomalen Route Lokaler Zustand plus mehrere zeitlich geordnete Außenansichten
Dauerhafte Reparatur Begrenzung der wiederholbaren Fehlerklasse aktualisierte Kontrollen, Tests, Zuständigkeit und Folgeverifikation

Diese Aufteilung vermeidet zwei Fehlbilder. Das erste wäre, jede Verantwortung dem Ursprung zuzuschreiben und die unabhängige Kontrollmacht der Upstreams zu ignorieren. Das zweite wäre, den Ursprung zu entlasten, weil ein Provider die Route hätte filtern können. Beide Ebenen besitzen eigene, nicht austauschbare Pflichten gegenüber dem von ihnen kontrollierten Zustand.

Register und Kollektoren nehmen eine andere Rolle ein. Sie bewahren Zuordnungen und Beobachtungen und ermöglichen spätere Prüfung. Sie sind weder eine souveräne Garantie der Erreichbarkeit noch eine zentrale Instanz, die Routerentscheidungen ersetzt. Die entscheidende Wirklichkeit entsteht aus der Richtlinie, die auf laufenden Netzen tatsächlich durchgesetzt wird.

Das Titelbild dieses Beitrags ist ausschließlich ein generisches, deterministisch erstelltes redaktionelles Netzwerkdiagramm. Es ist weder eine Fotografie noch die Darstellung einer Anlage von Vodafone Idea oder Bharti Airtel, weder eine Karte noch eine Rekonstruktion des Vorfalls. Seine abstrakten Pfade veranschaulichen lediglich, dass eine Route an einer Netzgrenze verworfen werden kann, während andere Pfade weitergegeben werden.