La fuite de route Google de 2018 a révélé le décalage entre les contrats de routage et le contrôle réel

Résumé

• Le 12 novembre 2018, des routes associées aux services Google ont été diffusées par le fournisseur nigérian MainOne vers China Telecom, puis propagées via d’autres fournisseurs, dirigeant une partie du trafic destiné à Google vers des chemins inattendus et rendant les services inaccessibles pour certains utilisateurs.
• Cet incident est distinct du détournement YouTube de Pakistan Telecom en 2008. Ici, le problème crucial de responsabilité n’était pas un bloc national exporté comme une route plus spécifique d’origine erronée; il s’agissait d’un décalage entre les contrats et le contrôle, où des routes apprises dans le cadre d’une relation se sont échappées vers d’autres.
• Les sources publiques confirment une erreur de configuration accidentelle plutôt que la preuve d’une compromission de contenu réussie. Google aurait déclaré que le trafic affecté était chiffré et qu’il n’y avait aucune raison de croire que les services aient été compromis, tandis que des observateurs indépendants considéraient le chemin de routage comme un risque sérieux pour la disponibilité et la surveillance.
• La validation d’origine RPKI n’est pas une réponse complète pour cette classe de défaillance, car les routes affectées pouvaient encore sembler provenir de l’AS légitime de Google. Les fuites de routes nécessitent un filtrage client et pair, des contrôles tenant compte des relations, des limites de préfixes, une surveillance, une coordination et des mécanismes ultérieurs tels que les rôles BGP.
• La leçon en matière de responsabilité est que les contrats commerciaux de peering et de transit ne s’appliquent pas d’eux-mêmes. Les opérateurs doivent convertir les relations commerciales en politiques de routeur et en contrôles vérifiables de l’extérieur avant qu’une fuite de route ne devienne une panne mondiale.

Registre des preuves et son utilisation

Cet article considère les sources publiques comme des preuves stratifiées. Les rapports d’incident, les normes, les mesures de navigateur ou de routage, les documents réglementaires ou politiques, ainsi que les directives actuelles des opérateurs sont utilisés pour différentes affirmations. Les sources émanant des entreprises sont attribuées en tant que positions de l’entreprise.

Les normes et les directives ultérieures sont utilisées pour expliquer les contrôles et présenter les attentes en matière de responsabilité, et non pour inventer des faits privés ou imposer rétroactivement des obligations ultérieures lorsque les sources publiques ne soutiennent pas cette affirmation.

L’incident portait sur des frontières que les routeurs ne pouvaient pas déduire

La fuite de route Google de 2018 peut facilement se résumer à une phrase familière: BGP est fragile. Cette phrase est vraie, mais pas assez précise. La leçon plus pointue est que l’Internet contient de nombreuses relations commerciales que les logiciels de routage ne peuvent pas déduire tant que les opérateurs ne les encodent pas. Un pair peut envoyer des routes qui devraient rester locales. Un fournisseur de transit peut recevoir des routes qui ne devraient jamais être acceptées de ce voisin. Une route peut conserver le bon AS d’origine tout en empruntant un chemin qui viole les attentes commerciales et opérationnelles.

Les comptes rendus de Cloudflare, ThousandEyes et l’Internet Society convergent sur la forme de base. MainOne disposait d’une connectivité vers Google via une relation de peering à Lagos. Des routes associées à Google se sont échappées de cette relation vers China Telecom. China Telecom les a propagées plus loin, et des chemins impliquant TransTelecom, NTT et d’autres réseaux sont apparus. Les utilisateurs tentant d’accéder aux services Google ont alors suivi des chemins qui n’avaient pas la capacité, la politique ou le filtrage attendu pour transporter ce trafic.

Une partie du trafic a été abandonnée et les services sont devenus inaccessibles pour certains utilisateurs.

Ce n’est pas le même mécanisme que le détournement YouTube de Pakistan Telecom. En 2008, Pakistan Telecom a annoncé une route plus spécifique pour l’espace d’adressage YouTube depuis un mauvais AS d’origine, et PCCW l’a propagée. En 2018, les analyses publiques importantes décrivent une fuite de route où les routes provenant de Google ont été propagées au-delà de la relation prévue. L’origine pouvait sembler légitime tandis que le chemin restait erroné. Cette distinction est importante car elle modifie les contrôles qui auraient été utiles. La validation d’origine peut rejeter une fausse origine.

Elle ne peut pas, à elle seule, prouver qu’une route d’origine correcte n’a traversé que des relations commerciales valides.

