Zusammenfassung

  • BGPMon verortete das AS12389-Ereignis am 26. April 2017 zwischen 22:36 und etwa 22:43 UTC. Es zählte 50 betroffene Präfixe in 37 autonomen Systemen. ThousandEyes nutzte einen anderen Rahmen: Es beobachtete während dieses Zeitfensters 137 von AS12389 ausgehende Präfixe, stufte etwa 100 als gewöhnlich oder mit russischen Organisationen verknüpft ein und identifizierte 36 Präfixe außerhalb des Unternehmens. Diese Nenner beschreiben unterschiedliche Auswahlen und sollten nicht zusammengeführt werden. [1][2]
  • Der direkte Infrastrukturmechanismus war eine falsche Routenentstehung und -verbreitung. Einige Ankündigungen waren spezifischere Routen. BGPMon hob 203.112.90.0/24 gegenüber einem normalerweise angekündigten /23 hervor – eine Unterscheidung, die erklärt, warum die normale Routenauswahl die falsche Route bevorzugen konnte, ohne dass der betroffene Dienst selbst kompromittiert wurde. [2]
  • ThousandEyes beobachtete, dass Peers wie Cogent, Hurricane Electric und Tata AS12389-Ankündigungen akzeptierten und weiterverbreiteten. Seine Pfadmessungen zeigten, dass der Datenverkehr für mindestens einen betroffenen E-Commerce-Dienst in das Netz von Rostelecom geleitet wurde und später das beabsichtigte Ziel erreichte. Dies stützt die Annahme einer Umleitung eines Teils des Produktivverkehrs, nicht jedoch die Behauptung, dass jede Route, jeder Nutzer oder jedes Paket umgeleitet wurde. [1]
  • Unter den betroffenen Präfixen waren Finanz-, Zahlungs-, E-Commerce-, Websicherheits- und zertifikatsbezogene Dienste vertreten. Zu den in den Berichten namentlich genannten Beispielen gehörten Mastercard, Visa, BNP Paribas, HSBC, Symantec und GeoTrust. Die Routing-Belege zeigen nicht, dass die internen Systeme dieser Organisationen kompromittiert wurden. [1][2]
  • Die bestätigten Belege bestehen aus Beobachtungen des Ursprungs von AS12389, dem kurzen Ereigniszeitfenster, einigen spezifischeren Ankündigungen, der Verbreitung durch mehrere Peers und gemessenen Pfadänderungen. Ein Routing- oder Konfigurationsfehler ist eine plausible Erklärung. Eine gezielte Ausrichtung und Abfangung bleiben umstritten. Die Identität des Akteurs, der interne Auslöser, die Paketinspektion, entschlüsselte Inhalte, Transaktionseffekte, Verluste und eine dauerhafte Behebung bleiben unbekannt.
  • Die Konzentration von Finanz- und sicherheitsrelevanten Zielen ließ das Muster für BGPMon und ThousandEyes verdächtig erscheinen. BGPMon beobachtete auch Ankündigungen, die andere mit Rostelecom verbundene autonome Systeme betrafen, was einen unabsichtlichen internen Fehler als konkurrierende Hypothese stützt. Keine der Überwachungsorganisationen verfügte über die internen Änderungs-, Authentifizierungs- oder Konfigurationsprotokolle des Betreibers. [1][2]
  • Die Verantwortlichkeit folgt der praktischen Kontrolle, nicht einer unbewiesenen Schlussfolgerung über das Motiv. Rostelecom kontrollierte die Routenerstellung und den Export innerhalb von AS12389. Die akzeptierenden Peers kontrollierten Filter, Validierung, Routenannahme und -weiterverbreitung. Präfix-Inhaber kontrollierten Autorisierungsdaten, externe Überwachung und Eskalation. Unabhängige Überwachungsorganisationen kontrollierten die Qualität und Erhaltung externer Beobachtungen.
  • RPKI kann einem Netzwerk helfen zu bewerten, ob ein Ursprung durch eine passende Route Origin Authorization autorisiert ist, beweist jedoch weder die Absicht noch den internen Mechanismus. Das Ereignis liegt zudem vor der breiten Durchsetzung der Route Origin Validation. Der historische ROA-Status jedes betroffenen Präfixes und die Validierungsrichtlinie jedes Peers müssten ermittelt werden, bevor behauptet werden kann, dass RPKI eine bestimmte Route blockiert hätte. [11]-[14][18]
  • Der nachweisbare Schaden ist ein vorübergehender Verlust der beabsichtigten Routing-Kontrolle und die Freilegung eines Teils des Datenverkehrs gegenüber einem nicht autorisierten Transitpfad. Der Datensatz belegt weder Transaktionsbetrug, gestohlene Zugangsdaten, eine TLS-Kompromittierung, geänderte Daten, einen vollständigen Ausfall, eine quantifizierte betroffene Bevölkerung noch finanziellen Schaden. Verschlüsselung kann die Offenlegung von Inhalten verringern, aber die verfügbaren Belege zeigen nicht, welche Sitzungen eine wirksame Verschlüsselung verwendeten.
  • Eine abschließende Darstellung würde Aufzeichnungen erfordern, die öffentliche Routing-Beobachtungen nicht liefern können: AS12389-Änderungs- und Authentifizierungsprotokolle, einen Bericht zur Ursachenanalyse, Peer-Filter- und Routenauswahlprotokolle, reproduzierbare Archivanalysen, den historischen ROA-Status, dienstseitige Datenverkehrs- und TLS-Aufzeichnungen, Paketaufzeichnungen, Vorfallberichte von Kunden und Belege dafür, ob die gemessenen Pfade Produktivverkehr übertrugen.

Sieben Minuten schufen ein dauerhaftes Belegproblem

Das Ereignis war kurz, aber seine Belegstruktur bleibt wichtig. BGPMon legte den Beginn auf 22:36 UTC und das Ende auf etwa 22:43 UTC am 26. April 2017 fest. Während dieses Intervalls sahen Routenkollektoren und Überwachungssysteme, wie AS12389 Erreichbarkeit für Adressbereiche ankündigte, die mit anderen autonomen Systemen verknüpft waren. Mehrere externe Netzwerke akzeptierten zumindest einige dieser Ankündigungen und verbreiteten sie weiter. ThousandEyes maß zudem veränderte End-to-End-Pfade, anstatt sich nur auf Aktualisierungen der Steuerungsebene zu verlassen. [1][2]

Diese Beobachtungen belegen mehr als eine vage Routing-Anomalie. Sie identifizieren ein autonomes Ursprungssystem, ein Zeitfenster, angekündigte Präfixe, die Verbreitung und eine Pfadkonsequenz. Verteilte Routing-Daten können daher eine starke Schlussfolgerung darüber stützen, was dem Internet mitgeteilt wurde: AS12389 stellte sich als Ursprung für Routen dar, die nicht zu seinem normalen autorisierten Satz gehörten, einschließlich des von Organisationen außerhalb von Rostelecom genutzten Adressraums.

Die gleichen Beobachtungen belegen weniger, als viele Beschreibungen andeuten. Ein BGP-Update enthält nicht das Motiv eines Betreibers. Ein geänderter Pfad verrät nicht, wer einen Befehl eingegeben hat, welches System ihn generiert hat, ob ein Konto missbraucht wurde oder ob eine geplante Konfiguration ihren beabsichtigten Rahmen überschritten hat. Selbst eine verdächtige Auswahl von Zielen offenbart nicht die interne Entscheidung, die zu dieser Auswahl führte.

Die Unterscheidung ist wichtig, da die zur Beschreibung eines Routing-Vorfalls verwendeten Wörter lautlos eine Schlussfolgerung implizieren können. „Leak“ (Leck) kann die Verbreitung von Routen beschreiben, die nicht hätten exportiert werden dürfen. „Hijack“ (Entführung) kann eine falsche Routenentstehung oder eine Route beschreiben, die Datenverkehr umleitet, wird jedoch oft als Beweis für eine feindselige Absicht verstanden. Die beobachtbare Aktenlage stützt falsche Ursprungsankündigungen und Datenverkehrsumleitung.

Sie belegt für sich genommen keine absichtliche Beschlagnahme, Spionage oder einen Plan, gezielt Finanzinstitute ins Visier zu nehmen.

