Cloudflare, der Route-Leak vom Juni 2019 und Verantwortung jenseits der Netzwerkgrenze

Zusammenfassung

• Am 24. Juni 2019 wurden optimierte, spezifischere Routen, die im Netzwerk von DQE Communications erzeugt wurden, über den Kunden AS396531 weitergeleitet und von Verizons AS701 akzeptiert. Verizon verbreitete dann Pfade, die Tausende von Netzwerken abdeckten. Da Router ein spezifischeres Zielpräfix bevorzugen, folgte ein erheblicher Teil des Datenverkehrs den durchgesickerten Pfaden auf Verbindungen, die nicht für die Aufnahme dieses Verkehrs ausgelegt waren; Cloudflare meldete, dass es auf dem Höhepunkt des Vorfalls etwa 15 % seines weltweiten Datenverkehrs verloren hat.
• Der öffentliche Routenverlauf unterstützt eine Kette von Kontrollversagen, nicht eine einzelne Ursache. Der Routerzeuger hielt seine Optimierungsrouten nicht lokal, ein mehrfach angebundener Kunde exportierte vom Provider gelernte Routen zu einem anderen Provider, und ein großes Transitnetzwerk akzeptierte und verbreitete Routen, die nicht der erwarteten Routing-Autorität des Kunden entsprachen. Cloudflare konnte die Routen erkennen, kommunizieren und zurückziehen helfen, aber es konnte nicht einseitig die Importrichtlinie eines anderen Netzwerks ändern.
• RPKI Route Origin Validation war für den Cloudflare-Teil dieses Vorfalls ungewöhnlich gut geeignet, da Cloudflares Route Origin Authorizations seine Aggregatpräfixe nur bis zu einer festgelegten maximalen Länge zuließen. Die durchgesickerten spezifischeren Routen überschritten diese Länge und waren daher ungültig. Das macht RPKI nicht zu einer vollständigen Lösung für Route-Leaks: Gültige Ursprungspfade können dennoch kommerzielle Beziehungen verletzen, weshalb Kundenfilterung, Präfixlimits, BGP Roles, Pfadkontrollen, Überwachung und erreichbare Betriebskontakte weiterhin notwendig sind.
• Verantwortlichkeit folgt der Kontrollfähigkeit. Betreiber, die außergewöhnliche Routen erzeugen oder exportieren, müssen diese eindämmen und testen; Provider müssen überprüfen, was Kunden anzukündigen berechtigt sind; Cloud-Plattformen müssen Routing-Autorität veröffentlichen, externe Pfade beobachten, schnell koordinieren und Kundenauswirkungen offenlegen; Kunden müssen für Abhängigkeitsausfälle planen; und Vorstände und Regulierungsbehörden sollten gemessene Routensicherheitsgarantien fordern, keine allgemeine Aussage, dass die besten Branchenpraktiken befolgt werden.

Ein Routing-Ausfall, kein Versagen von Cloudflares Servern

Am 24. Juni 2019 um 10:34:25 UTC begannen öffentliche BGP-Kollektoren, abnormale, spezifischere Routen für Cloudflare-Adressraum aufzuzeichnen. Die letzte der untersuchten Cloudflare-Routen verschwand um 12:38:54 UTC. Cloudflaresarchivierte Routenanalyserekonstruiert dieses Intervall aus RIPE NCC-Daten und zeigt einen bemerkenswert konsistenten Pfad: Cloudflares AS13335, einer seiner Transit-Provider, DQE Communications' AS33154, Allegheny Technologies' AS396531 und Verizons AS701. Andere Netzwerke lernten die Route dann über Verizon.

Der Pfad ist wichtig, da der Ausfall nicht mit einem ausgefallenen Cloudflare-Rechenzentrum oder einer Anwendungsbereitstellung begann. Cloudflares Maschinen kündigten weiterhin ihre gewöhnlichen Aggregatrouten an. Das globale Routingsystem lernte einfach konkurrierende Routen für kleinere Teile desselben Adressraums. Diese kleineren Teile gewannen die Weiterleitungsentscheidung in vielen Netzwerken und leiteten Pakete über einen unbeabsichtigten Pfad. Überlastung und Paketverlust folgten, bevor die Anfragen Cloudflares Edge erreichen konnten.

Cloudflares zeitgenössischeVorfallerklärungberichtete, dass auf dem Höhepunkt etwa 15 % seines weltweiten Datenverkehrs verloren ging. Das ist eine unternehmenseigene Messung, kein unabhängig geprüfter universeller Ausfallprozentsatz. Es beschreibt Cloudflare-Datenverkehr, nicht 15 % des gesamten Internets. Unabhängige Beobachtungen stützen jedoch den allgemeinen Mechanismus und die dienstübergreifenden Auswirkungen. ThousandEyes berichtete in seinerNetzwerkpfadanalyse, dass Benutzer etwa zwei Stunden lang Schwierigkeiten hatten, Cloudflare-frontierte Dienste und einige AWS-Dienste zu erreichen, während CatchpointsVorfallüberprüfungLeistungsprobleme bei namhaften Online-Diensten um 10:30 UTC verzeichnete.

Die Unterscheidung zwischen Routenverfügbarkeit und Serververfügbarkeit ist für die Verantwortlichkeit wichtig. Eine Plattform kann in vielen Ländern gesunde Server betreiben und dennoch unerreichbar sein, wenn die Routing-Kontrollebene den Datenverkehr woanders hinleitet. Kunden erleben ein einziges Ergebnis: Zeitüberschreitungen, Fehler und nicht verfügbare Anwendungen. Die technische Ursache bestimmt jedoch, welche Kontrollen den Verlust hätten verhindern können und welche Partei sie hätte bedienen können.

CloudflaresStatusaufzeichnung für das Ereignisbeschrieb zunächst Netzwerkleistungsprobleme, identifizierte dann einen möglichen Route-Leak und sagte später, dass das verantwortliche Netzwerk das Problem behoben habe. Öffentliche Kopien der Statusaktualisierungen setzen die Untersuchungsmitteilung auf 11:02 UTC, die Identifizierung auf 11:36 UTC und die Überwachung nach der Korrektur auf 12:42 UTC. Das BGP-Archiv zeigt abnormale Routen vor der ersten Statusmitteilung. Dieser Unterschied ist kein Beweis dafür, dass Cloudflare ein bekanntes Ereignis 28 Minuten lang ignoriert hat. Es ist eine nützliche Frage zur Verantwortlichkeit: Wann haben automatisierte Systeme abnormalen Datenverkehr erkannt, wann haben Ingenieure externes Routing als Ursache identifiziert, und wann hatte das Unternehmen genug Vertrauen, um Kunden zu benachrichtigen?

