Rostelecom-Routenleck 2020: Grenzen der RPKI-Validierung

Zusammenfassung

Der Monitoring-Standpunkt von Qrator datiert den Beginn des Vorfalls auf etwa 19:28 UTC am 1. April 2020 und beschreibt eine Beobachtung, die rund eine Stunde dauerte. Das ist ein zugeordnetes externes Beobachtungsfenster, keine vollständige interne Rostelecom-Chronologie und kein Beleg für einen exakten Start- und Endpunkt in jedem betroffenen Netz.[1]
Qrator meldete 8.870 betroffene Präfixe von fast 200 autonomen Systemen. CERT-EU fasste separat mehr als 8.800 Routen aus über 200 Netzen zusammen. Diese Zahlen beschreiben die Größe des aus unterschiedlichen Berichtswegen sichtbaren Bereichs; keine der Quellen belegt, dass jede Datenpfad-Kombination, jeder betroffene Nutzer oder der gesamte kommerzielle Effekt erfasst wurde.[1][2]
Qrator beobachtete, dass AS12389-Ankündigungen über Rascom AS20764, Cogent AS174 und Level 3 AS3356 propagiert wurden. Diese Kette zeigt, dass das Ereignis unabhängig betriebene Routing-Domänen kreuzte, aber nicht die exakten Import-Filter, Verträge, den Validierungsstatus oder die Router-Konfiguration in einem benannten Netz offenlegt.[1]
Die Routing-Evidenz verlangt, mehrere Kategorien strikt zu trennen: eine gelernte Route, die über ihren vorgesehenen Richtlinienrahmen hinaus exportiert wurde; eine unautorisierte Herkunftsankündigung; eine neu geroutete spezifischere Route; und eine Route, deren autorisierter Herkunfts-ASN und Länge intakt blieb, obwohl der AS-Pfad eine erwartete Geschäftsbeziehung verletzt. Diese Kategorien interagieren unterschiedlich mit Filtern und der RPKI-Herkunftsvalidierung.[4][17]
Ein separater RIPE NCC-Vorfall ereignete sich im RPKI-Kontrollplan. Nach einem Update der Registry-Software wurden 2.669 Route Origin Authorisations gelöscht, nachdem einige providerunabhängige Zuordnungen als nicht zertifizierbar eingestuft wurden. RIPE NCC stellte die fehlenden ROAs am 2. April wieder her.[3][5]
Zeitgleiche Gleichzeitigkeit begründete keine Kausalität. Die rückblickende Prüfung von RIPE NCC und eine unabhängige Analyse der Routing Working Group fanden keine direkte Beziehung zwischen der ROA-Löschung und dem Rostelecom-Routing-Vorfall.[4][5]
Die messbare Schnittmenge zwischen den Vorfällen war eng: drei providerunabhängige Inhaber und 12 Präfixe. Diese Überschneidung kann nicht auf alle 8.870 Präfixe ausgeweitet werden, und die öffentliche Akte stützt nicht die Aussage, dass alle betroffenen Routen als RPKI-Invalid zu behandeln seien.[4][5]
Route Origin Validation kann ein Präfix mit dem zugehörigen ASN gegen validierte ROA-Daten prüfen und das Ergebnis als Valid, Invalid oder NotFound klassifizieren. Sie validiert jedoch nicht den vollständigen AS-Pfad, prüft nicht automatisch, ob jeder Export eine Geschäftsbeziehung einhielt, rekonstruiert keine Konfigurationsänderung und kann keine Absichten nachweisen.[13]-[15]
Die praktische Kontrolle war verteilt: Rostelecom steuerte seine Ankündigungen und Export-Policy, die aufnehmenden Netze kontrollierten eigene Import-, Export- und Validierungsentscheidungen, Präfixinhaber kontrollierten ihre Datensätze und ROAs, RIPE NCC kontrollierte Zertifizierung und ROA-Management, Relying Parties kontrollierten Cache-Aktualität und Durchsetzung, Monitoring-Anbieter kontrollierten ihre Beobachtung und Alarmierung.
Wichtige Tatsachen bleiben unbekannt: der auslösende interne Ablauf, die genaue Trennung zwischen learned-route-Leaks und re-originated more-specifics, jeder RPKI-Stand eines akzeptierenden Netzes, die in jedem Hop angewendeten Filter, die vollständige Reaktionschronologie, die gesamte Daten-Plane-Auswirkung und ob der Vorfall versehentlich oder absichtlich begann.
Die Verantwortungsfeststellung ist daher operativ statt schuldzuweisend. Registry- und ROA-Datensätze lieferten Evidenz zu Ressourcenzuordnung und Herkunftsautorisierung, während laufende Konfigurationen, aktuelle Caches, Nachbar-Policies, Monitoring und koordinierte Wiederherstellung darüber entschieden, ob diese Evidenz das Live-Routing-Verhalten änderte.

Die Frage der Verantwortlichkeit

Der Vorfall vom 1. April 2020 ist bedeutsam, weil er eine Trennung zwischen dokumentierter Autorität und laufender Kontrolle offenlegte. Die RIPE-Datenbank konnte das administrative Objekt zu AS12389 identifizieren, und RPKI konnte für einige Präfixinhaber eine Herkunftsautorisierung ausdrücken.[8][10] Keine der beiden Instanzen bestimmte jedoch allein, was jeder Router akzeptieren, priorisieren oder weiterleiten sollte.

BGP-Sprecher tauschten UPDATE-Nachrichten aus, wählten Routen gemäß lokaler Policy und verteilten zulässige Ergebnisse an ihre Nachbarn.[12] Sobald unerwartete Ankündigungen eine Netzwerkgrenze überschritten, traf jeder empfangende Betreiber eine weitere lokal kontrollierte Entscheidung.

Diese Struktur schließt eine einfache Erklärung aus, in der ein Registry-Datensatz, ein Sicherheitsmechanismus oder eine Organisation das gesamte Ergebnis steuerte. Qrators gemeldete Weiterverbreitung über AS20764, AS174 und AS3356 setzte mehrere operative Kontrollpunkte in der beobachteten Kette.[1] Das Verhalten von Rostelecom war zentral, weil AS12389 in den untersuchten Ankündigungen erschien. Die Reichweite dieser Ankündigungen hing jedoch auch davon ab, welche Nachbarn sie akzeptierten, welche Routen diese Nachbarn weitergaben und welche Downstream-Netze auswählten.

Deshalb wurde das Ereignis zu einem Test der Grenzen der Origin-Validierung. Wenn eine Ankündigung einen unautoriserten Origin nutzte oder eine von ROA nicht zulässige Präfixlänge aufwies, konnte ein Betreiber mit aktuellen validierten Daten und einer durchsetzungsstarken Policy sie potenziell als Invalid klassifizieren und verwerfen. Wenn eine Route eine autorisierte Herkunft behielt, aber auf einem unangemessenen AS-Pfad transportiert wurde, konnte dieselbe Herkunftsprüfung Valid liefern. Gab es keine passende ROA, wäre das Ergebnis regelmäßig NotFound statt Invalid gewesen.

Die technischen Kontrollmechanismen hatten also unterschiedliche Hebelwirkung auf verschiedene Teile des beobachteten Ereignisses.

