Cogent-Level-3-Depeering 2005: Erreichbarkeit als Härtetest

Zusammenfassung

Level 3 stellte am 5. Oktober 2005 den direkten Verkehrsaustausch mit Cogent ein. Die öffentlichen Aufzeichnungen zeigen, dass einige Kunden die Erreichbarkeit zu Zielen über die Trennung hinweg verloren, während die vollständigen Auswirkungen auf Kunden und Präfixe unbekannt bleiben. [1][21][22]
Cogent forderte Level 3 öffentlich auf, die Verbindung vor weiteren Verhandlungen wiederherzustellen. Die erhaltene öffentliche Position von Level 3 besagte, dass die Testvereinbarung ihre Bedingungen nicht mehr erfüllte. Dies sind zugeschriebene kommerzielle Positionen, keine Feststellungen, dass einer der Anbieter einen Vertrag verletzt oder rechtswidrig gehandelt habe. [1][22]
Ein registriertes Präfix und ein Kundenvertrag schufen keinen funktionierenden Pfad. Die Erreichbarkeit hing von Routen ab, die AS174 und AS3356 austauschten, akzeptierten und auswählten, zusammen mit dem tatsächlich vorhandenen alternativen Transit- oder Multihoming-Anschluss der Kunden.
Merit verwendete ausgewählte RouteViews-Beobachtungen, um die Erreichbarkeit von Cogenents 38.0.0.0/8 zu untersuchen. RouteViews und RIPE RIS können Ankündigungen und Rücknahmen teilnehmender Kollektoren bewahren, aber sie können nicht jede private Richtlinie, lokale Präferenz, jeden Kundenpfad oder jede kommerzielle Bedingung offenlegen. [8]–[10]
Multihoming verringerte das Risiko nur dort, wo alternative Anbieter, akzeptierte Ankündigungen, Kapazität und Anwendungsabhängigkeiten tatsächlich unabhängig waren. Ein zweiter Vertrag ohne wirksame alternative Route war keine Kontinuität.
Am 28. Oktober kündigten die Anbieter eine geänderte settlementfreie Peering-Vereinbarung mit Verkehrspflichten, bedingten Zahlungen und einem Verfahren an, das Kunden schützen sollte, falls die Beziehung später endete oder Verstöße nicht behoben wurden. Die öffentliche Mitteilung beschreibt ein Kontrolldesign, keinen Beweis dafür, dass jedes künftige Interconnection-Risiko verschwand. [2]
Spätere Leitlinien von BGP, MANRS und NIST helfen, messbare Kontrollen wie explizite Richtlinien, Routenüberwachung, Max-Prefix-Grenzen, Koordination und Vorfallbelege zu definieren. Sie sind Vergleichsmaterial, kein rückwirkendes Recht für das Ereignis von 2005. [13]–[20]
Der Rechenschaftsmaßstab ist betrieblich: abhängige Kunden erfassen, alternative Erreichbarkeit vor der Trennung nachweisen, Routen- und Transaktionsauswirkungen während der Änderung beobachten, einen begrenzten Heilungsprozess erhalten und die Wiederherstellung von außerhalb beider Anbieternetze verifizieren.

Interneterreichbarkeit wird oft so verkauft, als wäre sie eine stabile Eigenschaft. Ein Kunde erhält eine Adresse, schließt sich einem Upstream-Anbieter an und sieht Routen zu Zielen auf der ganzen Welt. Aus dieser Perspektive erscheint „das Internet“ als ein durchgehender Dienst. In der Steuerungsebene ist Erreichbarkeit jedoch kein institutionelles Versprechen. Sie ist das aktuelle Ergebnis unabhängiger Netze, die Präfixe ankündigen, diese Ankündigungen annehmen oder ablehnen, Pfade auswählen und Datenverkehr nach ihren eigenen Richtlinien weiterleiten.

Der Streit vom Oktober 2005 zwischen Cogent Communications, das AS174 betrieb, und Level 3 Communications, das AS3356 betrieb, machte diesen Unterschied sichtbar. Am 5. Oktober stellte Level 3 den direkten Verkehrsaustausch mit Cogent ein. Zeitgenössische Aussagen und Berichte beschrieben, dass Kunden in beiden Netzen den Zugang zu einigen Zielen über die entstandene Trennung hinweg verloren. Die Unternehmen blieben mit anderen Teilen des Internets verbunden, und das Ereignis trennte nicht das gesamte globale Netz.

Aber wo kein akzeptabler alternativer Weg ein von Cogent erreichbares Ziel mit einer von Level 3 erreichbaren Quelle verband, konnten Registrierungsdaten und Kundenerwartungen Pakete nicht über die fehlende Zusammenschaltung befördern.

Dies war ein bewusstes Depeering, kein Routenleck, keine Routenentführung und keine versehentliche BGP-Ankündigung. Der betriebliche Fehler entstand durch die Entfernung eines Pfades, der zuvor Verkehr zwischen zwei großen Netzen getragen hatte. Diese Unterscheidung bestimmt, welche Beweise zählen. Untersuchende müssen die Interconnection-Entscheidung, BGP-Routenänderungen, alternative Pfade, Kundenabhängigkeit, Multihoming, Kommunikation und Wiederherstellung untersuchen. Eine allgemeine Darstellung einer kommerziellen Meinungsverschiedenheit übersieht den Mechanismus, der die Meinungsverschiedenheit folgenreich machte.

Die Episode testet außerdem eine besondere Art von Rechenschaftspflicht. Peering und Transit sind unterschiedliche kommerzielle Vereinbarungen, und die öffentlichen Aufzeichnungen beschreiben die wiederhergestellte Beziehung als settlementfreies Peering und nicht als bezahlten Transit. Dennoch verkauften beide Unternehmen Konnektivität innerhalb eines Ökosystems, dessen Wert von der Erreichbarkeit zwischen Domänen abhing. Die Frage der Rechenschaftspflicht lautet daher nicht, ob zwei autonome Systeme kostenlos peeren müssen.

Sie lautet, ob Anbieter, die eine folgenreiche Zusammenschaltung kontrollieren, Kundenabhängigkeiten erkennen, eine Trennung steuern können ohne die betrieblichen Folgen zu verschleiern, Beweise sichern und die Wiederherstellung nachweisen können.

Erreichbarkeit existiert im laufenden Pfad

Eine IP-Adresszuweisung kann den Inhaber eines Blocks identifizieren. Eine Autonomous-System-Nummer kann eine Routing-Domäne identifizieren. Ein Vertrag kann festhalten, was ein Kunde gekauft hat, und eine Interconnection-Vereinbarung kann beschreiben, was zwei Anbieter voneinander erwarten. Keiner dieser Datensätze installiert für sich genommen eine Route in der Weiterleitungstabelle eines Routers.

Damit ein Paket von einem Kunden hinter AS174 zu einem Ziel hinter AS3356 gelangen konnte, benötigten die beteiligten Netze eine Abfolge akzeptierter Routen in beide Richtungen. Diese Abfolge konnte die direkte Cogent-Level-3-Zusammenschaltung nutzen. Sie konnte stattdessen über einen anderen Anbieter führen, wenn Exportrichtlinien, kommerzielle Beziehungen, Kapazität und Routenauswahl diesen Pfad zuließen. Wenn kein Netz eine akzeptable Alternative ankündigte, konnte das Ziel weiterhin gültig registriert und korrekt originär sein und war dennoch von der anderen Seite aus nicht erreichbar.

Das macht „vollständige Internet-Erreichbarkeit“ zu einer betrieblichen Kurzform und nicht zu einer absoluten Garantie, dass jeder Host immer antwortet. Firewalls, Anwendungsfehler und lokale Richtlinien können einen bestimmten Dienst selbst dann unerreichbar machen, wenn eine Netzroute existiert. Die relevante Frage im Streit von 2005 ist enger: Bietete das gewöhnliche Interdomain-Routing nutzbare Pfade zwischen Präfixen, deren praktische Verbindung von der AS174-AS3356-Beziehung abhängig gewesen war?

Das Marktetikett eines Anbieters beantwortet diese Frage nicht. Ein Netz als großes Backbone oder Tier-1-Betreiber zu bezeichnen, kann Größe oder kommerzielle Stellung anzeigen, schafft aber keine weltweit durchgesetzte Routing-Pflicht. Jedes autonome System behält die Kontrolle über die Routen, die es exportiert, die Routen, die es akzeptiert, und die Pfade, die es bevorzugt. Das Internet hat keinen zentralen Router, der zwei Netze anweisen kann, nach Beendigung einer bilateralen Beziehung weiter Verkehr auszutauschen.