Spätere Bewertungen durch CERT-EU und ENISA ordneten das Ereignis in breitere Diskussionen über BGP-Hijacking und Routing-Sicherheitsrisiken ein. Diese Beschreibungen sind als zugeschriebene institutionelle Bewertungen nützlich. Sie ersetzen jedoch keine nicht offengelegten AS12389-Protokolle, Peer-Richtlinienaufzeichnungen oder dienstseitigen Datenverkehrsbelege. [4]-[6]

Der angemessene Verantwortlichkeitstest beginnt mit dieser Asymmetrie. Öffentliche Routing-Belege können unabhängig beobachtet und reproduziert werden. Interne Ursachen und Zwecke hängen weitgehend von Aufzeichnungen ab, die vom ursprünglichen Betreiber und anderen teilnehmenden Netzwerken kontrolliert werden. Je stärker die externen Belege für eine Routing-Änderung sind, desto spezifischer werden die unbeantworteten internen Fragen. Dennoch sollten die externen Belege nicht zu Antworten überdehnt werden, die sie nicht liefern können.

Aus diesem Grund kann ein siebenminütiges Ereignis auch Jahre später noch ungelöst sein. Die Rücknahme beendete den unmittelbaren Routing-Zustand. Sie schloss die Beleglücke nicht. Betriebliche Wiederherstellung und öffentliche Erklärung sind separate Pflichten: Die eine stellt das Routing wieder her, während die andere zeigt, wie der Fehler entstanden ist, welcher Datenverkehr offengelegt wurde, warum die Kontrollen ihn nicht eindämmen konnten und was sich danach geändert hat.

Die zwei Präfix-Zählungen beantworten unterschiedliche Fragen

BGPMon zählte 50 betroffene Präfixe in 37 autonomen Systemen. ThousandEyes berichtete, dass AS12389 während des relevanten Fensters 137 Präfixe ankündigte, und trennte dann etwa 100 Präfixe, die als gewöhnlich oder mit russischen Organisationen verknüpft erschienen, von 36 Präfixen, die externen Organisationen gehörten. [1][2]

Die Zahlen liegen nah genug beieinander, um zu einer einzigen Schlagzeile zu verleiten, und sind doch so unterschiedlich, dass dieser Schritt unzuverlässig wird. Die 50-Präfix-Zählung von BGPMon betrifft den betroffenen Satz über 37 autonome Systeme hinweg. ThousandEyes ging von allen 137 beobachteten, von AS12389 angekündigten Präfixen aus und klassifizierte sie dann, um 36 Präfixe außerhalb des Unternehmens zu isolieren. Jede Organisation nutzte ihre eigenen Beobachtungen und Auswahlmethoden. Die hier bereitgestellten öffentlichen Aufzeichnungen definieren keine Umrechnung, die einen Nenner in den anderen überführt.

Dies ist kein unbedeutendes statistisches Detail. Zählungen sind Teil der kausalen Behauptung. Eine Zahl für alle von einem autonomen System gesehenen Ankündigungen ist nicht dasselbe wie eine Zahl für mutmaßlich falsche Ursprünge. Eine Zahl für Präfixe ist keine Zahl für Opferorganisationen, Dienste, Nutzer, Sitzungen oder Pakete. Eine Zahl für autonome Systeme ist keine Zahl für juristische Personen. Die Kombination dieser Einheiten kann eine begrenzte Routenanomalie in eine unbegründete Schätzung der betroffenen Population verwandeln.

Die verantwortungsvolle Formulierung bewahrt beide Messungen und benennt, was sie messen. BGPMon beobachtete 50 betroffene Präfixe in 37 autonomen Systemen. ThousandEyes beobachtete 137 von AS12389 angekündigte Präfixe, stufte etwa 100 als wahrscheinlich gewöhnlich oder mit Russland verknüpft ein und identifizierte 36 Präfixe außerhalb des Unternehmens. Der Unterschied kann Sichtweisen, Timing, Klassifizierungs- und Zählentscheidungen widerspiegeln, aber diese Erklärungen bleiben Möglichkeiten, sofern kein reproduzierbarer Vergleich sie nachweist.

Eine historische Rekonstruktion kann diese Position verbessern. Die von Moriano und Co-Autoren von Experten geprüfte Arbeit nutzte historische BGPStream-Daten, während CAIDA den Zugang von BGPStream zu archivierten Route Views und RIPE RIS-Materialien beschreibt. Diese Quellen machen eine reproduzierbare Reanalyse im Prinzip möglich. Sie beseitigen jedoch nicht die Notwendigkeit, die Kollektorabdeckung, Zeitgrenzen, Präfixfilter und Klassifizierungsregeln zu dokumentieren. [7][8]

Zähldisziplin ist eine Verantwortlichkeitskontrolle, weil sie Übertreibungen begrenzt. Eine Betreiberreaktion, ein externer Monitor und eine institutionelle Bewertung sollten alle ihren Nenner offenlegen. Wenn ihre Zahlen voneinander abweichen, besteht die Aufgabe darin, die Methoden abzugleichen oder die Differenz beizubehalten, anstatt die Zahl zu wählen, die das Ereignis am größten oder kleinsten erscheinen lässt.

Spezifischere Routen erklären, warum die normale Auswahl den Datenverkehr umleiten konnte

BGP ist das Inter-Domain-System, über das Netzwerke Erreichbarkeitsansprüche für IP-Adressblöcke austauschen. Der entscheidende Mechanismus des Ereignisses bestand nicht nur darin, dass AS12389 irgendwo in einem unerwarteten Pfad auftauchte. Es wurde als Ursprung von Routen für Adressbereiche beobachtet, die mit anderen autonomen Systemen verknüpft waren. Einige dieser Routen waren spezifischer als die abdeckenden Routen, die normalerweise für denselben Adressraum verwendet werden. [1][2]

BGPMon hob 203.112.90.0/24 hervor, während die normale Ankündigung ein /23 abdeckte. Ein /24 beschreibt einen kleineren Adressblock als ein /23. Router bevorzugen üblicherweise die spezifischere Route für Datenverkehr, dessen Ziel in diesen kleineren Block fällt. Diese Bevorzugung erfolgt vor vielen anderen Pfadvergleichen. Das falsche /24 konnte daher Datenverkehr anziehen, selbst wenn das legitime /23 sichtbar blieb.

Dieser Mechanismus ist wichtig für die Zuweisungsdisziplin. Ein umgeleiteter Pfad erfordert keinen Beweis dafür, dass eine entfernte Bank, ein Zahlungsdienst oder ein zertifikatsbezogener Anbieter verletzt wurde. Das Routenauswahlsystem kann Datenverkehr an den falschen Ursprung senden, weil das Netzwerk einen spezifischeren Erreichbarkeitsanspruch erhalten und bevorzugt hat. Die betroffene Organisation kann ihre eigenen Systeme normal weiterbetreiben, während einige Nutzer diese Systeme über einen unbeabsichtigten Transitpfad erreichen.

Die spezifischere Beobachtung unterscheidet das Ereignis auch von der pauschalen Behauptung, AS12389 habe lediglich eine Route mit einem längeren oder ungewöhnlichen Pfad weiterverteilt. RFC 7908 liefert einen Rahmen für die Klassifizierung von Route Leaks, und RFC 7454 bietet operative Richtlinien für Sicherheit und Filterung. Diese Standards helfen Betreibern, Richtlinienfehler und Kontrollen zu beschreiben. Sie bestimmen allein anhand der öffentlichen Belege nicht, welche interne Aktion die Ankündigungen im April 2017 generiert hat oder ob die Aktion beabsichtigt war. [9][10]

Eine Verantwortlichkeitsanalyse sollte Erstellung, Export, Annahme und Auswahl trennen. Erstens wurde eine Route innerhalb von AS12389 erstellt oder eingeführt. Zweitens exportierte AS12389 diese an Nachbarn. Drittens akzeptierten und verbreiteten einige Nachbarn diese weiter. Viertens wählten nachgelagerte Router sie gemäß ihren lokalen Informationen und Richtlinien aus. Fünftens folgte zumindest ein Teil des gemessenen Datenverkehrs dem resultierenden Pfad.

