Résumé

  • La fuite BGP du 25 août 2017 doit être lue comme un échec de politique d’export, d’import et de redistribution entre réseaux autonomes: Google a annoncé à Verizon un grand ensemble de routes apprises auprès de pairs, Verizon les a acceptées puis propagées, et des préfixes plus spécifiques ont attiré du trafic vers une trajectoire qui ne correspondait pas à un rôle de transit opérationnel.
  • Les preuves publiques permettent de reconstruire une chaîne de responsabilité, mais elles ne permettent pas de tout conclure: les totaux de préfixes varient selon ce qui est compté, la correction de configuration annoncée par Google en huit minutes ne se confond pas avec la convergence ni avec le rétablissement client, et les registres ou ROA ne remplacent pas des filtres BGP exécutés par les routeurs.

Le point de départ doit rester étroit. L’événement pertinent est celui du 25 août 2017, lorsque des routes apprises par Google dans des relations de peering ont été exportées vers Verizon, puis redistribuées au-delà de cette frontière. Ce n’est pas le même dossier que la fuite de routes impliquant MainOne en 2018, ni que la panne de plan de contrôle de Google Cloud en 2019, ni que l’incident BGP de Meta en 2021. Ce n’est pas non plus une explication globale de tout incident Internet japonais lié, de près ou de loin, à Google.

La thèse ici est plus précise: un réseau peut disposer de registres exacts, de relations commerciales définies et de communications de crise, mais la joignabilité réelle reste décidée par les routes acceptées, sélectionnées, annoncées et retirées par du code en service.

La chronologie publique impose déjà cette discipline. D’après le récit de l’Internet Society, Google a accidentellement divulgué des préfixes appris auprès de pairs et s’est comporté, dans l’effet réseau, comme un transit pour des destinations qui n’auraient pas dû être exportées ainsi. La même analyse décrit un épisode court, inférieur à dix minutes dans la fenêtre de fuite elle-même. Internet Watch Impress a rapporté la position de Google selon laquelle l’erreur de configuration avait été corrigée en huit minutes.

Ces deux formulations appartiennent au temps du contrôle initial: création de l’annonce, détection ou correction, et arrêt du mécanisme à l’origine de l’export. Elles ne prouvent pas, à elles seules, que toutes les tables de routage globales, tous les chemins de retour, tous les caches d’état et tous les services clients étaient revenus à un état stable au même instant.

Les opérateurs japonais donnent justement une autre horloge. NTT Communications a signalé une instabilité OCN de 12 h 22 à 12 h 45, heure du Japon, en l’associant à de grands changements de routes sur Internet et en indiquant que ses propres équipements OCN ne présentaient pas d’anomalie. KDDI a publié un avis concernant des clients d’accès Internet touchés, avec une fenêtre de rétablissement plus longue, se terminant à 16 h 47 pour certains utilisateurs selon l’avis. Ces durées ne doivent pas être fusionnées. Huit minutes pour une correction chez Google ne signifient pas vingt-trois minutes chez NTT, ni plusieurs heures chez KDDI.

Elles représentent des couches différentes: correction de configuration, retrait des annonces, propagation des retraits, convergence des chemins, stabilisation des réseaux d’accès, puis récupération perçue par les clients.

La variation des chiffres de préfixes a la même importance méthodologique. Le paquet factuel impose de ne pas transformer les estimations publiques en un total unique incontesté. L’Internet Society, les analyses de Doug Madory publiées sur CircleID, les reconstructions techniques japonaises et les rapports secondaires ne comptent pas nécessairement la même chose. Certains chiffres renvoient aux routes reçues, d’autres aux routes divulguées, propagées, plus spécifiques ou visibles depuis certains collecteurs.

Le dossier mentionne notamment des ordres de grandeur publics tels que 135 000 et 160 000, mais ces nombres ne doivent pas être posés comme deux versions d’un même compteur. Ils expriment plutôt l’écart entre observation, propagation et impact. Dans BGP, une annonce visible depuis un point de collecte n’est pas automatiquement installée partout, et une route absente d’un collecteur ne prouve pas qu’elle n’a été reçue nulle part.

