Telekom Malaysias Route-Leak 2015: Verantwortlichkeitstest

Zusammenfassung

Unabhängige Überwachung datiert den Beginn eines großen BGP-Ankündigungsbursts von Telekom Malaysias AS4788 auf etwa 08:43 UTC am 12. Juni 2015. BGPMon berichtete von etwa 179.000 angekündigten Präfixen, während RFC 7908 das Ereignis später als ein großes Route-Leak-Beispiel anführte, bei dem Level 3 etwa 179.000 Präfixe akzeptierte und weiterleitete. [2][10]
Verschiedene Analysen berichten unterschiedliche Routenzahlen, da sie unterschiedliche Kollektoren, Zeitfenster und Definitionen verwenden. Geoff Hustons Analyse diskutierte etwa 2.500 neu sichtbare Routen und untersuchte einen Satz von 22.577 betroffenen Routen. Diese Zahlen können nicht verantwortungsvoll zu einer falschen Genauigkeit verschmolzen werden. [1][2]
AS3549 von Level 3 hat die AS4788-Ankündigungen nicht nur beobachtet. Es akzeptierte und verbreitete sie und vergrößerte den Schadensradius durch ein großes globales Transitnetzwerk. ThousandEyes maß schweren Paketverlust und terminale Pfade an mehreren Points of Presence von Level 3. [2][3]
Die Beweise stützen ein Beziehungsrichtlinien-Leak: Routen, die von Peers gelernt wurden, scheinen an vorgelagerte Transit-Provider weitergegeben worden zu sein. Die genaue Router-Konfiguration, Route-Map, der Befehl, die Software und die Genehmigungskette von Telekom Malaysia sind in diesem Paket nicht öffentlich. [1]
Die Verantwortlichkeit ist durch Kontrolle geteilt. AS4788 kontrollierte seine Exportrichtlinie und den Lebenszyklus der Route-Map. AS3549 kontrollierte, was es von einem Kunden akzeptierte, die Volumen- und Pfadprüfungen, die angewendet wurden, und ob akzeptierte Routen weitergeleitet wurden. Nachgelagerte Netzwerke kontrollierten ihre eigene Importrichtlinie und Überwachung.
Gewöhnliche RPKI-Route-Origin-Validation ist keine vollständige Antwort auf dieses Ereignis. Die meisten geleakten Pfade behielten legitime Ursprünge. Die Ursprungsautorisierung kann gültig sein, während ein Pfad die Exportabsicht des Kunden, Peers oder Providers verletzt. [1][15][16]
Spätere Standards verdeutlichen mögliche Kontrollen. RFC 8212 macht explizite Import- und Exportrichtlinie zur Standardanforderung für eBGP, während RFC 9234 beziehungsbewusste BGP-Rollen und das Only-to-Customer-Attribut hinzufügt. Sie sind retrospektive Kontrollrichtlinien, kein Beweis für eine Compliance-Verletzung im Jahr 2015. [11][12]
Eine glaubwürdige Reparaturbehauptung erfordert mehr als Wiederherstellung. Es bedarf einer eingefrorenen Rekonstruktion des Ankündigungssatzes, der beabsichtigten Session-Richtlinie, Vorher-Nachher-Konfigurationsbeweise, Tests gegen dieselbe Leak-Klasse, unabhängige Routenbeobachtung und den Beweis, dass sowohl die exportierende als auch die akzeptierende Seite eine Wiederholung verhindern können.

Eine Routenankündigung wurde zur Autorität über den Verkehr anderer

BGP wird oft als das Protokoll eingeführt, das dem Internet sagt, wo Netzwerke sind. Diese Beschreibung ist zutreffend, aber unvollständig. Eine BGP-Ankündigung ist auch ein Anspruch auf operative Autorität.

Wenn ein autonomes System einem anderen mitteilt, dass ein Präfix über es erreichbar ist, kann der Empfänger diesen Pfad bevorzugen und ihn weiter ankündigen. Andere Netzwerke können dann Verkehr auf den angekündigten Pfad leiten. Die Route trägt keine Garantie, dass das ankündigende Netzwerk genügend Kapazität hat, dass der Pfad den kommerziellen Beziehungen entspricht oder dass jeder zwischengeschaltete Betreiber Transit beabsichtigte. BGP verteilt Erreichbarkeitsinformationen und AS-Pfad-Daten; die Richtlinie bestimmt, welche Behauptungen ein Netzwerk akzeptiert und wiederholt. [8]

Diese Richtlinienebene ist der Punkt, an dem das Telekom-Malaysia-Ereignis von 2015 global folgenreich wurde.

Unabhängige Quellen sagen, dass ein großer Ankündigungsburst um etwa 08:43 UTC am 12. Juni begann. Telekom Malaysias AS4788 kündigte eine riesige Menge von Routen an Level 3's AS3549 an. Level 3 akzeptierte diese Routen und leitete sie an Peers und Kunden weiter. Der Verkehr folgte den geänderten Pfaden. Der Pfad durch AS3549 und AS4788 konnte unter der Routing-Richtlinie attraktiv erscheinen, obwohl die Verbindungen das resultierende Verkehrsaufkommen nicht sicher bewältigen konnten. Paketverlust und Latenz stiegen, und Dienste weit über Telekom Malaysias eigenen Kundenstamm hinaus wurden schwer oder unmöglich erreichbar. [2][3]

Das Ereignis war kein gefälschtes Zertifikat, keine Kompromittierung eines Domainnamens und keine erfundene Routenherkunft im einfachsten Sinne. Viele betroffene Präfixe endeten immer noch an ihren legitimen Ursprungsautonomen Systemen. Die schädliche Veränderung war, dass AS4788 sich als Transit für Routen einfügte, die es in dieser Richtung nicht exportieren sollte. Ein Pfad kann syntaktisch gültig, schleifenfrei und ursprungsgültig sein, während er die wirtschaftliche und operative Beziehung verletzt, unter der er gelernt wurde.

Diese Unterscheidung ist wichtig für die Verantwortlichkeit. Wenn das Problem nur als "Telekom Malaysia hat Routen durchsickern lassen" beschrieben wird, scheint die Verantwortung am exportierenden Netzwerk zu enden. Aber BGP-Weiterleitung ist bei jeder Session bilateral. Eine Seite kündigt an; die andere Seite entscheidet, was sie akzeptiert, bevorzugt und weiterleitet. Ein großes Transitnetzwerk hat eine größere Weiterleitungsmacht als ein isolierter Kunde. Diese Macht schafft eine entsprechende Filter- und Beweispflicht.

Die zentrale Frage ist nicht, welcher Betreiber zuerst den Fehler gemacht hat. Es ist, wie viele unabhängige Kontrollen die praktische Fähigkeit hatten, den Fehler zu stoppen, bevor er zum Ausfall anderer Netzwerke wurde.

Die Chronologie ist an den Rändern klar und in den Netzwerken unvollständig

BGPMon berichtete, dass AS4788 um 08:43 UTC begann, einen massiven Routensatz anzukündigen. Seine Überwachung sah einen starken Anstieg der BGP-Update-Nachrichten zur gleichen Zeit, als der Paketverlust begann. Die Analyse beschrieb etwa 179.000 angekündigte Präfixe und gab ein betroffenes Facebook-Präfix als Beispiel für einen Pfad, der durch AS3549 und AS4788 verlief, bevor er den legitimen Ursprung erreichte. [2]

ThousandEyes beschrieb unabhängig dieselbe grobe Abfolge. Es beobachtete neue Pfade durch Telekom Malaysia und Level 3, schweren Paketverlust und terminale Routen an Orten wie Amsterdam, Chicago, Frankfurt, London, Los Angeles, Seattle und Washington. Es sagte, Level 3 hörte um etwa 10:45 UTC auf, die Routen zu akzeptieren, und der Dienst begann sich zu normalisieren. [3]

