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 plus spécifiques optimisées, générées au sein du réseau de DQE Communications, ont été transmises via le client AS396531 et acceptées par l'AS701 de Verizon. Verizon a ensuite propagé des chemins couvrant des milliers de réseaux. Comme les routeurs préfèrent un préfixe de destination plus spécifique, une part importante du trafic a suivi les chemins divulgués vers des liens qui n'étaient pas dimensionnés pour le transporter; Cloudflare a signalé avoir perdu environ 15 % de son trafic mondial au pire moment de l'incident.
• Les enregistrements publics de routage révèlent un enchaînement de défaillances de contrôle, et non une cause unique. Le générateur de routes n'a pas conservé ses routes d'optimisation en local, un client multi-hébergé a exporté des routes apprises d'un fournisseur vers un autre fournisseur, et un réseau de transit majeur 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 ne pouvait pas modifier unilatéralement la politique d'importation d'un autre réseau.
• La validation de l'origine des routes RPKI (Resource Public Key Infrastructure) était exceptionnellement bien adaptée à la partie Cloudflare de cet événement, car les autorisations d'origine de route (ROA) de Cloudflare n'autorisaient ses préfixes agrégés que jusqu'à une longueur maximale indiquée. Les routes plus spécifiques divulguées dépassaient cette longueur et étaient donc invalides. Cela ne fait pas de RPKI une solution complète contre les fuites de routes: des chemins valides du point de vue de l'origine peuvent encore violer les relations commerciales, d'où la nécessité de maintenir le filtrage par client, les limites de préfixes, les rôles BGP, les contrôles de chemin, la surveillance et des contacts d'exploitation joignables.
• La responsabilité suit la capacité de contrôle. Les opérateurs qui génèrent ou exportent des routes exceptionnelles doivent les confiner et les tester; les fournisseurs doivent vérifier ce que les clients peuvent annoncer; les plateformes cloud doivent publier leur autorité de routage, observer les chemins externes, se coordonner rapidement et divulguer l'impact sur les clients; les clients doivent prévoir une défaillance 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 bonnes 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.

Le chemin est important car la panne n'a pas commencé par une défaillance d'un centre de données Cloudflare ou d'un déploiement d'application. Les machines de Cloudflare ont continué à annoncer leurs routes agrégées habituelles. Le système de routage mondial a simplement appris des routes concurrentes pour des blocs plus petits du même espace d'adressage. Ces blocs plus petits ont remporté la décision de transmission 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 ne puissent atteindre la périphérie de Cloudflare.

L'explication de l'incidentpar Cloudflare à l'époque a indiqué qu'environ 15 % de son trafic mondial avait été perdu au pire moment. Il s'agit d'une mesure interne à l'entreprise, et non d'un pourcentage de panne universelle audité de manière indépendante. Elle décrit le trafic de Cloudflare, et non 15 % de l'ensemble d'Internet. L'observation indépendante confirme néanmoins le mécanisme général et l'impact multi-services. ThousandEyes a signalé dans sonanalyse des chemins réseauque les utilisateurs ont eu du mal à accéder aux services utilisant Cloudflare et à certains services AWS pendant environ deux heures, tandis que l'examen de l'incidentpar Catchpoint a enregistré des problèmes de performance sur des services en ligne nommés vers 10 h 30 UTC.

La distinction entre la disponibilité des routes et la disponibilité des serveurs est importante pour la responsabilité. Une plateforme peut exploiter des serveurs sains dans de nombreux pays et rester inaccessible si le plan de contrôle du routage dirige le trafic ailleurs. Les clients subissent un seul résultat: des délais d'attente, des erreurs et des applications indisponibles. La cause technique détermine toutefois quels contrôles auraient pu éviter la perte et quelle partie aurait pu les mettre en œuvre.

Lerelevé 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 d'état placent 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. Les archives BGP montrent des routes anormales avant le premier avis d'état. 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 cause, et quand l'entreprise a-t-elle eu suffisamment confiance pour informer les clients?

