Cloudflare, der Route-Leak vom Juni 2019 und die Verantwortung jenseits des Netzwerkrands

Zusammenfassung

• Am 24. Juni 2019 wurden im Netzwerk von DQE Communications optimierte, spezifischere Routen generiert, über den Kunden AS396531 an AS701 von Verizon übermittelt und von diesem akzeptiert. Verizon verbreitete daraufhin Pfade, die Tausende von Netzwerken umfassten. Da Router ein spezifischeres Zielpräfix bevorzugen, folgte ein erheblicher Teil des Datenverkehrs den durchgestochenen Routen in Verbindungen, die dafür nicht dimensioniert waren; Cloudflare meldete auf dem Höhepunkt des Vorfalls einen Verlust von etwa 15 % seines weltweiten Datenverkehrs.
• Die öffentliche Aufzeichnung der Routen zeigt eine Kette von Kontrollversagen, nicht eine einzelne Ursache. Der Routengenerator hielt seine Optimierungsrouten nicht lokal, ein multihomed Kunde exportierte von einem Anbieter gelernte Routen zu einem anderen, 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 bei der Entfernung helfen, jedoch nicht einseitig die Importrichtlinie eines anderen Netzwerks ändern.
• Die RPKI-Origin-Validierung war für den Cloudflare betreffenden Teil dieses Ereignisses besonders geeignet, da seine Route Origin Authorizations (ROA) seine aggregierten Präfixe nur bis zu einer angegebenen maximalen Länge autorisierten. Die durchgestochenen Spezifischeren überschritten diese Länge und waren daher ungültig. Dies macht RPKI nicht zu einer vollständigen Lösung gegen Route-Leaks: Origin-gültige Pfade können immer noch Geschäftsbeziehungen verletzen, weshalb Kundenfilterung, Präfixgrenzen, BGP-Rollen, Pfadkontrollen, Überwachung und erreichbare Betriebskontakte weiterhin erforderlich sind.
• Verantwortung folgt der Kontrollfähigkeit. Betreiber, die außergewöhnliche Routen generieren oder exportieren, müssen diese eindämmen und testen; Anbieter müssen überprüfen, was Kunden ankündigen können; Cloud-Plattformen müssen Routing-Autorität veröffentlichen, externe Pfade beobachten, schnell koordinieren und die Auswirkungen auf Kunden offenlegen; Kunden müssen die Ausfallsicherheit von Abhängigkeiten planen; und Vorstände und Regulierungsbehörden müssen Maßnahmen zur Sicherung des Routings verlangen, anstatt eine allgemeine Konformitätserklärung mit bewährten Praktiken der Branche.

Ein Routing-Ausfall, kein Serverausfall von Cloudflare

Um 10:34:25 UTC am 24. Juni 2019 begannen öffentliche BGP-Sammler, anomale, spezifischere Routen für den Adressraum von Cloudflare aufzuzeichnen. Die letzte der untersuchten Cloudflare-Routen verschwand um 12:38:54 UTC. Die eingehende Analyse der archivierten Cloudflare-Routenrekonstruiert dieses Intervall anhand von RIPE NCC-Datenund zeigt einen bemerkenswert konsistenten Pfad: AS13335 von Cloudflare, einer seiner Transit-Anbieter, AS33154 von DQE Communications, AS396531 von Allegheny Technologies und AS701 von Verizon. Andere Netzwerke lernten die Route anschließend über Verizon.

Der Pfad ist wichtig, weil der Ausfall nicht mit einem Ausfall eines Cloudflare-Rechenzentrums oder einer Anwendungsbereitstellung begann. Cloudflares Maschinen kündigten weiterhin ihre üblichen aggregierten Routen 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 auf einen nicht vorgesehenen Pfad. Überlastung und Paketverlust folgten, bevor die Anfragen den Cloudflare-Rand erreichten.

Cloudflares Erklärung des Vorfalls damalsberichtete, dass auf dem Höhepunkt etwa 15 % seines weltweiten Datenverkehrs verloren gegangen seien. Dies ist eine unternehmenseigene Messung, kein universell geprüfter Ausfallprozentsatz. Sie beschreibt Cloudflare-Verkehr, nicht 15 % des gesamten Internets. Die unabhängige Beobachtung unterstützt dennoch den allgemeinen Mechanismus und die Multiservice-Auswirkung. ThousandEyes berichtete in seinerNetzwerkpfadanalyse, dass Benutzer etwa zwei Stunden lang Schwierigkeiten hatten, auf Cloudflare-gehostete Dienste und einige AWS-Dienste zuzugreifen, während die Untersuchung von CatchpointLeistungsprobleme bei genannten Online-Dienstengegen 10:30 UTC aufzeichnete.

Die Unterscheidung zwischen Routenverfügbarkeit und Serververfügbarkeit ist wichtig für die Verantwortung. Eine Plattform kann gesunde Server in vielen Ländern betreiben und dennoch unerreichbar sein, wenn die Routing-Kontrollebene den Datenverkehr woandershin leitet. 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 ausführen können.

Cloudflares Statusaufzeichnung für das Ereignisbeschrieb zunächst Leistungsprobleme im Netzwerk, identifizierte dann einen möglichen Route-Leak und teilte später mit, dass das verantwortliche Netzwerk das Problem behoben habe. Öffentliche Kopien der Statusaktualisierungen setzen die Untersuchungsmeldung auf 11:02 UTC, die Identifizierung auf 11:36 UTC und die Überwachung nach der Behebung auf 12:42 UTC. BGP-Archive zeigen anomale Routen vor der ersten Statusmeldung. Dieser Unterschied ist kein Beweis dafür, dass Cloudflare ein bekanntes Ereignis 28 Minuten lang ignoriert hat. Es ist eine Frage der nützlichen Verantwortung: Wann erkannten automatisierte Systeme anomalen Datenverkehr, wann identifizierten Ingenieure externes Routing als Ursache und wann hatte das Unternehmen genug Vertrauen, um die Kunden zu benachrichtigen?