Die öffentliche Evidenz unterstützt eine Verantwortlichkeitsanalyse nur, wenn diese Unterscheidungen bestehen bleiben. Das Entfernen der BGP-Ankündigungen, der AS12389-Evidenz, der Verbreitungsbeobachtungen, des ROA-Status, der Annahmeentscheidungen der Upstreams, des Monitorings und der Incident-Koordination würde nur zu einer generischen Sicherheitsdiskussion führen statt zu einer Erklärung dieses Vorfalls. Umgekehrt würde die Behandlung jeder Route als einheitliche Fehlerart dem ROV Fähigkeiten zuschreiben, die das Verfahren nicht besitzt.

Verantwortlichkeit bedeutet hier, zu identifizieren, wer praktische Kontrolle über eine messbare Entscheidung hatte und welche Evidenz diese Entscheidung belegen kann. Es bedeutet nicht, aus externen Routing-Beobachtungen auf Fahrlässigkeit, Kriminalität, individuelles Verschulden, Datenschutzbruch, rechtliche Haftung oder ein Interzeptionsmotiv zu schließen. CERT-EU stellte fest, dass unklar blieb, ob das Ereignis versehentlich war.[2] Die vorliegenden Unterlagen klären diese Unsicherheit nicht auf, daher darf die Analyse sie nicht durch Behauptung schließen.

Forensische Chronologie

Eine forensische Rekonstruktion muss direkt berichtete Beobachtungen von Schlussfolgerungen und ungeklärten internen Ereignissen trennen. Öffentliche Routen-Sammler und Monitoring-Plattformen liefern ausgewählte Kontroll-Ebenen-Einblicke statt einheitlicher Transcript-Bilder. RIPEstat-Dokumentation ordnet Routing-Daten als Beobachtung aus verfügbaren Quellen mit Grenzen durch Sichtbarkeitspunkte und Datenabdeckung ein.[9] Die folgende Chronologie benennt daher, was berichtet wurde, was getrennt ist und was unbekannt bleibt.

Zeit	Evidenzereignis
Vor 19:28 UTC, 1. April	Die öffentliche Akte benennt keine spezifische auslösende Konfigurationsänderung, keinen Router, keinen Befehl, keinen Mitarbeitenden und keine interne Freigabekette bei Rostelecom. Sie stellt auch nicht den genauen Vorfall-Zustand von Filtern und RPKI in jedem Netz fest, das später eine Ankündigung akzeptierte.
Etwa 19:28 UTC	Qrator setzt den Beginn seiner Beobachtung auf etwa 19:28 UTC. Es wurde berichtet, dass AS12389 Routen angekündigt hat, die mit einem großen Satz anderer Netze verknüpft waren.[1] Dieser Zeitstempel gehört zum Monitoring-Standpunkt von Qrator; er ist kein Beleg, dass jeder betroffene Router sein erstes Update exakt zu diesem Zeitpunkt sah.
Während der folgenden Weiterverbreitung	Qrator meldete, dass die Ankündigungen über Rascom AS20764, Cogent AS174 und Level 3 AS3356 propagiert wurden.[1] Die Beobachtung belegt die sichtbare Weiterleitung über diese autonomen Systeme, nicht jede Session-Entscheidung, Routenfilterauswertung oder Geschäftsbeziehungslogik dahinter.
Während des ungefähren einstündigen Fensters	Qrator zählte 8.870 betroffene Präfixe aus fast 200 autonomen Systemen.[1] CERT-EU fasste später mehr als 8.800 Routen aus mehr als 200 Netzen zusammen.[2] Das sind zugeordnete Messungen, kein Beleg dafür, dass jede Route dieselbe Ursprung-Validierung aufwies oder dieselbe Datenplane-Wirkung erzeugte.
Im Incident Response Verlauf	Qrator meldete, dass Rostelecom eine Echtzeit-Warnung erhielt und mit Qrator an Fehlerbehebung und Wiederherstellung arbeitete.[1] CERT-EU dokumentierte ebenfalls die Zusammenarbeit mit der meldenden Firma.[2] Der genaue Eskalations-, Mitigations- und Rollback-Ablauf bei Rostelecom ist nicht öffentlich.
Ungefähr eine Stunde nach der ersten Beobachtung	Qrator beschrieb das Ereignis als etwa einstündig.[1] Die öffentliche Akte stützt eine Wiederherstellung innerhalb dieses Beobachtungsintervalls, benennt jedoch nicht, welche Konfiguration oder Zurücknahme jedes betroffene Route beendete oder ob die Konvergenz überall gleichzeitig ablief.
Zeitgleicher RPKI-Vorfall	Parallel dazu verursachte ein Update der RIPE NCC-Registry-Software, dass bestimmte providerunabhängige Zuordnungen als nicht zertifizierbar klassifiziert wurden, woraus die Löschung von 2.669 ROAs resultierte.[3][5] Das war ein eigenständiger Datensatz-Betriebsfall auf der Kontrollplane, getrennt vom AS12389-Routingverhalten.
2. April	RIPE NCC stellte die fehlenden ROAs wieder her.[3][5] Diese Wiederherstellung gehört zur separaten RPKI-Service-Wiederanlaufchronik und darf nicht als Mechanismus dargestellt werden, der den Rostelecom-Vorfall beendete.
Nachfolgende Analyse	Eine Routing Working Group-Analyse und die spätere Nachprüfung von RIPE NCC fanden keine direkte Beziehung zwischen beiden Vorfällen. Sie identifizierten eine Überschneidung mit drei PI-Inhabern und 12 Präfixen.[4][5]

Diese Chronologie enthält zwei zeitgleiche, analytisch getrennte Fehlersequenzen. Eine zeigte sich in den BGP-Ankündigungen und deren Akzeptanz über Netzwerkgrenzen. Die andere lag in der Produktion und Verfügbarkeit von Herkunftsautorisierungsdatensätzen. Die erste hing von der laufenden Routing-Policy ab; die zweite von der Verfügbarkeit validierter ROA-Daten für die Relying Parties. Ihre begrenzte Schnittmenge erlaubt die Frage, ob fehlende Datensätze die Behandlung von 12 Präfixen veränderten. Sie macht aber die ROA-Löschung nicht zur Ursache des 8.870-Präfix-Ereignisses.

Die Chronologie trennt außerdem Beobachtungszeit von Auslöserzeit. Die ungefähre Beobachtung um 19:28 durch Qrator ist der Zeitpunkt, zu dem das Ereignis an deren Vantage Points sichtbar wurde. Sie sagt nicht, wann eine interne Änderung eingegeben, bestätigt oder verteilt wurde. Ebenso beschreibt die etwa einstündige Dauer nur den externen Beobachtungszeitraum. Sie kann nicht den exakten Zeitraum festlegen, in dem jede einzelne Route in jedem Routing-Informationsbestand präsent war.

Das Fehlen einer Router-zu-Router-Chronologie ist relevant. Ohne sie kann keine belastbare Aussage über den ersten akzeptierenden Nachbarn, die Reihenfolge von Policy-Bewertungen, welche Routen zuerst zurückgezogen oder korrigiert wurden, oder ob einige Netze den Vorfall noch weitertrugen getroffen werden. Eine verantwortliche Rekonstruktion hält diese Lücken und verwandelt keinen Monitoring-Trace in ein internes Ereignislog.

Was die beobachtete Weiterverbreitung belegt

