La fuite de route de Cox en 2025 a démontré ce que le confinement RPKI peut prouver

Résumé

• L'analyse des mises à jour BGP par APNIC a révélé que l'AS22773 est apparu comme l'origine de 4 651 routes IPv4 supplémentaires le 1er mai 2025. Le point d'observation n'a intentionnellement pas rejeté les routes RPKI Invalides, ce qui a rendu visibles des routes qu'un locuteur rejetant les Invalides aurait exclues. [1]
• Les ajouts sont apparus en deux vagues principales. APNIC a enregistré environ 3 365 routes entre 16 h 45 et 16 h 50 UTC, puis environ 1 141 entre 17 h 50 et 17 h 55. Les retraits importants sont également survenus en deux étapes, vers 21 h 30 à 21 h 45 et 22 h 30 à 22 h 40. Ce sont les heures de réception chez un observateur, pas les horodatages d'un changement interne chez Cox. [1]
• Parmi les 4 651 routes supplémentaires, 4 644 auraient été RPKI Invalides pour un locuteur validant. Sept n'étaient couvertes par aucune ROA valide. Ce résultat montre une grande différence de confinement entre un point d'observation non validant et un réseau qui rejette les routes Invalides, sans prouver ce que chaque réseau a accepté ou exporté. [1]
• Une ROA fournit une autorisation pour qu'un préfixe soit originaire d'un AS, et la validation de l'origine de la route évalue l'appariement préfixe-origine observé par rapport aux données d'autorisation validées. ROV n'authentifie pas tous les AS du chemin, ne prouve pas la relation commerciale derrière une annonce, ni n'établit qu'une route était opérationnellement intentionnelle. [8][10][11]
• Le préjudice confirmé concerne l'intégrité du routage. Des origines erronées sont entrées dans les informations BGP conservées par l'observateur et sont restées disponibles pour les réseaux qui n'ont pas rejeté les routes Invalides. L'enregistrement fourni n'établit pas de panne visible par l'utilisateur, de détournement de paquets, d'interception, de perte de clients, de mesure réglementaire ou de dommage financier. [1][8]
• Le confinement par les réseaux en aval n'excuse pas l'origine. Cox contrôlait la création des routes, la redistribution, la politique sortante, le déploiement, la surveillance, le retrait et la divulgation. Les détenteurs de ressources contrôlaient l'exactitude des ROA, tandis que les pairs et les fournisseurs de transit contrôlaient séparément les filtres d'importation, la ROV et les décisions de propagation.
• Le chiffre alors en vigueur d'APNIC selon lequel les ROA couvraient environ 95,06 % de l'ensemble des préfixes IPv4 annoncés par Cox est un contexte d'adoption utile, pas une preuve de la configuration exacte au 1er mai ni une explication de la validité de chaque route divulguée. Les vues actuelles d'APNIC Labs, RIPEstat et Cloudflare Radar ne doivent pas être lues à rebours comme des instantanés historiques. [1]-[3][5][6]
• Les contrôles d'origine côté exportation, les rôles BGP, le mécanisme Only-to-Customer, les filtres explicites de préfixes et de chemins AS, et les défenses orientées chemin comme Peerlock représentent différentes classes de contrôle. Leurs normes et leurs enregistrements de recherche montrent ce que les opérateurs peuvent déployer, mais n'établissent pas quels contrôles Cox ou un voisin avaient activés pendant cet événement. [12]-[17]
• Les preuves publiques ne peuvent étayer une conclusion de confinement que si leurs limites restent visibles. Un seul observateur non validant montre la réception à cet endroit. Il ne montre pas l'acceptation voisin par voisin, la sélection de route, l'exportation ultérieure, le flux de trafic, la portée mondiale, ni l'heure exacte et la cause d'une correction interne.
• Un enregistrement crédible de responsabilité ajouterait un inventaire des préfixes intentionnels, des tests sémantiques de politique d'exportation, des alarmes d'origine anormale, des preuves de déploiement par étapes, des données de rejet par les voisins, des instantanés historiques des ROA, un calendrier exact des retraits et une explication post-événement du déclencheur, de la propriété et de la réparation. Jusqu'à ce que ces preuves existent, la fuite accidentelle et le confinement matériel par ROV restent des conclusions probables, tandis que la cause première, l'impact utilisateur et la remédiation restent inconnus.

Le contraste est la preuve

Le fait le plus important de cet événement n'est pas simplement que des milliers de routes sont apparues avec une origine inattendue. Les fuites de routes sont souvent décrites à travers les routes qui ont propagé, les services qui ont échoué ou les organisations qui ont ensuite expliqué une erreur de configuration. L'enregistrement fourni pour le 1er mai 2025 est différent. Il fournit un contraste observationnel contrôlé entre un point d'observation BGP qui a intentionnellement conservé les routes Invalides et l'ensemble de routes qui resterait utilisable sous une politique qui les rejette.

L'analyse d'APNIC par Geoff Huston a rapporté 4 651 routes IPv4 supplémentaires avec AS22773 comme origine observée. Elle a ensuite évalué ces paires préfixe-origine par rapport aux données d'autorisation RPKI. Parmi l'ensemble complet, 4 644 auraient été classées Invalides par un locuteur sensible à la RPKI. Sept n'avaient pas de couverture ROA valide.

[1] Ces chiffres ne montrent pas que chaque réseau validant s'est comporté de manière identique, mais ils identifient une frontière technique claire: presque tout l'ensemble observé était susceptible d'être rejeté par la validation d'origine car l'enregistrement d'autorisation ne permettait pas à AS22773 de l'originer.

C'est une preuve de contrôle positive. Les données d'autorisation existaient indépendamment de l'événement. Les réseaux pouvaient les récupérer et les valider indépendamment. Chaque réseau pouvait ensuite appliquer sa propre politique de routage à l'état de validité résultant. Un réseau rejetant les routes Invalides n'avait pas besoin que Cox identifie l'erreur, publie un post-mortem ou demande que chaque route soit filtrée. Le décalage entre l'origine observée et l'autorisation publiée était testable par machine.

