Cloudflare, la fuite de route de juin 2019 et la responsabilité au-delà de la périphérie du réseau

Résumé

• Le 24 juin 2019, des routes optimisées et plus spécifiques générées à l’intérieur du réseau de DQE Communications ont traversé le client AS396531 et ont été acceptées par l’AS701 de Verizon. Verizon a ensuite propagé des chemins couvrant des milliers de réseaux. Parce que les routeurs préfèrent un préfixe de destination plus spécifique, un trafic substantiel a suivi les chemins divulgués vers des liaisons qui n’étaient pas dimensionnées pour le supporter; Cloudflare a signalé avoir perdu environ 15 % de son trafic mondial au pire moment de l’incident.
• Les enregistrements publics de routage font apparaître une chaîne de défaillances de contrôle, plutôt qu’un slogan à cause unique. Le générateur de routes n’a pas conservé ses routes d’optimisation en local, un client multi-domicilié a exporté des routes apprises d’un fournisseur vers un autre fournisseur, et un grand réseau de transit a accepté et propagé des routes qui ne correspondaient pas à l’autorité de routage attendue du client. Cloudflare a pu détecter, communiquer et aider à retirer les routes, mais il n’a pas pu modifier unilatéralement la politique d’importation d’un autre réseau.
• La validation d’origine de route RPKI était exceptionnellement adaptée à la partie Cloudflare de cet événement, car les autorisations d’origine de route de Cloudflare n’autorisaient ses préfixes agrégés que jusqu’à une longueur maximale déclarée. Les routes plus spécifiques divulguées dépassaient cette longueur et étaient donc invalides. Cela ne fait pas du RPKI une solution complète aux fuites de routes: des chemins valides à l’origine peuvent encore violer les relations commerciales, ce qui explique pourquoi le filtrage client, les limites de préfixes, les rôles BGP, les contrôles de chemin, la surveillance et des contacts opérationnels joignables restent nécessaires.
• La responsabilité suit la capacité de contrôle. Les opérateurs qui génèrent ou exportent des routes exceptionnelles doivent les contenir et les tester; les fournisseurs doivent vérifier ce que les clients peuvent annoncer; les plateformes cloud doivent publier l’autorité de routage, observer les chemins externes, se coordonner rapidement et divulguer l’impact client; les clients doivent planifier les défaillances de dépendance; et les conseils d’administration et les régulateurs doivent exiger une assurance mesurée de la sécurité du routage plutôt qu’une déclaration générique indiquant que les meilleures pratiques du secteur sont suivies.

Une panne de routage, pas une défaillance des serveurs de Cloudflare

À 10 h 34 min 25 s UTC le 24 juin 2019, les collecteurs BGP publics ont commencé à enregistrer des routes anormales et plus spécifiques pour l’espace d’adressage de Cloudflare. La dernière des routes Cloudflare étudiées a disparu à 12 h 38 min 54 s UTC. L’analyse approfondie des routes archivéesde Cloudflare reconstitue cet intervalle à partir des données du RIPE NCC et montre un chemin remarquablement cohérent: l’AS13335 de Cloudflare, l’un de ses fournisseurs de transit, l’AS33154 de DQE Communications, l’AS396531 d’Allegheny Technologies et l’AS701 de Verizon. D’autres réseaux ont ensuite appris la route via Verizon.

Ce chemin est important car la panne n’a pas commencé par une défaillance d’un centre de données Cloudflare ou un déploiement d’application. Les machines de Cloudflare ont continué d’annoncer leurs routes agrégées habituelles. Le système de routage mondial a simplement appris des routes concurrentes pour des fragments plus petits du même espace d’adressage. Ces fragments plus petits ont emporté la décision de transfert dans de nombreux réseaux et ont dirigé les paquets le long d’un chemin non prévu. La congestion et la perte de paquets ont suivi avant que les requêtes n’atteignent la périphérie de Cloudflare.

L’explication de l’incidentfournie par Cloudflare à l’époque indiquait qu’environ 15 % de son trafic mondial avait été perdu au plus fort de l’incident. Il s’agit d’une mesure interne à l’entreprise, et non d’un pourcentage de panne universel vérifié de manière indépendante. Elle décrit le trafic de Cloudflare, et non 15 % de l’Internet tout entier. Des observations indépendantes confirment néanmoins le mécanisme général et l’impact transversal. ThousandEyes a rapporté dans sonanalyse des chemins réseauque les utilisateurs ont rencontré des difficultés pour accéder aux services frontés par Cloudflare et à certains services AWS pendant environ deux heures, tandis que l’examen de l’incidentde Catchpoint a enregistré des problèmes de performance sur plusieurs services en ligne nommés aux alentours de 10 h 30 UTC.

La distinction entre disponibilité des routes et disponibilité des serveurs importe pour la responsabilité. Une plateforme peut faire fonctionner des serveurs en bon état dans de nombreux pays et rester inaccessible si le plan de contrôle de routage dirige le trafic ailleurs. Les clients subissent un seul résultat: délais d’attente, erreurs et applications indisponibles. La cause technique détermine toutefois quels contrôles auraient pu empêcher la perte et quelle partie aurait pu les actionner.

L’enregistrement d’état de Cloudflare pour l’événementa d’abord décrit des problèmes de performance réseau, puis a identifié une possible fuite de route, et a ensuite indiqué que le réseau responsable l’avait corrigée. Les copies publiques des mises à jour de statut situent l’avis d’enquête à 11 h 02 UTC, l’identification à 11 h 36 UTC et la surveillance après correction à 12 h 42 UTC. L’archive BGP montre des routes anormales avant le premier avis de statut. Cette différence ne prouve pas que Cloudflare a ignoré un événement connu pendant 28 minutes. C’est une question de responsabilité utile: quand les systèmes automatisés ont-ils détecté un trafic anormal, quand les ingénieurs ont-ils identifié le routage externe comme en étant la cause, et quand l’entreprise a-t-elle eu suffisamment confiance pour informer les clients?

