La réponse de Cloudflare à la fuite de route a rendu la réparation vérifiable plus importante que le simple apaisement

Résumé

• En juin 2019, une fuite de route BGP impliquant un petit réseau, un optimiseur de route et Verizon a perturbé l'accessibilité de Cloudflare et d'autres services. La réponse publique de Cloudflare a correctement souligné les défaillances de sécurité du routage en dehors de son réseau direct.
• Le nouvel angle est celui de la réparation vérifiable par rapport au simple apaisement. Après une fuite de route, les clients d'un fournisseur ont besoin de plus qu'une explication confiante; ils ont besoin de preuves que l'autorité d'origine de route, le filtrage en amont, la validation et la surveillance se sont améliorés.
• Cloudflare n'était pas le fuyard d'origine dans les archives publiques, mais elle avait un contrôle pratique sur sa propre autorité de route, le plaidoyer RPKI, la communication avec les clients, la surveillance, la pression sur le transit et l'explication publique du risque résiduel.
• Verizon et le réseau fuyard contrôlaient des points de propagation à fort levier. La carte de responsabilité sépare donc l'origine, l'amplificateur, le fournisseur affecté, les réseaux de validation et les clients, au lieu de traiter Internet comme un accident sans visage.
• La leçon durable est que les incidents de routage devraient laisser des artefacts mesurables: ROAs, rejet de routes invalides, changements de filtres, exigences de peering, données de route publiques, chronologies d'incidents et conseils aux clients sur ce qui peut ou ne peut pas être rendu sûr par la seule action du fournisseur.

Registre des preuves et utilisation

Cet article utilise l'analyse publique de Cloudflare comme compte rendu du fournisseur affecté de première partie, des sources de routage et d'industrie externes pour le contexte de sécurité du routage, et des RFC ou des directives gouvernementales pour les contrôles actuels de BGP, RPKI et de fuite de route. Les normes ultérieures sont utilisées pour encadrer la réparation vérifiable, et non comme des obligations légales rétroactives pour chaque entité de 2019.

L'apaisement n'est pas la réparation

Les fuites de route produisent un problème de communication publique prévisible. Le fournisseur affecté veut rassurer les clients que la panne a été causée en dehors de son contrôle direct. Cela peut être vrai. En juin 2019, l'analyse publique de Cloudflare a identifié un comportement de propagation de route impliquant Verizon et un optimiseur de route utilisé par un plus petit réseau. Cloudflare était un fournisseur affecté, pas la source originale des mauvaises informations de routage. Mais les clients n'achètent pas seulement une répartition des blâmes. Ils achètent un service accessible.

Après un incident de routage, le réconfort doit devenir une preuve de réparation.

Les preuves de réparation répondent à des questions que l'apaisement ne peut pas. Le fournisseur affecté a-t-il publié des autorisations d'origine de route précises pour ses préfixes? Ses fournisseurs de transit rejettent-ils les routes invalides ou non autorisées? Le fournisseur lui-même rejette-t-il les routes invalides des autres? A-t-il fait pression ou sélectionné des pairs en fonction de l'hygiène de routage? Les clients peuvent-ils voir si les données de routage publiques soutiennent le post-mortem? Le fournisseur divulgue-t-il les risques résiduels qui restent hors de son contrôle? Quels contrôles ont changé après l'événement?

La réponse de Cloudflare est intéressante car l'entreprise s'était déjà positionnée comme un défenseur de la sécurité du routage. Elle a publié des explications sur le RPKI et attiré l'attention sur la nécessité du filtrage et de la validation des routes. Ce plaidoyer est précieux. La question de responsabilité est de savoir comment le rendre vérifiable. Un fournisseur peut dire que le système de routage a besoin d'améliorations. Les clients ont besoin de savoir ce que le fournisseur lui-même a fait: ROAs, politiques de validation, exigences de transit, surveillance, communications avec les clients et exercices d'incident.

Cette distinction n'est pas pédante. Le routage Internet est un système de confiance avec de nombreuses relations privées. Les clients ne peuvent pas inspecter chaque filtre de transit ou politique de peering. Les preuves publiques sont donc essentielles. Les collecteurs de routes, les dépôts RPKI, la participation MANRS, les chronologies d'incidents et les déclarations des fournisseurs deviennent des substituts à l'inspection directe. Plus les preuves publiques sont solides, moins les clients doivent se fier à la confiance dans la marque.

L'apaisement a aussi une durée de vie. Immédiatement après un incident, il peut calmer les clients. Des mois plus tard, la question importante est de savoir si la faiblesse d'interconnexion a diminué. Une fuite de route qui ne laisse qu'un article de blog a moins appris à Internet que celle qui laisse une validation mesurable, de meilleurs filtres et une pression de responsabilité publique. La leçon principale est que la réparation doit être inspectable.

La fuite avait des rôles d'origine, d'amplificateur et de victime

