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

Résumé

• Le 24 juin 2019, des routes optimisées plus spécifiques générées dans le 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 partie substantielle du trafic a suivi les chemins divulgués dans des liaisons qui n'étaient pas dimensionnées pour le supporter; Cloudflare a signalé une perte d'environ 15 % de son trafic mondial au pire moment de l'incident.
• L'enregistrement public des routes indique une chaîne de défaillances de contrôle, pas un slogan à cause unique. Le générateur de routes n'a pas gardé ses routes d'optimisation locales, un client multihomologué a exporté des routes apprises d'un fournisseur vers un autre, et un grand réseau de transit a accepté et diffusé des routes qui ne correspondaient pas à l'autorité de routage attendue du client. Cloudflare pouvait 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 était particulièrement bien adaptée à la partie de cet événement concernant Cloudflare, car ses autorisations d'origine de routes (ROA) n'autorisaient ses préfixes agrégés qu'à une longueur maximale déclarée. Les plus spécifiques divulguées dépassaient cette longueur et étaient donc invalides. Cela ne fait pas de la RPKI une solution complète contre les fuites de routes: des chemins valides en origine peuvent toujours violer des relations commerciales, c'est 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é des routes, observer les chemins externes, coordonner rapidement et divulguer l'impact client; les clients doivent planifier la défaillance des dépendances; et les conseils d'administration et les régulateurs doivent exiger des mesures d'assurance de sécurité du routage plutôt qu'une déclaration générique de conformité aux meilleures pratiques du secteur.

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

À 10 h 34 min 25 s UTC le 24 juin 2019, des collecteurs BGP publics ont commencé à enregistrer des routes anormales plus spécifiques pour l'espace d'adressage de Cloudflare. La dernière des routes étudiées de Cloudflare a disparu à 12 h 38 min 54 s UTC. L'analyse approfondie des routes archivées de Cloudflare reconstruit 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 de Cloudflare ou un déploiement d'application. Les machines de Cloudflare continuaient d'annoncer leurs routes agrégées ordinaires. Le système de routage mondial a simplement appris des routes concurrentes pour de plus petites parties du même espace d'adressage. Ces plus petites parties ont gagné la décision de transfert dans de nombreux réseaux et ont dirigé les paquets vers un chemin non prévu. La congestion et la perte de paquets ont suivi avant que les requêtes n'atteignent le bord de Cloudflare.

L'explication de l'incident de Cloudflare à l'époque rapportait qu'environ 15 % de son trafic mondial avait été perdu au pire moment. Il s'agit d'une mesure de l'entreprise, pas d'un pourcentage de panne universel audité indépendamment. Elle décrit le trafic de Cloudflare, pas 15 % de l'ensemble d'Internet. L'observation indépendante soutient néanmoins le mécanisme général et l'impact multiservice.

ThousandEyes a rapporté dans son analyse de chemins réseau que les utilisateurs avaient des difficultés à atteindre les services hébergés par Cloudflare et certains services AWS pendant environ deux heures, tandis que l'examen de l'incident de 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 injoignable si le plan de contrôle de routage dirige le trafic ailleurs. Les clients vivent un seul résultat: des délais d'attente, des erreurs et des applications indisponibles. La cause technique, cependant, détermine quels contrôles auraient pu empêcher la perte et quelle partie aurait pu les opérer.

L'enregistrement de statut de Cloudflare pour l'événement a d'abord décrit des problèmes de performance réseau, puis identifié une possible fuite de route, et plus tard dit que le réseau responsable l'avait corrigée. Des copies publiques des mises à jour de statut placent l'avis d'investigation à 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 de statut. Cette différence n'est pas une preuve 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 notifier les clients?

Aucune preuve publique ne montre d'intention malveillante, d'inspection du trafic ou de compromission des systèmes de Cloudflare dans 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é du routage. Il ne convertit 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 centralisé. Chaque système autonome utilise le Border Gateway Protocol, 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 RFC 4271 donne aux opérateurs une liberté de politique considérable. Cette flexibilité soutient le peering commercial, le transit payant, le multihoming, l'ingénierie du trafic et les préférences locales. Cela signifie aussi qu'une route reçue d'un voisin n'est pas accompagnée d'une preuve universelle que chaque AS dans le chemin avait l'intention que l'annonce aille aussi loin.

Avant l'incident, DQE utilisait un produit d'optimisation BGP de Noction. Un tel produit peut mesurer la performance des chemins et injecter des routes plus spécifiques pour influencer quelle liaison 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 plus spécifiques peuvent être un instrument légitime d'ingénierie du 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.