BGPMon berichtete über eine Besserung um etwa 10:40 und eine umfassendere Bereinigung um etwa 11:15. Diese Zeiten sollten attribuiert bleiben. Ein Routenkollektor, eine aktive Messplattform, ein Transitbetreiber und ein Endbenutzer beobachten dasselbe Ereignis nicht zum selben Zeitpunkt. Ein Filter kann neue Ankündigungen stoppen, während veraltete Pfade anderswo ausgewählt bleiben. Rücknahmen können ungleichmäßig weitergegeben werden. Überlastung kann fortbestehen, nachdem der Kontrollebenenauslöser entfernt wurde. Die Wiederherstellung ist daher eine Abfolge, kein universeller Zeitstempel.

Die RIPE-Atlas-Analyse nutzte später das Ereignis, um zu untersuchen, wie sich große Ausfälle in der Kerninfrastruktur auf die End-to-End-Konnektivität auswirken. Es fand Beweise sowohl für Verkehr, der um unter Stress stehende Infrastruktur herumgeführt wurde, als auch für End-to-End-Ausfälle. Die Autoren waren explizit zur Repräsentativität: Selbst ein diverses globales Messsystem beobachtet nur einen endlichen Satz von Pfaden und Zielen. [4]

Die öffentliche Chronologie hat eine starke externe Aufzeichnung und eine schwache interne Aufzeichnung.

Externe Beobachter können den ungefähren Start, die geänderten Pfade, das Routenupdate-Volumen, den Paketverlust, die Latenz und die allgemeine Wiederherstellung identifizieren. Sie können die private Routen-Map, das Operator-Terminal, die genehmigte Änderung, das konfigurierte Präfixlimit, die Alarmwarteschlange oder das Entscheidungsgespräch zwischen Telekom Malaysia und Level 3 nicht sehen.

Diese Lücke sollte die Sprache des Artikels prägen.

Es ist vertretbar zu sagen, dass AS4788 die Routen ausgesendet hat, AS3549 sie akzeptiert und weitergeleitet hat und die globale Erreichbarkeit darunter litt. Es ist vertretbar zu sagen, dass das Muster mit dem Export von von Peers gelernten Routen zu einem vorgelagerten Provider konsistent ist. Es ist nicht vertretbar, den genauen Befehl, Router, Mitarbeiter, Änderungsticket oder Softwarefehler ohne einen authentifizierten Operator-Datensatz zu identifizieren.

Geoff Hustons Analyse verwendet probabilistische Formulierungen über einen Routenrichtlinienfehler und enthält scheinbare AS-Nummern-Tippfehler in einigen Passagen. Telekom Malaysias Netzwerk ist AS4788. Der Artikel sollte nicht aus scheinbaren AS4877- oder AS4778-Referenzen zusätzliche Akteure machen oder sie verwenden, um Gewissheit über ein internes Gerät zu erzeugen. [1]

Eine vollständige Verantwortlichkeitsaufzeichnung würde die externe Zeitlinie mit internen Beweisen verbinden:

die letzte bekannte gute Exportrichtlinie;
die vorgeschlagene und normalisierte Änderung;
die Zeit, zu der jeder Router oder jede Session sie erhalten hat;
die Anzahl und Art der für den Export ausgewählten Präfixe;
Alarme für Routenvolumen und Beziehungsverletzungen;
Akzeptanz- und Maximal-Präfix-Status bei AS3549;
Eskalationskontakte und Nachrichten;
der Befehl oder die automatisierte Aktion, die die Weiterleitung stoppte;
Kollektor-Beweise, die Rücknahme und Konvergenz zeigen;
Tests, die belegen, dass die reparierte Richtlinie dieselbe Routenklasse zurückweist.

Ohne diese Kette ist die Wiederherstellung sichtbar, aber das institutionelle Lernen bleibt schwer zu überprüfen.

Die Präfixzahlen beschreiben unterschiedliche Ansichten, nicht eine umstrittene Tatsache

Große Internet-Vorfälle ziehen eine einprägsame Zahl an. Hier kann dieser Instinkt die Aufzeichnung ungenauer machen.

BGPMon schrieb, dass AS4788 begann, etwa 179.000 Präfixe anzukündigen, und bezog sich später auf etwa 176.000 durchgesickerte Präfixe. RFC 7908 zitiert das "massive Telekom Malaysia Route Leak" mit etwa 179.000 Präfixen. ThousandEyes beschrieb einen großen Teil der globalen Routing-Tabelle. [2][3][10]

Hustons Analyse verwendete unterschiedliche Ansichten des Ereignisses. Es zeigte eine Netto-Routingtabellenänderung mit Tausenden von neu sichtbaren und zurückgezogenen Routen und untersuchte dann 22.577 Routen in einem bestimmten betroffenen Satz. [1]

Diese Zahlen können nebeneinander existieren, weil ein BGP-Ereignis nicht nur eine natürliche Einheit hat.

Ein Beobachter kann jede UPDATE-Nachricht, jedes einzigartige Präfix, das über einen unerwarteten Pfad angekündigt wurde, jedes Präfix, das an einem Kollektor neu sichtbar wurde, jeden geänderten besten Pfad, jede spezifischere Route, jede noch zu einer ausgewählten Zeit vorhandene Route oder jeden betroffenen Ursprung zählen. Kollektoren erhalten unterschiedliche Feeds. Eine Route kann angekündigt, zurückgezogen und erneut angekündigt werden. Einige Pfade sind an einem Kollektor sichtbar, an einem anderen nicht. Eine vollständige Tabelle und ein gefilterter betroffener Satz beantworten unterschiedliche Fragen.

Die verantwortungsvolle redaktionelle Wahl ist, die Messdefinition zu bewahren.

Der Artikel kann sagen, dass BGPMon und RFC 7908 in ihren Rekonstruktionen etwa 179.000 durchgesickerte Ankündigungen oder Präfixe beschrieben haben. Er kann sagen, dass Hustons separate Analyse einen Satz von 22.577 Routen untersuchte und Tausende von Tabellenadditionen und -rücknahmen beobachtete. Er sollte die Werte nicht mitteln, das größte für Dramatik auswählen oder eines als vollständige Zählung der Benutzerauswirkungen präsentieren.

Dieselbe Disziplin gilt für betroffene Dienste. BGPMon und ThousandEyes identifizierten Beispiele mit großen Plattformen und Finanzdiensten. Diese Beispiele zeigen Umfang und Kollateraleffekte. Sie belegen nicht, dass jedes Präfix denselben Paketverlust erlitt, jeder Dienst nicht verfügbar war oder jeder Benutzer durch AS4788 leitete.

Zahlen werden zu Verantwortlichkeitsbeweisen, wenn ihre Definitionen beibehalten werden:

Ankündigungszahltestet, ob das Exportvolumen anomal war;
Einzigartige Präfixzahltestet die Breite der beanspruchten Routing-Autorität;
Geänderte Best-Path-Zahltestet, wie viele Netzwerke den Leak ausgewählt haben;
Kollektor-Sichtbarkeittestet die Verbreitung;
Verkehrsvolumen und Paketverlusttesten den operativen Schaden;
Anzahl betroffener Kunden und Anwendungentestet die geschäftlichen Auswirkungen;
Rücknahmedauertestet die Eindämmung.

Jede Messung sollte einen Eigentümer, einen Schwellenwert und einen beibehaltenen Datensatz haben. Ein Transit-Provider könnte den normalen Satz eines Kunden von einigen tausend Präfixen akzeptieren, aber eine plötzliche Größenordnungsänderung unter Quarantäne stellen. Ein Routenüberwachungssystem könnte Pfade erkennen, die die Erwartungen des Kundenkegels verletzen, selbst wenn das rohe Präfixvolumen unter einem statischen Grenzwert bleibt. Ein öffentlicher Postmortem könnte beide Maßnahmen erklären, anstatt eine einzige Überschriftenzahl zu bieten.

Falsche Genauigkeit ist nicht nur ein Schreibproblem. Sie kann verbergen, welche Kontrolle versagt hat.

