Zusammenfassung

  • Am 8. April 2010 beobachtete BGPMon, dass AS23724, ein öffentlich als China-Telecom-Rechenzentrum-Netz identifizierter Ursprung, für ungefähr fünfzehn Minuten etwa 37.000 eindeutige Präfixe ankündigte, obwohl das Netz nach BGPMon normalerweise nur rund 40 Präfixe originierte.
  • Der Vorgang belegt eine ungewöhnliche Kontrollflächenstörung und eine teilweise internationale Weitergabe über die sichtbare AS4134-AS23724-Pfadgrenze, aber er belegt weder einen festen Anteil am weltweiten Datenverkehr noch Paketinspektion, Datenspeicherung oder Absicht.

Am 8. April 2010 entstand im globalen Routing eine kurze, aber bis heute lehrreiche Störung. BGPMon berichtete, dass AS23724 eine große Menge von Präfixen ankündigte, die diesem Ursprung nicht zugewiesen waren. Der beobachtete Pfad enthielt AS4134 vor AS23724. Damit lag nicht nur ein ungewöhnliches Origin-Signal vor, sondern auch eine sichtbare Import- und Weitergabegrenze: AS23724 exportierte die Routen, AS4134 nahm sie in einem beobachteten Pfad an und gab zumindest Teile davon weiter. Genau an dieser Grenze entscheidet sich die technische Verantwortungsfrage. Ein Ursprung kann falsche oder gelernte Präfixe exportieren.

Ein direkter Nachbar kann sie annehmen, abweisen, begrenzen oder in weitere Beziehungen tragen. Weitere Netze können wiederum eigene Präferenzen, Filter und Beziehungspolitiken anwenden. Die globale Wirkung entsteht nicht durch eine einzelne Zahl, sondern durch eine Kette von akzeptierten und weitergegebenen BGP-Entscheidungen.

Die Zahlen müssen eng an die Beobachtung gebunden bleiben. BGPMon gab für den ursprünglichen Bericht erste und letzte beobachtete Zeitpunkte von 17:54:31 UTC bis 18:10:14 UTC an. Das ist ein Beobachtungsfenster aus Route-Collector-Sicht, kein Beweis dafür, dass jeder Router der Welt genau in diesem Zeitraum betroffen war. BGPMon schrieb außerdem, AS23724 habe ungefähr 37.000 eindeutige Präfixe angekündigt und das Ereignis habe etwa fünfzehn Minuten gedauert.

In einer späteren Einordnung erklärte BGPMon, diese Präfixmenge habe ungefähr elf Prozent der damaligen Routing-Tabelle entsprochen, warnte aber ausdrücklich davor, Präfixanteil mit Datenverkehrsanteil gleichzusetzen. Ein Präfix kann sehr wenig oder sehr viel Verkehr tragen, kann stärker oder schwächer deaggregiert sein und kann von Beobachtungspunkten unterschiedlich gesehen werden. Präfixanteil ist deshalb ein Kontrollflächenmaß, kein Traffic-Maß.

Auch die Weitergabe muss begrenzt beschrieben werden. BGPMon schätzte, dass nur etwa zehn Prozent der angekündigten Präfixe außerhalb chinesischer Netze propagierten. In derselben Beobachtungslogik erfassten 28 Prozent der von BGPMon herangezogenen RIPE-RIS-Kollektoren irgendeinen Teil des Ereignisses. Diese Zahlen sind wichtig, weil sie die Geschichte von einer einfachen globalen Umleitungserzählung trennen. Sie zeigen, dass die Route-Leak-Signale nicht lokal verborgen blieben, aber sie zeigen nicht, dass ein fester Anteil des weltweiten Datenverkehrs über China Telecom lief.

Sie zeigen Sichtbarkeit auf der BGP-Kontrollfläche, nicht Volumen auf der Datenebene. Wer aus 37.000 Präfixen einen festen Prozentsatz des globalen Traffics macht, überschreitet die Quelle.

Die Chronologie beginnt mit einem abnormalen Export durch AS23724. Nach BGPMon originierte dieses Netz normalerweise nur eine kleine Zahl eigener Präfixe. Die plötzliche Ankündigung von etwa 37.000 eindeutigen Präfixen war deshalb ein Volumensignal, das nicht als gewöhnliche Routing-Änderung behandelt werden konnte. Ein solches Signal kann durch eine fehlerhafte Exportregel, eine falsche Redistribuierung, eine versehentliche Full-Table-Weitergabe oder andere Konfigurationsfehler entstehen.