Die AS-Pfad-Beobachtung zeigt, dass unerwartete Erreichbarkeitsinformationen nicht in einem einzelnen Netz blieben. BGP ist ein verteiltes Protokoll: ein von einem autonomen System akzeptiertes UPDATE kann Teil eines Entscheidungsprozesses eines anderen Systems werden und unter Policy-Bedingungen als Ankündigung an weitere Nachbarn gehen.[12] Die gemeldete AS12389–AS20764–AS174–AS3356-Weitergabe markiert deshalb eine Folge separater administrativer Entscheidungsstellen.[1]

Diese Sequenz belegt nicht, dass jedes genannte Netz alle 8.870 Präfixe annahm oder dass ein identischer Pfad das gesamte Internet erreichte. Sie legt auch nicht offen, weshalb eine konkrete Import-Policy eine Route akzeptierte. Ein Betreiber kann auf Customer-Prefix-Filter, IRR-Daten, RPKI-Validierung, manuell gepflegte Ausnahmen, breite Grenzwerte oder Vertragsannahmen zurückgegriffen haben, oder auf eine Kombination. Die eingefrorene Evidenz offenbart keine Konfiguration im April 2020 für ein bestimmtes Upstream- oder Peer-Netz.

Die Verbreitungs-Evidenz ist dennoch wertvoll, weil sie Orte möglicher Eindämmung markiert. AS12389 kontrollierte, ob es die Ankündigungen herstellte oder exportierte. Jedes direkt verbundene empfangende Netz kontrollierte ihre Annahme. Jede weitere Werbung aufwärts kontrollierte eine weitere Exportentscheidung. Downstream-Netze kontrollierten Routenwahl und mögliche lokale Validierungsrichtlinien. Das ist geteilte Kontrolle in einem präzisen technischen Sinn: mehrere Betreiber hatten eigenständige Mechanismen, mit denen sich zumindest einige Routing-Ergebnisse ändern ließen.

Geteilte Kontrolle darf nicht automatisch zu geteilter Schuld werden. Ein sichtbarer AS-Pfad allein sagt nichts über die Bedingungen einer Routingbeziehung, die Vollständigkeit des Präfixinventars eines Betreibers, den Zustand seiner Caches oder darüber, ob eine Route zum learned-route- oder re-originated-more-specific-Teil des Vorfalls gehörte. Er identifiziert einen Entscheidungspunkt, nicht die rechtliche oder moralische Bedeutung dieser Entscheidung.

Vier Routing-Kategorien, die nicht vermischt werden dürfen

Der Begriff „Leck“ wird oft unscharf verwendet, doch dieses Ereignis lässt sich nur korrekt erfassen, wenn vier Routing-Zustände getrennt betrachtet werden. RFC 7908 definiert Routing-Lecks anhand von Propagationsfällen über den vorgesehenen Geltungsbereich einer Route, insbesondere wenn der resultierende Pfad die erwartete Reihenfolge von Kunden-, Provider- und Peer-Beziehungen verletzt.[17] Dieser Begriff ist von der Herkunftsautorisierung zu unterscheiden.

Learned-route-Policy-Leck.Ein Netzwerk lernt eine legitime Route von einem Nachbarn und exportiert sie an einen anderen Nachbarn außerhalb des vorgesehenen Policy-Rahmens dieser Route. Der autorisierte Herkunfts-ASN des Präfixinhabers kann am Ende des AS-Pfads bestehen bleiben. Der Fehler liegt in der Exportgrenze: das Zwischennetzwerk wirkt als Transit, obwohl die Policy dies nicht vorsah. Da das Ursprungs-ASN und die Präfixlänge weiterhin zu einer ROA passen können, kann die normale Route Origin Validation die Route als Valid klassifizieren, obwohl der Pfad kommerziell oder operativ unangemessen ist.
Unautorisierte Herkunftsankündigung.Ein ASN kündigt ein Präfix an, für das der zuständige Ressourceneigentümer es ihm nicht zur Herkunftsoriginierung berechtigt hat. Wenn eine deckende ROA ein anderes ASN autorisiert und ein Relying Party aktuelle validierte Daten hat, kann die Ankündigung als Invalid eingestuft werden, weil die Herkunft nicht passt.[13]-[15] Der technische Begriff „origin hijack“ wird für diesen Zustand manchmal verwendet, doch diese Bezeichnung allein beweist keine böswillige Absicht, keine Verkehrsumleitung, kein kriminelles Verhalten und keine Rechtsinhaberschaft.
Re-originierte spezifischere Route.Ein ASN kündigt ein längeres Präfix innerhalb der Aggregation eines anderen Netzes an und stellt sich selbst als Herkunfts-ASN dar. Eine passende ROA kann die spezifischere Route als Invalid klassifizieren, entweder weil das Herkunfts-ASN abweicht oder die angekündigte Länge diemaxLengthder ROA überschreitet. Eine spezifischere Route kann wegen Longest-Prefix-First vor Standard-BGP-Pfadvergleich bevorzugt werden. Dennoch legt die öffentliche Akte den Zweck jeder Re-Originierung oder den Datenplane-Effekt jedes Präfixes nicht fest.
Valid-Origin-Policy-Leck.Präfix, Herkunfts-ASN und Länge sind autorisiert, doch AS-Pfad oder Exportbeziehung verletzt die vorgesehene Policy. Das ist der klarste Beleg für die Grenze von ROV. Origin-Validierung beantwortet, ob die Herkunft unter den vorliegenden ROA-Daten autorisiert ist; sie beantwortet nicht, ob ein Zwischen-AS zur Transit-Weitergabe befugt war, ob der Pfad eine zulässige Beziehung einhielt oder ob die Route an diesen Nachbarn hätte ausgegeben werden dürfen.

Die öffentlichen Analysen zeigen, dass die Beobachtungen von April 2020 eine Mischung aus learned routes und re-originated more-specifics enthielten.[4] Die genaue Verteilung ist unbekannt. Es wäre deshalb unpräzise, alle 8.870 Routen als unautorisierte Herkunften, als Policy-Lecks mit autorisierter Herkunft oder als RPKI-Invalid zu bezeichnen. Jede solche Gesamtaussage würde die nicht aufgelöste Verteilung durch eine uniforme Kategorie ersetzen.

NotFound muss ebenfalls getrennt bleiben. Wenn keine passende validierte ROA existiert, liefert Origin-Validierung üblicherweise NotFound.[14] Diese Lage ist in einem unvollständig abgedeckten Routing-System häufig. NotFound ist kein Beleg für eine autorisierte Herkunft, aber auch nicht automatisch ein als Invalid eingestuftes Ergebnis und nicht automatisch ein unabhängiger Verfehlungsbeleg. Ein Netz kann lokale Richtlinien für NotFound-Routen anwenden; der Zustand selbst sagt nur, dass der verfügbare validierte ROA-Datensatz keine passende Autorisierung gegen die Ankündigung lieferte.

Diese Kategorien definieren den Einsatzbereich möglicher Kontrollen. Origin-Filter, die auf einem vereinbarten Kundenpräfix-Inventar basieren, können unautorisierte Ursprünge und falsch exportierte learned routes an einer Kunden-Grenze begrenzen. ROV kann bei vorhandenen ROAs einige unautorisierte Ursprünge oder unzulässige Längen identifizieren. Pfad-/Beziehungs-Kontrollen können Valid-Origin-Policy-Lecks abfangen. Keine einzelne Filterkategorie deckt zwangsläufig die gesamte Mischung ab.