La dynamique technique qui a rendu l’incident grave tient à la spécificité des préfixes. BGP ne choisit pas d’abord une route parce qu’un registre dit qu’une organisation « devrait » joindre une destination par tel voisin. Dans l’acheminement IP, la correspondance de préfixe le plus long donne à un préfixe plus spécifique un pouvoir d’attraction très concret. Si un réseau annonce un bloc plus spécifique que le chemin agrégé habituel, le trafic destiné à ce sous-ensemble peut suivre cette annonce même si le détenteur légitime du numéro n’a pas changé.

Dans l’incident de 2017, les analyses publiques décrivent des routes désagrégées qui ont rendu la fuite plus attirante. C’est ce mécanisme qui transforme une erreur d’export en problème de joignabilité: le trafic ne lit pas une note d’intention, il suit la meilleure route telle que les routeurs l’ont calculée.

Il faut préciser ce point, parce qu’il explique pourquoi une fuite relativement courte peut produire un effet disproportionné. La décision de transmission commence par la destination IP et par la route la plus spécifique disponible pour cette destination. Si une table contient un agrégat légitime et, en parallèle, un sous-préfixe plus spécifique annoncé par une trajectoire anormale, le sous-préfixe peut être retenu pour le trafic correspondant avant même que les attributs BGP des chemins moins spécifiques deviennent décisifs.

L’AS-path, la préférence locale ou d’autres attributs peuvent départager des routes concurrentes vers le même préfixe, mais ils ne neutralisent pas le principe de plus longue correspondance entre un agrégat et un sous-ensemble plus précis. La fuite décrite en 2017 a donc posé un risque qui n’était pas seulement quantitatif. Le danger ne venait pas seulement du nombre de routes, mais de la capacité de routes plus spécifiques à attirer des flux vers Google LLC alors que Google LLC n’était pas, pour ces destinations, le transit opérationnel attendu.

La chaîne causale doit donc être énoncée sans raccourci. Premièrement, Google a créé ou exporté des annonces inattendues. Deuxièmement, la frontière d’import de Verizon a accepté des routes qui, selon les analyses publiques, n’auraient pas dû être traitées comme des routes à redistribuer dans cette relation. Troisièmement, Verizon les a propagées plus loin, ce qui a donné à la fuite une portée supérieure à une simple erreur locale. Quatrièmement, les préfixes plus spécifiques ont attiré du trafic vers Google.

Cinquièmement, Google n’était pas en train d’assurer un transit effectif pour ces destinations; du trafic pouvait donc être perdu, mal dirigé ou subir des chemins instables. Sixièmement, le rétablissement n’a pas été instantané pour tous les réseaux concernés, car les retraits et la convergence se propagent dans un système interdomaines distribué.

Il faut également éviter un excès inverse: l’incident ne démontre pas que « tout le Japon » aurait été coupé d’Internet, ni que chaque pair de Verizon aurait accepté chaque route, ni que tous les services japonais auraient traversé un chemin identique. Les avis de NTT Communications et de KDDI sont de fortes preuves d’impact, parce qu’ils proviennent d’opérateurs concernés et donnent des fenêtres temporelles précises. Ils ne sont pas pour autant un recensement complet de tous les services, de toutes les pertes ou de tous les utilisateurs.

Des rapports secondaires ont cité d’autres entreprises ou services japonais, mais l’analyse de responsabilité doit conserver ce statut: des indices et observations publiques, pas une carte exhaustive du dommage.

Le cas de Verizon est indispensable, non parce qu’il faudrait attribuer à Verizon une intention ou un manquement juridique que les sources publiques ne prouvent pas, mais parce que la portée d’une fuite dépend de la frontière suivante. Une erreur d’export chez Google crée la route. Une politique d’import robuste chez le voisin peut la refuser, la limiter, l’isoler ou déclencher une alarme. Une politique d’export robuste chez ce même voisin peut empêcher qu’une anomalie importée soit réannoncée à d’autres. Dans ce dossier, les analyses publiques décrivent une acceptation et une propagation par Verizon.