BGPMons Autor hielt eine Konfigurationsstörung für wahrscheinlicher als Absicht, markierte diese Einschätzung aber als Spekulation, weil er nicht mit den zuständigen Ingenieuren gesprochen hatte. Diese Grenze ist entscheidend. Die öffentlichen Daten belegen Ankündigungen und Pfade. Sie belegen nicht den Befehl, der sie ausgelöst hat, nicht die innere Entscheidungskette und nicht die Motivation.

Der entscheidende Punkt an AS23724 ist die Exportkante. Ein autonomes System, das gewöhnlich rund 40 Präfixe originierte, musste nicht nur wissen, welche eigenen Präfixe es in die Welt senden durfte. Es musste auch verhindern, dass gelernte Routen, fremde Ressourcen oder eine größere Routing-Tabelle versehentlich in eine externe Sitzung gerieten. Exportkontrolle ist in diesem Sinn kein kosmetisches Filter am Ende der Konfiguration. Sie ist die technische Umsetzung der Frage, ob ein Netz nur das ankündigt, wofür es zuständig ist.

Sie umfasst erlaubte Prefix-Sets, erlaubte Origin-Sets, interne Quellen für diese Sets, Change-Kontrollen, Rollback-Regeln und die Abgrenzung zwischen internen iBGP-Informationen und externen eBGP-Ankündigungen. Wenn an dieser Kante eine Größenordnung auftaucht, die mehrere hundert Mal über dem normalen Profil liegt, ist der Fehler nicht erst dann relevant, wenn Endnutzer ihn sehen. Der Fehler ist bereits auf der Kontrollfläche relevant, weil er anderen autonomen Systemen eine falsche Auswahl anbietet.

Diese Exportfrage ist auch deshalb streng, weil ein Ursprung mit einem einzigen fehlerhaften Policy-Pfad sehr unterschiedliche Präfixarten vermischen kann. Eigene Kundenpräfixe, intern gelernte Routen, Transit-Routen und volle Tabellen dürfen in einer robusten Konfiguration nicht denselben Ausgängen folgen. Für AS23724 wäre die technische Prüfung daher nicht nur: Welche Präfixe wurden am 8. April 2010 beobachtet? Sie müsste auch fragen: Aus welcher lokalen Route-Quelle kamen sie? Waren sie aus einem internen Protokoll redistribuiert? Wurden sie aus einem BGP-Nachbarn gelernt und dann neu originierend oder weiterleitend an AS4134 gegeben?

Welche Export-Policy hätte die Sitzung begrenzen sollen? Welche Prefix-Listen oder Route-Maps waren aktiv? Welche Änderung unmittelbar vor dem Ereignis hätte die Trennung zwischen eigener Origin-Ankündigung und fremden Routen aufgehoben? Die öffentlichen Quellen beantworten diese internen Fragen nicht. Gerade deshalb müssen sie als offene Kontrollfragen stehen bleiben.

Der nächste Punkt der Chronologie ist AS4134. In der beobachteten gemeinsamen Pfadangabe erschien AS4134 vor AS23724. Damit wurde AS4134 zur sichtbaren Importgrenze und zur Grenze für Weitergabeentscheidungen. Das heißt nicht, dass AS4134 allein den gesamten Vorfall verursacht hat. Es heißt auch nicht, dass jeder spätere Beobachtungspunkt ausschließlich durch AS4134 erreicht wurde. Aber es macht die Kontrollfrage konkret: Welche Präfixe durfte AS23724 gegenüber AS4134 ankündigen? Welche Importpolitik galt auf dieser Sitzung?

Gab es kundenspezifische Prefix-Listen, IRR-basierte oder RPKI-gestützte Erzeugung von Filtern, Maximum-Prefix-Schwellen, Warnschwellen und harte Abschaltungen? Wurden Routen, die aus einer bestimmten Geschäftsbeziehung gelernt wurden, nach Beziehungstyp weitergegeben oder begrenzt? Ohne diese Fragen bleibt die Verantwortung abstrakt.