La propre réponse à l'incident de Noction du 26 juin a reconnu que sa plateforme avait généré les plus spécifiques et a décrit trois conditions aggravantes: génération à l'intérieur du réseau de son client, fuite through un ASN en aval vers un grand fournisseur, et filtrage inadéquat aux trois systèmes autonomes. Noction a fait valoir que la création de plus spécifiques est une pratique courante plutôt qu'un défaut inhérent et a souligné le filtrage des fournisseurs. Cette réponse est pertinente car elle confirme le rôle de l'optimiseur tout en contestant un récit unipartite.

Ce n'est pas un post-mortem indépendant, et il ne publie pas la configuration précise, l'enregistrement des modifications, ou les preuves de test pour le déploiement de DQE.

L'analyse de routage séparée de 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 dit qu'AS396531 avait perdu des filtres et exporté des routes apprises de DQE. Cela fournit un déclencheur plausible pour pourquoi la condition a commencé quand elle l'a fait, mais l'enregistrement public disponible n'inclut pas les configurations de routeur ou les journaux d'AS396531, DQE, ou Verizon. La conclusion sûre est plus étroite: le chemin observable prouve que les routes ont traversé 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 empêche trois erreurs courantes. Premièrement, DQE ne devrait pas être décrit comme l'origine de l'espace d'adressage de Cloudflare au sens BGP. Le chemin AS observé se terminait toujours à l'AS13335 de Cloudflare. L'optimiseur de DQE a créé et propagé un chemin plus spécifique avec l'origine légitime conservée. 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 basées sur les 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 sembler comme si les routeurs avaient sélectionné un chemin AS plus court. La préférence décisive s'est produite plus tôt. Le transfert 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 sur une route couvrant un bloc plus large. RFC 4632, la spécification de routage interdomaine 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 apprend aussi104.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, donc il gagne même si son chemin AS est plus long ou opérationnellement absurde. Les attributs de chemin normaux décident entre les routes vers le même préfixe; ils ne font pas qu'un /20 sain bat un /21 accepté.

C'est pourquoi l'empreinte anycast de Cloudflare n'a pas automatiquement contourné le problème. L'anycast permet à de nombreux sites Cloudflare d'annoncer les mêmes préfixes, laissant BGP sélectionner une instance appropriée. Elle fournit 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 ordinaires /20 de Cloudflare. Le système de routage mondial pouvait préférer le /21 avant de comparer quel site anycast de Cloudflare était le plus proche. La redondance derrière la route perdante n'a pas restauré le trafic.

Le chemin non désiré a aussi 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é ou la politique pour le transporter. Les paquets ont été retardés ou perdus. Une fuite de route peut parfois livrer du trafic via un chemin inefficace; ici, l'échelle a transformé le chemin en goulot d'étranglement.

La taxonomie des fuites de route de l'Internet Engineering Task Force dans RFC 7908 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 du fournisseur exportées par un réseau multihomologué vers un autre fournisseur, ce qui ressemble au modèle classique de hairpin-turn, 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 semblait offrir du transit vers 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é croissante

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 avec des actions internes supposées.

La période la plus conséquente a commencé avant la première estampille temporelle. Si un conseil d'administration commence son examen à 10: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 conception, la portée des routes, les défauts par défaut, les politiques de peering, la revue des changements 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 traversé 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 du réseau d'origine et de l'optimiseur.DQE contrôlait l'environnement dans lequel le produit de Noction générait les plus spécifiques. Les routes destinées uniquement aux décisions locales avaient besoin d'une barrière d'exportation qui ne dépendait pas du bon comportement de chaque aval. Les options incluaient une politique d'exportation strictement limitée, 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 interrupteur d'arrêt lié à une propagation inattendue.

Noction dit avoir effectué des tests de déploiement et discute de l'utilisation deNO_EXPORT, mais fait aussi valoir queNO_EXPORTn'est pas approprié dans chaque conception multi-AS. La communauté bien connue est définie dans RFC 1997: une route qui la porte ne doit pas être annoncée en dehors d'une limite de confédération. On ne sait pas publiquement si elle a été utilisée, préservée, supprimée ou jamais attachée dans cet événement.

Contrôle d'exportation du client multihomologué.AS396531 n'aurait pas dû offrir les routes complètes ou optimisées d'un fournisseur à un autre fournisseur à moins qu'il n'opère intentionnellement comme transit. Un réseau feuille 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. RFC 8212, publiée en 2017, a codifié le rejet par défaut des eBGP 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é à originer ou transiter. L'analyse approfondie de Cloudflare a constaté 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.