Le décalage entre les contrats et le contrôle est au cœur du problème de gouvernance. Un contrat de peering peut stipuler qu’une partie ne doit échanger que certaines routes ou ne pas fournir de transit. Un accord de transit peut définir des cônes clients et des règles d’exportation. Mais un routeur distant transférera en fonction des routes qu’il reçoit et de la politique qu’il est configuré pour appliquer. Si la politique est manquante, obsolète ou trop permissive, la frontière juridique ou commerciale devient décorative. Le paquet suit le plan de contrôle, pas le PDF du contrat.

C’est pourquoi l’événement relève de la gouvernance. La défaillance n’était pas une mystérieuse catastrophe naturelle. C’était un décalage entre la configuration technique, la relation commerciale, l’autorité sur les routes, la surveillance et l’escalade. Chaque organisation sur le chemin avait une vue opérationnelle plus étroite que l’effet mondial. MainOne pouvait mal configurer l’exportation. China Telecom pouvait accepter et propager. D’autres fournisseurs pouvaient préférer ou transmettre les chemins.

Google pouvait détecter, communiquer et protéger la confidentialité au niveau du service, mais il ne pouvait pas réécrire directement chaque politique d’importation externe.

Une origine correcte ne signifiait pas une route correcte

De nombreuses discussions sur la sécurité du routage commencent par les détournements, car les annonces d’origine erronée sont plus faciles à expliquer. Quelqu’un qui ne possède pas un préfixe dit, en substance, envoyez-moi ce trafic. La validation d’origine de route RPKI est conçue pour traiter cette classe: le détenteur de la ressource publie une autorisation d’origine de route (ROA), et les réseaux de validation peuvent rejeter les routes dont l’AS d’origine ou la longueur de préfixe ne correspond pas. Ce contrôle est important. L’événement Google de 2018 montre ses limites.

L’Internet Society a clairement souligné dans son analyse publique: dans ce scénario, les préfixes provenaient toujours légitimement du bon AS, il est donc difficile pour les réseaux intermédiaires de bloquer la fuite en utilisant uniquement la validation d’origine. La route pouvait avoir une origine valide tout en représentant une relation d’exportation non valide. C’est pourquoi une fuite de route n’est pas simplement un détournement avec un langage plus doux. C’est une défaillance relationnelle: les routes se propagent au-delà de leur portée prévue.

L’effet pratique peut être tout aussi grave pour les utilisateurs. Une route d’origine correcte qui transite par le mauvais fournisseur peut acheminer le trafic vers un réseau dont la capacité est insuffisante, le filtrage restrictif, les préoccupations de surveillance ou la mauvaise accessibilité. Les utilisateurs voient des délais d’attente. Les clients voient des services cloud interrompus. Les équipes d’intervention voient des traceroutes étranges à travers des pays et des fournisseurs auxquels ils ne s’attendaient pas. L’origine correcte ne les rassure pas si le chemin abandonne des paquets ou viole leurs hypothèses de risque.

Cette distinction devrait modifier les achats et la surveillance du conseil d’administration. Demander si un fournisseur dispose de RPKI est utile mais incomplet. Les acheteurs devraient également demander si le fournisseur filtre les routes des clients, rejette les routes incompatibles avec les relations commerciales, maintient des limites de préfixes, surveille les fuites, participe aux canaux de coordination et peut expliquer comment les routes de peering sont empêchées de devenir des routes de transit. Une réponse par oui/non sur la couverture RPKI ne peut remplacer un contrôle de route tenant compte des relations.

Des travaux techniques ultérieurs tels que BGP Roles et l’attribut Only-to-Customer tentent de rendre les relations commerciales visibles par le protocole de routage. Ces mécanismes n’étaient pas un contrôle universel achevé en 2018, et l’article ne les applique pas rétroactivement comme une norme obligatoire. Leur pertinence est explicative: ils existent parce que les opérateurs ont reconnu que de nombreuses fuites dommageables sont des défaillances de politique de chemin plutôt que des défaillances d’autorisation d’origine. L’industrie avait besoin de moyens pour rendre « cette route ne devrait pas passer par là » vérifiable par machine.

China Telecom a été l’amplificateur de propagation