Es gibt keine öffentlichen Beweise für böswillige Absicht, Verkehrsüberwachung oder Kompromittierung von Cloudflare-Systemen bei diesem Vorfall. Ein Route-Leak kann eine Abfangmöglichkeit schaffen, aber der beobachtete Schaden für den Dienst war hier Überlastung und Verlust entlang eines unbeabsichtigten Pfades. Der Artikel behandelt den Vorfall daher als Verfügbarkeits- und Routing-Integritätsversagen. Er macht aus einer möglichen Sicherheitseigenschaft von Route-Leaks keine Behauptung, dass Verkehr gelesen wurde.

Wie eine lokale Optimierung zu einer globalen Route wurde

Das Internet ist eine Vereinbarung zwischen autonomen Systemen und kein zentral gesteuertes Netzwerk. Jedes autonome System verwendet das Border Gateway Protocol (BGP), um benachbarten Systemen mitzuteilen, welche IP-Präfixe es erreichen kann und über welchen AS-Pfad. Das Kernprotokoll inRFC 4271gibt den Betreibern erhebliche politische Freiheit. Diese Flexibilität unterstützt kommerzielles Peering, bezahlten Transit, Multihoming, Traffic Engineering und lokale Präferenzen. Sie bedeutet auch, dass eine von einem Nachbarn empfangene Route nicht mit einem universellen Beweis versehen ist, dass jeder AS im Pfad beabsichtigt hat, dass die Ankündigung so weit reist.

Vor dem Vorfall nutzte DQE ein BGP-Optimierungsprodukt von Noction. Ein solches Produkt kann die Pfadleistung messen und spezifischere Routen einfügen, um zu beeinflussen, welche Verbindung ausgewählten Datenverkehr trägt. In dem von Cloudflare veröffentlichten Beispiel wurde die normale104.20.0.0/20-Ankündigung in104.20.0.0/21und104.20.8.0/21aufgeteilt. Die beiden /21s decken denselben Adressbereich ab wie die /20, aber jedes benennt einen kleineren Zielblock.

Innerhalb eines kontrollierten Netzwerks können spezifischere Routen ein legitimes Instrument des Traffic Engineerings sein. Die Gefahr liegt im Umfang. Die Routen sollten die internen Entscheidungen von DQE beeinflussen. DQE kündigte sie an AS396531 an. AS396531 war sowohl mit DQE als auch mit Verizon verbunden und exportierte die gelernten Routen zu Verizon. Verizon akzeptierte sie von seinem Kunden und verbreitete sie weiter. Eine lokale Anweisung war zu einer globalen Behauptung geworden.

Noctions eigeneVorfallreaktion vom 26. Juniräumte ein, dass seine Plattform die spezifischeren Routen erzeugte, und beschrieb drei verstärkende Bedingungen: Generierung innerhalb des Netzwerks seines Kunden, Durchsickern über eine nachgelagerte ASN zu einem großen Provider und unzureichende Filterung in allen drei autonomen Systemen. Noction argumentierte, dass die Erstellung spezifischerer Routen eine gängige Praxis und kein inhärenter Defekt sei, und betonte die Provider-Filterung. Diese Reaktion ist relevant, weil sie die Rolle des Optimierers bestätigt, während sie eine einseitige Darstellung bestreitet. Es ist keine unabhängige Nachlese, und sie veröffentlicht nicht die genaue Konfiguration, den Änderungsdatensatz oder die Testergebnisse für DQEs Bereitstellung.

Qrator Labs'separate Routing-Analysebrachte den Beginn mit der Wiederherstellung der BGP-Sitzung zwischen AS396531 und Verizon kurz nach 10:35 UTC in Verbindung. Ihr Bericht besagt, dass AS396531 Filter verloren hatte und von DQE gelernte Routen exportierte. Dies liefert einen plausiblen Auslöser dafür, warum der Zustand zu diesem Zeitpunkt begann, aber die verfügbaren öffentlichen Aufzeichnungen enthalten keine Routerkonfigurationen oder Protokolle von AS396531, DQE oder Verizon. Die sichere Schlussfolgerung ist enger: Der beobachtbare Pfad beweist, dass Routen diese AS-Grenzen überschritten; Betreiberberichte identifizieren fehlende oder unzureichende Filter; die genaue interne Änderungssequenz bleibt nicht öffentlich.

Diese Unterscheidung verhindert drei häufige Fehler. Erstens sollte DQE nicht als Ursprung von Cloudflares Adressraum im BGP-Sinne beschrieben werden. Der beobachtete AS-Pfad endete immer noch bei Cloudflares AS13335. DQEs Optimierer erstellte und verbreitete einen spezifischeren Pfad mit dem legitimen Ursprung. Zweitens hat Verizon die Routen nicht erfunden, aber ihre Annahme und globale Verbreitung vergrößerte ihre Reichweite erheblich. Drittens hat Cloudflares Netzwerk AS396531 nicht als bevorzugten Pfad gewählt. Entfernte Netzwerke trafen Weiterleitungsentscheidungen basierend auf den empfangenen Ankündigungen.

Warum spezifischere Routen Distanz und Anycast besiegten

Für einen Laien könnte das Ereignis so klingen, als ob Router einen kürzeren AS-Pfad auswählten. Die entscheidende Präferenz trat früher auf. Die Internet-Weiterleitung verwendet Longest-Prefix-Matching: Eine Route, die den spezifischsten Zielblock abdeckt, wird gegenüber einer Route ausgewählt, die einen breiteren Block abdeckt.RFC 4632, die Spezifikation für Classless Inter-Domain Routing, beschreibt dieses Longest-Match-Verhalten und seine Beziehung zu Aggregat- und spezifischeren Routen.

Angenommen, ein Router weiß, dass Cloudflares104.20.0.0/20über einen normalen Provider erreichbar ist, und lernt auch104.20.0.0/21über Verizon, AS396531 und DQE. Ein Ziel innerhalb des ersten /21 stimmt mit beiden Ankündigungen überein. Das /21 ist spezifischer, also gewinnt es, selbst wenn sein AS-Pfad länger oder betrieblich absurd ist. Normale Pfadattribute entscheiden zwischen Routen zum selben Präfix; sie lassen ein gesundes /20 nicht gegen ein akzeptiertes /21 gewinnen.

Deshalb hat Cloudflares Anycast-Fußabdruck das Problem nicht automatisch umgangen. Anycast erlaubt es vielen Cloudflare-Standorten, dieselben Präfixe anzukündigen und BGP ein geeignetes Exemplar auswählen zu lassen. Es bietet geografische Verteilung und kann den Ausfall einzelner Standorte oder Verbindungen absorbieren. Aber die durchgesickerten /21s waren spezifischer als Cloudflares gewöhnliche /20-Ankündigungen. Das globale Routingsystem konnte das /21 bevorzugen, bevor es verglich, welcher Cloudflare-Anycast-Standort am nächsten war. Redundanz hinter der verlierenden Route stellte den Verkehr nicht wieder her.