Le guide de sécurité des opérations et de la sécurité BGP dans RFC 7454, publié en 2015, recommande des politiques pour les routes reçues et annoncées à chaque frontière, des contrôles de préfixe client, un filtrage de chemin AS, et des limites maximales de préfixes.

Rejet par les pairs et les avals.Les réseaux recevant les routes de Verizon avaient aussi une chance de les rejeter. Parce que Verizon est un grand réseau de transit, de nombreux destinataires ont accordé une confiance substantielle à ses annonces. Certains réseaux utilisant la validation de l'origine des routes auraient rejeté les 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.

Cependant, demander à chaque réseau distant de rattraper une erreur après qu'un grand fournisseur la distribue est moins efficace que de la rejeter sur la session client d'origine. La prévention la plus proche de la violation de politique limite la propagation avant que la convergence globale ne transforme une erreur de configuration en 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 la seule revue de configuration comme preuve qu'une route est restée locale.

La RPKI aurait pu bloquer ces routes, mais elle 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 son récit de déploiement RPKI. Une autorisation d'origine de route, ou ROA, indique quel système autonome peut originer un préfixe et, optionnellement, la longueur de préfixe la plus spécifique qu'il peut annoncer. Cloudflare dit que ses routes pertinentes autorisaient AS13335 avec une longueur maximale de /20. Les /21 divulgués ont conservé AS13335 comme origine mais ont dépassé la longueur maximale autorisée. Ils étaient donc invalides selon la validation de l'origine des routes.

La logique est formalisée dans RFC 6811. Une route reçue est valide si une charge utile ROA validée couvre le préfixe, l'ASN d'origine correspond, et la longueur de préfixe de la route ne dépasse pas le maximum de la 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'origine du RIPE NCC sépare utilement les états valide, invalide et inconnu et souligne que les opérateurs réseau décident encore quelle politique appliquer à ces états.

L'acte de Cloudflare de créer des ROA était nécessaire mais pas suffisant. Une ROA est une preuve publiée, pas une commande d'application à distance. Verizon ou un autre réseau récepteur devait récupérer des 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 du trafic destiné à 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 d'autres opérateurs la rendent effective.

Pour cet incident, la RPKI était un contrôle préventif particulièrement fort car l'optimiseur a changé la longueur du préfixe. Il serait erroné de généraliser cette condition de succès à chaque fuite 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 violerait toujours la topologie attendue fournisseur-client. 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 de la RPKI. C'est la raison de la déployer avec d'autres contrôles. Le guide NIST SP 800-189 combine la RPKI et la validation d'origine BGP avec le filtrage de préfixes et des pratiques de résilience interdomaines plus larges. Il traite les fuites de routes, les détournements, les déviations de trafic, les dénis de service et la dégradation des performances comme des risques opérationnels connexes nécessitant des couches.

L'événement de juin 2019 est une démonstration inhabituellement concrète: une couche aurait pu rejeter les mauvais préfixes exacts, tandis que le filtrage client de base aurait pu rejeter le chemin d'autorité invraisemblable même sans cryptographie.

Il y a aussi une leçon de gouvernance dansmaxLength. Une ROA trop permissive peut rendre des plus spécifiques non autorisées valides; une ROA trop restrictive ou périmée peut faire rejeter des routes légitimes. La couverture ROA, la longueur maximale, l'expiration, la santé des clés et du référentiel, et les changements de routage prévus nécessitent un contrôle des modifications. Un tableau de bord montrant que des ROA existent n'est pas une preuve qu'elles 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é à se développer 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 finie en juin 2019, mais ils montrent comment l'industrie a essayé d'encoder des hypothèses qui étaient auparavant implicites.