Aucune preuve publique ne montre d'intention malveillante, d'inspection de trafic ou de compromission des systèmes Cloudflare lors de cet événement. Une fuite de route peut créer une opportunité d'interception, mais le dommage 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é du routage. Il ne transforme pas une propriété de sécurité possible des fuites de route en une allégation selon laquelle le trafic a été lu.

Comment une optimisation locale est devenue une route mondiale

Internet est un accord entre systèmes autonomes plutôt qu'un réseau à répartition centralisée. Chaque système autonome utilise le protocole BGP (Border Gateway Protocol) pour indiquer aux systèmes voisins quels préfixes IP il peut atteindre et par quel chemin AS. Le protocole de base dans laRFC 4271laisse aux opérateurs une liberté de politique considérable. Cette flexibilité prend en charge le peering commercial, le transit payant, le multi-hébergement, l'ingénierie du trafic et les préférences locales. Cela signifie également qu'une route reçue d'un voisin n'est pas accompagnée d'une preuve universelle que chaque AS du chemin avait l'intention 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 le lien qui transporte le trafic sélectionné. Dans l'exemple publié par Cloudflare, l'annonce normale104.20.0.0/20a été 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.

Au sein d'un réseau contrôlé, les routes plus spécifiques peuvent être un instrument légitime d'ingénierie du trafic. Le danger réside dans 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 du 26 juinde Noction a reconnu que sa plateforme avait généré les routes plus spécifiques et a décrit trois conditions aggravantes: la génération au sein du réseau de son client, la fuite via un ASN en aval vers un fournisseur majeur 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 mis l'accent sur le filtrage par les fournisseurs. Cette réponse est pertinente car elle confirme le rôle de l'optimiseur tout en contestant une version unique des faits. Il ne s'agit pas d'une autopsie indépendante et elle ne publie pas la configuration précise, l'historique des modifications ni les preuves de test pour le déploiement de DQE.

L'analyse de routage distinctede Qrator Labs a associé le début au rétablissement de la session BGP entre AS396531 et Verizon peu après 10 h 35 UTC. Son récit indique qu'AS396531 avait perdu ses filtres et exporté des routes apprises de DQE. Cela fournit un déclencheur plausible expliquant pourquoi la situation a commencé à ce moment-là, mais les archives publiques disponibles n'incluent pas les configurations de routeur ni les journaux d'AS396531, DQE ou Verizon. La conclusion prudente est plus étroite: le chemin observable prouve que les routes ont franchi ces frontières AS; les comptes rendus des opérateurs identifient des filtres manquants ou inadéquats; la séquence exacte des modifications internes reste non publique.

Cette distinction évite trois erreurs courantes. 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 toujours par 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 transmission en fonction des annonces qu'ils ont reçues.

Pourquoi les routes plus spécifiques ont vaincu 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 s'est produite plus tôt. La transmission sur Internet utilise la correspondance de préfixe la plus longue: une route couvrant le bloc de destination le plus spécifique est sélectionnée de préférence à une route couvrant un bloc plus large. LaRFC 4632, la spécification du 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 le préfixe104.20.0.0/20de Cloudflare est accessible via un fournisseur normal et apprenne également104.20.0.0/21via Verizon, AS396531 et DQE. Une destination à l'intérieur du premier /21 correspond aux deux annonces. Le /21 est plus spécifique, il l'emporte donc même si son chemin AS est plus long ou opérationnellement absurde. Les attributs de chemin normaux départagent les routes pour le même préfixe; ils ne permettent pas à un /20 sain de battre 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 liens individuels. Mais les /21 divulgués étaient plus spécifiques que les annonces /20 habituelles 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 dimensionnés pour servir de 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 couloir 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 un goulot d'étranglement.

Lataxonomie des fuites de route de la RFC 7908de l'IETF 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 d'analyse. Il impliquait des routes apprises d'un fournisseur et exportées par un réseau multi-hébergé vers un autre fournisseur, ce qui ressemble au schéma classique du virage en épingle à cheveux, et des routes plus spécifiques utiles en interne qui n'étaient jamais destinées à une propagation mondiale. L'étiquette importe moins que l'invariant violé: un client de Verizon a semblé offrir un transit pour des préfixes en dehors de son cône de clientèle légitime, et Verizon a accepté cette apparence.

