La réponse de Cloudflare à la fuite de route a fait de la réparation vérifiable une priorité sur la réassurance

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 souligné à juste titre les défaillances de sécurité de routage extérieures à son propre réseau.
• La nouvelle perspective est celle de la réparation vérifiable par opposition à la simple réassurance. 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 des routes, le filtrage en amont, la validation et la surveillance ont été améliorés.
• D'après les enregistrements publics, Cloudflare n'était pas le fuyard d'origine, mais il avait un contrôle pratique sur sa propre autorité de route, sa promotion de RPKI, sa communication client, sa surveillance, sa pression sur les transits et son explication publique des risques résiduels.
• Verizon et le réseau fuyard contrôlaient les points de propagation à fort effet de levier. La carte des responsabilités 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 impersonnel.
• La leçon durable est que les incidents de routage devraient laisser des artefacts mesurables: ROA, rejet des routes invalides, modifications de filtres, exigences de pairs, données de route publiques, chronologies d'incident et conseils aux clients sur ce qui peut et ne peut pas être rendu sûr par la seule action du fournisseur.

Registre des preuves et leur utilisation

Cet article utilise l'analyse publique de l'incident par Cloudflare comme compte rendu de fournisseur affecté de première main, des sources de routage et sectorielles externes pour le contexte de sécurité du routage, et des RFC ou des orientations gouvernementales pour les contrôles BGP, RPKI et de fuite de route actuels. Les normes posté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.

La réassurance n'est pas la réparation

Les fuites de route produisent un problème de communication publique prévisible. Le fournisseur affecté veut rassurer ses clients en expliquant que la panne a été causée par des facteurs hors 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 petit réseau. Cloudflare était un fournisseur affecté, pas la source initiale des informations de routage erronées. Mais les clients n'achètent pas seulement une attribution de faute. Ils achètent un service accessible.

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

La preuve de réparation répond à des questions que la réassurance ne peut pas résoudre. Le fournisseur affecté a-t-il publié une autorisation d'origine de route exacte pour ses préfixes? Ses fournisseurs de transit rejettent-ils les routes invalides ou non autorisées? Le fournisseur rejette-t-il lui-même les routes invalides en provenance d'autres? A-t-il fait pression sur ses pairs ou sélectionné ceux-ci en fonction de l'hygiène de routage? Les clients peuvent-ils vérifier si les données publiques de routage corroborent l'autopsie? Le fournisseur divulgue-t-il les risques résiduels 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 en défenseur de la sécurité du routage. Elle a publié des explications sur RPKI et attiré l'attention sur le besoin de filtrage et validation des routes. Ce plaidoyer est précieux. La question de responsabilité est de 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 a fait concrètement: ROA, politiques de validation, exigences de transit, surveillance, communication client et exercices d'incident.

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

La réassurance a aussi une durée de vie limitée. Immédiatement après un incident, elle 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 ne laissant derrière elle qu'un billet de blog a moins appris à Internet qu'une qui laisse une validation mesurable, de meilleurs filtres et une pression publique de responsabilité. La leçon du titre 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 cartographie utile de fuite de route sépare les rôles. Un réseau a fui ou initié 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é altéré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 toute panne d'accessibilité. Cloudflare ne contrôlait ni l'acceptation de route par Verizon ni l'optimiseur de route du petit réseau. La seconde erreur est de disculper entièrement le fournisseur affecté parce que la fuite a commencé ailleurs. Cloudflare contrôlait encore sa propre autorité de route, sa posture de validation, sa surveillance, sa communication client et sa pression commerciale sur ses partenaires réseau. La responsabilité est répartie, pas dissoute.

