La réponse de Cloudflare à la fuite de routes a rendu la réparation vérifiable plus importante que 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 correctement mis l'accent sur les défaillances de sécurité du routage en dehors de son réseau direct.
• Le nouvel angle est la réparation vérifiable par opposition à la réassurance. Après une fuite de route, les clients d'un fournisseur ont besoin de plus qu'une explication rassurante; ils ont besoin de preuves que l'autorité d'origine des routes, le filtrage en amont, la validation et la surveillance se sont améliorés.
• Cloudflare n'était pas le fuyard initial selon les archives publiques, mais il avait un contrôle pratique sur sa propre autorité de route, la promotion de RPKI, la communication avec les clients, la surveillance, la pression sur les transitaires et l'explication publique du risque résiduel.
• Verizon et le réseau fuyard contrôlaient des points de propagation à fort effet de 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 anonyme.
• La leçon durable est que les incidents de routage devraient laisser des artéfacts mesurables: ROA, rejet des routes invalides, modifications des filtres, exigences envers les pairs, données de routage publiques, chronologies des incidents et conseils aux clients sur ce qui peut et ne peut pas être sécurisé par la seule action du fournisseur.

Registre des preuves et leur utilisation

Cet article utilise l'analyse d'incident publique de Cloudflare comme un compte rendu de fournisseur affecté de première main, des sources externes de routage et de l'industrie pour le contexte de la sécurité du routage, et les RFC ou les directives gouvernementales pour les contrôles actuels BGP, RPKI et de fuite de routes. 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.

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

Les fuites de routes 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 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 petit réseau. Cloudflare était un fournisseur affecté, pas la source initiale des mauvaises informations de routage. Mais les clients n'achètent pas seulement une attribution de responsabilité. Ils achètent un service accessible.

Après un incident de routage, la réassurance doit se transformer en preuve de réparation.

Les preuves de réparation répondent à des questions que la réassurance 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 sur ses pairs ou sélectionné ceux-ci en fonction de leur hygiène de routage? Les clients peuvent-ils voir si les données de routage publiques corroborent l'analyse post-incident? 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 parce que l'entreprise se positionnait déjà comme un défenseur de la sécurité du routage. Elle a publié des explications sur RPKI et a attiré l'attention sur la nécessité du filtrage et de la validation des routes. Ce plaidoyer est précieux. La question de la responsabilité est de savoir comment le rendre vérifiable. Un fournisseur peut dire que le système de routage doit s'améliorer. Les clients ont besoin de savoir ce que le fournisseur lui-même a fait: ROA, politiques de validation, exigences de transit, surveillance, communications avec les clients et exercices d'incidents.

Cette distinction n'est pas pointilleuse. 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 pair. 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 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 qui ne laisse qu'un article de blog a appris moins à Internet qu'une fuite qui laisse une validation mesurable, de meilleurs filtres et une pression publique sur la responsabilité. La leçon 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 carte utile de fuite de route sépare les rôles. Un réseau a fui ou a créé des informations de routage problématiques. Un autre réseau avec une portée plus large les a acceptées et propagées. Des 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 panne de service sans contrôler aucune de ces décisions de routage.

Cette carte des rôles évite deux erreurs. La première erreur est de blâmer le fournisseur affecté pour chaque panne d'accessibilité. Cloudflare ne contrôlait pas l'acceptation de route de Verizon ni l'optimiseur de route du petit réseau. La deuxième erreur est de dédouaner complètement le fournisseur affecté parce que la fuite a commencé ailleurs. Cloudflare contrôlait encore sa propre autorité de route, sa propre posture de validation, sa propre surveillance, sa propre communication client et sa propre pression commerciale sur ses partenaires réseau. La responsabilité est distribuée, pas dissoute.

Le rôle de Verizon était important parce que l'amplification détermine le rayon d'impact. Une mauvaise route d'un petit réseau peut rester petite si les fournisseurs 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 courtoisie 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 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 effet de levier. Si ces outils peuvent fuir des routes à travers les relations entre fournisseurs, ils peuvent transformer l'ingénierie de trafic commercial en panne publique. L'automatisation ne réduit pas la responsabilité; elle augmente la nécessité de contraintes, de tests de politique de route et de surveillance.