Jeder Schritt hat einen anderen Beleginhaber. Aufzeichnungen zur Routengenerierung und -authentifizierung lägen am nächsten am Ursprung. Exportrichtlinien und Sitzungsprotokolle würden zeigen, was AS12389 an welchen Nachbarn gesendet hat. Peer-Aufzeichnungen würden Annahme, Filterung und lokale Auswahl zeigen. Kollektorarchive würden zeigen, was externe Beobachtungspunkte erreichte. Aktive Messungen würden End-to-End-Pfadeffekte zeigen. Dienstbetreiber würden Datenverkehrs- und Anwendungsbelege halten.

Diese Kette verhindert eine vereinfachte Zuweisung der gesamten Verantwortung an eine einzige Stelle. AS12389 was der beobachtete falsche Ursprung und kontrollierte den ersten Export. Peers haben die Route nicht erstellt, aber Annahme und Verbreitung haben ihre Reichweite vergrößert. Präfix-Inhaber haben die Ankündigung nicht verursacht, aber ihre Autorisierungs- und Überwachungshaltung konnte die Erkennung und Ablehnung beeinflussen. Kein einzelner Teilnehmer kontrollierte das gesamte Internet, doch mehrere kontrollierten spezifische Punkte, an denen das Ereignis hätte verhindert, begrenzt oder erklärt werden können.

Pfadmessungen belegen Umleitung, nicht die Absicht des Abfangens

Beobachtungen der Steuerungsebene zeigen, welche Routen angekündigt wurden. Pfadmessungen liefern zusätzliche Belege darüber, wohin der Datenverkehr floss. ThousandEyes berichtete, dass einige Peers, darunter Cogent, Hurricane Electric und Tata, die AS12389-Ankündigungen akzeptierten und weiterverbreiteten. Seine Messungen für mindestens einen betroffenen E-Commerce-Dienst zeigten, dass der Datenverkehr in das Netzwerk von Rostelecom floss und später zum beabsichtigten Ziel weitergeleitet wurde. [1]

Diese Pfadform ist von Bedeutung. Sie stützt mehr als das theoretische Risiko, dass eine falsche Route Datenverkehr anziehen könnte. Sie deutet darauf hin, dass gemessener Produktivverkehr einem nicht autorisierten Transitpfad folgte. Der Pfad endete in dem genannten Beispiel nicht einfach bei AS12389; der Datenverkehr erreichte später das beabsichtigte Ziel. Dies steht im Einklang mit einer Umleitung gefolgt von einer Weiterleitung.

Die Messung stützt keine allgemeingültige Aussage. Nicht jedes Netzwerk akzeptierte oder bevorzugte die Route. ThousandEyes stellte fest, dass die Akzeptanz variierte. Ein von einem oder mehreren Messpunkten aus gesehener Pfad kann nicht zu einer Behauptung über alle Nutzer, alle Quellnetzwerke oder alle Pakete hochgerechnet werden. Routing-Entscheidungen variieren je nach Standort, Anbieter, Timing und Richtlinie.

Ebenso beweist die Weiterleitung keine Abfangung. Datenverkehr, der durch ein unbeabsichtigtes Netzwerk fließt, schafft die Möglichkeit zur Beobachtung oder Beeinflussung, aber eine Möglichkeit ist kein Beleg dafür, dass eine Inspektion stattgefunden hat. Die verfügbaren Pfaddaten zeigen weder Paketaufzeichnungen, Inhaltszugriffe, Änderungen, das Sammeln von Zugangsdaten noch Transaktionsmanipulationen. Sie identifizieren kein Abfangsystem oder einen Betreiber, der ein solches genutzt hat.

Verschlüsselung verkompliziert die Schadensbewertung weiter. Eine wirksame Verschlüsselung kann einschränken, was ein unbeabsichtigtes Transitnetzwerk lesen oder ändern kann, aber die öffentlichen Routing-Aufzeichnungen belegen nicht den Sicherheitsstatus jeder betroffenen Sitzung. Die Präsenz von Finanz- und zertifikatsbezogenen Diensten beweist weder, dass die Verschlüsselung fehlschlug, noch beweist sie, dass jede Verbindung korrekt geschützt war. Dienstseitige TLS-Aufzeichnungen, Sitzungstelemetrie und Paketbelege wären für eine spezifischere Schlussfolgerung erforderlich.

Der am sichersten belegbare Schaden ist daher der Verlust der beabsichtigten Pfadkontrolle und die vorübergehende Freilegung eines Teils des Datenverkehrs gegenüber einem nicht autorisierten Transitpfad. Dies ist eine reale Konsequenz für die Netzwerksicherheit, selbst ohne Beleg für eine Kompromittierung der Inhalte. Nutzer und Dienstbetreiber verlassen sich auf das Inter-Domain-Routing, um Datenverkehr über erwartete Erreichbarkeitsbeziehungen bereitzustellen. Ein falscher Ursprung kann diese Kontrollgrenze durchbrechen, während Anwendungsserver und verschlüsselte Sitzungen intakt bleiben.

Diese Unterscheidung schützt sowohl die Verantwortlichkeit als auch die Genauigkeit. Das Ereignis herunterzuspielen, weil kein Datendiebstahl nachgewiesen wurde, ignoriert die nachgewiesene Routenumleitung. Das Ereignis als Abfangung zu bezeichnen, weil der Datenverkehr Rostelecom passierte, behandelt eine mögliche Fähigkeit als vollendete Tat. Die Belege stützen die mittlere Position: Für den gemessenen Datenverkehr fand eine Umleitung statt; Inspektion, Entschlüsselung, Änderung und Ausnutzung bleiben unbekannt.

Vier Belegklassen halten die Zuweisung ehrlich

Das Ereignis lässt sich am besten anhand von vier Belegklassen verstehen: bestätigt, wahrscheinlich, umstritten und unbekannt. Das Vermischen dieser Klassen ist der Hauptweg von einer technischen Beobachtung zu einer unbegründeten Anschuldigung.

Zu den bestätigten Belegen gehören die Ursprungsbeobachtungen von AS12389, das Zeitfenster von 22:36 bis etwa 22:43 UTC, falsche Ankündigungen, einige spezifischere Routen, die Verbreitung durch mehrere Peers und gemessene Pfadänderungen. Die genannten Dienstkategorien und Beispiele sind ebenfalls belegt, wenn sie mit den Überwachungsberichten verknüpft werden. Diese Schlussfolgerungen hängen von verteilten Beobachtungen ab und nicht vom Zugriff auf die privaten Systeme von Rostelecom. [1][2]

Wahrscheinliche Erklärungen sollten unter Vorbehalt bleiben. Ein interner Routing- oder Konfigurationsfehler ist ein plausibler Kandidat für die Ursache. BGPMon beobachtete gleichzeitige Ankündigungen, die andere mit Rostelecom verbundene autonome Systeme betrafen – ein Muster, das die Hypothese eines breiteren internen Fehlers anstelle einer sorgfältig begrenzten externen Zielauswahl stützen kann. Die Belege belegen nicht die genaue Konfiguration, den Befehl oder das System, das versagt hat.

Umstrittene Interpretationen betreffen die gezielte Ausrichtung und Abfangabsicht. Die Konzentration von Finanz-, Zahlungs-, E-Commerce- und Sicherheitszielen in Kombination mit neu eingeführten spezifischeren Routen ließ das Muster für BGPMon und ThousandEyes verdächtig erscheinen. Verdacht ist relevant, da er die Reaktion auf Vorfälle und die Beweissicherung beeinflusst. Er ist kein Beleg für eine Absicht.

Zu den Unbekannten gehören die Frage, wer die Änderung initiiert hat, ob diese Person autorisiert war, der genaue interne Mechanismus, der Grund für die ausgewählten Präfixe, ob Pakete inspiziert wurden, ob Inhalte entschlüsselt wurden, ob Transaktionen betroffen waren, ob Nutzer Daten oder Geld verloren haben, die gesamte betroffene Population unter einer gemeinsamen Messmethode und welche dauerhaften Abhilfemaßnahmen ergriffen wurden.

CERT-EU und ENISA nutzten später in ihren institutionellen Diskussionen eine stärkere bedrohungsanalytische Rahmung. Diese Bewertungen verdienen eine genaue Zuweisung, da öffentliche Stellen vergangene Vorfälle nutzen, um Routing-Risiken zu erklären. Ihre Rahmung schafft jedoch keinen Zugang zu den AS12389-Änderungsprotokollen oder den Paketaufzeichnungen betroffener Dienste. Eine spätere, kategorische Einstufung sollte nicht als neuer primärer Beleg für die Absicht eines Betreibers im Jahr 2017 behandelt werden. [4]-[6]