Der unerwünschte Pfad konzentrierte auch die Last. AS396531 und seine Verbindungen waren nicht als globaler Transit für Cloudflare, Amazon, Linode und die vielen anderen betroffenen Netzwerke ausgelegt. Der durch die spezifischeren Ankündigungen angezogene Verkehr gelangte in einen Korridor ohne die Kapazität oder Richtlinie, ihn zu transportieren. Pakete wurden verzögert oder verworfen. Ein Route-Leak kann manchmal Verkehr auf einem ineffizienten Pfad zustellen; hier verwandelte der Maßstab den Pfad in einen Engpass.

DieRFC-7908-Taxonomie für Route-Leaksder Internet Engineering Task Force definiert einen Route-Leak als Verbreitung über den beabsichtigten Umfang einer Ankündigung hinaus. Das Ereignis vom Juni 2019 kombiniert Merkmale, die die Taxonomie zu Analysezwecken trennt. Es beinhaltete von Providern gelernte Routen, die von einem mehrfach angebundenen Netzwerk zu einem anderen Provider exportiert wurden, was dem klassischen Hairpin-Turn-Muster ähnelt, und intern nützliche spezifischere Routen, die nie für eine globale Verbreitung bestimmt waren. Die Bezeichnung ist weniger wichtig als die verletzte Invariante: Ein Kunde von Verizon schien Transit für Präfixe außerhalb seines legitimen Kundenkegels anzubieten, und Verizon akzeptierte diesen Anschein.

Die Chronologie und das sich erweiternde Verantwortlichkeitsfenster

Die Verantwortlichkeit ändert sich, wenn sich ein Vorfall von Prävention zu Erkennung und Wiederherstellung bewegt. Die folgende Zeitleiste verwendet öffentliche Routendaten und zugeschriebene Betreiberaussagen; sie füllt Lücken nicht mit angenommenen internen Aktionen.

Die folgenreichste Periode begann vor dem ersten Zeitstempel. Wenn ein Vorstand seine Überprüfung um 10:34 beginnt, wird er sich auf Alarmierung und Anrufe konzentrieren. Wenn er beginnt, als die Optimierer-Routen für die Produktion autorisiert wurden, kann er Design-Sicherheit, Routenumfang, Fail-Closed-Standardeinstellungen, Peer-Richtlinien, Änderungsüberprüfung und unabhängige Ausbreitungstests untersuchen. Die Vorfallreaktion verkürzte die Dauer. Präventive Kontrollen bestimmten, ob es überhaupt einen Vorfall gab, auf den reagiert werden musste.

Vier Filtergelegenheiten versagten in dieselbe Richtung

Die Route überquerte mehrere Grenzen, jede mit einer anderen Gelegenheit, sie zu stoppen. Die Behandlung dieser Gelegenheiten als Schichten verdeutlicht die Verantwortung, ohne vorzutäuschen, dass alle Parteien gleiche Kontrolle hatten.

Eindämmung durch Optimierer und Ursprungsnetzwerk.DQE kontrollierte die Umgebung, in der Noctions Produkt spezifischere Routen erzeugte. Routen, die nur für lokale Entscheidungen bestimmt waren, benötigten eine Exportschranke, die nicht davon abhing, dass jeder nachgelagerte Teil korrekt funktioniert. Optionen umfassten eine eng begrenzte Exportrichtlinie, einen dedizierten Routing-Kontext, von jedem Exit interpretierte explizite Communities, automatisierte Prüfungen durch externe Kollektoren und einen Kill-Switch, der an unerwartete Verbreitung gebunden ist. Noction sagt, es habe Bereitstellungstests durchgeführt und die Verwendung vonNO_EXPORTdiskutiert, argumentiert aber auch, dassNO_EXPORTnicht in jedem Multi-AS-Design geeignet ist. Die bekannte Community ist inRFC 1997definiert: Eine Route, die sie trägt, sollte nicht außerhalb einer Konföderationsgrenze angekündigt werden. Ob sie bei diesem Vorfall verwendet, beibehalten, entfernt oder nie angehängt wurde, ist öffentlich nicht geklärt.

Exportkontrolle durch mehrfach angebundene Kunden.AS396531 hätte die vollständigen oder optimierten Routen eines Providers nicht einem anderen Provider anbieten sollen, es sei denn, es betrieb absichtlich Transit. Ein Blatt- oder Unternehmensnetzwerk kann eine einfache Ausgangsregel anwenden: nur eigene autorisierte Präfixe und ausdrücklich genehmigte Kundenpräfixe ankündigen. Eine Default-Deny ist zuverlässiger, als zu versuchen, jede Route zu identifizieren, die nicht das Netzwerk verlassen darf.RFC 8212, veröffentlicht 2017, kodifizierte die standardmäßige externe BGP-Ablehnung, wenn keine explizite Import- oder Exportrichtlinie konfiguriert ist. Es kann nicht verhindern, dass ein Betreiber eine falsche erlaubende Richtlinie anwendet, aber es beseitigt eine Klasse von versehentlicher Verbreitung durch eine fehlende Richtlinie.

Kunden-Eingangskontrolle durch den Provider.Verizon hatte den wirksamsten Stoppunkt. Ein Transit-Provider weiß, welche Sitzung eine Kundensitzung ist, und sollte wissen, was dieser Kunde zu verursachen oder zu transitieren berechtigt ist. Cloudflares Tiefenanalyse ergab, dass die dem Kunden zugeordneten Routenregisterinformationen weder Cloudflares ASN noch die anderen durchgesickerten Netzwerke enthielten. Ein kundenspezifischer Präfix- und AS-Pfad-Filter hätte die Ankündigungen daher ablehnen können. DieBGP-Betriebs- und Sicherheitsleitlinien in RFC 7454, veröffentlicht 2015, empfehlen Richtlinien für an jeder Grenze empfangene und angekündigte Routen, Kundenpräfixkontrollen, AS-Pfad-Filterung und Maximalpräfixgrenzen.

Ablehnung durch nachgelagerte und Peer-Netzwerke.Netzwerke, die die Routen von Verizon erhielten, hatten ebenfalls die Chance, sie abzulehnen. Da Verizon ein großes Transitnetzwerk ist, schenkten viele Empfänger seinen Ankündigungen erhebliches Vertrauen. Einige Netzwerke, die Route Origin Validation verwenden, hätten die betroffenen Cloudflare-spezifischeren Routen als RPKI-ungültig abgelehnt. Andere könnten Route-Leak-Heuristiken oder Peer-Richtlinien verwenden. Doch jeden entfernten Netzwerk zu bitten, einen Fehler zu fangen, nachdem ein großer Provider ihn verbreitet hat, ist weniger effizient, als ihn auf der ursprünglichen Kundensitzung abzulehnen. Die der Richtlinienverletzung am nächsten gelegene Prävention begrenzt die Verbreitung, bevor die globale Konvergenz einen Konfigurationsfehler in einen verteilten Ausfall verwandelt.