Beziehungsrichtlinie ist die unsichtbare Struktur hinter der BGP-Erreichbarkeit

Das Internet ist kein flaches Netz, in dem jedes autonome System jedem anderen System kostenlosen Transit anbietet. Netzwerke kaufen Transit, verkaufen Transit und peeren unter Beziehungen, die die Routenrichtlinie prägen.

Eine vereinfachte operative Regel funktioniert so:

von Kunden gelernte Routen dürfen an Kunden, Peers und Provider angekündigt werden;
von Peers gelernte Routen dürfen an Kunden angekündigt werden, aber normalerweise nicht an einen anderen Peer oder Provider;
von Providern gelernte Routen dürfen an Kunden angekündigt werden, aber normalerweise nicht an einen anderen Provider oder Peer.

Diese Regeln produzieren das bekannte "Valley-Free"-Modell. Ein Pfad kann von Kunden zu Providern aufsteigen, höchstens eine Peer-Beziehung überqueren und zu Kunden absteigen. Ein Pfad, der absteigt und wieder aufsteigt, kann darauf hindeuten, dass ein Netzwerk unbeabsichtigten Transit bereitstellt. [1][10]

Tatsächliche kommerzielle Beziehungen sind komplizierter. Zwei Netzwerke können an verschiedenen Orten, Adressfamilien oder Diensten unterschiedliche Rollen haben. Teiltransit, bezahltes Peering, Route-Server und regionale Arrangements passen nicht immer in ein einziges Label. Diese Komplexität ist ein Grund, Richtlinien zu dokumentieren und zu testen, nicht ein Grund, sie wegzulassen.

Hustons Rekonstruktion besagt, dass AS4788 anscheinend Routen von Exchange-Point-Peers gesammelt und an vorgelagerte Transitnetzwerke weitergegeben hat. In diesem Modell wurden lateral gelernte Routen "bergauf" exportiert. Level 3 akzeptierte und leitete die Pfade dann weiter. [1]

Das Protokoll selbst kann nicht jede private Geschäftsbeziehung aus dem AS-Pfad ableiten. Eine Folge legitimer AS-Nummern sagt nicht aus, ob eine Route vertraglich und operativ erlaubt war, durch sie zu reisen. Dieses Wissen muss in lokaler Richtlinie, veröffentlichten Routing-Objekten, ausgehandelten Rollen, Communities, Kundenkegeldaten oder einem anderen Validierungssystem codiert sein.

Deshalb bleiben Route Leaks schwierig. Ein Router kann ein gültiges BGP-UPDATE von einem authentifizierten Nachbarn empfangen, einen legitimen Ursprung sehen, einen schleifenfreien AS-Pfad konstruieren und dennoch eine Route akzeptieren, die die beabsichtigte Beziehung verletzt.

Die operative Verantwortlichkeit erfordert daher, dass Netzwerke ihre Erwartungen wo möglich maschinenprüfbar machen:

Klassifizieren Sie jede eBGP-Session und jede Ausnahmerichtlinie;
Definieren Sie die Präfixe und Kundenpfade, die vom Nachbarn erwartet werden;
Beschränken Sie Exporte entsprechend der Art, wie Routen gelernt wurden;
Vergleichen Sie eine vorgeschlagene Richtlinie mit der beabsichtigten Beziehung;
Weisen Sie unerklärliche Erweiterungen zurück oder stellen Sie sie unter Quarantäne;
Behalten Sie eine für Menschen lesbare Erklärung für Ausnahmen;
Testen Sie die Richtlinie unter repräsentativen Volltabellenbedingungen.

Der öffentliche Vorfall zeigt, was passiert, wenn die Beziehungsabsicht implizit bleibt oder die Durchsetzung ineffektiv ist. Eine Route kann eine Session überqueren und zu einer globalen Behauptung werden, bevor ein Mensch ein Ticket liest.

AS4788 kontrollierte den Export, aber AS3549 kontrollierte Akzeptanz und Verbreitung

Telekom Malaysia hatte die direkteste Kontrolle über den Ankündigungssatz, der AS4788 verließ. Ein exportierendes Netzwerk sollte wissen, welche Routen es ursprünglich angekündigt hat, welche es von Kunden gelernt hat, welche von Peers oder Providern und welche Klassen an jeden Nachbarn gesendet werden dürfen.

Diese Kontrolle beginnt vor der Konfigurationsaktivierung.

Eine Änderung sollte in die tatsächliche Präfix- und AS-Pfad-Richtlinie kompiliert werden, die ein Router durchsetzen wird. Eine Überprüfung sollte das Ergebnis mit erwarteten Kundenkegeln, Routenzahlen und Beziehungsregeln vergleichen. Eine Testumgebung oder ein Offline-Bewerter sollte repräsentative Routen durch die Richtlinie führen und zeigen, was exportiert würde. Eine unabhängige Prüfung sollte Peer- oder Provider-gelernte Routen markieren, die für eine andere Nicht-Kunden-Session ausgewählt wurden.

Der öffentliche Datensatz belegt nicht, ob solche Kontrollen bei AS4788 existierten, ob eine Routinekonfiguration geändert wurde oder ob ein latenter Zustand ausgelöst wurde. Er belegt das Ergebnis: Ein großer, unsicherer Routensatz wurde exportiert.

Die Kontrollgrenze von Level 3 ist getrennt und ebenso wichtig für die globale Verbreitung.

AS3549 entschied, ob von AS4788 empfangene Routen teilnahmeberechtigt waren, wie sie bevorzugt wurden und wo sie angekündigt wurden. Ein großer Transit-Provider hat kundenspezifisches Wissen, das beliebige Dritte nicht haben. Er kann die erwartete Präfixanzahl, registrierte Kundenrouten, beobachtete Historie, Kundenkegelbeziehungen und den Sessionzweck kennen. Er kann anwenden:

explizite Importrichtlinie;
Präfixlisten, die aus authentifizierten Routing-Daten abgeleitet sind;
AS-Pfad- und Kundenkegelbeschränkungen;
Maximal-Präfix-Schwellenwerte;
Routen-Längen- und Bogon-Prüfungen;
beziehungsbewusste Leak-Erkennung;
Quarantäne- oder Niedrigpräferenz-Richtlinie für Anomalien;
menschliche Genehmigung für außergewöhnliche Erweiterungen.

BGPMons Bericht besagt, dass Level 3 die Ankündigungen akzeptierte und an Peers und Kunden weiterleitete. Die Routen zogen dann Verkehr an und trugen zu Überlastungen in Level 3 und großen Peering-Standorten bei. [2]

Dies bedeutet nicht, dass ein vorgelagerter Provider jede Kundenroute garantieren kann. Statische Filter können veralten. Multi-Homed-Kunden können legitimerweise Ankündigungen ändern. Notfall-Routing kann einen Satz erweitern. Komplexe Richtlinien können Kundenkegel schwer berechenbar machen. Ein Filter, der zu streng ist, kann selbst einen Ausfall verursachen.

Aber diese Kosten löschen die Handlungsfähigkeit des Providers nicht aus. Sie definieren das technische Problem.

Ein Transit-Provider mit globaler Verbreitungsmacht sollte antworten können:

Welcher Bereich von Routenzahl und Pfadform war für diesen Kunden normal?
Welche Änderungen erforderten eine Vorabkoordination?
Enthielt der akzeptierte Satz Routen mit anderen großen Peers oder Providern hinter dem Kunden?
Existierte ein Maximal-Präfix-Schwellenwert und war er gegen eine realistische Basislinie gesetzt?
Hatte die Session eine Ausnahme, die Prüfungen deaktivierte oder schwächte?
Welcher Alarm löste zuerst aus?
Wer konnte die Routen unterdrücken, ohne auf den Kunden zu warten?
Wie wurde Kollateralverkehr während der Untersuchung geschützt?