Aucune preuve publique ne montre une intention malveillante, une inspection du trafic ou une compromission des systèmes de Cloudflare lors de cet événement. Une fuite de route peut créer une opportunité d’interception, mais le préjudice de service observé ici était la congestion et la perte le long d’un chemin non prévu. L’article traite donc l’incident comme une défaillance de disponibilité et d’intégrité de routage. Il ne convertit pas une propriété de sécurité possible des fuites de route en une allégation selon laquelle le trafic aurait été lu.

Comment une optimisation locale est devenue une route mondiale

L’Internet est un accord entre systèmes autonomes plutôt qu’un réseau commandé centralement. Chaque système autonome utilise le protocole Border Gateway, ou BGP, pour indiquer aux systèmes voisins quels préfixes IP il peut atteindre et par quel chemin AS. Le protocole de base dans laRFC 4271donne aux opérateurs une liberté de politique considérable. Cette flexibilité prend en charge le peering commercial, le transit payant, le multi-domiciliation, l’ingénierie de trafic et les préférences locales. Cela signifie également qu’une route reçue d’un voisin ne s’accompagne pas d’une preuve universelle que chaque AS du chemin souhaitait que l’annonce voyage aussi loin.

Avant l’incident, DQE utilisait un produit d’optimisation BGP de Noction. Un tel produit peut mesurer les performances des chemins et injecter des routes plus spécifiques pour influencer la liaison qui transporte le trafic sélectionné. Dans l’exemple publié par Cloudflare, l’annonce normale104.20.0.0/20était divisée en104.20.0.0/21et104.20.8.0/21. Les deux /21 couvrent la même plage d’adresses que le /20, mais chacun nomme un bloc de destination plus petit.

À l’intérieur d’un réseau contrôlé, les routes plus spécifiques peuvent être un instrument légitime d’ingénierie de trafic. Le danger est la portée. Les routes étaient destinées à influencer les décisions internes de DQE. DQE les a annoncées à AS396531. AS396531 était connecté à la fois à DQE et à Verizon, et a exporté les routes apprises vers Verizon. Verizon les a acceptées de son client et les a propagées plus loin. Une instruction locale était devenue une revendication mondiale.

Laréponse à l’incident de Noction du 26 juina reconnu que sa plateforme avait généré les routes plus spécifiques et décrit trois conditions aggravantes: la génération à l’intérieur du réseau de son client, la fuite via un ASN en aval vers un grand fournisseur et un filtrage inadéquat au niveau des trois systèmes autonomes. Noction a fait valoir que la création de routes plus spécifiques est une pratique courante plutôt qu’un défaut inhérent, et a souligné le filtrage par les fournisseurs. Cette réponse est pertinente car elle confirme le rôle de l’optimiseur tout en contestant un récit à partie unique. Il ne s’agit pas d’un post-mortem indépendant, et elle ne publie pas la configuration précise, l’enregistrement des modifications ni les preuves de test pour le déploiement de DQE.

L’analyse de routage distincte de Qrator Labsa associé le début à la restauration de la session BGP entre AS396531 et Verizon peu après 10 h 35 UTC. Son compte indique qu’AS396531 avait perdu ses filtres et exporté les routes apprises de DQE. Cela fournit un déclencheur plausible pour expliquer pourquoi la condition a commencé à ce moment-là, mais les archives publiques disponibles ne contiennent pas les configurations de routeurs ni les journaux d’AS396531, de DQE ou de Verizon. La conclusion prudente est plus étroite: le chemin observable prouve que des routes ont franchi ces frontières AS; les récits des opérateurs identifient des filtres manquants ou inadéquats; la séquence exacte des changements internes reste non publique.

Cette distinction évite trois erreurs fréquentes. Premièrement, DQE ne doit pas être décrit comme l’origine de l’espace d’adressage de Cloudflare au sens BGP. Le chemin AS observé se terminait bien à l’AS13335 de Cloudflare. L’optimiseur de DQE a créé et propagé un chemin plus spécifique en conservant l’origine légitime. Deuxièmement, Verizon n’a pas inventé les routes, mais son acceptation et sa propagation mondiale ont considérablement élargi leur portée. Troisièmement, le réseau de Cloudflare n’a pas choisi AS396531 comme chemin préféré. Les réseaux distants ont pris des décisions de transfert sur la base des annonces qu’ils ont reçues.

Pourquoi les routes plus spécifiques ont battu la distance et l’anycast

Pour un non-spécialiste, l’événement peut donner l’impression que les routeurs ont sélectionné un chemin AS plus court. La préférence décisive est intervenue plus tôt. Le transfert Internet utilise la correspondance du préfixe le plus long: une route couvrant le bloc de destination le plus spécifique est sélectionnée par rapport à une route couvrant un bloc plus large. LaRFC 4632, la spécification de routage inter-domaine sans classe, décrit ce comportement de correspondance la plus longue et sa relation avec les routes agrégées et plus spécifiques.

Supposons qu’un routeur sache que le104.20.0.0/20de Cloudflare est joignable via un fournisseur normal et apprenne également le104.20.0.0/21via Verizon, AS396531 et DQE. Une destination située dans le premier /21 correspond aux deux annonces. Le /21 est plus spécifique, donc il l’emporte même si son chemin AS est plus long ou opérationnellement absurde. Les attributs de chemin normaux départagent les routes vers le même préfixe; ils ne permettent pas à un /20 sain de vaincre un /21 accepté.