Diese Unabhängigkeit ist eine der Stärken des Internets. Sie erlaubt Netzen, unterschiedliche Sicherheits-, technische und kommerzielle Entscheidungen zu treffen, ohne eine zentrale Autorität um Erlaubnis zu fragen. Dieselbe Unabhängigkeit schafft ein Kontinuitätsproblem: Eine bilaterale Entscheidung kann Auswirkungen über die beiden Parteien hinaus haben, wenn Kunden keinen nutzbaren Weg daran vorbei haben. Rechenschaftspflicht muss daher der praktischen Kontrolle folgen und nicht Etiketten.

Der Betreiber, der eine Session kontrolliert, kontrolliert, ob diese Session verfügbar bleibt; ein Betreiber, der Konnektivität verkauft, kontrolliert, welche Ausfallsicherheit er liefert oder empfiehlt; ein Kunde kontrolliert seine eigene Redundanz nur innerhalb technischer und finanzieller Grenzen.

Das Ereignis von 2005 führte diese Ebenen zusammen. Die Unternehmen hatten eine kommerzielle Meinungsverschiedenheit, aber ihre kundenseitige Wirkung wurde über BGP ausgedrückt. Die entscheidenden Fakten waren nicht einfach, was die Parteien als Vertragspflichten ansahen. Es ging darum, welche Routen nicht mehr ausgetauscht wurden, welche alternativen Routen akzeptabel blieben, welche Kunden vom entfernten Pfad abhingen und wie die direkte Beziehung wiederhergestellt wurde.

Eine begrenzte Chronologie des Oktober-Streits

Die belastbare Chronologie beginnt am 5. Oktober 2005, als Level 3 den direkten Verkehrsaustausch mit Cogent einstellte. Öffentliches Material beschreibt die Handlung als Beendigung der direkten Peering-Beziehung der Unternehmen. Die verfügbaren Beweise legen weder das vollständige physische Layout dieser Zusammenschaltung noch die Zahl der beteiligten Sessions oder Ports noch die Kapazität an jedem Standort fest. „Die Verbindung“ ist daher nicht als Beleg zu lesen, dass ein Kabel oder ein Router die gesamte Beziehung darstellte.

Zeitgenössische Berichte rahmten die Folge schnell als Erreichbarkeitsproblem. Einige Nutzer und Unternehmen, die über ein Netz verbunden waren, konnten Berichten zufolge keine Ziele erreichen, die vom anderen abhingen. Diese Berichte stützen den Schluss, dass das Depeering echte Kundenauswirkungen hatte. Sie belegen weder eine vollständige Liste betroffener Präfixe noch einen flächendeckenden Ausfall bei einem der Anbieter, gleiche Auswirkungen auf beiden Seiten oder einen genauen Prozentsatz des unerreichbar gewordenen Internets.

Am 7. Oktober forderte Cogent Level 3 öffentlich auf, die Zusammenschaltung wiederherzustellen, bevor die Unternehmen die Verhandlungen fortsetzten. Diese Aussage belegt Cogenents Position und vorgeschlagene Reihenfolge: zuerst die Kundenkonnektivität wiederherstellen, dann den Streit behandeln. Sie legt weder die vertraulichen Pflichten einer Partei unabhängig fest, noch entscheidet sie, ob die frühere Vereinbarung ihren Bedingungen entsprach.

Level 3 bot eine andere öffentliche Erklärung an. Die in der zeitgenössischen Berichterstattung erhaltene Stellungnahme beschrieb die beendete Beziehung als eine Test-Peering-Vereinbarung, die die geltenden Bedingungen nicht mehr erfüllte. Das ist ein Beleg für den von Level 3 genannten Grund. Die öffentlichen Aufzeichnungen liefern weder die vollständige Vereinbarung, die zu ihrer Bewertung verwendeten Messungen, die konkreten Verkehrsmerkmale noch die internen Überlegungen, die zur Trennung führten.

Sie können nicht die Feststellung stützen, Cogent habe eine bestimmte unveröffentlichte Bedingung verletzt oder die Einschätzung von Level 3 sei falsch gewesen.

Von NANOG archivierte Betreiberdiskussionen dokumentierten zeitgenössische Fragen zu Pfaden und Erreichbarkeit. Solche Nachrichten sind wertvoll, weil sie zeigen, was Netzwerkingenieure während des Ereignisses beobachteten und testeten. Sie sind keine kontrollierte Bestandsaufnahme des Internets. Die Teilnehmer hatten unterschiedliche Beobachtungspunkte, kommerzielle Beziehungen und Zugriff auf Routing-Informationen. Ein Bericht eines Netzes konnte dessen Pfad genau beschreiben, ohne festzulegen, was jedes andere Netz sah.

Am 28. Oktober gaben Cogent und Level 3 gemeinsam bekannt, eine geänderte settlementfreie Peering-Vereinbarung erreicht zu haben. Ihre Mitteilung beschrieb Pflichten zu Verkehrsmerkmalen und -volumen, Zahlungen bei Nichterfüllung dieser Pflichten und ein Verfahren, das Schäden für Kunden verringern sollte, falls die Beziehung später endete oder ein Verstoß unbehoben blieb. Die Ankündigung ist der stärkste gemeinsame öffentliche Beleg für die Struktur der Abhilfe, weil beide Unternehmen sie gemeinsam veröffentlichten.

Die Mitteilung war dennoch nicht der vollständige Vertrag. Sie legte nicht alle Schwellenwerte, Messmethoden, Heilungsfristen, Betriebsabläufe oder Entscheidungsrechte öffentlich offen. Ihre Existenz beweist auch nicht, dass jeder Kundenpfad im selben Moment wiederhergestellt wurde oder dass alle späteren Interconnection-Risiken verschwanden. Sie zeigt, dass die Unternehmen ihre Beziehung zu überarbeiteten Bedingungen wiederherstellten und Kundenschutzverfahren öffentlich als Teil der Lösung benannten.

Spätere FCC-Unterlagen behandelten das Ereignis in breiteren Analysen der Internet-Zusammenschaltung, des Backbone-Wettbewerbs und der Kundenerreichbarkeit. Diese Unterlagen helfen zu erklären, warum ein Streit zwischen großen Netzen Parteien betreffen konnte, die nicht Unterzeichner der Peering-Vereinbarung waren. Sie sollten nicht in ein rechtliches Urteil über das Verhalten von 2005 umgewandelt werden. Die zitierten Materialien belegen nicht, dass einer der Anbieter ein Gesetz, eine Vorschrift oder einen Vertrag verletzte.

Was sich in BGP änderte

BGP ermöglicht autonomen Systemen den Austausch von Erreichbarkeitsinformationen. Eine Routenankündigung identifiziert ein erreichbares Präfix und trägt Attribute, die empfangenden Netzen helfen, Richtlinien anzuwenden und Pfade auszuwählen. Der AS-Pfad verzeichnet autonome Systeme, durch die die Ankündigung weitergegeben wurde, während andere Attribute und lokal konfigurierte Präferenzen beeinflussen, welche Route ein Netz installiert.

Der Entscheidungsprozess ist dezentral. Cogent konnte Kunden- und interne Präfixe gemäß seiner Exportrichtlinie an Level 3 ankündigen. Level 3 konnte diese Ankündigungen gemäß seiner Importrichtlinie annehmen, filtern oder bevorzugen und anschließend ausgewählte Routen geeigneten Kunden oder Peers zugänglich machen. Der umgekehrte Prozess galt für Level-3-Routen, die Cogent erreichten. Keines der Unternehmen kontrollierte jedes dazwischenliegende Netz, und keines konnte einen Dritten zwingen, einen alternativen Pfad zu exportieren.

Wenn eine direkte externe BGP-Beziehung beendet wird, sind Routen, die ausschließlich über diese Beziehung gelernt wurden, nach Rücknahmen, Session-Verlust oder Richtlinienentfernung nicht mehr nutzbar. Router prüfen dann erneut andere verfügbare Pfade. Wenn ein anderer Anbieter eine akzeptable Route ankündigt, kann der Verkehr auf diese Route wechseln. Fehlen Alternativen, sind sie gefiltert oder kommerziell nicht verfügbar, hat der betroffene Router keinen nutzbaren Pfad zum Ziel.

Deshalb kann dasselbe Depeering für verschiedene Kunden unterschiedliche Ergebnisse haben. Ein Netz kann einen anderen Upstream haben, der einen Pfad zwischen den beiden Seiten trägt. Ein anderes erhält möglicherweise nur die Routen, die mit der direkten Session verschwanden. Ein drittes sieht möglicherweise einen alternativen Pfad, lehnt ihn jedoch wegen Richtlinien, Präfixlängenregeln oder Beziehungsbeschränkungen ab. Ein viertes wählt möglicherweise eine alternative Route, deren Kapazität oder Rückweg keinen zuverlässigen Anwendungsverkehr trägt.