Verantwortlichkeit folgt dieser praktischen Fähigkeit, Schaden zu begrenzen. AS4788s Exportfehler und AS3549s Akzeptanz sind keine sich gegenseitig ausschließenden Erklärungen. Sie sind aufeinanderfolgende Kontrollfehler in derselben Verbreitungskette.

Transitkonzentration verwandelte Richtlinienfehler in gemeinsamen Schaden

Nicht jeder Route Leak verursacht einen globalen Vorfall. Der Schadensradius hängt davon ab, wo der Leak akzeptiert wird, wie attraktiv der Pfad wird, wie weit er verbreitet wird und ob die empfangenden Netzwerke Kapazität haben, den umgeleiteten Verkehr zu tragen.

Level 3 war ein großer globaler Transit-Provider. Sobald AS3549 die Pfade verbreitete, konnten Netzwerke und Kunden weit entfernt von Malaysia sie auswählen. Verkehr, der normalerweise direkte, regionale oder besser ausgebaute Routen nahm, wurde auf einen Pfad durch Level 3 und AS4788 gezogen. [2][3]

Zwei Schadensmechanismen folgten.

Der erste war die direkte Pfadumleitung. Ein Zielpräfix konnte einen ausgewählten Pfad durch AS3549 und AS4788 erhalten. Pakete reisten dann zu Telekom Malaysia, obwohl es nicht beabsichtigt war, globalen Transit für dieses Ziel bereitzustellen. Die Verbindung konnte gesättigt werden, Pakete konnten verworfen werden und die Latenz konnte steigen.

Der zweite war kollaterale Überlastung. Ein Dienst musste keinen durchgesickerten Pfad selbst auswählen, um zu leiden. Wenn er auf die Kapazität von Level 3 oder einen überlasteten Point of Presence angewiesen war, konnte die außergewöhnliche Verkehrslast seine normale Route beeinträchtigen. ThousandEyes beschrieb Beispiele, in denen die eigene Route eines Dienstes unverändert blieb, aber die Überlastung innerhalb von Level 3 die Verfügbarkeit reduzierte. [3]

Dieser zweite Mechanismus ist wichtig, weil er die Verantwortlichkeitslinse über eine Liste durchgesickerter Präfixe hinaus erweitert. Gemeinsame Transitinfrastruktur kann Schaden auf Kunden übertragen, deren Routing-Richtlinie nicht direkt falsch ist. Kapazität, Isolierung und Verkehrstechnik werden Teil des Eindämmungsproblems.

Netzwerke können nicht jede Verbindung für einen beliebigen Bruchteil der globalen Tabelle bereitstellen, der sie plötzlich wählt. Wirtschaftliche Grenzen sind real. Dennoch kann ein Transit-Provider Kontrollen entwerfen, sodass ein anomaler Routensatz nicht von vornherein diese Verkehrsautorität erlangt.

Das Ereignis verbindet daher Routing-Sicherheit mit Konzentrationsrisiko. Ein hochvernetztes Transitnetzwerk verbessert die Erreichbarkeit unter normalen Bedingungen. Dieselbe Konnektivität verstärkt einen Richtlinienfehler, wenn unsichere Routen akzeptiert und verbreitet werden. Skalierung ist sowohl eine Resilienzressource als auch ein Schadensradius-Multiplikator.

Verantwortungsvoller Betrieb sollte die Verbreitungsreichweite als Risikovariable behandeln:

eine kleine lokale Kundenankündigung kann normale automatisierte Handhabung verwenden;
eine plötzliche Kundenankündigung von Routen aus vielen unabhängigen großen Netzwerken sollte Quarantäne oder Validierung erfordern;
eine Änderung, die Pfade über viele Regionen hinweg verändern würde, sollte eine Outside-In-Messung auslösen;
ein Provider sollte wissen, welche Points of Presence und Verbindungen umgeleiteten Verkehr erhalten würden;
Eindämmung sollte möglich sein, ohne gesunde Kundenrouten unnötig zu deaktivieren.

Das Ziel ist nicht, Automatisierung zu eliminieren. Es ist, Automatisierung proportional zu der Autorität zu machen, die sie gewährt.

Maximal-Präfix-Kontrollen helfen, aber sie sind keine vollständige Richtlinie

Maximal-Präfix-Limits sind eine intuitive Verteidigung gegen einen großen Leak. Wenn ein Kunde normalerweise einen begrenzten Satz ankündigt und plötzlich eine enorme Tabelle sendet, kann der Provider warnen, neue Routen ablehnen oder die Session beenden.

BGPMon deutete an, dass das anomale Routenvolumen auch Maximal-Präfix-Limits auf Level 3s Sessions mit anderen großen Netzwerken auslösen könnte, was zu weiterem Churn und Pfadänderungen führt. [2]

Diese Beobachtung offenbart sowohl den Wert als auch die Gefahr einfacher Schwellenwerte.

Am Kundenrand kann eine gut kalibrierte Maximal-Präfix-Kontrolle eine unplausible Erweiterung vor einer breiten Verbreitung stoppen. Bei nachgelagerten Sessions kann derselbe Mechanismus reagieren, nachdem die schlechten Routen bereits in einen großen Provider gelangt sind, möglicherweise eine gesamte Session fallen lassen und Verkehr woandershin verschieben. Ein Limit kann einen Pfad eindämmen, während es einen anderen destabilisiert.

Effektive Limits erfordern Kontext:

das normale Aggregat und spezifischere Präfixe des Kunden;
erwartetes Wachstum;
Wartungs- und Notfallszenarien;
getrenntes IPv4- und IPv6-Verhalten;
ob abgelehnte Routen geschlossen fehlschlagen oder den letzten bekannten guten Satz behalten;
Alarmeskalation vor einem harten Stopp;
einen sicheren Override-Prozess mit Ablauf;
Test der Antwort unter realistischem Verkehr.

Die Routenzahl kann auch nicht jeden Leak erkennen. Ein Kunde könnte eine kleine Anzahl hochattraktiver spezifischerer Routen durchsickern lassen. Er könnte Routen von einem mächtigen Peer exportieren, ohne das Gesamtvolumen stark zu erhöhen. Er könnte legitime Kundenrouten durch einen ähnlich großen unbefugten Satz ersetzen.

Maximal-Präfix ist daher eine Schicht. Präfixbesitz, Kundenkegelvalidierung, AS-Pfad-Beziehungen, Routenquellen-Tags und Anomalieerkennung adressieren unterschiedliche Fehlerformen.

Eine Nachfallaufzeichnung sollte sagen, welche Schichten existierten, nicht nur, dass "Filter verbessert wurden". Ein nach dem Ereignis hinzugefügter Maximal-Präfix-Schwellenwert wäre ein aussagekräftiger Beweis, wenn der Betreiber die Basislinie, die Schwellenwertlogik, den Antwortmodus und einen Test mit dem rekonstruierten Ankündigungssatz veröffentlicht.

RPKI-Origin-Validation hätte das Pfadrichtlinienproblem nicht gelöst

Routing-Sicherheitsdiskussionen verwenden RPKI oft als allgemeine Antwort auf BGP-Vorfälle. Diese Abkürzung ist hier gefährlich.

Die Resource Public Key Infrastructure ermöglicht es Inhabern von Internetnummernressourcen, kryptografisch überprüfbare Aussagen zu erstellen. Eine Route Origin Authorization identifiziert, welches autonome System berechtigt ist, ein Präfix zu originieren, vorbehaltlich der Präfixlängenregeln der Autorisierung. Route Origin Validation kann eine empfangene Ankündigung klassifizieren, indem es ihr Präfix und ihren Ursprungs-AS mit diesen Autorisierungen vergleicht. [15][16]

Das AS4788-Ereignis von 2015 war weitgehend ein Pfadrichtlinien-Leak, kein einfacher unbefugter Ursprung.

Für viele durchgesickerte Routen blieb der legitime Ursprung am Ende des AS-Pfades. AS4788 schob sich selbst als Transit ein und kündigte die Route an eine Beziehung, wo sie nicht erwartet wurde. Ein Ursprungsvalidator könnte einen autorisierten Ursprung sehen und ihn als gültig klassifizieren, obwohl die Route die Exportabsicht von Peer/Provider verletzte.