Diese Schichten waren nicht unabhängig genug. DQEs Optimierung, AS396531s Export und Verizons Import beruhten alle auf einer korrekten Routenrichtlinienkonfiguration. Wenn jede Schicht manuell erlaubend oder aus unvollständigen Kundenaufzeichnungen aufgebaut ist, können drei Kontrollen gemeinsam versagen. Ein ausgereiftes Assurance-Programm testet daher das Ergebnis von außerhalb der administrativen Domäne. Es akzeptiert nicht die Überprüfung der Konfiguration allein als Beweis dafür, dass eine Route lokal geblieben ist.

RPKI hätte diese Routen blockieren können, ist aber nicht die ganze Antwort

Cloudflare hatte 2018 begonnen, Routen zu signieren und Validierung zu implementieren, wie in seinemRPKI-Bereitstellungsberichtbeschrieben. Eine Route Origin Authorization (ROA) legt fest, welches autonome System ein Präfix verursachen darf und optional die spezifischste Präfixlänge, die es ankündigen darf. Cloudflare sagt, dass seine relevanten Routen AS13335 mit einer maximalen Länge von /20 autorisierten. Die durchgesickerten /21s behielten AS13335 als Ursprung bei, überschritten jedoch die autorisierte maximale Länge. Sie waren daher gemäß der Route Origin Validation ungültig.

Die Logik ist inRFC 6811formalisiert. Eine empfangene Route ist gültig, wenn ein validierter ROA-Payload das Präfix abdeckt, die Ursprungs-ASN übereinstimmt und die Präfixlänge der Route das Maximum der ROA nicht überschreitet. Sie ist ungültig, wenn eine deckende Autorisierung existiert, aber keine alle erforderlichen Eigenschaften erfüllt. DieErklärung der Ursprungsvalidierungvon RIPE NCC trennt nützlich gültige, ungültige und unbekannte Zustände und betont, dass Netzwerkbetreiber immer noch entscheiden, welche Richtlinie sie auf diese Zustände anwenden.

Cloudflares Handlung, ROAs zu erstellen, war notwendig, aber nicht ausreichend. Eine ROA ist ein veröffentlichter Beweis, kein entferntes Durchsetzungskommando. Verizon oder ein anderes empfangendes Netzwerk musste validierte RPKI-Daten abrufen, die Validierung auf die Kundenroute anwenden und Ungültige ablehnen. Cloudflare konnte ungültige Routen ablehnen, die in sein eigenes Netzwerk gelangten, aber das hinderte Netzwerke Dritter nicht daran, Cloudflare-gebundenen Verkehr entlang einer anderswo ausgewählten Route zu senden.

Routing-Sicherheit hat eine reziproke Struktur: Ein Adressinhaber veröffentlicht eine Autorisierung, während andere Betreiber sie wirksam machen.

Für diesen Vorfall war RPKI eine besonders starke Präventionskontrolle, da der Optimierer die Präfixlänge änderte. Es wäre falsch, diese Erfolgsbedingung auf jeden Route-Leak zu verallgemeinern. Wenn AS396531 Cloudflares gewöhnliches /20 durchgesickert hätte, während AS13335 am Ende des Pfades erhalten bliebe, könnte die Ursprungsvalidierung die Route als gültig betrachten. Die Route würde dennoch die erwartete Provider-Kunden-Topologie verletzen. Die RPKI-Ursprungsvalidierung beantwortet, wer ein Präfix verursachen darf und in welcher Länge. Sie beweist nicht, dass jede Transitbeziehung im AS-Pfad autorisiert ist.

Diese Grenze ist keine Kritik an RPKI. Sie ist der Grund, es mit anderen Kontrollen einzusetzen. NISTsSP 800-189-Leitfadenkombiniert RPKI und BGP-Ursprungsvalidierung mit Präfixfilterung und breiteren Inter-Domain-Resilienzpraktiken. Es behandelt Route-Leaks, Hijacks, Verkehrsumleitungen, Denial of Service und Leistungsverschlechterung als verwandte Betriebsrisiken, die Schichten erfordern. Das Ereignis vom Juni 2019 ist eine ungewöhnlich konkrete Demonstration: Eine Schicht hätte die genauen schlechten Präfixe ablehnen können, während grundlegende Kundenfilterung den unglaubwürdigen Autoritätspfad auch ohne Kryptographie hätte ablehnen können.

Es gibt auch eine Governance-Lehre inmaxLength. Eine übermäßig erlaubende ROA kann nicht autorisierte spezifischere Routen gültig erscheinen lassen; eine übermäßig restriktive oder veraltete ROA kann legitime Routen ablehnen lassen. ROA-Abdeckung, maximale Länge, Ablauf, Schlüssel- und Repository-Gesundheit und geplante Routing-Änderungen benötigen Änderungskontrolle. Ein Dashboard, das zeigt, dass ROAs existieren, ist kein Beweis dafür, dass sie die Produktionsabsicht genau beschreiben.

Pfadrichtlinien-Kontrollen nach 2019

Die Standards und die Richtlinienlandschaft entwickelten sich nach dem Ausfall weiter. Spätere Kontrollen sollten nicht so beschrieben werden, als ob Betreiber im Juni 2019 eine fertige Version hätten einsetzen können, aber sie zeigen, wie die Branche versucht hat, Annahmen zu kodifizieren, die zuvor implizit waren.

RFC 9234, veröffentlicht 2022, führte BGP Roles und das Only-to-Customer (OTC)-Attribut ein. Benachbarte Netzwerke können deklarieren, ob eine Beziehung Provider, Kunde, Peer, Route-Server oder Route-Server-Client ist. Die Rollenvereinbarung und die OTC-Behandlung ermöglichen es Routern, einige Ankündigungen zu erkennen, die eine Beziehungsgrenze in einer unzulässigen Richtung überschreiten. In einer vereinfachten Version des Pfades von 2019 sollte eine Route, die von einem Provider gelernt und dann an einen anderen Provider gesendet wird, Beweise tragen, die mit einem reinen Kundenexport unvereinbar sind. BGP Roles wandeln einiges kommerzielles Topologiewissen von einer Betreiberkonvention in einen protokollsichtbaren Zustand um.

Peerlock bietet einen weiteren pfadorientierten Ansatz. Das Papier von 2020„Flexsealing BGP Against Route Leaks"untersuchte den von Betreibern eingesetzten Mechanismus, einschließlich seiner Fähigkeit, Pfade zu stoppen, in denen ein geschütztes großes Netzwerk erscheint, wo es nicht sollte. Peerlock existierte vor dem Papier und vor dem Ereignis vom Juni 2019, aber die Bereitstellung hing von bilateralem Wissen und Konfiguration ab. Es ist ein Beweis dafür, dass praktische Pfadfilter möglich waren, kein Beweis dafür, dass eine universelle Standardlösung verfügbar war.