MainOne apparaît dans les sources publiques comme la source de la fuite, mais l’événement est devenu mondialement significatif parce que d’autres fournisseurs ont accepté et propagé les routes. China Telecom est au centre des comptes rendus publics car il a reçu les routes Google divulguées et les a transmises. Ce rôle doit être décrit avec soin. Les sources publiques soutiennent un traitement de route accidentel ou erroné; elles ne prouvent pas une opération d’interception de trafic réussie. Mais l’intention n’est pas nécessaire pour la responsabilité.

Un fournisseur de transit peut causer des dommages majeurs en croyant une route de client ou de pair qu’il aurait dû filtrer.

Un fournisseur avec une portée mondiale a l’obligation à fort levier de savoir quelles routes un voisin est autorisé à annoncer et quelles routes doivent être exportées. Cela ne signifie pas que chaque décision de route soit simple. Les cônes clients changent, les pairs ont des arrangements complexes, les points d’échange Internet transportent des routes diverses et les données de registre peuvent être désordonnées. Pourtant, le devoir fondamental demeure: un grand fournisseur ne devrait pas traiter chaque route inattendue comme exportable mondialement simplement parce que la syntaxe BGP est valide.

Le filtrage doit également correspondre à la relation. Une route de pair ne devrait pas devenir une route de transit à moins que la relation ne le permette explicitement. Un client ne devrait pas pouvoir annoncer les routes d’une plateforme cloud géante à moins que ce client ne fournisse légitimement du transit pour cette plateforme.

Un fournisseur devrait appliquer des filtres de préfixes et de chemins AS, des limites de préfixes maximums, une génération de politique de route à partir de données fiables, une surveillance des changements soudains d’ensembles de routes importants et une escalade hors bande pour les annonces anormales de préfixes célèbres.

La visibilité publique du chemin de route a rendu le rôle de propagation difficile à ignorer. ThousandEyes a décrit des chemins passant par China Telecom et TransTelecom. Cloudflare a enregistré un routage inhabituel et un impact sur le service. Les reportages se sont concentrés sur le trafic transitant par la Chine et la Russie parce que ce chemin comportait des préoccupations politiques et de surveillance évidentes. Même si le trafic était chiffré et qu’il n’a pas été démontré qu’il était compromis, la route elle-même a sapé les attentes des clients quant à l’endroit où le trafic voyagerait et s’il resterait accessible.

C’est le point politique: un fournisseur qui exporte une route divulguée transforme l’erreur d’un autre réseau en événement mondial. La mauvaise configuration initiale compte, mais la propagation détermine le rayon de l’explosion. La responsabilité en matière de routage devrait donc mesurer la première mauvaise exportation et chaque point d’amplification majeur.

Google avait des devoirs de résilience mais pas un contrôle unilatéral

Google était l’opérateur de services affecté et l’une des parties ayant la plus grande capacité à détecter que quelque chose d’étrange se produisait avec le trafic destiné à Google. Il contrôlait également les protections au niveau applicatif qui comptaient. Les rapports publics indiquaient que Google avait déclaré que le trafic affecté était chiffré et qu’il n’y avait aucune raison de croire que les services aient été compromis. Cette distinction est importante. Le chiffrement peut réduire le risque de confidentialité même lorsque le routage emprunte un mauvais chemin.

Il ne résout pas le risque de disponibilité, mais il empêche que la fuite de route ne devienne automatiquement un événement prouvé d’exposition de données.

Les devoirs de Google dans un tel événement incluent la surveillance des routes, la publication de ROA, des objets IRR précis, l’escalade vers les fournisseurs, la communication avec les clients, l’ingénierie de trafic d’urgence et les preuves post-incident. Une plateforme de la taille de Google ne peut pas empêcher chaque fuite externe, mais elle peut réduire le temps de détection et de réparation. Elle peut également concevoir des services de manière qu’un détour de chemin n’expose pas silencieusement le contenu des utilisateurs.

Le chiffrement, l’hygiène des certificats, la redondance des services et la télémétrie réseau font tous partie de ce package de résilience.

En même temps, Google ne pouvait pas forcer unilatéralement MainOne ou China Telecom à appliquer la bonne politique d’importation et d’exportation. C’est pourquoi la responsabilité en matière de sécurité du routage devrait suivre la capacité de contrôle plutôt que la visibilité de la marque. Les utilisateurs ont subi les symptômes de panne de Google, et la marque Google a subi le choc de confiance publique. Mais la politique de routeur qui a accepté et exporté les routes divulguées se trouvait en dehors du réseau de Google.

La question de gouvernance est de savoir comment les contrats de Google, les accords de peering et les manuels d’escalade ont traité cette dépendance externe avant l’événement.