Der Jahresrückblick der Internet Society zur Routing-Sicherheit ordnet die Episode in ein weitaus größeres Muster von Routing-Vorfällen und Präventionsbedenken ein. Dieser Kontext hilft zu zeigen, warum der Fall über einen einzelnen Betreiber hinaus von Bedeutung ist. Er sollte das Ereignis nicht zu einer allgemeinen Statistik verflachen oder seine ungelösten Zuweisungsfragen beantworten. [3]

Eine Belegleiter verdeutlicht, was eine stärkere Wortwahl rechtfertigen würde. Verteilte Routen-Aktualisierungen können eine falsche Routenentstehung nachweisen. Verbreitungsdaten aus mehreren Blickwinkeln können die Reichweite belegen. Aktive Pfadmessungen können die Umleitung von bestimmten Messpunkten aus belegen. Dienstprotokolle können empfangene Verbindungen, den TLS-Status und Anwendungseffekte belegen. Paketaufzeichnungen können Datenverkehrsinhalte und Änderungen in ihrem Rahmen belegen. Änderungs- und Authentifizierungsprotokolle des Betreibers können interne Aktionen identifizieren.

Eine Ursachenanalyse kann diese Aufzeichnungen mit Verantwortung und Absicht verknüpfen.

Die öffentlichen Aufzeichnungen vom April 2017 erreichen für Teile des Ereignisses die ersten drei Ebenen. Die späteren Ebenen erreichen sie nicht. Diese Grenze erlaubt eine klare betriebliche Verantwortlichkeit, ohne ein unbelegtes Motiv zuzuweisen. Rostelecom kann dafür verantwortlich gemacht werden, Routen zu erklären, die von AS12389 ausgingen und exportiert wurden, selbst wenn eine absichtliche gezielte Ausrichtung unbewiesen ist. Peers können aufgefordert werden, die Annahme und Verbreitung zu erklären, selbst wenn sie die Routen nicht erstellt haben.

Präfix-Inhaber können zu Autorisierung und Überwachung befragt werden, ohne zu implizieren, dass sie den Vorfall verursacht haben.

Zuweisungsbelege sollten zudem symmetrisch sein. Belege, die eine feindselige Hypothese stützen, sollten aufbewahrt werden, einschließlich der Zielkonzentration und spezifischerer Ankündigungen. Belege, die die Hypothese eines unabsichtlichen Fehlers stützen, sollten ebenfalls aufbewahrt werden, einschließlich der Ankündigungen, die verwandte autonome Systeme betrafen. Eine glaubwürdige Darstellung erklärt, warum eine Hypothese letztendlich besser passt, oder stellt fest, dass die verfügbaren Aufzeichnungen keine Entscheidung zulassen.

Diese Disziplin ist keine Unentschlossenheit. Sie weist eine klare Verantwortung für beobachtbare Handlungen zu, während sie sich weigert, den mentalen Zustand dahinter zu erfinden. Bei Routing-Vorfällen ist dies oft der Unterschied zwischen einer verantwortungsvollen Analyse und geopolitischem Storytelling.

AS12389 kontrollierte die aussagekräftigsten internen Belege

Rostelecom kontrollierte als Betreiber von AS12389 das system, das externe Beobachter bei der Entstehung und dem Export der Routen sahen. Das beweist nicht, dass die Unternehmensleitung das Ereignis angeordnet hat oder dass eine Einzelperson absichtlich gehandelt hat. Es identifiziert jedoch die Organisation, die dem Routengenerierungsprozess am nächsten stand, und die Belege, die am ehesten in der Lage sind, diesen zu erklären.

Die relevanten Kontrollen beginnen vor dem Export. Berechtigungen zur Routengenerierung bestimmen, welche Konten, Systeme und Workflows ein Präfix in den Routing-Prozess einführen können. Eine Änderungsüberprüfung kann eine zweite Prüfung bei sensiblen oder ungewöhnlich breiten Änderungen erfordern. Präfix-Erlaubnislisten können Kunden- und Infrastrukturankündigungen auf den erwarteten Adressraum beschränken. Egress-Richtlinien können eine Route stoppen, die das autonome System nicht verlassen sollte. Überwachung kann einen unerwarteten Ursprung oder eine plötzliche Reihe spezifischerer Ankündigungen erkennen.

Rücknahmeverfahren können die Freilegung nach der Erkennung verkürzen.

Dies sind Kontrollkategorien, keine Behauptungen über die genaue Konfiguration von AS12389 im April 2017. Die öffentlichen Aufzeichnungen zeigen nicht, welche Kontrollen existierten, welche versagten oder welche umgangen wurden. Sie zeigen auch nicht, ob der Routensatz auf einen manuellen Befehl, Automatisierung, eine Kundensitzung, einen internen Weiterverteilungsfehler, kompromittierte Zugangsdaten oder einen anderen Mechanismus zurückzuführen ist.

Die Belege des Betreibers sollten die Kategorien miteinander verknüpfen. Der Konfigurationsverlauf könnte zeigen, was sich geändert hat. Authentifizierungsdatensätze könnten zeigen, welches Konto oder System die Änderung vorgenommen hat. Genehmigungsaufzeichnungen könnten zeigen, ob sie autorisiert war. BGP-Sitzungs- und Exportprotokolle könnten zeigen, welche Routen an welche Nachbarn gesendet wurden. Alarmprotokolle könnten zeigen, wann das Personal zum ersten Mal davon erfuhr. Vorfallberichte könnten zeigen, wer die Rücknahme angeordnet hat und wie der betroffene Satz bestimmt wurde.

Geschwindigkeit allein reicht nicht aus. Die Ankündigungen wurden nach einem kurzen Zeitfenster zurückgenommen, aber eine Dauer von sieben Minuten verrät nicht, ob die Überwachung funktionierte, ein Peer Alarm schlug, ein Betreiber einen Fehler bemerkte oder der ursprüngliche Zustand automatisch endete. Ein schnelles Ende verringert die Freilegung; es erklärt nicht die Erkennung oder die Wirksamkeit der Kontrollen.

Die Offenlegung ist der letzte Kontrollpunkt des Ursprungsbetreibers. Eine nützliche öffentliche Darstellung des Vorfalls würde beobachtete Routenfakten von den Ergebnissen des Betreibers zur Ursachenanalyse unterscheiden. Sie würde den betroffenen Exportrahmen nennen, erklären, ob die Präfixe durch Konfiguration, Automatisierung, einen Kunden oder eine andere Routenquelle eingeführt wurden, die versagte Kontrolle beschreiben, die Eindämmung darstellen und begrenzte Belege für die Behebung liefern. Sie muss weder Zugangsdaten, kundenvertrauliche Topologien noch ausnutzbare Details offenlegen.

Ohne diese Darstellung können externe Beobachter zwar die betriebliche Verantwortung für Ursprung und Export zuweisen, aber sie können keine persönliche Verantwortung, Absicht oder interne Fehlerzuweisung verlässlich zuordnen. Die Asymmetrie der Belege ist selbst eine Tatsache der Verantwortlichkeit: Die Organisation, die den Routenprozess kontrollierte, kontrollierte auch die Aufzeichnungen, die zur Lösung der folgenreichsten Ungewissheit erforderlich waren.

Ein Betreiber kann diese Lücke nicht schließen, indem er darauf verweist, dass BGP verteilt ist. Verteilung bedeutet, dass AS12389 nicht kontrollierte, welche entfernten Netzwerke die Route akzeptierten. Sie hebt nicht die Kontrolle darüber auf, was AS12389 erstellte und exportierte. Umgekehrt hebt die Verortung des falschen Ursprungs bei AS12389 nicht die Rolle der Nachbarn auf, die ihn verbreiteten. Die praktische Verantwortung folgt jedem Kontrollpunkt, anstatt die gesamte Kette auf einen einzigen Akteur zu reduzieren.

Akzeptierende Peers kontrollierten die Verbreitungsgrenze des Ereignisses

Ein falscher Ursprung wird erst dann weitreichend folgenreich, wenn andere Netzwerke ihn akzeptieren und verbreiten. ThousandEyes beobachtete unter anderem Cogent, Hurricane Electric und Tata unter den Peers, die AS12389-Ankündigungen übertrugen. Diese Beobachtung zeigt nicht die vollständige Richtlinie oder den Entscheidungsprozess innerhalb eines der genannten Netzwerke. Sie zeigt jedoch, dass die Akzeptanz durch Peers Teil des Pfades vom Ursprung bis zur gemessenen Umleitung war. [1]