Les mêmes preuves définissent également ce qui ne peut pas être affirmé. L'observateur APNIC était délibérément configuré pour ne pas rejeter les routes simplement parce qu'elles étaient Invalides. Sa vue ne peut donc pas être présentée comme celle d'un réseau validant typique. Inversement, la classification ne prouve pas que chaque réseau prétendant effectuer une ROV disposait de données fraîches, appliquait le rejet à chaque session, ou empêchait chaque route d'être sélectionnée ou exportée. Le résultat est un contrefactuel politique fort, pas un recensement mondial.

La distinction est importante pour la responsabilité. Si l'événement est décrit uniquement comme une fuite « arrêtée par la RPKI », l'expression cache les acteurs et les décisions qui ont produit le résultat. Les détenteurs de ressources ont dû publier des autorisations précises. Les dépôts RPKI et les validateurs ont dû rendre les données utilisables. Les opérateurs ont dû choisir de valider et de rejeter. Les moniteurs ont dû préserver une vue non validante pour que la différence soit observable. Pendant ce temps, le réseau d'origine devait encore contrôler ce qu'il originait et exportait.

Le confinement est apparu de couches indépendantes, pas d'un bouclier automatique.

Ce résultat en couches constitue le lien direct avec l'infrastructure réseau de l'article. Supprimez l'origine BGP, les données ROA et la politique de rejet local, et l'événement ainsi que la comparaison des preuves disparaissent. La question de la responsabilité n'est pas attachée au routage comme analogie. Elle découle de qui contrôlait les annonces, qui contrôlait les objets d'autorisation, qui contrôlait l'acceptation, et qui a conservé suffisamment de preuves pour tester l'affirmation de confinement.

Un événement en deux étapes vu d'un seul point d'observation

La chronologie commence avec l'observateur, pas avec un changement interne supposé. APNIC a rapporté une première grande addition d'environ 3 365 routes entre 16 h 45 et 16 h 50 UTC. Une deuxième addition d'environ 1 141 routes a suivi entre 17 h 50 et 17 h 55. Des retraits importants sont apparus plus tard en deux étapes, avec les plus grands changements vers 21 h 30 à 21 h 45 et 22 h 30 à 22 h 40. [1]

Ces chiffres doivent rester dans leurs contextes rapportés. Les deux comptes d'intervalle sont des observations larges du changement, tandis que 4 651 est le compte de l'analyse pour l'ensemble de routes supplémentaire tout au long de l'événement. Ils ne doivent pas être forcés dans une nouvelle décomposition arithmétique ou utilisés pour inférer une troisième étape non documentée. L'affirmation défendable est que l'observateur a vu deux vagues dominantes d'ajouts, un ensemble total de 4 651 origines supplémentaires, et deux vagues dominantes de retraits.

L'heure de réception n'est pas non plus l'heure d'action. Un collecteur BGP enregistre les mises à jour après qu'elles ont traversé les relations de routage et les décisions politiques pour l'atteindre. La première mise à jour visible à 16 h 45 UTC n'est pas la preuve qu'un opérateur, un système d'automatisation ou un routeur de Cox a changé d'état exactement à 16 h 45. Le dernier retrait visible vers 22 h 40 n'est pas la preuve que la réparation interne s'est terminée à ce moment. La chronologie publique mesure quand un observateur a reçu des informations de routage.

Cette prudence ne rend pas la chronologie faible. La forme est opérationnellement importante. Des milliers d'origines sont arrivées dans un court intervalle, un autre grand ensemble est arrivé environ une heure plus tard, et un retrait large a eu lieu plusieurs heures après les premières observations. La séquence est cohérente avec une exportation non intentionnelle et une correction ultérieure, c'est pourquoi l'analyse fournie traite une fuite accidentelle comme probable. Ce n'est pas une preuve d'intention malveillante, et cela n'identifie pas le changement qui a produit les annonces.

Les deux vagues invitent à des questions de contrôle sans y répondre. Deux chemins politiques se sont-ils activés séparément? Une configuration a-t-elle affecté différents groupes de routes à différents moments? La surveillance a-t-elle détecté la première vague avant la seconde? Les retraits ont-ils été échelonnés par nécessité technique, par des dispositifs séparés ou par des groupes politiques séparés? Rien dans l'enregistrement fourni ne choisit parmi ces possibilités. Un compte rendu responsable peut identifier les questions parce que les horodatages les rendent mesurables, mais il ne peut pas les convertir en conclusions.

Les retraits montrent également une correction dans la vue de routage, pas une remédiation durable. Supprimer une annonce erronée est nécessaire. Cela n'établit pas pourquoi l'annonce a été créée, si la configuration responsable a été annulée, si une garde a été ajoutée, si un chemin similaire est resté ailleurs, ou si une réparation testée a empêché la récurrence. Un enregistrement post-événement devrait connecter les retraits observés à des preuves de changement interne.

C'est là que l'observation indépendante soutient la responsabilité. L'opérateur contrôle ses journaux internes et ses enregistrements de changements. Les moniteurs externes contrôlent des preuves distinctes de ce qui les a atteints et quand cela a disparu. Lorsque ces enregistrements sont comparés, ils peuvent tester les déclarations sur la détection, la réponse et la propagation. Sans l'enregistrement externe, le public n'aurait que la chronologie que l'origine a choisie de divulguer. Sans enregistrements internes, l'observateur peut décrire la visibilité des routes mais pas la cause première.

Ce que signifient les 4 644 classifications Invalides

BGP fournit des informations d'accessibilité entre systèmes autonomes. La ligne de base du protocole décrit comment les locuteurs échangent des informations de routage et utilisent des attributs, y compris un chemin AS, pour prendre des décisions de routage. Elle ne prouve pas, par elle-même, que l'origine au bout d'un chemin reçu était autorisée par le détenteur de l'espace d'adressage. [9]

RPKI ajoute une couche d'autorisation distincte. Une autorisation d'origine de route (ROA) indique qu'un AS est autorisé à originer un préfixe couvert. Les spécifications de validation d'origine décrivent comment un locuteur BGP peut comparer un préfixe et un AS d'origine observés avec des données d'autorisation validées et attribuer un résultat de validité. [10][11] Dans cet événement, cette comparaison a été décisive: l'observateur a vu AS22773 comme origine, tandis que l'état d'autorisation rendait 4 644 des 4 651 routes supplémentaires Invalides pour un locuteur validant. [1]