Le rôle de Verizon était important car l'amplification détermine le rayon d'impact. Une mauvaise route d'un petit réseau peut rester confinée si les transits amont la filtrent. La propagation par un grand fournisseur de transit peut la rendre mondiale. C'est pourquoi le filtrage amont n'est pas une courtoise optionnelle. C'est une obligation de sécurité pour les réseaux qui vendent de la portée. Plus un fournisseur a de portée, plus il doit valider avec soin 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 impact. Si de tels outils sont autorisés à fuir des routes entre relations de fournisseurs, ils peuvent transformer l'ingénierie de trafic commerciale en panne publique. L'automatisation ne réduit pas la responsabilité; elle accroît le besoin de contraintes, de tests de politiques de route et de surveillance.

Le rôle de fournisseur affecté de Cloudflare porte une obligation différente: rendre visible la défaillance de contrôle externe, l'expliquer avec précision et transformer l'événement en exigences de sécurité de route plus fortes. 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 initiale. L'essentiel est de rendre la réparation mesurable.

RPKI change la norme de preuve

RPKI compte parce qu'il transforme certaines questions d'autorité de route en données vérifiables cryptographiquement. Un détenteur de ressource peut publier une autorisation d'origine de route (ROA) indiquant quel système autonome est autorisé à annoncer 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 là où la politique l'exige. Cela ne résout pas toutes les fuites de route, mais change ce qui peut être prouvé.

Pour Cloudflare, RPKI n'était pas simplement une correction technique. C'était un instrument de responsabilité. Si l'entreprise publie des ROA exactes pour ses préfixes, les clients et autres réseaux peuvent inspecter une partie de l'enregistrement d'autorité. Si les réseaux rejettent les routes invalides, certaines annonces d'origine erronée deviennent moins dangereuses. Si Cloudflare mesure et promeut l'adoption, il crée une pression sur les réseaux qui acceptent encore l'autorité invalide. La réparation devient moins dépendante d'assurances privées.

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

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

La valeur publique de RPKI est qu'il crée des artefacts. Les ROA peuvent être vérifiées. Le rejet des routes invalides peut être mesuré. L'adoption peut être suivie. On peut demander aux opérateurs réseau pourquoi ils valident ou non. Ces artefacts donnent aux clients quelque chose de plus solide qu'un simple désolé après incident. Le plaidoyer de Cloudflare pour la sécurité du routage est le plus fort lorsqu'il est lié à de telles preuves inspectables.

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

MANRS importe parce que la sécurité du routage ne peut pas être résolue par un seul fournisseur. Le réseau qui annonce, le transit amont qui accepte, le pair qui propage et l'aval qui valide façonnent tous le résultat. Des normes volontaires comme le filtrage, l'anti-usurpation, la coordination et la validation globale rendent visible le comportement d'interconnexion privé en tant qu'attente publique. Elles ne garantissent pas la conformité, mais définissent ce que les opérateurs responsables devraient pouvoir montrer.

Pour l'incident de juin 2019, le prisme de MANRS est direct. La fuite est devenue nuisible parce que des informations de routage incorrectes ont franchi une barrière relationnelle et ont été largement propagées. Le filtrage des annonces de clients et le maintien d'informations de routage exactes sont des devoirs de prévention centraux. La coordination et la capacité de contact importent une fois la fuite en cours. La validation importe aux 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 façon dont il a utilisé sa position de marché pour pousser ces normes. A-t-il exigé une meilleure hygiène de routage de ses fournisseurs de transit? A-t-il rendu public le rôle du filtrage? A-t-il facilité ou rendu plus visible l'adoption de la sécurité du routage? A-t-il soutenu l'éducation publique pour que les clients comprennent pourquoi les choix de transits de leur fournisseur comptent? Ces actions peuvent transformer une panne en pression sur l'écosystème.

Les clients peuvent aussi utiliser des questions de type MANRS lors de l'approvisionnement. Le fournisseur filtre-t-il les routes clients? Valide-t-il RPKI? Maintient-il des objets de route exacts? A-t-il des contacts de sécurité routage disponibles 24 heures sur 24? Participe-t-il à des initiatives de sécurité routage reconnues? Publie-t-il des rapports d'incident lorsque le routage tourne mal? Un client qui achète de la sécurité edge devrait se renseigner sur la sécurité du routage car l'edge n'est accessible que par le système de routage.

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