Les incidents de routage sont souvent décrits comme si Internet avait échoué en général. Ce langage est trop vague pour la responsabilité. Une carte utile des fuites de route sépare les rôles. Un réseau a fui ou originait des informations de route problématiques. Un autre réseau, avec une portée plus large, les a acceptées et propagées. Les fournisseurs affectés comme Cloudflare ont vu leur trafic détourné ou leur accessibilité perturbée. D'autres réseaux ont accepté, rejeté ou observé la route. Les clients ont subi une défaillance de service sans contrôler aucune de ces décisions de routage.

Cette carte des rôles évite deux erreurs. La première est de blâmer le fournisseur affecté pour chaque défaillance d'accessibilité. Cloudflare ne contrôlait pas l'acceptation de route par Verizon ni l'optimiseur de route du plus petit réseau. La seconde est d'absoudre entièrement le fournisseur affecté parce que la fuite provenait d'ailleurs. Cloudflare contrôlait toujours sa propre autorité de route, sa posture de validation, sa surveillance, sa communication avec les clients et sa pression commerciale sur les partenaires réseau. La responsabilité est distribuée, non dissoute.

Le rôle de Verizon était important car l'amplification détermine le rayon d'explosion. Une mauvaise route d'un petit réseau peut rester petite si les upstreams la filtrent. La propagation d'un grand fournisseur de transit peut la rendre mondiale. C'est pourquoi le filtrage en amont n'est pas une courtoisie optionnelle. C'est une obligation de sécurité pour les réseaux qui vendent la portée. Plus un fournisseur a de portée, plus il doit valider soigneusement ce qu'il propage.

L'angle de l'optimiseur de route est aussi un avertissement sur l'automatisation. Les outils qui optimisent les décisions BGP peuvent créer des changements de routage à fort levier. Si de tels outils sont autorisés à fuir des routes à travers les relations entre fournisseurs, ils peuvent transformer l'ingénierie du trafic commercial en panne publique. L'automatisation ne réduit pas la responsabilité; elle augmente le besoin de contraintes, de tests de politique de routage et de surveillance.

Le rôle de fournisseur affecté de Cloudflare comporte une obligation différente: rendre visible la défaillance de contrôle externe, l'expliquer avec précision et convertir l'événement en exigences plus fortes de sécurité du routage. C'est une forme légitime de responsabilité. Un fournisseur peut aider à réparer l'écosystème même s'il n'a pas causé la fuite originale. La clé est de rendre la réparation mesurable.

Le RPKI modifie la norme de preuve

Le RPKI est important car il transforme certaines questions d'autorité de route en données cryptographiquement vérifiables. Un détenteur de ressource peut publier une autorisation d'origine de route indiquant quel système autonome est autorisé à originer un préfixe et avec quelle longueur maximale. Les réseaux qui effectuent une validation d'origine de route peuvent classer les routes reçues et rejeter les origines invalides lorsque la politique l'exige. Cela ne résout pas toutes les fuites de route, mais cela change ce qui peut être prouvé.

Pour Cloudflare, le RPKI n'était pas seulement une solution technique. C'était un instrument de responsabilité. Si l'entreprise publie des ROAs précises pour ses préfixes, les clients et autres réseaux peuvent inspecter une partie du registre d'autorité. Si les réseaux rejettent les routes invalides, certaines annonces de mauvaise origine deviennent moins dangereuses. Si Cloudflare mesure et encourage l'adoption, elle crée une pression sur les réseaux qui acceptent encore une autorité invalide. La réparation devient moins dépendante d'assurances privées.

Le RPKI n'est pas un bouclier magique. Une fuite de route peut impliquer une route qui reste valide en origine parce que l'AS d'origine est toujours autorisé alors que la relation de chemin est erronée. C'est pourquoi la taxonomie des fuites de route de la RFC 7908 et les mécanismes ultérieurs comme les rôles BGP sont importants. La validation d'origine de route répond à qui peut originer; la prévention des fuites de route demande aussi si la route doit être propagée à travers une relation donnée. La réparation vérifiable doit inclure à la fois la validation d'origine et le filtrage conscient des relations.

Cette nuance est importante pour une communication honnête avec les clients. Un fournisseur ne devrait pas laisser entendre que le RPKI rend tous les incidents de routage impossibles. Il devrait expliquer ce que le RPKI peut prévenir, ce qu'il ne peut pas prévenir, et quels contrôles complémentaires sont nécessaires. Les clients peuvent alors comprendre le risque résiduel. Exagérer un contrôle est une autre forme d'apaisement sans réparation.

La valeur publique du RPKI est qu'il crée des artefacts. Les ROAs peuvent être vérifiées. Le rejet de routes invalides peut être mesuré. L'adoption peut être suivie. Les opérateurs réseau peuvent être interrogés sur les raisons pour lesquelles ils valident ou non. Ces artefacts donnent aux clients quelque chose de plus solide qu'une excuse post-incident. Le plaidoyer de Cloudflare pour la sécurité du routage est plus fort lorsqu'il est lié à des preuves inspectables.

Les normes de type MANRS transforment le routage privé en attente publique