Keine öffentlichen Beweise zeigen böswillige Absicht, Verkehrsüberwachung oder Kompromittierung von Cloudflare-Systemen bei diesem Ereignis. Ein Route-Leak kann eine Abfangmöglichkeit schaffen, aber der hier beobachtete Dienstschaden war Überlastung und Verlust entlang eines nicht vorgesehenen Pfads. Der Artikel behandelt den Vorfall daher als einen Ausfall der Routing-Verfügbarkeit und -Integrität. Er wandelt keine mögliche Sicherheitseigenschaft von Route-Leaks in eine Behauptung um, dass Datenverkehr gelesen wurde.

Wie eine lokale Optimierung zu einer globalen Route wurde

Das Internet ist eine Vereinbarung zwischen autonomen Systemen und kein zentrales 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 grundlegende Protokoll inRFC 4271gibt den Betreibern erhebliche Richtlinienfreiheit. 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 einhergeht, dass jeder AS im Pfad beabsichtigt hatte, die Ankündigung so weit reichen zu lassen.

Vor dem Vorfall verwendete DQE ein BGP-Optimierungsprodukt von Noction. Ein solches Produkt kann die Leistung von Pfaden messen und spezifischere Routen einfügen, um zu beeinflussen, welche Verbindung den ausgewählten Datenverkehr transportiert. Im von Cloudflare veröffentlichten Beispiel wurde die normale Ankündigung104.20.0.0/20aufgeteilt in104.20.0.0/21und104.20.8.0/21. Beide /21 decken denselben Adressbereich wie das /20 ab, benennen jedoch jeweils einen kleineren Zielblock.

Innerhalb eines kontrollierten Netzwerks können die Spezifischeren ein legitimes Werkzeug des Traffic Engineerings sein. Die Gefahr liegt in der Reichweite. 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 einem globalen Anspruch geworden.

Noctions eigene Antwort auf den Vorfall vom 26. Junierkannte an, dass seine Plattform die Spezifischeren generiert hatte, und beschrieb drei erschwerende Bedingungen: Generierung innerhalb des Netzwerks seines Kunden, Leck durch einen nachgelagerten ASN zu einem großen Anbieter und unzureichende Filterung an allen drei autonomen Systemen. Noction argumentierte, dass die Erstellung von Spezifischeren eine gängige Praxis und kein inhärenter Fehler sei, und betonte die Filterung der Anbieter. Diese Antwort ist relevant, da sie die Rolle des Optimierers bestätigt, während sie eine einseitige Erzählung in Frage stellt. Es ist kein unabhängiger Post-Mortem und veröffentlicht nicht die genaue Konfiguration, das Änderungsprotokoll oder die Testergebnisse für die Bereitstellung bei DQE.

Die separate Routing-Analyse von Qrator Labsverband den Beginnmit der Wiederherstellung der BGP-Sitzung zwischen AS396531 und Verizon kurz nach 10:35 UTC. Sein Bericht besagt, dass AS396531 Filter verloren und von DQE gelernte Routen exportiert hatte. Dies liefert einen plausiblen Auslöser dafür, warum der Zustand zu diesem Zeitpunkt begann, aber die verfügbare öffentliche Aufzeichnung enthält keine Router-Konfigurationen oder Protokolle von AS396531, DQE oder Verizon. Die sichere Schlussfolgerung ist enger: Der beobachtbare Pfad beweist, dass die Routen diese AS-Grenzen überschritten haben; die Berichte der Betreiber identifizieren fehlende oder unzureichende Filter; die genaue Abfolge interner Änderungen bleibt nicht öffentlich.

Diese Unterscheidung verhindert drei häufige Fehler. Erstens sollte DQE nicht als Ursprung des Cloudflare-Adressraums im BGP-Sinne beschrieben werden. Der beobachtete AS-Pfad endete immer bei AS13335 von Cloudflare. Der Optimierer von DQE erstellte und verbreitete einen spezifischeren Pfad mit erhaltener legitimer Herkunft. Zweitens erfand Verizon die Routen nicht, aber seine Annahme und globale Verbreitung erweiterte ihre Reichweite erheblich. Drittens wählte das Netzwerk von Cloudflare nicht AS396531 als bevorzugten Pfad. Entfernte Netzwerke trafen Weiterleitungsentscheidungen basierend auf den Ankündigungen, die sie erhielten.

Warum spezifischere Routen Distanz und Anycast besiegten

Für einen Nicht-Spezialisten könnte das Ereignis so aussehen, als hätten Router einen kürzeren AS-Pfad ausgewählt. Die entscheidende Präferenz trat früher auf. Das Internet-Routing verwendet die längste Präfix-Übereinstimmung: 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 klassenloses Inter-Domain-Routing, beschreibt dieses Verhalten der längsten Übereinstimmung und seine Beziehung zu aggregierten und spezifischeren Routen.

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

Deshalb umging Cloudflares Anycast-Fußabdruck das Problem nicht automatisch. Anycast ermöglicht es vielen Cloudflare-Standorten, dieselben Präfixe anzukündigen, sodass BGP eine geeignete Instanz auswählt. Es bietet geografische Verteilung und kann den Ausfall einzelner Standorte oder Verbindungen abfangen. Aber die durchgestochenen /21 waren spezifischer als Cloudflares normale /20-Ankündigungen. Das globale Routingsystem konnte das /21 bevorzugen, bevor es verglich, welcher Anycast-Standort von Cloudflare am nächsten war. Die Redundanz hinter der verlierenden Route stellte den Datenverkehr 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 Datenverkehr gelangte in einen Korridor ohne die Kapazität oder Richtlinie, ihn zu transportieren. Pakete wurden verzögert oder verworfen. Ein Route-Leak kann manchmal Datenverkehr über einen ineffizienten Pfad liefern; hier verwandelte der Maßstab den Pfad in einen Engpass.