C’est donc une question de contrôle opérationnel: quels filtres de routes clients, de pairs et de transit étaient appliqués, quels seuils de préfixes anormaux étaient configurés, quelles alertes étaient propriétaires, et quelle autorité pouvait interrompre la propagation ?

La distinction entre registre et politique exécutée est centrale. Les registres ASN et préfixes, les objets d’autorisation et les données de contact fournissent un grand livre de responsabilité: qui détient une ressource, quelle origine peut être attendue, quels contacts et quelles métadonnées permettent une enquête. Ils sont indispensables pour auditer et automatiser les filtres. Mais ils ne forcent pas un routeur à refuser une relation d’export incohérente. Un objet ROA peut aider la validation d’origine lorsqu’une route annonce une origine incompatible avec l’autorisation publiée.

Il ne suffit pas, en revanche, à détecter toutes les fuites de relation lorsque l’origine reste légitime mais que le chemin d’AS révèle un export hors périmètre. C’est pourquoi il serait inexact de conclure que RPKI ou la validation d’origine auraient, à eux seuls, empêché l’événement de 2017.

Les collecteurs publics de routes complètent ce tableau sans le fermer. RouteViews, BGPStream et des analyses indépendantes permettent de reconstruire des annonces vues par des pairs entités, d’établir des fenêtres temporelles et de comparer des chemins AS. Cette preuve est forte parce qu’elle est extérieure aux acteurs directs et qu’elle montre ce qui a réellement circulé dans certaines parties du système. Mais elle est partielle.

Elle ne révèle pas toutes les sessions privées, toutes les valeurs de préférence locale, tous les rejets de routes, toutes les configurations de routeurs, tous les paquets perdus ni tous les journaux d’approbation de changement. Voir une route ne prouve pas qu’elle a été installée partout; ne pas la voir ne prouve pas qu’elle n’a touché personne.

Le résultat est un dossier de responsabilité par couches. Google contrôlait son système de génération de routes, ses politiques d’export vers les pairs et voisins, la revue de changement, le retour arrière, la surveillance et la communication publique. Verizon contrôlait l’import, les limites de préfixes, la politique relationnelle entre client, pair et transit, la redistribution et l’escalade interne. Les opérateurs japonais contrôlaient leur surveillance locale, leur sélection de routes, leur communication client et leur stabilisation d’accès, sans contrôler la création initiale de routes interdomaines erronées.

Les détenteurs de ressources contrôlaient la publication de données et d’autorisations dans la mesure où ces mécanismes s’appliquaient. Les organisations de mesure contrôlaient la précision et les limites de leurs observations. Les utilisateurs finaux, eux, ne contrôlaient aucune de ces frontières BGP et ne peuvent pas devenir les responsables de prévention simplement parce qu’ils dépendent de la connectivité.

Cette lecture ne transforme pas BGP en système ingouvernable. Elle montre l’inverse: la gouvernance utile est celle qui devient une politique machine vérifiée contre la propagation réelle. Une relation de peering qui n’est pas censée servir de transit doit être encodée dans des filtres d’export et d’import. Une limite de préfixes doit bloquer ou au moins alerter lorsqu’un voisin annonce soudain un volume incompatible avec son rôle.

Une surveillance doit distinguer le moment où l’annonce anormale cesse d’être produite, le moment où elle disparaît des collecteurs, le moment où les opérateurs voient leur réseau stabilisé et le moment où les clients cessent de ressentir l’incident. Une communication de rétablissement ne peut être complète que si elle explique quelle horloge elle mesure.

La responsabilité, dans ce cas, n’est donc pas une accusation morale. Elle est une matrice de contrôles vérifiables: export filters chez l’annonceur, import filters chez le voisin, max-prefix controls aux frontières, route monitoring indépendant, rollback autorisé et testé, conservation de snapshots reçus et annoncés, corrélation entre collecteurs publics et RIB/FIB locales, puis preuves de récupération côté service. Plus ces preuves sont contemporaines, moins l’enquête dépend d’un récit reconstruit après coup.

L’incident de 2017 reste instructif précisément parce qu’il oblige à tenir ensemble le comportement du protocole, les limites de la preuve publique et les durées vécues par les opérateurs japonais.