AS4134 ist in dieser Analyse daher nicht bloß ein AS-Pfad-Element. Es ist die sichtbare Stelle, an der eine Importentscheidung und eine mögliche Weitergabeentscheidung zusammenfallen. Ein Nachbar kann von einem angeschlossenen Netz falsche Routen empfangen. Das allein beweist noch nicht, wie weit der Fehler reicht. Die Reichweite entsteht, wenn der Nachbar diese Routen in seine eigene Routing-Entscheidung aufnimmt und sie anschließend an andere Beziehungen exportiert. Genau hier liegt der Unterschied zwischen einem lokalen Kundenfehler und einer internationalen Kontrollflächenstörung.

Eine robuste Importpolitik hätte die erwartete Menge und den erwarteten Charakter der Routen prüfen müssen. Eine robuste Weitergabe-Policy hätte zusätzlich sicherstellen müssen, dass eine aus einer bestimmten Beziehung gelernte Route nicht in Beziehungen getragen wird, in denen sie nicht erscheinen sollte. Diese zweite Stufe ist wichtig: Selbst wenn eine Route intern kurz angenommen wird, muss daraus nicht automatisch externe Propagation folgen.

Die beobachtete externe Propagation macht den Vorfall nicht automatisch zu einem universalen Ausfall, aber sie macht ihn zu einem Interdomain-Kontrollversagen. BGP ist kein zentral validiertes System. Ein autonomes System entscheidet, welche Routen es annimmt, bevorzugt, exportiert und zurückzieht. Ein Leak kann klein bleiben, wenn direkte Nachbarn falsch angekündigte Präfixe ablehnen oder durch Beziehungspolitik begrenzen. Er kann größer werden, wenn Nachbarn die Routen akzeptieren und an Peers oder Transits weitergeben, die wiederum eigene Auswahlregeln anwenden.

Die BGPMon-Zahl von etwa zehn Prozent externer Propagation beschreibt genau diese teilweise Kettenreaktion. Sie ist zu klein für die Behauptung einer vollständigen globalen Umleitung und groß genug, um die Filter- und Eskalationsfrage ernst zu nehmen.

Route Collectors liefern dafür wertvolle, aber begrenzte Evidenz. Sie speichern, was ihnen teilnehmende Router und Peers liefern. Sie können zeigen, dass bestimmte Präfixe zu bestimmten Zeitpunkten mit bestimmten AS-Pfaden beobachtet wurden. Sie können Volumensprünge, Origin-Wechsel, Pfadänderungen und Rücknahmen sichtbar machen. Sie können aber nicht allein beweisen, welcher Anteil realer Pakete über einen bestimmten Pfad floss. Sie sehen nicht jeden Router, nicht jede Routing-Entscheidung, nicht jede lokale Präferenz und nicht jede Datenebenenweiterleitung.

Ein Collector kann auch ein Ereignis verpassen, das in einem anderen Teil des Netzes sichtbar war, oder ein Ereignis sehen, das für viele Endnutzer nie bevorzugter Pfad wurde. Deshalb dürfen Collector-Zahlen weder abgewertet noch überdehnt werden. Sie sind Beweise für Kontrollflächenverhalten, keine vollständige Verkehrsmessung.

Diese Messgrenze erklärt auch, warum unterschiedliche spätere Berichte abweichende Zählungen enthalten können. Beobachter verwenden verschiedene Collector-Sätze, andere Zeitfenster, unterschiedliche Definitionen von Prefix, Route, Announcement und betroffenem Pfad. Manche zählen eindeutige Präfixe, andere Routen oder Updates. Manche berücksichtigen Deaggregation anders. Manche rekonstruieren mit späteren Datensätzen breitere oder engere Sichtfenster. Daraus folgt nicht automatisch, dass eine Quelle falsch ist. Es bedeutet, dass jede Zahl mit ihrer Methode gelesen werden muss.

Für eine Verantwortungsanalyse ist die BGPMon-Angabe von etwa 37.000 Präfixen für etwa fünfzehn Minuten ein belastbarer Kern, wenn sie als BGPMon-Beobachtung und nicht als universelle Internetmessung dargestellt wird.

Die Trennung zwischen Präfixvolumen und Verkehr ist mehr als ein methodischer Vorbehalt. Sie entscheidet darüber, ob die Analyse beweisbar bleibt. Ein Präfix ist eine Adressmenge in der Routing-Tabelle. Der Verkehr, der über diese Adressmenge läuft, hängt von den Nutzern, den Diensten, den Pfadpräferenzen, dem Grad der Deaggregation und der tatsächlichen Datenebenenweiterleitung ab. Ein einzelnes großes Präfix kann wenig aktuellen Verkehr tragen, während mehrere kleine Präfixe stark genutzt werden können. Ein beobachteter BGP-Pfad kann außerdem in einem Netz vorhanden sein, ohne der beste Pfad zu sein. Lokale Präferenz kann ihn verdrängen.