C’est pourquoi l’empreinte anycast de Cloudflare n’a pas automatiquement contourné le problème. L’anycast permet à de nombreux emplacements Cloudflare d’annoncer les mêmes préfixes, laissant BGP sélectionner une instance appropriée. Il offre une distribution géographique et peut absorber la défaillance de sites ou de liaisons individuels. Mais les /21 divulgués étaient plus spécifiques que les annonces /20 ordinaires de Cloudflare. Le système de routage mondial pouvait préférer le /21 avant de comparer quel emplacement anycast Cloudflare était le plus proche. La redondance derrière la route perdante n’a pas rétabli le trafic.

Le chemin non désiré a également concentré la charge. AS396531 et ses connexions n’étaient pas provisionnés comme transit mondial pour Cloudflare, Amazon, Linode et les nombreux autres réseaux affectés. Le trafic attiré par les annonces plus spécifiques est entré dans un corridor sans la capacité ni la politique pour le transporter. Les paquets ont été retardés ou abandonnés. Une fuite de route peut parfois acheminer le trafic par un chemin inefficace; ici, l’échelle a transformé le chemin en goulot d’étranglement.

Lataxonomie des fuites de route de la RFC 7908de l’Internet Engineering Task Force définit une fuite de route comme une propagation au-delà de la portée prévue d’une annonce. L’événement de juin 2019 combine des caractéristiques que la taxonomie sépare à des fins analytiques. Il impliquait des routes apprises d’un fournisseur exportées par un réseau multi-domicilié vers un autre fournisseur, ce qui ressemble au schéma classique du demi-tour, et des routes plus spécifiques utiles en interne qui n’ont jamais été destinées à une propagation mondiale. L’étiquette importe moins que l’invariant violé: un client de Verizon semblait offrir du transit pour des préfixes en dehors de son cône client légitime, et Verizon a accepté cette apparence.

La chronologie et la fenêtre de responsabilité qui s’élargit

La responsabilité change à mesure qu’un incident passe de la prévention à la détection et au rétablissement. La chronologie suivante utilise des données de route publiques et des déclarations attribuées aux opérateurs; elle ne comble pas les lacunes par des actions internes supposées.

La période la plus déterminante a commencé avant le premier horodatage. Si un conseil d’administration commence son examen à 10 h 34, il se concentrera sur les alertes et les appels. S’il commence lorsque les routes de l’optimiseur ont été autorisées pour la production, il peut examiner la sécurité de la conception, la portée des routes, les valeurs par défaut de fermeture sécurisée, les politiques de peering, l’examen des modifications et les tests de propagation indépendants. La réponse à l’incident a réduit la durée. Les contrôles préventifs ont déterminé s’il y avait un incident auquel répondre.

Quatre opportunités de filtrage ont échoué dans la même direction

La route a franchi plusieurs frontières, chacune offrant une occasion différente de l’arrêter. Traiter ces occasions comme des couches clarifie la responsabilité sans prétendre que toutes les parties avaient un contrôle égal.

Confinement de l’optimiseur et du réseau d’origine.DQE contrôlait l’environnement dans lequel le produit de Noction générait des routes plus spécifiques. Les routes destinées uniquement à des décisions locales nécessitaient une barrière d’exportation qui ne dépende pas du bon comportement de chaque réseau en aval. Les options comprenaient une politique d’exportation étroitement définie, un contexte de routage dédié, des communautés explicites interprétées par chaque sortie, des vérifications automatisées à partir de collecteurs externes et un coupe-circuit lié à une propagation inattendue. Noction indique avoir effectué des tests de déploiement et évoque l’utilisation deNO_EXPORT, mais soutient également queNO_EXPORTn’est pas approprié dans toutes les conceptions multi-AS. La communauté bien connue est définie dans laRFC 1997: une route qui la porte ne doit pas être annoncée en dehors d’une frontière de confédération. Qu’elle ait été utilisée, préservée, supprimée ou jamais attachée lors de cet événement n’est pas établi publiquement.

Contrôle d’exportation du client multi-domicilié.AS396531 n’aurait pas dû proposer les routes complètes ou optimisées d’un fournisseur à un autre fournisseur, à moins de fonctionner intentionnellement comme transit. Un réseau feuille ou d’entreprise peut appliquer une règle de sortie simple: n’annoncer que ses propres préfixes autorisés et les préfixes clients explicitement approuvés. Un refus par défaut est plus fiable que d’essayer d’identifier chaque route qui ne doit pas sortir. LaRFC 8212, publiée en 2017, a codifié le rejet externe-BGP par défaut lorsqu’aucune politique d’importation ou d’exportation explicite n’est configurée. Elle ne peut pas empêcher un opérateur d’attacher une politique permissive erronée, mais elle élimine une classe de propagation accidentelle causée par une politique absente.

Contrôle d’entrée du fournisseur client.Verizon avait le point d’arrêt le plus déterminant. Un fournisseur de transit sait quelle session est une session client et doit savoir ce que ce client est autorisé à originer ou à transiter. L’analyse approfondie de Cloudflare a révélé que les informations du registre de routes associées au client n’incluaient pas l’ASN de Cloudflare ni les autres réseaux divulgués. Un filtre de préfixe et de chemin AS spécifique au client aurait donc pu rejeter les annonces. Lesconseils d’exploitation et de sécurité BGP de la RFC 7454, publiés en 2015, recommandent des politiques pour les routes reçues et annoncées à chaque frontière, des contrôles de préfixes clients, le filtrage de chemin AS et des limites de préfixes maximum.

