Résumé

  • Cloudflare a décrit deux événements de routage distincts survenus le 27 juin 2024 : AS267613 a commencé à annoncer 1.1.1.1/32 à 18 h 51 UTC, tandis qu’AS262504 a divulgué 1.1.1.0/24 via AS1031 à 18 h 52 UTC.
  • L’annonce /32 concernait une nouvelle origine et était invalide au regard de la validation d’origine RPKI. La fuite /24, en revanche, conservait l’origine correcte AS13335 tout en empruntant un chemin non autorisé.
  • Cloudflare a indiqué qu’un réseau de premier rang non nommé avait accepté le /32 comme route de blackhole déclenchée à distance. Cette attribution ne permet pas de reconstituer sa politique privée ni son implantation technique.
  • Les effets rapportés étaient l’impossibilité, pour certains utilisateurs, d’atteindre 1.1.1.1 ou une latence élevée. Les éléments disponibles ne démontrent pas une panne mondiale du résolveur DNS.
  • Les données d’allocation et les ROA constituent des preuves d’autorisation d’origine. Elles ne configurent pas les filtres des routeurs et ne certifient pas l’ensemble des relations entre systèmes autonomes d’un chemin BGP.
  • RouteViews et RIPE RIS conservent des observations utiles à l’enquête, mais n’autorisent aucune route, ne commandent aucun retrait et ne prouvent pas chaque résultat réel d’acheminement.
  • Le RTBH est une défense légitime contre certains trafics indésirables. Son caractère destructeur impose toutefois une autorisation stricte du client, du préfixe, de la longueur, de la portée, de la journalisation et du retrait.
  • La responsabilité opérationnelle suit le contrôle pratique : origine de la route, export du client, acceptation par le fournisseur, propagation par transit ou serveur de routes, autorisation du blackhole, surveillance, confinement et vérification du retour à l’état normal.

Deux événements, pas un incident BGP indifférencié

L’adresse 1.1.1.1 est largement reconnue comme l’une des adresses du résolveur DNS public exploité par Cloudflare. Cette visibilité rend toute anomalie de routage particulièrement sensible, mais elle ne dispense pas d’une reconstruction précise. Le 27 juin 2024, deux routes différentes ont été annoncées presque au même moment. Elles n’avaient ni la même origine, ni la même longueur de préfixe, ni la même anomalie de politique. Les réunir sous une seule étiquette ferait disparaître les contrôles qui auraient pu arrêter chacune d’elles.

Selon le compte rendu de Cloudflare, AS267613 a commencé à annoncer 1.1.1.1/32 à 18 h 51 UTC. Un /32 IPv4 représente une seule adresse. Il est donc plus spécifique que le bloc 1.1.1.0/24 qui contient cette adresse. Dans le plan de routage global ordinaire, une annonce aussi précise n’est pas une route normale destinée à transporter universellement le trafic vers un service. Cloudflare l’a décrite comme invalide au regard de la validation d’origine RPKI.

Une minute plus tard, à 18 h 52 UTC, AS262504 a divulgué 1.1.1.0/24 via AS1031, toujours selon Cloudflare. Cette seconde route conservait AS13335, le système autonome de Cloudflare, comme origine. Son problème ne résidait donc pas dans le simple couple préfixe-origine : il concernait le chemin et la propagation de la route. La distinguer du /32 est essentiel, car un validateur d’origine pouvait considérer le /24 comme valide sans savoir si chaque export ou relation intermédiaire était autorisé.

La proximité temporelle ne transforme pas ces annonces en un seul mécanisme. Le /32 posait notamment la question de l’acceptation d’une route très spécifique, d’une origine non autorisée et de son traitement comme blackhole. Le /24 posait celle d’une fuite de route : une information de joignabilité, associée à l’origine correcte, avait franchi une frontière de politique qu’elle n’aurait pas dû franchir. Les mêmes outils ne couvrent pas automatiquement les deux risques.

Chronologie et limites de l’observation

À 18 h 51 UTC, l’annonce 1.1.1.1/32 attribuée à AS267613 a commencé. À 18 h 52 UTC, la fuite 1.1.1.0/24 attribuée à AS262504 via AS1031 a suivi. Ces heures viennent du récit de Cloudflare et doivent rester rattachées à cette source. Elles fournissent une chronologie opérationnelle, non une preuve universelle de ce que chaque routeur de l’Internet a reçu à la même seconde.