Was RPKI-Herkunftsvalidierung feststellen kann

RPKI stellt eine kryptografisch gestützte Struktur bereit, über die Adressressourceninhaber Route Origin Authorisations anlegen können. Ein ROA drückt aus, dass ein festgelegtes ASN autorisiert ist, ein Präfix bis zu einer maximalen Präfixlänge zu originieren.[13] Eine Relying Party ruft und validiert RPKI-Material ab, erzeugt validierte ROA-Payloads und stellt diese Informationen für Routing-Systeme oder Policy-Engines bereit. RIPE NCC betreibt Zertifizierungs- und ROA-Management-Services für Ressourcen in seinem Servicegebiet, programmiert aber nicht zentral die Router aller teilnehmenden Netze.[10]

Auf Basis eines konkreten validierten Datensatzes kann die Origin-Validierung drei relevante Ergebnisse liefern. Eine Route istValid, wenn eine deckende Autorisierung den beobachteten Herkunfts-ASN und die Präfixlänge zulässt. Sie istInvalid, wenn deckende Autorisierungen vorhanden sind, aber keine die Kombination aus Herkunft und Länge erlaubt. Sie istNotFound, wenn keine deckende Autorisierung verfügbar ist.[14] Dies sind Aussagen relativ zu den Daten der Relying Party zu einem Zeitpunkt, nicht zeitlose globale Eigenschaften der Route.

Diese Einordnung ist während eines Registry-Ereignisses bedeutsam. Zwei Relying Networks können vorübergehend unterschiedliche validierte Sichtweisen haben, weil Repository-Synchronisierung, Cache-Zustände, Ablaufverhalten oder operative Reaktionen differieren. RFC 7115 beschreibt die operative Bedeutung von Relying-Party-Verarbeitung und validierten Daten.[15] Die eingefrorene Evidenz zeigt nicht den exakten gecachten Stand jedes Netzes während der einstündigen Rostelecom-Beobachtung.

Die Aussage, ein benannter Betreiber habe „Invalid gesehen“, benötigt daher Evidenz zur validierten Datenlage und Policy dieses Betreibers im relevanten Moment.

ROV liefert nützliche Origin-Evidenz. Wenn eine AS12389-Ankündigung für ein abgedecktes Präfix mit dem autorisierten ASN kollidierte oder wenn ein spezifischeres Präfix die anwendbaremaxLengthüberschritt, konnte ein durchsetzender Betreiber sie potenziell als Invalid ablehnen. Diese Bedingung gilt nur, wenn das zugehörige ROA existierte, korrekt ausgedrückt war, in einen aktuellen Relying-Party-Cache gelangte, in die Routing-Policy einspeiste und ohne übersteuernde Ausnahme angewendet wurde. Das Entfernen eines dieser Elemente kann das Live-Ergebnis ändern.

Ein Valid-Ergebnis beweist weit weniger als „sichere Route“. Es validiert nicht die Zwischen-AS-Abfolge. Es zertifiziert nicht automatisch Kunden-Provider- oder Peer-Beziehungen. Es zeigt nicht, dass ein Zwischennetzwerk berechtigt war, eine gelernte Route zu exportieren. Es beweist nicht, dass der Datenpfad das vorgesehene Ziel erreichte, dass Verkehr nicht umgeleitet wurde oder dass operative Kontakte reagieren würden. Eine autorisierte Herkunft kann hinter einem unerwünschten Pfad stehen.

Ein Invalid-Ergebnis hat ebenfalls begrenzte Aussagekraft. Es zeigt einen Konflikt mit den in dieser Relying Party verfügbaren deckenden Autorisierungen. Es kann aus unautorisierter Herkunft, überlanger Präfixlänge, veralteter operativer Intention oder fehlerhafter ROA entstehen. Es belegt allein weder Motivation, noch Interzeption oder strafbares Handeln. Betreiber benötigen Change-Management, Ausnahmebehandlung und Untersuchung, um einen Angriff von Konfigurations- oder Datensatzfehlern zu unterscheiden.

NotFound liefert die geringste Herkunftsspezifik. Es gibt keine deckende validierte Autorisierung im Blick der Relying Party, sodass ROV die Herkunft über eine ROA weder bestätigen noch widerlegen kann. NotFound pauschal als bösartig zu behandeln wäre eine lokale Policy-Entscheidung und nicht implizite Aussage des Validierungsstatus. Außerdem bestünde das Risiko, legitime Routen ohne ROA-Abdeckung routinemäßig abzulehnen.

Das Beispiel der RIPE NCC-Löschung unterstreicht diese Trennung. Das Löschen von 2.669 ROAs kann in den Ansichten mancher Relying Parties Routen von Valid oder Invalid zu NotFound verändern, abhängig von verbleibenden deckenden Datensätzen und Cache-Zeitpunkt.[3][5] Es erzeugte nicht die AS12389-BGP-Ankündigungen, veranlasste keine Zwischennetze zum Export dieser Routen und veränderte nicht automatisch komplette AS-Pfade. Für den Rostelecom-Vorfall betrug die nachgewiesene Schnittmenge nur drei PI-Inhaber und 12 Präfixe, und spätere Analyse zeigte keinen direkten Zusammenhang zwischen den Vorfällen.[4][5]

Eine universelle ROV kann daher nicht beansprucht werden, diesen gesamten Vorfall verhindert zu haben. Sie hätte den Teil begrenzen können, in dem Ankündigungen unter vorliegenden aktuellen ROA-Daten und durchsetzender Policy invalid wären. Sie würde jedoch nicht automatisch ein learned-route-Policy-Leck verhindern, wenn die autorisierte Herkunft unverändert blieb, und sie validiert nicht automatisch den kompletten AS-Pfad. Diese Grenze ist kein Evidenzdefizit, sondern die korrekte Beschreibung dessen, was der Mechanismus beantworten sollte.

Root Cause

Die auslösende interne Abfolge bei Rostelecom ist unbekannt. Die öffentlichen Quellen benennen keine spezifische Konfigurationsänderung, keinen Befehl, keinen Router, keinen Mitarbeitenden, keine Freigabebewertung oder eine Automatisierungsstörung. Sie zeigen extern beobachtetes AS12389-Ankündigungsverhalten und die Weitergabe, nicht den internen Mechanismus, der es erzeugte. Daher lässt sich die Root Cause nicht auf eine benannte Aktion oder eine Person aus der verfügbaren Evidenz reduzieren.

Auf der Beobachtungsebene begann der Vorfall mit AS12389-Herkunfts- oder Exportverhalten, das unerwartete Routen in BGP einführte, einschließlich Beobachtungen, die als learned-route-Leak und als re-originated more-specifics interpretiert wurden.[1][4] Akzeptanz und Weitergabe durch andere Netze vergrößerten den sichtbaren Umfang. Das ist eine durch Routingbeobachtung gestützte Ereignisfolge, kein vollständiger Root-Cause-Abschluss.