Les preuves BGP publiques font partie du registre d'incident

Les fuites de route sont inhabituelles parmi les incidents d'infrastructure car des observateurs extérieurs peuvent en observer des parties importantes. RouteViews, RIPE RIS et d'autres collecteurs ne révèlent pas l'intention privée du routeur, mais peuvent montrer les annonces, retraits, chemins AS et la synchronisation 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 de croire chaque affirmation sur parole.

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. Une autopsie 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 mesures d'atténuation ont compté. Le but n'est pas de submerger les lecteurs de tables BGP. C'est de rendre l'histoire causale vérifiable.

Les preuves publiques protègent aussi contre le blâme vague. Si un fournisseur affirme qu'un transit amont a fui des routes, le registre de route devrait soutenir cette affirmation. Si un transit amont dit avoir corrigé son filtrage, le comportement ultérieur de la route devrait être cohérent avec la correction. Si un réseau dit rejeter les routes RPKI invalides, la mesure publique devrait pouvoir le tester 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 uniquement fondée sur la réputation.

Les clients devraient demander des preuves d'itinéraire post-incident sous une forme utilisable. Un bref 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'incident. 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 bruitées. Elles peuvent nécessiter une interprétation experte. Mais leurs limites ne sont pas une raison de les omettre. En matière de responsabilité de routage, des preuves publiques incomplètes valent toujours mieux que la seule réassurance privée.

La responsabilité des fournisseurs 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 levier important. 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 sont en concurrence 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 un critère de sélection de fournisseur et de pression de peering.

La critique publique par 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 client sont maintenus, et que les fuites de route déclenchent un confinement rapide. Une partie de ces preuves peut provenir d'engagements publics; une partie de mesures; une partie d'exigences contractuelles; une partie de l'absence future d'incident couplée à un audit.

Les fournisseurs affectés ont aussi du levier. Un grand réseau edge peut choisir ses relations de transit, définir ses préférences de peering, publier des exigences de sécurité du routage et éduquer ses clients sur l'hygiène des fournisseurs. Il ne peut pas forcer chaque réseau sur Internet à valider, mais il peut influencer les incitations autour de ses propres interconnexions. Si un fournisseur vend de la sécurité et de la fiabilité, l'approvisionnement en sécurité du routage fait partie du produit, pas seulement du travail de fond de l'équipe réseau.

La leçon politique plus large est que le filtrage amont devrait être traité comme un devoir lié à 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 edge, la réponse peut être inconfortable: pas grand-chose en temps réel, à moins que le client n'ait préétabli des chemins de diffusion indépendants. Si le routage Internet public dévie le trafic hors des chemins légitimes du fournisseur, l'origine d'un client peut être saine et pourtant ne pas être joignable via l'edge attendu.

Le basculement DNS peut aider dans certaines architectures, mais il peut être limité par la mise en cache, la configuration des certificats, la capacité d'origine et la préparation de fournisseurs alternatifs.

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

La responsabilité de Cloudflare envers ses clients est donc en partie explicative. Il devrait dire aux clients quels risques Cloudflare peut réduire par RPKI, surveillance de route et sélection de transit, et quels risques exigent une architecture client. Un fournisseur qui laisse entendre qu'il peut absorber toutes les pannes 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 de risques devraient refléter cela. Un engagement de niveau de service peut ne pas couvrir tout l'impact opérationnel des fuites de route. Des crédits ne maintiennent pas un service joignable. Les clients devraient demander si les charges de travail critiques ont besoin d'une diversité de diffusion, si cette diversité est réellement 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 les charges 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 panne. 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 importe. 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 crédible de réparation de fuite de route devrait comporter des éléments observables. Premièrement, une chronologie précise de la propagation de 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 lorsque connus. Troisièmement, des preuves d'origine de route: ROA, choix de maxLength et posture de validation. Quatrièmement, des preuves de filtrage: contrôles des ensembles de routes client, rejet des routes invalides et méthodes de prévention des fuites.