Un registre public plus solide de la part des plateformes affectées inclurait le temps de détection, le nombre de préfixes affectés, l’impact pour les clients, les changements de chemin observés, l’évaluation du chiffrement et de la confidentialité, les fournisseurs contactés, l’horodatage de la réparation et tout changement apporté à la surveillance des routes ou aux exigences des partenaires après l’incident. Certaines de ces preuves peuvent être sensibles lors d’un événement en direct, mais les résumés post-incident peuvent partager des catégories sans exposer les secrets défensifs.

Pour les clients, la leçon n’est pas de blâmer Google pour chaque route externe. Il s’agit de demander aux grands fournisseurs de cloud et de plateformes comment ils surveillent l’accessibilité mondiale, quelles routes sont autorisées, à quelle vitesse ils détectent les chemins suspects et quels engagements ils prennent lorsqu’une défaillance de routage par un tiers rend les services inaccessibles. La disponibilité ne s’arrête pas à la périphérie du fournisseur.

Les contrats ont besoin de contrôles exécutables

L’expression décalage contrat-contrôle capture un schéma de défaillance qui apparaît dans toute l’infrastructure Internet. Les parties peuvent avoir des contrats qui définissent qui est un pair, un client ou un fournisseur. Mais les routeurs appliquent la politique de route, pas l’intention juridique. Si la politique de route n’incarne pas la relation, le contrat devient un argument après les faits plutôt qu’un contrôle préventif. La fuite Google de 2018 a rendu cet écart visible pour les utilisateurs ordinaires parce que le changement de chemin a interrompu des services très visibles.

Les contrôles exécutables incluent des filtres de préfixes construits à partir d’ensembles de routes autorisés par le client, des filtres de chemins AS, des limites de routes, des politiques de session de pair, la validation d’origine RPKI, la détection des fuites de route, l’alerte pour les exportations soudaines de préfixes célèbres et des contacts d’urgence testés. Ils incluent également des contrôles de gouvernance: examen des modifications de la politique d’exportation, rapprochement périodique des ensembles de routes, examen des cônes clients, exercices d’incident et autorité documentée pour fermer rapidement une session qui fuit.

Les directives de MANRS, du NIST et de l’IETF rendent ces contrôles moins exotiques qu’ils ne l’étaient dans les époques antérieures. Le point n’est pas que chaque opérateur puisse éliminer chaque fuite demain. Le point est que le vocabulaire de contrôle existe. Un fournisseur qui vend une accessibilité mondiale devrait pouvoir expliquer comment il empêche une route de peering locale de devenir un transit mondial et comment il détecte la défaillance si la prévention échoue.

Les conseils d’administration devraient demander des preuves, pas des slogans. « Nous suivons les meilleures pratiques » ne suffit pas. Un tableau de bord utile montrerait la politique de validation RPKI, la couverture des filtres clients, la couverture explicite des politiques d’importation et d’exportation EBGP, les événements de préfixes maximums, les exceptions d’objets de route obsolètes, les alertes de fuite, les temps de réponse et les anomalies non résolues. Il distinguerait le rejet d’origine invalide des contrôles de fuite de chemin, car ce sont des classes de risque différentes.

L’essentiel est que la fuite de route Google de 2018 était un événement de responsabilité concernant la gouvernabilité des relations. L’erreur de MainOne a compté. La propagation de China Telecom a compté. L’acceptation par d’autres réseaux a compté. La résilience et la communication de Google ont compté. Le public a dû subir une défaillance de la politique de route comme une interruption de service. La leçon de réparation n’est pas seulement une meilleure hygiène BGP dans l’abstrait; c’est la conversion des contrats et des attentes en contrôles de route qui échouent de manière visible et se rétablissent rapidement.

Le chemin semblait politique parce que le chemin était opérationnellement erroné

La fuite de route Google de 2018 a attiré l’attention du public en partie parce que le trafic semblait transiter par la Chine et la Russie. Cette géographie importait aux utilisateurs et aux journalistes car elle soulevait des préoccupations de surveillance et de souveraineté. Elle illustre également une règle plus générale: lorsque les chemins de routage violent les attentes, l’espace d’explication s’élargit rapidement. Les utilisateurs ne savent pas s’ils sont confrontés à une congestion, une censure, un détournement, une fuite accidentelle, une surveillance, une attaque ou un optimiseur de routage défaillant.