Der RIPE NCC-Fall hatte eine andere dokumentierte technische Abfolge. Ein Registry-Softwareupdate klassifizierte einige providerunabhängige Zuordnungen als nicht certifizierbar und löschte 2.669 ROAs.[3][5] Dieses Software- und Datensatzverwaltungsversagen veränderte RPKI-Daten, während der Rostelecom-Vorfall die Live-BGP-Ankündigungen veränderte. Eine spätere Analyse fand kein direktes kausales Verhältnis zwischen beiden Vorfällen.[4][5] Eine Zusammenführung beider als eine Ursache widerspräche der dokumentierten Akte.

Beitragende Bedingungen

Die erste beitragende Bedingung war die Abhängigkeit von BGP-Lokalsystempolitik an jeder Netzgrenze. BGP verteilt Erreichbarkeit, doch Betreiber bestimmen, was akzeptiert, bevorzugt und beworben wird.[12] Eine Route, die innerhalb einer Beziehungsgruppe geblieben wäre, kann sich ausbreiten, wenn sukzessive Konfigurationen dies zulassen. Die beobachtete Durchleitung über AS20764, AS174 und AS3356 zeigt mehrere Annahme- und Exportpunkte, obwohl sie die spezifische Policy in keinem der Fälle offenlegt.[1]

Die zweite Bedingung war die ungleich wirksame Herkunftsautorisierung. Routen mit kollidierenden oder deckenden ROAs konnten Kandidaten für ROV-Ablehnung sein. Valid-Origin-Policy-Leaks wären es nicht gewesen. Routen ohne deckende ROA wären NotFound gewesen. Die unbekannte Mischung der Kategorien bedeutet, dass keine tragfähige Analyse eine einheitliche Prüfmethode für das Gesamtset ansetzt.

Die dritte Bedingung war die Abhängigkeit von aktuellen Betriebsdaten. Ein korrekt erstellter ROA wirkt nur, wenn Relying Parties ihn abrufen und validieren, Caches aktuell bleiben, Router das Ergebnis erhalten und die lokale Policy darauf reagiert. Die RIPE NCC-Löschung veränderte den Datensatzlayer vorübergehend; Cache-Synchronisierung und lokale Durchsetzung entschieden, wann oder ob diese Änderung für eine Netzdatenentscheidung wirksam wurde.[3][10][15]

Die vierte Bedingung war eine verteilte Filterung. Kundenpräfix-Filter, Maximum-Prefix-Kontrollen, Routenregister, RPKI-Validierung und Export-Policy-Prüfungen können sich ergänzen.[11][16] Die öffentliche Akte legt nicht fest, welche dieser Kontrollen bei Rostelecom oder in den Verbreitungsnetzen im April 2020 tatsächlich vorhanden, fehlten, umgangen oder fehlerhaft skaliert waren. Sie sind relevante Kontrollkategorien, keine Feststellungen zu nicht dokumentierten Konfigurationen.

Die fünfte Bedingung war fragmentierte Sichtbarkeit. Monitoring-Anbieter sehen abweichende Ankündigungen aus ausgewählten Vantage-Points und warnen Betreiber, aber sie besitzen nicht jede Adj-RIB-In-, lokale Routing-Informationsbasis, Weiterleitungstabelle oder Konfigurationshistorie eines Routers. Qrators Alarm lieferte verwertbare externe Evidenz.[1] Er konnte jedoch nicht selbst die auslösende interne Störung rekonstruieren oder garantieren, dass alle betroffenen Netze gleichzeitig konvergiert waren.

Auslösendes Ereignis

Der unmittelbare Auslöser innerhalb von Rostelecom bleibt nicht identifiziert. Er durfte nicht auf eine Person, einen Befehl, einen Router, einen Vertrag oder eine Motivation zurückgeführt werden, nur auf Basis öffentlicher Evidenz. Das erste belastbare externe Ereignis ist das Auftreten der betroffenen AS12389-Ankündigungen im Beobachtungspunkt von Qrator um etwa 19:28 UTC.[1]

„Auslöser“ darf nicht mit „Bedingung“ verwechselt werden. Nachsichtige Nachbar-Policies, unvollständige ROA-Abdeckung, veraltete Daten oder begrenztes Monitoring können ein Ereignis ausbreiten oder die Eindämmung verzögern, aber keine dieser Bedingungen beweist, was die Ankündigungen ausgelöst hat. Ebenso war die separate ROA-Löschung zeitgleich, aber nicht der dokumentierte Auslöser für das AS12389-Routing-Verhalten.[4][5]

Erkennung

Qrator berichtete, dass es den Vorfall in Echtzeit entdeckte und Rostelecom warnte.[1] Seine Messungen lieferten den ungefähren Start, die Dauer, die erkennbare Größe und die sichtbare Weiterleitungskette, die die öffentliche Rekonstruktion stützen. CERT-EU fasste den Vorfall später zusammen und nannte sowohl die Unsicherheit über eine Unfallursache als auch die Zusammenarbeit mit Rostelecom.[2]

Externe Erkennung ist ein wichtiges Kontinuitätsinstrument, weil interne Sicht eines Betreibers nicht zwingend zeigt, wie Nachbarn oder entfernte Netze seine Routen erhalten. Die Begrenzung ist gleichbedeutend wichtig: Ein Monitoring-Alarm beweist Sichtbarkeit am Messstandpunkt des Systems. Er zeigt nicht den genauen Zeitpunkt des internen Auslösens, jede nachgelagerte Selektionsentscheidung oder die vollständige Daten-Plane-Auswirkung. Starke Erkennung kombiniert lokale Session- und Policy-Telemetrie mit unabhängigen Routenbeobachtungen.

Reaktion

Qrator gab an, dass Rostelecom nach Erhalt der Echtzeitwarnung mit ihm die Fehlerbehebung und Wiederherstellung koordinierte.[1] Das stützt eine Feststellung zur Incident-Koordination. Es legt jedoch nicht die interne Eskalationskette, die Identität der Eingreifenden, die geprüfte Konfiguration, die gewählte Gegenmaßnahme oder den exakten Zeitpunkt der einzelnen Schritte offen.

Die Reaktion der Verbreitungsnetze ist in der eingefrorenen Akte nicht vergleichbar dokumentiert. Ihre praktischen Optionen konnten Filterung von Ankündigungen, Präferenzänderung, Kontaktaufnahme zu angrenzenden Netzen oder Abwarten korrigierter Updates umfassen, doch es wäre spekulativ, dass ein bestimmter Betreiber einen konkreten Ansatz verwendete. Verantwortlichkeit verlangt die Trennung zwischen vorhandenen Kontrollmöglichkeiten und nachgewiesenen Handlungen.

RIPE NCC reagierte in einem eigenen Ablauf. Es untersuchte die fehlenden ROAs, stellte sie am 2. April wieder her und beschrieb danach Monitoring-Verbesserungen.[3][5] Diese Reaktion betraf Integrität und Verfügbarkeit von RPKI-Datensätzen. Sie war nicht der Routing-Wiederherstellungsmechanismus, der AS12389-Ankündigungen korrigierte.

Wiederherstellung

Die etwa einstündige Beobachtung durch Qrator und die Berichte zu Fehlerbehebung und Wiederherstellung stützen die Schlussfolgerung, dass das sichtbare Routing-Ereignis in diesem breiten Fenster unter Kontrolle gebracht wurde.[1] Sie benennen nicht, ob die Wiederherstellung auf Withdrawals, korrigierten Ankündigungen, Änderungen der Export-Policy, Neighbor-Filterung oder einer Kombination beruhte. Sie beweisen auch nicht gleichzeitige Konvergenz in jedem Netz.