Cloudflare a ouvert son incident à 20 h 03 UTC. Cet intervalle entre les premières annonces rapportées et l’ouverture de l’incident soulève une question légitime sur la détection, la qualification et l’escalade. Il ne suffit cependant pas à conclure à une faute. Il faudrait connaître les alarmes disponibles, leurs seuils, le moment où les symptômes ont été reliés au routage, la qualité des données reçues et les étapes internes de confirmation.

Cloudflare a enregistré la résolution complète de la fuite /24 à 2 h 28 UTC le 28 juin. Ce jalon concerne le rétablissement rapporté de cette fuite. Il ne doit pas être transformé en affirmation selon laquelle toutes les tables BGP, tous les caches, tous les chemins de données et toutes les expériences utilisateur auraient changé simultanément. Une route peut disparaître de certains points d’observation avant d’autres, et la visibilité d’un collecteur ne représente jamais parfaitement chaque réseau.

Les effets décrits par Cloudflare étaient l’impossibilité d’atteindre 1.1.1.1 ou une latence élevée pour certains utilisateurs. Ces symptômes sont cohérents avec des décisions de routage divergentes : certains chemins peuvent abandonner le trafic, d’autres le détourner, et d’autres encore conserver une route fonctionnelle. Ils ne prouvent pas une interruption mondiale du DNS de Cloudflare, encore moins une panne générale du DNS sur Internet.

L’analyse publiée par APNIC a indiqué que l’événement n’était pas visible mondialement et que son effet était probablement marginal par rapport à l’ensemble des utilisateurs d’Internet. Cette appréciation doit rester attribuée à APNIC. Internet Society Pulse a employé un langage d’observation plus large à propos de réseaux et de pays où des traces avaient été vues. Cette formulation doit, elle aussi, rester attribuée à sa source. Les deux descriptions ne mesurent pas nécessairement la même chose : voir une route dans une zone ou depuis un réseau n’établit pas que tous ses utilisateurs ont perdu le service.

Aucune des sources retenues ne prouve l’intention malveillante d’AS267613, d’AS262504, d’AS1031 ou d’un autre acteur. Elles n’établissent pas non plus un nombre exact de clients affectés, un volume précis de trafic perdu, une géographie complète, la totalité des chemins de propagation, une négligence, une illégalité, une dissimulation ou une responsabilité juridique. L’analyse doit donc rester sur le terrain des contrôles techniques et des faits observables.

Pourquoi le /32 pouvait détourner ou détruire le trafic

BGP distribue des informations de joignabilité entre systèmes autonomes. Lorsqu’un routeur possède plusieurs routes couvrant une même destination, la sélection de la route la plus spécifique intervient avant de nombreux autres critères. Pour joindre 1.1.1.1, une route /32 correspond plus précisément que 1.1.1.0/24. Si les deux sont installées et utilisables, la route vers l’adresse unique peut donc capter le trafic destiné à 1.1.1.1.

Cela ne signifie pas que chaque réseau de l’Internet accepte ou propage un /32. Des politiques de longueur de préfixe limitent habituellement les annonces IPv4 globales, et de nombreux opérateurs filtrent les routes plus spécifiques qu’un certain seuil. Le résultat dépend des filtres réellement déployés, des relations entre voisins, des communautés BGP et du traitement local. Les RFC fournissent le contexte de protocole ou les recommandations ; elles ne prouvent pas que chaque réseau concerné appliquait un réglage donné.

Cloudflare a rapporté qu’un réseau de premier rang non nommé avait accepté le /32 comme route RTBH, c’est-à-dire comme instruction de blackholing déclenchée à distance. Lorsqu’un tel mécanisme est correctement autorisé, il permet d’écarter rapidement le trafic vers une cible attaquée et de protéger le reste d’un réseau. Il peut être utile face à une attaque volumétrique, car le trafic est rejeté en amont plutôt que de saturer des liens plus proches du service.

Le même pouvoir devient destructeur si une route de blackhole est acceptée pour une adresse qu’un client n’est pas autorisé à neutraliser. Le trafic correspondant peut alors être abandonné à l’intérieur du réseau qui a reconnu la signalisation, voire dans une portée plus large selon sa politique. Dans cet incident, le point de responsabilité n’est donc pas « le RTBH est dangereux par nature ». Il est plus précis : quel contrôle autorisait ce voisin à demander le blackholing de 1.1.1.1, avec cette longueur, pour cette portée et à cet instant ?