Hustons Analyse machte diesen Punkt direkt. In dem von ihm untersuchten Routensatz war nur eine kleine Minderheit, bei der AS4788 als Ursprung auftauchte, was eine gewöhnliche ROA-Filterung adressieren könnte. Der Großteil des Problems betraf Transitinformationen. [1]

Das macht RPKI nicht unwichtig. Ursprungsvalidierung kann unbefugte Ursprünge, versehentliche Fehloriginationen und viele Hijacks stoppen. Sie kann eine Klasse falscher Erreichbarkeit reduzieren. Sie liefert auch authentifizierte Ressourceninformationen, die breitere Kontrollen unterstützen können.

Es bedeutet, dass der Kontrollanspruch präzise sein muss.

"Wir haben ROV eingesetzt" beweist keinen Schutz vor Routen, die gültige Ursprünge, aber ungültige Beziehungspfade haben. Ein Netzwerk benötigt zusätzliche Informationen darüber, wer für wen Transit bereitstellen darf und welche Pfade mit der Richtlinie konsistent sind. RPSL, Kundenkegeldaten, Communities, BGP-Rollen, das Only-to-Customer-Attribut, ASPA-bezogene Arbeiten und betreiberspezifische Filter adressieren Teile dieses Problems auf unterschiedlichen Reifegraden.

Die verantwortungsvolle Botschaft ist geschichtet:

RPKI validiert die Ursprungsautorität;
explizite Import- und Exportrichtlinie schränkt Sessions ein;
beziehungsbewusste Kontrollen schränken die Pfadverbreitung ein;
Überwachung erkennt Anomalien, die statische Daten übersehen;
operative Koordination enthält, was Prävention nicht stoppt.

Die Vermischung dieser Schichten erzeugt falsche Sicherheit und schwächt das Lernen aus Vorfällen.

Route-Registries können Absicht veröffentlichen, aber veraltete Absicht ist keine Kontrolle

Routing Policy Specification Language wurde entwickelt, um Routing-Richtlinien in Internet Routing Registries zu beschreiben. RPSL und RPSLng können Import- und Exportrichtlinien, autonome Systemmengen, Routensätze und verwandte Absichten ausdrücken. [13][14]

Im Prinzip kann ein Provider authentifizierte und gepflegte Richtliniendaten verwenden, um Filter für einen Kunden zu generieren. Ein Kunde kann die Präfixe und AS-Beziehungen veröffentlichen, die er anzukündigen beabsichtigt. Peers können beobachtete Routen mit erklärter Absicht vergleichen.

Hustons Analyse erklärt die Anziehungskraft und die Einschränkungen. Registerdaten können unvollständig, veraltet, über Datenbanken hinweg dupliziert oder zu grob für sitzungsspezifische Beziehungen sein. Komplexe Richtlinien können schwer auszudrücken und zu pflegen sein. Einige Registries erlaubten historisch Dritteinträge mit schwacher Autorität. [1]

Die falsche Lehre ist, dass Route-Registries nutzlos sind. Die richtige Lehre ist, dass ein Registry-Objekt nur dann ein Beweis ist, wenn seine Eigentümerschaft, Aktualität, Reichweite und Verwendung überprüfbar sind.

Eine ausgereifte Filter-Pipeline sollte aufzeichnen:

die Registry und verwendeten Objekte;
Authentifizierung und Wartungsautorität;
die letzte erfolgreiche Aktualisierung;
Erweiterung von AS-Sets in konkrete Präfixe und Pfade;
Konflikte zwischen Registries;
lokale Ausnahmen;
das generierte Filter-Diff;
das Router-Bereitstellungsergebnis;
Überwachung auf Abweichung zwischen veröffentlichter und beobachteter Richtlinie.

MANRS rahmt Routing-Sicherheit als kollektive operative Verantwortung. Seine Betreiberaktionen betonen das Filtern von Ankündigungen, das Pflegen von Koordinationskontakten und das Veröffentlichen von Informationen, die andere validieren können. Der aktuelle Implementierungsleitfaden diskutiert Präfix- und AS-Pfad-Granularität und empfiehlt Kontrollen, die verhindern, dass von Kunden gelernte oder zwischengeschaltete Routen an unangemessene Nicht-Kunden-Peers exportiert werden. [17][18]

Diese aktuellen Dokumente stammen in ihrer gegenwärtigen Form aus der Zeit nach dem Ereignis von 2015. Sie sollten als Kontrollrahmen verwendet werden, nicht als rückwirkender rechtlicher Beweis.

Das Ereignis zeigt, warum der Rahmen wichtig ist. Eine Richtlinie, die nur einer Router-Konfiguration bekannt ist, ist für ein anderes Netzwerk schwer zu validieren. Eine Richtlinie, die veröffentlicht, aber nie in Filter kompiliert wurde, ist nur Dokumentation. Ein Filter, der aus veralteten Daten kompiliert wurde, kann gültige Routen ablehnen oder ungültige akzeptieren. Verantwortlichkeit erfordert die Kette von der erklärten Absicht über das eingesetzte Verhalten zu den beobachteten Routen.

Standardmäßige Ablehnung ändert den Fehlermodus

RFC 8212, veröffentlicht im Jahr 2017, aktualisiert das BGP-Verhalten, sodass Routen auf einer eBGP-Session weder importiert noch exportiert werden, es sei denn, es wurde eine explizite Richtlinie konfiguriert. [11]

Dies ist eine trügerisch wichtige Designentscheidung.

Ein permissiver Standard macht Erreichbarkeit während der Erstkonfiguration einfach. Es bedeutet auch, dass eine fehlende Richtlinie stillschweigend zu "alles akzeptieren" oder "alles ankündigen" werden kann. Ein Betreiber muss daran denken, jede Schutzregel hinzuzufügen, bevor die Session Routen trägt.

Eine Standard-Ablehnungshaltung ändert den Fehlermodus. Fehlende Richtlinie produziert keinen Routenaustausch, was sichtbar und lokal ist, anstatt unbeabsichtigte globale Verbreitung. Betreiber können immer noch eine falsche explizite Richtlinie schreiben. RFC 8212 sagt dies. Die Kontrolle löst keine semantischen Fehler, veraltete Filter oder absichtliche Ausnahmen.

Sie kodiert jedoch ein solides Verantwortlichkeitsprinzip: Globale Erreichbarkeit sollte eine positive Richtlinienentscheidung erfordern.

Für eine Kunden-Transit-Session sollte diese Entscheidung überprüfbar sein:

welche Präfixe akzeptiert werden dürfen;
welche Ursprünge und Kundenpfade erwartet werden;
welche Routen zurück exportiert werden dürfen;
wie Ausnahmen genehmigt werden;
was passiert, wenn Richtliniendaten nicht verfügbar sind;
welches System den Rollback besitzt;
welche Beweise die Bereitstellung belegen.

Hätte jede relevante eBGP-Kante einen strikten Standard mit korrekter expliziter Richtlinie verwendet, wäre ein fehlender Filter geschlossen fehlgeschlagen. Die öffentlichen Beweise können nicht zeigen, ob ein RFC-8212-ähnliches Verhalten diesen genauen Vorfall verhindert hätte, da sie die tatsächlichen Konfigurationen von 2015 nicht offenlegen. Der RFC bleibt ein nützlicher retrospektiver Test: Erforderte der Routenaustausch explizite, begrenzte Autorität auf beiden Seiten?

BGP-Rollen und Only to Customer adressieren Beziehungsinformationen

RFC 9234, veröffentlicht im Jahr 2022, standardisiert BGP-Rollen und das Only-to-Customer-Attribut. Nachbarn können Rollen wie Provider, Kunde, Peer, Route-Server und Route-Server-Client aushandeln. Weitergeleitete Routen können Informationen tragen, die helfen, die erwartete Beziehungsrichtung durchzusetzen und Lecks zu erkennen. [12]