Die Verantwortlichkeitsfrage des Peers unterscheidet sich von der von Rostelecom. Ein akzeptierendes Netzwerk wusste bei der Ankunft einer Route nicht zwangsläufig, dass diese falsch war, und es hat den ursprünglichen Anspruch nicht erstellt. Dennoch kontrollierte es die lokale Importrichtlinie, Kunden- und Peerfilter, die Nutzung von Routenautorisierungsdaten, die Anomaliewarnung, den weiteren Export und die Notfallkoordination.

Filterpflichten müssen anhand von Belegen beschrieben werden, anstatt sie aus einer kommerziellen Bezeichnung abzuleiten. Ein Netzwerk kann einen Nachbarn im Rahmen seiner eigenen Richtlinien als Kunden, Peer oder Transitdienstleister behandeln. Die öffentlichen Beobachtungen legen diese Verträge oder die Importregeln jeder Sitzung nicht offen. Sie zeigen auch nicht, ob eine Route passierte, weil kein Filter existierte, eine Erlaubnisliste zu breit war, Registerdaten unvollständig waren, ein Validierungssignal nicht verfügbar war oder die lokale Richtlinie eine Warnung akzeptierte.

RFC 7454, NIST SP 800-189 und die MANRS-Betreibermaterialien bieten Kontrollreferenzen für Filterung, Koordination und belastbaren Routenaustausch. Sie stützen die Erwartung, dass Netzwerke wissen sollten, welche Routen ein Nachbar ankündigen darf, unplausible Ankündigungen ablehnen sollten, sofern zuverlässige Informationen dies zulassen, Anomalien überwachen und Kontaktpfade für eine schnelle Korrektur pflegen sollten. Sie weisen nicht nach, dass ein bestimmter Peer im April 2017 eine spezifische Pflicht verletzt hat. Diese Schlussfolgerung würde die historischen Richtlinien-, Routenauswahl- und Alarmprotokolle des Peers erfordern.

[10][15]-[17]

Die Verbreitung schafft eine proportionale Nachweispflicht. Ein Peer, der eine unerwartete spezifischere Route übertragen hat, sollte in der Lage sein zu zeigen, was er empfangen hat, welche Validierung oder Filter gelaufen sind, welche lokale Präferenz sie ausgewählt hat, wohin er die Route exportiert hat und wann er sie zurückgezogen hat. Aufbewahrte Belege ermöglichen eine spätere Unterscheidung zwischen einer unvermeidbaren Einschränkung der verfügbaren Autorisierungsdaten und einem kontrollierbaren Richtlinienfehler.

Die gleichen Belege können eine ungerechtfertigte Schuldzuweisung verhindern. Ein Peer kann nachweisen, dass keine anwendbare ROA existierte, dass die Registerdaten keinen ausreichend engen Kundensatz definierten, dass er die Route im Rahmen einer dokumentierten Richtlinie akzeptierte oder dass er nach einer Warnung umgehend den Kurs änderte. Alternativ können Aufzeichnungen zeigen, dass eine bekannte Einschränkung fehlte oder ignoriert wurde. Öffentliche Routenbeobachtungen identifizieren die zu befragenden Netzwerke; sie liefern nicht die vollständige Antwort.

Verteiltes Routing führt daher zu verteilter Verantwortlichkeit. AS12389 trägt die Verantwortung für den falschen Ursprung und den Export. Akzeptierende Netzwerke tragen die Verantwortung für die Kontrollen an ihren eigenen Grenzen. Diese Verantwortlichkeiten überschneiden sich in ihrer Wirkung, ohne in ihrer Ursache identisch zu werden.

Präfix-Inhaber und unabhängige Monitore kontrollierten unterschiedliche Formen der Bereitschaft

Die Organisationen, deren Adressraum im betroffenen Satz auftauchte, haben die Ankündigungen von AS12389 nicht verursacht. Ihre Verantwortung betrifft die Vorbereitung, Erkennung, Eskalation und dienstseitige Beweissicherung, nicht die Schuld am Ursprung.

Präfix-Inhaber können genaue Routing- und Autorisierungsdaten pflegen, eine externe Ursprungsüberwachung einrichten, Eskalationskontakte für Anbieter definieren und Dienstbelege sichern, wenn ein Alarm auftritt. Soweit betrieblich geeignet, können sie erwägen, eine abmildernde spezifischere Route über legitime Anbieter anzukündigen. Jede Abmilderung muss sorgfältig geprüft werden, da während eines Vorfalls vorgenommene Routenänderungen neue Erreichbarkeitsprobleme verursachen können.

Der historische Kontext ist wesentlich. Das Ereignis fand vor der breiten Durchsetzung der Route Origin Validation statt. Die verfügbaren Aufzeichnungen belegen nicht, welche betroffenen Präfixe im April 2017 gültige ROAs hatten, welche Maximallängen diese ROAs autorisierten oder welche empfangenden Netzwerke die Validierung nutzten. Es wäre daher falsch, das Fehlen einer universellen Ablehnung als Beweis dafür zu werten, dass jeder Präfix-Inhaber RPKI vernachlässigt oder jeder Peer ein verfügbares ungültiges Signal ignoriert hat.

Überwachungsorganisationen kontrollierten einen anderen Kontrollpunkt: die Qualität der externen Belege. BGPMon lieferte ein begrenztes Ereigniszeitfenster, eine Zählung betroffener Präfixe, einen Nenner von 37 autonomen Systemen, ein spezifischeres Beispiel und konkurrierende Hypothesen zur Absicht. ThousandEyes lieferte seinen Beobachtungsrahmen von 137 Präfixen, die Klassifizierung, die zu 36 Präfixen außerhalb des Unternehmens führte, Beobachtungen zur Peer-Verbreitung, Beispiele für betroffene Dienste und gemessene Pfade. [1][2]

Diese Aufzeichnungen sind am aussagekräftigsten, wenn ihre Beobachtungspunkte, Zeitgrenzen und Klassifizierungsmethoden reproduzierbar bleiben. Der Datenzugriff auf BGPStream von CAIDA und die historische Rekonstruktion von Moriano und Co-Autoren veranschaulichen, wie archiviertes Route Views- und RIPE RIS-Material spätere Analysen stützen kann. Eine spätere Rekonstruktion muss dennoch angeben, welche Kollektoren und Aktualisierungsintervalle verwendet und wie die Präfixe gruppiert wurden. [7][8]

Unabhängige Monitore haben zudem eine Pflicht zur sprachlichen Sorgfalt. Sie können eine verdächtige Auswahl beschreiben und erklären, warum spezifischere Routen Anlass zur Sorge geben. Sie sollten separat angeben, ob sie über Belege für den Zweck, den internen Zugriff oder das Abfangen von Inhalten verfügen. Diese Trennung ermöglicht es einem Monitor, Betreiber schnell zu warnen, ohne einen Anomaliewert in ein Zuweisungsurteil zu verwandeln.

Betroffene Dienstbetreiber halten die Belege, die zur Bewertung des nachgelagerten Schadens erforderlich sind. Datenverkehrsprotokolle können Verschiebungen bei den Verbindungen zeigen. TLS-Aufzeichnungen können zeigen, ob Sitzungen sicher abgeschlossen wurden. Anwendungs- und Transaktionsdaten können Fehler, Betrug oder das Ausbleiben wesentlicher Auswirkungen zeigen. Kundenberichte können Geografie und Dauer identifizieren. Keine dieser Aufzeichnungen kann allein aus Routen-Aktualisierungen verlässlich rekonstruiert werden.

Die praktische Aufteilung ist klar. Präfix-Inhaber kontrollieren Bereitschaft und Eskalation. Unabhängige Monitore kontrollieren die externe Beobachtung und Analyse. Dienstbetreiber kontrollieren die Belege für Anwendungs- und Kundeneffekte. Jeder kann einen anderen Teil der Vorfalldokumentation schließen, und niemand sollte behaupten, dass die Belege einer anderen Partei überflüssig sind.

RPKI kann falsche Ursprünge einschränken, aber nicht über das Motiv entscheiden