Der Verlust des direkten Pfades muss auch keine symmetrischen Symptome erzeugen. BGP-Entscheidungen werden von jedem Netz separat getroffen, und Datenverkehr benötigt funktionierende Hin- und Rückwege. Ein Paket kann ein Ziel erreichen, während seine Antwort keinen nutzbaren Rückweg findet. Unterschiedliche lokale Präferenzen können die beiden Richtungen über verschiedene autonome Systeme führen. Folglich beweist eine erfolgreiche Routenbeobachtung in einer Richtung keinen vollständigen bidirektionalen Dienst.

Die öffentlichen Aufzeichnungen legen die vollständigen Local-Preference-Konfigurationen von Cogent und Level 3 nicht offen. Sie offenbaren nicht jeden Routenfilter, Community-Umgang, privaten Peer oder Drittanbieter-Transit. Öffentliche AS-Pfade können nahelegen, wie der Verkehr geflossen sein könnte, aber sie können nicht alle internen Richtlinien offenlegen, die die Routenauswahl bestimmten.

BGP-Communities fügen eine weitere mögliche Beweisebene hinzu. RFC 1997, der vor dem Ereignis datiert, definiert eine Möglichkeit, richtlinienrelevante Tags an Routen anzuhängen. Netze können Communities nutzen, um Propagierungsverhalten anzufragen oder zu signalisieren. Bedeutung und Implementierung vieler Communities sind jedoch netzspezifisch. Selbst wenn eine Community in einem öffentlichen Update erscheint, legt sie nicht automatisch die private Vereinbarung offen, die die Route regelt, und beweist nicht, dass jeder Router die beabsichtigte Richtlinie anwandte.

Das Ereignis lässt sich daher nicht auf „die Routen verschwanden überall“ reduzieren. AS174 und AS3356 blieben in Betrieb, und mit ihnen verbundene Präfixe konnten von vielen Standorten aus sichtbar bleiben. Die engere Frage war, ob Pfade, die die frühere Beziehung kreuzten, über andere Netze verfügbar blieben. Ein an einem Kollektor sichtbares Präfix konnte von einem bestimmten Kunden aus unerreichbar sein. Umgekehrt konnte eine an einem Kollektor fehlende Route anderswo über einen privaten oder anders ausgewählten Pfad erreichbar bleiben.

Routengültigkeit kann Konnektivität auch nicht garantieren. Ein korrekt originäres Präfix kann unerreichbar sein, weil keine akzeptable Route ein bestimmtes Netz erreicht. Moderne Origin-Validierungsmechanismen können helfen festzustellen, ob ein Ursprung autorisiert ist, aber sie können zwei autonome Systeme nicht zwingen, eine Peering-Session aufrechtzuerhalten, und kein drittes Netz verpflichten, Verkehr zwischen ihnen zu tragen. Der Fehler von 2005 betraf Pfadverfügbarkeit und Richtlinien, nicht einfach Adressbesitz oder Ursprungsauthentizität.

Warum einige Netze die Trennung umgehen konnten

Multihoming ist der offensichtlichste Resilienzmechanismus bei einem Depeering-Ereignis. Ein Kunde, der mit mehr als einem Upstream verbunden ist, kann sein Präfix über mehrere Netze ankündigen und Ziele über mehr als einen Pfad lernen. Wenn ein Upstream die Erreichbarkeit zu einem Teil des Internets verliert, kann der andere einen nutzbaren Weg erhalten.

Diese Beschreibung ist technisch korrekt, aber als Rechenschaftsantwort unvollständig. Multihoming erfordert mehr als die Unterzeichnung eines zweiten Zugangsvertrags. Der Kunde benötigt möglicherweise Adressraum, den beide Upstreams akzeptieren, eine Autonomous-System-Nummer, kompatible Routing-Ausrüstung, Personal, das BGP betreiben kann, Routenfilter, Überwachung, Sicherheitskontrollen und ausreichende Kapazität auf der alternativen Verbindung. Auch der Rückweg muss auf eine funktionierende Route konvergieren.

Anwendungen mit zustandsbehafteten Firewalls, Adressabhängigkeiten oder Empfindlichkeit gegenüber Pfadänderungen benötigen möglicherweise zusätzliche Technik.

Kommerzielle Richtlinien zählen ebenfalls. Ein alternativer Anbieter muss bereit und in der Lage sein, die relevanten Routen zu exportieren. Ein Kunde kann nicht annehmen, dass zwei beliebige Verbindungen einen Pfad über jeden Streit zwischen Upstream-Netzen hinweg schaffen. Präfixlängenfilter können verhindern, dass spezifischere Ankündigungen weitergegeben werden. Ein alternativer Leitungsweg, der für Notfall-Management-Verkehr dimensioniert ist, trägt möglicherweise keine normale Produktionslast. Eine nominell diverse Verbindung kann physische Einrichtungen oder eine gemeinsame Upstream-Abhängigkeit teilen.

Aus diesen Gründen beweist das Vorhandensein von Multihoming nicht, dass jeder multihomed Kunde den Dienst behielt. Es begründet eine mögliche Kontrolle, deren Wirksamkeit getestet werden muss. Ebenso begründet das Fehlen von Multihoming für sich genommen keine Unvorsichtigkeit. Kleine Kunden können Budget, Fachwissen, Adressressourcen oder Verhandlungsmacht fehlen, um unabhängig geroutete Verbindungen zu betreiben. Ein als gewöhnlicher Internetzugang verkaufter Dienst kann vernünftigerweise genutzt werden, ohne dass der Kunde ein Miniatur-Backbone aufbaut.

Single-Homed-Kunden waren einer schärferen Abhängigkeit ausgesetzt. Wenn ihr einziger Upstream keinen akzeptablen Weg zu Zielen auf der anderen Seite hatte, konnten sie nach dem Depeering keine Backbone-Zusammenschaltung wiederherstellen. Sie konnten Notfalldienst von einem anderen Anbieter suchen, aber Bereitstellung, Routenakzeptanz, Ausrüstung und Verträge brauchen Zeit. Die Partei, die die entfernte Zusammenschaltung kontrollierte, konnte die Routenverfügbarkeit weit schneller ändern, als viele abhängige Kunden sie ersetzen konnten.

Drittanbieter waren ein weiterer Teil des Pfades. Ein alternatives Netz konnte Beziehungen zu Cogent und Level 3 haben, aber seine Exportrichtlinie erlaubte ihm möglicherweise nicht, als Vermittler zwischen ihnen zu agieren. Interdomain-Routing spiegelt gewöhnlich kommerzielle Rollen wider: Ein Anbieter kann Kundenrouten breit ankündigen, aber keinen kostenlosen Transit zwischen Peers anbieten. Öffentliche BGP-Pfade können Rückschlüsse auf diese Beziehungen stützen, aber die Dokumentation von CAIDA betont, dass die zugrunde liegenden kommerziellen Vereinbarungen im Allgemeinen vertraulich sind und oft abgeleitet werden müssen.

Das ist wichtig, weil eine topologische Zeichnung die Resilienz überschätzen kann. Zwei Netze können beide mit einem dritten autonomen System verbunden sein, ohne einen nutzbaren Pfad über dieses zu erhalten. Die relevante Frage ist nicht, ob auf einer Karte eine Linie existiert. Sie lautet, ob Routen unter realen Richtlinien exportiert, akzeptiert und ausgewählt werden – mit genügend Weiterleitungskapazität für den entstehenden Verkehr.

Eine belastbare Kontinuitätsbewertung würde Kunden daher nach beobachteter Abhängigkeit klassifizieren statt nach einem einfachen Label multihomed oder single-homed. Sie würde fragen, welche Präfixe verifizierte alternative Pfade hatten, welche Dienste bidirektionale Erreichbarkeit besaßen, ob die Kapazität ausreichend blieb und wie lange jede Kundengruppe beeinträchtigt war. Die eingefrorenen öffentlichen Beweise liefern diese vollständige Matrix für Oktober 2005 nicht, daher müssen Aussagen über die Verteilung der Auswirkungen begrenzt bleiben.

Rekonstruktion des Ereignisses aus öffentlichen Routenbeweisen

Öffentliche Routenkollektoren bieten ein wichtiges, aber unvollständiges Fenster in den Vorfall. RouteViews archivierte BGP-Updates aus Oktober 2005, sodass Untersuchende Ankündigungen und Rücknahmen teilnehmender Peers prüfen können. RIPE RIS erläutert die vergleichbare Rolle verteilter Kollektoren: Sie zeichnen Routing-Informationen auf, die von Netzen sichtbar sind, die sich entscheiden, mit ihnen zu peeren.