Les sources publiques ne permettent pas d’identifier le réseau de premier rang ni de reconstituer ses configurations privées. On ne peut pas affirmer quel format de communauté il utilisait, quels filtres étaient actifs, comment sa relation client était représentée ou pourquoi la route a franchi ses contrôles. On peut seulement énoncer les vérifications qu’un système robuste devrait imposer : identité du voisin, préfixes autorisés, longueur maximale admissible, relation commerciale, communauté permise, portée de propagation, durée de vie, journal d’acceptation et procédure de retrait.

Le blackholing ne modifie pas seulement le plan de contrôle. Il entraîne délibérément un résultat dans le plan de données : l’abandon du trafic correspondant. Cette conséquence justifie une autorisation plus étroite que celle d’une communauté informative ordinaire. La possibilité de détruire la joignabilité d’une adresse mondialement connue ne devrait jamais résulter d’une correspondance trop générale ou d’une confiance implicite accordée à tout préfixe annoncé par un voisin.

Pourquoi la fuite /24 échappait à une validation limitée à l’origine

Le second événement concernait 1.1.1.0/24. D’après Cloudflare, AS262504 a divulgué cette route via AS1031 tout en conservant AS13335 comme origine. C’est le cas pédagogique d’une route dont l’origine peut être autorisée alors que la propagation ne l’est pas.

Un ROA associe un préfixe, une longueur maximale et un système autonome autorisé à l’originer. La validation d’origine compare l’annonce reçue à cette information. Elle peut conduire à un état valide, invalide ou inconnu selon les données disponibles et la relation entre préfixe, longueur et origine. Elle ne détermine pas si chaque système autonome intermédiaire avait le droit de transmettre la route à son voisin.

Ainsi, le fait que le /24 aboutisse à AS13335 ne répond pas aux questions suivantes : AS262504 pouvait-il exporter cette route dans ce sens ? La relation avec AS1031 autorisait-elle cet export ? AS1031 devait-il l’accepter d’un tel voisin ? Un serveur de routes ou un opérateur de transit devait-il la redistribuer ? La séquence de systèmes autonomes respectait-elle les relations commerciales et les rôles configurés ?

La validation d’origine RPKI peut rejeter une origine invalide ou une longueur supérieure à celle autorisée. Elle ne valide pas un chemin AS complet. Dire le contraire donnerait aux lecteurs une assurance inexistante et déplacerait à tort toute la responsabilité vers les registres ou les opérateurs de ROA.

RFC 7908 décrit des catégories de fuites de routes et aide à nommer le problème. RFC 7454 présente des pratiques de sécurité BGP, tandis que RFC 8212 insiste sur la nécessité de politiques explicites d’import et d’export. RFC 9234 définit des rôles BGP et l’attribut Only-to-Customer, conçu pour limiter certaines fuites en transportant une information de relation. Ces mécanismes renforcent les frontières de politique, mais les textes ne démontrent pas leur implantation ou leur efficacité dans les réseaux nommés pendant l’incident.

Un déploiement partiel reste utile sans être absolu. Un réseau qui filtre correctement ses clients peut arrêter une route avant qu’elle n’atteigne le transit. Un fournisseur qui associe explicitement chaque session à un rôle peut détecter un export incohérent. Un route server peut appliquer une politique empêchant qu’un participant transforme une route reçue d’un fournisseur en route exportée vers d’autres pairs. Mais une chaîne de routage n’est aussi solide que les contrôles réellement exécutés aux frontières qu’elle traverse.

Registre, allocation et ROA : des preuves, pas des commandes

Les informations d’allocation d’APNIC apportent un contexte essentiel au préfixe 1.1.1.0/24. Elles permettent de documenter l’espace d’adressage, son statut administratif et les acteurs liés à son exploitation. L’explorateur RPKI de Cloudflare rend visibles des éléments d’autorisation d’origine. Ces données permettent aux opérateurs de construire des filtres et aux enquêteurs de comparer une annonce observée à une autorisation publiée.

Leur fonction est probatoire et structurante. Elles peuvent indiquer qu’une origine n’est pas couverte par le ROA attendu ou qu’une longueur excède le maximum autorisé. Elles peuvent aider à reconstituer l’état de l’autorisation à un moment donné. Elles peuvent aussi soutenir un échange rapide entre équipes réseau en fournissant une référence commune.

Elles ne poussent toutefois aucune configuration dans les routeurs par leur seule existence. Un opérateur doit récupérer les objets, les valider, distribuer le résultat à ses équipements, définir une politique pour chaque état et surveiller le bon fonctionnement de cette chaîne. Une route RPKI invalide peut encore circuler dans des réseaux qui ne font pas de validation ou qui n’appliquent pas une politique de rejet.