Autonomous System Provider Authorization (ASPA) zielt darauf ab, einem AS zu erlauben, überprüfbare Provider-Beziehungen durch das RPKI-System zu veröffentlichen. Es ist vielversprechend, da viele Route-Leaks Pfadplausibilitätsfehler und keine Ursprungsfehler sind. Es erfordert auch eine sorgfältige Sprache: Die Standards und der Bereitstellungszustand von ASPA haben sich weiterentwickelt, und eine teilweise Abdeckung erzeugt unbekannte Pfade.

Es sollte als zusätzliches Validierungssignal behandelt werden, nicht als rückwirkender Beweis dafür, dass die Teilnehmer von 2019 einen damals obligatorischen kryptografischen Pfadstandard verletzt haben.

Auch die Erkennung ist ausgereifter geworden. Cloudflare beschrieb später seinenRadar-Route-Leak-Erkennungsdienst, der Routing-Beziehungen und beobachtete Pfade verwendet, um wahrscheinliche Leaks zu markieren. Überwachung reduziert die Zeit bis zum Wissen und die Zeit bis zur Koordination, aber sie verhindert nicht, dass ein Router die Route akzeptiert. Ein zweistündiger Vorfall kann immer noch globalen Schaden anrichten, wenn der Behebungspfad eine menschliche Telefonkette ist. Die Erkennung muss mit geübten Aktionen verbunden sein: betroffene Präfixe identifizieren, defensive Richtlinien anwenden, wo sicher, autorisierte Betreiber erreichen, Kundenstatus veröffentlichen, Rückzüge über unabhängige Kollektoren verifizieren und die Verkehrserholung beobachten.

Das nützliche Kontrollmodell ist daher kumulativ:

1. Veröffentlichen Sie genaue Routing-Autorität durch IRR-Objekte und ROAs.
2. Generieren Sie Kunden-Importfilter aus vertrauenswürdigen Daten und aktualisieren Sie sie sicher.
3. Lehnen Sie standardmäßig Routen ab, für die keine explizite Richtlinie vorliegt.
4. Durchsetzen Sie Kundenzapfen-, AS-Pfad-, Präfixlängen- und Maximalpräfix-Erwartungen.
5. Lehnen Sie RPKI-ungültige Ankündigungen an jedem relevanten externen Eingang ab.
6. Fügen Sie beziehungssensitive Kontrollen wie BGP Roles, OTC, Peerlock und, wenn es reift, ASPA-Validierung hinzu.
7. Beobachten Sie die Verbreitung von unabhängigen externen Standpunkten aus.
8. Halten Sie kontinuierlich getestete Betriebskontakte und Return-on-Authority bereit.

Keine einzelne Position ersetzt die anderen. Ihr Wert ergibt sich aus verschiedenen Fehlermodi.

Verantwortlichkeit zuweisen, ohne ein Haftungsurteil zu erfinden

Die öffentliche technische Aufzeichnung unterstützt eine Verantwortungsanalyse, aber sie enthält kein Gerichtsurteil, keine Regulierungsanordnung oder vollständige Vertragssätze, die die rechtliche Haftung zwischen DQE, AS396531, Verizon, Noction, Cloudflare und betroffenen Kunden zuweist. Es wurde kein öffentlicher Verizon-Root-Cause-Bericht in der für diesen Artikel verwendeten Aufzeichnung gefunden. Die folgende Zuordnung ist daher betrieblich: Wer hat welche Sicherheitsvorkehrung kontrolliert und wer könnte welches Risiko reduzieren. Es ist keine prozentuale Zuweisung von Schäden.

DQE Communications.DQE kontrollierte das Netzwerk, in dem Optimierungsrouten erzeugt wurden, und die Beziehung, über die sie AS396531 erreichten. Seine wertvollsten Pflichten waren es, den Routenumfang einzuschränken, eine externe Sichtbarkeit zu testen, eine korrekte Exportrichtlinie aufrechtzuerhalten und die Ankündigungen zu stoppen, sobald sie kontaktiert wurden. Cloudflare schrieb DQE-Mitarbeitern zu, beim Rückzug der Routen geholfen zu haben. Schnelle Zusammenarbeit verkürzte die Dauer; sie löscht das präventive Kontrollversagen nicht aus.

AS396531.Das mehrfach angebundene Netzwerk war die Brücke zwischen den Providern. Seine beobachtbare Ankündigung gegenüber Verizon ließ es so erscheinen, als ob es Erreichbarkeit für Routen bereitstellte, die es über DQE gelernt hatte. Ein Nicht-Transit-Unternehmen sollte eine enge Positivliste exportieren, keine gelernte vollständige Tabelle. Die öffentliche Aufzeichnung identifiziert nicht den Ingenieur, den Anbieter oder die Änderung, die das Filter entfernt oder umgangen hat, daher wäre eine individuelle Schuldzuweisung Spekulation. Die organisatorische Verantwortung liegt bei dem Design, das es einer Sitzungswiederherstellung erlaubte, Routen außerhalb der Autorität des Unternehmens freizulegen.

Verizon.Verizons kundenseitige Importrichtlinie war die folgenreichste nicht ausgeübte Kontrolle. Ein großes Transitnetzwerk, das Tausende von Routen von einem Kunden akzeptiert, sollte autorisierte Präfixe, erwartete Ursprünge und Pfade sowie das Präfixvolumen überprüfen. Das Routenarchiv zeigt, dass Verizon den Pfad verbreitete. Cloudflare sagt, dass relevante IRR-Daten und RPKI-Validierung ihn hätten ablehnen können, und berichtet von Schwierigkeiten, Verizon während des Vorfalls zu erreichen. Ohne Verizons interne Aufzeichnungen kann man nicht sagen, ob ein Filter nicht vorhanden, veraltet, falsch angewendet, umgangen oder auf andere Weise ausgefallen war. Jede dieser Möglichkeiten weist auf Assurance- und Incident-Koordinationspflichten hin, die proportional zum Maßstab des Providers sind.

Noction.Ein Routing-Optimierer, der global bevorzugte spezifischere Routen erzeugen kann, hat einen vorhersehbaren folgenschweren Fehlermodus, wenn die Eindämmung fehlschlägt. Zur Produktverantwortung gehören sichere Standardeinstellungen, auffällige Risikowarnungen, Bereitstellungsvalidierung, Routen-Tagging, externe Leak-Tests, Rollback und Kontrollen, die den intrusiven Modus nur mit verifizierten Grenzen aktivieren lassen. Noctions Antwort besagt, dass es die Verbreitung während der Bereitstellung getestet hat und dass Filter obligatorisch bleiben. Diese Behauptung wirft die nächste Prüfungsfrage auf: Hat das Produkt die Eindämmung nach Peering- oder Sitzungsänderungen kontinuierlich überprüft oder nur bei der Inbetriebnahme? Ein einmaliger Test kann die Sicherheit einer dynamischen Routing-Umgebung auf Dauer nicht beweisen.