Rejet en aval et par les pairs.Les réseaux recevant les routes de Verizon avaient également une chance de les rejeter. Comme Verizon est un grand réseau de transit, de nombreux destinataires accordaient une confiance substantielle à ses annonces. Certains réseaux utilisant la validation d’origine de route auraient rejeté les routes plus spécifiques de Cloudflare affectées comme invalides RPKI. D’autres pouvaient utiliser des heuristiques de fuite de route ou des politiques de peering. Pourtant, demander à chaque réseau distant de détecter une erreur après qu’un grand fournisseur l’a distribuée est moins efficace que de la rejeter sur la session client d’origine. La prévention au plus près de la violation de politique limite la propagation avant que la convergence mondiale ne transforme une erreur de configuration en une panne distribuée.

Ces couches n’étaient pas suffisamment indépendantes. L’optimisation de DQE, l’exportation d’AS396531 et l’importation de Verizon reposaient toutes sur une configuration correcte de la politique de routage. Si chaque couche est manuellement permissive ou construite à partir d’enregistrements clients incomplets, trois contrôles peuvent échouer ensemble. Un programme d’assurance mature teste donc le résultat depuis l’extérieur du domaine administratif. Il n’accepte pas la seule revue de configuration comme preuve qu’une route est restée locale.

Le RPKI aurait pu bloquer ces routes, mais il n’est pas la réponse complète

Cloudflare avait commencé à signer des routes et à déployer la validation en 2018, comme décrit dans soncompte de déploiement RPKI. Une autorisation d’origine de route, ou ROA, indique quel système autonome peut originer un préfixe et, éventuellement, la longueur de préfixe la plus spécifique qu’il peut annoncer. Cloudflare indique que ses routes pertinentes autorisaient AS13335 avec une longueur maximale de /20. Les /21 divulgués conservaient AS13335 comme origine mais dépassaient la longueur maximale autorisée. Ils étaient donc invalides selon la validation d’origine de route.

La logique est formalisée dans laRFC 6811. Une route reçue est valide si un enregistrement ROA validé couvre le préfixe, que l’ASN d’origine correspond et que la longueur de préfixe de la route ne dépasse pas le maximum du ROA. Elle est invalide lorsqu’une autorisation couvrante existe mais qu’aucune ne correspond à toutes les propriétés requises. L’explication de la validation d’originedu RIPE NCC sépare utilement les états valide, invalide et inconnu, et souligne que les opérateurs de réseau décident toujours de la politique à appliquer à ces états.

La création de ROA par Cloudflare était nécessaire mais pas suffisante. Un ROA est une preuve publiée, pas un ordre d’exécution à distance. Verizon ou un autre réseau destinataire devait récupérer les données RPKI validées, appliquer la validation à la route client et rejeter les invalides. Cloudflare pouvait rejeter les routes invalides entrant dans son propre réseau, mais cela n’empêchait pas les réseaux tiers d’envoyer le trafic à destination de Cloudflare le long d’une route sélectionnée ailleurs.

La sécurité du routage a une structure réciproque: un détenteur d’adresse publie une autorisation, tandis que les autres opérateurs la rendent effective.

Pour cet incident, le RPKI constituait un contrôle préventif particulièrement fort car l’optimiseur modifiait la longueur des préfixes. Il serait erroné de généraliser cette condition de succès à toutes les fuites de route. Si AS396531 avait divulgué le /20 ordinaire de Cloudflare tout en conservant AS13335 à la fin du chemin, la validation d’origine aurait pu considérer la route comme valide. La route aurait quand même violé la topologie fournisseur-client attendue. La validation d’origine RPKI répond à qui peut originer un préfixe et à quelle longueur. Elle ne prouve pas que chaque relation de transit dans le chemin AS est autorisée.

Cette limite n’est pas une critique du RPKI. C’est la raison de le déployer avec d’autres contrôles. Leguide SP 800-189 du NISTcombine le RPKI et la validation d’origine BGP avec le filtrage de préfixes et des pratiques plus larges de résilience inter-domaine. Il traite les fuites de route, les détournements, les déviations de trafic, le déni de service et la dégradation des performances comme des risques opérationnels connexes nécessitant des couches. L’événement de juin 2019 en est une démonstration inhabituellement concrète: une couche aurait pu rejeter les mauvais préfixes exacts, tandis qu’un filtrage client de base aurait pu rejeter le chemin d’autorité invraisemblable même sans cryptographie.

Il y a également une leçon de gouvernance dansmaxLength. Un ROA trop permissif peut faire paraître valides des routes plus spécifiques non autorisées; un ROA trop restrictif ou périmé peut entraîner le rejet de routes légitimes. La couverture des ROA, la longueur maximale, l’expiration, la santé des clés et des dépôts, ainsi que les changements de routage planifiés nécessitent un contrôle des modifications. Un tableau de bord montrant que des ROA existent ne prouve pas qu’ils décrivent précisément l’intention de production.

Contrôles de politique de chemin après 2019

Le paysage des normes et des politiques a continué d’évoluer après la panne. Les contrôles ultérieurs ne doivent pas être décrits comme si les opérateurs auraient pu déployer une version finie en juin 2019, mais ils montrent comment l’industrie a tenté de coder des hypothèses auparavant implicites.

LaRFC 9234, publiée en 2022, a introduit les rôles BGP et l’attribut Only-to-Customer, ou OTC. Les réseaux voisins peuvent déclarer si une relation est de type fournisseur, client, pair, serveur de routes ou client de serveur de routes. L’accord de rôle et la gestion OTC permettent aux routeurs de détecter certaines annonces qui franchissent une frontière de relation dans une direction non autorisée. Dans une version simplifiée du chemin de 2019, une route apprise d’un fournisseur puis envoyée à un autre fournisseur devrait porter des preuves incompatibles avec une exportation réservée aux clients. Les rôles BGP convertissent certaines connaissances de topologie commerciale d’une convention d’opérateur en un état visible par le protocole.