À l’inverse, une route d’origine valide n’est pas automatiquement une route légitime dans toutes ses dimensions. Le registre répond à une question limitée : quelle origine est autorisée pour ce préfixe et cette longueur ? Les contrôles de relation répondent à une autre question : qui peut exporter cette route à qui ? Les filtres de préfixe client répondent à une troisième : ce voisin est-il autorisé à présenter cet espace ? La surveillance et le plan de réponse traitent enfin du délai nécessaire pour détecter, contenir et retirer une anomalie.

Cette séparation évite deux excès. Le premier consiste à croire qu’une base de données exacte garantit à elle seule la disponibilité du service. Le second consiste à conclure que les registres sont inutiles dès qu’une fuite portant la bonne origine échappe à la validation. En réalité, l’autorisation d’origine est une couche nécessaire parmi plusieurs couches indépendantes.

Observation et acheminement réel

RouteViews et RIPE RIS collectent des annonces BGP depuis des points de vue distribués. Leurs archives permettent de rechercher quand une route est apparue, quels chemins ont été observés, comment sa visibilité a évolué et quand elle a disparu de certains flux. Elles sont particulièrement précieuses lorsque l’événement est terminé et que les opérateurs doivent comparer leurs journaux privés à une trace extérieure.

Ces plateformes ne sont cependant ni des autorités d’autorisation ni des systèmes de commande. Elles ne décident pas qu’une route est légitime, ne forcent pas un transit à la rejeter et ne retirent pas une annonce. Leur visibilité dépend des sessions de collecte et des chemins que leurs pairs leur transmettent.

Une observation dans un collecteur prouve qu’une information de routage a atteint ce point de vue, sous la forme enregistrée. Elle ne prouve pas que chaque réseau d’un pays l’a reçue, qu’elle a été sélectionnée comme meilleure route partout, ni que le trafic utilisateur a effectivement emprunté le même chemin. Le plan de contrôle observé et le plan de données vécu se recouvrent sans être identiques.

Pour qualifier l’impact, il faut donc combiner plusieurs familles de preuves : mises à jour BGP, vues RIB, états de validation, mesures actives de joignabilité, latence, télémétrie du résolveur, journaux de peering, tickets d’incident et confirmations de retrait. Chacune répond à une question particulière. Les confondre conduit à surestimer ou à minimiser l’événement.

L’illustration associée à cet article est un schéma éditorial générique et déterministe montrant plusieurs chemins de propagation convergeant vers un système de contrôle du routage. Ce n’est ni une photographie, ni une installation de Cloudflare, ni une reconstruction de l’incident. Elle visualise des catégories de chemins possibles sans prétendre représenter une topologie réelle.

Prévenir l’annonce /32

La première barrière se trouve au voisinage de l’origine. Un réseau ne devrait pouvoir annoncer que les préfixes et les longueurs explicitement autorisés pour sa session. Une liste de préfixes client établie à partir de sources fiables, confirmée par la relation contractuelle et mise à jour de manière contrôlée aurait vocation à rejeter une annonce telle que 1.1.1.1/32 si le client ne détenait aucune autorisation correspondante.

Une limite de longueur constitue une autre barrière. Accepter un /32 IPv4 dans une session de transit ordinaire demande une justification particulière. Les routes de blackhole font partie de ces exceptions, mais elles doivent être reconnues comme une classe contrôlée, non comme un contournement général des filtres de préfixe.

L’autorisation RTBH devrait associer au minimum le client authentifié, le préfixe détenu ou délégué, la longueur permise, la communauté attendue et la portée de l’action. Elle devrait refuser qu’un voisin neutralise une adresse extérieure à son inventaire. Les modifications de cet inventaire devraient être traçables et soumises à une séparation raisonnable des responsabilités.

La validation d’origine RPKI aurait pu constituer une barrière supplémentaire pour le /32, puisque Cloudflare l’a décrit comme invalide. Son efficacité dépend toutefois de l’application locale d’une politique cohérente. La connaissance de l’état invalide ne protège pas le trafic si le routeur continue d’accepter la route ou si une exception de blackhole écrase la décision sans contrôle équivalent.

Enfin, les réseaux devraient tester leurs filtres avec des cas négatifs. Vérifier seulement qu’une route autorisée passe ne suffit pas. Il faut aussi confirmer qu’un préfixe non client, une longueur excessive, une origine invalide et une communauté RTBH non autorisée sont rejetés sans effet destructeur.