Cloudflare.Cloudflare hat die unerwünschten Pfade weder erzeugt noch verbreitet, und es konnte Verizons Kundensitzung nicht konfigurieren. Es hatte den Kunden dennoch einen auf globalem Routing aufbauenden Verfügbarkeits- und Sicherheitsdienst verkauft. Seine Verantwortung liegt daher in den Restkontrollen: genaue ROAs, vielfältige Interkonnektion, externe Routenüberwachung, schnelle Diagnose, erreichbare Peer-Kontakte, Kundenkommunikation, Abhilfeoptionen und transparente Offenlegung. Es hatte auch die Pflicht, nicht zu behaupten, was seine Architektur aushalten könnte. Anycast und ein großes globales Netzwerk reduzieren viele Ausfälle, können aber ohne Hilfe validierender Netzwerke einen global akzeptierten spezifischeren nicht besiegen.

Andere Netzwerke.Peers und nachgelagerte Netzwerke, die die Routen von Verizon akzeptierten, waren nicht gleichermaßen positioniert, um AS396531s Kundenautorisierung zu kennen, aber sie konnten RPKI-Validierung und Pfadkontrollen einsetzen. Ihre Entscheidungen betrafen ihre eigenen Benutzer und in einigen Fällen die weitere Verbreitung. Das System ist sicherer, wenn große Transitnetzwerke korrekt handeln, aber ein empfangendes Netzwerk bleibt für die von ihm installierten Routen verantwortlich.

Diese Zuordnung vermeidet die bequeme, aber wenig hilfreiche Aussage, dass BGP auf Vertrauen basiert und daher niemand verantwortlich ist. Vertrauen wird durch Konfigurationen, Register, Verträge und Betriebspraktiken implementiert. Diese sind kontrollierbar. Die Offenheit des Protokolls erklärt, warum sich ein Fehler ausbreiten kann; sie entschuldigt keinen Provider von der Filterung von Kundenrouten.

Cloudflares geschäftliche Verantwortung überlebte die externe Ursache

Ein externer Auslöser hebt die Verpflichtungen eines Cloud-Providers gegenüber Kunden nicht auf. Cloudflares geänderte 2019Form S-1 Registrierungserklärungsagte, dass der Route-Leak im Juni erhebliche Störungen seines Datenverkehrs und dem anderer Provider verursachte. Es warnte, dass Route-Leaks den Ruf und das Vertrauen schädigen könnten, beschrieb Service-Level-Verpflichtungen, die zu Gutschriften oder Rückerstattungen führen könnten, und erklärte, dass der Route-Leak im Juni und ein separater Ausfall im Juli einige dieser Verpflichtungen auslösten. Damals erwartete Cloudflare nicht, dass die Vorfälle einen wesentlichen Einfluss auf die Betriebsergebnisse oder die Finanzlage haben würden.

Diese Offenlegung folgte auf einenSEC-Mitarbeiterkommentar, der das Unternehmen aufforderte, die angemessenerweise erwarteten finanziellen Auswirkungen des Route-Leaks im Juni im Lichte der Service-Level-Verpflichtungen zu behandeln. Der Austausch ist ein kompaktes Beispiel dafür, dass Verantwortlichkeit vom Netzwerkoperationszentrum zur Unternehmensberichterstattung wandert. Ein Vorfall kann extern verursacht, betrieblich bedeutend, vertraglich kompensierbar und finanziell unwesentlich für den Provider zugleich sein.

Die Einreichung legt nicht die Anzahl der betroffenen Kunden, die gesamten Gutschriften, Rückerstattungen, verlorenen Transaktionen oder die kundenseitige Ausfallzeit offen. Sie diskutiert den Route-Leak im Juni auch neben Cloudflares intern verursachtem Ausfall der Web Application Firewall am 2. Juli. Diese Ereignisse sollten nicht vermischt werden. Der Juni-Vorfall testet die Abhängigkeit von externem Routing. Der Juli-Vorfall testet interne Software-Änderungskontrollen. Beide betrafen die Verfügbarkeit, aber die präventiven Eigentümer und Beweise sind unterschiedlich.

Für Kunden ist eine Dienstgutschrift nicht gleichbedeutend mit einem wiederhergestellten Geschäft. Ein kleiner Online-Händler kann Bestellungen verlieren, ein Kommunikationsdienst kann Sitzungen verlieren, und ein Unternehmen kann Mitarbeiterstunden verbrauchen, bevor eine monatliche Abonnementgutschrift berechnet wird. Vertragliche Abhilfen weisen einen Bruchteil der direkten Providergebühren zu, nicht die vollen sozialen oder kundenseitigen Kosten von Ausfällen.

Cloud-Provider sollten daher mehr als nur vertragliche Betriebszeit melden: Erreichbarkeit nach Region und Netzwerk, Verkehrsverluste, Zeit bis zur Erkennung, Zeit bis zur Identifizierung, Zeit bis zur Kommunikation und Zeit bis zur stabilen Wiederherstellung.

Was Vorstände zu Peering- und Transitrisiken fragen sollten

Routing wird oft als spezialistisches Anliegen unterhalb der Ebene der Vorstandsaufsicht behandelt. Das Ereignis vom Juni 2019 zeigt, warum diese Trennung zu sauber ist. Eine BGP-Importrichtlinie bei einem großen Provider veränderte den Zugang zu vielen Cloud-Diensten, löste Kundenverpflichtungen aus, führte zu Investorenoffenlegung und legte Konzentration außerhalb formaler Cloud-Vendor-Verträge offen. Der Vorstand muss keine Router-Syntax wählen. Er benötigt jedoch Belege dafür, dass das Management weiß, wo die Verfügbarkeit vom Verhalten eines anderen autonomen Systems abhängt.

Ein nützliches Vorstandspaket beginnt mit der Exposition, nicht mit Compliance-Behauptungen:

Der Nenner ist in jeder Metrik wichtig. Zu sagen, dass RPKI auf Kernroutern bereitgestellt ist, verrät nicht, ob eine nicht validierte Edge-Sitzung eine Route in dasselbe Netzwerk injizieren kann. Zu sagen, dass Kundenfilter automatisiert sind, zeigt nicht, ob das Quellregister vollständig ist, ob Notfallausnahmen bestehen bleiben oder ob eine neue BGP-Sitzung die Richtlinie geerbt hat. Zu sagen, dass Kontakte in einer Datenbank sind, beweist nicht, dass jemand um 06:30 Uhr Ortszeit mit Autorität antwortet.

