Résumé

  • Cloudflare indique qu’une opération de nettoyage a supprimé des références obsolètes à des listes de préfixes propres au site de Bogotá, mais a laissé dans une règle d’export IPv6 générée les éléments route-type internal et accept.
  • La suppression du dernier prédicat étroit n’a pas rendu la configuration invalide. Elle a élargi l’ensemble des routes susceptibles de satisfaire la règle et donc d’être exportées.
  • Selon Cloudflare, l’automatisation a appliqué cette politique à un seul routeur de Miami à 20 h 25 UTC le 22 janvier 2026. L’impact public, limité à IPv6, a duré 25 minutes.
  • L’entreprise a décrit l’export de routes apprises auprès de pairs, dont Meta AS32934, depuis Cloudflare AS13335 vers le fournisseur de transit AS3356.
  • Une requête RIPEstat bornée a retrouvé 1 548 événements pour le préfixe étudié, dont 1 440 avec AS13335 et AS32934 dans le chemin. Elle confirme une visibilité publique du chemin anormal, sans prouver la configuration interne, l’étendue complète de l’incident ni ses conséquences sur le trafic.
  • La validation RPKI de l’origine n’aurait pas nécessairement bloqué cette fuite : l’origine Meta pouvait rester autorisée alors que la relation d’export intermédiaire était incorrecte.
  • Une mise en production progressive ne constitue un contrôle utile que si le routeur canari compare, avant émission, les ensembles de routes et les variations d’Adj-RIB-Out, puis s’arrête automatiquement lorsqu’une contrainte de relation est violée.
  • Le retour arrière doit corriger à la fois la politique active du routeur et sa source génératrice, suspendre l’automatisation, vérifier les retraits depuis l’extérieur et attribuer explicitement la décision de reprise.

Un incident bref, mais une chaîne de preuve longue

La fuite de routes du 22 janvier 2026 n’est pas correctement décrite comme une simple faute de frappe, une panne générique du cloud ou un problème que l’on pourrait réduire à « BGP a accepté une mauvaise route ». Le point central est plus précis : une transformation apparemment restrictive du code source a rendu une politique d’export générée moins restrictive.

Cloudflare explique que le changement visait à retirer des références devenues obsolètes après des évolutions d’infrastructure à Bogotá. Ces références reliaient des règles d’export à des listes de préfixes locales. Une fois la dernière de ces conditions étroites supprimée, la règle correspondante n’a pas disparu. Elle conservait une condition plus large, route-type internal, ainsi qu’une action d’acceptation.

Une configuration peut, dans ces circonstances, rester syntaxiquement correcte tout en changeant radicalement de sens. Le générateur produit encore du texte valide. Le routeur peut encore charger la politique. Les sessions BGP peuvent rester établies. Les routes peuvent continuer d’être calculées. Pourtant, l’autorité conférée à la règle d’export s’est élargie : elle ne sélectionne plus seulement l’ensemble étroit prévu par les anciennes listes, mais des routes internes au sens de la plateforme, y compris, selon le récit de Cloudflare, des routes apprises par iBGP et redistribuées à l’intérieur du réseau.

La question de responsabilité n’est donc pas seulement de savoir qui a supprimé une ligne ou si le dépôt a accepté une modification. Elle est de savoir si le système de changement pouvait démontrer que la politique rendue demeurait conforme aux relations réseau autorisées.

Cette démonstration exige de séparer plusieurs couches que les rapports d’incident condensent souvent :

  1. l’intention exprimée dans la modification du code source ;
  2. la politique candidate produite par le générateur ;
  3. la politique effectivement chargée et active sur le routeur ;
  4. les routes présentes dans la Loc-RIB et susceptibles de satisfaire cette politique ;
  5. l’Adj-RIB-Out calculée pour chaque voisin ;
  6. les mises à jour BGP réellement émises ;
  7. l’état des tables de routage et de transfert, RIB et FIB ;
  8. les observations du trafic, de la latence, des pertes et des rejets ;
  9. les chemins visibles auprès des collecteurs externes.