Ein Filter kann ihn an einer anderen Grenze stoppen. Ein alternativer Pfad kann schneller ausgewählt werden. Deshalb ist die Aussage, eine bestimmte Präfixmenge sei sichtbar gewesen, nicht gleichbedeutend mit der Aussage, ein bestimmter Anteil des weltweiten Traffics sei geflossen. Die erste Aussage beschreibt die Kontrollfläche. Die zweite bräuchte Datenebenenmessung, Routerzähler, Flow-Daten oder vergleichbare Belege.

Gleichzeitig darf diese Vorsicht den Präfixumfang nicht kleinreden. Ein Kontrollflächenereignis mit ungefähr 37.000 Präfixen ist eine große Störung, auch wenn die Datenebenenwirkung offen bleibt. BGP ist die Ebene, auf der Erreichbarkeit angekündigt, Pfade ausgewählt und Verantwortungsgrenzen sichtbar werden. Wenn ein falscher Ursprung oder ein falscher Export für sehr viele Präfixe erscheint, muss die Untersuchung nicht warten, bis ein genauer Traffic-Wert bekannt ist. Die Verantwortungsfrage entsteht bereits daraus, dass andere Netze falsche oder unerwartete Kontrollinformationen erhalten konnten.

Der richtige Schluss lautet daher nicht: Weil Präfixanteil kein Traffic-Anteil ist, ist der Vorfall unbedeutend. Der richtige Schluss lautet: Weil Präfixanteil kein Traffic-Anteil ist, muss die Störung als Routing- und Policy-Störung analysiert werden, nicht als belegte Aussage über einen festen Datenverkehrsanteil.

Die stärkste Lehre des Vorfalls liegt deshalb nicht in einer Schlagzeilenzahl, sondern in der Aufteilung der Kontrollgrenzen. AS23724 kontrollierte seine Origin-Ankündigungen und seine Exportpolitik. Wenn ein Netz nur rund 40 eigene Präfixe legitim originieren sollte, muss eine abrupte Ankündigung von etwa 37.000 Präfixen an der Exportkante auffallen und möglichst dort blockiert werden. AS4134 kontrollierte als sichtbarer Nachbar Import, Routenauswahl und Weitergabe im Rahmen seiner Geschäftsbeziehungen. Weitere Netze kontrollierten ihre eigene Annahme, Präferenz und Propagation.

Präfixinhaber kontrollierten Autorisierungsdaten wie ROAs, soweit vorhanden, sowie externe Überwachung und Eskalationskontakte. Route Collectors kontrollierten Beobachtung und Beweissicherung, aber nicht die Produktionsweiterleitung. Endnutzer hatten keine direkte Kontrolle über BGP-Zustände.

Diese Aufteilung verhindert eine falsche Vereinfachung. Es reicht nicht, den Ursprung zu nennen und den Rest als unvermeidlich darzustellen. Es reicht auch nicht, den Transit-Nachbarn allein als Ursache zu behandeln. Ein Route Leak wird durch mehrere Entscheidungspunkte geformt. Der Ursprung muss verhindern, dass fremde, gelernte oder volle Tabellen exportiert werden. Der direkte Nachbar muss nur erwartete Kundensätze akzeptieren und Beziehungspolitik erzwingen. Weiter entfernte Netze müssen eigene Filter und Anomalieerkennung betreiben, statt jeden attraktiven Pfad unkritisch zu propagieren.

Präfixhalter müssen Autorisierungsdaten pflegen und unabhängige Alarmierung betreiben. Jeder Punkt hat andere Beweise, andere Fehlermodi und andere Abhilfen.

Präfixautorisierung ist dabei ein wichtiger, aber kein alleiniger Kontrollmechanismus. Registry-, IRR-, WHOIS-, RDAP-, RPKI- und ROA-Daten können zeigen, welche Ressource wem zugeordnet ist und welcher Ursprung für einen Präfix autorisiert sein soll. Diese Daten sind Rechenschafts- und Entscheidungshilfen. Sie setzen aber nicht automatisch Routerpolitik durch. Die laufende Konfiguration entscheidet, ob eine Route angenommen und weitergegeben wird. Wenn ein ROA existiert und Origin Validation aktiv ist, kann ein Router eine Route mit nicht autorisiertem Ursprung als ungültig erkennen und ablehnen.