RFC 9234, publié 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 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 traversent une frontière relationnelle dans une direction impermissible. Dans une version simplifiée du chemin de 2019, une route apprise d'un fournisseur puis envoyée à un autre fournisseur devrait porter une preuve incompatible avec une exportation réservée au client.

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 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é à 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 de la connaissance bilatérale et de la configuration. C'est une preuve que des filtres de chemin pratiques étaient possibles, pas une 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 routes sont des échecs de plausibilité de chemin plutôt que des échecs d'origine. Cela exige aussi un langage prudent: les normes et l'état de déploiement d'ASPA ont évolué, et une couverture partielle produit des chemins inconnus. Il doit être traité comme un signal de validation supplémentaire, pas 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 son service de détection de fuites de routes Radar, qui utilise les relations de routage et les chemins observés pour signaler les fuites probables. La surveillance réduit le temps de savoir et le temps de coordonner, mais elle 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 là où c'est sûr, joindre les opérateurs autorisés, publier le statut client, vérifier les retraits sur 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 route 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 mettre à jour en toute sécurité.
3. Refuser par défaut les routes qui manquent d'une politique explicite.
4. Appliquer les attentes de cône client, de chemin AS, de longueur de préfixe et de nombre maximal de préfixes.
5. Rejeter les annonces RPKI-invalides à chaque entrée externe pertinente.
6. Ajouter des contrôles conscients des relations tels que les rôles BGP, OTC, Peerlock et, à mesure qu'il mûrit, la validation ASPA.
7. Observer la propagation depuis des points de vue externes indépendants.
8. Maintenir des contacts opérationnels testés en continu et une autorité de retrait de routes.

Aucun élément ne se substitue aux autres. Leur valeur provient de différents modes de défaillance.

Attribuer la responsabilité sans inventer un verdict de responsabilité légale

Le dossier technique public soutient l'analyse des responsabilités, mais il ne contient pas de jugement de tribunal, d'ordonnance de régulateur, ni d'ensemble complet de contrats attribuant 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é localisé dans le dossier utilisé pour cet article. L'attribution suivante est donc opérationnelle: qui contrôlait quelle sauvegarde et qui pouvait réduire quel risque. Ce n'est pas 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 devoirs les plus importants étaient de limiter la portée des routes, tester la visibilité externe, maintenir une politique d'exportation correcte et arrêter les annonces une fois contacté. Cloudflare a crédité le personnel de DQE d'avoir aidé à retirer les routes. Une coopération rapide a réduit la durée; elle n'efface pas l'échec du contrôle préventif.

AS396531.Le réseau multihomologué était le pont entre les fournisseurs. Son annonce observable vers Verizon le faisait apparaître comme offrant une joignabilité pour les routes apprises via DQE. Une entreprise non-transit devrait exporter une liste d'autorisation étroite, pas une table complète apprise. Le dossier public n'identifie pas l'ingénieur, le fournisseur ou le changement qui a supprimé ou contourné le filtrage, donc une blame individuelle serait spéculative. La responsabilité organisationnelle s'attache à 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 côté 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 devrait vérifier les préfixes autorisés, les origines et chemins attendus, et le volume de préfixes. L'archive des routes montre que Verizon a propagé le chemin. Cloudflare dit que les données IRR pertinentes et la validation RPKI auraient pu le rejeter et rapporte des difficultés à joindre Verizon pendant l'événement.

Sans les enregistrements 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 pointe vers des devoirs d'assurance et de coordination d'incident proportionnés à l'échelle du fournisseur.

Noction.Un optimiseur de routage qui peut créer des plus spécifiques globalement préférées a un mode de défaillance prévisible à haute conséquence si le confinement échoue. La responsabilité du produit inclut des valeurs par défaut sûres, des avertissements de risque visibles, une validation de déploiement, un étiquetage des routes, des tests de fuite externes, des retours arrière et des contrôles qui rendent le mode intrusif difficile à activer sans limites vérifiées. La réponse de Noction dit qu'il a testé la propagation pendant le déploiement et que les filtres restaient obligatoires.

Cette affirmation soulève la prochaine question d'audit: 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 la sécurité d'un environnement de routage dynamique indéfiniment.

Cloudflare.Cloudflare n'a ni généré ni propagé les chemins non désirés, et il 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é se situe donc dans les contrôles résiduels: ROA précises, interconnexion diversifiée, surveillance des routes externes, diagnostic rapide, contacts pairs joignables, communication avec les clients, options d'atténuation et divulgation transparente. Il avait aussi 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 une plus spécifique acceptée mondialement sans l'aide de réseaux de validation.

Autres réseaux.Les pairs et les avals 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 récepteur reste responsable des routes qu'il installe.

Cette attribution évite l'affirmation commode mais inutile selon laquelle BGP est basé sur la confiance et donc personne n'est responsable. La confiance est mise en œuvre via des configurations, des registres, des contrats et des pratiques opérationnelles. 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 clients.

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