Peerlock offre une autre approche centrée sur le chemin. L’article de 2020« Flexsealing BGP Against Route Leaks »a étudié le mécanisme déployé par les opérateurs, y compris sa capacité à arrêter les chemins dans lesquels un grand réseau protégé apparaît là où il ne devrait pas. Peerlock existait avant l’article et avant l’événement de juin 2019, mais le déploiement dépendait d’une connaissance et d’une configuration bilatérales. C’est la preuve que des filtres de chemin pratiques étaient possibles, et non la preuve qu’un contrôle universel prêt à l’emploi était disponible.

L’autorisation de fournisseur de système autonome, ou ASPA, vise à permettre à un AS de publier des relations de fournisseur vérifiables via le système RPKI. Elle est prometteuse car de nombreuses fuites de route sont des échecs de plausibilité de chemin plutôt que des échecs d’origine. Elle exige également un langage prudent: les normes et l’état de déploiement d’ASPA ont évolué, et une couverture partielle produit des chemins inconnus. Elle doit être traitée comme un signal de validation supplémentaire, et non comme une preuve rétrospective que les entités de 2019 ont violé une norme cryptographique de chemin alors obligatoire.

La détection a également mûri. Cloudflare a décrit plus tard sonservice de détection de fuites de route Radar, qui utilise les relations de routage et les chemins observés pour signaler les fuites probables. La surveillance réduit le temps de connaissance et le temps de coordination, mais n’empêche pas un routeur d’accepter la route. Un incident de deux heures peut encore imposer un préjudice mondial si le chemin de remédiation est une chaîne téléphonique humaine. La détection doit être connectée à une action répétée: identifier les préfixes affectés, appliquer une politique défensive lorsque c’est sûr, joindre les opérateurs autorisés, publier l’état client, vérifier les retraits à travers des collecteurs indépendants et surveiller le rétablissement du trafic.

Le modèle de contrôle utile est donc cumulatif:

1. Publier une autorité de routage précise via les objets IRR et les ROA.
2. Générer des filtres d’importation client à partir de données fiables et les rafraîchir en toute sécurité.
3. Refuser par défaut les routes qui ne disposent pas d’une politique explicite.
4. Appliquer les attentes de cône client, de chemin AS, de longueur de préfixe et de préfixe maximum.
5. Rejeter les annonces invalides RPKI à chaque entrée externe pertinente.
6. Ajouter des contrôles basés sur les relations tels que les rôles BGP, OTC, Peerlock et, à mesure qu’elle mûrit, la validation ASPA.
7. Observer la propagation depuis des points d’observation externes indépendants.
8. Tenir à jour des contacts d’exploitation testés en continu et une autorité de retrait de route.

Aucun élément unique ne remplace les autres. Leur valeur provient de modes de défaillance différents.

Attribuer la responsabilité sans inventer un verdict de responsabilité civile

Les archives techniques publiques permettent une analyse des responsabilités, mais elles ne contiennent pas de jugement de tribunal, d’ordre de régulateur ni d’ensemble complet de contrats répartissant la responsabilité légale entre DQE, AS396531, Verizon, Noction, Cloudflare et les clients affectés. Aucun rapport d’analyse des causes profondes de Verizon n’a été trouvé dans les archives utilisées pour cet article. L’attribution suivante est donc opérationnelle: qui contrôlait quel dispositif de protection et qui pouvait réduire quel risque. Il ne s’agit pas d’une attribution de dommages en pourcentage.

DQE Communications.DQE contrôlait le réseau où les routes d’optimisation étaient générées et la relation par laquelle elles atteignaient AS396531. Ses devoirs les plus importants étaient de limiter la portée des routes, de tester la visibilité externe, de maintenir une politique d’exportation correcte et d’arrêter les annonces une fois contacté. Cloudflare a crédité le personnel de DQE pour avoir aidé à retirer les routes. Une coopération rapide a réduit la durée; elle n’efface pas la défaillance du contrôle préventif.

AS396531.Le réseau multi-domicilié était le pont entre les fournisseurs. Son annonce observable vers Verizon le faisait paraître fournir une joignabilité pour les routes apprises via DQE. Une entreprise non transit devrait exporter une liste d’autorisation étroite, et non une table complète apprise. Les archives publiques n’identifient pas l’ingénieur, le fournisseur ou le changement qui a supprimé ou contourné le filtrage, de sorte que le blâme individuel serait spéculatif. La responsabilité organisationnelle s’attache à la conception qui a permis qu’une restauration de session expose des routes en dehors de l’autorité de l’entreprise.

Verizon.La politique d’importation client de Verizon était le contrôle non exercé le plus conséquent. Un grand réseau de transit acceptant des milliers de routes d’un client doit vérifier les préfixes autorisés, les origines et chemins attendus et le volume de préfixes. L’archive de routes montre que Verizon a propagé le chemin. Cloudflare indique que les données IRR pertinentes et la validation RPKI auraient pu le rejeter et signale des difficultés à joindre Verizon pendant l’événement. Sans les enregistrements internes de Verizon, on ne peut dire si un filtre était absent, périmé, mal appliqué, contourné ou a échoué d’une autre manière. Chacune de ces possibilités pointe vers des devoirs d’assurance et de coordination d’incident proportionnels à l’échelle du fournisseur.

Noction.Un optimiseur de routage capable de créer des routes plus spécifiques globalement préférées présente un mode de défaillance prévisible aux conséquences élevées si le confinement échoue. La responsabilité du produit inclut des valeurs par défaut sûres, des avertissements de risque visibles, une validation du déploiement, un marquage des routes, des tests de fuite externes, une annulation et des contrôles rendant le mode intrusif difficile à activer sans frontières vérifiées. La réponse de Noction indique qu’il a testé la propagation lors du déploiement et que les filtres restaient obligatoires. Cette affirmation soulève la question d’audit suivante: le produit a-t-il vérifié en continu le confinement après des changements de peering ou de session, ou seulement lors de la mise en service? Un test ponctuel ne peut pas prouver indéfiniment la sécurité d’un environnement de routage dynamique.