Le rôle de fournisseur affecté de Cloudflare comporte une obligation différente: rendre visible la défaillance du contrôle externe, l'expliquer avec précision et transformer l'événement en des exigences de sécurité de routage 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. La clé est de rendre la réparation mesurable.

RPKI change la norme de preuve

RPKI est important car il transforme certaines questions d'autorité de route en données vérifiables cryptographiquement. Un détenteur de ressources peut publier une autorisation d'origine de route 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 routes, mais cela change ce qui peut être prouvé.

Pour Cloudflare, RPKI n'était pas seulement un correctif technique. C'était un instrument de responsabilité. Si l'entreprise publie des ROA précis pour ses préfixes, les clients et d'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, cela crée une pression sur les réseaux qui acceptent encore une autorité invalide. La réparation devient moins dépendante des 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 original est toujours autorisé tandis 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 annoncer; la prévention des fuites de route demande aussi si la route devrait être propagée à travers une relation donnée. La réparation vérifiable doit inclure à la fois la validation d'origine et le filtrage sensible aux 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 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. 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 artéfacts. Les ROA peuvent être vérifiés. Le rejet de routes invalides peut être mesuré. L'adoption peut être suivie. On peut demander aux opérateurs de réseau pourquoi ils valident ou non. Ces artéfacts donnent aux clients quelque chose de plus solide qu'une excuse post-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 est important parce que la sécurité du routage ne peut pas être résolue par un seul fournisseur. Le réseau qui annonce, le fournisseur amont qui accepte, le pair qui propage, et le client qui valide, tous influencent le résultat. Les normes volontaires comme le filtrage, la lutte contre l'usurpation, la coordination et la validation globale rendent le comportement d'interconnexion privé visible 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, la perspective MANRS est directe. La fuite est devenue nuisible parce que des informations de routage incorrectes ont franchi une frontière de relation et ont été largement propagées. Le filtrage des annonces des clients et le maintien d'informations de routage précises sont des devoirs de prévention centraux. La coordination et la préparation 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 chaque défaillance.

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 promouvoir ces normes. A-t-elle exigé une meilleure hygiène de routage de la part de ses fournisseurs de transit? A-t-elle rendu public le rôle du filtrage? A-t-elle rendu l'adoption de la sécurité du routage plus facile ou plus visible? A-t-elle soutenu l'éducation publique pour que les clients comprennent pourquoi les choix amont de leur fournisseur sont importants? 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. Un fournisseur filtre-t-il les routes de ses clients? Valide-t-il RPKI? Maintient-il des objets de route précis? A-t-il des contacts de sécurité du routage 24h/24? Participe-t-il à des initiatives reconnues de sécurité du routage? Publie-t-il des rapports d'incident lorsque le routage tourne mal? Un client qui achète de la sécurité edge 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églementation 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 poser des questions 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 routes 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 des routeurs, mais ils peuvent montrer les annonces, les retraits, les chemins AS et la synchronisation depuis de nombreux points de vue. Ces preuves publiques aident à valider ou à contester les récits d'incidents. Elles aident également 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 rapport post-mortem sur une fuite de route devrait inclure suffisamment de données de routage publiques pour rendre le mécanisme lisible: quels préfixes ont été affectés, quels chemins AS ont été impliqués, ce qui a changé au fil du temps, quand la propagation s'est arrêtée et quelles atténuations ont été importantes. 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 également contre les accusations vagues. Si un fournisseur dit qu'un fournisseur amont a fuité des routes, l'enregistrement de route devrait soutenir cette affirmation. Si un fournisseur amont dit qu'il a corrigé le filtrage, le comportement ultérieur des routes devrait être cohérent avec la correction. Si un réseau dit qu'il rejette les routes RPKI invalides, la 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 sous 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é, chaque décision de politique ou chaque alarme interne. Elles peuvent être bruyantes. Elles peuvent nécessiter une interprétation experte. Mais leurs limites ne sont pas une raison de les omettre. Dans la responsabilité de routage, des preuves publiques incomplètes restent meilleures que la réassurance privée seule.

La responsabilité du fournisseur de transit est le point de levier le plus élevé

L'incident de juin 2019 a montré à nouveau que les fournisseurs de transit ont un levier élevé. 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 de relation 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 intégrer l'hygiène de routage dans la sélection des fournisseurs et la pression de peering.