Ces couches sont liées, mais aucune ne remplace les autres. Un diff de dépôt ne révèle pas nécessairement l’ensemble des routes qui correspondront à une règle rendue. Une politique chargée ne prouve pas à elle seule ce qui a effectivement été annoncé. Un chemin public ne révèle ni le texte exact de la configuration interne ni le raisonnement qui a autorisé son déploiement. Une mesure de trafic, enfin, ne suffit pas à identifier le mécanisme de contrôle qui a échoué.

Chronologie attribuée de l’événement

Le récit publié par Cloudflare fournit une séquence temporelle détaillée. Les heures ci-dessous sont en UTC et les événements internes demeurent attribués à l’entreprise.

Heure Événement rapporté
19 h 52 La modification du dépôt est fusionnée.
20 h 25 L’automatisation s’exécute sur un routeur de Miami ; le début de l’impact est situé à cette heure.
20 h 40 L’enquête commence.
20 h 44 L’incident est formellement signalé.
20 h 50 Un opérateur rétablit manuellement la politique du routeur et suspend l’automatisation.
21 h 47 La modification du dépôt est annulée.
22 h 07 L’automatisation est jugée de nouveau saine.
22 h 40 L’automatisation est réactivée.

Cloudflare borne l’impact public à 25 minutes, de 20 h 25 à 20 h 50, et précise que seul IPv6 a été affecté. Cette limite est importante, mais elle ne permet pas à elle seule de conclure que toutes les séparations entre familles d’adresses fonctionnaient comme prévu. Elle établit le périmètre déclaré de cet incident, non une preuve générale de l’indépendance de tous les systèmes IPv4 et IPv6.

L’entreprise rapporte une congestion entre Miami et Atlanta, une augmentation de la latence sur les liaisons concernées et des pertes plus élevées pour une partie du trafic de ses clients. Elle indique également que les filtres de pare-feu des routeurs ont rejeté du trafic destiné à des préfixes qui n’étaient pas en aval de Cloudflare. Selon son estimation, ce trafic rejeté a atteint environ 12 Gbit/s au pic.

Ces mesures ne doivent pas être transformées en affirmations plus larges. Le dossier public ne fournit pas le nombre total de clients touchés, leur identité, l’étendue exhaustive des préfixes concernés ni une évaluation financière. Il ne justifie pas davantage une conclusion sur une faute juridique, une violation contractuelle ou une responsabilité réglementaire. Les chiffres disponibles décrivent ce que Cloudflare a mesuré et choisi de publier.

Comment la suppression d’une condition a élargi l’export

Une politique de routage se compose généralement de règles associant des conditions à des actions. Une condition peut porter sur un préfixe, une longueur de masque, une communauté, un type de route, un chemin d’AS ou un autre attribut. L’action peut accepter, rejeter ou modifier la route avant de poursuivre son évaluation.

Lorsqu’une règle contient plusieurs conditions, leur suppression ne produit pas nécessairement une erreur. Si le générateur enlève une condition devenue vide mais conserve le reste de la règle, celle-ci peut encore être parfaitement interprétable. Le danger apparaît lorsque la condition supprimée était la dernière à limiter l’application de l’action accept à un ensemble précis.

Dans le cas décrit par Cloudflare, les références à des listes de préfixes de Bogotá jouaient ce rôle restrictif. Après leur suppression, route-type internal restait présent. Le terme « internal » pouvait sembler rassurant dans une révision textuelle : il évoque intuitivement quelque chose de local, donc de non exportable. Sa sémantique opérationnelle était toutefois plus large. Selon Cloudflare, elle englobait des routes non externes, notamment des routes apprises par iBGP.

L’erreur de raisonnement consisterait à confondre la provenance interne dans le processus de routage avec l’autorisation d’export vers un voisin externe. Une route transportée à l’intérieur d’un système autonome peut avoir été initialement reçue d’un pair, d’un fournisseur ou d’un client. Son passage par iBGP ne transforme pas sa relation commerciale ou opérationnelle d’origine. Il ne crée pas non plus une autorisation générale de la réannoncer.