MANRS est important car la sécurité du routage ne peut pas être résolue par un seul fournisseur. Le réseau qui origine, l'upstream qui accepte, le pair qui propage et le downstream qui valide façonnent tous le résultat. Les normes volontaires telles que le filtrage, l'anti-usurpation, la coordination et la validation mondiale rendent visible le comportement d'interconnexion privé comme une attente publique. Elles ne garantissent pas la conformité, mais elles définissent ce que les opérateurs responsables devraient pouvoir montrer.

Pour l'incident de juin 2019, l'angle MANRS est direct. La fuite est devenue nuisible parce que des informations de routage incorrectes ont échappé à une frontière relationnelle et ont été largement propagées. Filtrer les annonces des clients et maintenir des informations de routage précises sont des devoirs de prévention centraux. La coordination et la disponibilité des contacts sont importantes une fois la fuite en cours. La validation est importante dans les réseaux qui reçoivent la route. Le système a besoin de tous ces contrôles car aucune couche unique n'attrape toutes les défaillances.

La réponse de Cloudflare devrait donc être jugée en partie par la manière dont elle a utilisé sa position sur le marché pour pousser ces normes. A-t-elle exigé une meilleure hygiène de routage de la part des fournisseurs de transit? A-t-elle publicisé le rôle du filtrage? A-t-elle facilité ou rendu plus visible l'adoption de la sécurité du routage? A-t-elle soutenu l'éducation publique pour que les clients comprennent pourquoi les choix upstream de leur fournisseur importent? Ces actions peuvent transformer une panne en pression sur l'écosystème.

Les clients peuvent aussi utiliser des questions de type MANRS dans leurs achats. Le fournisseur filtre-t-il les routes des clients? Valide-t-il le RPKI? Maintient-il des objets de route précis? A-t-il des contacts de sécurité de routage 24h/24? Participe-t-il à des initiatives reconnues de sécurité du routage? Publie-t-il des rapports d'incident en cas de problème de routage? Un client qui achète de la sécurité en périphérie devrait poser des questions sur la sécurité du routage car la périphérie n'est accessible qu'à travers le système de routage.

Le point n'est pas que les normes volontaires remplacent la régulation ou le contrat. Le point est que le comportement de routage se situe souvent entre les contrats privés et le préjudice public. Les attentes de type MANRS donnent aux clients et aux pairs un vocabulaire pour s'interroger sur ce comportement. La réparation vérifiable dépend d'un vocabulaire qui peut être testé.

Les preuves BGP publiques font partie du dossier d'incident

Les fuites de route sont inhabituelles parmi les incidents d'infrastructure car les observateurs extérieurs peuvent en voir des parties importantes. RouteViews, RIPE RIS et d'autres collecteurs ne révèlent pas l'intention privée du routeur, mais ils peuvent montrer les annonces, les retraits, les chemins AS et le timing depuis de nombreux points de vue. Ces preuves publiques aident à valider ou contester les récits d'incident. Elles aident aussi les fournisseurs affectés à expliquer ce qui s'est passé sans demander aux clients d'accepter chaque affirmation sur la foi.

L'analyse publique de Cloudflare a utilisé des preuves de routage pour montrer comment la panne s'est développée. C'est une bonne pratique. Un post-mortem de fuite de route devrait inclure suffisamment de données de route publiques pour rendre le mécanisme lisible: quels préfixes ont été affectés, quels chemins AS étaient impliqués, ce qui a changé au fil du temps, quand la propagation s'est arrêtée et quelles atténuations ont compté. Le but n'est pas de submerger les lecteurs avec des tables BGP. C'est de rendre l'histoire causale vérifiable.

Les preuves publiques protègent aussi contre les blâmes vagues. Si un fournisseur dit qu'un upstream a fui des routes, le registre de route devrait soutenir cette affirmation. Si un upstream dit qu'il a corrigé le filtrage, le comportement de route ultérieur devrait être cohérent avec la correction. Si un réseau dit qu'il rejette les routes RPKI invalides, une mesure publique devrait pouvoir tester cela en termes généraux. Plus les affirmations de sécurité du routage deviennent mesurables, moins il y a de place pour une réparation basée uniquement sur la réputation.

Les clients devraient demander des preuves de route post-incident dans une forme utilisable. Un court récit est utile pour les dirigeants. Une annexe technique est utile pour les équipes réseau. Une chronologie est utile pour les gestionnaires d'incidents. Une liste des contrôles modifiés est utile pour les propriétaires de risques. Un client ne devrait pas avoir besoin d'être un expert BGP pour comprendre si le fournisseur est passé de l'explication à la réparation.

Les preuves de route publiques ont des limites. Elles peuvent ne pas capturer chaque pair privé, décision politique ou alarme interne. Elles peuvent être bruyantes. Elles peuvent nécessiter une interprétation experte. Mais leurs limites ne sont pas une raison pour les omettre. Dans la responsabilité du routage, des preuves publiques incomplètes valent toujours mieux que l'apaisement privé seul.

La responsabilité du fournisseur de transit est le point à fort levier