RPKI ist zentral für die Kontrolldiskussion, da das Ereignis einen falschen Ursprung betraf. Seine Rolle muss präzise formuliert werden. Die RPKI-Architektur stützt kryptografisch verifizierbare Aussagen über Internet-Nummernressourcen. Eine Route Origin Authorization identifiziert ein autonomes System, das autorisiert is, bestimmte Präfixe innerhalb des Rahmens des Objekts anzukündigen. Die Route Origin Validation ermöglicht es einem empfangenden Netzwerk, eine BGP-Ursprungsankündigung mit den verfügbaren Autorisierungsdaten zu vergleichen. [11]-[14][18]

Dieser Mechanismus kann einem Netzwerk nützliche Belege dafür liefern, dass ein beobachteter Ursprung nicht mit einer abdeckenden Autorisierung übereinstimmt. Wenn ein betroffenes Präfix im April 2017 eine entsprechende ROA hatte und ein empfangendes Netzwerk eine Validierung durchführte, hätte ein AS12389-Ursprung ein Signal erzeugen können, das die Richtlinie ablehnen oder de-priorisieren könnte. Das tatsächliche Ergebnis würde von der historischen Autorisierung, der Präfixlänge, den Validierungsdaten und der lokalen Routing-Richtlinie abhängen.

Es ergeben sich mehrere Grenzen.

Erstens beweist RPKI keine Absicht. Eine Route kann die Ursprungsvalidierung aufgrund einer feindseligen Ankündigung, eines Betreiberfehlers, einer veralteten Autorisierung, einer falsch dimensionierten ROA oder einer anderen Abweichung nicht bestehen. Das Signal betrifft die Autorisierung des Ursprungs, nicht den Geisteszustand oder die Identität der Person hinter der Aktualisierung.

Zweitens erklärt die Ursprungsvalidierung nicht den internen Auslöser. Sie kann einen Konflikt an einer Empfangsgrenze identifizieren, lässt jedoch unbeantwortet, ob die Route aus manueller Konfiguration, Automatisierung, einer Kundensitzung, einem kompromittierten Zugriff oder einem unbeabsichtigten Weiterverteilungspfad stammte.

Drittens validiert RPKI für sich genommen nicht den vollständigen AS-Pfad. Eine autorisierte Ursprungserklärung ist kein kryptografischer Beweis dafür, dass jede Transitbeziehung oder jedes Pfadsegment legitim ist. Die Klassifizierung von Route Leaks nach RFC 7908 und die Filterrichtlinien nach RFC 7454 befassen sich mit breiteren richtlinienbezogenen und betrieblichen Belangen, die nicht auf eine einzige Ursprungsprüfung reduziert werden können. [9][10]

Viertens erfordert eine retrospektive Behauptung retrospektive Daten. Die heutige RPKI-Abdeckung, Validierungspraxis oder Registerführung kann nicht ohne Belege auf die Vergangenheit projiziert werden. Die relevanten Fragen sind, welche betroffenen Präfixe am 26. April 2017 geeignete ROAs hatten, welche Präfixlängen sie autorisierten, welche Validierungsdaten jeder Peer erhielt und wie jeder Peer den resultierenden Zustand behandelte.

Fünftens ist eine Kontrolle nur so nützlich wie ihre betriebliche Integration. Autorisierungsdatensätze müssen genau sein und gepflegt werden. Validatoren und Datenverteilung müssen überwacht werden. Die Routing-Richtlinie muss definieren, was passiert, wenn ein Signal vorhanden oder abwesend ist. Betreiber benötigen Ausnahme-, Rollback- und Notfallkontaktverfahren. Die MANRS- und NIST-Richtlinien ordnen Filterung, Validierung, Koordination und globale Routing-Hygiene in eine breitere betriebliche Praxis ein, anstatt RPKI als vollständige Antwort darzustellen. [15]-[17]

Diese Einschränkungen schwächen die Argumente für die Sicherheit des Routenursprungs nicht. Sie verdeutlichen, was die Kontrolle beweisen kann. RPKI kann das Vertrauen in unauthentifizierte Ursprungsansprüche verringern und empfangenden Netzwerken helfen, eine fundiertere Entscheidung zu treffen. Es kann nicht bestimmen, warum AS12389 die Routen angekündigt hat, ob der Datenverkehr inspiziert wurde oder wer die gesamte Verantwortung tragen sollte.

Der Fall vom April 2017 ist daher ein Argument für mehrschichtige Kontrollen. Ursprungsautorisierungen können die Annahme einschränken. Präfixfilter können einschränken, was ein Nachbar exportiert. Die Überwachung von spezifischeren Routen und Ursprungsänderungen kann die Erkennungszeit verkürzen. Die Peer-Koordination kann die Rücknahme beschleunigen. Aktive Messungen können die Pfadauswirkungen zeigen. Dienstprotokolle können den Schaden bewerten. Betreiberaufzeichnungen können die Ursache erklären.

Keine Ebene liefert die gesamte Darstellung. Das stärkste institutionelle Design sorgt dafür, dass die Ebenen Belege erzeugen, die nach einem Ereignis abgeglichen werden können.

Standards der Routing-Sicherheit schaffen Pflichten zur Fähigkeit, keine rückwirkenden Urteile

Standards und Best-Practice-Dokumente sind hier am nützlichsten als Kontrollpläne. RFC 7908 liefert ein Vokabular für Route Leaks. RFC 7454 befasst sich mit operativer BGP-Sicherheit und Filterung. RFC 6811 und RFC 7115 beschreiben die Ursprungsvalidierung und deren operativen Einsatz. RFC 6480 und RFC 6482 definieren die RPKI- und ROA-Grundlagen. NIST SP 800-189 und MANRS verknüpfen Filterung, Validierung, Koordination und Überwachung mit einem belastbaren Inter-Domain-Betrieb. RIPE NCC erklärt die BGP-Ursprungsvalidierung und ihre Grenzen. [9]-[18]

Zusammen stützen sie institutionelle Pflichten, die messbar sind, ohne eine Rechtsverletzung im Jahr 2017 zu behaupten. Ein Ursprungsnetzwerk sollte einschränken, welche Präfixe es erstellen und exportieren kann. Ein empfangendes Netzwerk sollte angemessene Importkontrollen unterhalten und zuverlässige Autorisierungsdaten verwenden, sofern verfügbar. Ein Präfix-Inhaber sollte genaue Aufzeichnungen führen und unerwartete Ursprünge überwachen. Betreiber sollten Protokolle und Kontakte aufbewahren, die eine schnelle Rücknahme und spätere Erklärung ermöglichen.

Die Pflichten sind Fähigkeiten, keine Slogans. „Wir nutzen RPKI“ ist unvollständig ohne die historische ROA, den Validierungsstatus und die lokale Reaktion. „Wir filtern Kunden“ ist unvollständig ohne den zulässigen Präfixsatz und den Nachweis, dass der Filter lief. „Wir überwachen BGP“ ist unvollständig ohne Alarmschwellen, Zeitstempel und Eskalation. „Die Route wurde zurückgezogen“ ist unvollständig ohne das Erkennungs- und Entscheidungsprotokoll.

Die Dokumente belegen nicht, dass Rostelecom oder ein genannter Peer während des Ereignisses eine bestimmte Kontrolle versäumt hat. Dies würde einen Vergleich zwischen den historischen Anforderungen, der tatsächlichen Architektur des Betreibers und den Vorfallsbelegen erfordern. Heutige Standards können dennoch die Fragen definieren, die eine verantwortliche Institution nun beantworten können sollte.

Dieser Ansatz vermeidet zwei Fehler. Der eine ist der technologische Fatalismus, bei dem das verteilte Design von BGP zu einem Grund wird, warum niemand verantwortlich sein kann. Der andere ist die technologische Gewissheit, bei der eine moderne Kontrolle zu einer garantierten historischen Prävention erklärt wird. Die Belege stützen keines von beiden.

Institutionelle Verantwortlichkeit fragt stattdessen, ob jeder Akteur seine Kontrolle an dem Punkt nachweisen konnte, den er besaß. Dieser Standard bleibt gültig, selbst wenn das globale System keinen zentralen Betreiber hat und das ursprüngliche Motiv ungelöst ist.

Schaden sollte gemessen werden, ohne eine Verletzung zu erfinden