Le compte rendu de l’opérateur doit donc être suffisamment précis pour séparer l’impact sur la disponibilité de la compromission de la confidentialité et l’accident de l’intention.

Les rapports publics ont conservé la position de Google selon laquelle le trafic affecté était chiffré et qu’il n’y avait aucune raison de croire que ses services aient été compromis. Cette déclaration était importante. Elle réduisait le risque qu’un détour de chemin soit automatiquement traité comme une violation de contenu. Mais le chiffrement n’a pas effacé le problème de disponibilité. Un utilisateur dont le trafic est chiffré mais abandonné ne peut toujours pas accéder au service. Une entreprise dont le service Google est inaccessible subit toujours une perturbation opérationnelle.

Une agence publique dont le chemin traverse désormais une juridiction inattendue peut encore avoir des préoccupations politiques même si la confidentialité de la charge utile est préservée.

Le chemin a également montré pourquoi les contrôles tenant compte des relations importent plus que les étiquettes nationales. Le rôle de China Telecom n’était pas problématique simplement parce que le réseau est chinois. Il était problématique parce que la route n’aurait apparemment pas dû être acceptée et propagée sous cette forme. Un autre grand fournisseur dans un autre pays aurait pu créer une panne similaire s’il avait accepté une route apprise d’un pair ou divulguée par un client qui violait la politique de route.

La norme de responsabilité devrait donc se concentrer sur les filtres, l’autorité des routes, la relation, la surveillance et les preuves de réparation, tout en reconnaissant que la géographie peut amplifier les préoccupations des utilisateurs.

Cette distinction permet d’éviter deux mauvaises lectures. Une mauvaise lecture traite l’événement comme une preuve d’interception malveillante sans preuve. L’autre le traite comme un accident inoffensif parce qu’aucune compromission de contenu n’a été prouvée. La bonne lecture se situe entre les deux: une fuite de route peut être accidentelle et néanmoins grave; le trafic chiffré peut rester confidentiel tout en étant indisponible; un fournisseur peut ne pas avoir d’intention malveillante et néanmoins manquer à un devoir de filtrage important. La gouvernance a besoin de ce vocabulaire intermédiaire.

Les optiques politiques montrent également pourquoi une communication publique rapide est importante. En l’absence d’explication de l’opérateur, les traceroutes et les chemins BGP deviennent matière à spéculation. Les plateformes affectées devraient communiquer ce qui est connu sur le chemin, ce qui est connu sur le chiffrement, ce qui reste inconnu, ce qui a été corrigé et quelles parties contrôlaient les politiques de route défaillantes. Ce n’est pas seulement de la gestion de réputation.

C’est une façon d’empêcher les utilisateurs de confondre chaque route étrange avec une violation confirmée tout en traitant la disponibilité et l’intégrité du routage comme des risques réels.

Le peering et le transit sont des relations commerciales aux dents techniques

Le peering et le transit sont souvent résumés comme des arrangements commerciaux: les pairs échangent du trafic pour un bénéfice mutuel, tandis que les fournisseurs de transit vendent l’accessibilité à l’Internet plus large. La fuite Google montre pourquoi ces termes ont besoin de dents techniques. Une route apprise d’un pair ne devrait pas être automatiquement exportée comme s’il s’agissait d’une route client. Une route client ne devrait pas être automatiquement crue comme si le client était autorisé à transiter une plateforme mondiale.

Une route acceptée dans le cadre d’une relation devrait porter des contraintes politiques lorsqu’elle franchit une autre frontière.

Cette correspondance doit être mise en œuvre dans la configuration des routeurs et les systèmes de validation. Elle inclut une politique d’importation explicite pour ce qu’un voisin peut envoyer, une politique d’exportation explicite pour où ces routes peuvent aller, des filtres de préfixes et de chemins AS, des limites de routes, la validation d’origine RPKI le cas échéant, des balises de relation, une surveillance de l’expansion soudaine des ensembles de routes et une autorité d’arrêt d’urgence. Le mot important est explicite.

Les valeurs par défaut, les suppositions et les connaissances tribales ne suffisent pas lorsqu’une erreur de configuration peut rendre Google inaccessible.

Le principe de rejet par défaut de la RFC 8212 reflète la même philosophie: les sessions BGP externes ne devraient pas ou exporter des routes sans politique explicite. Cela n’empêche pas chaque erreur. Une mauvaise politique explicite peut encore divulguer des routes. Mais elle élimine l’hypothèse la plus dangereuse selon laquelle une session non configurée ou sous-configurée devrait se propager par défaut. En langage de gouvernance, le rejet par défaut oblige les opérateurs à énoncer leur intention de routage avant que le plan de contrôle n’agisse.