Dieser Mechanismus zielt auf die Lücke, die im AS4788-Ereignis sichtbar ist. Ein legitimer Ursprung und ein schleifenfreier Pfad offenbaren nicht, ob eine von einem Peer gelernte Route an einen Provider gesendet werden darf. Beziehungsinformationen machen diese Richtlinie im Protokollaustausch expliziter.

Der Standard hängt immer noch von korrekter Konfiguration und Bereitstellung ab. Netzwerke müssen Rollen genau zuweisen. Komplexe Beziehungen erfordern Sorgfalt. Teilweise Einführung schränkt den Schutz ein. Legacy-Routen und -Ausrüstung bleiben. Keine Protokollfunktion eliminiert die Notwendigkeit von Überwachung und operativer Koordination.

Der Wert ist, dass beide Seiten Erwartungen vergleichen können. Ein einseitiges lokales Label kann ohne sofortige Rückmeldung falsch sein. Eine ausgehandelte Rolle kann den Session-Aufbau fehlschlagen lassen oder einen Pfad markieren, wenn die beiden Enden sich uneinig sind. Das Only-to-Customer-Attribut kann helfen, Routen zu identifizieren, die nicht zu einem anderen Provider oder Peer reisen sollten.

Auch dies ist eine spätere Anleitung. Es wäre historisch ungenau zu sagen, dass AS4788 oder AS3549 es versäumt haben, einen Standard von 2022 im Jahr 2015 zu verwenden.

Der Vorfall liefert stattdessen den Testfall:

Kann eine von einem Peer gelernte Route ohne erkennbare Richtlinienverletzung an einen vorgelagerten Provider exportiert werden?
Kann der vorgelagerte Provider erkennen, dass der Pfad des Kunden Routen außerhalb der erwarteten Kundenbeziehung enthält?
Kann eine der beiden Seiten die Route vor der globalen Verbreitung stoppen?
Unterscheiden die Beweise eine Richtlinienausnahme von einem versehentlichen Leak?

Moderne rollenbewusste Mechanismen sollten gegen einen rekonstruierten AS4788-ähnlichen Routensatz evaluiert werden, nicht nur gegen synthetische Beispiele, die einer sauberen Topologie entsprechen.

Überwachung muss Routen mit Absicht vergleichen, nicht nur Verfügbarkeit

Verfügbarkeitsüberwachung erkennt den Schaden, nachdem Benutzer beginnen, Erreichbarkeit zu verlieren. Routenüberwachung kann die Anomalie der Kontrollebene früher identifizieren.

Der öffentliche Datensatz von 2015 wurde durch mehrere Formen der Beobachtung bewahrt:

BGPMon verarbeitete Update-Streams und identifizierte den Ankündigungsburst;
RouteViews und RIPE RIS behielten rohe BGP-Archive;
ThousandEyes kombinierte Routen- und Netzwerkmessungen;
RIPE Atlas lieferte aktive End-to-End-Messungen;
unabhängige Analysten verglichen Pfade, Präfixzahlen und Zeitabläufe. [2][3][4][5][6]

Diese Systeme sahen unterschiedliche Ausschnitte. Diese Diversität ist eine Stärke. Die interne Sicht eines einzelnen Providers kann übersehen, wie seine Routen anderswo erscheinen. Eine aktive Sonde kann Paketverlust sehen, aber nicht die Richtlinie, die ihn verursacht hat. Ein Routenkollektor kann einen AS-Pfad sehen, aber nicht jeden Verkehrspfad oder jede private Session.

Moderne Erkennungssysteme können mit Topologie, AS-Beziehungen, Routenhistorie und anomaler Verbreitung nach Route Leaks suchen. Cloudflare beschreibt öffentliche Route-Leak-Erkennung als eine Möglichkeit, anomale Pfade aufzudecken, während die RIPE-Atlas-Dokumentation reproduzierbare Messungen von verteilten Sonden unterstützt. [19][20]

Erkennung sollte mit Aktion verbunden sein.

Ein Alarm, der besagt "Routenzahl gestiegen", ist schwach, wenn niemand den Schwellenwert besitzt oder die Route unterdrücken kann. Ein nützlicher Vorfallspfad definiert:

die erwartete Beziehung und den Routensatz;
die Anomaliebedingung;
Vertrauen und False-Positive-Handhabung;
den Betreiber, der zur Quarantäne berechtigt ist;
eine sichere Eindämmungsaktion;
externe Bestätigung;
Beweisaufbewahrung;
Überprüfung nach dem Vorfall.

Die erste Reaktion muss nicht immer die gesamte Session beenden. Ein Provider kann die Präferenz senken, unerwartete Routen unter Quarantäne stellen, den letzten bekannten guten akzeptierten Satz bewahren oder nur Pfade außerhalb des Kundenkegels ablehnen. Die richtige Aktion hängt von der Router-Fähigkeit und dem Kundendesign ab.

Überwachung sollte auch Prävention von Erkennung unterscheiden. Die Veröffentlichung eines Route-Leak-Alarms nach globaler Verbreitung ist wertvoller öffentlicher Beweis. Sie beweist nicht, dass der Provider eine Kontrolle vor der Verbreitung hatte. Verantwortlichkeitsberichte sollten sagen, welche Stufe das Ereignis erkannt hat und welche Stufe es gestoppt hat.

Eine sichere Routenrichtlinienänderung benötigt aktuelle Byte-Beweise

Routing-Konfiguration durchläuft oft Vorlagen, Datenbanken, Automatisierung, Richtliniencompiler und anbieterspezifische Syntax, bevor sie einen Router erreicht. Ein menschlicher Prüfer kann eine Darstellung genehmigen, während das Gerät eine andere erhält.

Die Beweiskette sollte die aktuellen Bytes auf jeder Stufe binden:

Quellrichtlinie oder Änderungsanfrage;
normalisierte Beziehungs- und Präfixdaten;
generierte Route-Map oder Richtliniensprache;
gerätespezifische Konfiguration;
Kandidatenkonfigurations-Diff;
committeter Konfigurations-Hash;
resultierender angekündigter und akzeptierter Routensatz;
externe Kollektorbeobachtung.

Dies ist wichtig, weil "die Richtlinie wurde überprüft" mehrdeutig ist. Welche Version wurde überprüft? Hat ein Automatisierungsjob ein AS-Set nach der Genehmigung erweitert? Hat eine veraltete Registry-Snapshot den Filter produziert? Hat ein manueller Notfallbefehl die normale Pipeline umgangen? Haben alle Router dieselbe Ausgabe erhalten?

Ein verantwortliches Änderungssystem sollte fehlschlagen, wenn diese Bindungen auseinanderfallen.

Vor der Bereitstellung sollte es repräsentative Routen durch die kompilierte Richtlinie abspielen. Für AS4788-ähnliche Bedingungen sollten Tests enthalten:

vom Kunden originierte Routen;
Kundenkegel-Routen;
von Peers gelernte Routen;
von Providern gelernte Routen;
Routen, die große Transitnetzwerke enthalten;
unerwartete spezifischere Angaben;
eine plötzliche Volltabellenskala-Eingabe;
gemischte gültige und ungültige Ankündigungen.

Der Test sollte sowohl positives als auch negatives Verhalten behaupten. Gültige Kundenrouten müssen weiterhin passieren. Von Peers und Providern gelernte Routen dürfen nicht zu einem vorgelagerten Provider entweichen. Der akzeptierende Provider sollte Pfade unabhängig ablehnen, die nicht mit der erwarteten Kundenrolle übereinstimmen.

Nach der Bereitstellung sollten Routenkollektoren oder Looking Glasses das beobachtbare Ergebnis überprüfen. Ein Konfigurations-Hash allein beweist nicht, dass der Router nur die beabsichtigten Routen angekündigt hat. Zustand der Kontrollebene, Gerätefehler und Interaktion mit anderen Richtlinien können das effektive Verhalten ändern.