La chronologie et la fenêtre de responsabilité élargie

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

La période la plus conséquente 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 au moment où les routes d'optimisation 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 en cas d'échec, les politiques de peering, l'examen des modifications et les tests de propagation indépendants. La réponse à l'incident en 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 avec une opportunité différente de l'arrêter. Traiter ces opportunités 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 Noction générait des routes plus spécifiques. Les routes destinées uniquement aux décisions locales nécessitaient une barrière d'exportation qui ne dépendait pas du comportement correct de chaque aval. Les options comprenaient une politique d'exportation étroitement définie, un contexte de routage dédié, des communautés explicites interprétées à 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 discute de l'utilisation deNO_EXPORT, mais fait également valoir 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, conservée, supprimée ou jamais attachée dans cet événement n'est pas établi publiquement.

Contrôle d'exportation du client multi-hébergé.AS396531 n'aurait pas dû offrir les routes complètes ou optimisées d'un fournisseur à un autre fournisseur, sauf s'il fonctionnait intentionnellement comme transit. Un réseau d'extrémité ou d'entreprise peut appliquer une règle de sortie simple: annoncer uniquement 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 BGP externe 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 supprime une classe de propagation accidentelle causée par une politique absente.

Contrôle d'entrée client du fournisseur.Verizon avait le point d'arrêt le plus efficace. Un fournisseur de transit sait quelle session est une session client et devrait savoir ce que ce client est autorisé à annoncer ou à transiter. L'analyse approfondie de Cloudflare a révélé que les informations du registre de routage 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. Lesrecommandations d'exploitation et de sécurité BGP de la RFC 7454, publiées en 2015, recommandent des politiques pour les routes reçues et annoncées à chaque frontière, des contrôles de préfixes clients, un filtrage des chemins 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 la possibilité de les rejeter. Comme Verizon est un grand réseau de transit, de nombreux destinataires accordaient une confiance considérable à ses annonces. Certains réseaux utilisant la validation d'origine de route auraient rejeté les routes plus spécifiques Cloudflare concernées comme invalides selon RPKI. D'autres pourraient 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 fournisseur majeur 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 assez 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 le seul examen de la configuration comme preuve qu'une route est restée locale.

RPKI aurait pu bloquer ces routes, mais ce 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 rendu de déploiement RPKI. Une autorisation d'origine de route (ROA) indique quel système autonome peut annoncer 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 une charge utile ROA validée 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 de couverture 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 une commande d'application à 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 par un chemin sélectionné ailleurs. La sécurité du routage a une structure réciproque: un détenteur d'adresse publie une autorisation, tandis que d'autres opérateurs la rendent effective.

Pour cet incident, RPKI était un contrôle préventif particulièrement fort parce que l'optimiseur a modifié la longueur du préfixe. 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 pourrait considérer la route comme valide. La route violerait toujours la topologie fournisseur-client attendue. La validation d'origine RPKI répond à la question de savoir qui peut annoncer 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 de RPKI. C'est la raison pour laquelle il faut le déployer avec d'autres contrôles. Lesrecommandations SP 800-189du NIST combinent RPKI et la validation d'origine BGP avec le filtrage de préfixes et des pratiques plus larges de résilience interdomaine. Elles traitent 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 liés nécessitant des couches. L'événement de juin 2019 en est une démonstration exceptionnellement concrète: une couche aurait pu rejeter exactement les mauvais préfixes, 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 obsolète peut entraîner le rejet de routes légitimes. La couverture des ROA, la longueur maximale, l'expiration, la santé des clés et du dépôt, ainsi que les modifications de routage planifiées nécessitent un contrôle des modifications. Un tableau de bord indiquant que des ROA existent ne prouve pas qu'ils décrivent avec précision 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 avaient pu déployer une version finalisée en juin 2019, mais ils montrent comment l'industrie a tenté d'encoder des hypothèses qui étaient auparavant implicites.

LaRFC 9234, publiée en 2022, a introduit les rôles BGP et l'attribut Only-to-Customer (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 le traitement OTC permettent aux routeurs de détecter certaines annonces qui franchissent une frontière de relation dans une direction inadmissible. 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 une partie de la connaissance de la topologie commerciale, d'une convention d'opérateur à un état visible par le protocole.