Invalide est un résultat précis, mais ce n'est pas un verdict complet sur la route. Il dit que la paire préfixe-origine observée entre en conflit avec l'état d'autorisation validé. Il ne prouve pas pourquoi le conflit s'est produit. Une mauvaise exportation, un chemin de redistribution non intentionnel, une politique locale obsolète ou un autre événement opérationnel peut produire le décalage. L'enregistrement public ici n'identifie pas lequel.

Invalide n'authentifie pas non plus le chemin AS complet. Une route peut avoir une origine qui est autorisée tout en étant propagée d'une manière qui viole les relations commerciales intentionnelles. Elle peut aussi avoir une origine non autorisée même si le chemin visible contient de vrais numéros AS. ROV répond à la question de l'autorisation d'origine. Elle ne prouve pas que chaque relation de transit, segment de chemin ou décision d'exportation était légitime.

C'est pourquoi les sept routes non couvertes sont importantes. Elles ne partageaient pas la même base de ROA valide pour une classification Invalide. L'absence de cette couverture d'autorisation ne les rend pas démontrablement légitimes, et elle ne prouve pas que les réseaux les ont acceptées ou utilisées. Elle signifie que ce mécanisme de confinement particulier ne pouvait pas les rejeter sur la même base Invalide. Différents filtres, politique de routage ou décisions de l'opérateur devraient supporter la charge de contrôle.

Le chiffre de 4 644 est donc une preuve de la précision de l'autorisation en dehors du système d'exportation de l'origine fuyante. Les détenteurs de ressources avaient publié des informations qui permettaient à un réseau validant de distinguer une origine AS22773 non autorisée d'une origine autorisée. La valeur de ces informations est devenue visible précisément parce que l'événement d'origine était erroné. Une route correcte et une route erronée peuvent se ressembler au niveau de la syntaxe BGP ordinaire; RPKI fournit à la politique une entrée d'autorisation vérifiable de manière externe.

APNIC a également rapporté une couverture ROA alors en vigueur d'environ 95,06 % pour l'ensemble des préfixes IPv4 annoncés par Cox. [1][2] Ce chiffre appartient à l'enregistrement, mais il ne doit pas être confondu avec la classification de 4 644. La métrique de couverture de Cox décrit le contexte d'autorisation pour les préfixes que Cox a annoncés. L'ensemble divulgué impliquait AS22773 apparaissant comme origine pour des routes supplémentaires dont l'état d'autorisation ne permettait en grande partie pas cette origine.

Le confinement dépendait des données d'autorisation des détenteurs de ressources concernés et de la politique de validation de chaque réseau récepteur.

La vue RPKI associée d'APNIC Labs peut fournir un contexte de comportement, tandis que l'enregistrement RDAP d'ARIN établit le contexte d'enregistrement pour AS22773. [3][4] RIPEstat et Cloudflare Radar offrent un contexte de routage supplémentaire pour l'ASN. [5][6] Aucune de ces surfaces actuelles ne doit être utilisée comme substitut à un instantané historique du 1er mai. L'état du tableau de bord peut changer à mesure que les routes, les autorisations et les méthodes de mesure changent.

La conclusion de l'événement repose sur l'analyse historique et ses données de mise à jour observées, pas sur la lecture d'un tableau de bord actuel à rebours.

Le confinement est un contrefactuel politique, pas une affirmation de portée mondiale

L'expression « la RPKI a contenu la fuite » n'est défendable que lorsque ses termes sont explicites. Le point d'observation APNIC a conservé les routes Invalides. Un locuteur utilisant le même état d'autorisation validé et une politique qui rejette les routes Invalides exclurait 4 644 routes de l'ensemble utilisable. Le contraste observé démontre ce que la politique de rejet pouvait contenir. Il n'énumère pas chaque réseau qui a appliqué cette politique.

Cette différence sépare la réception, la classification, l'acceptation, la sélection et la propagation. Un routeur peut recevoir une mise à jour d'un voisin et classifier son état d'origine. La politique locale détermine ensuite si cette mise à jour reste éligible. Une route rejetée peut encore être présente dans un enregistrement de diagnostic même si elle n'est pas sélectionnée pour le transfert ou annoncée plus loin. La preuve APNIC concerne les routes conservées par un observateur non rejetant et la classification qu'elles recevraient sous validation. Ce n'est pas une télémétrie de paquets.

En conséquence, l'analyse ne prouve pas que le trafic a été détourné vers AS22773. Elle ne prouve pas qu'un client a subi une perte, une latence ou une panne d'accessibilité. Elle ne prouve pas d'interception. Elle ne prouve pas non plus qu'aucun utilisateur n'a été affecté. Ces résultats nécessitent des mesures de trafic, des déclarations de réseaux affectés ou des preuves de service qui ne figurent pas dans l'enregistrement fourni.

La même discipline s'applique à la propagation. La réception par un observateur prouve que les annonces ont traversé suffisamment de frontières politiques pour atteindre cet observateur. Elle n'établit pas une portée mondiale. Elle n'identifie pas chaque voisin qui a accepté les routes, chaque fournisseur en amont qui les a exportées, chaque serveur de routes qui les a relayées ou chaque réseau qui les a rejetées. Une relecture multi-collecteurs pourrait produire une carte de propagation plus large, mais cette preuve n'est pas fournie ici.

La méthodologie de surveillance RPKI du NIST est pertinente car les mesures de validation dépendent des données, du point d'observation, du timing et de la méthode de classification. [7] Une conclusion de validité historique devrait lier la vue de route à l'état d'autorisation utilisé à ce moment. Une vérification de validité actuelle peut être informative mais peut ne pas reproduire ce que les validateurs savaient pendant l'événement. C'est pourquoi les instantanés historiques des ROA font partie des preuves manquantes.