Diese aktuelle-Byte-Disziplin ist keine Bürokratie um ihrer selbst willen. Es ist, wie eine Organisation beweist, dass der Code, die Richtlinie und die Routen, die diskutiert werden, dieselben Objekte sind, die Schaden verursacht oder verhindert haben.

Wiederherstellung ist nicht dasselbe wie verifizierte Reparatur

Die öffentlichen Quellen zeigen, dass Routen zurückgezogen wurden oder nicht mehr akzeptiert wurden und sich der Dienst in den folgenden Stunden erholte. Das ist operative Wiederherstellung.

Reparatur stellt eine schwierigere Frage: Könnte dieselbe Klasse von Routen erneut entkommen?

Ein glaubwürdiges Sanierungsprogramm würde einen repräsentativen Vorfallssatz aus RouteViews, RIPE RIS und internen Logs einfrieren. Es würde die beabsichtigte Beziehung für jede Route identifizieren und die Export- und Importentscheidungen in einer Testumgebung reproduzieren.

Für AS4788 würde der Test verifizieren, dass von Peers oder Providern gelernte Routen nicht für den Export zu AS3549 ausgewählt werden können, es sei denn, eine explizite, überprüfte Ausnahme gilt. Für AS3549 würde es verifizieren, dass ein Kunde keine Pfade außerhalb des erwarteten Kundenkegels ankündigen oder ein gerechtfertigtes Volumen ohne Quarantäne überschreiten kann.

Das Programm würde dann Beweise generieren:

fehlgeschlagene Tests vor der Behebung;
Richtlinien- oder Systemänderungen;
bestehende Tests nach der Behebung;
Geräte- und Softwareversionen;
Bereitstellungsabdeckung;
Alarm- und Eindämmungsübungen;
externe Routenbeobachtungen;
Ausnahmebestand und Ablauf;
Eigentum an fortlaufender Überwachung.

Die Reparatur sollte auch degradierte Bedingungen testen. Was passiert, wenn Registry-Daten nicht verfügbar sind? Schlägt das System geschlossen fehl, verwendet es den letzten bekannten guten Satz oder akzeptiert es alles? Was passiert, wenn der Anomaliedetektor ausfällt? Kann ein Betreiber die Session über einen unabhängigen Managementpfad isolieren? Stoppt eine Maximal-Präfix-Abschaltung kritische Kundenrouten oder verwirft sie alle?

Die öffentliche Offenlegung muss keine privaten kommerziellen Bedingungen oder ausbeutbare Konfiguration offenlegen. Sie kann die Fehlerklasse, die betroffene Richtliniengrenze, die hinzugefügten Kontrollen, die Testmethode, die Bereitstellungsabdeckung und das Verifikationsdatum angeben.

Ohne diese Beweise ist "wir haben den Filter behoben" eine Behauptung über die Absicht. Damit können Kunden und Peers bewerten, ob der Betreiber das System geändert hat, das die globale Verbreitung ermöglichte.

Verantwortlichkeit sollte nicht in persönliche Schuld kollabieren

Ein Internet-Route-Leak wird oft zu einer Geschichte über einen Ingenieur, der einen schlechten Befehl eingibt. Der öffentliche Datensatz hier belegt diese Geschichte nicht. Selbst wenn eine einzelne Aktion das Ereignis auslöste, erforderte die globale Auswirkung mehrere Systeme und organisatorische Entscheidungen.

Ein Betreiber entwirft die Konfigurationsschnittstelle. Er wählt, ob Änderungen generiert oder handschriftlich vorgenommen werden. Er definiert Peer- und Provider-Beziehungen. Er entscheidet, welche Tests obligatorisch sind, ob ein zweiter Prüfer erforderlich ist, wie schnell Richtlinien propagiert werden und ob der Rollback unabhängig ist.

Ein Transit-Provider entscheidet, wie viel Vertrauen er in eine Kundenankündigung setzt, welche Filter wirtschaftlich und operativ machbar sind und welche Anomalie eine Eindämmung auslöst. Die Führung entscheidet, ob Routing-Sicherheitsarbeit Personal, Wartungsfenster und Autorität hat, um den Verkehrsfluss zu unterbrechen.

Persönliche Schuld kann diese Kontrollen verschleiern. Sie kann auch Offenlegung entmutigen. Ein besseres Verantwortlichkeitsmodell fragt:

Wer hatte die Fähigkeit, das Verlassen der Route zu verhindern?
Wer hatte die Fähigkeit, sie abzulehnen?
Wer hatte die Fähigkeit, ihre Verbreitung zu begrenzen?
Wer konnte den Schaden unabhängig erkennen?
Wer konnte zurückziehen oder unter Quarantäne stellen?
Wer hat Beweise aufbewahrt?
Wer hatte die Autorität, Sanierung zu finanzieren und zu verifizieren?

Diese Fragen können Verantwortung identifizieren, ohne Absicht oder Fahrlässigkeit zu behaupten, die öffentliche Quellen nicht belegen.

Sie verhindern auch, dass Verantwortung in "das Internet ist dezentralisiert" zerfällt. Dezentralisierung bedeutet, dass kein einzelner Betreiber jeden Pfad kontrolliert. Es bedeutet nicht, dass jeder Betreiber keine Kontrolle über seine eigenen Ankündigungen, Sessions und Verbreitungsentscheidungen hat.

Was Kunden und Peers vernünftigerweise verlangen können

Die meisten Kunden können die Router eines Transit-Providers nicht auditieren. Peers können nicht jeden privaten Änderungsprozess sehen. Sie können dennoch Beweise verlangen, die der Abhängigkeit angemessen sind.

Vor einem Vorfall kann ein Betreiber veröffentlichen:

genaue Routing-Kontakte;
registrierte Präfixe und autonome Systeme;
Routen- und AS-Sets;
eine übergeordnete Peering- und Filterrichtlinie;
RPKI-Abdeckung;
Unterstützung für relevante Rollen- und Validierungsmechanismen;
Status- und Vorfallskanäle.

Während eines Vorfalls kann er kommunizieren:

die betroffene Routen- oder Sessionsklasse;
ob Ankündigungen noch propagieren;
Eindämmungsmaßnahme;
bekannte Regionen und Dienste;
Messunsicherheit;
Wiederherstellungsbeweise;
nächste Aktualisierungszeit.

Nach einem Vorfall kann er bereitstellen:

Quell- und Akzeptanzgrenzen;
Routenzahldefinitionen;
Zeitstrahl mit Herkunft;
versagte Kontrollen;
Kontrollen, die Schaden begrenzt haben;
testbare Sanierung;
verbleibende Einschränkungen.

Kunden sollten auch ihre eigene Gefährdung testen. Multi-Homing garantiert keine Unabhängigkeit, wenn beide Provider vom selben Upstream abhängen. Eine Backup-Route kann existieren, aber unter lokaler Präferenz verlieren. Spezifischere Ankündigungen können die beabsichtigte Vielfalt außer Kraft setzen. Verkehr kann einem durchgesickerten Pfad ausweichen, aber dennoch unter Überlastung in einem gemeinsamen Transit-Provider leiden.

Unabhängige Routenüberwachung, RIPE-Atlas-Messungen und Looking-Glass-Prüfungen können einen Teil dieser Gefährdung aufdecken. [4][5][6][20]

Die Pflicht ist proportional. Ein kritischer öffentlicher Dienst oder eine Finanzplattform sollte die Upstream-Konzentration tiefer verstehen als eine Low-Impact-Personal-Website. Aber kein Kunde kann vollständig dafür kompensieren, dass ein Transit-Provider einen massiven unsicheren Routensatz akzeptiert und verbreitet.

Was der öffentliche Datensatz nicht beweisen kann

Der Quellensatz unterstützt eine starke Netzwerkverantwortlichkeitsanalyse, aber er unterstützt keinen vollständigen internen Postmortem.

Er kann nicht beweisen:

den genauen Telekom-Malaysia-Router oder -Standort;
den genauen Konfigurationsbefehl oder die Vorlage;
ob der Auslöser eine geplante Änderung, ein veralteter Zustand, ein Automatisierungsfehler oder ein manueller Fehler war;
die Software- oder Hardwareversion;
die privaten Beziehungsbedingungen zwischen AS4788 und AS3549;
die genauen Import-, Export- und Maximal-Präfix-Einstellungen auf beiden Seiten;
den ersten internen Alarm und die Betreiberreaktion;
private Koordinationsnachrichten;
eine abgestimmte Präfixzahl über alle Kollektoren hinweg;
eine vollständige Zählung betroffener Benutzer oder finanzieller Verluste;
rechtliche Haftung oder Vertragsverletzung;
die dauerhafte Sanierung, die von einem der Betreiber eingesetzt wurde.

Das Paket sollte auch spätere Kontrollen nicht in historische Anforderungen verwandeln. RFC 8212 wurde 2017 veröffentlicht, RFC 9234 2022, und der aktuelle MANRS-Implementierungsleitfaden spiegelt spätere operative Arbeit wider. Sie definieren nützliche heutige Tests. Sie beweisen nicht, welche Konfigurationen oder Verpflichtungen im Jahr 2015 existierten. [11][12][18]

Ebenso sind aktuelle RIPEstat-Daten aktueller Netzwerkressourcenkontext, kein eingefrorener Registry-Snapshot von 2015. [7]

Diese Grenzen machen die Schlussfolgerung glaubwürdiger. Der beobachtbare Ausfall reicht aus, um geteilte Kontrolle zu identifizieren. Der fehlende interne Datensatz ist selbst eine Verantwortlichkeitslücke, aber er ist keine Erlaubnis, eine zu erfinden.

Ein wiederverwendbarer Upstream-Filtering-Verantwortlichkeitstest

Das Ereignis unterstützt einen praktischen Test für jeden Kunden, Transit-Provider oder Peer, der BGP in bedeutendem Umfang betreibt.

1. Definieren Sie die Beziehung für jede Session.
Erfassen Sie Provider, Kunde, Peer, Route-Server und Ausnahmerollen mit der Granularität, bei der sich die Richtlinie unterscheidet.

2. Binden Sie beabsichtigte Routen an authentifizierte Beweise.
Pflegen Sie Präfixe, Ursprünge, Kundenkegel, AS-Sets und Ausnahmen mit Eigentümerschaft, Aktualität und Herkunft.

3. Kompilieren Sie die Richtlinie vor der Bereitstellung.
Zeigen Sie die konkreten Routen und Pfade, die die Import- und Exportrichtlinie akzeptieren wird. Überprüfen Sie das effektive Verhalten, nicht nur Vorlagentext.

4. Fehlschlagen geschlossen, wenn explizite Richtlinie fehlt.
Keine eBGP-Route sollte globale Autorität erlangen, weil ein Filter fehlte oder der Datenabruf fehlschlug.

5. Testen Sie Beziehungsverletzungen.
Spielen Sie von Peers und Providern gelernte Routen gegen Kunden- und Upstream-Sessions ab. Verifizieren Sie, dass die ungültige Richtung sowohl auf der Export- als auch auf der Empfängerseite abgelehnt wird.

6. Kalibrieren Sie Volumenkontrollen.
Setzen Sie Maximal-Präfix- und Anomalieschwellenwerte gegen normales Verhalten, gerechtfertigtes Wachstum und Notfälle. Definieren Sie sichere Eindämmung anstatt sich nur auf das Herunterfahren der gesamten Session zu verlassen.

7. Trennen Sie Ursprungs- und Pfadvalidierung.
Verwenden Sie RPKI für Ursprungsautorität, aber beschreiben Sie ROV nicht als Beweis für beziehungsgültige Verbreitung. Fügen Sie Pfad- und Kundenkegelkontrollen hinzu.

8. Überwachen Sie von außen.
Verwenden Sie unabhängige Kollektoren und aktive Messungen, um beobachtete Routen und Erreichbarkeit mit der beabsichtigten Richtlinie zu vergleichen.

9. Geben Sie der Eindämmung einen Eigentümer.
Identifizieren Sie, wer Routen unter Quarantäne stellen, die Präferenz senken, einen letzten bekannten guten Satz wiederherstellen oder eine Session zurücksetzen kann, auch außerhalb gewöhnlicher Änderungsfenster.

10. Bewahren Sie aktuelle-Byte-Beweise auf.
Binden Sie genehmigte Richtlinie, generierte Konfiguration, bereitgestellte Bytes, Routenzustand, Alarme, Entscheidungen und externe Beobachtungen.

11. Beweisen Sie die Reparatur mit der ursprünglichen Ereignisklasse.
Laufen Sie den rekonstruierten Leak durch beide Seiten der Session und zeigen Sie, wo er stoppt. Testen Sie semantische Varianten, nicht nur eine gespeicherte Präfixliste.

12. Veröffentlichen Sie genug, damit abhängige Netzwerke überprüfen können.
Erklären Sie die Kontrollgrenze, Routenzahldefinitionen, Sanierung und verbleibende Unsicherheit, ohne sensible private Bedingungen offenzulegen.

Dieser Test verspricht nicht, dass Route Leaks verschwinden. Er macht Präventions-, Eindämmungs- und Beweispflichten auf jedem Netzwerk explizit, das der Route weitere Autorität erteilen kann.

Fazit

Der Telekom-Malaysia-Route-Leak vom 12. Juni 2015 zeigte, wie schnell lokale Routing-Richtlinie zu globalem Infrastrukturschaden werden kann.

AS4788 sendete einen sehr großen Satz von Routen aus. AS3549 akzeptierte und verbreitete sie. Der Verkehr verlagerte sich auf Pfade durch Level 3 und Telekom Malaysia. Paketverlust, Latenz und Erreichbarkeitsausfälle breiteten sich über Regionen aus und betrafen sowohl direkt umgeleitete Dienste als auch Benutzer, die der Überlastung in einem gemeinsamen Transitnetzwerk ausgesetzt waren. Unabhängige Routenkollektoren und Messplattformen bewahrten die öffentliche Umrisse. [1][2][3][4]

Das Ereignis kann nicht verantwortungsvoll als eine einzige schlechte Ankündigung eines Netzwerks erklärt werden. Export und Import sind getrennte Kontrollen. Ein Kunde hat die Pflicht, nur autorisierte Routen anzukündigen. Ein Transit-Provider hat eine Pflicht proportional zu seiner Macht, diese Routen zu akzeptieren und zu verbreiten. Peers und nachgelagerte Netzwerke haben zusätzliche Überwachungs- und Importkontrollen. Keine Schicht kann Perfektion garantieren, aber jede kann verhindern, dass ein Fehler mehr Reichweite erlangt.

RPKI-Origin-Validation ist wertvoll und unzureichend für diesen Pfadrichtlinienfehler. Route-Registries können Absicht veröffentlichen und dennoch veraltet sein. Maximal-Präfix-Kontrollen können Volumen eindämmen und dennoch kleinere Lecks übersehen. Spätere Standard-Ablehnungs- und beziehungsbewusste Standards verbessern das Kontrollmodell, beweisen aber nicht rückwirkend eine Verletzung von 2015. Die dauerhafte Antwort ist geschichtet: explizite Richtlinie, authentifizierte Routendaten, Beziehungsprüfungen, kalibrierte Grenzen, unabhängige Überwachung, schnelle Eindämmung und reproduzierbare Reparatur.

Risiko folgt der Reichweite, die eine Ankündigung erlangen kann. Verantwortlichkeit folgt dem, der diese Reichweite hätte einschränken können, der sich dafür entschieden hat, sie zu verbreiten, und der beweisen kann, dass dieselbe Fehlerklasse jetzt gestoppt wird, bevor der Verkehr anderer zum Test wird.

Telekom Malaysias Route-Leak von 2015: Upstream-Filterung als Verantwortlichkeitstest für Transit