Un contrôle centré sur la syntaxe répond seulement à des questions limitées : la politique est-elle parsable ? Les objets référencés existent-ils ? La configuration peut-elle être chargée ? Il ne répond pas à la question décisive : quelles routes réelles cette politique permettra-t-elle d’annoncer à chaque voisin ?

La validation doit donc porter sur la sémantique de l’ensemble rendu. Pour chaque règle d’acceptation, le système devrait établir au minimum :

  • les prédicats qui subsistent après génération ;
  • les routes de la Loc-RIB qui satisfont ces prédicats ;
  • la relation attribuée à la source de chaque route ;
  • la relation attribuée au voisin de destination ;
  • l’Adj-RIB-Out attendue avant et après le changement ;
  • les préfixes, origines, chemins et communautés qui apparaissent ou disparaissent ;
  • les limites numériques autorisées pour la variation ;
  • la décision automatique à prendre lorsque la variation dépasse l’enveloppe prévue.

Une modification censée retirer des références obsolètes devrait normalement réduire l’état ou laisser inchangé l’ensemble des exports. Si le calcul candidat montre au contraire une augmentation substantielle du nombre de routes admissibles, cette expansion constitue un signal de sécurité, même si chaque ligne du rendu est valide.

Cette propriété peut être formulée comme une obligation de monotonie pour certaines catégories de changements : une opération qualifiée de nettoyage ou de suppression ne doit pas acquérir silencieusement une autorité d’export supplémentaire. Si elle en acquiert une, le système doit interrompre la mise en production jusqu’à ce qu’un responsable nommé examine la différence.

De l’intention du dépôt à l’Adj-RIB-Out

Le code source de l’automatisation est un plan. La politique candidate est le résultat de sa compilation. La politique active est le comportement réellement imposé au routeur. Ces trois objets doivent être conservés et comparés séparément.

Le diff source montre ce qu’un auteur a modifié, mais pas nécessairement tout ce que le générateur supprimera, conservera ou réordonnera. Le rendu candidat permet de voir la configuration complète, mais son inspection textuelle reste insuffisante si l’on ne connaît pas les routes auxquelles les règles correspondront. La configuration active indique ce que le routeur exécute, sans prouver que cette exécution correspond à l’intention déclarée.

La Loc-RIB, dans le modèle BGP, contient les routes locales retenues après le processus de décision. Elle ne constitue pas une liste de routes autorisées pour tous les voisins. L’export est calculé séparément selon les politiques applicables à chacun d’eux. L’Adj-RIB-Out représente conceptuellement les routes préparées pour l’annonce à un pair précis. C’est à ce niveau que l’on peut vérifier si une route autorisée pour un client est également, et légitimement, autorisée pour un pair ou un fournisseur.

Une comparaison générale du nombre de routes dans la RIB est donc trop grossière. Un changement peut laisser la taille totale de la Loc-RIB inchangée tout en ajoutant des milliers d’exports à un voisin. Inversement, une évolution interne importante n’implique pas nécessairement un changement de l’Adj-RIB-Out. Le contrôle doit être effectué par famille d’adresses et par voisin, avec les relations et les attributs pertinents.

Il faut aussi distinguer l’Adj-RIB-Out calculée des mises à jour effectivement envoyées. Une politique candidate peut être évaluée dans un environnement contrôlé, puis bloquée avant émission. Une fois la politique active, les journaux de mises à jour ou la télémétrie du routeur doivent établir ce qui a quitté l’AS. Enfin, les collecteurs externes apportent une vue indépendante, mais partielle, de ce qui est devenu visible sur Internet.

Cette succession produit une chaîne vérifiable :

intention source → rendu candidat → politique active → routes correspondantes → Adj-RIB-Out par voisin → mises à jour émises → visibilité externe → conséquences observées.

Une preuve d’intégrité solide doit pouvoir relier chaque flèche. L’existence d’un pipeline d’automatisation ne prouve pas que ces transitions ont été vérifiées.