L'incident de juin 2019 a montré une fois de plus que les fournisseurs de transit ont un fort levier. Un petit réseau peut fuir. Un optimiseur de route peut mal se comporter. Mais un grand fournisseur de transit peut décider si cette route devient largement crue. Les filtres clients, les limites de préfixe, la validation de route et les politiques relationnelles du fournisseur sont des contrôles de sécurité publique car ils déterminent jusqu'où les mauvaises informations voyagent.

C'est là que les incitations commerciales peuvent échouer. Les fournisseurs de transit rivalisent sur la portée, la performance et le prix. Le filtrage et la validation exigent un effort opérationnel et peuvent créer des frictions avec les clients. Si le marché ne récompense pas l'hygiène de routage, les fournisseurs peuvent sous-investir jusqu'à ce qu'un incident crée un coût de réputation. Les clients et les réseaux affectés devraient donc faire de l'hygiène de routage une partie de la sélection des fournisseurs et de la pression de peering.

La critique publique de Cloudflare du point d'amplification a rempli une fonction de marché utile. Elle a nommé la défaillance à fort levier. Mais nommer n'est que le début. La réparation vérifiable exige des preuves que les politiques de transit ont changé, que les routes invalides ou non autorisées sont rejetées, que les ensembles de routes clients sont maintenus, et que les fuites de route déclenchent un confinement rapide. Certaines de ces preuves peuvent provenir d'engagements publics; d'autres de mesures; d'autres d'exigences contractuelles; d'autres de l'absence future d'incidents associée à un audit.

Les fournisseurs affectés ont aussi du levier. Un grand réseau de périphérie peut choisir ses relations de transit, définir des préférences de peering, publier des exigences de sécurité de routage et éduquer les clients sur l'hygiène des fournisseurs. Il ne peut pas forcer chaque réseau sur Internet à valider, mais il peut déplacer les incitations autour de sa propre interconnexion. Si un fournisseur vend de la sécurité et de la fiabilité, l'achat de sécurité de routage fait partie du produit, pas seulement le travail d'arrière-plan de l'équipe réseau.

La leçon politique plus large est que le filtrage en amont devrait être traité comme un devoir attaché à la portée. Plus un réseau vend de portée mondiale, plus il peut créer de préjudice public en acceptant de mauvaises routes. Ce devoir devrait être visible dans les normes, les contrats, les audits et les rapports post-incident.

La continuité client a des limites en cas de défaillance de routage

Les clients demandent souvent ce qu'ils auraient pu faire différemment après une panne de fournisseur. Dans une fuite de route affectant un grand fournisseur de périphérie, la réponse peut être inconfortable: pas grand-chose en temps réel, à moins que le client n'ait préconstruit des chemins de livraison indépendants. Si l'Internet public détourne le trafic loin des chemins légitimes du fournisseur, l'origine d'un client peut être saine et toujours inaccessible via la périphérie attendue.

Le basculement DNS peut aider dans certaines architectures, mais il peut être contraint par la mise en cache, la configuration des certificats, la capacité de l'origine et la disponibilité d'un fournisseur alternatif.

Cela ne signifie pas que les clients sont impuissants. Ils peuvent classer les services critiques, maintenir des pages de statut alternatives, utiliser un multi-CDN ou des retours à l'origine directe pour certaines charges de travail, surveiller depuis des réseaux diversifiés, et éviter de placer chaque canal de communication publique derrière le même fournisseur. Mais ces mesures nécessitent une planification. Pendant une fuite de route, l'improvisation est rarement suffisante.

La responsabilité de Cloudflare envers les clients est donc en partie explicative. Elle devrait dire aux clients quels risques Cloudflare peut réduire grâce au RPKI, à la surveillance des routes et à la sélection de transit, et quels risques nécessitent une architecture client. Un fournisseur qui laisse entendre qu'il peut absorber toutes les défaillances de routage Internet invite à une confiance mal placée. Un fournisseur qui explique le risque résiduel aide les clients à prendre de meilleures décisions de continuité.

Les contrats clients et les évaluations des risques devraient refléter cela. Un engagement de niveau de service peut ne pas couvrir tout l'impact opérationnel des fuites de route. Les crédits ne maintiennent pas un service accessible. Les clients devraient demander si les charges de travail critiques ont besoin de diversité de livraison, si cette diversité est vraiment indépendante, et si les canaux de communication d'urgence survivent à la même défaillance de routage. Les réponses peuvent différer selon la charge de travail, mais les questions sont obligatoires pour les services à fort impact.

L'incident de fuite de route montre aussi que le risque de dépendance peut être invisible jusqu'à la défaillance. Un client peut ne pas savoir quelles relations de transit ou politiques de route façonnent son accessibilité via un fournisseur. C'est pourquoi la transparence du fournisseur est importante. Les clients ne peuvent pas gérer ce que le fournisseur refuse de rendre lisible.

La réparation vérifiable a besoin d'une liste de contrôle