Die Taxonomie von Route-Leaks der Internet Engineering Task Force inRFC 7908definiert einen Route-Leak als eine Verbreitung über den beabsichtigten Geltungsbereich einer Ankündigung hinaus. Das Ereignis vom Juni 2019 kombiniert Merkmale, die die Taxonomie zu Analysezwecken trennt. Es umfasste vom Anbieter gelernte Routen, die von einem Multihoming-Netzwerk zu einem anderen Anbieter exportiert wurden, was dem klassischen Hairpin-Turn-Modell ähnelt, und spezifischere Routen, die intern nützlich waren, aber nie für eine globale Verbreitung bestimmt waren. Das Etikett ist weniger wichtig als die verletzte Invariante: Ein Kunde von Verizon schien Transit zu Präfixen außerhalb seines legitimen Kundenkegels anzubieten, und Verizon akzeptierte diesen Anschein.

Die Zeitleiste und das wachsende Verantwortungsfenster

Die Verantwortung verschiebt sich, wenn ein Vorfall von der Prävention zur Erkennung und Wiederherstellung übergeht. Die folgende Zeitleiste verwendet öffentliche Routendaten und Aussagen, die den Betreibern zugeschrieben werden; sie füllt Lücken nicht mit angenommenen internen Aktionen.

Die folgenreichste Periode begann vor dem ersten Zeitstempel. Beginnt ein Vorstand seine Prüfung um 10:34, konzentriert er sich auf Warnungen und Anrufe. Beginnt er, als die Optimiererrouten für die Produktion freigegeben wurden, kann er Konzeptsicherheit, Routenreichweite, Standardeinstellungen, Peering-Richtlinien, Änderungsüberprüfung und unabhängige Ausbreitungstests prüfen. Die Reaktion auf den Vorfall 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 durchquerte mehrere Grenzen, jede mit einer anderen Gelegenheit, sie zu stoppen. Diese Gelegenheiten als Schichten zu behandeln, klärt die Verantwortung, ohne zu behaupten, dass alle Parteien gleiche Kontrolle hatten.

Eindämmung im Ursprungsnetzwerk und Optimierer.DQE kontrollierte die Umgebung, in der das Noction-Produkt die Spezifischeren generierte. Routen, die nur für lokale Entscheidungen bestimmt waren, benötigten eine Exportsperre, die nicht vom korrekten Verhalten jedes Nachgelagerten abhing. Zu den Optionen gehörten eine strikt begrenzte Exportrichtlinie, ein dedizierter Routing-Kontext, explizite Communities, die von jedem Ausgang interpretiert werden, automatisierte Prüfungen von externen Sammlern und ein Notausschalter, der an unerwartete Ausbreitung gekoppelt ist. Noction sagt, es habe Bereitstellungstests durchgeführt und die Verwendung vonNO_EXPORTdiskutiert, argumentiert aber auch, dassNO_EXPORTnicht in jedem Multi-AS-Design angemessen sei. Die bekannte Community ist inRFC 1997definiert: Eine Route, die sie trägt, darf nicht außerhalb einer Konföderationsgrenze angekündigt werden. Es ist nicht öffentlich bekannt, ob sie in diesem Ereignis verwendet, aufbewahrt, entfernt oder nie angehängt wurde.

Exportkontrolle beim Multihoming-Kunden.AS396531 hätte die vollständigen oder optimierten Routen eines Anbieters nicht an einen anderen Anbieter weitergeben dürfen, es sei denn, es fungierte absichtlich als Transit. Ein Blatt- oder Unternehmensnetzwerk kann eine einfache Ausgangsregel anwenden: Nur eigene autorisierte Präfixe und explizit genehmigte Kundenpräfixe ankündigen. Eine Standardverweigerung ist zuverlässiger als zu versuchen, jede Route zu identifizieren, die nicht herausgehen soll.RFC 8212, veröffentlicht 2017, kodifizierte die Standardverweigerung von eBGP, wenn keine explizite Import- oder Exportrichtlinie konfiguriert ist. Es kann nicht verhindern, dass ein Betreiber eine falsche, freizügige Richtlinie anwendet, aber es beseitigt eine Klasse versehentlicher Ausbreitung, die durch fehlende Richtlinie verursacht wurde.

Kunden-Eingangskontrolle beim Anbieter.Verizon hatte den effektivsten Stoppunkt. Ein Transit-Anbieter weiß, welche Sitzung eine Kundensitzung ist, und sollte wissen, was dieser Kunde anzukündigen oder zu transitieren berechtigt ist. Cloudflares eingehende Analyse stellte fest, dass die mit dem Kunden verbundenen Registerinformationen weder die ASN von Cloudflare noch die anderen durchgestochenen Netzwerke enthielten. Ein kundenspezifischer Präfix- und AS-Pfad-Filter hätte die Ankündigungen daher ablehnen können. Der Leitfaden für BGP-Betrieb und -Sicherheit inRFC 7454, veröffentlicht 2015, empfiehlt Richtlinien für empfangene und angekündigte Routen an jeder Grenze, Kundenpräfixprüfungen, AS-Pfad-Filterung und maximale Präfixgrenzen.

Ablehnung durch Peers und Nachgelagerte.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 Origin-Validierung verwendeten, hätten die betroffenen Cloudflare-Spezifischeren als RPKI-ungültig abgewiesen. Andere konnten Route-Leak-Heuristiken oder Peering-Richtlinien verwenden. Jedoch ist es weniger effektiv, jedes entfernte Netzwerk zu bitten, einen Fehler abzufangen, nachdem ein großer Anbieter ihn verteilt, als ihn an der ursprünglichen Kundensitzung abzuweisen. Die Prävention, die der Richtlinienverletzung am nächsten ist, begrenzt die Ausbreitung, 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 korrekt konfigurierten Routing-Richtlinie. Wenn jede Schicht manuell freizügig oder auf der Grundlage unvollständiger Kundenaufzeichnungen aufgebaut ist, können drei Kontrollen zusammen versagen. Ein ausgereiftes Assurance-Programm testet daher das Ergebnis von außerhalb des administrativen Bereichs. Es akzeptiert nicht die alleinige Konfigurationsprüfung als Beweis dafür, dass eine Route lokal geblieben ist.

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