Cinquièmement, des preuves de coordination: contacts, escalade et communication avec les réseaux responsables. Sixièmement, des conseils client sur les risques résiduels 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. L'étape suivante de responsabilité est de lier chaque affirmation à un artefact durable. Si RPKI fait partie de la réponse, montrez l'adoption. Si le filtrage amont fait partie de la réponse, énoncez les attentes envers les transits amont. Si les collecteurs de routes publics soutiennent la chronologie, incluez suffisamment de données pour inspection. Si les clients ont besoin de changements d'architecture, dites-le directement.

Cette liste de contrôle protège aussi les fournisseurs affectés. Quand le fournisseur peut montrer qu'il a publié des ROA, validé des routes, surveillé le BGP public, choisi des transits responsables et escaladé rapidement, les clients peuvent voir que le risque résiduel provenait de l'écosystème de routage plus large. Sans ces preuves, les clients n'entendent peut-être que de la réassurance. La preuve est la défense la plus solide du fournisseur quand il n'a vraiment pas causé la panne.

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, fournisseurs cloud, banques, portails gouvernementaux ou dépôts 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 traitent de la prévention des fuites tenant compte des relations que la seule validation d'origine RPKI ne peut résoudre. Les fournisseurs ne devraient pas figer leur modèle de réparation aux contrôles disponibles en 2019. Un véritable programme de réparation adopte de meilleurs mécanismes à mesure qu'ils deviennent déployables.

Le plaidoyer est plus fort lorsqu'il est associé à l'approvisionnement

Cloudflare a souvent utilisé sa plateforme publique pour plaider en faveur d'une meilleure sécurité du routage. Le plaidoyer compte parce que la sécurité du routage est un travail d'action collective. Mais le plaidoyer devient plus fort lorsqu'il est associé à des engagements d'approvisionnement et opérationnels. Un fournisseur peut écrire sur RPKI tout en choisissant des partenaires, des pairs et des accords 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.

Cette association importe parce que l'adoption de la sécurité du routage peut souffrir de dynamiques de passager clandestin. Si les réseaux responsables valident mais que ceux qui sont irresponsables propagent encore 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 à cause d'un filtrage faible a une plus forte raison de s'améliorer. Un pair qui ne peut pas maintenir ses objets de route fait face à plus de surveillance.

Un réseau qui rejette les routes invalides peut annoncer cette maturité.

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

La position de fournisseur affecté de Cloudflare lui donne la crédibilité pour pousser cet agenda. Il 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 billet de blog persuasif est utile; un marché du routage changé est meilleur.

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

Les fuites de route exposent les limites de la redondance edge

Cloudflare exploite un vaste réseau edge mondial, 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 du trafic sophistiquée, tout en étant affecté lorsque Internet croit à un mauvais chemin. La redondance au sein du patrimoine du fournisseur est nécessaire, mais elle n'est pas la même chose que l'indépendance de routage. Le chemin public vers l'edge fait partie du service.

Cela importe pour les attentes des clients. Les clients achètent souvent des services edge 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, un edge mondial peut devenir globalement mal acheminé de manière spécifique. 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'attente en distinguant la résilience du service du risque de l'écosystème de routage. Une autopsie devrait dire quelles parties étaient sous le contrôle de Cloudflare, lesquelles étaient en dehors, et quelles mesures d'atténuation relient la frontière. La publication RPKI est un pont. Le rejet des routes invalides en est un autre. La sélection de transit et la politique de peering en sont un autre. La surveillance BGP publique en est un autre. La diffusion multi-fournisseur côté client peut en être un autre pour les charges de travail à criticité élevée.

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 edge affecte également les exercices d'incident. Les fournisseurs devraient tester non seulement la perte de centre de données et les régressions logicielles, mais aussi les scénarios de détournement de route, de fuite de route, d'acceptation d'origine invalide et de mauvaise conduite de fournisseur de transit. Ces exercices devraient inclure la communication client car les incidents de routage sont déroutants pour les équipes non réseau.