Peerlock propose une autre approche axé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é à bloquer les chemins où 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 de connaissances 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. C'est prometteur car de nombreuses fuites de route sont des échecs de plausibilité de chemin plutôt que des échecs d'origine. Cela 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 de chemin cryptographique 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 prise de conscience et de coordination, mais n'empêche pas un routeur d'accepter la route. Un incident de deux heures peut encore causer des dommages mondiaux si le chemin de remédiation est une chaîne téléphonique humaine. La détection doit être relié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 des clients, vérifier les retraits via des collecteurs indépendants et surveiller la récupération du trafic.

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

1. Publier une autorité de routage précise via des objets IRR et des ROA.
2. Générer des filtres d'importation client à partir de données fiables et les actualiser en toute sécurité.
3. Rejeter par défaut les routes qui manquent d'une politique explicite.
4. Appliquer les attentes en matière 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 sensibles aux relations tels que les rôles BGP, OTC, Peerlock et, à mesure qu'elle mûrit, la validation ASPA.
7. Observer la propagation à partir de points d'observation externes indépendants.
8. Maintenir 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 différents modes de défaillance.

Répartir la responsabilité sans inventer un verdict de responsabilité légale

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

DQE Communications.DQE contrôlait le réseau où les routes d'optimisation ont été générées et la relation par laquelle elles ont atteint AS396531. Ses obligations les plus importantes é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 reconnu que le personnel de DQE avait 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-hébergé était le pont entre les fournisseurs. Son annonce observable vers Verizon le faisait paraître comme fournissant une accessibilité pour les routes apprises via DQE. Une entreprise qui n'est pas un transit ne devrait exporter qu'une liste autorisée étroite, et non une table complète apprise. Les archives publiques n'identifient pas l'ingénieur, le fournisseur ou la modification qui a supprimé ou contourné le filtrage, de sorte que le blâme individuel serait de la spéculation. La responsabilité organisationnelle est liée à la conception qui a permis à une restauration de session d'exposer des routes en dehors de l'autorité de l'entreprise.

Verizon.La politique d'importation de Verizon orientée client était le contrôle non exercé le plus important. Un grand réseau de transit acceptant des milliers de routes d'un client devrait vérifier les préfixes autorisés, les origines et les chemins attendus, ainsi que le volume de préfixes. Les archives de routage montrent que Verizon a propagé le chemin. Cloudflare indique que les données IRR pertinentes et la validation RPKI auraient pu le rejeter, et fait état de difficultés à joindre Verizon pendant l'événement. Sans les dossiers internes de Verizon, on ne peut pas dire si un filtre était absent, obsolète, mal appliqué, contourné ou a échoué d'une autre manière. Chacune de ces possibilités renvoie à des obligations d'assurance et de coordination des incidents proportionnelles à l'échelle du fournisseur.

Noction.Un optimiseur de routage qui peut créer des routes plus spécifiques préférées mondialement présente un mode de défaillance prévisible à 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 externe, un retour en arrière et des contrôles qui rendent le mode intrusif difficile à activer sans limites vérifiées. La réponse de Noction indique qu'il a testé la propagation pendant le 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 unique 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 indésirables, 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é reposant 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 vaste réseau mondial réduisent de nombreuses défaillances, mais ne peuvent pas contrer une route plus spécifique acceptée 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 en mesure de 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 répartition évite l'affirmation commode mais peu utile 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 filtrer les routes des clients.

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

Un déclencheur externe ne supprime pas les obligations d'un fournisseur de 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 importante 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 les engagements de niveau de service pouvant donner lieu à des crédits ou des remboursements, et précisait que la fuite de route de juin et une panne distincte en juillet avaient déclenché certaines de ces obligations. À l'époque, Cloudflare ne s'attendait pas à ce que les incidents aient un effet significatif sur les résultats d'exploitation ou la situation financière.