Les contrats devraient suivre la même logique. Un accord de peering ou un contrat de transit ne devrait pas seulement dire ce que les parties ont l’intention de faire; il devrait exiger des preuves que l’intention est appliquée. Chaque partie maintient-elle des filtres de route? Comment les ensembles de préfixes clients sont-ils générés? À quelle fréquence sont-ils examinés? Que se passe-t-il lorsqu’un voisin divulgue des préfixes célèbres? Qui a le pouvoir d’arrêter une session? Quel avis public ou client suit? Ces clauses ne sont pas un excès juridique exotique.

Elles sont la traduction du préjudice de routage en obligations opérationnelles.

Les clients devraient s’en soucier même s’ils ne sont pas opérateurs de réseau. Un acheteur SaaS, une banque, un éditeur ou une agence gouvernementale peut dépendre d’un fournisseur dont l’accessibilité dépend des relations de transit. L’acheteur ne peut pas auditer chaque route mondiale, mais il peut demander à ses fournisseurs critiques comment ils surveillent l’accessibilité, comment ils utilisent RPKI, comment ils se protègent contre les fuites de route et comment ils informent les clients lorsqu’une défaillance de route externe affecte le service.

Un accord de niveau de service qui exclut les « problèmes de routage Internet » peut décrire l’allocation juridique, mais il ne fait pas disparaître la dépendance opérationnelle.

Pourquoi la validation d’origine avait toujours sa place dans la discussion

Parce que l’événement Google de 2018 était une fuite de route plutôt qu’un simple détournement d’origine erronée, certains lecteurs pourraient conclure que RPKI n’est pas pertinent. Ce serait la mauvaise leçon. La validation d’origine RPKI n’était pas un contrôle complet pour la fuite, mais elle fait toujours partie de la pile de responsabilité. Elle aide à distinguer une classe de fausse autorité d’une autre, réduit le niveau de fond des mauvaises routes et donne aux opérateurs des preuves lisibles par machine pour de nombreux incidents qui dépendraient autrement de la confiance manuelle.

La limite est précise. Si la route provient toujours de l’AS Google autorisé, le composant d’origine peut valider tandis que le chemin reste inacceptable. Dans ce cas, RPKI dit que l’origine est autorisée, pas que MainOne, China Telecom, TransTelecom, NTT ou tout autre segment de chemin devrait transporter la route dans cette relation. La validation de chemin et la prévention des fuites de route nécessitent des contrôles supplémentaires. C’est pourquoi la RFC 9234 et les mécanismes tenant compte des relations sont importants. Ils traitent une partie différente du problème de confiance.

La validation d’origine peut encore aider lors de la réponse aux incidents. Si une route suspecte est d’origine invalide, les opérateurs peuvent la rejeter ou l’escaler comme probablement non autorisée. Si elle est d’origine valide mais de chemin suspect, ils peuvent classer l’incident comme une fuite ou une défaillance de politique de chemin. Cette classification affecte qui appeler et quelles preuves inspecter. Une opération de sécurité de routage mature ne demande pas à RPKI de répondre à chaque question; elle utilise RPKI pour lever l’ambiguïté là où elle le peut, puis applique des vérifications supplémentaires de politique de route.

RPKI modifie également les incitations autour de la documentation. Une plateforme comme Google devrait maintenir des ROA précis, mais elle devrait aussi maintenir des objets de route, des politiques de pair, des contacts de fournisseur et une surveillance externe. Un fournisseur comme China Telecom devrait valider les origines mais aussi filtrer en fonction de la relation. Un pair comme MainOne devrait empêcher les routes apprises des pairs de fuir dans le transit. Les contrôles se complètent plutôt que de se remplacer mutuellement.

Le lecteur devrait donc retenir un modèle en couches. RPKI gère l’autorité d’origine. Les filtres de préfixes et de chemins AS gèrent l’autorité attendue des clients et des pairs. BGP Roles et OTC peuvent encoder la direction de la relation. La surveillance détecte les écarts. La coordination humaine répare ce que l’automatisation ne peut pas décider en toute sécurité. Le langage contractuel et les métriques de gouvernance maintiennent les couches. L’événement Google a exposé une lacune dans ce modèle en couches, pas la futilité de le construire.

Un meilleur registre public de réparation aurait séparé chaque point de contrôle