Un client rencontrant 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.

La meilleure preuve de réparation inclut donc la 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 ROA? A-t-il surveillé les chemins AS suspects? Disposait-il d'un langage prêt pour les clients en cas d'incident 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 affectés et les utilisateurs pendant la panne, mais elle persiste après si les hypothèses de confiance sous-jacentes ne sont pas corrigées. La réassurance peut calmer le moment présent. La réparation rembourse la dette.

La dette de confiance est cumulative. Chaque fuite de route publique apprend aux clients que l'accessibilité Internet dépend de contrôles qu'ils ne peuvent voir. Si la réponse n'est que narrative, 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 de RPKI, les engagements de filtrage de route et la surveillance publique des routes ne sont pas simplement de l'hygiène technique; ce sont des outils de reconstruction de la confiance.

Le rôle de Cloudflare est compliqué parce qu'il est à la fois victime de défaillances de confiance de routage et vendeur de services de confiance Internet. Ce double rôle élève la norme. Les clients attendent de l'entreprise non seulement qu'elle se rétablisse, mais qu'elle explique la faiblesse d'Internet et promeuve des solutions crédibles. Lorsque Cloudflare publie des explications sur la sécurité du routage, il convertit son propre incident en éducation publique. L'étape suivante consiste à montrer quelles parties de cette éducation sont opérationnalisées dans son réseau et ses relations commerciales.

La dette de confiance incombe également aux réseaux amplificateurs. Un fournisseur de transit qui accepte et propage de mauvaises routes nuit à la confiance au-delà de ses clients directs. La dette devrait le suivre dans les futures conversations d'approvisionnement et de peering. A-t-il changé ses filtres? A-t-il validé plus de routes? A-t-il rejoint ou satisfait aux normes de sécurité du routage? A-t-il rendu compte de manière transparente? Si non, 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é à des 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 ROA, mais de leur création soigneuse. Une ROA autorise un AS d'origine et peut fixer une longueur de préfixe maximale. Cette longueur maximale importe. Si elle est trop large, elle peut autoriser des annonces plus spécifiques qui affaiblissent la protection. Si elle est trop étroite, une désagrégation légitime pour ingénierie de trafic ou urgence peut devenir invalide. La preuve d'origine de route exige donc une gouvernance, et non une simple publication de case à cocher.

Pour un fournisseur edge mondial, les décisions de longueur maximale devraient être liées à une pratique de routage documentée. Quels préfixes sont normalement annoncés? Quels plus spécifiques sont utilisés pour l'ingénierie de trafic? Lesquels pourraient être utilisés en urgence? Lesquels ne devraient jamais apparaître? Qui approuve les modifications? Comment les ROA 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 client.

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 de route plus spécifique ou les erreurs de propagation. RPKI peut rendre certaines fausses origines invalides, mais il peut aussi créer un faux sentiment de sécurité si les ROA sont trop permissives. La réparation vérifiable doit donc inclure la preuve que l'autorité de route est exacte et maintenue. Un registre de ROA périmé ou négligé 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 avertis 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 du fournisseur 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 recoupe également l'intégration des clients. Si un CDN ou fournisseur edge annonce des préfixes appartenant au client ou prend en charge des arrangements BYOIP, la coordination des ROA devient partie du risque client. Le fournisseur et le client doivent aligner l'autorisation d'origine, la longueur maximale et les procédures d'urgence. Un désalignement peut créer des routes invalides ou affaiblir la protection. La réparation vérifiable devrait couvrir ces cas limites client, pas seulement les préfixes du fournisseur.

Les fuites de relation exigent des preuves de relation

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 à l'origine et pourtant fuir. C'est pourquoi les contrôles tenant compte des relations comme le filtrage de route, les rôles BGP et les mécanismes Only-to-Customer importent. La réparation vérifiable doit traiter la couche relationnelle.