Le guide de pratique du NIST explique l'architecture et les risques pour l'intégrité du routage que la validation d'origine est conçue pour traiter. [8] Il peut soutenir la conclusion que les origines non autorisées créent un problème de contrôle et que ROV fournit une défense pratique. Il ne peut pas transformer l'événement Cox en une panne ou une perte prouvée. Les classes de dommages générales ne sont pas des conclusions de dommages spécifiques à un événement.

La conclusion la plus forte est plus étroite et plus utile. La fuite a atteint un observateur délibérément non validant. Presque toutes les paires préfixe-origine supplémentaires étaient incompatibles avec les données d'autorisation validées. Par conséquent, un opérateur rejetant les routes Invalides disposait d'une base concrète et localement exécutoire pour empêcher ces routes d'entrer dans son ensemble de routes utilisables. La preuve soutient un potentiel de confinement matériel et un confinement réel probable, tandis que le résultat exact réseau par réseau reste inconnu.

Le préjudice confirmé est à l'intégrité du routage

L'analyse des risques s'affaiblit souvent lorsqu'un mécanisme dramatique est utilisé pour porter une affirmation d'impact non étayée. C'est inutile ici. L'événement a un préjudice confirmé même sans preuve de panne: les informations de routage ont été contaminées par des milliers d'origines supplémentaires que le système d'autorisation a en grande partie identifiées comme Invalides.

L'intégrité du routage est importante car les opérateurs dépendent des annonces reçues pour décider où les préfixes sont accessibles. Une origine erronée crée une exposition dans chaque réseau qui la reçoit sans règle de rejet efficace. L'exposition n'est pas identique au détournement de trafic, mais c'est la condition préalable qui peut rendre une route erronée opérationnellement disponible.

L'observateur non validant démontre cette exposition directement. Sa politique a préservé les annonces, montrant que la propagation BGP ordinaire pouvait les transporter jusqu'à ce point. Un réseau avec une visibilité comparable mais sans rejet des Invalides aurait pu les conserver comme candidats. Qu'il les ait sélectionnés ou exportés dépendrait de ses autres routes et de sa politique. Les preuves publiques ne résolvent pas ces décisions en aval.

Cette frontière empêche à la fois la sous-estimation et l'exagération. Appeler l'événement inoffensif parce qu'une grande partie d'Internet a peut-être appliqué la ROV ignorerait la contamination observée et les sept routes sans la même couverture d'autorisation. L'appeler une panne majeure inventerait un résultat. La déclaration d'impact correcte est que les origines supplémentaires d'AS22773 ont créé une exposition à l'intégrité du routage, tandis que des ROA précises et une politique ROV locale ont fourni une couche de confinement mesurable.

La note d'impact devrait donc refléter la signification du contrôle plutôt qu'une perte de client supposée. L'événement a testé une sauvegarde de routage Internet contre un grand ensemble d'origines erronées. Il a également montré l'exposition résiduelle des réseaux non validants et des routes non couvertes. C'est un événement d'infrastructure significatif même si les sources fournies n'établissent pas de victime nommée ou de conséquence financière.

Le succès en aval ne transfère pas le devoir de l'origine

L'erreur de responsabilité la plus importante serait de traiter le filtrage réussi en aval comme une permission pour un réseau d'origine de compter sur ses voisins. ROV est précieux car les réseaux indépendants peuvent se protéger. Cette indépendance ne change pas qui contrôlait la création et l'exportation des mauvaises origines.

Cox contrôlait les systèmes et les politiques qui ont fait apparaître AS22773 comme origine. L'enregistrement public ne révèle pas le mécanisme interne, mais les catégories de contrôle sont claires: création de routes, redistribution de routes, politique sortante, déploiement de changements, surveillance, escalade, retrait et divulgation. Chaque catégorie reste avec l'opérateur même lorsqu'un autre réseau rejette le résultat.

Un inventaire des préfixes intentionnels est la première unité de preuve. Un opérateur devrait être capable de déclarer quels préfixes chaque AS d'origine et chaque contexte d'exportation peut annoncer. Cet inventaire doit être utilisable pour la génération et les tests de politique, pas seulement documenté après l'événement. Un changement qui ferait originer par un AS des milliers de préfixes supplémentaires devrait être comparé à l'ensemble intentionnel avant d'atteindre une session externe.

Le test sémantique est différent de la vérification qu'une configuration est analysable. Une politique syntaxiquement valide peut encore exporter les mauvaises routes. Le test pertinent demande ce que la politique résultante annoncerait après la redistribution des routes, les transformations locales et les règles spécifiques à la session. Un test devrait échouer lorsque le résultat effectif dépasse la frontière de préfixe et d'origine intentionnelle.

Le déploiement par étapes est un autre contrôle côté origine. Une politique qui modifie l'éligibilité des routes sur de nombreuses sessions n'a pas besoin du système de routage mondial pour révéler sa signification. Un déploiement limité, une inspection des différences de routes et des conditions d'arrêt automatique peuvent exposer un grand changement d'ensemble d'origine avant qu'il n'atteigne chaque sortie affectée. L'enregistrement fourni n'établit pas si Cox a utilisé de tels contrôles.

La surveillance doit rechercher un changement sémantique, pas seulement la santé des dispositifs. Un routeur peut être disponible et une session BGP peut rester établie pendant que les routes envoyées à travers elle sont erronées. Une alarme d'origine anormale peut comparer l'ensemble actuel originaire avec une ligne de base approuvée. Un seuil de changement maximum peut exiger une révision lorsque des milliers de routes apparaissent. Des moniteurs indépendants peuvent confirmer ce qui a échappé à la télémétrie propre du réseau.

Les preuves de réponse connectent ensuite la détection au retrait. Le retrait observé en deux étapes fournit des horodatages externes. L'enregistrement interne de Cox pourrait montrer quand l'anomalie a été détectée pour la première fois, qui possédait la décision, quelles sessions ou politiques ont été modifiées, pourquoi le retrait est survenu en deux vagues larges, et quelles vérifications ont confirmé l'achèvement. Sans cet enregistrement, le public peut voir la correction dans le flux de routes mais pas le chemin de contrôle derrière elle.