Cloudflare.Cloudflare n’a ni généré ni propagé les chemins non désirés, et ne pouvait pas configurer la session client de Verizon. Il avait néanmoins vendu aux clients un service de disponibilité et de sécurité construit sur le routage mondial. Sa responsabilité réside donc dans les contrôles résiduels: des ROA précis, une interconnexion diversifiée, une surveillance externe des routes, un diagnostic rapide, des contacts de pairs joignables, une communication client, des options d’atténuation et une divulgation transparente. Il avait également le devoir de ne pas surestimer ce que son architecture pouvait supporter. L’anycast et un grand réseau mondial réduisent de nombreuses défaillances mais ne peuvent pas vaincre un plus spécifique accepté mondialement sans l’aide de réseaux de validation.

Autres réseaux.Les pairs et les réseaux en aval qui ont accepté les routes de Verizon n’étaient pas également positionnés pour connaître l’autorisation client d’AS396531, mais ils pouvaient déployer la validation RPKI et des contrôles de chemin. Leurs décisions ont affecté leurs propres utilisateurs et, dans certains cas, la propagation ultérieure. Le système est plus sûr lorsque les grands réseaux de transit agissent correctement, mais un réseau destinataire reste responsable des routes qu’il installe.

Cette attribution évite l’affirmation commode mais inutile selon laquelle BGP est basé sur la confiance et que personne n’est donc responsable. La confiance est mise en œuvre par des configurations, des registres, des contrats et des pratiques d’exploitation. Ceux-ci sont contrôlables. L’ouverture du protocole explique pourquoi une défaillance peut se propager; elle n’excuse pas un fournisseur de ne pas filtrer les routes clients.

La responsabilité commerciale de Cloudflare a survécu à la cause externe

Un déclencheur externe ne supprime pas les obligations d’un fournisseur cloud envers ses clients. Ladéclaration d’enregistrement S-1 modifiéede Cloudflare en 2019 indiquait que la fuite de route de juin avait causé une perturbation significative de son trafic et de celui d’autres fournisseurs. Elle avertissait que les fuites de route pouvaient nuire à la réputation et à la confiance, décrivait des engagements de niveau de service pouvant donner lieu à des crédits ou remboursements, et précisait que la fuite de route de juin et une panne distincte de juillet déclenchaient certaines de ces obligations. À l’époque, Cloudflare ne s’attendait pas à ce que les incidents aient un effet matériel sur les résultats d’exploitation ou la situation financière.

Cette divulgation faisait suite à uncommentaire du personnel de la SECdemandant à l’entreprise d’aborder l’impact financier raisonnablement attendu de la fuite de route de juin à la lumière des engagements de niveau de service. L’échange est un exemple compact de la responsabilité passant du centre des opérations réseau au reporting d’entreprise. Un incident peut être causé de l’extérieur, significatif sur le plan opérationnel, indemnisable contractuellement et financièrement non matériel pour le fournisseur simultanément.

Le dossier ne divulgue pas le nombre de clients affectés, le total des crédits, les remboursements, les transactions perdues ou le temps d’arrêt au niveau client. Il aborde également la fuite de route de juin parallèlement à la panne de pare-feu applicatif web du 2 juillet causée en interne par Cloudflare. Ces événements ne doivent pas être confondus. L’incident de juin teste la dépendance au routage externe. L’incident de juillet teste les contrôles internes de changement logiciel. Tous deux ont affecté la disponibilité, mais les propriétaires de la prévention et les preuves sont différents.

Pour les clients, un crédit de service n’équivaut pas à une activité restaurée. Un petit commerçant en ligne peut perdre des commandes, un service de communication peut perdre des sessions, et une entreprise peut consommer des heures de personnel avant qu’un crédit d’abonnement mensuel ne soit calculé. Les recours contractuels allouent une fraction des frais directs du fournisseur, et non le coût social ou client total du temps d’arrêt.

Les fournisseurs cloud devraient donc signaler plus que la disponibilité contractuelle: la joignabilité par région et réseau, la perte de trafic, le temps de détection, le temps d’identification, le temps de communication et le temps de rétablissement stable.

Ce que les conseils d’administration devraient demander concernant le risque de peering et de transit

Le routage est souvent traité comme une préoccupation de spécialiste en dessous du niveau de surveillance du conseil d’administration. L’événement de juin 2019 montre pourquoi cette division est trop nette. Une politique d’importation BGP chez un grand fournisseur a modifié l’accès à de nombreux services cloud, déclenché des obligations clients, créé des divulgations pour les investisseurs et exposé une concentration en dehors des contrats formels de fournisseurs cloud. Le conseil d’administration n’a pas besoin de choisir la syntaxe des routeurs.

Il a besoin de preuves que la direction sait où la disponibilité dépend du comportement d’un autre système autonome.

Un dossier utile pour le conseil commence par l’exposition, et non par des revendications de conformité:

Le dénominateur importe dans chaque métrique. Dire que le RPKI est déployé sur les routeurs centraux ne révèle pas si une session périphérique non validée peut injecter une route dans le même réseau. Dire que les filtres clients sont automatisés ne montre pas si le registre source est complet, si des exceptions d’urgence persistent ou si une nouvelle session BGP a hérité de la politique. Dire que les contacts sont dans une base de données ne prouve pas que quelqu’un répond avec autorité à 6 h 30 heure locale.