Die BGP-Inspektions-Fallstudie von Merit behandelt das Cogent-Level-3-Ereignis als Routenanalyseübung und untersucht die Erreichbarkeit von Cogenents 38.0.0.0/8 von ausgewählten RouteViews-Peers aus. Das ist eine nützliche, begrenzte Untersuchung. Sie verwandelt ein Aggregat und ausgewählte Beobachtungspunkte nicht in ein vollständiges Inventar der Cogent-Kunden, Level-3-Kunden oder global betroffenen Routen.

Eine gründliche Rekonstruktion beginnt damit, Ereignisanker von Routenbeobachtungen zu trennen. Die Unternehmensaussagen belegen, dass die direkte Beziehung bewusst beendet und später wiederhergestellt wurde. Kollektordaten können dann zeigen, wie bestimmte Routen vor, während und nach diesen Änderungen für teilnehmende Peers erschienen. Zeitgenössische Betreibernachrichten, Traceroutes und Kundenberichte können prüfen, ob die beobachteten Änderungen der Steuerungsebene mit Weiterleitungs- oder Anwendungsfehlern zusammenhingen.

Die zeitliche Zuordnung ist wichtig. BGP-Update-Ströme enthalten gewöhnliche Routing-Unruhe ebenso wie vorfallbezogene Änderungen. Sessions werden aus vielen Gründen zurückgesetzt; Präfixe können unabhängig von einem Peering-Streit zurückgenommen und erneut angekündigt werden. Man sollte nicht jedes Update in der Nähe des 5. Oktober als durch das Depeering verursacht kennzeichnen. Die stärkere Schlussfolgerung ergibt sich aus wiederholten Änderungen relevanter Pfade, konsistenter zeitlicher Abfolge über unabhängige Beobachtungspunkte und Bestätigung durch betriebliche Beobachtungen.

Kollektorvielfalt ist ebenso wichtig. Ein RouteViews-Peer liefert die Routen, die er ausgewählt und an den Kollektor zu exportieren beschlossen hat. Er legt nicht jede vom Peer erwogene Route, jede durch Richtlinien abgelehnte Route oder jeden Weiterleitungstabelleneintrag im Netz offen. Ein RIS-Kollektor unterliegt derselben grundlegenden Einschränkung. Mehr Kollektoren erhöhen die Sichtbarkeit, aber keine endliche Menge erzeugt einen allwissenden Blick auf jede private Zusammenschaltung und jeden Router.

Auch AS-Pfad-Beweise erfordern Zurückhaltung. Der sichtbare Pfad identifiziert die in der ausgewählten Ankündigung aufgeführten autonomen Systeme. Er offenbart keine internen Router-Hops, Portauslastung, Vertragspreise oder den gesamten tatsächlich über diesen Pfad weitergeleiteten Verkehr. Lokale Präferenz verbreitet sich gewöhnlich nicht zwischen autonomen Systemen, sodass ein externer Beobachter möglicherweise nicht weiß, warum ein Pfad gewann. Privates Peering kann in öffentlichen Kollektordaten fehlen.

Eine Rücknahme ist ohne Kontext ähnlich mehrdeutig. Sie kann bedeuten, dass eine Route für den ankündigenden Peer nicht mehr verfügbar ist, dass sich die Exportrichtlinie änderte oder dass eine Session ausfiel. Sie identifiziert für sich genommen nicht die geschäftliche Entscheidung hinter der Änderung. In diesem Fall liefern die Unternehmensaussagen die Absicht, die rohe Updates nicht liefern können: Die Zusammenschaltung endete bewusst.

Traceroutes fügen Hinweise zur Weiterleitung hinzu, aber keine Allwissenheit. Router können Antworten unterdrücken, Adressen verwenden, die nichts mit dem sichtbaren Pfad zu tun haben, oder Verkehr asymmetrisch weiterleiten. Eine abbrechende Traceroute identifiziert nicht immer den genauen Fehlerpunkt. Eine erfolgreiche Traceroute von einem Standort belegt keine Erreichbarkeit von allen Standorten. Wiederholte Traces aus unabhängigen Netzen können dennoch helfen, ein lokales Anwendungsproblem von einem breiteren Fehlen von Interdomain-Pfaden zu unterscheiden.

Kundenberichte liefern eine weitere Schicht. Ein Unternehmen, das eine Website über die Trennung hinweg nicht erreichen kann, liefert einen Beleg für praktischen Schaden. Der Bericht allein identifiziert jedoch möglicherweise nicht, welcher Upstream, welche Routenrichtlinie oder welcher Rückweg den Fehler verursachte. Die belastbarste Darstellung gleicht die Beschwerde mit Quell- und Zielpräfixen, Zeitstempeln, BGP-Beobachtungen und, soweit verfügbar, Hin- und Rückwegtests ab.

Die resultierenden Beweise sollten mit Vertrauensstufen angegeben werden. Eine direkte Unternehmensankündigung kann belegen, dass die Beziehung beendet oder wiederhergestellt wurde. Ein Kollektor kann belegen, dass ein teilnehmender Peer zu einem bestimmten Zeitpunkt einen bestimmten Pfad ankündigte. Mehrere unabhängige Routen- und Weiterleitungsbeobachtungen können eine breitere Schlussfolgerung stützen. Keine davon allein liefert die vollständige Kundenliste, den privaten Vertrag oder die genauen weltweiten Auswirkungen.

FCC-Materialien ergänzen Marktkontext statt Beweise auf Paketebene. Ihre Erörterung von Backbone-Zusammenschaltung und Netzwerkeffekten hilft zu erklären, warum Kunden den Zugang zu Zielen außerhalb ihres eigenen Anbieters schätzen. Spätere regulatorische Verweise auf den Cogent-Level-3-Streit zeigen dessen Relevanz für die Interconnection-Politik. Sie ersetzen keine Routenbeweise und entscheiden nicht über die rechtliche Verantwortung für einzelne Kundenverluste.

Warum dies kein Routenleck und keine Entführung war

Ein Routenleck betrifft im Allgemeinen die Weitergabe von Routing-Informationen über den durch die jeweiligen Beziehungen beabsichtigten Umfang hinaus. Das resultierende Problem ist oft das Vorhandensein oder die Auswahl eines unbeabsichtigten Pfades. Eine Entführung betrifft im Allgemeinen einen unberechtigten Ursprung oder eine andere falsche Routing-Behauptung, die Verkehr umleitet oder abfängt. Beides kann Erreichbarkeits- und Sicherheitsfehler verursachen, aber die Mechanismen unterscheiden sich vom bewussten Depeering.

Das Cogent-Level-3-Ereignis betraf die Entfernung des direkten Routenaustauschs. Die öffentlichen Aussagen beschreiben eine absichtliche Interconnection-Entscheidung. Der zentrale Fehler war, dass einige Pfade nicht mehr verfügbar waren, nicht dass ein Anbieter fälschlich die Präfixe des anderen originär ankündigte oder sich versehentlich als Transit für Routen bezeichnete, die er nicht hätte weitergeben dürfen.

Dieser Unterschied verändert die geeigneten Kontrollen. Präfixfilterung und Origin-Validierung können die Annahme unberechtigter Ankündigungen verringern. Beziehungsbewusste Exportrichtlinien können Routenlecks verringern. Diese Mechanismen zwingen einen Betreiber nicht, eine gültige Peering-Beziehung fortzusetzen. Ein perfekt gefilterter Router kann nach einer bewussten Session-Beendigung weiterhin keine Route zu einem Ziel haben.

Rohe BGP-Daten können den Unterschied allein nicht immer offenbaren. Ein Kollektor kann Rücknahmen, Ersatzpfade oder Sichtbarkeitsverlust sehen. Die Absicht wird erst klar, wenn diese Beobachtungen mit den öffentlichen Erklärungen der Unternehmen kombiniert werden. Die Episode als Leck oder Entführung zu bezeichnen, würde sowohl die Beweise als auch die Kontrollfläche falsch darstellen.

Die Unterscheidung schützt auch den historischen Vergleich vor Rückschaufehlern. Spätere Routenleck-Taxonomien und Relationship-Role-Mechanismen helfen heutigen Betreibern, Routing-Absichten auszudrücken und zu prüfen. Sie beweisen nicht, dass die Trennung von 2005 ein versehentlicher Richtlinienausbruch war, und sie schaffen keine rückwirkenden Pflichten für die kommerzielle Entscheidung der Unternehmen.

Kommerzielle Positionen und betriebliche Rechenschaftspflicht

Die vertraulichen Peering-Bedingungen sind für jeden Vertragsstreit wichtig, aber sie sind nicht notwendig, um das Problem der Kundenkontinuität zu identifizieren. Die beiden Unternehmen stritten öffentlich darüber, ob die Testbeziehung weiterhin ihre Bedingungen erfüllte. Ohne die vollständige Vereinbarung und die zugrunde liegenden Messungen kann eine externe Darstellung nicht bestimmen, welche kommerzielle Auslegung richtig war.