Cloudflare hatte 2018 begonnen, Routen zu signieren und die Validierung bereitzustellen, wie in seinemRPKI-Bereitstellungsberichtbeschrieben. Eine Route Origin Authorization (ROA) gibt an, welches autonome System ein Präfix originieren darf und optional die spezifischste Präfixlänge, die es ankündigen kann. Cloudflare gibt an, dass seine relevanten Routen AS13335 mit einer maximalen Länge von /20 autorisierten. Die durchgestochenen /21 behielten AS13335 als Ursprung bei, überschritten jedoch die maximal autorisierte Länge. Sie waren daher laut Origin-Validierung ungültig.

Die Logik ist inRFC 6811formalisiert. Eine empfangene Route ist gültig, wenn eine validierte ROA-Nutzlast das Präfix abdeckt, die ursprüngliche ASN übereinstimmt und die Präfixlänge der Route das Maximum der ROA nicht überschreitet. Sie ist ungültig, wenn eine Deckungsautorisierung existiert, aber keine alle erforderlichen Eigenschaften erfüllt. Die Erklärung der Origin-Validierung des RIPE NCCunterscheidet nützlich zwischen den Zuständen gültig, ungültig und unbekanntund betont, dass Netzbetreiber immer noch entscheiden, welche Richtlinie sie auf diese Zustände anwenden.

Cloudflares Akt der Erstellung von ROAs war notwendig, aber nicht ausreichend. Eine ROA ist ein veröffentlichter Nachweis, kein Fernanwendungsbefehl. Verizon oder ein anderes empfangendes Netzwerk musste validierte RPKI-Daten abrufen, die Validierung auf die Kundenroute anwenden und die Ungültigen ablehnen. Cloudflare konnte ungültige Routen, die in sein eigenes Netzwerk kamen, ablehnen, aber das verhinderte nicht, dass Drittanbieter-Netzwerke Datenverkehr, der für Cloudflare bestimmt war, entlang einer anderswo ausgewählten Route sendeten.

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 vorbeugende Kontrolle, da der Optimierer die Präfixlänge änderte. Es wäre falsch, diese Erfolgsbedingung auf jeden Route-Leak zu verallgemeinern. Hätte AS396531 das normale /20 von Cloudflare durchgestochen, während AS13335 am Ende des Pfads blieb, hätte die Origin-Validierung die Route möglicherweise als gültig betrachtet. Die Route würde immer noch die erwartete Anbieter-Kunden-Topologie verletzen. Die RPKI-Origin-Validierung beantwortet, wer ein Präfix originieren darf und in welcher Länge. Sie beweist nicht, dass jede Transitbeziehung im AS-Pfad autorisiert ist.

Diese Einschränkung ist keine Kritik an RPKI. Sie ist der Grund, sie zusammen mit anderen Kontrollen bereitzustellen. Der NIST SP 800-189-Leitfadenkombiniert RPKI und BGP-Origin-Validierungmit Präfixfilterung und breiteren Praktiken der Inter-Domain-Resilienz. Er behandelt Route-Leaks, Hijacks, Verkehrsablenkungen, 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 falschen Präfixe ablehnen können, während eine grundlegende Kundenfilterung den unglaubwürdigen Autoritätspfad auch ohne Kryptographie hätte ablehnen können.

Es gibt auch eine Governance-Lehre inmaxLength. Eine zu freizügige ROA kann nicht autorisierte Spezifischere gültig machen; eine zu restriktive oder veraltete ROA kann legitime Routen ablehnen lassen. ROA-Abdeckung, maximale Länge, Ablauf, Schlüssel- und Repository-Gesundheit sowie geplante Routing-Änderungen erfordern eine Änderungskontrolle. Ein Dashboard, das zeigt, dass ROAs existieren, ist kein Beweis dafür, dass sie die Produktionsabsicht genau beschreiben.

Pfadrichtlinienkontrollen nach 2019

Die Landschaft der Standards und Richtlinien entwickelte sich nach dem Ausfall weiter. Spätere Kontrollen sollten nicht so beschrieben werden, als ob Betreiber im Juni 2019 eine fertige Version hätten bereitstellen können, aber sie zeigen, wie die Industrie versucht hat, Annahmen zu kodieren, die zuvor implizit waren.

RFC 9234, veröffentlicht 2022, führte BGP-Rollen und das Only-to-Customer (OTC)-Attribut ein. Benachbarte Netzwerke können deklarieren, ob eine Beziehung Anbieter, Kunde, Peer, Route-Server oder Route-Server-Kunde ist. Die Rollenvereinbarung und die OTC-Verarbeitung ermöglichen es Routern, bestimmte Ankündigungen zu erkennen, die eine Beziehungsgrenze in einer unzulässigen Richtung überschreiten. In einer vereinfachten Version des Pfads von 2019 sollte eine Route, die von einem Anbieter gelernt und dann an einen anderen Anbieter gesendet wird, einen Beweis tragen, der mit einem kundenreservierten Export unvereinbar ist. BGP-Rollen wandeln bestimmtes Wissen über Geschäftstopologie von einer Betreiberkonvention in einen protokollsichtbaren Zustand um.