Les tests devraient inclure des cas négatifs contrôlés. Un fournisseur peut tenter d’annoncer un préfixe de laboratoire non autorisé, un préfixe plus long que ne le permet son ROA, un nombre excessif de routes et un chemin qui viole la relation client déclarée. Le résultat attendu doit être observé au niveau de la politique de réception et chez les collecteurs indépendants. Les tests nécessitent des garde-fous pour ne pas devenir eux-mêmes des fuites, mais éviter tout test réaliste laisse le comportement le plus risqué non vérifié.

Résilience client sans conseil simpliste de multi-fournisseur

Les clients entendent souvent qu’ils devraient éviter la dépendance en achetant un deuxième CDN, un deuxième fournisseur DNS ou un deuxième cloud. La diversité peut aider, mais les défaillances de routage ne respectent pas les étiquettes de produit. Deux fournisseurs peuvent partager le transit, les points d’échange, la fibre, les collecteurs de routes ou les mêmes réseaux d’accès non validants. Un plus spécifique divulgué peut également attirer le trafic avant que la logique de basculement DNS ou applicative du client n’ait une chance d’aider.

La conception correcte commence par le chemin de service. Quel fournisseur fait autorité pour le DNS? Où sont conservées les clés TLS et les politiques de sécurité? Une origine peut-elle accepter en toute sécurité le trafic direct? Le trafic peut-il être déplacé sans créer un contournement de sécurité? À quelle vitesse les caches DNS changent-ils? Les clients conservent-ils les connexions? Un fournisseur secondaire a-t-il une configuration et une capacité à jour? L’organisation peut-elle distinguer une panne de routage amont d’une panne d’origine avant de déplacer le trafic?

Pour certains services, une fourniture active-active via des fournisseurs routés indépendamment est justifiée. Pour d’autres, la complexité, l’incohérence de la politique de sécurité, le comportement du cache et la surface d’attaque ajoutée l’emportent sur un gain de disponibilité de deux heures. Une décision défendable enregistre la criticité, le temps de récupération testé, les dépendances partagées, le coût et le risque résiduel. Elle ne compte pas les noms de fournisseurs et n’appelle pas le résultat résilient.

Les clients peuvent également utiliser le levier d’approvisionnement. Ils peuvent demander à un fournisseur cloud ou réseau la couverture ROA, la politique ROV, les contrôles de filtrage client, la participation à MANRS, les pratiques de contact d’incident, la surveillance externe et des résultats de test anonymisés. Lesactions des opérateurs réseau MANRSfournissent un cadre pratique: filtrage, anti-usurpation, coordination et publication d’informations que d’autres peuvent valider. L’adhésion ou la conformité est un signal, non une preuve de fonctionnement sans faille, mais les actions traduisent la sécurité du routage en questions qu’un acheteur peut comprendre.

La question contractuelle la plus importante n’est souvent pas le pourcentage de disponibilité. C’est la preuve et l’assistance que le fournisseur fournit lorsque le trafic ne peut pas atteindre un service sain en raison d’un routage externe. Une communication d’état rapide et spécifique aide les clients à éviter des changements destructeurs sur des origines saines. Les données de route post-incident les aident à réconcilier leurs propres observations. Une clause de force majeure ou de tiers étroite peut limiter l’indemnisation, mais elle ne doit pas mettre fin au devoir opérationnel du fournisseur de diagnostiquer et de communiquer.

Des normes volontaires à la gestion des risques fondée sur des preuves

L’événement de juin 2019 s’est produit dans un environnement de sécurité du routage largement volontaire. Les meilleures pratiques n’étaient pas inconnues. Le filtrage par préfixe et par chemin AS, les données IRR, les contrôles de préfixes maximum, le RPKI et les registres de contacts d’opérateurs existaient. L’adoption et l’assurance étaient inégales, en particulier lorsqu’un réseau devait supporter le coût de déploiement tandis que les bénéfices se répartissaient sur l’Internet.

Ce problème d’action collective a ensuite attiré une attention gouvernementale plus explicite. LaFeuille de route pour l’amélioration de la sécurité du routage Internetdu Bureau du directeur national de la cybernétique des États-Unis en 2024 décrit l’incapacité de BGP, en fonctionnement courant, à valider l’autorité d’origine, l’intégrité des messages, les informations de chemin à distance ou les annonces qui violent les politiques commerciales de voisinage. Elle appelle à une adoption plus forte de la sécurité de l’origine des routes, en particulier parmi les grands fournisseurs et les services sous contrat gouvernemental. La feuille de route est une orientation politique, pas une conclusion concernant les entités de 2019.

L’avis sur le routage Internet sécuriséde la Federal Communications Commission en 2024 a proposé des plans de gestion des risques BGP et des rapports pour les fournisseurs haut débit, et a sollicité des commentaires sur des mesures au-delà de la validation d’origine RPKI. Il a explicitement reconnu que la sécurité du chemin nécessite des travaux supplémentaires. Encore une fois, cela ne crée pas de responsabilité rétroactive pour juin 2019. Cela illustre un changement de gouvernance, passant de la question de savoir si un fournisseur soutient le RPKI en principe à la demande d’un plan maintenu, de données de couverture, d’attestation et de progrès.

La réglementation a ses propres risques. Un objectif de pourcentage pour l’enregistrement des ROA peut récompenser des autorisations larges et permissives. Une exigence de dépôt peut devenir une paperasserie déconnectée de la politique du routeur. La divulgation publique de configurations défensives détaillées peut créer des problèmes de sécurité. Une surveillance efficace devrait donc se concentrer sur les résultats et les preuves contrôlées: autorisation précise, couverture de rejet, politique client testée, gouvernance des exceptions, vitesse de détection, préparation des contacts et apprentissage des incidents.

Un accès confidentiel de surveillance peut être approprié pour les détails sensibles, tandis que les indicateurs agrégés d’adoption et d’incident restent publics.