La critique publique de Cloudflare du point d'amplification a servi une fonction de marché utile. Elle a nommé la défaillance à fort effet de 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 routes 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'incidents associée à un audit.

Les fournisseurs affectés ont aussi un 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é 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 influencer les incitations autour de sa propre interconnexion. Si un fournisseur vend de la sécurité et de la fiabilité, l'approvisionnement en sécurité de 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 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 panne 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 livraison indépendants. Si l'Internet public achemine le trafic loin des chemins légitimes du fournisseur, l'origine d'un client peut être saine et pourtant ne pas être joignable via la périphérie attendue.

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 d'état alternatives, utiliser un multi-CDN ou des basculements vers l'origine directe pour certaines charges de travail, surveiller depuis des réseaux divers, 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 les clients est donc en partie explicative. Elle devrait dire aux clients quels risques Cloudflare peut réduire via RPKI, la surveillance des routes et la 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 l'impact opérationnel complet des fuites de routes. Les crédits ne maintiennent pas un service joignable. Les clients devraient demander si les charges de travail critiques ont besoin de diversité de livraison, si cette diversité est véritablement indépendante, et si les canaux de communication d'urgence survivent à la même panne 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 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 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 avoir des éléments observables. Premièrement, une chronologie précise de la propagation, de la détection, de l'atténuation et de la récupération de la route. 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: ROA, choix de maxLength et posture de validation. Quatrièmement, des preuves de filtrage: contrôles d'ensemble de routes clients, rejet des 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 artéfact 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 pour les fournisseurs amont. Si les collecteurs de routes publiques 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 également les fournisseurs affectés. Lorsque le fournisseur peut montrer qu'il a publié des ROA, validé des routes, surveillé le BGP public, sélectionné des transitaires 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 peuvent n'entendre que de la réassurance. La preuve est la défense la plus solide du fournisseur lorsqu'il n'a vraiment pas causé la faute.

La réparation vérifiable devrait être reproductible à travers les incidents. 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 également ê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 sensible aux relations que la validation d'origine RPKI seule 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 dès 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 est important 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 opérationnels et d'approvisionnement. Un fournisseur peut écrire sur 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 jumelage est important 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 les irresponsables propagent encore de mauvaises routes, tout le monde reste exposé. Les grands fournisseurs peuvent changer les incitations en intégrant l'hygiène de routage dans les relations commerciales. Un fournisseur de transit qui risque de perdre des clients importants à cause d'un filtrage faible a une raison plus forte de s'améliorer. Un pair qui ne peut pas maintenir ses objets de route fait face à plus d'examen.

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épondent 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 devenir une partie de l'approvisionnement en 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 cet agenda. 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 meilleur.

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

Les fuites de routes exposent les limites de la redondance edge

Cloudflare exploite un grand 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 de trafic sophistiquée, tout en étant affecté lorsque Internet croit un mauvais chemin. La redondance à l'intérieur du domaine du fournisseur est nécessaire, mais elle n'est pas la même chose 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 edge parce qu'ils supposent que l'échelle crée une 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 mondialement mal acheminée 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'attentes en distinguant la résilience de service du risque de l'écosystème de routage. Un rapport post-mortem devrait dire quelles parties étaient sous le contrôle de Cloudflare, lesquelles étaient en dehors, et quelles atténuations font le pont entre les deux. 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 est un autre. 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 à criticité élevée.

Sans cette explication en couches, les clients peuvent soit faire trop confiance au fournisseur, soit le blâmer à tort pour chaque panne 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 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 comportement défaillant du 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 voyant des erreurs intermittentes depuis certaines régions peut ne pas savoir si le problème est la santé de l'origine, le DNS, le logiciel CDN, le filtrage FAI ou la propagation de route. La capacité du fournisseur à expliquer la couche rapidement 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? Avait-il un langage préparé 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 ont 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 subsiste après si les hypothèses de confiance sous-jacentes ne sont pas corrigées. La réassurance peut calmer le moment. 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 pas voir. Si la réponse n'est que narrative, la confiance s'affaiblit parce que le prochain incident semble inévitable. Si la réponse produit des améliorations mesurables, la confiance peut se rétablir parce que le système devient plus inspectable. L'adoption de RPKI, les engagements de filtrage des routes et la surveillance publique des routes 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é parce qu'il est à la fois une victime des défaillances de confiance de routage et un 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 correctifs crédibles. Lorsque Cloudflare publie des explications sur la sécurité du routage, il 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 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 les 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é 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 à la réparation d'être mesurée.

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. Un ROA autorise un AS d'origine et peut définir une longueur de préfixe maximale. Cette longueur maximale est importante. 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 l'ingénierie de trafic ou les urgences peut devenir invalide. La preuve d'origine de route exige donc une gouvernance, pas seulement une publication de case à cocher.