Un déclencheur externe n'élimine pas les obligations d'un fournisseur cloud envers ses clients. La déclaration d'enregistrement modifiée de Cloudflare en 2019 Formulaire S-1 a dit que la fuite de route de juin a causé une perturbation significative de son trafic et de celui d'autres fournisseurs. Il a averti que les fuites de routes pouvaient nuire à la réputation et à la confiance, a décrit des engagements de niveau de service pouvant conduire à des crédits ou des remboursements, et a déclaré que la fuite de route de juin et une panne distincte en juillet ont déclenché certaines de ces obligations.

À l'époque, Cloudflare ne s'attendait pas à ce que les incidents aient un effet matériel sur les résultats des opérations ou la situation financière.

Cette divulgation a fait suite à un commentaire du personnel de la SEC demandant à l'entreprise de traiter 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 d'opérations réseau aux rapports d'entreprise. Un incident peut être causé de l'extérieur, significatif sur le plan opérationnel, compensable contractuellement et financièrement immatériel 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, les remboursements, les transactions perdues ou le temps d'arrêt au niveau client. Il discute aussi de la fuite de route de juin parallèlement à la panne du pare-feu d'application 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 de changement logiciel interne. Les deux ont affecté la disponibilité, mais les propriétaires préventifs et les preuves sont différents.

Pour les clients, un crédit de service n'est pas équivalent à 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, pas le coût social ou client total des temps d'arrêt.

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

Ce que les conseils d'administration devraient demander sur le risque de peering et de transit

Le routage est souvent traité comme une préoccupation spécialisée 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éé une divulgation aux investisseurs et exposé une concentration en dehors des contrats formels de fournisseur cloud. Le conseil n'a pas besoin de choisir la syntaxe du routeur. Il a besoin de preuves que la direction sait où la disponibilité dépend du comportement d'un autre système autonome.

Un dossier de conseil utile commence par l'exposition, pas les affirmations de conformité:

Le dénominateur compte dans chaque métrique. Dire que la RPKI est déployée sur les routeurs centraux ne révèle pas si une session de bord non validée peut injecter une route dans le même réseau. Dire que le filtrage client est automatisé 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é à 06h30 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 sa ROA permet, un nombre excessif de routes, et un chemin qui viole la relation client déclarée. Le résultat attendu devrait être observé à la politique de réception et sur des collecteurs indépendants. Les tests ont besoin de garanties pour ne pas devenir eux-mêmes des fuites, mais éviter tout test réaliste laisse le comportement le plus risqué sans preuve.

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 du transit, des points d'échange, de la fibre, des collecteurs de routes, ou les mêmes réseaux d'accès non validants. Une plus spécifique divulguée peut aussi attirer le trafic avant que la logique de basculement DNS ou d'application du client ait une chance d'aider.

La conception correcte commence par le chemin de service. Quel fournisseur est faisant autorité pour le DNS? Où sont stockées les clés TLS et les politiques de sécurité? Une origine peut-elle accepter en toute sécurité du trafic direct? Le trafic peut-il être déplacé sans créer de 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 défaillance de routage en amont d'une défaillance d'origine avant de déplacer le trafic?

Pour certains services, une livraison active-active sur des fournisseurs indépendamment routés est justifiée. Pour d'autres, la complexité, la politique de sécurité incohérente, le comportement du cache et la surface d'attaque accrue l'emportent sur un gain de disponibilité de deux heures. Une décision défendable enregistre la criticité, le temps de rétablissement 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 aussi utiliser le levier des achats. 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 les résultats de test anonymisés. Les actions des opérateurs réseau MANRS fournissent 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 parfait, 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 quelles preuves et quelle assistance le fournisseur fournit lorsque le trafic ne peut pas atteindre un service sain en raison du routage externe. Une communication rapide et spécifique du statut aide les clients à éviter des changements destructeurs sur des origines saines. Les données de route post-incident les aident à concilier leurs propres observations.

Une clause de force majeure ou de tiers étroitement rédigée 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 meilleures pratiques n'étaient pas inconnues. Le filtrage de préfixes et de chemins AS, les données IRR, les contrôles de préfixes maximum, la RPKI et les registres de contacts opérateurs existaient. L'adoption et l'assurance étaient inégales, en particulier là où un réseau devait supporter le coût de déploiement tandis que les bénéfices se répartissaient sur Internet.

Ce problème d'action collective a ensuite attiré une attention gouvernementale plus explicite. La Feuille de route pour renforcer la sécurité du routage Internet du Bureau du directeur national de la cybersécurité des États-Unis en 2024 décrit l'incapacité de BGP, dans le 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é d'origine des routes, en particulier parmi les grands fournisseurs et les services contractés par le gouvernement.