La divulgation fait partie de la responsabilité opérationnelle parce que l'origine possède des faits que les étrangers ne peuvent pas reconstituer à partir du seul BGP. Une explication post-événement n'a pas besoin d'exposer une configuration sensible. Elle peut identifier la classe de contrôle qui a échoué, l'ampleur de l'exportation non intentionnelle, la source de détection, la séquence de correction, les sauvegardes ajoutées et les preuves utilisées pour les tester. Aucun post-mortem de Cox n'est présent dans l'enregistrement fourni, donc aucun de ces détails ne peut être affirmé.

L'exactitude des ROA appartient aux détenteurs de ressources

L'événement montre également pourquoi les données d'autorisation sont un contrôle opérationnel, pas des métadonnées de registre décoratives. Les 4 644 résultats Invalides étaient possibles parce que les détenteurs de ressources concernés avaient fourni une autorisation qui ne permettait pas AS22773 comme origine. Leur action de contrôle a eu lieu avant la fuite, et les réseaux en aval pouvaient la consommer sans se coordonner avec Cox pendant l'événement.

Cela produit un modèle de responsabilité distribué. Un détenteur de ressources contrôle si ses ROA décrivent avec précision les arrangements d'origine autorisés. Un service de RIR et le système de publication RPKI au sens large soutiennent la disponibilité du matériel signé. Les parties prenantes valident les données. Les opérateurs réseau décident comment l'état de validation affecte la politique de routage. Aucune partie ne contrôle toute la chaîne.

L'exactitude est essentielle car une erreur d'autorisation peut créer un mode de défaillance différent. Une autorisation trop étroite, obsolète ou autrement incorrecte peut faire classer une annonce légitime comme Invalide. Ce résultat inverse est en dehors de l'événement de cet article, mais il explique pourquoi l'adoption de la RPKI doit inclure la coordination et les tests de changement. La preuve positive ici provient de données d'autorisation qui distinguaient les origines erronées; ce n'est pas une affirmation que chaque ROA est toujours correcte.

Les sept routes non couvertes identifient le résidu. Là où aucune autorisation valide ne couvre une route, une politique de rejet des Invalides manque de la même base pour bloquer l'origine. Cela n'éloigne pas la responsabilité de l'opérateur d'origine. Cela montre que la couverture du détenteur de ressources et les contrôles d'exportation côté opérateur résolvent différentes parties du problème.

La preuve historique fait donc partie de la gouvernance des ROA. Un tableau de bord actuel ne peut pas montrer de manière concluante quelle autorisation existait lorsqu'une mise à jour a été observée. Les détenteurs de ressources, les dépôts et les moniteurs devraient préserver des instantanés qui permettent à un examinateur ultérieur de reproduire la classification de validité par rapport au moment pertinent. Dans cet événement, un instantané historique capable de tester les comptes de 4 644 et sept renforcerait l'enregistrement.

La politique des voisins est une surface de contrôle distincte

Les pairs et les fournisseurs de transit contrôlaient ce qui se passait après que les annonces aient quitté AS22773. Leurs contrôles incluaient des filtres de préfixes, des filtres de chemins AS, des politiques ROV, des limites de préfixes maximum, des alertes de changement anormal et des règles d'exportation ultérieure. Le fait que l'origine était responsable des mauvaises routes ne rend pas les décisions des voisins non pertinentes. Un voisin peut soit contraindre, soit amplifier l'erreur d'une origine.

ROV est la preuve la plus claire côté voisin dans ce cas. Un réseau rejetant les routes Invalides avait une raison directe d'exclure 4 644 paires préfixe-origine. Cette politique protégeait le réseau et limitait les routes disponibles pour la propagation ultérieure. Elle réduisait également la dépendance à une liste maintenue manuellement de chaque préfixe que Cox était censé originer.

Cependant, ROV seule ne règle pas chaque fuite. La taxonomie des fuites de routes reconnaît que les annonces peuvent échapper à une relation intentionnelle même lorsque l'origine elle-même est autorisée. [12] Dans un tel cas, une paire préfixe-origine peut passer la ROV tandis que le chemin viole une attente d'exportation. Cet événement a produit un grand ensemble Invalide, donc la validation d'origine a été exceptionnellement efficace. Ce succès ne doit pas être généralisé à chaque fuite de route.

Le filtrage explicite des préfixes reste pertinent pour les sept routes non couvertes et pour la défense en profondeur. Les directives MANRS placent à la fois le filtrage des préfixes et des chemins AS dans l'ensemble de contrôle de l'opérateur. [15] Un fournisseur qui a une vue fiable de ce qu'un client peut annoncer peut rejeter les routes en dehors de cette frontière. Les règles de chemin AS peuvent également détecter des relations ou des contenus de chemin qui ne devraient pas arriver d'une session donnée.

Les contrôles de préfixe maximum sont utiles mais incomplets. Un seuil peut détecter un changement soudain du nombre de routes, mais un nombre seul ne prouve pas que chaque route est autorisée ou intentionnelle. Un seuil élevé peut permettre une grande erreur; un seuil bas peut interrompre un changement légitime. La conception plus forte combine des garde-fous basés sur le nombre avec une politique sensible à l'autorisation et à la relation.

Les preuves des voisins rendraient l'affirmation de confinement mesurable. Chaque voisin direct pourrait rapporter combien des routes supplémentaires il a reçues, combien il a classées Invalides, combien il a rejetées, si certaines ont été sélectionnées, et si certaines ont été exportées. Une divulgation agrégée pourrait préserver la confidentialité commerciale tout en montrant le résultat du contrôle. Aucune donnée voisin par voisin n'est dans l'enregistrement fourni.

La répartition de la responsabilité est donc asymétrique mais partagée. Cox conservait la responsabilité principale de prévenir les origines erronées et de les corriger. Les voisins conservaient la responsabilité de protéger leurs propres domaines de routage et de limiter la propagation. Les détenteurs de ressources conservaient la responsabilité d'autorisations précises. Le succès d'une couche est la preuve que les contrôles en couches fonctionnent, pas une raison pour qu'une autre couche disparaisse.

Les sauvegardes d'exportation et de relation traitent différentes classes de défaillance