Pour un fournisseur edge mondial, les décisions de maxLength 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 changements? Comment les ROA sont-ils testés 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 parce que les fuites et les détournements de routes exploitent souvent la préférence de route plus spécifique ou les erreurs de propagation. RPKI peut rendre certaines origines fausses invalides, mais il peut aussi créer un faux sentiment de sécurité si les ROA sont trop permissifs. La réparation vérifiable doit donc inclure la preuve que l'autorité de route est précise et maintenue. Un enregistrement 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 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 artéfacts techniques deviennent des artéfacts de gouvernance.

L'autorité de route recoupe également l'intégration des clients. Si un CDN ou un fournisseur edge annonce des préfixes appartenant aux clients ou prend en charge des accords « bring-your-own-IP », la coordination des ROA devient une partie du risque client. Le fournisseur et le client doivent aligner l'autorisation d'origine, la maxLength 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 particuliers client-edge, et non seulement les préfixes appartenant au 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 avoir fuité. C'est pourquoi les contrôles sensibles aux relations, comme le filtrage des routes, les rôles BGP et les mécanismes Only-to-Customer sont importants. La réparation vérifiable doit traiter la couche des relations.

Dans 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 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 exigeait-il des filtres de préfixe spécifiques aux clients? Classifiait-il les rôles de voisinage? Limitait-il la propagation des routes en fonction de la relation commerciale? Maintenait-il des données IRR et RPKI précises? Surveillait-il les anomalies de chemin incompatibles avec les relations normales?

La RFC 9234 est importante car elle représente une tentative sur la voie des normes pour encoder les rôles de relation 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 de relation sont plus difficiles à publier que les preuves d'origine parce que les relations commerciales peuvent être sensibles. Néanmoins, les fournisseurs peuvent divulguer des engagements de politique sans exposer chaque terme privé. Ils peuvent déclarer que les routes des 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 routes déclenchent des alarmes, et que les fournisseurs de transit sont évalués pour l'hygiène de routage.

Ils peuvent également soutenir des normes industrielles qui rendent ces déclarations comparables.

La valeur pour le client est la clarté. Si un fournisseur dit qu'il a RPKI mais ne dit rien sur les fuites de routes, les clients peuvent surestimer la protection. S'il distingue la validation d'origine du filtrage relationnel, les clients reçoivent une image des risques plus honnête. Les images honnêtes des risques 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 fournisseur amont l'a causée, que les services ont été impactés et que des mesures correctives sont 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 le mécanisme d'automatisation, le réseau amplificateur, les préfixes affectés, les récepteurs qui valident 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 parce qu'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 générale de tout l'impact client.

L'analyse d'incident de Cloudflare était plus forte qu'une déclaration générique parce qu'elle a nommé le comportement de routage et a expliqué pourquoi le filtrage amont était important. La norme plus large devrait être que chaque incident de routage majeur inclut suffisamment 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 livraison multi-fournisseur aurait-elle aidé? Notre fournisseur a-t-il surveillé rapidement? Nos propres communications d'état ont-elles survécu?

Le langage affecte aussi 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 les échecs de validation manquants exacts, les réseaux responsables font face à un examen. Le but n'est pas la honte publique pour elle-même. C'est 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, les sessions ou les moniteurs clients 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'agencer les caractères pour rendre le langage écrit lisible, compréhensible et visuellement attrayant. Elle implique la sélection de polices, de tailles de points, de longueurs de lignes, d'interlignes 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 comprennent 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 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é 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 distribuée à travers 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éé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, 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 edge mondial devrait produire un meilleur dossier public sur qui peut annoncer, qui peut propager, qui valide, qui surveille et qui peut se rétablir.

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 la réassurance est devenue un routage plus sûr.