Un dossier de réparation de fuite de route crédible devrait comporter des éléments observables. Premièrement, une chronologie précise de la propagation de la route, de la détection, de l'atténuation et de la récupération. Deuxièmement, une carte des rôles identifiant l'origine, l'amplificateur, les préfixes affectés et les réseaux de validation lorsqu'ils sont connus. Troisièmement, des preuves d'origine de route: ROAs, choix de maxLength et posture de validation. Quatrièmement, des preuves de filtrage: contrôles des ensembles de routes clients, rejet de routes invalides et méthodes de prévention des fuites de route.

Cinquièmement, des preuves de coordination: contacts, escalade et communication avec les réseaux responsables. Sixièmement, des conseils aux clients sur le risque résiduel et les conceptions de continuité possibles.

Une telle liste de contrôle aurait fait de l'événement de juin 2019 plus qu'un récit. Cloudflare a fourni une explication publique substantielle et un plaidoyer. La prochaine étape de responsabilité est de relier chaque affirmation à un artefact durable. Si le RPKI fait partie de la réponse, montrez l'adoption. Si le filtrage en amont fait partie de la réponse, énoncez les attentes pour les upstreams. Si les collecteurs de route publics soutiennent la chronologie, incluez suffisamment de données pour inspecter. Si les clients ont besoin de changements d'architecture, dites-le directement.

Cette liste de contrôle protège aussi les fournisseurs affectés. Lorsque le fournisseur peut montrer qu'il a publié des ROAs, validé des routes, surveillé le BGP public, choisi un transit responsable et escaladé rapidement, les clients peuvent voir que le risque résiduel venait de l'écosystème de routage plus large. Sans ces preuves, les clients peuvent n'entendre que de l'apaisement. La preuve est la meilleure défense du fournisseur lorsqu'il n'a vraiment pas causé le défaut.

La réparation vérifiable devrait être reproductible d'un incident à l'autre. La même structure peut s'appliquer aux fuites affectant les CDN, les fournisseurs cloud, les banques, les portails gouvernementaux ou les dépôts de logiciels. Les détails diffèrent, mais les éléments de responsabilité restent: autorité de route, contrôle de propagation, validation, surveillance, coordination et continuité client.

La liste de contrôle devrait aussi être mise à jour à mesure que la technologie évolue. Les rôles BGP et les mécanismes Only-to-Customer de la RFC 9234 abordent la prévention des fuites consciente des relations que la seule validation d'origine RPKI ne peut pas résoudre. Les fournisseurs ne devraient pas figer leur modèle de réparation aux contrôles disponibles en 2019. Un programme de réparation authentique adopte de meilleurs mécanismes à mesure qu'ils deviennent déployables.

Le plaidoyer est plus fort lorsqu'il est associé aux achats

Cloudflare a souvent utilisé sa plateforme publique pour plaider en faveur d'une meilleure sécurité du routage. Le plaidoyer est important car la sécurité du routage est un travail d'action collective. Mais le plaidoyer devient plus fort lorsqu'il est associé à des engagements opérationnels et d'achat. Un fournisseur peut écrire sur le RPKI tout en choisissant des partenaires, des pairs et des arrangements de transit qui reflètent les mêmes valeurs. Il peut demander aux clients de s'en soucier tout en montrant qu'il s'en soucie dans ses propres achats réseau.

Ce couplage est important car l'adoption de la sécurité du routage peut souffrir de dynamiques de passager clandestin. Si les réseaux responsables valident mais que les réseaux irresponsables propagent toujours de mauvaises routes, tout le monde reste exposé. Les grands fournisseurs peuvent changer les incitations en faisant de l'hygiène de routage une partie des relations commerciales. Un fournisseur de transit qui risque de perdre des clients importants en raison d'un filtrage faible a une raison plus forte de s'améliorer. Un pair qui ne peut pas maintenir des objets de route fait face à plus de scrutiny.

Un réseau qui rejette les invalides peut faire la publicité de sa maturité.

Les clients peuvent renforcer la même incitation. Ils peuvent demander aux fournisseurs de périphérie quels fournisseurs de transit ils utilisent, s'ils valident le RPKI, s'ils maintiennent des contrôles de type MANRS, et comment ils répondent aux fuites. Tous les détails ne seront pas publics, mais la pression répétée des acheteurs change la conversation. La sécurité du routage devrait faire partie des achats de fiabilité, pas un sujet de niche d'ingénierie réseau.

La position de fournisseur affecté de Cloudflare lui donne de la crédibilité pour pousser ce programme. Elle a subi le préjudice et a pu l'expliquer à un large public. La norme de responsabilité est de continuer à convertir cette crédibilité en pression mesurable sur l'écosystème. Un article de blog persuasif est utile; un marché du routage changé est mieux.

Le même principe s'applique à chaque fournisseur qui vend de l'accessibilité sécurisée. Si la promesse du produit inclut de maintenir les clients en ligne et protégés, alors l'achat de sécurité du routage est un travail produit. La frontière entre les opérations réseau et la confiance client est artificielle lors d'une panne.

Les fuites de route exposent les limites de la redondance en périphérie