Tests sollten kontrollierte Negativfälle umfassen. Ein Provider kann versuchen, ein nicht autorisiertes Laborpräfix, ein Präfix, das länger ist, als seine ROA erlaubt, eine übermäßige Routenanzahl und einen Pfad, der die deklarierte Kundenbeziehung verletzt, anzukündigen. Das erwartete Ergebnis sollte an der empfangenden Richtlinie und an unabhängigen Kollektoren beobachtet werden. Tests benötigen Sicherheitsvorkehrungen, damit sie selbst nicht zu Leaks werden, aber die Vermeidung aller realistischen Tests lässt das risikoreichste Verhalten unbewiesen.

Kundenresilienz ohne vereinfachende Multi-Provider-Ratschläge

Kunden hören oft, dass sie Abhängigkeiten vermeiden sollten, indem sie einen zweiten CDN, einen zweiten DNS-Provider oder eine zweite Cloud kaufen. Diversität kann helfen, aber Routing-Ausfälle respektieren keine Produktlabels. Zwei Provider können sich Transit, Austauschpunkte, Fasern, Routenkollektoren oder dieselben nicht validierenden Zugangsnetzwerke teilen. Ein durchgesickerter spezifischerer kann auch Verkehr anziehen, bevor die DNS- oder Anwendungs-Failover-Logik eines Kunden helfen kann.

Das korrekte Design beginnt mit dem Servicepfad. Welcher Provider ist autoritativ für DNS? Wo werden TLS-Schlüssel und Sicherheitsrichtlinien gehalten? Kann ein Ursprung sicheren direkten Verkehr akzeptieren? Kann der Verkehr verlagert werden, ohne eine Sicherheitsumgehung zu schaffen? Wie schnell ändern sich DNS-Caches? Halten Clients Verbindungen aufrecht? Hat ein sekundärer Provider aktuelle Konfiguration und Kapazität? Kann die Organisation einen Upstream-Routing-Ausfall von einem Ursprungsausfall unterscheiden, bevor sie den Verkehr verlagert?

Für einige Dienste ist die Active-Active-Bereitstellung über unabhängig geroutete Provider gerechtfertigt. Für andere überwiegen die Komplexität, inkonsistente Sicherheitsrichtlinien, das Cache-Verhalten und die zusätzliche Angriffsfläche einen zweistündigen Verfügbarkeitsgewinn. Eine vertretbare Entscheidung dokumentiert die Kritikalität, getestete Wiederherstellungszeit, gemeinsame Abhängigkeiten, Kosten und Restrisiko. Sie zählt keine Anbieternamen und nennt das Ergebnis belastbar.

Kunden können auch Beschaffungshebel nutzen. Sie können einen Cloud- oder Netzwerkprovider nach ROA-Abdeckung, ROV-Richtlinie, Kundenfilterkontrollen, MANRS-Teilnahme, Incident-Kontaktpraktiken, externer Überwachung und anonymisierten Testergebnissen fragen. DieMANRS-Netzwerkbetreibermaßnahmenbieten einen praktischen Rahmen: Filterung, Anti-Spoofing, Koordination und Veröffentlichung von Informationen, die andere validieren können. Mitgliedschaft oder Konformität ist ein Signal, kein Beweis für einwandfreien Betrieb, aber die Aktionen übersetzen Routensicherheit in Fragen, die ein Käufer verstehen kann.

Die wichtigste vertragliche Frage ist oft nicht der Betriebszeitprozentsatz. Es ist, welche Beweise und Unterstützung der Provider liefert, wenn Verkehr aufgrund von externem Routing keinen gesunden Dienst erreichen kann. Schnelle, spezifische Statuskommunikation hilft Kunden, destruktive Änderungen an gesunden Ursprüngen zu vermeiden. Routendaten nach einem Vorfall helfen ihnen, ihre eigenen Beobachtungen abzugleichen. Eine eng gefasste Force-Majeure- oder Drittparteienklausel kann die Entschädigung begrenzen, aber sie sollte nicht die betriebliche Pflicht des Providers zur Diagnose und Kommunikation beenden.

Von freiwilligen Normen zu Risikomanagement-Nachweisen

Das Ereignis vom Juni 2019 fand in einem weitgehend freiwilligen Routensicherheitsumfeld statt. Die besten Praktiken waren nicht unbekannt. Präfix- und AS-Pfad-Filterung, IRR-Daten, Maximalpräfixkontrollen, RPKI und Betreiberkontaktregister existierten. Annahme und Sicherstellung waren ungleichmäßig, insbesondere wenn ein Netzwerk Bereitstellungskosten tragen musste, während die Vorteile im gesamten Internet verteilt wurden.

Dieses kollektive Handlungsproblem zog später explizitere staatliche Aufmerksamkeit auf sich. DerFahrplan zur Verbesserung der Internet-Routing-Sicherheitdes Büros des National Cyber Director der USA aus dem Jahr 2024 beschreibt BGPs Unfähigkeit, im üblichen Betrieb die Ursprungsautorität, Nachrichtenintegrität, entfernte Pfadinformationen oder Ankündigungen zu validieren, die benachbarte Geschäftsrichtlinien verletzen. Er fordert eine stärkere Annahme von Routenursprungssicherheit, insbesondere bei großen Providern und staatlich beauftragten Diensten. Der Fahrplan ist eine politische Leitlinie, keine Feststellung über die Teilnehmer von 2019.

DieSecure Internet Routing-Mitteilungder Federal Communications Commission von 2024 schlug BGP-Risikomanagementpläne und Berichterstattung für Breitbandanbieter vor und bat um Kommentare zu Maßnahmen über die RPKI-Ursprungsvalidierung hinaus. Sie erkannte ausdrücklich an, dass Pfadsicherheit weitere Arbeit erfordert. Auch dies schafft keine rückwirkende Haftung für Juni 2019. Es veranschaulicht einen Governance-Wandel von der Frage, ob ein Provider RPKI grundsätzlich unterstützt, hin zur Forderung nach einem gepflegten Plan, Abdeckungsdaten, Bestätigung und Fortschritt.

Regulierung hat ihre eigenen Risiken. Ein Prozentziel für die ROA-Registrierung kann breite, erlaubende Autorisierungen belohnen. Eine Einreichungspflicht kann zu Papierkram werden, der von der Routerrichtlinie getrennt ist. Die öffentliche Offenlegung detaillierter defensiver Konfigurationen kann Sicherheitsbedenken hervorrufen. Eine wirksame Aufsicht sollte sich daher auf Ergebnisse und kontrollierte Nachweise konzentrieren: genaue Autorisierung, Ablehnungsabdeckung, getestete Kundenrichtlinie, Ausnahmegovernance, Erkennungsgeschwindigkeit, Kontaktbereitschaft und Lernen aus Vorfällen.

Ein vertraulicher Aufsichtszugang kann für sensible Details angemessen sein, während aggregierte Annahme- und Vorfallmetriken öffentlich bleiben.