Les relations ne se déduisent pas d’un préfixe valide

Une route BGP n’est pas légitime à l’export uniquement parce que son préfixe est bien formé, que son origine est connue ou que son chemin ne contient pas d’anomalie syntaxique. L’autorisation dépend aussi de la relation entre le réseau qui a transmis la route et celui auquel elle est annoncée.

Dans une représentation simplifiée, un réseau accepte généralement d’assurer le transit du trafic de ses clients. En revanche, il ne fournit pas automatiquement un transit gratuit entre deux pairs ni entre un pair et son fournisseur. Ces règles économiques et opérationnelles se traduisent en politiques d’export.

Une route issue d’un client peut souvent être annoncée à des clients, des pairs et des fournisseurs, sous réserve des accords réels. Une route apprise d’un pair est habituellement destinée au réseau local et à ses clients, pas à un autre pair ou à un fournisseur. Une route apprise d’un fournisseur ne doit généralement pas être exportée à un autre fournisseur ou à un pair comme si le réseau intermédiaire fournissait un transit universel.

Ce modèle demeure une simplification. Les accords privés peuvent comporter des exceptions, et le seul chemin d’AS public ne suffit pas à reconstruire les contrats. C’est précisément pourquoi l’opérateur doit maintenir ses propres contraintes de relation et les appliquer indépendamment des attributs d’origine.

Cloudflare décrit des routes IPv6 de Meta, AS32934, apprises comme routes de pair puis exportées depuis AS13335 vers le fournisseur de transit AS3356. L’entreprise publie comme exemple le préfixe 2a03:2880:f077::/48 et le chemin :

64112 22850 174 3356 13335 32934

Le point probant n’est pas que cette chaîne, prise isolément, révélerait tous les contrats entre les AS. Elle montre une propagation publiquement visible impliquant AS13335 et AS32934. La qualification de Meta comme pair et d’AS3356 comme fournisseur repose sur le récit de Cloudflare.

Cloudflare décrit l’événement comme un mélange de fuites de Type 3 et de Type 4 au sens de la RFC 7908. Le Type 3 concerne l’export de préfixes appris d’un fournisseur vers un pair ; le Type 4, l’export de préfixes appris d’un pair vers un fournisseur. Ces catégories rendent visible la nature relationnelle du défaut : le problème n’est pas nécessairement l’origine du préfixe, mais la direction dans laquelle une route apprise a été propagée.

Une politique robuste doit donc tester deux autorisations indépendantes :

  • l’origine est-elle autorisée à annoncer ce préfixe ?
  • la route apprise dans cette relation peut-elle être exportée dans la relation de destination ?

Répondre « oui » à la première question ne répond pas à la seconde.

Le canari d’un seul routeur doit être un contrôle, pas seulement une réduction d’échelle

L’exécution initiale sur un seul routeur de Miami a limité le nombre d’équipements directement modifiés. Cette réduction du périmètre est utile, mais elle ne suffit pas à faire d’un déploiement un véritable canari.

Un canari efficace doit avoir une hypothèse, des seuils et une capacité d’arrêt automatique. Dans le cas d’une politique d’export, il devrait comparer avant toute émission l’état courant et l’état candidat pour chaque voisin concerné. Cette comparaison doit porter non seulement sur le nombre de préfixes, mais aussi sur leur origine, leur chemin, leur communauté, leur provenance relationnelle et leur famille d’adresses.

Une procédure adaptée pourrait fonctionner en deux phases. La première calcule une Adj-RIB-Out candidate sans l’émettre. Elle vérifie que les nouvelles routes restent dans une enveloppe approuvée. La seconde autorise une émission limitée seulement après le passage de ces contrôles.

Le canari doit s’arrêter automatiquement notamment lorsqu’il détecte :

  • l’apparition de routes apprises d’un pair dans l’export vers un fournisseur ;
  • l’apparition de routes apprises d’un fournisseur dans l’export vers un pair ;
  • une augmentation inattendue de l’ensemble des préfixes ;
  • une origine ou un chemin extérieur à l’enveloppe approuvée ;
  • la disparition de la dernière contrainte de préfixe, de communauté ou de relation dans une règle d’acceptation ;
  • une variation non expliquée entre la politique candidate et l’Adj-RIB-Out ;
  • des annonces externes que le modèle candidat ne prévoyait pas.