Le registre des normes fournit des classes de contrôle supplémentaires sans prouver le déploiement. La RFC 8893 traite de la validation de l'origine RPKI dans le contexte de l'exportation et attire l'attention sur l'origine effective après les transformations de routage locales d'un réseau. [13] Cela importe car une route peut changer de signification à l'intérieur d'un opérateur avant l'exportation. Une vérification qui se produit à un seul point d'entrée peut ne pas évaluer le résultat préfixe-origine qu'un voisin externe recevra réellement.

Pour AS22773, la question pertinente est de savoir si l'origine effective exportée et l'ensemble de préfixes ont été comparés à une frontière approuvée et autorisée avant que les mises à jour ne quittent le réseau. Les preuves publiques ne peuvent pas y répondre. La norme montre que la validation côté exportation est une option de contrôle reconnue; elle n'établit pas les capacités, la configuration ou l'application du routeur de Cox au 1er mai.

La RFC 9234 fournit un contrôle orienté relation via les rôles BGP et le mécanisme Only-to-Customer. [14] Ces mécanismes aident les réseaux à exprimer les rôles de session et à identifier les annonces qui ne devraient pas être propagées dans certaines directions. Ils traitent d'une dimension différente de l'autorisation d'origine: si la propagation d'une route est cohérente avec la relation représentée par la session.

Cette distinction importe car un opérateur peut produire au moins deux grandes classes d'erreur. Il peut originer un préfixe qu'il n'est pas autorisé à originer, ce que ROV peut identifier lorsque l'autorisation existe. Ou il peut propager une route avec une origine autorisée au-delà de sa relation intentionnelle, ce qui peut nécessiter des contrôles de chemin et de relation. Une conception de routage robuste traite ces vérifications comme complémentaires.

Les directives de filtrage MANRS rendent l'attente opérationnelle explicite en incluant des contrôles de préfixe et de chemin AS plutôt que de réduire la sécurité du routage à un seul indicateur de validité. [15] Le cadre de mesure de l'Observatoire MANRS reconnaît également les fuites de routes et les réseaux qui permettent la propagation comme des phénomènes mesurables. [16] La mesure n'attribue pas de responsabilité légale, mais elle peut montrer si un opérateur origine, accepte ou propage de manière répétée des informations de routage anormales.

La recherche Peerlock fournit des preuves que les défenses orientées chemin peuvent contraindre la propagation des fuites de routes. [17] Sa pertinence ici n'est pas que Peerlock ait été nécessairement déployé par Cox ou ses voisins. L'enregistrement fourni ne le dit pas. La recherche démontre que les opérateurs ont des options de contrôle au-delà de la ROV lorsque le chemin ou la relation, plutôt que l'autorisation d'origine, porte l'avertissement.

Ces classes de contrôle ne doivent pas être effondrées. ROV vérifie l'autorisation d'origine. Les filtres de préfixes comparent les annonces avec un ensemble autorisé. Les filtres de chemin AS inspectent le contenu du chemin. Les rôles BGP et OTC communiquent les attentes de relation. Une politique de style Peerlock contraint les chemins impliquant des réseaux protégés. Les limites de préfixe maximum détectent les changements d'échelle. La surveillance compare le comportement observé avec des lignes de base. Chacune attrape un sous-ensemble différent de défaillances.

L'observation est à la fois une fonction de contrôle et de preuve

La décision de l'observateur APNIC de ne pas rejeter les routes Invalides peut sembler contraire à la politique défensive normale. Dans un système de mesure, elle servait un objectif différent. En conservant les annonces qu'un réseau de production pourrait rejeter, l'observateur a préservé la preuve de ce qui était émis et propagé. [1]

Cette fonction de preuve est essentielle. Si chaque point de vue public rejetait les mêmes routes avant de les enregistrer, la communauté du routage pourrait savoir que la défense fonctionnait localement mais perdrait la visibilité sur les mauvaises annonces elles-mêmes. Un flux délibérément non validant peut exposer l'origine, les préfixes, le timing et le modèle de retrait nécessaires pour comprendre l'événement.

Les réseaux de production et les systèmes de mesure ont donc des objectifs valides différents. Un opérateur de production peut rejeter les routes Invalides pour protéger le trafic et réduire la propagation. Un moniteur peut les conserver dans une vue analytique isolée pour rendre les anomalies observables. Le choix du moniteur n'est pas la preuve que les réseaux de production devraient accepter les routes.

De multiples surfaces d'observation améliorent la confiance. ARIN RDAP fournit un contexte de registre pour AS22773. [4] RIPEstat peut fournir un contexte ASN et de routage indépendant. [5] Cloudflare Radar offre une autre vue de routage. [6] APNIC Labs offre une couverture ROA et un contexte de comportement RPKI. [2][3] NIST décrit une méthodologie pour la surveillance RPKI. [7] Les comptes et la chronologie spécifiques à l'événement, cependant, proviennent de l'analyse d'APNIC, et les tableaux de bord actuels ne peuvent pas remplacer cet enregistrement historique.

Une conception de surveillance responsable préserve à la fois les mises à jour de routes et les données d'autorisation utilisées pour les classer. Elle enregistre l'identité du collecteur, la politique, la base de temps et la fraîcheur des données. Elle distingue les routes reçues des routes sélectionnées. Elle conserve également suffisamment d'informations pour recalculer le résultat lorsque le logiciel de validité ou les données source changent.

La même conception devrait soutenir des alarmes rapides. Une nouvelle origine pour des milliers de préfixes est un événement observable. Les détenteurs de ressources peuvent surveiller leur propre espace d'adressage pour des origines non autorisées. Un opérateur d'origine peut surveiller son ensemble annoncé pour une croissance inattendue. Les voisins peuvent surveiller les mises à jour acceptées et rejetées. Les services indépendants peuvent comparer les vues et alerter lorsque la propagation franchit les frontières attendues.

L'enregistrement fourni ne montre pas qui a détecté en premier l'anomalie AS22773 ni si l'observation externe a précédé la détection interne. Ce fait affecterait matériellement l'analyse de responsabilité. Si Cox a détecté l'événement à partir de ses propres contrôles sémantiques, la preuve soutiendrait une observabilité interne. Si des outsiders l'ont détecté en premier, le cas pour un renforcement de la surveillance côté origine serait plus direct. L'enregistrement actuel laisse cette séquence inconnue.