Operative Wiederherstellung hat mindestens drei Ebenen. Auf der Ankündigungsebene geht es darum, unerwartete Routen zu stoppen oder zu korrigieren. Auf der Verbreitungsebene müssen Nachbarn und nachgelagerte Netze die Änderung verarbeiten. Auf der Evidenzebene muss Monitoring bestätigen, dass abweichende Pfade über nützliche Sichtpunkte hinweg verschwunden sind. Eine Erklärung aus allein lokalem Routerbild kann verbleibende Verbreitung übersehen; eine Erklärung aus ausschließlich externen Sammlern kann interne Zustände übersehen.

Die RPKI-Service-Wiederherstellung war getrennt: RIPE NCC stellte die gelöschten ROAs am 2. April wieder her.[3][5] Abhängig von diesen Daten mussten Relying Parties dann mit eigener Synchronisierung und Validierung die reparierte Sicht erhalten. Die Wiederherstellung im Repository und die Konvergenz in jedem Relying Network sind verwandt, aber nicht identisch.

Zuweisung der praktischen Kontrolle

Verantwortlichkeit wird klarer, wenn Kontrolle nach Entscheidungen statt nach allgemeinen institutionellen Labels zugeordnet wird.

Akteur	Praktische Kontrolle	Grenze der Evidenz
Rostelecom / AS12389	Routenherkunft und Export-Policy, nachbarbezogene Filter, Präfixinventare, Konfigurationsreview, Ausrollung von Änderungen, Monitoring, Eskalation und Rollback	Auslösende Konfiguration und interne Reaktionskette sind nicht öffentlich
Rascom AS20764, Cogent AS174, Level 3 AS3356 und andere Verbreitungsnetze	Eigene Import-/Exportfilter, Beziehungs-Policy, Präfixgrenzen, ROV-Nutzung, Ausnahmeregeln, Reaktionsmanagement bei Anomalien und Weiterleitung	Die Konfigurationen, Cache-Zustände und Verträge im April 2020 sind unbekannt
Präfixinhaber	Genauigkeit von Resource Records, ROA-Erstellung, Auswahl von Herkunfts-ASN und`maxLength`, operative Kontakte und unabhängiges Route-Monitoring	Individuelle Entscheidungen können nicht pauschal über fast 200 betroffene autonome Systeme hinweg abgeleitet werden
RIPE NCC	Zertifizierungs- und ROA-Managementsysteme, Softwaretests, Service-Monitoring, Rollback, Wiederherstellung und öffentliche Vorfallsdarstellung im Rahmen seiner Rolle	Sie bestimmte oder setzte nicht zentral die Pfade von unabhängig betriebenen Routern fest
Relying-Party-Betreiber	Repository-Synchronisierung, Cache-Aktualität, Bereitstellung validierter Ergebnisse, lokale Invalid/NotFound-Policy, Ausnahmen und finale Routing-Entscheidungen	Kein globaler Beobachter kann auf jeden Zeitpunkt den Validierungsstand jeder Relying Party ableiten
Routing-Monitoring-Anbieter	Sammlung an Vantage Points, Anomalieanalyse, Alarmierung, Koordinationsnachweise und Berichte nach dem Vorfall	Sie beobachten ausgewählte Routing-Sichten und steuern keine Ankündigungen oder rekonstruieren jede interne Handlung

Diese Zuweisung verhindert zwei gegensätzliche Fehler. Erstens die Konzentration der gesamten Verantwortlichkeit auf das Ursprungsnetz und das Ignorieren unabhängiger Annahmeentscheidungen, die die Verbreitung ermöglichten. Zweitens die unkritische Streuung der Kontrolle, in der keine Entscheidung einen Verantwortungsinhaber besitzt. Rostelecom kontrollierte, was AS12389 ankündigte oder exportierte. Jeder Nachbar steuerte seine eigene Annahme. Jedes weitere Netzwerk kontrollierte eine zusätzliche Verbreitungsentscheidung. Der Registry-Operator steuerte die Verfügbarkeit der Ursprungsdatensätze.

Relying Parties entschieden, ob diese Datensätze Routing änderten.

Die Kontrolle über eine Ebene bedeutet nicht Kontrolle über eine andere. Ein Präfixinhaber kann einen korrekten ROA veröffentlichen, aber nicht erzwingen, dass jedes Netz ihn abruft oder durchsetzt. RIPE NCC kann einen gelöschten Datensatz wiederherstellen, aber nicht direkt eine BGP-Route eines unabhängigen Operators zurückziehen. Ein Monitoring-Anbieter kann Rostelecom warnen, aber keine Rollback-Aktion ausführen. Ein Upstream kann eine Route an seiner Grenze ablehnen, aber nicht die Ausgangskonfiguration reparieren. Operative Kontinuität entsteht durch Zusammenspiel dieser Kontrollen.

Die Verteilung begrenzt auch Schlussfolgerungen. Die Nennung eines autonomen Systems in einem beobachteten Pfad ist Evidenz dafür, dass dessen Netzkennung in der Beobachtung erschien. Sie ist für sich allein kein Beleg für den mentalen Zustand eines Mitarbeiters, eine Vertragsverletzung oder rechtliche Verantwortlichkeit. Diese Schlussfolgerungen brauchen Unterlagen jenseits der hier betrachteten Routing-Evidenz.

Root-Cause-Evidenz versus beitragende Evidenz

Root-Cause-Evidenz würde den internen Mechanismus benennen, der erstmals das unerwartete AS12389-Verhalten erzeugte, etwa ein Konfigurationsdifferenz, ein Automationsprotokoll, Versionsgeschichte und passende Zeitstempel mit Session-Trace. Keine dieser Belege liegt in der öffentlichen Akte vor. Die externen Routenbeobachtungen definieren das Ereignis und seine Ausweitung, füllen aber diese interne Evidenzlücke nicht.

Beitragende Evidenz erfüllt eine andere Funktion. Eine von aufeinanderfolgenden Netzen akzeptierte und weitergegebene Route zeigt, dass die Live-Policies entlang dieses beobachteten Pfads sie an früheren Grenzen nicht blockierten. Eine Invalid-Ankündigung, die über einen validierenden Netzpunkt hinaus sichtbar ist, kann Fragen zu Datensicherheit, Durchsetzung oder Ausnahmen aufwerfen, sofern der tatsächliche RPKI-Stand dieses Netzwerks bekannt ist. Ein valid-origin-policy-leak, der ROV passiert, zeigt demgegenüber, dass die Herkunftsautorisierung für diesen Teil ungeeignet war.

Trigger-Evidenz würde eine interne Aktion mit den ersten unerwarteten Updates verbinden. Detection-Evidenz würde zeigen, wann Monitoring-Systeme die Anomalie identifizierten. Response-Evidenz würde Kontakte, Entscheidungen und Änderungen dokumentieren. Recovery-Evidenz würde Withdrawal oder Korrektur über lokale und externe Sichtpunkte zeigen. Diese Trennung macht einen Nachberichtsfall prüfbar und verhindert, dass ein Erkennungszeitpunkt als Auslösezeitpunkt missverstanden wird.