Der betroffene Satz umfasste Finanz-, Zahlungs-, E-Commerce-, Websicherheits- und zertifikatsbezogene Dienste. Berichte nannten unter anderem Mastercard, Visa, BNP Paribas, HSBC, Symantec und GeoTrust als Beispiele für die betroffenen Präfixe. Diese Namen erklären, warum Beobachter das Muster ernst nahmen. Sie beweisen keine Kompromittierung der Organisationen oder ihrer Kunden. [1][2]

Der bestätigte Schaden ist ein Routing-Schaden. Ein Teil des Datenverkehrs verlor seinen beabsichtigten Pfad und passierte ein nicht autorisiertes Transitnetzwerk. Das änderte die Vertrauensgrenze für die betroffenen Verbindungen und verringerte die Kontrolle der Präfix-Inhaber darüber, wie Nutzer ihre Dienste erreichten.

Mögliche sekundäre Schäden erfordern separate Belege. Transaktionsbetrug würde Transaktionsaufzeichnungen erfordern. Der Diebstahl von Zugangsdaten würde Authentifizierungs-, Nutzer- oder forensische Belege erfordern. Eine TLS-Kompromittierung würde Sitzungs- und Zertifikatsbelege erfordern. Eine Datenänderung würde Paket-, Anwendungs- oder Integritätsaufzeichnungen erfordern. Ein Ausfall würde Verfügbarkeitsmessungen erfordern, die mit betroffenen Nutzern verknüpft sind. Finanzieller Schaden würde Verlustaufzeichnungen und eine Kausalitätsanalyse erfordern.

Keine derartige Schlussfolgerung ergibt sich allein daraus, dass eine Route AS12389 passierte. Die Weiterleitung kann es ermöglichen, dass der Dienst verfügbar bleibt, und Verschlüsselung kann lesbare Inhalte einschränken. Keine der beiden Tatsachen beseitigt das Risiko. Keine beweist die Sicherheit für jede Verbindung.

Die Schadensberichterstattung sollte daher eine mehrschichtige Skala verwenden. Der Verlust der Routenkontrolle ist nachgewiesen. Die Freilegung gegenüber einem unbeabsichtigten Transitpfad ist für den gemessenen Datenverkehr nachgewiesen. Die Sichtbarkeit von Inhalten ist möglich, aber unbewiesen. Aktives Abfangen ist umstritten und unbewiesen. Datenkompromittierung, Transaktionseffekte und Verluste sind unbekannt.

Diese Skala gibt den betroffenen Organisationen Raum für eine ehrliche Berichterstattung. Sie können ein schwerwiegendes Netzwerkkontrollereignis anerkennen, während die Untersuchungen andauern. Später können sie dienstseitige Ergebnisse hinzufügen, ohne die Routing-Beobachtungen umzuschreiben. Wenn kein Anwendungsschaden festgestellt wird, sollte dieses Ergebnis als Beleg im untersuchten Rahmen gemeldet werden und nicht als Beweis dafür, dass der falsche Ursprung harmlos war.

Die gleiche Disziplin gilt für öffentliche Stellen und Forscher. Eine starke Bedrohungsrahmung kann zu besseren Kontrollen motivieren, sollte jedoch Kategorien möglicher Schäden nicht in Fakten des Vorfalls verwandeln. Die Glaubwürdigkeit der Routing-Sicherheitsarbeit hängt von der Einhaltung dieser Grenze ab.

Offenlegung sollte Kontrollfragen beantworten, selbst wenn die Zuweisung ungelöst bleibt

Ein Vorfallsbericht muss keinen feindseligen Akteur identifizieren, um nützlich zu sein. Er kann angeben, was der Betreiber über die Erstellung, den Export, die Verbreitung, die Erkennung und die Rücknahme von Routen weiß, während das Motiv als ungelöst gekennzeichnet wird.

Für AS12389, die minimal nützliche Darstellung die Quellklasse der Ankündigungen, den Routensatz und den Exportrahmen, den Erkennungskanal, die Rücknahmeentscheidung, den betroffenen Zeitraum und die danach vorgenommenen Kontrolländerungen identifizieren. Sie könnte erklären, ob das Ereignis Konfiguration, Automatisierung, Kundeneingaben oder einen anderen internen Mechanismus beinhaltete, ohne sensible Befehle oder Zugangsdaten offenzulegen.

Akzeptierende Netzwerke könnten offenlegen, ob die Routen als Kunden-, Peer- oder Transitankündigungen behandelt wurden; ob Präfix-, Ursprungs- oder Pfadprüfungen angewendet wurden; ob historische RPKI-Daten ein nutzbares Signal lieferten; und wie die Routen entfernt wurden. Präfix-Inhaber könnten offenlegen, wann sie alarmiert wurden, welche Anbieter sie kontaktierten und ob dienstseitige Belege messbare Kundeneffekte zeigten.

Die von Monitoren bereitgestellten öffentlichen Aufzeichnungen trennen bereits einige Fakten von Interpretationen. BGPMon und ThousandEyes dokumentierten das Timing, die Routensätze, spezifischere Routen, die Verbreitung und Pfadeffekte und diskutierten anschließend, warum das Zielmuster verdächtig erschien. BGPMon bewahrte zudem Belege auf, die die Hypothese eines unabsichtlichen Fehlers stützen. [1][2]

Dies ist das Modell für eine verantwortungsvolle Ungewissheit. Ein Bericht sollte verdächtige Belege nicht verbergen, um Reputationsrisiken zu vermeiden. Er sollte Verdacht nicht als Absicht darstellen. Er sollte die Aufzeichnungen nennen, die das Problem lösen würden, und angeben, ob diese Aufzeichnungen untersucht wurden.

Die Offenlegung benötigt zudem einen dauerhaften Nachweis der Behebung. Die Aussage, dass Routen zurückgezogen wurden, beschreibt die Eindämmung. Sie zeigt nicht, dass sich Berechtigungen geändert, Filter verengt, Alarme verbessert, Protokolle aufbewahrt oder die Peer-Koordination getestet wurde. Behebungsbelege sollten die fehlgeschlagene Kontrolle, die Änderung, den Test und das Überwachungsergebnis identifizieren.

Institutionen haben unterschiedliche Offenlegungsbeschränkungen. Betreiber können sicherheitssensible und kundenvertrauliche Informationen schützen. Finanz- und Sicherheitsdienstleister können die Offenlegung von Datenverkehrsmustern vermeiden. Peers können Richtlinien als kommerziell sensibel behandeln. Diese Einschränkungen rechtfertigen Aggregation und Schwärzung, jedoch keine belegfreie Schlussfolgerung.

Das öffentliche Interesse ist an der Grenze zwischen bestätigtem Betrieb und behauptetem Zweck am größten. Eine klare Darstellung kann besagen, dass AS12389 falsche Routen erstellte, Peers einige davon verbreiteten und gemessener Datenverkehr den Pfad änderte. Sie kann auch besagen, dass eine gezielte Ausrichtung, Abfangung und Spionage nicht nachgewiesen sind. Diese Kombination ist verantwortungsvoller als entweder Leugnung durch Unbestimmtheit oder Anschuldigung durch Schlussfolgerung.

Belege, die die Bewertung ändern könnten

Mehrere Aufzeichnungen könnten Teile der aktuellen Bewertung wesentlich untermauern, eingrenzen oder umkehren.

Der Konfigurationsverlauf von AS12389 könnte die genaue Routenquelle und -änderung identifizieren. Authentifizierungs- und Autorisierungsprotokolle könnten das beteiligte Konto oder System identifizieren und zeigen, ob die Aktion einem genehmigten Workflow folgte. Export- und BGP-Sitzungsaufzeichnungen könnten feststellen, welche Nachbarn welche Ankündigungen erhielten. Alarm- und Vorfallreaktionsprotokolle könnten zeigen, wie das Ereignis erkannt wurde und warum die Rücknahme erfolgte.

Ein Ursachenbericht von Rostelecom könnte diese Aufzeichnungen verknüpfen, Fehler von unbefugten Aktionen unterscheiden und die Behebung dokumentieren. Seine Glaubwürdigkeit würde von der Methode, der Beweissicherung und der Frage abhängen, ob konkurrierende Hypothesen untersucht wurden. Eine bloße Behauptung eines Unfalls oder Angriffs würde die Zuweisungsfrage nicht lösen.