La responsabilité suit cinq propriétaires de contrôle

L'événement peut être réparti entre cinq propriétaires pratiques sans prétendre que chacun avait un pouvoir égal.

Cox et AS22773 contrôlaient l'origine et l'exportation.Cela inclut quelles routes sont entrées dans un ensemble originaire ou redistribué, quelles politiques les ont rendues éligibles pour les sessions externes, comment les changements ont été examinés, comment la croissance anormale a été détectée, comment les retraits ont été exécutés et ce que l'entreprise a divulgué par la suite. L'origine observée en fait la surface principale de prévention et d'explication.

Les détenteurs de ressources contrôlaient l'exactitude de l'autorisation.Leurs ROA ont permis aux réseaux validants d'identifier la plupart des origines AS22773 comme Invalides. Ils contrôlaient également si les préfixes non couverts restaient en dehors de cette couche. Leur responsabilité est de maintenir l'autorisation alignée sur les arrangements de routage légitimes et de préserver les preuves de changements.

Les pairs et les fournisseurs de transit contrôlaient l'acceptation et la propagation.Chaque réseau choisissait de valider ou non, de rejeter les routes Invalides ou non, quels filtres de préfixe et de chemin appliquer, quels seuils appliquer et s'il fallait exporter une route reçue plus loin. Leurs choix déterminaient la portée de l'événement au-delà de l'origine.

Les fournisseurs et les implémenteurs de normes contrôlaient les sauvegardes disponibles.Le comportement des routeurs, le langage politique, l'intégration de la validation, les vérifications d'origine effective, les rôles BGP et le support OTC façonnent ce que les opérateurs peuvent appliquer de manière fiable. La disponibilité n'est pas le déploiement, et le déploiement n'est pas la configuration correcte. L'enregistrement public n'établit ni l'un ni l'autre pour Cox.

Les moniteurs indépendants contrôlaient l'observabilité publique.Leurs flux de routes, leurs instantanés d'autorisation et leurs méthodes analytiques déterminent si les affirmations de confinement peuvent être testées. Un moniteur peut montrer qu'une route est arrivée et comment elle s'est classée à ce point d'observation. Il ne peut pas fournir le déclencheur interne de Cox ou le résultat du trafic.

Cette répartition évite deux erreurs courantes. La première est la simplification à une seule partie, dans laquelle chaque acceptation en aval est traitée comme l'action de l'origine. Les réseaux prennent des décisions politiques indépendantes, donc le contrôle de la propagation est partagé. La seconde est la dilution de la responsabilité, dans laquelle le contrôle partagé devient le devoir de personne. Les voisins de Cox pouvaient contenir une erreur, mais seul Cox contrôlait si AS22773 l'émettait.

La charge de la preuve devrait suivre ces pouvoirs. Cox pourrait divulguer des preuves d'exportation intentionnelle et de correction. Les détenteurs de ressources et les services RPKI pourraient préserver l'historique des autorisations. Les voisins pourraient divulguer des données agrégées de rejet et de propagation. Les fournisseurs pourraient documenter les sauvegardes prises en charge et le comportement testé. Les moniteurs pourraient publier des observations reproductibles. Aucun acteur n'a besoin d'accéder au système interne de chaque autre acteur pour prouver la partie qu'il contrôlait.

La divulgation devrait rendre le résultat de contrôle reproductible

Une divulgation post-événement solide commencerait par l'ensemble de routes observé et séparerait les faits des inférences. Elle identifierait combien de préfixes supplémentaires ont été originaires, quels contextes d'exportation étaient impliqués, quand l'opérateur a détecté le changement pour la première fois, et quand les actions correctives ont commencé. Elle concilierait ses horodatages internes avec les heures de réception et de retrait externes.

La section suivante identifierait le déclencheur sans exagérer la faute. Une règle de redistribution, un changement d'automatisation, une entrée de session client, une action de maintenance ou une configuration humaine sont toutes des catégories possibles. L'enregistrement fourni n'en établit pas une. Une divulgation devrait nommer le chemin réel et expliquer pourquoi l'examen ou les garde-fous existants ne l'ont pas arrêté.

Les preuves de contrôle devraient suivre. L'opérateur pourrait montrer que la politique réparée ne produit qu'un ensemble de préfixes approuvé, que les origines effectives sont vérifiées avant l'exportation, qu'une grande augmentation de l'ensemble de routes déclenche un arrêt, et que le déploiement par étapes empêche un changement équivalent d'atteindre toutes les sessions externes. Les résultats de test sont plus utiles qu'une déclaration générale selon laquelle les procédures ont été améliorées.

Les preuves de confinement devraient rester séparées. Cox pourrait demander des rapports agrégés des voisins directs montrant le rejet des Invalides et toute acceptation résiduelle. Les collecteurs indépendants pourraient rejouer l'événement. Les données historiques des ROA pourraient reproduire les classifications de 4 644 et sept. Ces enregistrements quantifieraient ce que les contrôles externes ont accompli sans les réécrire comme une prévention côté origine.

Les preuves d'impact devraient également rester limitées. La télémétrie du trafic pourrait montrer si des paquets ont suivi une route erronée. Les enregistrements de service pourraient montrer si l'accessibilité ou les performances ont changé. Les réseaux affectés pourraient signaler des incidents. En leur absence, l'opérateur ne devrait pas impliquer qu'une ROV réussie signifie qu'aucun effet ne s'est produit, et les critiques ne devraient pas prétendre à une panne simplement parce qu'une fuite a été observée.

Enfin, la remédiation devrait être liée à des tests de récurrence. Un retrait de route met fin à l'événement visible. Il ne prouve pas que la condition responsable ne peut pas se reproduire. Un compte rendu durable identifierait le contrôle ajouté, le scénario utilisé pour le tester, la portée du déploiement et la métrique continue qui révélerait une régression.

Aucune divulgation de Cox de ce type n'est incluse dans l'enregistrement fourni. Cette absence ne prouve pas que Cox n'a pas enquêté ou réparé le problème en interne. Elle signifie que les preuves publiques ne peuvent pas évaluer ces actions. La responsabilité s'arrête à la frontière de ce qui peut être montré.