Betriebliche Rechenschaftspflicht beginnt an einem anderen Punkt. Sobald ein Betreiber weiß, dass die Beendigung einer Zusammenschaltung für einige Kunden den einzigen funktionierenden Pfad entfernen kann, hat die Entscheidung messbare Kontinuitätsfolgen. Diese Folgen können untersucht werden, ohne zu erklären, dass der Betreiber kein vertragliches Recht zur Beendigung hatte.

Diese Trennung vermeidet zwei entgegengesetzte Fehler. Der erste ist die Annahme, jede Kundenauswirkung beweise Fehlverhalten. Netze müssen die Fähigkeit behalten, Vereinbarungen durchzusetzen, Infrastruktur zu schützen und Beziehungen zu beenden. Ein Kontinuitätsstandard, der faktisch ewiges settlementfreies Peering vorschreibt, würde legitime betriebliche und kommerzielle Autonomie auslöschen.

Der zweite Fehler ist, einen bilateralen Vertragsstreit so zu behandeln, als hätte er nur bilaterale Auswirkungen. Kunden waren keine Parteien der Peering-Beziehung, doch einige hingen von darüber ausgetauschten Routen ab. Wenn keiner der Anbieter diese Abhängigkeit erfasst, Alternativen getestet oder ein begrenztes Trennungsverfahren eingerichtet hatte, bliebe das Fehlen dieser Kontrollen selbst dann wichtig, wenn die Beendigung vertraglich zulässig war.

Rechenschaftspflicht ist daher nicht gleichbedeutend mit Schuldzuweisung. Sie ist eine Beweisdisziplin, die fragt, wer jede Entscheidung kontrollierte, was jede Partei vernünftigerweise beobachten konnte, welche Schutzmaßnahmen existierten und ob das Ergebnis verifiziert wurde. Rechtliche Haftung erfordert zusätzliche Tatsachen und anwendbares Recht. Die öffentlichen Aufzeichnungen belegen hier keinen Vertragsbruch, keine Fahrlässigkeit, keinen bösen Glauben, kein Monopolverhalten und keinen Verstoß gegen Vorschriften.

Behauptungen über Verkehrsungleichgewichte veranschaulichen, warum Zuschreibung entscheidend ist. Die öffentliche Erklärung von Level 3 verwies auf Bedingungen für die Testvereinbarung, während die spätere gemeinsame Mitteilung Verkehrsmerkmale, Volumenpflichten und bedingte Zahlungen beschrieb. Diese Aussagen zeigen, dass verkehrsbezogene kommerzielle Kriterien Teil des öffentlichen Streits und der Abhilfe waren. Sie legen nicht die genauen Verhältnisse, Schwellenwerte, Messintervalle oder Preise offen.

Ein Routenkollektor kann diese Lücke nicht füllen. AS-Pfade zeigen angekündigte Erreichbarkeit, nicht Verkehrsvolumen. Selbst Interface-Zähler bräuchten Kontext zu Standort, Richtung, Aggregation und vertraglicher Messung. Vertrauliche Peering-Schwellen aus öffentlichen BGP-Daten abzuleiten, würde die Routing-Steuerungsebene mit kommerzieller Buchführung verwechseln.

Die richtige Schlussfolgerung ist begrenzt: Eine kommerzielle Meinungsverschiedenheit führte zur bewussten Entfernung des direkten Routenaustauschs; einige Kunden verloren Berichten zufolge die Erreichbarkeit; die Parteien brachten öffentlich unterschiedliche Erklärungen vor; und sie stellten die Zusammenschaltung später zu überarbeiteten Bedingungen wieder her, die Kundenschutzverfahren umfassten. Die Beweise entscheiden nicht über die unveröffentlichten vertraglichen Verdienste.

Eine Kontrollkarte für den Fehler

Level 3 kontrollierte seine Entscheidung, die direkte Peering-Beziehung zu beenden, und seine Seite der relevanten BGP-Sessions. Es kontrollierte auch die Routen, die es akzeptierte und exportierte, seine interne Eskalation, seine Kommunikation mit Kunden und jedes gestufte oder sofortige Trennungsverfahren. Diese Bereiche definieren seine betriebliche Rechenschaftspflicht, ohne zu klären, ob die Beendigung kommerziell gerechtfertigt war.

Cogent kontrollierte seine eigenen Sessions, Routenankündigungen, Import- und Exportrichtlinien, Kundenkommunikation und Resilienzangebote. Seine Erklärung vom 7. Oktober schlug eine sofortige Wiederherstellung vor weiteren Verhandlungen vor, aber öffentliche Forderungen beseitigen nicht die eigenen Verantwortlichkeiten. Cogent war in der Lage zu verstehen, welche Kunden von seinen Upstream- und Peer-Beziehungen abhingen, welche Alternativen es liefern konnte und welche Einschränkungen die verkaufte Konnektivität begleiteten.

Beide Anbieter teilten die Kontrolle über die bilaterale Wiederherstellung. Eine Seite konnte anbieten, eine Session wiederherzustellen, aber eine funktionierende Zusammenschaltung erforderte kompatible Maßnahmen beider Seiten: aktive Sessions, akzeptierte Routen, funktionierende Richtlinien und funktionierende Weiterleitung. Die gemeinsame Ankündigung zeigt, dass die Beziehung durch Vereinbarung und nicht durch einseitige Routing-Aktionen wiederhergestellt wurde.

Andere Anbieter kontrollierten mögliche alternative Pfade. Ihre Richtlinien bestimmten, ob sie Routen zwischen den beiden Seiten tragen würden und unter welcher kommerziellen Beziehung. Sie kontrollierten auch Kapazität, Filterung und Vorfallkommunikation in ihren eigenen Netzen. Ihre Präsenz in der Topologie garantierte nicht, dass sie einen akzeptablen Pfad bereitstellen würden.

Kunden kontrollierten einige Resilienzentscheidungen, darunter ob sie diverse Verbindungen kauften, BGP betrieben, Dienste über Netze verteilten oder externe Erreichbarkeit überwachten. Diese Kontrolle war durch Kosten, technische Fähigkeiten, Adressressourcen, Vertragsverfügbarkeit und Bereitstellungszeit eingeschränkt. Es wäre unzutreffend, jeden betroffenen Kunden als zu sofortigem Multihoming fähig zu behandeln.

Register kontrollierten Aufzeichnungen zu Autonomous-System-Nummern und Adressressourcen. Diese Aufzeichnungen unterstützten Identität und Routing-Verwaltung, setzten aber keinen funktionierenden Pfad zwischen AS174 und AS3356 durch. Ein korrekter Registereintrag konnte einem Betreiber helfen zu wissen, wer ein Präfix ankündigte oder wen er kontaktieren sollte. Er konnte eine beendete BGP-Beziehung nicht wiederherstellen.

Routenkollektor-Betreiber kontrollierten Messinfrastruktur, nicht die Produktionspfade. Ihre Archive ermöglichen spätere Analysen, aber ein Kollektor kann einen Anbieter nicht veranlassen, eine Route zu akzeptieren. Messung ist ein Rechenschaftsbuch: Sie zeichnet einen Teil dessen auf, was teilnehmende Netze offenlegten. Sie ist kein Ersatz für betriebliche Kontinuität.

Regulierungsbehörden konnten die Marktstruktur prüfen und gesetzlich verliehene Befugnisse ausüben, aber sie betrieben die Router nicht. FCC-Unterlagen liefern Kontext zu Interconnection-Anreizen und Netzwerkeffekten. Sie belegen nicht, dass die Behörde die Wiederherstellung von 2005 anordnete oder eines der Unternehmen rechtlich verantwortlich machte.

Diese Karte verhindert, dass Verantwortung auf einen bequemen Akteur zusammenschrumpft. Trennungsentscheidung, kommerzieller Streit, Bestand der alternativen Pfade, Kundenresilienz und Wiederherstellung wurden von verschiedenen Parteien kontrolliert. Wirksame Rechenschaftspflicht zeichnet diese Aufteilungen auf, statt anzunehmen, dass die Rolle eines Akteurs alle anderen aufhebt.

Die Vereinbarung vom 28. Oktober als Abhilfedesign

Die gemeinsame Ankündigung vom 28. Oktober ist wichtig, weil sie über konkurrierende öffentliche Stellungnahmen hinausging. Cogent und Level 3 erklärten, eine geänderte settlementfreie Peering-Vereinbarung erreicht zu haben. Die Mitteilung beschrieb Pflichten zu Verkehrsmerkmalen und -volumen, Zahlungen bei Nichterfüllung und ein Verfahren, das die Kundenkonnektivität schützen sollte, falls die Beziehung endete oder Verstöße ungelöst blieben.