Cette divulgation faisait suite à uncommentaire du personnel de la SECdemandant à l'entreprise de traiter l'impact financier raisonnablement attendu de la fuite de route de juin au regard des engagements de niveau de service. L'échange est un exemple condensé du déplacement de la responsabilité du centre d'exploitation du réseau vers les rapports d'entreprise. Un incident peut être causé de l'extérieur, opérationnellement significatif, contractuellement indemnisable et financièrement négligeable pour le fournisseur en même temps.

Le dépôt ne divulgue pas le nombre de clients affectés, le total des crédits, des remboursements, des transactions perdues ou des temps d'arrêt au niveau des clients. Il traite également de la fuite de route de juin parallèlement à la panne du pare-feu d'application Web du 2 juillet, causée en interne. Ces événements ne doivent pas être fusionnés. L'incident de juin teste la dépendance au routage externe. L'incident de juillet teste les contrôles internes de modification logicielle. Les deux ont affecté la disponibilité, mais les responsables préventifs et les preuves sont différents.

Pour les clients, un crédit de service n'équivaut pas à la restauration de l'activité. 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 n'allouent qu'une fraction des frais directs du fournisseur, et non le coût social ou client total du temps d'arrêt. Les fournisseurs de cloud devraient donc communiquer plus que la disponibilité contractuelle: accessibilité par région et par réseau, perte de trafic, temps de détection, temps d'identification, temps de communication et temps de récupération stable.

Ce que les conseils d'administration devraient demander en matière de 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 fournisseur majeur a modifié l'accès à de nombreux services cloud, déclenché des obligations envers les clients, créé des obligations de divulgation pour les investisseurs et exposé une concentration en dehors des contrats formels avec les fournisseurs de cloud. Le conseil d'administration n'a pas besoin de choisir la syntaxe de routeur. Il a besoin de preuves que la direction sait où la disponibilité dépend du comportement d'un autre système autonome.

Le dénominateur compte dans chaque métrique. Dire que RPKI est déployé sur les routeurs centraux ne révèle pas si une session de périphérie 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 les 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 ce que son ROA permet, un nombre de routes excessif et un chemin qui viole la relation client déclarée. Le résultat attendu devrait être observé au niveau de la politique de réception et des 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 des produits. 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. Une route plus spécifique divulguée peut également attirer le trafic avant que la logique de basculement DNS ou applicative du client ait une chance d'intervenir.

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 la configuration et la capacité actuelles? L'organisation peut-elle distinguer une défaillance de routage amont d'une défaillance d'origine avant de déplacer le trafic?

Pour certains services, une livraison 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 supplémentaire 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 des fournisseurs pour qualifier le résultat de résilient.

Les clients peuvent également utiliser le levier des achats. Ils peuvent demander à un fournisseur de cloud ou de réseau la couverture ROA, la politique ROV, les contrôles de filtrage client, la participation à MANRS, les pratiques de contact en cas d'incident, la surveillance externe et les résultats de tests anonymisés. Lesactions des opérateurs de réseau MANRSfournissent un cadre pratique: filtrage, anti-spoofing, coordination et publication d'informations que d'autres peuvent valider. L'adhésion ou la conformité est un signal, pas 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 du routage externe. Une communication d'état rapide et spécifique aide les clients à éviter des modifications destructrices sur des origines saines. Les données de route post-incident les aident à rapprocher leurs propres observations. Une clause de force majeure ou de tiers rédigée de manière étroite peut limiter l'indemnisation, mais elle ne devrait pas mettre fin au devoir opérationnel du fournisseur de diagnostiquer et de communiquer.

Des normes volontaires aux preuves de gestion des risques

L'événement de juin 2019 s'est produit dans un environnement de sécurité du routage largement volontaire. Les bonnes pratiques n'étaient pas inconnues. Le filtrage des préfixes et des chemins AS, les données IRR, les contrôles de préfixes maximum, RPKI et les registres de contacts des 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 avantages se répandaient sur Internet.

Ce problème d'action collective a par la suite attiré une attention gouvernementale plus explicite. Lafeuille de route pour l'amélioration de la sécurité du routage Internetde 2024 du Bureau du directeur national de la cybernétique des États-Unis décrit l'incapacité de BGP, dans son fonctionnement courant, à valider l'autorité d'origine, l'intégrité des messages, les informations de chemin distant ou les annonces qui violent les politiques commerciales voisines. Elle appelle à une adoption plus forte de la sécurité de l'origine des routes, en particulier parmi les principaux fournisseurs et les services sous contrat gouvernemental. La feuille de route est une orientation politique et non une conclusion sur les entités de 2019.