Le bien commun de la sécurité du routage traverse également les frontières nationales. La propagation de Verizon a affecté des utilisateurs et des services dans le monde entier; des ingénieurs de Cloudflare dans plusieurs régions ont participé à la réponse; l’autorité de routage est distribuée via les registres régionaux; et les destinataires appliquent leur propre politique. Une règle nationale peut améliorer la conduite des fournisseurs sous sa juridiction, mais ce sont les normes interopérables et les normes des opérateurs qui font voyager cette amélioration.

Les preuves encore manquantes dans les archives publiques

L’analyse approfondie de Cloudflare est exceptionnellement reproductible: elle identifie les données du RIPE NCC, fournit des commandes et montre les chemins et horodatages observés. Cette transparence confère une confiance élevée dans la chronologie des routes. Elle ne répond pas à toutes les questions de responsabilité.

Les enregistrements suivants amélioreraient matériellement l’analyse si les opérateurs impliqués les publiaient:

• La configuration de l’optimiseur de DQE, la politique des préfixes générés, les cartes d’exportation, la gestion des communautés et les tests de propagation externe avant et après le déploiement.
• La politique BGP d’AS396531 attachée aux sessions DQE et Verizon, la chronologie de la coupure et du rétablissement de la session, les changements de configuration, le nombre de routes et la raison pour laquelle les routes apprises du fournisseur étaient éligibles à l’exportation.
• Le dossier d’intégration client de Verizon, la source IRR ou de liste de préfixes, la politique de chemin AS, le paramètre de préfixe maximum, l’état de validation RPKI, les alertes, la chronologie de réponse de l’opérateur et l’explication de la propagation mondiale.
• La liste de contrôle de déploiement de Noction, les dispositifs de confinement continu, le comportement d’alerte et les changements de produit apportés après l’incident.
• Le premier horodatage de détection interne de Cloudflare, la source d’alerte, les décisions d’atténuation envisagées, la chronologie d’escalade des contacts de pairs, l’impact client par réseau et région et la vérification des actions correctives.
• Les crédits de service, remboursements, charge de support et attrition client quantifiés attribuables spécifiquement à la fuite de route de juin plutôt qu’à la panne distincte de juillet.

Leur absence ne rend pas l’événement inconnaissable. Les annonces BGP publiques sont la preuve de ce que les réseaux se sont dit les uns aux autres. Les mesures de trafic sont la preuve de l’impact sur le service. Les dépôts à la SEC sont la preuve de la divulgation d’entreprise et de l’importance relative attendue. Les blogs d’opérateurs sont la preuve d’explications attribuées. La discipline consiste à maintenir ces classes de preuves séparées.

Il est également important de ne pas confondre des archives publiques manquantes avec des archives internes manquantes. Verizon, DQE, AS396531 et Noction peuvent avoir effectué des examens approfondis qui n’ont jamais été publiés. Cloudflare peut détenir une télémétrie détaillée non incluse dans ses publications. La responsabilité publique est plus faible lorsque les preuves restent privées, mais l’article ne peut pas déduire qu’aucun apprentissage n’a eu lieu.

Une norme de responsabilité durable pour la résilience du routage

La panne de juin 2019 est restée dans les mémoires parce qu’un petit réseau est devenu la route apparente vers de grandes parties de l’Internet. Sa leçon plus profonde est que l’échelle n’a pas créé un scepticisme correspondant. Un grand fournisseur de transit a reçu des revendications extraordinaires d’un client et les a distribuées; de nombreux réseaux ont accepté le résultat; le trafic a suivi les règles du protocole dans un chemin invraisemblable; et la récupération a dépendu de trouver des personnes capables de retirer les annonces.

L’événement était évitable avec des contrôles disponibles à l’époque. DQE aurait pu confiner les routes d’optimisation. AS396531 aurait pu n’exporter que des préfixes autorisés. Verizon aurait pu filtrer les annonces client avec des preuves de registre, de chemin, de nombre de préfixes et de RPKI. Les réseaux destinataires auraient pu rejeter les routes plus spécifiques Cloudflare invalides RPKI. Une meilleure surveillance et une meilleure préparation des contacts auraient pu raccourcir l’événement.

Les normes ultérieures rendent certaines hypothèses relationnelles plus faciles à signaler, mais elles ne transforment pas la discipline opérationnelle en une préoccupation héritée facultative.

Le rôle de Cloudflare est plus compliqué que celui de victime ou de propriétaire. C’était la destination dont la joignabilité a été compromise par des décisions externes. Il avait déjà publié des ROA adaptés au rejet des routes plus spécifiques divulguées, exploitait un réseau distribué, détectait l’événement, coordonnait le retrait, expliquait l’enregistrement des routes et divulguait les conséquences contractuelles. Il devait encore aux clients un statut clair, un effort de récupération, des recours financiers lorsque le contrat le prévoyait, et un compte rendu véridique du risque de routage résiduel.

Un fournisseur ne peut pas promettre que le reste de l’Internet validera ses routes; il peut promettre de rendre la validation possible, de surveiller ce qui se passe et de répondre avec des preuves.

La norme de responsabilité finale n’est donc pas l’absence de fuites de route. Aucun réseau mondial ne peut garantir que chaque système autonome configurera correctement chaque session. La norme est de savoir si chaque partie a réduit le risque sous son contrôle, a testé cette réduction de l’extérieur, a limité le rayon d’explosion des erreurs inévitables, a répondu par un chemin de coordination rodé et a produit suffisamment de preuves pour que les clients et les superviseurs puissent vérifier l’amélioration.

C’est à cela que ressemble la résilience du réseau au-delà de la périphérie: non pas l’indépendance vis-à-vis des autres réseaux, ce que l’Internet rend impossible, mais des limites disciplinées quant à la confiance non vérifiée qu’une seule route peut consommer.