Diese Elemente adressieren mehrere unterschiedliche Fehlerdrücke. Messbare Verkehrspflichten können die kommerziellen Kriterien zwischen den Parteien weniger mehrdeutig machen. Bedingte Zahlungen können eine Alternative zur sofortigen Trennung bieten, wenn der Betriebsdienst trotz eines kommerziellen Ungleichgewichts fortbesteht. Ein definiertes Verfahren für Ablauf oder unbehobene Verstöße kann Zeit schaffen, Kunden zu benachrichtigen und alternative Pfade einzurichten.

Die öffentliche Beschreibung zeigt nicht genau, wie diese Mechanismen funktionierten. Sie offenbart keine Schwellenwerte, Formeln, Fristen, Eskalationsverantwortliche oder die zum Nachweis der Einhaltung erforderlichen Belege. Sie beweist auch nicht, dass bedingte Zahlungen in jeder Situation verfügbar waren. Jede stärkere Beschreibung würde private Bedingungen rekonstruieren, die nie veröffentlicht wurden.

Die Kundenschutzbestimmung ist dennoch bedeutsam. Ihre Aufnahme zeigt, dass die Parteien Konnektivitätsauswirkungen als etwas behandelten, das eine Interconnection-Vereinbarung verfahrenstechnisch adressieren konnte. Das ist etwas anderes als die Aussage, die Vereinbarung garantiere ununterbrochene globale Erreichbarkeit. Ein Verfahren kann Risiken verringern und dennoch unter unvorhergesehenen Bedingungen, unzureichender Kapazität oder unvollständiger Umsetzung scheitern.

Wiederherstellung erfordert außerdem mehr als die Unterzeichnung von Bedingungen oder das Versetzen einer BGP-Session in einen etablierten Zustand. Routen müssen ausgetauscht, akzeptiert und ausgewählt werden. Die Weiterleitung muss in beide Richtungen funktionieren. Alternative Pfade, die während der Unterbrechung aktiv wurden, müssen möglicherweise zurückkonvergieren, ohne neue Instabilität zu verursachen. Kundenendpunkte müssen von relevanten Netzen aus erreichbar werden.

Die öffentliche Ankündigung belegt die wiederhergestellte Vereinbarung, liefert aber keinen vollständigen kundenbezogenen Wiederherstellungsnachweis. Eine begrenzte Darstellung sollte daher sagen, dass die Unternehmen die direkte Zusammenschaltung zu überarbeiteten Bedingungen wiederherstellten, nicht dass jede betroffene Anwendung gleichzeitig genesen oder alle Folgen zu einem einzigen universellen Zeitpunkt geendet seien.

Spätere Leitlinien als Vergleich, nicht als rückwirkendes Recht

RFC 4271 formalisiert den BGP-4-Routenaustausch- und Entscheidungsrahmen. Er wurde nach dem Streit vom Oktober 2005 veröffentlicht, obwohl er die Protokollfamilie dokumentiert, die bereits im Internet betrieben wurde. Er hilft zu erklären, wie Routen angekündigt, zurückgenommen und ausgewählt werden. Er erlegt zwei autonomen Systemen keine kommerzielle Pflicht auf, settlementfreies Peering aufrechtzuerhalten.

RFC 7454, viel später veröffentlicht, sammelt betriebliche Sicherheitspraktiken für BGP-Sessions. Er behandelt Filterung, Session-Schutz, Präfixgrenzen und Richtlinienkontrollen. Diese Praktiken sind nützlich, um zu bewerten, wie ein Betreiber Interconnection-Verhalten vorhersehbarer und beobachtbarer machen kann. Sie entscheiden nicht, ob eines der Unternehmen die im Jahr 2005 vernünftigerweise anwendbaren Standards erfüllte, und sie garantieren keine Kontinuität nach einer absichtlichen Session-Abschaltung.

RFC 8212 etabliert explizite Import- und Exportrichtlinien als sichereren Standard für externes BGP. Dieser Ansatz verringert versehentliche Weitergabe durch fehlende Richtlinien. Das Cogent-Level-3-Ereignis war kein Beispiel dafür, dass Routen versehentlich exportiert wurden, weil eine leere Konfiguration permissives Verhalten als Standard hatte. Explizite Richtlinien könnten Absichten dokumentieren, erlaubten aber weiterhin eine bewusste Entscheidung, keine Routen auszutauschen.

RFC 7908 klassifiziert Routenlecks. Seine Taxonomie hilft, unbeabsichtigte Weitergabe von legitimen Kunden-, Peer- und Transitbeziehungen zu unterscheiden. Das Ereignis von 2005 gehört außerhalb des zentralen Fehlermodus dieser Taxonomie, weil die Beweise ein bewusstes Depeering betreffen. Die sorgfältige Anwendung der Terminologie verhindert, dass ein fehlender Pfad fälschlich als übermäßiger oder unberechtigter Pfad bezeichnet wird.

RFC 9234 führte später BGP Roles und Mechanismen zur Darstellung der Beziehungsabsicht zwischen benachbarten autonomen Systemen ein. Eine bessere Darstellung der Rollen kann helfen, inkompatible Konfigurationen zu erkennen und Routenweitergabe einzuschränken. Sie kann nicht jede private kommerzielle Bedingung kodieren und zwingt zwei Netze nicht, nach dem Ende einer Beziehung verbunden zu bleiben.

RFC 1997 ist historisch anders, weil BGP-Communities bereits vor dem Streit standardisiert waren. Communities konnten Netzen helfen, Präferenzen zur Routenbehandlung zu signalisieren. Ihre Verfügbarkeit beweist nicht, wie AS174 oder AS3356 sie im Oktober 2005 verwendeten. Sie macht einen an einem Kollektor beobachteten Community-Wert auch nicht zu einer vollständigen Aussage über die Vertragsabsicht.

Die MANRS-Leitlinien artikulierten später Betreibermaßnahmen zu Filterung, Koordination, globaler Validierung und Anti-Spoofing. Die spätere Interdomain-Routing-Leitlinie des NIST betont ebenfalls resiliente Konfiguration, Überwachung und Vorfallreaktion. Diese Materialien bieten nützliche zeitgenössische Vergleichspunkte: Betreiber können Kontaktinformationen pflegen, Routenänderungen beobachten, Richtlinien validieren und Reaktionsverfahren vorbereiten.

Keines davon ist rückwirkendes Recht. Keines liefert den fehlenden Vertrag von 2005, Verkehrsmessungen oder interne Eskalationsaufzeichnungen. Keines beweist Fahrlässigkeit allein deshalb, weil das historische Verhalten eines Betreibers von einer späteren Empfehlung abweicht. Ihr richtiger Gebrauch ist prospektiv: Sie helfen, die Episode in Kontrollen zu übersetzen, die heutige Netze messen können.

Moderne RPKI-basierte Origin-Validierung verdient dieselbe Vorsicht. Sie kann einem Netz helfen, eine ungültige Ursprungsankündigung abzulehnen. Sie legt nicht fest, ob ein Peer eine gültige Route tragen sollte, ob Kapazität existiert oder ob eine kommerzielle Beziehung fortbestehen muss. Eine Route kann kryptografisch mit einem autorisierten Ursprung übereinstimmen und dennoch unerreichbar sein, weil kein akzeptabler Pfad die relevante Netzgrenze überquert.

Die übertragbarste spätere Lehre ist daher nicht, dass ein Sicherheitsmechanismus den Streit gelöst hätte. Sie lautet, dass Beziehungsabsicht, Routenrichtlinie, Überwachung, Koordination und Kontinuitätsplanung verbunden werden müssen. Ein Netz muss wissen, was es austauschen will, was es tatsächlich austauscht, welche Kunden von diesem Zustand abhängen und wie es einen kontrollierten Ausstieg verifiziert.

Ein messbarer Standard für Trennung und Wiederherstellung

Ein nützlicher Rechenschaftsstandard muss gegenüber dem kommerziellen Ergebnis neutral bleiben. Er sollte kein unbegrenztes Peering verlangen, Abrechnungsbedingungen diktieren oder annehmen, dass ein Teilnehmer Anspruch auf kostenlosen Transit hat. Er sollte Betreiber verpflichten, die Kontinuitätsfolgen einer geplanten Trennung beobachtbar und begrenzt zu machen.