Wenn kein ROA existiert, wenn die Validierung nicht aktiviert ist, wenn lokale Politik Validierungszustände nur schwach berücksichtigt oder wenn der Ursprung gültig bleibt, aber die Weitergabebeziehung falsch ist, löst RPKI allein das Problem nicht.

Diese RPKI-Grenze ist im Fall von 2010 besonders wichtig, weil der Vorfall oft als Beleg für eine einzige fehlende Sicherheitsmaßnahme gelesen wird. RPKI Origin Validation adressiert die Frage, ob ein bestimmtes AS als Ursprung für einen Präfix autorisiert ist. Sie beweist nicht, dass der gesamte AS-Pfad legitim ist. Sie beweist nicht, dass eine Route aus der richtigen Kunden-, Peer- oder Providerbeziehung stammt. Sie verhindert nicht jeden Leak, bei dem der Ursprung gültig ist, aber die Weitergabe entgegen der Beziehungspolitik erfolgt. Sie ist daher eine notwendige Schicht für viele Fälle, aber kein vollständiges Heilmittel.

Eine robuste Antwort kombiniert präzise ROAs mit Importfiltern, Exportfiltern, Maximum-Prefix-Kontrollen, Rollen- oder Beziehungssignalen und unabhängiger Überwachung.

RPKI kann außerdem nur so gut wirken wie seine Abdeckung, seine Aktualität und seine Umsetzung in lokaler Policy. Ein gültiges ROA hilft, wenn der prüfende Router Origin Validation einsetzt und die lokale Entscheidung ungültige Origins tatsächlich zurückweist. Ein fehlendes ROA erzeugt in der üblichen Prüfung keinen eindeutigen Ungültigkeitsbeweis. Ein veraltetes oder falsch gepflegtes ROA kann selbst zu Erreichbarkeitsproblemen führen. Eine Route mit gültigem Ursprung kann trotzdem über eine unerwünschte Beziehungskette verbreitet werden. Deshalb ist RPKI in einer Verantwortungsanalyse keine Entlastungsformel und keine Allzweckanklage.

Es ist eine überprüfbare Kontrollschicht: Welche Präfixe hatten Autorisierung? Welche Router validierten sie? Welche Zustände wurden akzeptiert, verworfen oder nur mit geringerer Präferenz behandelt? Wie wurden Ausnahmen dokumentiert? Ohne diese Fragen bleibt RPKI eine abstrakte Empfehlung, nicht ein Beleg für wirksame Eindämmung.

Relationship-aware Filtering ist die zweite zentrale Schicht. BGP ist wirtschaftlich und technisch beziehungsabhängig. Routen, die von Kunden gelernt werden, dürfen typischerweise anders weitergegeben werden als Routen, die von Peers oder Providern kommen. Ein Leak entsteht häufig, wenn diese Grenze verwischt wird: Ein Netz exportiert mehr, als es in einer Beziehung exportieren sollte, und Nachbarn akzeptieren oder propagieren es. BGP Roles und ähnliche beziehungsbewusste Schutzmechanismen adressieren genau diesen Bereich.

Sie ersetzen keine Prefix-Listen und keine Origin Validation, aber sie verhindern, dass eine korrekt oder inkorrekt originierte Route durch eine unpassende Beziehungskante weitergetragen wird. Im AS23724-AS4134-Kontext wäre die Frage nicht nur, ob einzelne Präfixe autorisiert waren, sondern auch, ob die Sitzung eine plausible Menge und Art von Routen liefern durfte.

Beziehungsbewusste Filter sind besonders wichtig, weil ein Leak oft nicht wie eine einfache Fälschung aussieht. Eine Route kann syntaktisch gültig sein, einen plausiblen AS-Pfad haben und dennoch aus der falschen Beziehung kommen. Ein Netz, das von einem Kunden Routen lernt, kann sie anders behandeln als Routen von einem Peer. Ein Netz, das von einem Peer lernt, sollte sie nicht so weiterreichen, als seien sie Kundenrouten. Diese Unterscheidung ist nicht bloß kaufmännisch. Sie bestimmt, wie weit eine Ankündigung getragen wird.