Un registre post-incident utile pour la fuite de 2018 identifierait chaque point de contrôle sur le chemin. Chez MainOne, le registre expliquerait quel ensemble de routes a été appris de Google, quelle politique aurait dû empêcher l’exportation, ce qui a changé, quand la fuite a commencé, quand elle a été détectée et comment elle a été corrigée. Chez China Telecom, il expliquerait pourquoi la route divulguée a été acceptée, si des filtres clients ou pairs existaient, si les limites de routes se sont déclenchées et quand l’exportation a cessé. Chez les fournisseurs en aval, il expliquerait quels chemins ont été sélectionnés et pourquoi.

Pour Google, le registre couvrirait l’impact pour les clients, les services affectés, l’évaluation du chiffrement et de la compromission, le calendrier de détection, l’escalade vers les fournisseurs, la surveillance des routes, toute ingénierie de trafic d’urgence et les changements post-événement apportés aux exigences de peering. Pour les observateurs indépendants, les preuves des collecteurs de routes pourraient montrer la propagation et le retrait. Pour les clients, un résumé concis pourrait distinguer la perte de disponibilité des preuves d’exposition des données.

Ces registres séparés permettraient à chaque partie de posséder sa surface de contrôle sans forcer la déclaration d’un acteur à expliquer tout l’Internet.

Le registre public est partiellement disponible via des analyses indépendantes, mais le registre de réparation interne reste mince. C’est courant dans les incidents de routage. Les opérateurs corrigent souvent la route et passent à autre chose. Le problème est que les incidents de routage ne sont des occasions d’apprentissage que si la défaillance de contrôle est décrite au niveau où elle peut être réparée. « Mauvaise configuration » ne suffit pas. Quelle politique? Quelle session? Quel ensemble de routes? Quelle relation de voisinage? Quelle alerte? Quelle autorité pour retirer?

Sans ces réponses, la même défaillance peut se répéter avec un préfixe différent et une plateforme différente.

Les régulateurs et les grands acheteurs ne devraient pas exiger que chaque opérateur publie une configuration de routeur sensible. Ils peuvent exiger des plans de sécurité du routage et des catégories de preuves. Par exemple: couverture des filtres de préfixes clients, politique de validation RPKI, alerte de fuite de route, couverture explicite de la politique EBGP, exceptions de préfixes maximums, taux de succès des contacts d’urgence et résumés post-incident. Ces métriques sont suffisamment pratiques pour être auditées sans exposer chaque ligne de routeur.

La fuite Google de 2018 reste utile parce qu’elle rend visible le décalage contrat-contrôle. Il ne suffisait pas que les relations commerciales impliquent que la route ne devait pas passer par là. Les routeurs avaient besoin d’une politique applicable. La surveillance devait voir l’écart. Les humains avaient besoin de contacts joignables. Le public avait besoin de preuves que la fuite était contenue et que le chiffrement limitait le risque de confidentialité. C’est la pile de gouvernance que l’incident a exposée.

La décision du lecteur pour les contrats de routage

Un lecteur devrait repartir de la fuite de route Google de 2018 avec une question d’approvisionnement et de gouvernance: nos fournisseurs critiques traduisent-ils les relations de routage en contrôles que nous pouvons mesurer? Une fuite de route ne se soucie pas qu’un contrat étiquette un voisin comme pair ou client. Elle se soucie de savoir si la politique du routeur empêche la mauvaise exportation et si la surveillance détecte la fuite lorsque la politique échoue.

Les clients devraient donc demander aux fournisseurs des preuves de filtrage des préfixes clients, de politiques explicites d’importation et d’exportation EBGP, de validation RPKI, d’alerte de fuite de route et de contacts d’escalade 24 heures sur 24.

Pour les plateformes, la décision est de traiter le routage externe comme faisant partie de la résilience du service. Un fournisseur peut posséder d’excellents centres de données, un TLS solide et des applications renforcées tout en devenant inaccessible si des réseaux distants préfèrent un chemin divulgué. Cela signifie que la surveillance mondiale des routes, les exercices d’escalade vers les fournisseurs, l’hygiène des ROA, l’hygiène des objets de route et la communication avec les clients doivent se situer à proximité de l’ingénierie de disponibilité ordinaire.

« L’Internet a cassé en dehors de notre périphérie » peut être descriptivement vrai, mais les clients ont toujours besoin de preuves de détection, de diagnostic et de réparation.