Lors de l'événement de juin 2019, le schéma nuisible impliquait une propagation à travers des réseaux où la route n'aurait pas dû se diffuser à cette échelle. Les politiques privées exactes ne sont pas entièrement visibles pour les clients, donc la preuve publique de réparation doit décrire la classe de contrôle. Le fournisseur a-t-il exigé des filtres de préfixe spécifiques au client? 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 exactes? A-t-il surveillé les anomalies de chemin incompatibles avec les relations normales?

La RFC 9234 est importante car elle représente une tentative de normalisation pour encoder les rôles relationnels dans la prévention des fuites BGP. Elle est postérieure à l'incident, donc elle ne devrait pas être utilisée pour juger le comportement de 2019 avec 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 courants au moment de l'incident. Ils devraient se demander quels mécanismes plus récents peuvent réduire la même classe de risque maintenant.

Les preuves de relation sont plus difficiles à publier que les preuves d'origine car les relations commerciales peuvent être sensibles. Néanmoins, les fournisseurs peuvent divulguer des engagements de politique sans exposer chaque condition privée. Ils peuvent déclarer que les routes client sont filtrées par rapport aux préfixes attendus, que les routes RPKI invalides sont rejetées, que les relations pair et 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 route.

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

La valeur client est la clarté. Si un fournisseur dit qu'il a 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 de relation, les clients reçoivent une image du risque plus honnête. Les images honnêtes du risque font partie de la réparation.

Le langage d'incident 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 transit amont l'a causée, 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, le mécanisme d'optimiseur ou d'automatisation, le réseau amplificateur, les préfixes affectés, les récepteurs validants ou non, le chemin de détection et les symptômes visibles par le client. Elle indiquerait aussi l'incertitude lorsque 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 également le fournisseur affecté d'utiliser une défaillance amont comme explication globale de tout l'impact client.

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

Le langage affecte également les incitations publiques. Si les rapports décrivent les incidents de routage comme une bizarrerie inévitable d'Internet, les opérateurs ont moins de pression pour s'améliorer. Si les rapports décrivent les filtres ou pannes de validation manquants exacts, les réseaux responsables font face à un examen. Le but n'est pas la dénonciation publique pour elle-même. C'est de rendre les modes de défaillance assez 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 du 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 client ne reviennent à la normale. Les clients ont besoin de cette nuance pour leurs propres rapports.

Typographie

La typographie est l'art et la technique d'arranger les caractères pour rendre le langage écrit lisible, facile à lire et visuellement attrayant. Elle implique la sélection de polices, de tailles de points, de longueurs de ligne, d'espacement des lignes et d'espacement des lettres.

• La typographie est née avec l'invention des caractères mobiles par Johannes Gutenberg au XVe siècle.
• Les éléments clés incluent le choix de la police, le crénage, l'approche et l'interlignage.
• Une bonne typographie améliore la lisibilité et transmet une ambiance ou un ton dans le design.

La norme de réparation est la preuve publique

La réponse de Cloudflare à la fuite de route de juin 2019 est précieuse parce qu'elle a rendu une défaillance de routage invisible compréhensible à 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é du routage au sens large devraient laisser des preuves publiques que la faiblesse a été réduite. La preuve peut être partielle. Elle peut être technique. Elle peut être répartie entre dépôts RPKI, collecteurs de routes, engagements MANRS, politiques des fournisseurs et 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éétablies et la pression d'approvisionnement. Cette carte de contrôle explique pourquoi la réassurance seule est insuffisante. Chaque acteur doit montrer la réparation au point qu'il contrôle.

La leçon durable est que l'accessibilité Internet n'est pas une confiance auto-exécutoire. C'est un ensemble de promesses opérationnelles échangées via BGP, DNS, registres, contrats et relations de peering. Lorsque ces promesses échouent, la réponse doit être inspectable. Une fuite de route qui perturbe un fournisseur edge mondial devrait produire un meilleur enregistrement public de qui peut annoncer, 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. Ça a été 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 la réassurance est devenue un routage plus sûr.