La détection après émission reste nécessaire, mais elle représente une seconde ligne de défense. Si l’alerte dépend d’une congestion, d’une hausse de pertes ou d’un collecteur public, la route non autorisée a déjà quitté le réseau. La responsabilité de l’automatisation consiste à arrêter la violation avant cette étape lorsque les données nécessaires existent localement.

RPKI protège l’origine, pas toute la relation de transit

L’infrastructure RPKI et les autorisations d’origine de route répondent à un problème essentiel : un AS est-il autorisé par le détenteur des ressources à être l’origine d’un préfixe ? Les RFC 6480, 6811, 8210 et 7115 décrivent les éléments de cette validation et son utilisation opérationnelle.

Dans l’événement étudié, les routes divulguées conservaient Meta AS32934 comme origine. Une autorisation d’origine valide pouvait donc rester cohérente avec le préfixe, même si le chemin intermédiaire violait une politique de relation. La validation d’origine ne détermine pas si Cloudflare était autorisé à exporter une route apprise d’un pair à son fournisseur.

Cette limite ne rend pas RPKI inutile. Elle empêche simplement de lui attribuer une fonction qu’il n’assure pas seul. Une défense de routage complète doit distinguer au moins trois questions :

  1. l’origine est-elle autorisée pour le préfixe ?
  2. le chemin observé est-il compatible avec les relations attendues ?
  3. ce voisin précis est-il autorisé à recevoir cette route dans cette direction ?

La première relève directement de la validation d’origine. Les deux autres nécessitent des informations et des contrôles supplémentaires.

La RFC 9234 définit les rôles BGP et l’attribut Only-to-Customer, ou OTC. Ces mécanismes permettent aux voisins de négocier des rôles et de transporter une indication utile pour détecter certaines propagations contraires aux relations déclarées. Ils peuvent apporter une défense distincte de la logique locale du générateur.

Ils ne doivent cependant pas être décrits comme une protection effectivement déployée chez Cloudflare sur la seule base des documents publics disponibles. Cloudflare a annoncé vouloir vérifier la prise en charge de ces mécanismes par les équipements concernés. Il s’agit d’une orientation de remédiation, pas d’une preuve de déploiement ultérieur ni d’efficacité mesurée.

Les communautés BGP de confiance peuvent également signaler la provenance ou la catégorie relationnelle d’une route. Pour être utiles comme barrière indépendante, elles doivent être protégées contre l’injection non fiable, normalisées aux frontières et vérifiées au moment de l’export. Une communauté simplement ajoutée par le même pipeline qui a produit la politique erronée ne constitue pas nécessairement une défense indépendante.

Le filtrage externe apporte une autre couche. Un fournisseur ou un pair peut limiter ce qu’il accepte d’un voisin selon des préfixes, des origines, des chemins ou des relations attendues. Les recommandations opérationnelles de la RFC 7454 et les pratiques décrites par MANRS éclairent cette approche. Elles ne prouvent pas quels filtres privés étaient présents le 22 janvier ni comment ils ont réagi.

Enfin, les travaux ASPA cherchent à mieux vérifier les relations fournisseur-client visibles dans les chemins d’AS. Ils sont pertinents pour la détection de chemins relationnellement anormaux, mais le document cité reste un travail en développement. Il ne doit être présenté ni comme un standard final universellement appliqué ni comme une protection prouvée dans cet incident.

Ces contrôles répondent donc à des questions différentes :