Das erste Maß ist die Abhängigkeitsabdeckung. Vor der Beendigung einer folgenreichen Zusammenschaltung sollte jeder Anbieter die Kundenpräfixe, Zielgruppen oder Dienstklassen identifizieren, für die die direkte Beziehung der einzige verifizierte Pfad ist. Das messbare Ergebnis ist nicht der Anspruch, das gesamte Internet zu kennen. Es ist der Anteil des im Umfang befindlichen Kundeninventars des Betreibers, für den die Abhängigkeit bewertet und mit Zeitstempel versehen wurde.

Ein Abhängigkeitsdatensatz sollte direkte Beobachtung von Schlussfolgerung unterscheiden. Eine über die Zusammenschaltung gesehene Route ist nicht notwendigerweise von ihr abhängig, wenn ein anderer akzeptabler Pfad existiert. Ein in einer Topologie gezeigter alternativer Pfad ist nicht verifiziert, wenn der Betreiber nie getestet hat, ob er exportiert, akzeptiert und nutzbar ist. Der Datensatz sollte daher die Beobachtungspunkte, Routenrichtlinien und Weiterleitungstests angeben, die jede Klassifizierung stützen.

Das zweite Maß ist die Verifikation alternativer Pfade. Für jede Abhängigkeitsgruppe sollte der Anbieter festhalten, ob mindestens eine getestete alternative Route existiert, ob Hin- und Rückweg funktionieren und ob der Pfad ausreichende Betriebskapazität für den beabsichtigten Dienst hat. Die relevante Metrik ist die verifizierte Abdeckung: getestete erreichbare Einheiten geteilt durch alle Einheiten, die voraussichtlich eine Alternative benötigen.

Dieses Verhältnis muss Umfangsinformationen enthalten. Ein hohes Ergebnis, das nur von den Routern des Betreibers selbst gemessen wurde, belegt keine externe Erreichbarkeit. Tests sollten unabhängige Netze mit wesentlich unterschiedlichen Pfaden einbeziehen. Der Standard muss keine universelle Zahl von Beobachtungspunkten vorschreiben; er sollte vom Anbieter verlangen zu erklären, warum die gewählte Menge die gefährdeten Kunden und Regionen repräsentiert.

Das dritte Maß ist die Richtlinienbereitschaft. Der Betreiber sollte die vor, während und nach der Trennung beabsichtigte Import- und Exportrichtlinie zusammen mit dem verantwortlichen Eigentümer und dem Aktivierungszeitpunkt aufbewahren. Diese Beweise ermöglichen es, einen geplanten Rückzug von einem versehentlichen Leck, Konfigurationsfehler oder unabhängigen Session-Ausfall zu unterscheiden.

Zur Richtlinienbereitschaft gehört auch, soweit machbar, eine Simulation oder ein kontrollierter Test. Ein Betreiber kann die Präferenz für die direkte Route verringern oder ausgewählte Kundenpräfixe über Alternativen testen, bevor die Beziehung endet. Solche Tests sind möglicherweise nicht in jeder Architektur möglich und können selbst Risiken erzeugen. Die rechenschaftspflichtige Anforderung ist zu dokumentieren, ob sie durchgeführt wurden, was sie abdeckten und warum eine ungetestete Abhängigkeit akzeptiert wurde.

Das vierte Maß ist die Kapazitätsbereitschaft. Ein alternativer BGP-Pfad ist keine Kontinuitätskontrolle, wenn er unter gewöhnlichem umgeleitetem Verkehr zusammenbricht. Betreiber sollten die getestete Kapazität relevanter Alternativen, die einbezogenen Verkehrsklassen und den Testzeitpunkt festhalten. Dies erfordert nicht die Veröffentlichung vertraulicher Volumina. Es erfordert interne Beweise, die ausreichen, um zu belegen, dass das Routing um die Zusammenschaltung herum mehr als eine theoretische Möglichkeit war.

Das fünfte Maß ist Benachrichtigung und Eskalation. Ein Trennungsplan sollte den Entscheidungseigentümer, den Netzbetriebseigentümer, den Eigentümer der Kundenkommunikation und den Kontakt der Gegenpartei benennen. Er sollte festhalten, wann jeder benachrichtigt wurde und wann Kunden in identifizierten Abhängigkeitsgruppen handlungsrelevante Informationen erhielten.

Handlungsrelevante Benachrichtigung muss das betriebliche Risiko erklären, statt nur einen kommerziellen Streit zu beschreiben. Ein Kunde muss wissen, welche Dienste Erreichbarkeit verlieren können, welche alternative Konnektivität verfügbar ist, welche Tests er durchführen sollte und wo er einen Fehler melden kann. Die Metrik ist Abdeckung und verstrichene Zeit: wie viele identifizierte abhängige Kunden eine Benachrichtigung erhielten und wie lange vor oder nach der Routing-Änderung diese Benachrichtigung erfolgte.

Der Standard sollte eine Notfallausnahme zulassen. Sicherheitsvorfälle, unkontrollierte Ausfälle oder unmittelbare Vertragsrisiken können eine Vorabbenachrichtigung unmöglich machen. Eine Ausnahme sollte Beweise nicht auslöschen. Sie sollte den Grund für das sofortige Handeln, die genehmigende Person, die erwogenen Schutzmaßnahmen und den frühesten Zeitpunkt festhalten, zu dem Kunden und Gegenpartei informiert wurden.

Das sechste Maß ist die Ereignisbeobachtbarkeit. Bei der Trennung sollten beide Anbieter Session-Zustand, Routenzahlen, relevante Ankündigungen und Rücknahmen, Änderungen akzeptierter Pfade und Ergebnisse von Weiterleitungstests sichern. Ein einzelner Eintrag „Session down“ ist unzureichend, weil die Kundenwirkung von den Routen und Pfaden abhängt, die mit ihr verschwinden.

Beobachtbarkeit sollte eine Erreichbarkeitsmatrix erzeugen statt eines globalen Prozentsatzes. Zeilen können getestete Quellnetze oder Kundengruppen darstellen; Spalten können relevante Zielpräfixe oder Dienste darstellen. Jede Zelle kann erreichbar, unerreichbar, beeinträchtigt oder ungeprüft mit Zeitstempel und Beobachtungspunkt festhalten. Dies legt Unsicherheit offen, statt ungemessenen Raum in angenommenen Erfolg umzuwandeln.

Das siebte Maß ist die Erkennungsleistung. Ein Betreiber sollte wissen, wie lange die Überwachung nach der Routing-Änderung benötigte, um den Erreichbarkeitsverlust zu erkennen. Die Uhr sollte nicht anhalten, wenn die BGP-Session den Zustand ändert. Sie sollte anhalten, wenn das System die kundenseitige Folge mit genügend Spezifität für Maßnahmen identifiziert.

Erkennung sollte Signale der Steuerungsebene und der Datenebene trennen. Eine Routenrücknahme kann Schäden vorhersagen, während aktive Sonden feststellen, ob Pakete weiterhin über einen alternativen Pfad fließen. Anwendungsprüfungen können zeigen, ob ein Dienst nach der Routing-Konvergenz funktioniert. Diese Maße getrennt zu halten, verhindert, dass ein Routentabelleneintrag mit abgeschlossenem Kundendienst verwechselt wird.

Das achte Maß ist die Vorfallkommunikation. Während der Unterbrechung sollten Statusmeldungen verifizierte Fakten von Hypothesen und zugeschriebenen kommerziellen Positionen unterscheiden. Ein Betreiber sollte berichten, was sich geändert hat, welchen Umfang er gemessen hat, was unbekannt bleibt und wann er ein weiteres Update liefert. Aussagen wie „das Internet bleibt verfügbar“ sind unzureichend, wenn sie bekannte Trennungen zwischen Kundengruppen verbergen.

Das neunte Maß ist die begrenzte Wiederherstellung. Die Wiederherstellung beginnt, wenn die Parteien Korrekturmaßnahmen ergreifen, ist aber nicht allein deshalb abgeschlossen, weil eine Session in einen etablierten Zustand zurückkehrt. Ein Anbieter sollte verifizieren, dass erwartete Präfixe ausgetauscht werden, Richtlinien sie akzeptieren, ausgewählte Pfade stabil sind und die Weiterleitung von repräsentativen externen Netzen aus funktioniert.

Ein Wiederherstellungsdatensatz sollte getrennte Zeitstempel für Session-Aufbau, Routenakzeptanz, erste erfolgreiche Datenebenentests, Erholung jeder Kundengruppe und Abschluss offener Beschwerden bewahren. Diese Zeitstempel verhindern, dass ein technisch bequemes Ereignis – etwa das erste BGP-Keepalive – als universelles Ende des Kundenschadens dargestellt wird.