Prévenir la fuite /24

La fuite /24 appelle une défense différente. Le filtre doit évaluer non seulement le préfixe et l’origine, mais aussi la direction de l’export et la relation entre voisins. Une route apprise d’un fournisseur ne doit généralement pas être réexportée comme si elle provenait d’un client. Une route apprise d’un pair ne doit pas devenir un service de transit involontaire.

Des politiques explicites par défaut réduisent les erreurs où une session nouvellement créée accepte ou exporte tout faute de règle. La logique de RFC 8212 est particulièrement importante : l’absence de politique ne devrait pas être interprétée comme une permission générale.

Les rôles BGP et le signal Only-to-Customer peuvent fournir un indice exploitable automatiquement pour certaines relations. Ils ne remplacent pas les inventaires de session, les filtres de préfixe et les validations contractuelles. Ils ajoutent une couche de contrôle capable de détecter qu’une route franchit une frontière contraire au rôle déclaré.

Les serveurs de routes des points d’échange doivent eux aussi être considérés comme des points de contrôle. Ils peuvent faciliter la diffusion entre de nombreux participants ; une erreur de politique peut donc gagner rapidement en visibilité. Leur responsabilité pratique porte sur les fonctions qu’ils exploitent réellement : validation des participants, politiques d’import et d’export, traitement des communautés, visibilité des décisions et mécanismes de retrait.

Les opérateurs de transit peuvent appliquer des filtres adaptés aux clients, aux pairs et aux fournisseurs. Leur responsabilité ne découle pas du simple fait qu’une route apparaît dans leur voisinage. Elle dépend de ce qu’ils ont accepté, sélectionné, propagé ou refusé, et des contrôles qu’ils pouvaient raisonnablement exercer à cette frontière.

Détecter sans confondre visibilité et impact

Une surveillance efficace doit associer les routes à l’identité du service. Pour 1.1.1.1, une alerte peut être déclenchée par une nouvelle origine, une longueur anormale, un chemin AS inhabituel, un état RPKI invalide ou une propagation depuis un voisin inattendu. Ces signaux devraient être corrélés avec la disponibilité et la latence du résolveur.

Le /32 et le /24 nécessitent des règles distinctes. Une alerte « origine inconnue pour une route plus spécifique » aurait vocation à détecter le premier. Une alerte « chemin ou export incompatible avec les relations attendues malgré une origine valide » serait nécessaire pour le second. Un tableau de bord limité au statut RPKI de l’origine pourrait donc voir le /32 tout en manquant l’anomalie de chemin du /24.

Les mesures doivent être distribuées. Un test effectué depuis une seule région peut conclure à tort que le service fonctionne partout ou qu’il est indisponible partout. Les résultats doivent indiquer le point de mesure, l’amont, la route observée, l’heure et la méthode. Il faut également séparer un échec DNS, un échec IP, une perte de paquets et une hausse de latence.

L’objectif de la détection n’est pas seulement de lever une alarme. Il est de produire assez de contexte pour savoir qui contacter et quelle action demander : retrait par l’origine, filtrage par le fournisseur, suppression d’une exportation, neutralisation d’une communauté ou changement temporaire de préférence.

Contenir sans étendre les dégâts

Le confinement doit commencer par la route la plus directement contrôlable. L’AS qui émet une annonce erronée peut la retirer. Son fournisseur peut bloquer le préfixe ou la longueur. Un réseau qui a accepté une instruction RTBH peut supprimer l’action et empêcher sa redistribution. Un route server peut filtrer la route fautive. Cloudflare peut coordonner ses pairs, surveiller les chemins restants et appliquer des mesures de service compatibles avec ses propres limites.

Une réaction trop large peut créer un second incident. Bloquer l’ensemble de 1.1.1.0/24 pour répondre à un /32 mal autorisé pourrait supprimer des routes légitimes. Désactiver sans discernement toutes les communautés de blackhole pourrait retirer une protection utile à d’autres clients. Modifier les préférences globales sans mesurer les effets peut déplacer la congestion plutôt que restaurer le service.

Le confinement doit donc être borné par le préfixe, la longueur, l’origine, le voisin, la communauté, la région de politique et la durée. Chaque exception temporaire devrait avoir un propriétaire, une heure d’expiration et une condition de retour. Les commandes d’urgence doivent être conservées avec leur justification.