Die Routensicherheits-Allmende überschreitet auch nationale Grenzen. Verizons Verbreitung betraf Benutzer und Dienste weltweit; Cloudflare-Ingenieure in mehreren Regionen beteiligten sich an der Reaktion; Routenautorität wird über regionale Register verteilt; und Empfänger wenden ihre eigene Richtlinie an. Eine nationale Regel kann das Verhalten von Providern in ihrem Zuständigkeitsbereich verbessern, aber interoperable Standards und Betreibernormen sind es, die diese Verbesserung reisen lassen.

Die noch fehlenden Beweise aus der öffentlichen Aufzeichnung

Cloudflares Tiefenanalyse ist ungewöhnlich reproduzierbar: Sie identifiziert RIPE NCC-Daten, liefert Befehle und zeigt beobachtete Pfade und Zeitstempel. Diese Transparenz unterstützt ein hohes Vertrauen in die Routenchronologie. Sie beantwortet nicht jede Frage zur Verantwortlichkeit.

Die folgenden Aufzeichnungen würden die Analyse wesentlich verbessern, wenn die beteiligten Betreiber sie veröffentlichen würden:

• DQEs Optimiererkonfiguration, Richtlinie für erzeugte Präfixe, Exportkarten, Community-Handhabung und externe Verbreitungstests vor und nach der Bereitstellung.
• AS396531s BGP-Richtlinie, die an DQE- und Verizon-Sitzungen angebunden ist, die Sitzungsabwärts- und -aufwärtszeitlinie, Konfigurationsänderungen, Routenanzahlen und der Grund, warum vom Provider gelernte Routen für den Export infrage kamen.
• Verizons Kunden-Onboarding-Aufzeichnung, IRR- oder Präfixlistenquelle, AS-Pfad-Richtlinie, Maximalpräfixeinstellung, RPKI-Validierungsstatus, Alarme, Betreiberantwortzeitlinie und Erklärung für die globale Verbreitung.
• Noctions Bereitstellungscheckliste, Sicherheitsvorkehrungen zur kontinuierlichen Eindämmung, Alarmierungsverhalten und Produktänderungen nach dem Vorfall.
• Cloudflares erster interner Erkennungszeitstempel, Alarmquelle, erwogene Abhilfemaßnahmen, Eskalationszeitlinie für Peer-Kontakte, Kundenauswirkungen nach Netzwerk und Region und Überprüfung von Korrekturmaßnahmen.
• Quantifizierte Dienstgutschriften, Rückerstattungen, Supportaufkommen und Kundenabwanderung, die spezifisch auf den Route-Leak im Juni und nicht auf den separaten Ausfall im Juli zurückzuführen sind.

Ihre Abwesenheit macht das Ereignis nicht unerkennbar. Öffentliche BGP-Ankündigungen sind Beweise dafür, was Netzwerke einander sagten. Verkehrsmessungen sind Beweise für die Dienstauswirkungen. SEC-Einreichungen sind Beweise für die Offenlegung von Unternehmen und die erwartete Wesentlichkeit. Betreiber-Blogs sind Beweise für zugeschriebene Erklärungen. Die Disziplin besteht darin, diese Beweisklassen getrennt zu halten.

Es ist auch wichtig, eine fehlende öffentliche Aufzeichnung nicht mit einer fehlenden internen Aufzeichnung zu verwechseln. Verizon, DQE, AS396531 und Noction haben möglicherweise umfangreiche Überprüfungen durchgeführt, die nie veröffentlicht wurden. Cloudflare verfügt möglicherweise über detaillierte Telemetriedaten, die nicht in seinen Beiträgen enthalten sind. Die öffentliche Verantwortlichkeit ist schwächer, wenn die Beweise privat bleiben, aber der Artikel kann nicht ableiten, dass kein Lernen stattgefunden hat.

Ein dauerhafter Verantwortlichkeitsstandard für Routenresilienz

Der Ausfall vom Juni 2019 ist in Erinnerung geblieben, weil ein kleines Netzwerk zum scheinbaren Pfad zu großen Teilen des Internets wurde. Die tiefere Lektion ist, dass der Maßstab nicht entsprechende Skepsis erzeugte. Ein großer Transit-Provider erhielt außergewöhnliche Behauptungen von einem Kunden und verbreitete sie; viele Netzwerke akzeptierten das Ergebnis; Verkehr folgte Protokollregeln in einen unglaubwürdigen Pfad; und die Wiederherstellung hing davon ab, Menschen zu finden, die die Ankündigungen zurückziehen konnten.

Das Ereignis war mit den damals verfügbaren Kontrollen vermeidbar. DQE hätte Optimierungsrouten eindämmen können. AS396531 hätte nur autorisierte Präfixe exportieren können. Verizon hätte Kundenankündigungen mit Register-, Pfad-, Präfixanzahl- und RPKI-Beweisen filtern können. Empfangende Netzwerke hätten die RPKI-ungültigen Cloudflare-spezifischeren ablehnen können. Bessere Überwachung und Kontaktbereitschaft hätten das Ereignis verkürzen können. Spätere Standards machen einige Beziehungsannahmen leichter signalisierbar, aber sie verwandeln betriebliche Disziplin nicht in ein optionales Erbe-Anliegen.

Cloudflares Rolle ist komplizierter als Opfer oder Eigentümer. Es war das Ziel, dessen Erreichbarkeit durch externe Entscheidungen beeinträchtigt wurde. Es hatte bereits ROAs veröffentlicht, die zur Ablehnung der durchgesickerten spezifischeren geeignet waren, betrieb ein verteiltes Netzwerk, erkannte das Ereignis, koordinierte den Rückzug, erklärte den Routenverlauf und offenbarte vertragliche Konsequenzen. Es schuldete den Kunden dennoch einen klaren Status, Wiederherstellungsbemühungen, finanzielle Abhilfen, wo vertraglich vereinbart, und eine wahrheitsgemäße Darstellung des verbleibenden Routing-Risikos.

Ein Provider kann nicht versprechen, dass der Rest des Internets seine Routen validiert; er kann versprechen, die Validierung zu ermöglichen, zu überwachen, was passiert, und mit Beweisen zu reagieren.

Der endgültige Verantwortlichkeitsstandard ist daher nicht null Route-Leaks. Kein globales Netzwerk kann garantieren, dass jedes autonome System jede Sitzung korrekt konfiguriert. Der Standard ist, ob jede Partei das Risiko in ihrem Kontrollbereich reduziert hat, diese Reduzierung von außen getestet hat, den Schrapnell unvermeidbarer Fehler begrenzt hat, durch einen geübten Koordinationspfad reagiert hat und genügend Beweise für Kunden und Aufseher produziert hat, um Verbesserungen zu überprüfen.

So sieht Netzwerk-Resilienz jenseits der Grenze aus: nicht Unabhängigkeit von anderen Netzwerken, die das Internet unmöglich macht, sondern disziplinierte Grenzen dafür, wie viel nicht verifiziertes Vertrauen eine einzelne Route verbrauchen kann.