Peerlock bietet einen anderen pfadorientierten Ansatz. Der Artikel von 2020„Flexsealing BGP Against Route Leaks“untersuchte den von Betreibern bereitgestellten Mechanismus, einschließlich seiner Fähigkeit, Pfade zu stoppen, in denen ein großes geschütztes Netzwerk dort erscheint, wo es nicht sollte. Peerlock existierte vor dem Artikel 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, einsatzbereite Kontrolle verfügbar war.

Die Autonomous System Provider Authorization (ASPA) zielt darauf ab, es einem AS zu ermöglichen, überprüfbare Anbieterbeziehungen über das RPKI-System zu veröffentlichen. Dies ist vielversprechend, da viele Route-Leaks Fehler der Pfadplausibilität und nicht der Herkunft sind. Es erfordert jedoch eine vorsichtige Sprache: Die Standards und der Bereitstellungsstatus von ASPA haben sich weiterentwickelt, und eine teilweise Abdeckung erzeugt unbekannte Pfade.

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

Die Erkennung ist ebenfalls gereift. Cloudflare beschrieb später seinenRadar-Route-Leak-Erkennungsdienst, der Routing-Beziehungen und beobachtete Pfade verwendet, um wahrscheinliche Lecks zu melden. Überwachung verkürzt die Zeit bis zur Kenntnisnahme und die Zeit zur Koordination, verhindert jedoch 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 wiederholbaren Maßnahmen verbunden sein: betroffene Präfixe identifizieren, defensive Richtlinien anwenden, wo sicher, autorisierte Betreiber erreichen, Kundenstatus veröffentlichen, Rückzüge an unabhängigen Sammlern überprüfen und die Verkehrserholung überwachen.

Das nützliche Kontrollmodell ist daher kumulativ:

1. Veröffentlichen Sie genaue Routing-Autorität über IRR-Objekte und ROAs.
2. Generieren Sie Kunden-Importfilter aus zuverlässigen Daten und aktualisieren Sie diese sicher.
3. Lehnen Sie Routen standardmäßig ab, denen eine explizite Richtlinie fehlt.
4. Wenden Sie Erwartungen an Kundenkegel, AS-Pfad, Präfixlänge und maximale Anzahl von Präfixen an.
5. Lehnen Sie RPKI-ungültige Ankündigungen an jedem relevanten externen Eingang ab.
6. Fügen Sie beziehungsbewusste Kontrollen wie BGP-Rollen, OTC, Peerlock und, sobald ausgereift, ASPA-Validierung hinzu.
7. Beobachten Sie die Ausbreitung von unabhängigen externen Standpunkten aus.
8. Halten Sie kontinuierlich getestete Betriebskontakte und eine Autorität zum Zurückziehen von Routen aufrecht.

Kein Element ersetzt die anderen. Ihr Wert ergibt sich aus unterschiedlichen Fehlermodi.

Verantwortung zuweisen, ohne ein rechtliches Haftungsurteil zu erfinden

Die öffentliche technische Akte unterstützt die Verantwortungsanalyse, enthält aber kein Gerichtsurteil, keine Regulierungsverfügung und keinen vollständigen Vertragssatz, der die rechtliche Haftung zwischen DQE, AS396531, Verizon, Noction, Cloudflare und den betroffenen Kunden zuweist. Es wurde kein öffentlicher Root-Cause-Bericht von Verizon in der für diesen Artikel verwendeten Akte gefunden. Die folgende Zuordnung ist daher operativ: Wer kontrollierte welche Sicherung und wer konnte welches Risiko reduzieren. Es ist keine prozentuale Zuweisung von Schäden.

DQE Communications.DQE kontrollierte das Netzwerk, in dem die Optimierungsrouten generiert wurden, und die Beziehung, über die sie AS396531 erreichten. Seine wichtigsten Pflichten waren, die Reichweite der Routen zu begrenzen, die externe Sichtbarkeit zu testen, eine korrekte Exportrichtlinie aufrechtzuerhalten und die Ankündigungen zu stoppen, sobald es kontaktiert wurde. Cloudflare schrieb dem DQE-Personal zu, bei der Entfernung der Routen geholfen zu haben. Schnelle Zusammenarbeit verkürzte die Dauer; sie löscht das Versagen der vorbeugenden Kontrolle nicht aus.

AS396531.Das Multihoming-Netzwerk war die Brücke zwischen den Anbietern. Seine beobachtbare Ankündigung an Verizon ließ es so aussehen, als böte es Erreichbarkeit für die über DQE gelernten Routen. Ein Unternehmen ohne Transit sollte eine enge Zulassungsliste exportieren, keine vollständig gelernte Tabelle. Die öffentliche Akte identifiziert weder den Ingenieur, den Anbieter noch die Änderung, die die Filterung entfernt oder umgangen hat, daher wäre eine individuelle Schuld spekulativ. Die organisatorische Verantwortung liegt bei dem Design, das es einer Sitzungswiederherstellung ermöglichte, 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 Ereignisses zu erreichen. Ohne Verizons interne Aufzeichnungen kann nicht gesagt werden, ob ein Filter fehlte, veraltet, falsch angewendet, umgangen oder anderweitig fehlgeschlagen war. Jede dieser Möglichkeiten weist auf Assurance- und Incident-Koordinationspflichten hin, die im Verhältnis zum Maßstab des Anbieters stehen.

Noction.Ein Routing-Optimierer, der global bevorzugte Spezifischere erstellen kann, hat einen vorhersehbaren Fehlermodus mit hohen Auswirkungen, wenn die Eindämmung versagt. Die Produktverantwortung umfasst sichere Standardeinstellungen, sichtbare Risikowarnungen, Bereitstellungsvalidierung, Routenmarkierung, externe Lecktests, Rückfallmöglichkeiten und Kontrollen, die den intrusiven Modus ohne überprüfte Grenzen schwer aktivierbar machen. Noctions Antwort sagt, es habe die Ausbreitung während der Bereitstellung getestet und die Filter seien obligatorisch geblieben. Diese Behauptung wirft die nächste Prüfungsfrage auf: Hat das Produkt die Eindämmung kontinuierlich nach Peering- oder Sitzungsänderungen überprüft oder nur bei der Inbetriebnahme? Ein einzelner Test kann die Sicherheit einer dynamischen Routing-Umgebung nicht auf Dauer beweisen.