La communication entre opérateurs gagne à utiliser des faits vérifiables : route exacte, chemin observé, horodatage, état RPKI, collecteur, résultat de mesure et action demandée. Accuser prématurément un acteur d’intention malveillante ou de faute juridique ne retire aucune route et peut ralentir la coopération.

Récupération et retrait vérifié

Un retrait annoncé ne suffit pas à clore un incident. Il faut vérifier sa visibilité depuis plusieurs points, confirmer que les routes fautives ne sont plus sélectionnées, tester la joignabilité du service et observer la normalisation de la latence. Pour le RTBH, il faut aussi confirmer que l’état de rejet a disparu de chaque périmètre où il avait été appliqué.

La récupération doit distinguer l’arrêt de l’annonce, la disparition des tables BGP, le rétablissement du trafic et la stabilisation du service. Ces étapes peuvent se chevaucher sans être simultanées. La résolution complète rapportée par Cloudflare à 2 h 28 UTC le 28 juin constitue un jalon important pour la fuite /24, mais elle ne remplace pas cette décomposition.

Les équipes devraient conserver un instantané des données utiles avant leur rotation : mises à jour BGP, journaux des sessions, décisions de validation, changements de filtres, communautés reçues, mesures de service et chronologie des contacts. Le but n’est pas d’accumuler des données sans limite, mais de permettre une reconstruction contradictoire.

Une clôture solide répond à quatre questions : l’annonce initiale a-t-elle cessé ? Les réseaux qui l’avaient acceptée l’ont-ils retirée ? Le trafic atteint-il à nouveau la destination attendue depuis des points représentatifs ? Les contrôles défaillants ont-ils été corrigés et testés ?

La carte réelle de la responsabilité

Pour AS267613, la question porte sur la capacité d’origine : quel mécanisme a permis l’annonce du /32, qui contrôlait la session, quels préfixes étaient autorisés et quel retrait a été effectué ? Cette formulation ne suppose aucune intention et ne préjuge pas de la cause.

Pour AS262504, l’enjeu est l’export du /24 : d’où la route avait-elle été apprise, quelle politique autorisait ou aurait dû interdire sa transmission, et comment l’erreur a-t-elle été retirée ? Là encore, le fait d’être nommé dans la chronologie ne suffit pas à établir une faute juridique.

Pour AS1031, nommé par Cloudflare dans le chemin de la fuite, les questions concernent l’acceptation et la propagation observées : quel rôle avait la session, quelles règles d’import et d’export s’appliquaient, et quelles preuves permettent de confirmer la chronologie ? Les sources retenues ne justifient pas d’aller au-delà de ces questions.

Pour tout serveur de routes ou opérateur de transit ayant propagé l’une des annonces, la responsabilité est fonction du contrôle exercé. Un acteur ne peut être tenu techniquement responsable de toutes les routes de l’Internet, mais il peut répondre de ses propres politiques d’acceptation, de redistribution, de communauté et de retrait.

Pour le réseau de premier rang non nommé, le fait attribué par Cloudflare est l’acceptation du /32 comme RTBH. L’analyse doit s’arrêter avant toute identification spéculative. Les éléments pertinents seraient l’autorisation du client, le périmètre du préfixe, la longueur, la communauté, la portée du blackhole, les journaux et le retrait vérifié.

Pour les détenteurs de préfixes et les opérateurs RPKI, la responsabilité porte sur l’exactitude et la continuité des données d’autorisation : ROA correct, longueur maximale appropriée, renouvellement, supervision de la chaîne de validation et capacité de correction. Elle ne s’étend pas à la configuration automatique de tous les réseaux tiers.

Pour Cloudflare, les contrôles comprennent la surveillance des annonces liées à ses services, la corrélation avec les symptômes, l’escalade, la coordination avec les pairs et transits, la communication publique et la vérification du rétablissement. Le service est exposé aux décisions de routage extérieures, mais son opérateur conserve un rôle dans la vitesse de détection et la qualité de la réponse.

Pour RouteViews et RIPE RIS, la fonction est celle de témoin technique. La qualité, la diversité et la conservation de leurs observations renforcent l’enquête. Ils ne deviennent pas pour autant les auteurs des routes qu’ils enregistrent.

Cette carte évite la recherche d’un responsable unique là où plusieurs frontières de contrôle se succèdent. L’origine, le client, le fournisseur, le route server, le transit, le gestionnaire de blackhole, le détenteur du préfixe et l’opérateur du service disposent chacun de leviers différents. Une analyse utile attribue à chaque acteur les décisions qu’il pouvait effectivement prendre.