Pour les fournisseurs de transit, la décision est de prouver le filtrage avant qu’une fuite de route célèbre ne rende le problème public. Une session client ou pair ne devrait pas être autorisée à devenir un chemin de transit surprise pour Google, une banque, un service gouvernemental ou un CDN. Le fournisseur devrait connaître les ensembles de routes attendus, rejeter les annonces improbables, alerter en cas d’expansion soudaine et conserver suffisamment de journaux pour expliquer la réparation. La valeur de la portée mondiale s’accompagne du devoir de ne pas mondialiser l’erreur d’une autre partie.

Pour les conseils d’administration et les régulateurs, la leçon est d’exiger des métriques de sécurité du routage de la même manière qu’ils exigent des métriques cybernétiques. Le taux de rejet RPKI invalide, la couverture des filtres clients, la couverture explicite des politiques, les alertes de fuite, les objets de route obsolètes, les incidents de préfixes maximums et le temps de réponse des contacts sont des signaux de gouvernance. Ce ne sont pas des secrets de paquets profonds. Ce sont des preuves que les frontières relationnelles ont une application technique.

L’événement de 2018 reste utile parce qu’il refuse de s’adapter à un seul contrôle. RPKI compte, mais la validation d’origine seule n’était pas suffisante. Les contrats comptent, mais ils ne s’appliquaient pas d’eux-mêmes. Le chiffrement comptait, mais il n’a pas rétabli l’accessibilité. La réparation nécessitait toute la pile: politique de route, surveillance, coordination, communication avec les clients et preuves publiques.

Un test opérationnel final consiste à se demander si la prochaine fuite de route serait d’abord remarquée par les clients, des chercheurs extérieurs ou les réseaux qui la transportent. Si les utilisateurs externes sont le principal détecteur, le système contrat-contrôle est trop faible. Les fournisseurs devraient pouvoir voir quand un pair semble soudainement transiter un réseau hyperscale, quand un client exporte un ensemble de routes en dehors de son autorité et quand les chemins de trafic contredisent les relations commerciales. Cette visibilité transforme les contrats de routage de la paperasse en infrastructure applicable.

Le même test s’applique dans l’approvisionnement des fournisseurs de cloud et de contenu. Un acheteur peut ne pas exécuter BGP à l’échelle mondiale, mais il peut demander si son fournisseur surveille les fuites de route, valide les origines, publie des contacts de sécurité de routage, répète l’escalade vers les fournisseurs et peut expliquer si le trafic était simplement indisponible ou également exposé à un risque de chemin. Ces réponses ne sont pas des anecdotes réseau abstraites. Elles façonnent la continuité des revenus, le support client, l’assurance de confidentialité et l’accès du secteur public.

L’incident Google/MainOne est donc un rappel que les propriétaires d’applications héritent d’une certaine dépendance au routage, que leurs équipes touchent ou non à la politique de routeur. La responsabilité commence lorsque cette dépendance héritée est nommée, mesurée et attribuée à un propriétaire de contrôle au lieu d’être traitée comme la météo inconnaissable de l’Internet.

Ce propriétaire devrait également contrôler le langage utilisé pendant une panne. Les fuites de route peuvent ressembler à des anecdotes de transporteur distant, mais la question du client est immédiate: les utilisateurs peuvent-ils accéder au service, le chemin est-il digne de confiance, qu’est-ce qui a changé et quand sera-t-il de nouveau normal? Une note d’incident solide distingue la perte d’accessibilité, le chemin de transit inattendu, l’état du chiffrement, la compromission suspectée et la remédiation. Le registre Google montre pourquoi ces distinctions comptent.

La réassurance que le trafic était chiffré est importante, mais elle ne répond pas à la question de disponibilité. Un retrait de route peut rétablir le service, mais il n’explique pas quelle relation a échoué. Une bonne communication maintient ces surfaces de contrôle suffisamment séparées pour que les acheteurs, les utilisateurs et les opérateurs puissent apprendre de l’événement.

Typographie

L’essentiel

La norme de responsabilité est un contrôle pratique associé à des preuves publiques. Le registre le plus solide ne prétend pas que chaque acteur contrôlait chaque résultat. Il identifie qui pouvait prévenir la défaillance, qui pouvait la détecter, qui pouvait limiter le rayon de l’explosion, qui pouvait notifier les parties affectées, qui pouvait réparer la relation de confiance, et quelles preuves attestent que la réparation a atteint les systèmes et les personnes qui en dépendaient.