Cloudflare.Cloudflare hat die unerwünschten Pfade weder generiert noch verbreitet und konnte die Kundensitzung von Verizon nicht konfigurieren. Es hatte dennoch Kunden einen Dienst für Verfügbarkeit und Sicherheit verkauft, der auf globalem Routing basiert. Seine Verantwortung liegt daher in den verbleibenden Kontrollen: genaue ROAs, diversifizierte Interkonnektion, Überwachung externer Routen, schnelle Diagnose, erreichbare Peering-Kontakte, Kundenkommunikation, Abhilfeoptionen und transparente Offenlegung. Es hatte auch die Pflicht, nicht zu überschätzen, was seine Architektur verkraften konnte. Anycast und ein großes globales Netzwerk reduzieren viele Ausfälle, können aber eine global akzeptierte Spezifischere ohne die Hilfe von Validierungsnetzwerken nicht überwinden.

Andere Netzwerke.Peers und Nachgelagerte, die die Routen von Verizon akzeptierten, waren nicht gleichermaßen in der Position, die Kundenautorisierung von AS396531 zu kennen, aber sie konnten RPKI-Validierung und Pfadkontrollen bereitstellen. Ihre Entscheidungen betrafen ihre eigenen Benutzer und in einigen Fällen die weitere Ausbreitung. Das System ist sicherer, wenn große Transitnetzwerke korrekt handeln, aber ein empfangendes Netzwerk bleibt für die Routen verantwortlich, die es installiert.

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

Cloudflares geschäftliche Verantwortung überlebte die externe Ursache

Ein externer Auslöser beseitigt nicht die Verpflichtungen eines Cloud-Anbieters gegenüber seinen Kunden. Cloudflares geänderter Registrierungsantrag von 2019,Formular S-1, sagte, dass der Route-Leak vom Juni eine erhebliche Störung seines Datenverkehrs und des anderer Anbieter verursacht habe. 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 vom Juni und ein separater Ausfall im Juli einige dieser Verpflichtungen ausgelöst hätten. Zu dieser Zeit erwartete Cloudflare nicht, dass die Vorfälle einen wesentlichen Einfluss auf die Betriebsergebnisse oder die finanzielle Lage haben würden.

Diese Offenlegung folgte auf einenKommentar des SEC-Personals, der das Unternehmen aufforderte, die angemessen erwarteten finanziellen Auswirkungen des Route-Leaks vom Juni im Lichte der Service-Level-Verpflichtungen zu behandeln. Der Austausch ist ein kompaktes Beispiel dafür, wie die Verantwortung vom Network Operations Center zur Unternehmensberichterstattung übergeht. Ein Vorfall kann extern verursacht, operativ bedeutsam, vertraglich kompensierbar und finanziell unwesentlich für den Anbieter gleichzeitig sein.

Die Einreichung legt weder die Anzahl der betroffenen Kunden, die Gesamtsumme der Gutschriften, Rückerstattungen, verlorenen Transaktionen noch die Ausfallzeit auf Kundenseite offen. Sie diskutiert den Route-Leak vom Juni auch zusammen mit dem am 2. Juli durch Cloudflare intern verursachten Ausfall der Web Application Firewall. Diese Ereignisse sollten nicht verwechselt werden. Der Vorfall im Juni testet die Abhängigkeit vom externen Routing. Der Vorfall im Juli testet interne Software-Änderungskontrollen. Beide betrafen die Verfügbarkeit, aber die vorbeugenden Eigentümer und die Beweise sind unterschiedlich.

Für Kunden ist eine Servicegutschrift nicht gleichbedeutend mit wiederhergestellter Geschäftstätigkeit. Ein kleiner Online-Händler kann Bestellungen verlieren, ein Kommunikationsdienst kann Sitzungen verlieren und ein Unternehmen kann Personalstunden verbrauchen, bevor eine monatliche Abonnementgutschrift berechnet wird. Vertragliche Abhilfen weisen einen Bruchteil der direkten Gebühren des Anbieters zu, nicht die gesamten sozialen oder kundenbezogenen Kosten von Ausfallzeiten.

Cloud-Anbieter sollten daher mehr als nur die vertragliche Verfügbarkeit melden: Erreichbarkeit nach Region und Netzwerk, Verkehrsverlust, Erkennungszeit, Identifizierungszeit, Kommunikationszeit und stabile Erholungszeit.

Was Vorstände zum Peering- und Transitrisiko fragen sollten

Routing wird oft als spezialisiertes Anliegen unterhalb der Aufsichtsebene des Vorstands behandelt. Das Ereignis vom Juni 2019 zeigt, warum diese Trennung zu scharf ist. Eine BGP-Importrichtlinie bei einem großen Anbieter veränderte den Zugang zu vielen Cloud-Diensten, löste Kundenverpflichtungen aus, schuf eine Offenlegung gegenüber Investoren und legte eine Konzentration außerhalb der formellen Cloud-Anbieterverträge offen. Der Vorstand muss nicht die Router-Syntax wählen. Er benötigt Hinweise darauf, dass das Management weiß, wo die Verfügbarkeit vom Verhalten eines anderen autonomen Systems abhängt.

Eine nützliche Vorstandsakte beginnt mit der Exposition, nicht mit Konformitätsbehauptungen:

Der Nenner zählt bei jeder Metrik. Zu sagen, dass RPKI auf Kernroutern bereitgestellt ist, zeigt nicht, ob eine unvalidierte Randsitzung eine Route in dasselbe Netzwerk einschleusen kann. Zu sagen, dass die Kundenfilterung automatisiert ist, 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 Anbieter kann versuchen, ein nicht autorisiertes Laborpräfix, ein längeres Präfix als von seiner ROA erlaubt, eine übermäßige Anzahl von Routen und einen Pfad anzukündigen, der die deklarierte Kundenbeziehung verletzt. Das erwartete Ergebnis sollte an der Empfangsrichtlinie und an unabhängigen Sammlern beobachtet werden. Tests benötigen Sicherungen, um selbst keine Lecks zu werden, aber die Vermeidung realistischer Tests hinterlässt das riskanteste Verhalten ohne Nachweis.

Kundenresilienz ohne simplen Multi-Anbieter-Rat

Kunden hören oft, sie sollten Abhängigkeit vermeiden, indem sie einen zweiten CDN, einen zweiten DNS-Anbieter oder eine zweite Cloud kaufen. Vielfalt kann helfen, aber Routing-Ausfälle halten sich nicht an Produktetiketten. Zwei Anbieter können sich Transit, Austauschpunkte, Glasfaser, Routensammler oder dieselben nicht validierenden Zugangsnetzwerke teilen. Ein durchgestochenes Spezifischeres kann auch Datenverkehr anziehen, bevor die DNS- oder Anwendungs-Failover-Logik des Kunden eine Chance hat zu helfen.

Das richtige Design beginnt mit dem Dienstpfad. Welcher Anbieter ist autoritativ für DNS? Wo werden TLS-Schlüssel und Sicherheitsrichtlinien gespeichert? Kann ein Ursprung direkten Datenverkehr sicher annehmen? Kann der Datenverkehr verschoben werden, ohne Sicherheitsumgehungen zu schaffen? Wie schnell ändern sich DNS-Caches? Halten Kunden Verbindungen aufrecht? Hat ein sekundärer Anbieter eine aktuelle Konfiguration und Kapazität? Kann die Organisation einen vorgelagerten Routing-Ausfall von einem Ursprungsausfall unterscheiden, bevor sie den Datenverkehr verschiebt?

Für einige Dienste ist eine Active-Active-Bereitstellung über unabhängig geroutete Anbieter gerechtfertigt. Für andere überwiegen die Komplexität, inkonsistente Sicherheitsrichtlinien, das Cache-Verhalten und die erhöhte Angriffsfläche einen Verfügbarkeitsgewinn von zwei Stunden. Eine vertretbare Entscheidung dokumentiert die Kritikalität, die getestete Wiederherstellungszeit, die gemeinsamen Abhängigkeiten, die Kosten und das Restrisiko. Sie zählt keine Anbieternamen und nennt das Ergebnis nicht resilient.

Kunden können auch die Kaufkraft nutzen. Sie können einen Cloud- oder Netzwerkanbieter nach ROA-Abdeckung, ROV-Richtlinie, Kundenfilterkontrollen, MANRS-Teilnahme, Incident-Kontaktpraktiken, externer Überwachung und anonymisierten Testergebnissen fragen. DieMANRS-Netzbetreiberaktionenbieten 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 perfekten Betrieb, aber die Aktionen übersetzen Routing-Sicherheit in Fragen, die ein Käufer verstehen kann.

Die wichtigste vertragliche Frage ist oft nicht der Verfügbarkeitsprozentsatz. Es ist, welche Beweise und welche Unterstützung der Anbieter liefert, wenn Datenverkehr einen gesunden Dienst aufgrund externen Routings nicht 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 Drittanbieterklausel kann die Entschädigung begrenzen, sollte aber nicht die operative Pflicht des Anbieters zur Diagnose und Kommunikation beenden.

Von freiwilligen Standards zu risikomanagementbasierten Nachweisen

Das Ereignis vom Juni 2019 ereignete sich in einer weitgehend freiwilligen Umgebung der Routing-Sicherheit. Bewährte Praktiken waren nicht unbekannt. Präfix- und AS-Pfad-Filterung, IRR-Daten, maximale Präfixkontrollen, RPKI und Betreiberkontaktregister existierten. Die Einführung und Assurance waren ungleichmäßig, insbesondere dort, wo ein Netzwerk die Bereitstellungskosten tragen musste, während der Nutzen auf das Internet verteilt war.

Dieses Kollektivhandlungsproblem zog später explizitere Regierungsaufmerksamkeit auf sich. DerFahrplan zur Verbesserung der Internet-Routing-Sicherheitdes US-amerikanischen Office of the National Cyber Director von 2024 beschreibt die Unfähigkeit von BGP, im laufenden Betrieb die Ursprungsautorität, die Nachrichtenintegrität, entfernte Pfadinformationen oder Ankündigungen zu validieren, die benachbarte Geschäftsrichtlinien verletzen. Er fordert eine stärkere Einführung der Ursprungssicherheit, insbesondere bei großen Anbietern und staatlich beauftragten Diensten. Der Fahrplan ist ein politischer Leitfaden, kein Urteil über Entitäten von 2019.

Die Mitteilung der Federal Communications Commission von 2024 zurSicherung des Internet-Routingsschlug BGP-Risikomanagementpläne und Berichterstattung für Breitbandanbieter vor und bat um Kommentare zu Maßnahmen über die RPKI-Origin-Validierung hinaus. Sie erkannte explizit an, dass Pfadsicherheit zusätzliche Arbeit erfordert. Auch dies schafft keine rückwirkende Haftung für Juni 2019. Es veranschaulicht einen Wandel in der Governance von der Frage, ob ein Anbieter RPKI grundsätzlich unterstützt, hin zur Forderung nach einem gepflegten Plan, Abdeckungsdaten, einer Zusicherung und Fortschritten.