Das zehnte Maß ist der Abgleich des Routenzustands. Während der Unterbrechung genutzte Pfade können nach Rückkehr des direkten Peerings bevorzugt bleiben, oder der Verkehr kann oszillieren, während Richtlinien neu konvergieren. Betreiber sollten den beabsichtigten Zustand nach der Wiederherstellung mit beobachteten Routen vergleichen und wesentliche Unterschiede untersuchen. Das Ziel ist nicht, jede Route auf ihren früheren Pfad zu zwingen; es ist sicherzustellen, dass der resultierende Zustand verstanden und nutzbar ist.

Das elfte Maß ist die ungeprüfte Exposition. Jeder Trennungsdatensatz sollte angeben, wie viele Präfixe, Kundengruppen oder externe Regionen im Umfang nicht getestet wurden. Unbekannte Abdeckung ist eine Rechenschaftstatsache, kein leeres Feld. Sie zu berichten, verhindert, dass eine begrenzte erfolgreiche Stichprobe zu einer unbelegten Behauptung universeller Erholung wird.

Das zwölfte Maß ist die Beweiserhaltung. Routenbeobachtungen, Konfigurationsänderungen, Benachrichtigungen, Vorfallnachrichten und Wiederherstellungstests sollten entlang einer konsistenten Zeitachse aufbewahrt werden. Öffentliche Kollektoren bleiben wertvolle unabhängige Referenzen, aber die eigenen Beweise der Anbieter sollten vollständiger sein, weil sie lokale Präferenzen, abgelehnte Routen, interne Topologie und Kundenzuordnung sehen können.

Diese Maße lassen sich als Kontinuitätskette zusammenfassen:

Ermitteln, wer von der Zusammenschaltung abhängt.
Verifizieren, welche alternativen Pfade tatsächlich funktionieren.
Richtlinien, Kapazität und Entscheidungseigentümer festhalten.
Gegenpartei und betroffene Kunden nach einem erklärten Verfahren benachrichtigen.
Sowohl Routenzustand als auch Paketzustellung während der Änderung beobachten.
Schäden nach begrenzten Gruppen und unabhängigen Beobachtungspunkten messen.
Sessions, akzeptierte Routen und Weiterleitung wiederherstellen.
Den resultierenden Zustand abgleichen und ungelöste Unsicherheit bewahren.

Keine öffentlichen Beweise zeigen, dass diese vollständige Kette 2005 bei einem der Anbieter existierte. Der Standard sollte nicht als historische Pflicht dargestellt werden, die die Unternehmen notwendigerweise verletzten. Er ist ein Weg, die nachgewiesenen Fehlerdrücke des Ereignisses in messbare aktuelle Praxis zu übersetzen.

Er vermeidet außerdem eine unmögliche Garantie. Kein Betreiber kann die Erreichbarkeit von jedem Netz zu jedem Endpunkt zu jedem Zeitpunkt nachweisen. Was ein Betreiber nachweisen kann, ist der Umfang, den er bewertet hat, die Alternativen, die er getestet hat, die Beobachtungen, die er aufbewahrt hat, die Kunden, die er gewarnt hat, und die Bedingungen, unter denen er die Wiederherstellung erklärt hat.

Was die öffentlichen Aufzeichnungen weiterhin nicht belegen können

Der vollständige Peering-Vertrag bleibt unzugänglich. Die öffentlichen Aussagen offenbaren nicht alle Verkehrsverhältnisse, Messfenster, Portkapazitäten, Preise, Heilungsfristen oder Beendigungsrechte. Ohne diese Tatsachen kann eine externe Darstellung nicht bestimmen, ob eines der Unternehmen seine privaten Pflichten erfüllte oder verletzte.

Der vollständige Routing-Zustand ist ebenfalls unbekannt. RouteViews, RIPE RIS und Merit liefern wertvolle Beobachtungen, aber sie legen nicht jeden privaten Peer, jede lokale Präferenz, jede abgelehnte Route oder jede Weiterleitungsentscheidung offen. Die erhaltenen öffentlichen Daten können nicht jedes betroffene Präfix oder jeden betroffenen Kunden identifizieren.

Kundenschäden lassen sich aus den eingefrorenen Aufzeichnungen nicht präzise quantifizieren. Zeitgenössische Berichte stützen den Schluss, dass einige Unternehmen und Nutzer Erreichbarkeitsausfälle erlebten. Sie belegen weder den gesamten entgangenen Umsatz, die Dauer für jeden Kunden, anwendungsbezogene Folgen über alle Dienste hinweg noch gleiche Auswirkungen auf beide Netze.

Die interne Entscheidungsverantwortung ist nicht öffentlich. Level 3 kontrollierte seine Trennungsmaßnahme, aber das verfügbare Material identifiziert nicht jeden Führungs- oder Betriebsgenehmiger, die Eskalationsabfolge oder die vor der Änderung durchgeführten internen Tests. Cogenents interner Reaktionsprozess und seine Resilienzbewertung sind ähnlich unvollständig.

Die überarbeitete Vereinbarung ist ein Beleg für das Abhilfedesign, kein vollständiger Umsetzungsnachweis. Ihre öffentliche Beschreibung weist auf Verkehrspflichten, bedingte Zahlungen und ein Kundenschutzverfahren hin. Sie zeigt nicht, wie jede Kontrolle später getestet wurde oder ob sie jedes künftige Fehlerszenario adressiert hätte.

Die rechtliche Zuordnung bleibt hier ungeklärt. Spätere FCC-Erörterungen liefern regulatorischen Kontext, aber die zitierten Unterlagen begründen keine Feststellung von Rechtswidrigkeit, Vertragsbruch, Fahrlässigkeit oder bösem Glauben in diesem Ereignis. Betriebliche Kontrolle und messbare Rechenschaftspflicht können analysiert werden, ohne sie in rechtliche Schlussfolgerungen umzuwandeln.

Kontinuität wird durch funktionierende Routen bewiesen

Das Cogent-Level-3-Depeering von 2005 bleibt lehrreich, weil es die Annahme beseitigte, der Status als großes Netz garantiere universelle Erreichbarkeit. AS174 und AS3356 blieben jeweils identifizierbare Netze mit registrierten Ressourcen, Kunden und Verbindungen anderswo. Dennoch hörten einige Pfade über ihre frühere Beziehung auf zu funktionieren, und einige Kunden konnten Berichten zufolge nicht um die Trennung herum routen.

Die zentrale Tatsache des Ereignisses war nicht nur, dass zwei Unternehmen uneins waren. Es war, dass eine bilaterale kommerzielle Entscheidung die Verfügbarkeit von Interdomain-Routen veränderte. BGP-Rücknahmen, alternative Weitergabe, Import- und Exportrichtlinien, Multihoming und Wiederherstellung bestimmten das praktische Ergebnis.

Die öffentlichen Beweise stützen eine vorsichtige Schlussfolgerung. Level 3 beendete am 5. Oktober bewusst das direkte Peering. Cogent verlangte öffentlich eine Wiederherstellung vor weiteren Verhandlungen. Level 3 erklärte, die Testvereinbarung erfülle ihre Bedingungen nicht mehr. Ein Teil der Kundenerreichbarkeit wurde gestört, obwohl der vollständige Umfang unbekannt ist. Am 28. Oktober kündigten die Unternehmen wiederhergestelltes settlementfreies Peering zu überarbeiteten Bedingungen an, die ein Verfahren zum Schutz von Kunden bei einem künftigen Ablauf oder ungelösten Verstoß umfassten.

Nichts in dieser Schlussfolgerung erfordert eine Entscheidung über die privaten vertraglichen Verdienste. Sie erfordert auch kein obligatorisches Peering. Sie erfordert die Anerkennung, dass autonome Kontrolle eine Beweispflicht mit sich bringt, wenn ihre Ausübung abhängige Kunden isolieren kann.

Ein Register kann festhalten, wer einen Adressblock hält. Ein Vertrag kann kommerzielle Pflichten festhalten. Eine Statusmeldung kann die Position einer Partei festhalten. Vollständige Internet-Erreichbarkeit wird anderswo bewiesen: in Routen, die tatsächlich angekündigt, akzeptiert, ausgewählt und weitergeleitet werden, mit beobachtbaren Alternativen, wenn eine direkte Beziehung endet.

Das ist der bleibende Rechenschaftstest. Vor der Beendigung einer folgenreichen Zusammenschaltung: wissen, welche Kunden von ihr abhängen. Während der Änderung: messen, was verschwindet, statt anzunehmen, der Rest des Internets werde darum herum routen. Nach der Wiederherstellung: Kundenpfade verifizieren, statt bei der Vertragsunterschrift oder dem BGP-Session-Zustand stehen zu bleiben. Der Datensatz ist nur nützlich, wenn er einem laufenden Pfad entspricht.

Das Depeering zwischen Cogent und Level 3 im Jahr 2005 machte vollständige Internet-Erreichbarkeit zu einem Test der Transit-Verantwortung