Cloudflare exploite un vaste réseau mondial de périphérie, mais l'incident de fuite de route a montré que la redondance physique et logicielle n'élimine pas la dépendance au routage interdomaine. Un fournisseur peut avoir de nombreux centres de données, de nombreux serveurs et une gestion de trafic sophistiquée, mais être toujours affecté lorsque l'Internet croit en un mauvais chemin. La redondance au sein du domaine du fournisseur est nécessaire, mais elle n'est pas la même que l'indépendance de routage. Le chemin public vers la périphérie fait partie du service.

Cela compte pour les attentes des clients. Les clients achètent souvent des services de périphérie parce qu'ils supposent que l'échelle crée l'immunité. L'échelle crée de la capacité et de nombreuses options de récupération, mais elle crée aussi plus de relations d'interconnexion et plus d'exposition aux décisions de routage des autres. Si un grand fournisseur de transit propage de mauvaises routes, une périphérie mondiale peut devenir globalement mal atteinte de manières spécifiques. Les clients doivent comprendre que la résilience interne du fournisseur et l'hygiène de routage externe d'Internet sont des couches différentes.

La communication publique de Cloudflare peut réduire cet écart d'attentes en distinguant la résilience du service du risque de l'écosystème de routage. Un post-mortem devrait dire quelles parties étaient sous le contrôle de Cloudflare, lesquelles étaient en dehors, et quelles atténuations comblent la frontière. La publication RPKI est un pont. Le rejet de routes invalides en est un autre. La sélection de transit et la politique de peering en sont d'autres. La surveillance BGP publique en est un autre. La livraison multi-fournisseur côté client peut en être un autre pour les charges de travail à haute criticité.

Sans cette explication en couches, les clients peuvent soit trop faire confiance au fournisseur, soit le blâmer à tort pour chaque défaillance de route externe.

La leçon de redondance en périphérie affecte aussi les exercices d'incident. Les fournisseurs devraient tester non seulement la perte de centre de données et la régression logicielle, mais aussi les scénarios de détournement de route, de fuite de route, d'acceptation d'origine invalide et de mauvais comportement du fournisseur de transit. Ces exercices devraient inclure la communication avec les clients car les incidents de routage sont déroutants pour les équipes non réseau.

Un client voyant des erreurs intermittentes depuis certaines régions peut ne pas savoir si le problème vient de la santé de l'origine, du DNS, du logiciel CDN, du filtrage FAI ou de la propagation de route. La capacité du fournisseur à expliquer rapidement la couche fait partie de la résilience.

Les meilleures preuves de réparation incluent donc une couverture de scénarios. Le fournisseur a-t-il testé la détection de fuite de route? A-t-il répété l'escalade de transit? A-t-il vérifié l'exactitude des ROAs? A-t-il surveillé les chemins AS suspects? Avait-il un langage prêt pour les clients en cas d'incidents de routage? Ces questions transforment le routage d'un domaine réservé aux experts en une obligation de service responsable.

Les faux chemins créent une dette de confiance

Une fuite de route est un événement de dette de confiance. Elle révèle que des réseaux ont accepté un chemin qu'ils n'auraient pas dû accepter, ou propagé une route à travers une relation où elle n'aurait pas dû voyager. La dette est payée par les fournisseurs et utilisateurs affectés pendant la panne, mais elle reste ensuite si les hypothèses de confiance sous-jacentes ne sont pas corrigées. L'apaisement peut calmer le moment. La réparation rembourse la dette.

La dette de confiance est cumulative. Chaque fuite de route publique enseigne aux clients que l'accessibilité d'Internet dépend de contrôles qu'ils ne voient pas. Si la réponse n'est qu'un récit, la confiance s'affaiblit car le prochain incident semble inévitable. Si la réponse produit des améliorations mesurables, la confiance peut se rétablir car le système devient plus inspectable. L'adoption du RPKI, les engagements de filtrage de route et la surveillance de route publique ne sont pas seulement de l'hygiène technique; ce sont des outils de reconstruction de la confiance.

Le rôle de Cloudflare est compliqué car elle est à la fois victime de défaillances de confiance de routage et vendeuse de services de confiance Internet. Ce double rôle élève la norme. Les clients s'attendent à ce que l'entreprise non seulement récupère, mais explique la faiblesse d'Internet et plaide pour des correctifs crédibles. Lorsque Cloudflare publie des explications sur la sécurité du routage, elle convertit son propre incident en éducation publique. La prochaine étape est de montrer quelles parties de cette éducation sont opérationnalisées dans son réseau et ses relations commerciales.

La dette de confiance appartient aussi aux réseaux amplificateurs. Un fournisseur de transit qui accepte et propage de mauvaises routes endommage la confiance au-delà de ses clients directs. La dette devrait le suivre dans les futurs achats et conversations de peering. A-t-il changé les filtres? A-t-il validé plus de routes? A-t-il rejoint ou respecté les normes de sécurité du routage? A-t-il fait un rapport transparent? Sinon, le marché a peu de raisons de croire que le même comportement ne se reproduira pas.

Pour les clients, la dette de confiance devrait apparaître dans les registres de risques. Si un service critique dépend d'un fournisseur exposé aux incidents de routage mondiaux, le risque devrait nommer le mode de défaillance et les contrôles. Il ne devrait pas être caché sous un langage générique de panne Internet. La spécificité est ce qui permet de mesurer la réparation.