Die Filter-, Validierungs- und Auswahllogs akzeptierender Peers könnten zeigen, warum bestimmte Routen passierten. Historische Richtlinien-Snapshots könnten eine fehlende Kontrolle von fehlenden Autorisierungsdaten unterscheiden. Exportaufzeichnungen könnten die Verbreitungsgrenze zeigen, während Kontakt- und Ticketaufzeichnungen zeigen könnten, wann Peers die Rücknahme koordinierten.

Eine reproduzierbare Reanalyse der archivierten RIPE RIS- und Route Views-Aktualisierungen könnte die Zählrahmen von BGPMon und ThousandEyes abgleichen oder erklären, warum sie sich unterscheiden. Sie könnte zudem die Verbreitung über Zeit und Beobachtungspunkte hinweg abbilden. Die Analyse würde deklarierte Kollektoren, Zeitstempel, Deduplizierungs- und Präfixklassifizierungsmethoden erfordern. [7][8]

Historische ROA-Aufzeichnungen für jedes betroffene Präfix könnte zeigen, ob die Ursprungsvalidierung zu diesem Zeitpunkt ein nützliches Ergebnis geliefert hätte. Die Analyse würde den relevanten autorisierten Ursprung, das Präfix und den maximalen Längenbereich erfordern, zusammen mit Belegen darüber, welche Validierungsdaten jedes empfangende Netzwerk hatte und wie seine lokale Richtlinie reagierte.

Dienstseitige Datenverkehrs-, TLS-, Authentifizierungs-, Anwendungs- und Transaktionsprotokolle könnten feststellen, ob umgeleitete Verbindungen erfolgreich abgeschlossen wurden, fehlschlugen oder verdächtige Effekte zeigten. Paketaufzeichnungen könnten direktere Belege innerhalb ihres begrenzten Rahmens und Aufbewahrungszeitraums liefern. Vorfall- und Verlustprotokolle von Kunden könnten technische Effekte mit Personen oder Organisationen verknüpfen.

Belege dafür, dass der gemessene Pfad keinen Produktivverkehr übertrug, würden die Schadensschlussfolgerung einschränken. Belege für Paketinspektion, -änderung oder die Nutzung von Zugangsdaten würden sie erweitern. Belege für eine absichtliche, authentifizierte Routenänderung, die mit einem verantwortlichen Akteur verknüpft ist, würden die Zuweisungsbewertung wesentlich verändern. Belege für einen internen Fehler und eine getestete Korrekturkontrolle würden die Erklärung eines unabsichtlichen Fehlers untermauern.

Bis solche Aufzeichnungen verfügbar sind, sollte die Schlussfolgerung begrenzt bleiben. Ankündigungen von AS12389 und Pfadumleitungen sind bestätigt. Ein Routing- oder Konfigurationsfehler ist plausibel. Eine gezielte Ausrichtung, Abfangung und die Identität des Akteurs sind ungelöst. Datenkompromittierung und Verluste sind unbewiesen.

Verantwortlichkeit beginnt dort, wo die Belege kontrolliert werden

Das Ereignis vom April 2017 ist nicht primär eine Geschichte darüber, ob eine alarmierende Bezeichnung eine andere besiegt. Es ist ein test des wie Verantwortung in einer Infrastruktur zugewiesen wird, die bauartbedingt verteilt ist.

Rostelecom kontrollierte die Routenerstellung, die Exportrichtlinien und die internen Aufzeichnungen, die der Ursache am nächsten lagen. Akzeptierende Peers kontrollierten Filter, Validierung, Verbreitung und ihre eigenen Belege. Präfix-Inhaber kontrollierten Autorisierungsdaten, Überwachung und Eskalation. Unabhängige Monitore kontrollierten die externe Beobachtung und die analytische Transparenz. Betroffene Dienste kontrollierten die Belege für Kunden- und Anwendungseffekte.

Kein Akteur kontrollierte den gesamten Pfad. Jeder kontrollierte einen Kontrollpunkt, an dem Vorbeugung, Begrenzung, Erkennung oder Erklärung möglich war. Das reicht für eine betriebliche Verantwortlichkeit aus, selbst wenn das Motiv unbekannt bleibt.

Das Ereignis zeigt auch, warum RPKI als begrenzte Kontrolle behandelt werden muss. Ursprungsautorisierungen können empfangenden Netzwerken helfen, das Vertrauen in einen falschen Ursprung abzulehnen oder zu verringern, wenn die historischen Daten und Richtlinien dieses Ergebnis stützen. Sie können weder die Person hinter der Aktualisierung identifizieren, eine Abfangung beweisen noch den Exportfilter, die Peer-Koordination, die Pfadmessung und die dienstseitige Untersuchung ersetzen.

Die stärkste Schlussfolgerung ist daher sowohl klar als auch begrenzt. Öffentliche Beobachtungen belegen, dass AS12389 falsche Routen erstellte, dass mehrere Peers einige Ankündigungen verbreiteten und dass gemessener Datenverkehr den Pfad änderte. Sie belegen nicht, dass Russland oder Rostelecom eine Spionage beabsichtigten, dass der Datenverkehr inspiziert wurde oder dass Finanzdaten oder Geld verloren gingen.

Verantwortlichkeit erfordert nicht die Erfindung dieser Fakten. Sie erfordert von den Betreibern, die die entscheidenden Belege kontrollierten, diese aufzubewahren, zu testen und zu erklären, was sie zeigen.

Quellen

Zugriff geprüft: 2026-07-25

  1. ThousandEyes, Ereignismechanismus, Pfadbelege und betroffene Dienstoberfläche:https://www.thousandeyes.com/blog/rostelecom-route-leak-targets-ecommerce-services
  2. BGPMon, Ereignis-Timing, Zählungen, spezifischeres Beispiel und konkurrierende Hypothesen:https://www.bgpmon.net/bgpstream-and-the-curious-case-of-as12389/
  3. Internet Society, unabhängiger Routing-Sicherheits-Jahreskontext:https://www.internetsociety.org/blog/2018/01/14000-incidents-2017-routing-security-year-review/
  4. CERT-EU, spätere institutionelle Vorfalls- und Schadenszusammenfassung:https://cert.europa.eu/publications/threat-intelligence/threat-memo-190611-1/pdf
  5. ENISA, BGP-Sicherheitsanalyse und Kontrollempfehlungen:https://www.enisa.europa.eu/sites/default/files/publications/WP%202019%20-%20O.1.2.3.P%20-%20Short%20position%20paper%20%E2%80%94%20analysis%20of%20a%20technical%20topic%20%28BGP%20security%29.pdf
  6. CERT-EU, spätere zugeschriebene Bedrohungsbewertung:https://cert.europa.eu/publications/threat-intelligence/threat-memo-bgp-hijacking-russia/pdf
  7. Moriano und Co-Autoren, von Experten geprüfte historische Rekonstruktion:https://pmoriano.com/docs/COMNET21.pdf
  8. CAIDA BGPStream, Zugang zu historischen Route Views- und RIPE RIS-Daten:https://bgpstream.caida.org/data
  9. IETF RFC 7908, Definitionen und Klassifizierung von Route Leaks:https://datatracker.ietf.org/doc/html/rfc7908
  10. IETF RFC 7454, BGP-Betriebssicherheits- und Filterrichtlinien:https://datatracker.ietf.org/doc/html/rfc7454
  11. IETF RFC 6811, BGP-Ursprungsvalidierungsstatus:https://datatracker.ietf.org/doc/html/rfc6811
  12. IETF RFC 7115, operativer Einsatz der RPKI-Ursprungsvalidierung:https://datatracker.ietf.org/doc/html/rfc7115
  13. IETF RFC 6480, RPKI-Architektur:https://datatracker.ietf.org/doc/html/rfc6480
  14. IETF RFC 6482, Profil der Route Origin Authorization:https://datatracker.ietf.org/doc/html/rfc6482
  15. NIST SP 800-189, Richtlinien für BGP-Sicherheit und belastbaren Austausch:https://csrc.nist.gov/pubs/sp/800/189/final
  16. MANRS, Maßnahmen für Netzwerkbetreiber:https://manrs.org/netops/
  17. MANRS, Implementierungsrichtlinien für Netzwerkbetreiber:https://manrs.org/netops/bcop/
  18. RIPE NCC, Erklärung der BGP-Ursprungsvalidierung und Grenzen:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origin-validation/