Regulierung hat ihre eigenen Risiken. Ein prozentuales Ziel für die ROA-Registrierung kann breite, freizügige Autorisierungen belohnen. Eine Einreichungspflicht kann zu einer Papierflut werden, die von der Router-Richtlinie losgelöst ist. Die öffentliche Offenlegung detaillierter defensiver Konfigurationen kann Sicherheitsbedenken hervorrufen. Effektive Aufsicht sollte sich daher auf Ergebnisse und kontrollierte Nachweise konzentrieren: genaue Autorisierung, Ablehnungsabdeckung, getestete Kundenrichtlinie, Ausnahmeverwaltung, Erkennungsgeschwindigkeit, Kontaktbereitschaft und Lernen aus Vorfällen.

Ein vertraulicher Aufsichtszugriff kann für sensible Details angemessen sein, während aggregierte Kennzahlen zu Einführung und Vorfällen öffentlich bleiben.

Die Allmende der Routing-Sicherheit überschreitet auch nationale Grenzen. Verizons Ausbreitung betraf Benutzer und Dienste weltweit; Cloudflare-Ingenieure in mehreren Regionen beteiligten sich an der Reaktion; die Routing-Autorität wird über regionale Register verteilt; und die Empfänger wenden ihre eigene Richtlinie an. Eine nationale Regel kann das Verhalten von Anbietern in ihrer Zuständigkeit verbessern, aber interoperable Standards und Betreibernormen sind es, die diese Verbesserung transportieren lassen.

Die noch fehlenden Beweise in der öffentlichen Akte

Cloudflares eingehende Analyse ist ungewöhnlich reproduzierbar: Sie identifiziert die RIPE NCC-Daten, gibt Befehle und zeigt beobachtete Pfade und Zeitstempel. Diese Transparenz unterstützt ein hohes Vertrauen in die Routenchronologie. Sie beantwortet nicht alle Verantwortungsfragen.

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

• Die Konfiguration des DQE-Optimierers, die Richtlinie für generierte Präfixe, die Exportzuordnungen, das Community-Management und Tests der externen Ausbreitung vor und nach der Bereitstellung.
• Die BGP-Richtlinie von AS396531, die an den DQE- und Verizon-Sitzungen angebracht ist, die Chronologie der Sitzungsab- und -aufbauten, die Konfigurationsänderungen, die Routenzählungen und der Grund, warum vom Anbieter gelernte Routen exportierbar waren.
• Die Kunden-Onboarding-Akte von Verizon, die IRR- oder Präfixlistenquelle, die AS-Pfad-Richtlinie, die maximale Präfixeinstellung, der RPKI-Validierungsstatus, Warnungen, die Reaktionschronologie der Betreiber und die Erklärung der globalen Ausbreitung.
• Noctions Bereitstellungs-Checkliste, die kontinuierlichen Eindämmungssicherungen, das Alarmverhalten und die nach dem Vorfall vorgenommenen Produktänderungen.
• Der erste interne Erkennungszeitstempel von Cloudflare, die Alarmquelle, die in Betracht gezogenen Abhilfeentscheidungen, die Eskalationschronologie der Peering-Kontakte, die Auswirkungen auf Kunden nach Netzwerk und Region sowie die Verifizierung von Korrekturmaßnahmen.
• Die quantifizierten Servicegutschriften, Rückerstattungen, der Supportaufwand und die Kundenabwanderung, die spezifisch auf den Route-Leak im Juni zurückzuführen sind, und nicht auf den separaten Ausfall im Juli.

Ihre Abwesenheit macht das Ereignis nicht unerkennbar. Öffentliche BGP-Ankündigungen sind ein Beweis dafür, was Netzwerke einander gesagt haben. Verkehrsmessungen sind ein Beweis für die Auswirkungen auf den Dienst. SEC-Einreichungen sind ein Beweis für Unternehmensoffenlegung und erwartete Wesentlichkeit. Betreiber-Blogs sind ein Beweis für zugeschriebene Erklärungen. Die Disziplin besteht darin, diese Beweisklassen getrennt zu halten.

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

Ein tragfähiger Verantwortungsstandard für Routing-Resilienz

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

Das Ereignis war mit den damals verfügbaren Kontrollen vermeidbar. DQE hätte die 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-Nachweisen filtern können. Empfangende Netzwerke hätten die RPKI-ungültigen Cloudflare-Spezifischeren ablehnen können. Bessere Überwachung und Kontaktverfügbarkeit hätten das Ereignis verkürzen können. Spätere Standards erleichtern die Signalisierung bestimmter Beziehungsannahmen, aber sie verwandeln die operative Disziplin nicht in ein optionales, vererbtes Anliegen.

Cloudflares Rolle ist komplizierter als die eines Opfers oder Eigentümers. Es war das Ziel, dessen Erreichbarkeit durch externe Entscheidungen beeinträchtigt wurde. Es hatte bereits ROAs veröffentlicht, die die durchgestochenen Spezifischeren ablehnen würden, betrieb ein verteiltes Netzwerk, erkannte das Ereignis, koordinierte den Rückzug, erklärte die Routenaufzeichnung und legte die vertraglichen Konsequenzen offen. Es schuldete den Kunden dennoch einen klaren Status, Wiederherstellungsbemühungen, finanzielle Abhilfe, wo vertraglich vereinbart, und eine wahrheitsgemäße Darstellung des verbleibenden Routing-Risikos.

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

Der letztendliche Verantwortungsstandard 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 unter ihrer Kontrolle stehende Risiko reduziert, diese Reduzierung von außen getestet, den Explosionsradius unvermeidbarer Fehler begrenzt, über einen geübten Koordinationspfad reagiert und genügend Beweise produziert hat, damit Kunden und Aufsichtsbehörden die Verbesserung überprüfen können.

So sieht Netzwerk-Resilienz jenseits des Rands aus: nicht Unabhängigkeit von anderen Netzwerken – was das Internet unmöglich macht – sondern disziplinierte Grenzen dafür, wie viel ungeprüftes Vertrauen eine einzelne Route verbrauchen kann.