Zusammenfassung

  • BGPMon verband die Google-Erreichbarkeitsprobleme vom 12. Maerz 2015 mit einem Route Leak, bei dem von Google stammende Praefixe von Hathway AS17488 gelernt und an Airtel AS9498 weitergegeben wurden [1].
  • Das oeffentlich beobachtete Zeitfenster war kurz, von 08:58 UTC bis 09:14 UTC, doch BGPMon nannte 336 betroffene Google-IPv4-Praefixe [1].
  • RFC 7908 fuehrte den Hathway-Airtel-Leak spaeter als Beispiel fuer die Weitergabe von Peer-Praefixen an einen Transit-Provider auf [2].
  • Der Artikel unterstellt keine boese Absicht und erfindet keine Nutzer- oder Verlustzahlen. Der verantwortliche Kontrollpunkt liegt bei Kundenfiltern, Beziehungsvalidierung, Exportregeln, Alarmen und beweisbarer Reparatur.

Was geschah

BGPMon beschrieb den Vorfall als Unterbrechung von Google-Diensten, sichtbar in Nutzerberichten und Routingdaten. Die Analyse zeigte, dass sich viele Pfade zu Google-Praefixen zwischen 08:58 UTC und 09:14 UTC aenderten und Airtel AS9498 in Indien enthielten [1].

Entscheidend ist, dass die Praefixe weiterhin von Google AS15169 originatierten. Es handelte sich also nicht um einen einfachen Origin-Hijack, bei dem ein anderes Netz vorgibt, Google zu sein. Das Problem lag in der Mitte des Pfades: BGPMon schrieb, dass Google mit Hathway AS17488 peerte, Hathway diese Routen an seinen Transit-Provider Airtel AS9498 leakte und Airtel die Ankuendigungen an Peers an Internet Exchanges weitergab [1].

Diese Unterscheidung bestimmt die Abhilfe. Ein korrekter Ursprung beweist keinen korrekten Beziehungspfad. Eine Route kann in einer begrenzten Beziehung gelernt werden, darf aber nicht automatisch als Transitroute fuer andere Peers oder Provider exportiert werden.

Warum es wichtig ist

Der Vorfall zeigt, dass selbst eine Plattform wie Google von Routingentscheidungen ausserhalb des eigenen Netzes betroffen sein kann. Google hielt und originatierte die Praefixe. Wenn jedoch eine in einer begrenzten Beziehung gelernte Route an einen Transit-Provider gelangt und andere Netze diesen Pfad bevorzugen, erleben Nutzer die Stoerung als Google-Erreichbarkeitsproblem.

Das ist auch eine Kostenverschiebung. Ein grosszuegiger Kundenfilter kann operativ bequem sein, weil er manuelle Ausnahmen reduziert. Wenn ein grosser Transit-Provider den Pfad aber verstaerkt, tragen unbeteiligte Netze und Nutzer die Kosten fuer Fehlersuche, Support und Verfuegbarkeit.

RPKI-Origin-Validation reicht hier nicht aus. Wenn der Ursprung Google AS15169 bleibt, kann eine nur am Ursprung orientierte Pruefung bestehen, obwohl der Pfad falsch ist. Verantwortung liegt dann in der Beziehung: wer die Route lernte, wer sie exportieren durfte, wer sie bevorzugte und welche Beweise die Wiederholung derselben Route-Klasse verhindern.

Die technische Ebene

Am einfachsten ist das als Routing-Policy-Ledger zu verstehen. Ein Betreiber muss wissen, welche Praefixe jeder Kunde, Peer oder Provider senden darf und zu welchen Nachbarn diese Routen exportiert werden duerfen. Eine von einem Peer gelernte Route sollte normalerweise nicht in Transit fuer einen anderen Peer oder Provider verwandelt werden. Eine Kundenroute muss gegen Praefixautorisierung, Route-Objekte, historische Pfade und ausdrueckliche Freigaben geprueft werden.

BGPMon ordnete den Pfad Google AS15169, Hathway AS17488 und Airtel AS9498 zu. Zudem schrieb BGPMon, Airtel habe die Ankuendigungen an Peers an Internet Exchanges weitergegeben; manche Netze koennten den Airtel-Pfad bevorzugt haben, weil Kundenrouten haeufig hoeher bewertet werden als Peering-Routen [1]. Die Kontrollflaeche liegt damit zwischen Local Preference, Kunden-Provider-Oekonomie und Exporthygiene.

Glaubwuerdige Reparaturbeweise waeren: autorisierte Praefixlisten, Route Maps, max-prefix-Grenzen, Beziehungstags, IRR/RPKI-Objekte, Leak-Alarme, first seen und last seen, Withdrawals und eine Nachpruefung durch oeffentliche Collector-Daten.

Wer betroffen war

BGPMon schrieb, Berichte haetten vor allem europaeische und indische Nutzer betroffen. RFC 7908 sprach allgemeiner von einer Unterbrechung von Google-Diensten in Europa und Asien [1][2]. Vice nutzte den Fall spaeter, um zu erklaeren, wie globale Routingentscheidungen zu nutzersichtbaren Ausfaellen werden koennen [3].

Diese Quellen tragen eine Erreichbarkeitsformulierung, aber keine erfundenen Nutzerzahlen, Entschaedigungen oder die Behauptung, alle Google-Dienste seien weltweit ausgefallen. Die staerkste oeffentliche Evidenz bleibt der AS-Pfad, die Praefixzahl und das Zeitfenster.

Worauf zu achten ist

Erstens muss der Betreiber die fehlgeschlagene Routenklasse benennen koennen: Kundenpraefixfilter, Peer-Route-Export, Local Preference, Route-Objekt, temporaere Ausnahme oder verpasster Alarm. Ein allgemeiner Hinweis auf ein behobenes Routingproblem beweist keine Kontrollaenderung.

Zweitens braucht es beziehungsbewusste Kontrollen. RFC 7908 definierte das Problem; BGP Roles, Only-to-Customer und ASPA-aehnliche Pfadautorisierung gehen in dieselbe Richtung, weil sie Provider-, Kunden- und Peer-Scope expliziter machen.

Drittens muessen oeffentliche Collector-Daten und interne Telemetrie zusammenpassen. Ein fuer sechzehn Minuten sichtbares Ereignis sollte mit BGP-Logs, Countern, Alarmen, Kundenmeldungen und Withdrawals abgleichbar sein.

Quellen

[1] BGPMon, "What caused the Google service interruption?", https://www.bgpmon.net/what-caused-the-google-service-interruption/

[2] RFC 7908, "Problem Definition and Classification of BGP Route Leaks," https://www.rfc-editor.org/rfc/rfc7908.txt

[3] Vice, "Anatomy of a Globe-Spanning Google Outage," https://www.vice.com/en/article/anatomy-of-a-globe-spanning-google-outage/