Contrôle Question principale Limite dans ce dossier
RPKI et validation d’origine L’AS d’origine est-il autorisé pour le préfixe ? Ne suffit pas à valider la relation de propagation intermédiaire.
Rôles BGP et OTC La propagation respecte-t-elle les rôles déclarés entre voisins ? Le dossier ne prouve pas leur déploiement effectif.
Communautés de confiance Quelle provenance ou relation l’opérateur associe-t-il à la route ? Leur fiabilité dépend de leur gouvernance et de leur contrôle aux frontières.
Filtrage externe Le voisin accepte-t-il seulement les routes attendues ? Les politiques privées et leur état au moment de l’incident ne sont pas établis.
ASPA Le chemin est-il compatible avec des relations fournisseur-client autorisées ? Le mécanisme demeure en développement et son déploiement ne peut être présumé.

La défense la plus crédible ne choisit pas un seul de ces mécanismes. Elle les combine de façon à ce qu’une erreur du générateur ne neutralise pas toutes les barrières en même temps.

Ce que les collecteurs publics confirment

Les collecteurs de routes fournissent une vue extérieure des annonces BGP reçues par leurs points d’observation. Ils sont particulièrement utiles lorsqu’un opérateur affirme qu’une route a quitté son réseau : ils peuvent montrer qu’un chemin correspondant est devenu visible au-delà de l’infrastructure interne.

La requête RIPEstat BGPlay bornée au préfixe 2a03:2880:f077::/48 et à la période allant de 20 h 24 à 20 h 52 UTC a renvoyé un statut ok ainsi que 1 548 événements. Parmi eux, 1 440 contenaient à la fois AS13335 et AS32934 dans leur chemin.

Ce résultat corrobore la visibilité publique du motif de chemin décrit par Cloudflare. Il fournit une observation indépendante du fait que des collecteurs ont reçu des mises à jour associant ces deux AS pendant la fenêtre examinée.

Il ne permet pas de déduire :

  • le texte de la politique active sur le routeur de Miami ;
  • la manière exacte dont le générateur a construit cette politique ;
  • l’ensemble total des préfixes affectés ;
  • le nombre de clients concernés ;
  • la quantité de trafic détourné ou rejeté ;
  • les accords commerciaux privés entre tous les AS du chemin ;
  • l’identité de toutes les interfaces ou de tous les équipements impliqués ;
  • la cause interne de la congestion ou des pertes.

Les collecteurs ne voient pas l’intégralité d’Internet. Leur visibilité dépend de leurs pairs, de la sélection des meilleures routes et des annonces reçues. Le nombre d’événements ne correspond donc ni à un nombre de préfixes ni à un nombre de victimes. Plusieurs mises à jour peuvent concerner le même préfixe ou refléter des changements successifs de chemin.

Les archives MRT et les données RIPE RIS restent néanmoins une pièce essentielle de la chaîne de responsabilité. Elles permettent de comparer l’heure des annonces et des retraits avec les journaux internes, de vérifier que les retraits sont devenus visibles depuis plusieurs points et de détecter une persistance que l’état local pourrait manquer.

Les conséquences doivent rester rattachées à leur source

Cloudflare relie l’incident à une congestion entre Miami et Atlanta. L’entreprise rapporte une hausse de la latence, des pertes plus importantes pour une partie du trafic client et le rejet de trafic non destiné à des préfixes en aval. Elle estime le pic de trafic rejeté à environ 12 Gbit/s.

Ces éléments appartiennent à une couche de preuve différente de celle des chemins BGP publics. Les collecteurs montrent les annonces. Ils ne mesurent pas directement la congestion interne, les filtres de pare-feu ou la qualité perçue par les clients de Cloudflare.

Inversement, une alarme de trafic ne prouve pas à elle seule quel chemin a été annoncé à quel voisin. Pour relier le contrôle et l’impact, l’opérateur doit conserver des horodatages compatibles entre :

  • les modifications de la politique ;
  • les variations d’Adj-RIB-Out ;
  • les mises à jour envoyées ;
  • les changements observés dans les RIB et FIB ;
  • les compteurs de trafic et de rejet ;
  • les variations de latence et de perte ;
  • les premières observations externes ;
  • les retraits et le retour à la normale.

Cette corrélation ne doit pas être remplacée par une narration rétrospective. Elle doit pouvoir être reconstruite à partir d’éléments conservés au moment du changement.