La feuille de route est un guide politique, pas une conclusion sur les entités de 2019.

L'avis de la Federal Communications Commission de 2024 sur la sécurisation du routage Internet a proposé des plans de gestion des risques BGP et des rapports pour les fournisseurs de large bande et a sollicité des commentaires sur des mesures au-delà de la validation d'origine RPKI. Il a explicitement reconnu que la sécurité des chemins nécessite un travail supplémentaire. Encore une fois, cela ne crée pas de responsabilité rétroactive pour juin 2019.

Cela illustre un changement de gouvernance passant de demander si un fournisseur soutient la RPKI en principe à exiger un plan maintenu, des données de couverture, une attestation et des progrès.

La réglementation a ses propres risques. Un objectif en pourcentage pour l'enregistrement ROA peut récompenser des autorisations larges et permissives. Une exigence de dépôt peut devenir une paperasse déconnectée de la politique du routeur. La divulgation publique de configurations défensives détaillées peut créer des préoccupations 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, état de 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 mesures agrégées d'adoption et d'incidents restent publiques.

Les communs de la sécurité du routage traversent aussi 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é des routes 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 des normes interopérables et des normes opérateurs sont ce qui fait voyager cette amélioration.

Les preuves encore manquantes dans le dossier public

L'analyse approfondie de Cloudflare est inhabituellement reproductible: elle identifie les données du RIPE NCC, fournit des commandes et montre les chemins et estampilles observés. Cette transparence soutient une grande confiance 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 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 des sessions descendantes et montantes, les modifications de configuration, les comptes 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 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 des opérateurs et l'explication de la propagation mondiale.
• La liste de contrôle de déploiement de Noction, les sauvegardes de confinement continu, le comportement d'alerte et les modifications de produit apportées après l'incident.
• La première estampille de détection interne de Cloudflare, la source d'alerte, les décisions d'atténuation envisagées, la chronologie d'escalade des contacts pairs, l'impact client par réseau et région, et la vérification des actions correctives.
• Les crédits de service quantifiés, les remboursements, la charge de support et l'attrition client 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 des preuves de ce que les réseaux se sont dit. Les mesures de trafic sont des preuves de l'impact sur le service. Les dépôts SEC sont des preuves de divulgation d'entreprise et de matérialité attendue. Les blogs d'opérateurs sont des preuves d'explications attribuées. La discipline est de garder ces classes de preuves séparées.

Il est aussi important de ne pas confondre un dossier public manquant avec un dossier interne manquant. Verizon, DQE, AS396531 et Noction ont peut-être 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 articles. La responsabilité publique est plus faible lorsque les preuves restent privées, mais l'article ne peut pas inférer qu'aucun apprentissage n'a eu lieu.

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

La panne de juin 2019 est mémorisée parce qu'un petit réseau est devenu le chemin apparent vers de grandes parties d'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 le rétablissement 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 exporter uniquement les préfixes autorisés. Verizon aurait pu filtrer les annonces clients avec des preuves de registre, de chemin, de nombre de préfixes et de RPKI. Les réseaux récepteurs auraient pu rejeter les plus spécifiques de Cloudflare invalides RPKI. Une meilleure surveillance et une meilleure disponibilité des contacts auraient pu raccourcir l'événement.

Les normes ultérieures facilitent le signalement de certaines hypothèses relationnelles, mais elles ne transforment pas la discipline opérationnelle en une préoccupation facultative héritée.

Le rôle de Cloudflare est plus compliqué que victime ou propriétaire. Il était la destination dont la joignabilité a été compromise par des décisions externes. Il avait déjà publié des ROA adaptées pour rejeter les 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. Il devait encore aux clients un statut clair, un effort de rétablissement, des recours financiers là où ils étaient contractés, et un compte rendu véridique du risque de routage résiduel.

Un fournisseur ne peut pas promettre que le reste d'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 zéro fuite de route. Aucun réseau mondial ne peut garantir que chaque système autonome configurera chaque session correctement. La norme est de savoir si chaque partie a réduit le risque sous son contrôle, testé cette réduction de l'extérieur, limité le rayon d'explosion des erreurs inévitables, répondu via un chemin de coordination pratiqué, et produit suffisamment de preuves pour que les clients et les superviseurs puissent vérifier l'amélioration.

C'est à quoi ressemble la résilience du réseau au-delà du bord: non pas l'indépendance par rapport aux autres réseaux, ce qu'Internet rend impossible, mais des limites disciplinées sur la quantité de confiance non vérifiée qu'une seule route peut consommer.