Messbare Nachsteuerungsmaßnahmen

Der Vorfall unterstützt eine geschichtete Nachsteuerung, aber die Maßnahmen sollten als messbare Kontrollen formuliert werden, nicht als Schuldzuweisungen.

Erstens kann ein Ursprungs- oder Transitnetz ein nachbarbezogenes Route-Inventar unterhalten und Import- und Export-Policy vor Inbetriebnahme testen. Nützliche Messgrößen sind die Anzahl zulässiger Präfixe pro Nachbar, Abweichungen vom genehmigten Baseline-Satz, unerwartete Herkunfts-ASNs, längere Ankündigungen und Routen, deren Beziehungs-Klassifikation sich während eines geplanten Updates ändert. Ein Test sollte zwischen lokal originierter Route und gelernten Routen unterscheiden.

Zweitens können Betreiber die Eindämmung an externen Grenzen messen. Kunden- und Peer-Sessions lassen sich auf Default-Deny-Verhalten, explizite Allow-Listen, Maximum-Prefix-Schwellen und Exportregeln prüfen, die provider- oder peer-gelernte Routen nicht in eine andere unangemessene Beziehung exportieren. Allgemeine Filter- und Validierungspraxen aus operativen Leitlinien liefern ein geschichtetes Modell statt eines einzelnen universellen Checks.[11][16]

Drittens kann RPKI-Betrieb end-to-end gemessen werden. Relevante Indikatoren sind Repository-Synchronisationsalter, Cache-Serienstände, Verfügbarkeit der Validierungs-Feeds, Anzahl von Valid-, Invalid- und NotFound-Routen je Session, Policy-Ausnahmen sowie Alarme für abrupte Änderungen der ROA-Abdeckung. Ein Datensatz im ausstellenden System reicht nicht aus, wenn ein veralteter Cache oder ein getrennter Policy-Engine-Durchlauf dessen Wirkung auf Live-Entscheidungen verhindert.[10][15]

Viertens können Präfixinhaber überprüfen, ob ihre ROAs die aktuellen Ursprünge abbilden und obmaxLengthnicht weiter ist als operativ erforderlich. Eine engere Autorisierung kann einige unautorisierte specific-prefix-Subpräfixes als Invalid markieren; eine zu enge Einstellung kann jedoch auch legitime Traffic-Engineering-Ankündigungen invalidieren. Die korrekte Konfiguration hängt vom tatsächlichen Routing-Plan ab, und spätere Analysen zumaxLengthsowie dem Risiko von gefälschten Ursprungs-Subpräfixen unterstreichen, dass dies eine präzise operative Wahl bleibt.[20]

Fünftens kann der Incident-Response-Prozess über zeitbezogene Kennzahlen bewertet werden: Zeit vom ersten abnormalen Update bis zum lokalen Alarm; Zeit bis zur externen Bestätigungsbeobachtung; Zeit bis zur Kontaktaufnahme mit relevanten Nachbarn; Zeit zur Identifikation der betroffenen Policy; Zeit bis zur Unterbindung neuer Verbreitung; und Zeit bis zur Wiederherstellungsbestätigung über mehrere Sichtpunkte. Der Qrator-Bericht zeigt den Nutzen von Echtzeitwarnung und Koordination, ohne diese Zeitfenster vollständig offenzulegen.[1]

Ein hilfreicher Nachbericht würde den ersten beobachteten Update, den Konfigurationsstand, Ergebnisse der Routen-Policy-Auswertung, RPKI-Cache-Zustände, Betreiberkontakte, korrigierende Änderung und abschließende externe Verifikation vollständig festhalten. Solche Evidenz erlaubt später eine Trennung zwischen Ursprungsausfall, Exportausfall, Annahmefehler, veralteten Validierungsdaten und verzögerter Koordination. Ohne diese Nachweise sind interne Ursachen nur teilweise aus globalen Beobachtungen ableitbar.

Diese Maßnahmen bleiben neutral zu Intention und Haftung. Sie prüfen, ob eine Kontrolle existierte, ob sie wirkte, ob ihr Ergebnis beobachtbar war und wie schnell das System wieder stabil wurde. Das ist eine belastbare Verantwortlichkeitsmethode statt der Annahme, ein Routing-Anomaliebeleg beweise automatisch Schädigungsabsicht oder fordere eine Sicherheitstechnologie, die jedes Routenbild verhindern müsse.

Registry-Evidenz und Betriebsrealität

Registry-Einträge und ROAs sind essenzielle Evidenz. Ein Datenbankeintrag verknüpft administrative Informationen mit einer Netzressource, während ein ROA die Herkunftsautorisierung eines Ressourceninhabers ausdrückt.[8][13] Genauigkeit, Eindeutigkeit und aktuelle Sicherheitsmetadaten machen diese Datensätze für Betreiber und Ermittler nutzbar. Sie helfen zu klären, wer für eine Ressource dokumentiert ist und welches ASN berechtigt ist, ein Präfix zu originieren.

Datensätze steuern das Internet jedoch nicht per Erlass. Ein BGP-Sprecher wendet seine laufende Policy auf empfangene Updates an. Ein Relying Party muss aktuelle RPKI-Daten erhalten. Ein Router muss Validierungsergebnisse empfangen. Ein Betreiber muss entscheiden, was verworfen, bevorzugt oder untersucht wird. Exportfilter müssen die beabsichtigten Beziehungen abbilden, und Monitoring muss offenlegen, wann tatsächliche Verbreitung von Absicht abweicht. Koordinierte Wiederherstellung muss dann Evidenz in Korrekturmaßnahmen übersetzen.

Der getrennte RIPE NCC-Löschvorgang unterstreicht beide Seiten dieser Struktur. Registry und RPKI-Service waren bedeutsam, weil das Entfernen von Autorisierungen das im Relying Party sichtbare Origin-Evidenzbild verändern konnte. Doch die Löschung schrieb nicht zentral AS-Pfade neu oder zwang Netze, AS12389-Ankündigungen zu akzeptieren. Die operative Kontinuität hing von Wiederherstellung des Datensatzes, aktueller Cache-Verfügbarkeit, lokaler Routing-Policy, aktiven Filtern und Response-Koordination als Kette ab.

Diese Realität verhindert, die Registry als souveräne Pfaddurchsetzungsinstanz zu behandeln. Sie vermeidet aber ebenso, Datensätze als irrelevant abzutun, nur weil die Durchsetzung lokal ist. ROAs können maschinenprüfbare Evidenz liefern, die bestimmte Ursprungskonflikte handhabbar macht. Ihr Nutzen ist am größten, wenn Datensatzgenauigkeit, Verteilung, Cache-Gesundheit und Operator-Policy gemeinsam messbar sind.

Spätere Designkontexte, keine rückwirkenden Anforderungen

RFC 8212 beschreibt für externe BGP-Sitzungen eine Default-Reject-Haltung, wenn Import- oder Export-Policy nicht explizit konfiguriert ist.[18] Als Designkontext reduziert dieser Ansatz das Risiko, dass eine unvollständig spezifizierte Beziehung standardmäßig Routen austauscht. Er ist relevant für künftige Konfigurationsdisziplin, aber kein Beleg dafür, dass alle genannten Betreiber das im April 2020 so einsetzten oder dass RFC als rückwirkender Haftungsstandard gilt.