Revenir en arrière sur deux plans

À 20 h 50, selon Cloudflare, un opérateur a manuellement rétabli la politique du routeur et suspendu l’automatisation. Cette intervention a corrigé l’état actif et interrompu la propagation automatique du changement. Le dépôt n’a toutefois été rétabli qu’à 21 h 47.

Cet écart illustre une règle importante : un retour arrière opérationnel doit corriger à la fois le système en exécution et la source qui peut le régénérer. Si seul le routeur est corrigé, l’automatisation peut réintroduire la politique fautive. Si seul le dépôt est rétabli, le routeur peut continuer à exécuter la configuration incorrecte jusqu’au prochain passage du pipeline.

Une procédure de récupération complète devrait donc :

  1. figer l’automatisation afin d’éviter une réapplication ;
  2. corriger la politique active sur l’équipement touché ;
  3. vérifier la nouvelle Adj-RIB-Out et l’arrêt des annonces anormales ;
  4. corriger la source génératrice ;
  5. produire de nouveau la configuration candidate ;
  6. comparer cette candidate à l’état sain attendu ;
  7. observer les retraits auprès de plusieurs sources externes ;
  8. confirmer la normalisation du trafic et des compteurs de rejet ;
  9. attribuer à une personne ou une fonction nommée la décision de reprise ;
  10. réactiver l’automatisation avec des critères documentés.

Cloudflare indique que l’automatisation a été jugée saine à 22 h 07 puis réactivée à 22 h 40. Le délai entre ces deux étapes peut correspondre à une période de prudence, mais le dossier public ne permet pas d’en connaître les critères internes. Il ne faut donc pas inventer les tests effectués, les responsabilités de décision ou les contrôles cachés.

Une responsabilité mesurable pour l’automatisation de routage

La conclusion la plus facile serait d’opposer l’humain à l’automatisation. Elle serait trompeuse. Une configuration manuelle peut produire la même fuite, tandis qu’une automatisation correctement instrumentée peut détecter des expansions que l’œil humain manquerait.

La question pertinente est de savoir ce que le système automatisé est capable de prouver avant et après un changement. Une chaîne responsable devrait conserver, pour chaque déploiement :

  • l’objectif déclaré du changement ;
  • la version exacte de la source ;
  • le rendu candidat complet ;
  • la différence entre le rendu candidat et la politique active ;
  • les règles d’acceptation ayant perdu une contrainte ;
  • l’ensemble des routes correspondant à chaque règle ;
  • les relations attribuées aux routes et aux voisins ;
  • les deltas d’Adj-RIB-Out par voisin et par famille d’adresses ;
  • le résultat du canari ;
  • les seuils d’arrêt automatique ;
  • les mises à jour BGP émises ;
  • les observations de collecteurs externes ;
  • les alarmes de trafic, de latence, de perte et de rejet ;
  • l’état du retour arrière dans le routeur et dans la source ;
  • la personne ou la fonction ayant autorisé le déploiement et la reprise.

Une telle liste ne signifie pas que toute modification doit être approuvée manuellement. Elle signifie que l’autorité du générateur doit avoir des limites observables. Le système peut continuer automatiquement lorsque le changement reste dans l’enveloppe approuvée. Il doit s’arrêter lorsque les routes admissibles s’étendent de manière inattendue ou franchissent une frontière de relation.

Cloudflare a indiqué vouloir renforcer la détection des règles vides ou erronées dans son processus d’intégration et de déploiement, ajouter des protections fondées sur les communautés BGP, étudier la prise en charge des rôles BGP et améliorer la détection précoce. Ce sont des directions cohérentes avec le mécanisme décrit. Elles restent des engagements. Sans éléments ultérieurs, elles ne prouvent ni leur déploiement complet ni leur efficacité.

L’exigence de responsabilité ne consiste pas à demander une confiance absolue dans une promesse de correction. Elle consiste à définir les preuves qui permettraient, lors d’un futur changement, de constater que l’autorité d’export ne s’est pas élargie silencieusement.