Zusammenfassung

  • Cloudflare berichtete, dass am 24. Juni 2019 gegen 10:30 UTC ein kleines Unternehmen über Verizon AS701 zu einem bevorzugten Pfad für viele Routen wurde; Cloudflare-Präfixe gehörten zu den betroffenen Ankündigungen [1].
  • Die spätere Cloudflare-Analyse stellte den Route-Optimizer-Pfad und die Weitergabe durch einen großen Transitprovider in den Mittelpunkt [2].
  • Noction reagierte öffentlich, weil sein Optimierungsprodukt Teil der Diskussion war; diese Antwort trennt Produktabsicht von Deployment-Governance [3].
  • ThousandEyes/Catchpoint beobachtete externe Erreichbarkeitseffekte für Cloudflare-Nutzer und verankerte die Schadensgrenze in Messungen [4].
  • RFC 7908 und RFC 9234 erklären, warum es um ein BGP-Beziehungsleck ging und warum explizite Rollen wie Only-to-Customer relevant sind [6][7].

Was geschah

Cloudflare beschrieb, dass viele Routen über Verizon zu einem kleinen Unternehmen als bevorzugtem Pfad liefen. In BGP ist das öffentliche Problem nicht nur, dass ein Netzwerk etwas ankündigt. Das Problem entsteht, wenn andere Netze diesen Pfad als nutzbar behandeln, bevorzugen und über die ursprüngliche Beziehung hinaus exportieren. Eine überraschende Ankündigung wird erst dann zum Internetereignis, wenn umliegende Netze sie akzeptieren.

DQE steht deshalb im Titel. Verizon war der große sichtbare Transitprovider, aber die Verantwortungsanalyse beginnt früher: bei der kundenseitigen Routenquelle, dem Route Optimizer und den Upstream-Akzeptanzregeln. Ein kleines Netz ist nicht automatisch harmlos. BGP führt Policies aus, nicht Unternehmensgrößen.

Warum es wichtig ist

Ein Routenleck kann einen gültigen Origin behalten und trotzdem die Beziehung in der Mitte des AS-Pfads verletzen. RPKI Origin Validation hilft bei falschen Origins, löst aber nicht jede Beziehungsverletzung. Erforderlich sind Beziehungsnachweise, Import- und Exportpolitik, Präfixgrenzen, AS-path-Filter, IRR/RPKI-Disziplin, Leak-Erkennung und Monitoring.

Öffentliche Quellen können zeigen, dass ein Routingereignis stattfand. Sie ersetzen keine internen Route Maps, Change-Tickets, Optimizer-Konfigurationen, Akzeptanzlogs oder Incident-Entscheidungen. Daher darf aus öffentlichen Quellen nicht auf Absicht von DQE, Noction oder Verizon geschlossen werden. Belegt ist enger: Die Akzeptanzkette war schwach genug, damit ein kundenseitiges Leak über einen großen Provider weitergetragen wurde.

Die technische Ebene

RFC 7908 beschreibt Routenlecks als Weitergabe, die gegen die beabsichtigte Beziehung zwischen Netzen verstößt. RFC 9234 zeigt mit BGP Roles und Only-to-Customer eine Reparaturrichtung: Rollen werden expliziter. Das repariert Altverbindungen nicht automatisch, macht aber verborgene Annahmen zu Protokollbeweisen.

Ein glaubwürdiger Abschluss müsste Präfixe, AS-Pfade, Beginn und Ende, Collector-Orte, betroffene Sessions, Import-/Exportfilter, Max-Prefix-Limits, IRR/RPKI-Grundlagen, Withdrawals und Wiederholungstests nennen. Ohne diese Angaben bleibt unklar, ob es nur Konvergenz, zu breite Policy oder ein ernster Betriebsfehler war.

Wer betroffen ist

Betroffen sind Nutzer und Netze, deren Betreiber den geleakten Pfad auswählten oder dadurch Latenz, Paketverlust oder Teil-Nichterreichbarkeit sahen. Öffentliche Berichte liefern keine vollständige Liste aller Transaktionen. Der Schaden muss daher über Dauer, Präfixe, Pfadauswahl, Messpunkte und Symptome bewertet werden.

Worauf zu achten ist

Zu beobachten sind Kundensessions, die plötzlich Routen außerhalb ihres normalen Sets exportieren, Optimizer-Ausgaben ohne Beziehungskontrolle, große Transitprovider mit abnormalen Kundenrouten und Incident-Berichte ohne Leak-Klasse, Dauer, Präfixset und Wiederholschutz.

Sources

  1. https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
  2. https://blog.cloudflare.com/the-deep-dive-into-how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-monday/
  3. https://www.noction.com/news/incident-response
  4. https://www.thousandeyes.com/blog/cloudflare-users-burned-by-internet-routing-pile-up
  5. https://www.kentik.com/blog/a-brief-history-of-the-internets-biggest-bgp-incidents/
  6. https://www.rfc-editor.org/rfc/rfc7908
  7. https://www.rfc-editor.org/rfc/rfc9234