La longueur maximale est une décision de gouvernance

La réparation RPKI ne dépend pas seulement de la création de ROAs, mais de leur création soigneuse. Une ROA autorise un AS d'origine et peut définir une longueur de préfixe maximale. Cette longueur maximale compte. Si elle est trop large, elle peut autoriser des annonces plus spécifiques qui affaiblissent la protection. Si elle est trop étroite, une ingénierie du trafic légitime ou une désagrégation d'urgence peut devenir invalide. Les preuves d'origine de route nécessitent donc une gouvernance, pas seulement une publication de case à cocher.

Pour un fournisseur de périphérie mondial, les décisions de maxLength devraient être liées à une pratique de routage documentée. Quels préfixes sont normalement annoncés? Quelles spécificités sont utilisées pour l'ingénierie du trafic? Lesquelles pourraient être utilisées en cas d'urgence? Lesquelles ne devraient jamais apparaître? Qui approuve les changements? Comment les ROAs sont-elles testées avant publication? À quelle vitesse les erreurs peuvent-elles être corrigées? Ce sont des questions opérationnelles avec des conséquences pour les clients.

La discussion sur la fuite de route de juin 2019 rend cela concret car les fuites et détournements de route exploitent souvent la préférence pour les routes plus spécifiques ou les erreurs de propagation. Le RPKI peut rendre certaines fausses origines invalides, mais il peut aussi créer un faux sentiment de sécurité si les ROAs sont trop permissives. La réparation vérifiable doit donc inclure la preuve que l'autorité de route est précise et maintenue. Un enregistrement ROA obsolète ou bâclé n'est pas une réparation. C'est une nouvelle source de risque.

Les clients n'ont pas besoin d'inspecter chaque ligne de ROA, mais les clients sophistiqués et les observateurs publics devraient pouvoir voir qu'un fournisseur a une posture RPKI disciplinée. Les outils publics peuvent vérifier l'existence et la validité. Les déclarations des fournisseurs peuvent expliquer la politique. Les rapports d'incident peuvent décrire si la validation d'origine de route a aidé ou aurait aidé. C'est là que les artefacts techniques deviennent des artefacts de gouvernance.

L'autorité de route intersecte aussi l'intégration des clients. Si un CDN ou un fournisseur de périphérie annonce des préfixes appartenant aux clients ou prend en charge des arrangements BYOIP, la coordination ROA fait partie du risque client. Le fournisseur et le client doivent aligner l'autorisation d'origine, le maxLength et les procédures d'urgence. Un décalage peut créer des routes invalides ou affaiblir la protection. La réparation vérifiable devrait couvrir ces cas périphériques clients, pas seulement les préfixes appartenant au fournisseur.

Les fuites relationnelles nécessitent des preuves relationnelles

La validation d'origine RPKI répond à une question spécifique: cet AS d'origine est-il autorisé pour ce préfixe? Les fuites de route posent souvent une question différente: cette route aurait-elle dû être transmise d'une relation à une autre? Une route peut être valide en origine et quand même fuir. C'est pourquoi les contrôles conscients des relations tels que le filtrage de route, les rôles BGP et les mécanismes Only-to-Customer sont importants. La réparation vérifiable doit aborder la couche relationnelle.

Dans l'événement de juin 2019, le modèle nuisible impliquait une propagation à travers des réseaux où la route n'aurait pas dû se propager à cette échelle. Les politiques privées exactes ne sont pas entièrement visibles pour les clients, donc les preuves de réparation publiques doivent décrire la classe de contrôle. Le fournisseur a-t-il exigé des filtres de préfixe spécifiques aux clients? A-t-il classé les rôles des voisins? A-t-il limité la propagation des routes en fonction de la relation commerciale? A-t-il maintenu des données IRR et RPKI précises? A-t-il surveillé les anomalies de chemin inconsistantes avec les relations normales?

La RFC 9234 est importante car elle représente une tentative de normalisation de l'encodage des rôles relationnels dans la prévention des fuites BGP. Elle est postérieure à l'incident, elle ne devrait donc pas être utilisée pour juger le comportement de 2019 par un mécanisme futur. Elle devrait être utilisée pour élever la norme de réparation actuelle. Les fournisseurs ne devraient pas s'arrêter aux contrôles qui étaient courants lorsque l'incident s'est produit. Ils devraient demander quels mécanismes plus récents peuvent réduire la même classe de risque maintenant.

Les preuves relationnelles sont plus difficiles à publier que les preuves d'origine car les relations commerciales peuvent être sensibles. Néanmoins, les fournisseurs peuvent divulguer des engagements politiques sans exposer chaque terme privé. Ils peuvent déclarer que les routes clients sont filtrées par rapport aux préfixes attendus, que les routes RPKI invalides sont rejetées, que les relations de pair et de client sont classifiées, que les fuites de route déclenchent des alarmes, et que les fournisseurs de transit sont évalués pour l'hygiène de routage.