Für AS4134-ähnliche Grenzen bedeutet das: Die Importentscheidung muss mit der erwarteten Beziehung und der erwarteten Präfixmenge verbunden sein, und die Exportentscheidung muss wissen, aus welcher Beziehung die Route kam. Wenn diese Herkunftsinformation in der Policy verloren geht, kann eine lokal angenommene Route globaler werden, als sie sein darf.

Maximum-Prefix-Kontrollen sind die grobe, aber praktische Sicherung gegen Volumensprünge. Wenn ein Nachbar normalerweise eine kleine Zahl von Präfixen liefert, kann ein plötzliches Vielfaches eine Warnung, Dämpfung oder harte Sitzungsschutzmaßnahme auslösen. Solche Kontrollen sind kein semantischer Beweis. Eine große legitime Änderung kann vorkommen, und ein kleiner Leak kann trotzdem gefährlich sein. Aber bei einer Differenz zwischen rund 40 normalen Präfixen und etwa 37.000 beobachteten Präfixen wäre eine gut gepflegte Schwelle ein naheliegender Kontrollpunkt.

Entscheidend ist nicht nur das Vorhandensein einer Schwelle, sondern deren Pflege, Alarmierung, Eskalationsweg und getestetes Verhalten. Eine Warnung, die niemand besitzt, ist keine wirksame Kontrolle.

Maximum-Prefix ist dabei keine Entschuldigung für schlechte Präfixdaten. Eine Schwelle kann einen groben Unfall stoppen, aber sie weiß nicht, welche einzelnen Präfixe legitim sind. Sie kann auch zu hoch gesetzt sein, weil Betreiber Wachstum, Aggregationsänderungen oder Kundenmigrationen erwarten. Sie kann nur warnen, aber nicht schließen. Sie kann eine Sitzung hart trennen und dadurch legitime Erreichbarkeit verlieren.

Darum gehört sie in eine gestufte Policy: genaue Prefix-Sets zuerst, Origin Validation als zusätzliche Prüfung, Beziehungspolitik als Weitergabegrenze, Maximum-Prefix als Volumenbremse und externe Beobachtung als unabhängiger Alarm. Im 2010er Fall ist die Größenordnung so auffällig, dass jede dieser Schichten eine konkrete Frage auslöst. Welche Schicht hätte anschlagen müssen? Welche Schicht schlug an? Welche wurde ignoriert? Welche existierte nicht oder war nicht wirksam geladen?

Unabhängige Messung ist die dritte Schicht. Ein Betreiber kann nicht allein auf eigene Routeranzeigen vertrauen, wenn die Frage lautet, ob ein Leak über externe Beziehungen sichtbar ist. Interne Logs zeigen, was lokal konfiguriert, angenommen und zurückgezogen wurde. Externe Route Collectors zeigen, was außerhalb gesehen wurde. Aktive Messungen können ergänzen, ob Datenebenenpfade sich tatsächlich verändert haben. Zusammen ergeben sie ein Bild, das falsifizierbar ist. Im 2010er Fall wäre eine belastbare Rücknahme nicht nur die Aussage, dass eine Konfiguration korrigiert wurde.

Sie müsste zeigen, wann die abnormalen Ankündigungen zurückgezogen wurden, wann direkte Nachbarn die Routen nicht mehr sahen, wann unabhängige Kollektoren zur erwarteten Sicht zurückkehrten und ob aktive Pfadmessungen wieder dem Normalzustand entsprachen.

Der Begriff Rücknahme ist dabei mehr als ein BGP-Update. Ein Withdraw im Protokoll kann lokal gesendet werden und trotzdem an unterschiedlichen Beobachtungspunkten zeitversetzt sichtbar sein. Route-Refresh, Session-Reset, lokale Präferenz und Alternativpfade können die äußere Wahrnehmung verändern. Deshalb sollte eine Wiederherstellungsprüfung mehrere Vantage Points enthalten. Sie sollte den Beginn der abnormalen Ankündigung, die erste interne Erkennung, die Alarmierung, die Entscheidung zur Änderung, die gesendeten Withdrawals und die externe Beobachtung trennen.

Nur so lässt sich feststellen, ob die Reparatur die Ursache beseitigt oder nur die Symptome an einem Beobachtungspunkt reduziert hat.