Carte des preuves et limites des affirmations

L'enregistrement source soutient différentes affirmations avec différentes forces. Garder ces rôles séparés empêche un document de norme ou un tableau de bord actuel d'être utilisé comme preuve d'événement.

Cette carte mène à une hiérarchie claire. La source [1] porte les faits de l'événement. Les sources [2] à [7] fournissent des mesures, une identité et un contexte, avec des limites temporelles. Les sources [8] à [17] expliquent l'architecture de contrôle, les normes et les défenses disponibles. Aucune de ces dernières ne peut être substituée à un post-mortem de Cox ou à une reconstruction multi-collecteurs de l'événement.

Preuves qui changeraient l'analyse

Plusieurs types de nouvelles preuves pourraient modifier matériellement la conclusion.

Un post-mortem de Cox pourrait identifier le déclencheur, le chemin politique responsable, la source de détection, la séquence de retrait et la réparation. Il pourrait renforcer la conclusion que l'événement était accidentel, ou montrer que certaines routes ont été intentionnellement générées dans un contexte limité. Il pourrait également révéler qu'une catégorie de contrôle supposée n'était pas impliquée.

Une relecture multi-collecteurs pourrait quantifier la propagation réelle. Elle pourrait montrer que les routes ont atteint de nombreux réseaux non validants, ou que l'acceptation était bien plus limitée que ce que suggère la réception d'un seul observateur. Les enregistrements des voisins directs pourraient identifier où le rejet des Invalides a fonctionné et où il n'a pas fonctionné.

Des instantanés historiques des ROA pourraient reproduire ou réviser les classifications de 4 644 Invalides et sept non couvertes. Parce que les données d'autorisation changent, une archive temporelle est plus probante qu'une requête actuelle. Toute révision de ces comptes changerait la frontière de confinement mesurée.

La télémétrie du trafic, la surveillance des services ou les déclarations des réseaux affectés pourraient prouver ou réfuter un préjudice visible par l'utilisateur. La preuve que le trafic a suivi les routes supplémentaires ferait passer l'analyse au-delà de l'exposition à l'intégrité du routage. La preuve que les routes n'ont jamais été sélectionnées resserrerait l'impact. Aucun des deux résultats n'est disponible ici.

Enfin, la preuve que les routes étaient autorisées, délibérément originaires ou confinées à un environnement de test limité remettrait en question la caractérisation de fuite elle-même. Le modèle actuel rend une exportation non intentionnelle probable, mais la probabilité ne remplace pas la preuve interne.

Jusqu'à ce qu'un de ces enregistrements apparaisse, la conclusion disciplinée est stable. AS22773 a été observé comme originaire de 4 651 routes IPv4 supplémentaires. Presque toutes présentaient un décalage d'autorisation qu'un locuteur rejetant les Invalides pouvait appliquer. L'événement démontre une capacité de confinement RPKI matérielle et la valeur de ROA précises, tout en laissant non résolus la portée mondiale, l'effet sur le trafic, le déclencheur, l'intention et la réparation.

Le confinement est la preuve d'une couche, pas la preuve d'un système

L'événement du 1er mai donne aux opérateurs réseau une comparaison mesurable rare. L'observateur non validant a conservé des milliers de routes. Les données RPKI ont classé 4 644 d'entre elles d'une manière qui permettait aux réseaux validants de les rejeter localement. C'est une preuve solide que l'autorisation d'origine peut transformer une erreur de routage en une condition politique contenable.

Ce n'est pas la preuve que la RPKI valide le chemin complet, que tous les réseaux ont rejeté les annonces, que les sept routes non couvertes étaient inoffensives, ou que les contrôles d'origine et d'exportation peuvent être délégués aux voisins. Ce n'est pas non plus la preuve d'une panne client, d'une interception, d'une perte ou d'une violation réglementaire.

Le résultat de responsabilité suit le contrôle. Cox contrôlait ce qu'AS22773 originait et exportait. Les détenteurs de ressources contrôlaient l'exactitude de l'autorisation. Les voisins contrôlaient l'acceptation et la propagation. Les fournisseurs contrôlaient les sauvegardes utilisables. Les moniteurs contrôlaient les preuves indépendantes. Chaque couche peut prouver sa propre action, et aucune couche ne peut utiliser le succès d'une autre pour effacer son devoir.

La clôture la plus crédible serait donc mesurable: un inventaire des préfixes intentionnels, des sémantiques d'exportation testées, des alarmes d'origine anormale, un déploiement par étapes, des données de rejet des voisins, des instantanés historiques d'autorisation, un calendrier de retrait reconcilié et une explication publique de la cause et de la réparation. Le confinement RPKI a déjà montré ce qu'une couche peut prouver. La question sans réponse est de savoir si les autres propriétaires de contrôle peuvent produire des preuves d'une précision égale.

Sources

Accès vérifié: 2026-07-25

1. https://blog.apnic.net/2025/05/06/analysis-of-a-route-leak/
2. https://stats.labs.apnic.net/roa/AS22773?d=Percent&o=a22773cl0s0rvttrdp&t=Route+Objects&v=IPv4&x=1&z=1
3. https://stats.labs.apnic.net/RPKI/AS22773
4. https://rdap.arin.net/registry/autnum/22773
5. https://stat.ripe.net/data/as-overview/data.json?resource=AS22773
6. https://radar.cloudflare.com/routing/as22773
7. https://rpki-monitor.antd.nist.gov/Methodology
8. https://csrc.nist.gov/pubs/sp/1800/14/final
9. https://www.rfc-editor.org/rfc/rfc4271.html
10. https://www.rfc-editor.org/rfc/rfc6483.html
11. https://www.rfc-editor.org/rfc/rfc6811.html
12. https://www.rfc-editor.org/rfc/rfc7908.html
13. https://www.rfc-editor.org/rfc/rfc8893.html
14. https://www.rfc-editor.org/rfc/rfc9234.html
15. https://docs.manrs.org/docs/network-guide/filtering/
16. https://manrs.org/manrs-observatory/measurement-framework/
17. https://arxiv.org/abs/2006.06576