RFC 9234 definierte später BGP Roles und den Only-to-Customer-Mechanismus und stellt Protokollsignale bereit, die bestimmte Route-Leaks anhand von Beziehungsstruktur abbilden sollen, die ROV nicht trägt.[19] Diese Arbeiten adressieren Informationslücken, die ROV nicht hält: ob ein Pfad in der Beziehungskonfiguration konsistent weitergegeben wird. Sie sind keine Beschreibung der Ursache des Ereignisses 2020 oder ein damals zwingendes Verfahren auf den beobachteten Sessions.

RFC 9319 analysierte später betriebliche Überlegungen zu RPKImaxLengthund Exposure durch gefälschte Ursprungs-Subpräfixe.[20] Sie hilft zu erklären, wie eine deckende Autorisierung eine spezifischere Ankündigung ein- oder ausschließen kann. Sie legt aber nicht die exakte ROA-Konfiguration für jedes betroffene Präfix im Jahr 2020 fest und kann die 8.870-Präfix-Zählung nicht in Invalid-Routen umsetzen.

Zusammen zeigen diese späteren Dokumente, warum geschichtete Architektur notwendig ist. Default-Reject-Policies adressieren fehlende Beziehungsdefinitionen. BGP Roles und Pfadsignale können manche policybezogene Leaks abfangen. RPKI kann manche Herkunftskonflikte und Prefix-Längen-Verstöße erfassen. Monitoring und Koordination bleiben erforderlich, weil kein Mechanismus alle Routingeigenschaften validiert.

Was dieser Beitrag nicht vermischt

Das Ereignis 2020 ist klar getrennt von der finanziellen Routing-Anomalie von Rostelecom im Jahr 2017. Das frühere Ereignis betraf einen anderen Zeitpunkt, ein anderes betroffenen Routen-Set, eine andere Dauer und eine andere Attributionfrage. Es wird hier nicht erneut erzählt, und Evidenz aus dieser Episode darf nicht genutzt werden, um Absicht, wiederkehrende Kausalität oder Verantwortung für das Ereignis am 1. April 2020 abzuleiten. Diese Analyse bleibt auf den beobachteten AS12389-Verbreitungspfad, seine rund einstündige Beobachtung und die für dieses Ereignis relevanten Kontrollen begrenzt.

Der Beitrag ist auch klar abgegrenzt von einer allgemeinen Analyse von ROA-Misskonfigurationen und generellen Ausfallsmuster-Abhängigkeiten. Die RIPE NCC-Löschung ist hier nur wegen des separaten zeitgleichen Vorfalls mit einem dokumentierten Überschneidungsbereich von drei PI-Inhabern und 12 Präfixen relevant.[4][5] Eine breitere Theorie zu ROA-Erstellungsfehlern würde die konkrete Frage verwischen: Welche Teile des gemischten Routing-Ereignisses konnte Origin-Validierung erkennen, und welche erforderten pfadbezogene Policy und Grenzfilter?

Diese Abgrenzung bewahrt den evidenziellen Kern des Ereignisses. Die 2020er Verantwortlichkeitsprüfung hängt an AS12389-Ankündigungen, Verbreitung über AS20764, AS174 und AS3356, differenzierten Routen-Kategorien, zeitabhängigem ROA-Zustand und unabhängig kontrollierten Routing-Entscheidungen. Ohne diese Elemente wird die Analyse entweder zu einer Wiederholung des anderen Rostelecom-Ereignisses oder zu einem abstrakten RPKI-Essay.

Zentrale Unklarheiten

Die auslösende interne Fehlersequenz bleibt unbekannt. Die genaue Aufteilung zwischen learned-route-Leaks und re-originated more-specifics bleibt unbekannt. Der vollständige Satz betroffener Forwarding-Pfade und Endnutzer-Symptome bleibt unbekannt. Der RPKI-Stand jedes Relying Network zum Zeitpunkt jedes Ereignismoments bleibt unbekannt. Die Import- und Exportfilter aller Verbreitungsnetze bleiben unbekannt.

Auch die vollständige Reaktionschronologie ist nicht vorliegend. Qrator dokumentierte Echtzeitwarnung, Zusammenarbeit, Fehlerbehebung und Wiederherstellung, jedoch nicht jede interne Entscheidung.[1] Die Evidenz belegt weder eine verantwortliche Einzelperson, eine Absicht zur absichtsvollen Umleitung, eine Straftat, einen Verstoß noch rechtliche Haftung. Sie misst keinen Ausfall bei jedem Dienst, dessen Routen im betroffenen Set enthalten gewesen sein könnten.

Dies sind keine Randbemerkungen. Sie definieren die Grenze zwischen beobachtetem Infrastrukturevidenz und Spekulation. Eine präzise Darstellung kann Verantwortungsinhaber und Eindämmungsmöglichkeiten benennen und zugleich Motivation und Rechtsfolgen im Ungeklärten belassen.

Fazit

Das Ereignis von Rostelecom am 1. April 2020 zeigte, dass Origin-Evidenz und Route-Policy-Evidenz unterschiedliche Fragen beantworten. Qrator beobachtete ein großes AS12389-Ereignis, das gegen 19:28 UTC begann, rund eine Stunde anhielt und über Rascom, Cogent und Level 3 verbreitet wurde. Es wurden 8.870 betroffene Präfixe in nahezu 200 autonomen Systemen gezählt und eine Echtzeit-Koordination mit Rostelecom berichtet.[1] Diese Beobachtungen definieren Umfang, Verbreitung und Reaktion, nicht aber eine vollständige interne Ursache.

Die gleichzeitige Löschung von 2.669 RIPE NCC ROAs war ein separater operativer Ausfall. Spätere Analysen fanden keinen direkten Zusammenhang zum Rostelecom-Leck und identifizierten nur drei PI-Inhaber mit 12 Präfixen als Überschneidung.[3]-[5] Diese Evidenz verhindert sowohl Kausalvermischung als auch die Aussage, alle betroffenen Routen seien Invalid gewesen.

ROV konnte in einigen Fällen nützliche Evidenz für unautorisierte Ursprünge oder überlange more-specifics liefern, wenn aktuelle deckende ROAs und durchsetzende Policies vorlagen. Es konnte jedoch nicht den vollständigen AS-Pfad validieren oder jedes valid-origin-Policy-Leck verhindern. Die verbleibende Kontrolle lag bei laufender Import-/Export-Policy, beziehungsbewusster Filterung, aktuellen Caches, Route-Monitoring und koordinierter Wiederherstellung.

Die Verantwortlichkeitslehre ist damit verteilt, aber konkret. Rostelecom besaß die Entscheidung über seine Ankündigungs- und Exportvorgänge. Verbreitungsnetze besaßen ihre Grenzentscheidungen. Präfixinhaber besaßen die Genauigkeit ihrer Autorisierungen und Kontakte. RIPE NCC besaß die Zuverlässigkeit seines Zertifikats- und ROA-Management-Service. Relying Parties besaßen Datenaktualität und Durchsetzung. Monitoring-Anbieter besaßen Qualität und Geschwindigkeit ihrer Beobachtung und Alarme. Niemand kontrollierte das ganze System, aber jeder kontrollierte einen erkennbaren Teil der operativen Kontinuität.