L'avis sur le routage Internet sécuriséde 2024 de la Federal Communications Commission a proposé des plans de gestion des risques BGP et des rapports pour les fournisseurs de haut débit, et a sollicité des commentaires sur des mesures allant au-delà de la validation d'origine RPKI. Elle a explicitement reconnu que la sécurité des chemins 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 RPKI en principe à la demande d'un plan maintenu, de données de couverture, d'attestation et de progrès.

La réglementation comporte ses propres risques. Un objectif de pourcentage pour l'enregistrement des ROA peut récompenser des autorisations larges et permissives. Une obligation de déclaration peut devenir une paperasse déconnectée de la politique des routeurs. La divulgation publique des configurations défensives détaillées peut créer des problèmes de sécurité. Une supervision 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 de supervision confidentiel peut être approprié pour les détails sensibles, tandis que les métriques d'adoption agrégées et d'incidents restent publiques.

Le bien commun de la sécurité du routage dépasse également les frontières nationales. La propagation par 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 par l'intermédiaire de 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 absentes des 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 observés et les horodatages. Cette transparence confère une grande confiance dans la chronologie des routes. Elle ne répond pas à toutes les questions de responsabilité.

Les enregistrements suivants amélioreraient considérablement l'analyse si les opérateurs impliqués les publiaient:

• La configuration de l'optimiseur de DQE, la politique de 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 déconnexion et de la reconnexion des sessions, les modifications de configuration, le nombre de routes et la raison pour laquelle les routes apprises des fournisseurs étaient éligibles à l'exportation.
• Le dossier d'intégration client de Verizon, la source IRR ou la liste de préfixes, la politique de chemin AS, le paramètre de préfixes 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 garanties de confinement continu, le comportement d'alerte et les modifications du produit apportées 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 avec les pairs, l'impact sur les clients par réseau et par région, et la vérification des actions correctives.
• Les crédits de service, remboursements, charge de support et attrition de clients quantifiés spécifiquement attribuables à 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 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 des opérateurs sont la preuve d'explications attribuées. La discipline consiste à maintenir ces catégories de preuves séparées.

Il est également important de ne pas confondre une archive publique manquante avec une archive interne manquante. Verizon, DQE, AS396531 et Noction peuvent avoir effectué des examens approfondis qui n'ont jamais été publiés. Cloudflare peut détenir des données de télémétrie détaillées non incluses dans ses articles. La responsabilité publique est plus faible lorsque les preuves restent privées, mais l'article ne peut pas en déduire qu'aucun apprentissage n'a eu lieu.

Une norme de responsabilité durable pour la résilience des routes

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 d'Internet. Sa leçon plus profonde est que l'échelle n'a pas créé de scepticisme correspondant. Un fournisseur de transit majeur 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 la recherche de personnes capables de retirer les annonces.

L'événement était évitable avec les contrôles disponibles à l'époque. DQE aurait pu confiner les routes d'optimisation. AS396531 aurait pu n'exporter que les préfixes autorisés. Verizon aurait pu filtrer les annonces des clients avec des preuves de registre, de chemin, de nombre de préfixes et RPKI. Les réseaux destinataires auraient pu rejeter les routes plus spécifiques Cloudflare invalides selon 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 font pas de la discipline opérationnelle 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 l'accessibilité a été compromise par des décisions externes. Elle avait déjà publié des ROA adaptés pour rejeter les routes plus spécifiques divulguées, exploitait un réseau distribué, a détecté l'événement, coordonné le retrait, expliqué l'enregistrement des routes et divulgué les conséquences contractuelles. Elle devait encore aux clients un état clair, des efforts de récupération, des recours financiers lorsque cela était contractuel 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 totale 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'impact 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 qu'Internet rend impossible, mais des limites disciplinées quant à la confiance non vérifiée qu'une seule route peut consommer.