Eine verifizierte Rücknahme müsste außerdem die AS23724-Exportkante und die AS4134-Weitergabekante getrennt behandeln. Wenn AS23724 die abnormalen Ankündigungen beendet, ist der Ursprungsschaden begrenzt, aber es bleibt zu prüfen, ob irgendwo gelernte Routen noch sichtbar sind. Wenn AS4134 eine Route nicht mehr weitergibt, ist die externe Ausbreitung begrenzt, aber es bleibt zu prüfen, ob die Ursprungsankündigung noch an der direkten Sitzung besteht. Wenn weitere Netze die Route nicht mehr bevorzugen, ist die Datenebenenwirkung kleiner, aber das sagt nicht automatisch, dass die Kontrollflächenursache verschwunden ist.

Ein guter Nachweis arbeitet deshalb von innen nach außen und von außen nach innen: lokale Konfiguration, gesendete Updates, empfangene Updates beim Nachbarn, externe Collector-Sicht, aktive Messung, abschließender Abgleich der erwarteten Präfixmenge.

Der Vorfall bleibt auch deshalb aktuell, weil er die Grenze zwischen Registerwahrheit und Routingwirklichkeit offenlegt. Ein Register kann eine Ressource dokumentieren. Ein ROA kann einen Ursprung autorisieren. Ein IRR-Objekt kann Policy-Informationen bereitstellen. Aber ein Router muss aus diesen Daten konkrete Regeln erhalten, und diese Regeln müssen im laufenden Zustand aktiv sein. Der operative Satz lautet: Nicht die Existenz einer Quelle schützt das Routing, sondern die korrekte Übersetzung in Routerpolitik, ihre Anwendung auf der richtigen Sitzung und ihre Überprüfung gegen unabhängige Beobachtung.

Der 2010er Vorfall war kein Papierproblem. Er war ein Running-Code-Problem an den Kanten zwischen autonomen Systemen.

Für China Telecom ergibt sich daraus eine eng begrenzte Verantwortungsfrage. Die öffentlichen Belege rechtfertigen keine Aussage über Absicht, Paketinhalt, Inspektion oder Speicherung. Sie rechtfertigen aber die Frage, wie ein Rechenzentrum-bezogenes AS eine derart große Menge fremder Präfixe originieren konnte, warum ein sichtbarer AS4134-Pfad diese Ankündigungen trug, welche Filter an der AS23724-AS4134-Grenze aktiv waren und wie die Rücknahme unabhängig verifiziert wurde. Das ist keine politische oder moralische Überdehnung.

Es ist die nüchterne Kontrollfrage an Betreiber, deren Routingentscheidungen internationale Reichweite bekommen können.

Die Nutzerwirkung bleibt dagegen unbestimmt. BGPMon und spätere Messarbeiten können zeigen, dass die Kontrollfläche betroffen war. Daraus folgt nicht automatisch, dass jeder betroffene Präfix Traffic über AS23724 oder AS4134 trug. Lokale Präferenz, kürzere oder längere AS-Pfade, Peering-Entscheidungen, MED, Communitys, Filter und Datenebenenrealität bestimmen, welcher Pfad tatsächlich für Pakete genutzt wird. Einige Netze können eine Route gesehen, aber nicht bevorzugt haben. Andere können sie kurz bevorzugt haben. Wieder andere konnten nie betroffen sein.

Ohne Datenebenenmessung, Routerlogs und Verkehrsdaten bleibt die Nutzerwirkung eine offene Frage. Diese Offenheit schwächt die Analyse nicht; sie schützt sie vor falscher Sicherheit.

Die richtige Accountability-Formel lautet daher: groß genug, um eine technische Untersuchung zu verlangen; begrenzt genug, um keine unbelegten Verkehrsschlüsse zu ziehen. Etwa 37.000 von BGPMon beobachtete Präfixe sind ein erheblicher Kontrollflächenumfang. Etwa fünfzehn Minuten sind kurz, aber im globalen Routing lang genug, um externe Propagation, Alarmierung und Rücknahme zu prüfen. Etwa zehn Prozent externe Propagation in BGPMons Beobachtungssatz zeigen internationale Ausbreitung, aber keine globale Datenverkehrsumleitung.

28 Prozent sichtbare RIPE-RIS-Kollektoren in dieser Analyse zeigen Beobachtbarkeit, aber keine vollständige Netzabdeckung. Jede dieser Zahlen ist nützlich, wenn sie auf ihrer Ebene bleibt.