Résumé

  • BGPMon a relié les difficultés d'accès à des services Google du 12 mars 2015 à une fuite de routes où des préfixes Google ont été appris par Hathway AS17488 puis transmis à Airtel AS9498 [1].
  • La fenêtre publique observée était courte, de 08:58 UTC à 09:14 UTC, mais BGPMon a indiqué que 336 préfixes IPv4 de Google étaient concernés [1].
  • RFC 7908 a ensuite cité la fuite Hathway-Airtel comme exemple de fuite de routes impliquant la propagation de préfixes de pair vers un fournisseur de transit [2].
  • Le bon périmètre de responsabilité reste étroit: pas d'intention malveillante présumée, pas de pertes inventées, mais une exigence de preuves sur les filtres clients, l'export, les alertes et les journaux retenus.

Ce qui s'est passé

BGPMon a décrit l'incident comme une interruption de services Google visible depuis des rapports d'utilisateurs et des données de routage. Son analyse a montré que beaucoup de chemins vers des préfixes Google ont changé entre 08:58 UTC et 09:14 UTC pour inclure Airtel AS9498 en Inde [1].

Le détail important est que les préfixes restaient originés par Google AS15169. Ce n'était donc pas un simple détournement d'origine où un autre réseau prétendait être Google. Le problème se situait au milieu du chemin: BGPMon a écrit que Google échangeait des routes avec Hathway AS17488, que Hathway a laissé sortir ces routes vers son fournisseur de transit Airtel AS9498, puis qu'Airtel a propagé les annonces à des pairs sur des points d'échange Internet [1].

Cette distinction est essentielle. Une origine BGP correcte peut coexister avec une mauvaise relation de transit. Un réseau peut apprendre une route pour une relation limitée, mais il ne devrait pas transformer cette route en chemin utilisable par des pairs ou fournisseurs qui n'étaient pas censés la recevoir.

Pourquoi cela compte

L'incident montre qu'une plateforme de taille Google peut subir les choix de routage d'opérateurs extérieurs. Google possédait les préfixes et les annonçait. Pourtant, si une route apprise auprès d'un pair ou d'un client est transmise à un fournisseur de transit, d'autres réseaux peuvent préférer ce chemin et déplacer l'impact vers les utilisateurs.

Cela transfère les coûts. Un filtre permissif peut sembler pratique dans une relation commerciale parce qu'il évite des exceptions manuelles. Mais il permet aussi à une erreur locale de déplacer les coûts de diagnostic, de support et de disponibilité vers des réseaux et utilisateurs qui ne participaient pas à cette relation.

L'événement rappelle aussi que la validation d'origine RPKI ne suffit pas. Si l'origine reste Google AS15169, une validation centrée uniquement sur l'origine peut passer alors que le chemin reste faux. La responsabilité porte ici sur la relation: qui a appris la route, qui pouvait l'exporter, qui l'a préférée et quelle preuve permet de bloquer la même classe d'erreur.

La couche technique

Le modèle le plus simple est celui d'un registre opérationnel des politiques de route. Un opérateur doit savoir quels préfixes chaque client, pair ou fournisseur peut envoyer, et vers quels voisins ces routes peuvent être exportées. Si un pair envoie une route, le réseau récepteur ne doit normalement pas la transformer en transit pour un autre pair ou fournisseur.

BGPMon a placé le chemin autour de Google AS15169, Hathway AS17488 et Airtel AS9498. Il a aussi indiqué qu'Airtel avait propagé les annonces à des pairs sur des points d'échange, et que certains réseaux pouvaient préférer des routes client à des routes de peering [1]. Le point de contrôle est donc à l'intersection de la préférence locale, de l'économie client/fournisseur et du filtrage anti-fuite.

Les preuves attendues sont concrètes: listes de préfixes autorisés, objets IRR/RPKI quand ils existent, classification de relation, route maps, limites de préfixes, marquage de provenance, alarmes de fuite, début et fin vus par les collecteurs, retraits, puis vérification post-réparation.

Qui est affecté

BGPMon a indiqué que les rapports touchaient surtout des utilisateurs européens et indiens, et RFC 7908 a parlé d'une interruption de services Google en Europe et en Asie [1][2]. Vice a utilisé l'événement pour expliquer comment le système mondial de routage peut transformer des choix de chemin en panne visible par les utilisateurs [3].

Ces sources justifient un cadrage en termes de joignabilité. Elles ne justifient pas des chiffres d'utilisateurs, des pertes financières ou une affirmation que chaque service Google était indisponible partout. La formulation prudente est que les observateurs publics ont relié l'événement à des problèmes de joignabilité Google, avec la preuve technique la plus forte dans les chemins AS et les préfixes.

Ce qu'il faut surveiller

Le premier signal est la capacité à nommer la classe de route qui a échoué: filtre de préfixes client, export de route de pair, préférence locale, objet de route, exception temporaire ou alarme manquée. Dire seulement que le routage est revenu à la normale ne prouve pas que le contrôle a changé.

Le deuxième signal est le déploiement de contrôles sensibles à la relation. RFC 7908 donne la définition du problème. Des mécanismes comme BGP Roles, Only-to-Customer et des approches ASPA vont dans la même direction: représenter le périmètre fournisseur/client/pair au lieu de dépendre de la mémoire opérationnelle.

Le troisième signal est la réconciliation entre collecteurs publics et télémétrie interne. Un événement visible pendant seize minutes doit pouvoir être comparé aux journaux de route, compteurs, alertes, rapports clients et messages de retrait.

Sources

[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/