Ils peuvent aussi soutenir les normes industrielles qui rendent ces déclarations comparables.

La valeur pour le client est la clarté. Si un fournisseur dit qu'il a le RPKI mais ne dit rien sur les fuites de route, les clients peuvent surestimer la protection. S'il distingue la validation d'origine du filtrage relationnel, les clients reçoivent une image de risque plus honnête. Les images de risque honnêtes font partie de la réparation.

Le langage des incidents devrait éviter d'aplatir la causalité

Les incidents de routage sont techniquement denses, et les incidents denses sont faciles à aplatir. Une entreprise peut dire qu'une fuite de route s'est produite, qu'un upstream en est la cause, que les services ont été impactés et que la remédiation est en cours. Ce langage peut être vrai mais insuffisant. Un langage aplati cache qui avait quel contrôle, quels contrôles ont échoué et quels contrôles ont changé. Une culture de réparation vérifiable utilise une causalité précise.

Une causalité précise séparerait la source de la fuite, l'optimiseur ou mécanisme d'automatisation, le réseau amplificateur, les préfixes affectés, les récepteurs validateurs ou non validateurs, le chemin de détection et les symptômes visibles par le client. Elle énoncerait aussi l'incertitude là où les preuves publiques sont incomplètes. Cela aide les clients à faire confiance au rapport car il ne prétend pas que chaque détail privé est connu. Cela empêche aussi le fournisseur affecté d'utiliser une défaillance upstream comme explication générale pour tout impact client.

L'analyse d'incident de Cloudflare était plus forte qu'une déclaration générique car elle nommait le comportement de routage et expliquait pourquoi le filtrage en amont était important. La norme plus large devrait être que chaque incident de routage majeur inclut suffisamment de structure causale pour que les clients mettent à jour leurs contrôles. Une équipe de sécurité devrait pouvoir demander: le RPKI aurait-il aidé? La prévention des fuites de route aurait-elle aidé? La livraison multi-fournisseur aurait-elle aidé? Notre fournisseur a-t-il surveillé rapidement? Nos propres communications de statut ont-elles survécu?

Le langage affecte aussi les incitations publiques. Si les rapports décrivent les incidents de routage comme des bizarreries Internet inévitables, les opérateurs ont moins de pression pour s'améliorer. Si les rapports décrivent les filtres manquants exacts ou les défaillances de validation, les réseaux responsables font face à un examen. Le point n'est pas la honte publique pour elle-même. C'est de rendre les modes de défaillance suffisamment spécifiques pour que le marché puisse récompenser la réparation.

La précision devrait s'étendre aux affirmations de récupération. Un fournisseur devrait distinguer le retrait de route, la convergence de propagation de route, la récupération de service, la récupération visible par le client et la surveillance post-incident. Ces jalons peuvent différer. Une route peut être corrigée avant que les caches, sessions ou moniteurs clients ne reviennent à la normale. Les clients ont besoin de cette nuance pour leurs propres rapports.

La norme de réparation est la preuve publique

La réponse de Cloudflare à la fuite de route de juin 2019 est précieuse car elle a rendu compréhensible une défaillance de routage invisible pour un large public. Mais la norme de responsabilité de l'article est plus élevée que l'explication. Le fournisseur affecté, le fournisseur de transit amplificateur et la communauté de routage plus large devraient laisser une preuve publique que la faiblesse a été réduite. La preuve peut être partielle. Elle peut être technique. Elle peut être répartie entre les dépôts RPKI, les collecteurs de routes, les engagements MANRS, les politiques des fournisseurs et les rapports d'incident.

Mais elle doit être plus que de la confiance.

Cloudflare contrôlait des parties importantes de cette preuve: sa propre autorité de route, sa surveillance, son éducation publique, sa posture de validation, ses conseils aux clients et sa pression commerciale. Verizon et le réseau fuyard contrôlaient d'autres parties: le filtrage, la discipline de politique de route et la propagation. Les clients ne contrôlaient que les options de continuité préconstruites et la pression d'achat. Cette carte de contrôle explique pourquoi l'apaisement seul est insuffisant. Chaque acteur doit montrer la réparation au point qu'il contrôle.

La leçon durable est que l'accessibilité d'Internet n'est pas une confiance auto-exécutante. C'est un ensemble de promesses opérationnelles échangées via BGP, DNS, les registres, les contrats et les relations de peering. Lorsque ces promesses échouent, la réponse doit être inspectable. Une fuite de route qui perturbe un fournisseur de périphérie mondial devrait produire un meilleur registre public de qui peut originer, qui peut propager, qui valide, qui surveille et qui peut récupérer.

La meilleure contribution de Cloudflare après la fuite n'a pas été simplement de dire qu'un autre réseau a causé le problème. C'était de rendre le problème de sécurité du routage visible. La prochaine étape pour chaque fournisseur est de rendre la réparation visible aussi. Les clients ne devraient pas avoir à choisir entre croire une marque et comprendre une route. Ils devraient pouvoir voir la preuve que l'apaisement est devenu un routage plus sûr.