Un ROA défectueux peut transformer la sécurité du routage en une panne de mode commun

Résumé

• Le 18 mars 2025, des sources d’analyse réseau publiques ont signalé que des routes BGP liées à la Corée du Nord devenaient RPKI-invalides après la publication d’une ROA défectueuse, autorisant apparemment un /22 alors que le réseau annonçait quatre /24.
• L’incident constitue un cas utile de redevabilité car le mécanisme de sécurité du routage a fonctionné comme prévu du point de vue du validateur: les réseaux rejetant les routes invalides ont réduit la connectivité pour des routes opérationnellement légitimes mais incohérentes avec la nouvelle ROA.
• L’échec n’était donc pas un argument contre RPKI. Il démontrait que les données RPKI sont devenues une infrastructure partagée et doivent être régies par une revue des modifications, des phases de test, une discipline sur maxLength, une surveillance, des retours arrière et des alertes.
• La dépendance de mode commun est le risque clé. À mesure que davantage de réseaux adoptent la validation d’origine de route et rejettent les invalides, une seule erreur de publication du détenteur de ressource ou d’un RIR peut avoir des conséquences opérationnelles plus larges car de nombreux réseaux consomment la même déclaration cryptographique.
• La norme de réparation devrait être vérifiable: identifier les préfixes invalides, corriger la ROA, mesurer la reprise de la propagation des routes, conserver la chronologie et publier suffisamment de preuves pour que les autres opérateurs puissent auditer leurs propres contrôles de maxLength et d’alertes.

Registre de preuves et utilisation

Cet article traite le registre public comme des preuves stratifiées. Les rapports d’incident, les normes, les mesures de navigateur ou de routage, les documents réglementaires ou politiques et les guides opérationnels actuels sont utilisés pour différentes affirmations. Les sources provenant d’entreprises sont attribuées comme des positions d’entreprise. Les normes et les guides ultérieurs sont utilisés pour expliquer les contrôles et présenter les attentes de redevabilité, et non pour inventer des faits privés ou pour imposer rétroactivement des obligations ultérieures lorsque le registre public ne soutient pas une telle affirmation.

RPKI a rendu l'erreur visible et conséquente

RPKI existe parce que le BGP ordinaire laisse trop de place aux réseaux pour croire de fausses déclarations de connectivité. Les autorisations d’origine de route permettent aux détenteurs de ressources de dire quel système autonome peut annoncer tel préfixe et, via maxLength, à quel point l’annonce peut être spécifique. Les réseaux qui effectuent la validation d’origine de route peuvent alors traiter les routes comme valides, invalides ou non trouvées, et appliquer une politique. C’est une amélioration majeure de la sécurité.

L’incident de la ROA défectueuse en Corée du Nord montre que cette amélioration crée une nouvelle dépendance opérationnelle à l’exactitude des données d’autorisation publiées.

Kentik a rapporté que le 18 mars 2025, les routes BGP de la Corée du Nord sont devenues RPKI-invalides à cause de la publication d’une ROA défectueuse. D’autres rapports publics décrivent une autorisation /22 avec un maxLength de /22 alors que le réseau annonçait quatre préfixes /24. Selon la logique de validation d’origine, une route peut être invalide même si l’AS d’origine correspond, lorsque le préfixe annoncé est plus spécifique que ce que la ROA autorise. Si les opérateurs rejettent les invalides, la connectivité chute. Autrement dit, le système n’a pas échoué en ignorant la ROA.

Il a échoué parce que la ROA décrivait incorrectement le routage en production.

C’est le point central de la dépendance de mode commun. Avant RPKI, les filtres et les jugements de chaque réseau pouvaient échouer de différentes manières. Avec RPKI, de nombreux réseaux consomment le même objet signé. C’est bénéfique quand l’objet est correct: un détournement avec une mauvaise origine peut être rejeté massivement. C’est dangereux quand l’objet est erroné: des routes légitimes peuvent être rejetées massivement. La source de vérité partagée devient un mode de défaillance partagé.

La réponse n’est pas de renoncer à RPKI. Refuser de valider parce que les autorisations peuvent être fausses revient à conserver l’ancien problème de confiance du BGP. La réponse consiste à traiter les données de ROA comme un changement en production soumis à un contrôle strict. Créer la première ROA pour un détenteur de ressources, modifier maxLength, déplacer des origines ou désagréger des préfixes doit être traité comme un changement de routage à fort impact. Cela nécessite une revue, une simulation, une surveillance, un retour arrière et des alertes.

C’est particulièrement important pour les réseaux petits ou concentrés. L’empreinte Internet publique de la Corée du Nord est limitée par rapport à celle d’un fournisseur hyperscale, ce qui a rendu l’incident plus facile à analyser. Mais le même schéma peut affecter des universités, des gouvernements, des banques, des CDN, des opérateurs régionaux ou des réseaux de services d’urgence. Un petit nombre de préfixes peut tout de même transporter des services critiques. Une mauvaise ROA peut transformer un contrôle de sécurité en un incident de disponibilité.

maxLength est une décision politique, pas un champ de formulaire

Le champ facultatif maxLength est à l’origine de nombreuses erreurs de ROA qui deviennent des pannes. Une ROA couvrant un préfixe global peut n’autoriser que cette longueur de préfixe ou permettre des annonces plus spécifiques jusqu’à un maximum défini. Si le réseau annonce normalement des /24 sous un /22 mais que la ROA n’autorise que le /22, les validateurs considèrent les /24 comme invalides. Cela semble être l’explication publique de l’incident nord-coréen. Le champ n’était pas un détail cosmétique; il encodait l’autorisation ou non des routes de production.

Les opérateurs préfèrent parfois des valeurs de maxLength étroites parce que des autorisations trop larges peuvent affaiblir la protection. Si une ROA /22 autorise les /24, des annonces plus spécifiques non autorisées utilisant la même origine peuvent être plus facilement considérées comme valides. Si elle ne les autorise pas, l’ingénierie de trafic légitime ou la désagrégation peut échouer. La bonne valeur dépend de l’intention de routage réelle, des plans d’urgence et de la surveillance. Il n’existe pas de réglage automatique universellement sûr.

Cela fait de maxLength une question de gouvernance. Qui connaît l’ensemble des routes de production? Qui approuve la désagrégation? Qui maintient les ROA lorsque les préfixes se déplacent, que les annonces changent ou que des fournisseurs sont ajoutés? Qui reçoit les alertes lorsqu’une route devient invalide? Qui peut corriger l’objet en dehors des heures ouvrées? Qui vérifie qu’une ROA nouvellement publiée correspond au BGP avant que les réseaux qui s’y fient ne commencent à rejeter les invalides? Ces questions semblent procédurales, mais elles déterminent si un déploiement de sécurité protège ou interrompt la connectivité.

Les guides d’APNIC sur le nettoyage des routes invalides et les documents des RIR sur les ROA incorrectes indiquent la voie de réparation pratique: trouver la route invalide, inspecter la ROA, corriger le maxLength ou l’origine, et attendre que les caches des parties utilisatrices et la propagation BGP convergent. Cette séquence devrait être répétée. Une première ROA pour un pays, une agence ou une entreprise ne devrait pas être publiée comme s’il s’agissait d’une simple mise à jour administrative.

Le problème relève aussi du langage contractuel. Les fournisseurs de réseau géré, les titulaires de compte RIR et les équipes de routage externalisées peuvent partager la responsabilité de la création des ROA. Un client peut ne pas savoir qu’un fournisseur a modifié une ROA jusqu’à ce que des utilisateurs signalent une panne depuis des réseaux valideurs. Les contrats devraient préciser qui possède les données de ROA, qui approuve le maxLength, quel système de surveillance existe, et quelles preuves sont fournies après un changement d’état de validité.

Les incitations fail-open et fail-closed sont délicates

RPKI crée une tension d’incitation. Si les réseaux rejettent les routes invalides, ils contribuent à stopper les détournements et les erreurs d’origine. S’ils acceptent les routes invalides, ils évitent de rompre la connectivité lorsqu’un réseau légitime publie une ROA défectueuse. L’incident nord-coréen se situe au cœur de cette tension. Les routes sont devenues invalides. Les réseaux qui appliquaient strictement le rejet ont réduit la connectivité. Ceux qui étaient permissifs ont peut-être conservé des chemins disponibles, mais ont aussi maintenu une faiblesse de sécurité du routage.

Cette tension est parfois utilisée comme argument contre une validation stricte. C’est trop simpliste. Un contrôle de sécurité qui ne bloque jamais rien ne peut pas protéger contre l’attaque qu’il est censé arrêter. Mais un contrôle de sécurité qui bloque le trafic de production à cause de données obsolètes ou erronées créera une pression pour le désactiver. La réponse durable consiste à améliorer l’hygiène des données et les alertes afin que les routes légitimes invalides soient rares, rapidement détectées et rapidement corrigées.

Les recherches sur les conflits RPKI bénins et les incitations des opérateurs illustrent ce point à grande échelle. Les mauvaises configurations persistent, et les réseaux qui rejettent les invalides peuvent perdre du trafic lorsque l’état invalide est bénin. Cela crée une pression économique contre l’adoption. La solution n’est pas de normaliser les mauvaises données. C’est de rendre les mauvaises données visibles, de fournir des vérifications avant publication, d’avertir les détenteurs de ressources avant les changements d’état de route, et de créer des chemins de correction d’urgence.

La validation d’origine de route change aussi qui paie pour les erreurs. Un détenteur de ressources ou un administrateur de compte peut publier une ROA défectueuse. La perte de connectivité immédiate peut être subie par les utilisateurs et les services en aval. Les fournisseurs de transit appliquant la validation d’origine peuvent être blâmés pour avoir abandonné le trafic, alors que leur politique ne fait qu’appliquer ce que le modèle de sécurité prévoit. La partie qui a créé le mauvais objet peut ne pas recevoir tous les appels au support.

Cette répartition des coûts peut miner la confiance, à moins que les preuves n’identifient la véritable source de l’invalidité.

Un bilan de redevabilité mature devrait donc éviter la formule paresseuse « RPKI a provoqué la panne ». Plus précisément, une autorisation inexacte a rendu des routes de production légitimes invalides, et les réseaux valideurs qui rejettent les invalides ont appliqué cette déclaration. Le problème fondamental était une défaillance de gouvernance des données dans un système de sécurité partagé.

La surveillance doit couvrir le plan de contrôle et le plan d'autorisation

La surveillance traditionnelle du routage observe les annonces BGP: origines, chemins, longueurs de préfixe, retraits et propagation. RPKI exige une deuxième couche de surveillance: le plan d’autorisation. Une route peut changer de validité sans que le locuteur BGP ne modifie son annonce. Une nouvelle ROA publiée, un certificat expiré, une panne de dépôt ou un changement de maxLength peut transformer la route valide d’hier en route invalide d’aujourd’hui. Surveiller seulement BGP ne suffit plus.

C’est pourquoi les services comme les alertes de route invalide de bgp.tools sont importants. Un préfixe qui devient RPKI-invalide est un signal de production urgent. Cela peut indiquer un détournement, une erreur d’origine, une discordance de maxLength, une ROA périmée, un problème de dépôt ou un changement planifié qui a mal tourné. L’opérateur a besoin de savoir rapidement de quel cas il s’agit. Pour un réseau critique, cette alerte devrait alerter quelqu’un ayant l’autorité de modifier la ROA ou l’annonce de routage.

La discussion ultérieure de RIPE Labs sur l’analyse en temps réel du routage et la visualisation des incidents montre une direction utile pour l’avenir: combiner les vues BGP, la validité RPKI, la propagation des routes et les preuves de connectivité dans un seul flux de travail. Durant l’incident nord-coréen, des observateurs externes pouvaient voir le changement de validité et la chute de propagation. Un détenteur de ressources devrait avoir au moins ce niveau de visibilité pour ses propres préfixes avant que le public ne le remarque.

La surveillance devrait également être préalable aux changements. Avant de publier une ROA, un outil devrait comparer les ROA envisagées avec les annonces BGP actuelles et signaler toute route qui deviendrait invalide. Si le résultat est intentionnel, l’opérateur devrait planifier le changement de routage et le changement de ROA ensemble. S’il ne l’est pas, l’outil devrait empêcher la publication. C’est de la logique ordinaire de gestion des changements appliquée aux données de routage cryptographiques.

Les réseaux du secteur public nécessitent une attention particulière. Les agences dépendent souvent de sous-traitants, de services partagés ou de fournisseurs amont pour le routage. Si l’administration des ROA est confiée à une équipe et la continuité de service à une autre, une erreur de maxLength peut se retrouver à cheval sur les frontières de responsabilité. Un plan de continuité devrait nommer le titulaire du compte RPKI, le propriétaire de l’ensemble des routes, le contact d’urgence et les preuves nécessaires pour prouver la reprise.

Une réparation vérifiable vaut mieux qu'une simple assurance

Un incident de ROA défectueuse ne devrait pas se terminer par « corrigé ». Il devrait se terminer par des preuves. Quelle ROA était erronée? Quels préfixes sont devenus invalides? Quelle origine était autorisée? Quel maxLength était défini? Quand l’objet a-t-il été publié? Quels collecteurs de routes ont observé la chute de propagation? Quand la ROA a-t-elle été corrigée? Combien de temps les caches des parties utilisatrices ont-ils mis pour converger? Quels réseaux rejetaient encore la route après la correction? Ces détails permettent aux autres opérateurs d’apprendre et aux utilisateurs affectés de faire confiance à la réparation.

L’incident nord-coréen est documenté de manière externe, mais il n’est pas accompagné d’un rapport post-mortem complet tel qu’une grande entreprise ou une agence publique devrait le fournir après une panne équivalente. L’analyse externe peut reconstituer une grande partie de l’événement, mais des preuves internes expliqueraient pourquoi la ROA a été créée ainsi, si des vérifications existaient, qui l’a approuvée et ce qui a changé ensuite. Ces faits sont importants car la même classe d’erreur peut se reproduire n’importe où.

Pour les fournisseurs d’outils et les RIR, la leçon est de rendre les changements de ROA dangereux difficiles à effectuer en silence. Les interfaces devraient afficher les annonces BGP actuelles, simuler les résultats de validité, avertir des conflits de maxLength, fournir des conseils de retour arrière et encourager les alertes. L’objectif n’est pas de retirer l’autonomie de l’opérateur. C’est de rendre visible la conséquence d’un objet signé avant qu’elle n’affecte la connectivité mondiale.

Pour les réseaux qui valident RPKI, la leçon est de continuer à appliquer les règles tout en améliorant la gestion des exceptions. Les opérateurs ont besoin de visibilité sur les routes invalides qu’ils rejettent, de contacts pour les détenteurs de ressources et d’une politique pour l’évaluation d’urgence. Rejeter les invalides ne doit pas signifier ignorer la souffrance des clients; cela doit signifier utiliser des preuves pour déterminer si la route est malveillante, erronée ou obsolète, puis pousser la correction vers le bon propriétaire.

Le résultat final est que RPKI transforme la confiance du routage en données. C’est un progrès. Mais les données deviennent une infrastructure quand suffisamment de réseaux en dépendent. Une ROA défectueuse peut donc être un incident d’infrastructure, et non une erreur administrative. La gouvernance doit rattraper la puissance de l’objet signé.

Le contrôle de sécurité est devenu une dépendance de disponibilité

La validation d’origine de route est conçue pour rendre les réseaux plus sûrs en rejetant les routes qui contredisent l’autorisation signée. Cette conception même explique pourquoi une ROA défectueuse peut provoquer une panne. Le contrôle n’est pas décoratif; les réseaux valideurs l’utilisent réellement. Lorsqu’une route légitime devient invalide à cause d’une erreur de maxLength ou d’origine, les réseaux qui rejettent les invalides appliquent les données publiées par le détenteur de ressources. La panne est donc le signe que RPKI est devenu opérationnellement significatif, et non qu’il est inutile.

Cela importe pour la manière dont les organisations décrivent le risque. Si les responsables disent « RPKI nous a cassés », ils risquent de désactiver le validateur et de revenir à un modèle de confiance plus ancien et plus faible. S’ils disent « nos données d’autorisation de route ne correspondaient pas à notre routage », ils peuvent corriger le vrai problème. L’incident nord-coréen se comprend au mieux comme un désalignement entre le plan d’autorisation et le plan de routage. Les annonces BGP continuaient d’exister. L’autorisation signée a changé leur état de validité global.

Une dépendance de disponibilité créée par un contrôle de sécurité doit être gouvernée avec le même sérieux que toute autre dépendance de production. Les ancres de confiance DNSSEC, les journaux de transparence des certificats, les répondeurs OCSP, les dépôts RPKI et les flux de validateurs entrent tous dans cette catégorie. Ce sont des systèmes de sécurité, mais ils affectent le flux du trafic de production. Les traiter comme des artefacts de conformité plutôt que comme une infrastructure vivante invite les surprises opérationnelles.

Le risque de mode commun augmente avec l’adoption. Quand seuls quelques réseaux rejettent les routes RPKI-invalides, une ROA défectueuse a une portée limitée. Quand de nombreux grands réseaux rejettent les invalides, la même ROA défectueuse peut avoir un effet étendu. Ce n’est pas un argument contre l’adoption. C’est un argument en faveur de contrôles de publication rigoureux. Un mécanisme de sécurité partagé doit devenir plus discipliné à mesure qu’il rencontre du succès.

L’incident suggère également une métrique plus soigneuse pour les programmes RPKI. Le pourcentage de couverture ne suffit pas. Un réseau peut avoir une couverture ROA élevée tout en créant un risque si les valeurs de maxLength sont erronées, obsolètes ou trop larges. Une meilleure métrique combine la couverture, l’alignement de la validité, l’examen des objets obsolètes, la politique de maxLength, les alertes, la santé du dépôt et le temps de correction. L’objectif n’est pas seulement « nous avons des ROA ». L’objectif est « nos ROA décrivent avec précision les routes que nous voulons voir acceptées par l’Internet ».

Les flux de travail des RIR et des comptes font partie de la surface de contrôle

Les ROA sont souvent créées via les portails des RIR ou des outils délégués. Cela signifie que l’interface utilisateur, les permissions du compte, le flux d’approbation et le système d’avertissement font partie du contrôle de sécurité. Un validateur bien conçu ne peut pas compenser un flux de publication qui laisse passer une erreur de maxLength à fort impact sans avertissement. L’incident nord-coréen montre pourquoi la création d’une ROA devrait inclure une simulation par rapport aux annonces BGP actuelles avant publication.

Un portail peut dire à un opérateur: si vous publiez cette ROA, ces routes actuellement visibles deviendront invalides. Cet avertissement n’est pas spéculatif. Il découle directement de la logique de validation d’origine de route. Si l’opérateur a l’intention de retirer ces routes, l’avertissement aide à coordonner le calendrier. S’il n’a pas l’intention de provoquer une invalidité, l’avertissement prévient une panne. Les RIR et les fournisseurs d’outils devraient traiter cette simulation comme une mesure de sécurité, et non comme une commodité facultative.

La propriété du compte compte également. Dans de nombreuses organisations, la personne qui peut publier les ROA n’est pas la même que celle qui gère les routeurs ou la continuité de service. Un administrateur de registre peut agir dans une optique de gestion des adresses, tandis que le centre d’opérations réseau voit les annonces BGP et que l’équipe applicative voit les pannes. Si ces équipes ne sont pas connectées, le plan d’autorisation peut changer sans que le plan de routage ne s’adapte.

La solution est une cartographie de la propriété: chaque ROA devrait avoir un propriétaire de routage, un propriétaire de service, un contact d’urgence et une fréquence de revue.

Les permissions devraient être délimitées. Tous les utilisateurs d’un compte de registre ne devraient pas pouvoir apporter des modifications à fort impact sur les ROA sans examen. Les modifications qui rendraient invalides des routes actuellement observées devraient exiger une confirmation, voire un deuxième approbateur pour les ressources critiques. Des chemins de correction d’urgence devraient exister, mais la création d’urgence d’objets dangereux devrait être visible et journalisée. Encore une fois, il ne s’agit pas de bureaucratie. Il s’agit de respecter la puissance opérationnelle d’une autorisation de route signée.

Les guides des RIR sur les ROA incorrectes et le nettoyage sont précieux car ils normalisent l’idée que les états invalides proviennent souvent d’erreurs ordinaires. C’est constructif. La honte n’améliore pas les données de sécurité du routage. Des avertissements clairs, un meilleur outillage, des exemples partagés et des chemins de correction rapides le font. L’incident devrait motiver les RIR, les fournisseurs de services gérés et les détenteurs de ressources à améliorer le flux de travail autour des données de ROA, et non à reculer devant leur publication.

Les validateurs ont besoin de preuves pour la gestion des exceptions

Les réseaux qui rejettent les routes invalides ont également besoin d’une discipline de gestion des exceptions. Si un client ou un service public se plaint qu’une route est injoignable parce qu’elle est RPKI-invalide, l’opérateur valideur a besoin de savoir quelles preuves justifieraient une éventuelle dérogation temporaire. Accepter aveuglément les routes invalides sape la sécurité. Refuser d’aider à diagnostiquer une route invalide bénigne sape la confiance dans le déploiement. La voie médiane est un triage fondé sur les preuves.

La première question est de savoir si l’invalidité est causée par une discordance d’origine, une discordance de longueur de préfixe, une publication expirée ou manquante, une panne de dépôt ou un état du validateur. Chaque cause pointe vers un propriétaire différent. Une discordance d’origine peut être un détournement ou une migration périmée. Une discordance de longueur de préfixe peut être une erreur de maxLength. Une panne de dépôt peut affecter de nombreux préfixes. Un problème de cache du validateur peut être local. Un bon outillage devrait classer rapidement l’invalidité.

La deuxième question est de savoir si la perte de connectivité est étendue. Les collecteurs de routes, les looking glasses, les données RIS/RouteViews, la surveillance commerciale et les rapports des clients peuvent montrer si de nombreux réseaux ont abandonné la route ou seulement quelques-uns. Ces preuves aident à déterminer l’urgence et la communication. Une seule route invalide avec un impact limité peut être traitée par un ticket ordinaire. Un préfixe de service public critique invalidé sur de nombreux réseaux valideurs exige une escalation immédiate.

La troisième question est de savoir qui peut réparer la source de vérité. Si le détenteur de ressources a publié la mauvaise ROA, la solution propre consiste à mettre à jour la ROA, et non à demander à chaque réseau valideur de passer outre sa politique. Si l’annonce BGP est erronée, la solution propre peut être de modifier la route. Si les deux changent dans le cadre d’une migration, la solution est une séquence coordonnée. La gestion des exceptions devrait pousser la correction vers le bon propriétaire plutôt que de normaliser les contournements locaux.

C’est là que les registres publics d’incidents sont utiles. Lorsqu’un incident connu tel que la ROA défectueuse en Corée du Nord est documenté, les opérateurs peuvent l’utiliser comme matériel de formation. Ils peuvent se demander si leur centre d’opérations réseau aurait reconnu l’invalidité, si des alertes se seraient déclenchées, si les contacts du registre étaient à jour et si un retour arrière aurait pu avoir lieu en dehors des heures ouvrées. Un bon incident devient une répétition pour le suivant.

La dépendance de mode commun exige des contrôles indépendants

Une défaillance de mode commun signifie que de nombreuses parties échouent de la même manière parce qu’elles dépendent du même composant ou de la même hypothèse. Dans RPKI, l’objet d’autorisation signé peut devenir ce composant partagé. S’il est correct, de nombreux réseaux s’améliorent ensemble. S’il est erroné, de nombreux réseaux peuvent rejeter ensemble. Des contrôles indépendants sont donc essentiels avant la publication et après le changement.

Un contrôle indépendant est la comparaison avec le BGP. Comparez les ROA envisagées avec les annonces globales actuelles. Un autre est la surveillance par étapes. Publiez de manière à permettre une observation rapide des changements de validité et un retour arrière. Un autre est l’alerte externe provenant de services non gérés par le détenteur de ressources. Un tableau de bord local peut indiquer que l’objet existe; un moniteur externe peut montrer qu’une route est désormais invalide sur l’Internet public. Les deux sont utiles, et aucun ne devrait être le seul signal.

Un deuxième contrôle indépendant est l’examen humain de l’intention politique. Le réseau annonce-t-il parfois des /24 sous ce /22? Dispose-t-il d’une atténuation DDoS qui désagrège? Utilise-t-il plusieurs AS d’origine lors des basculements? Un fournisseur annonce-t-il en son nom? Une migration exige-t-elle temporairement une double origine? Une ROA peut être syntaxiquement correcte et opérationnellement erronée si elle ignore ces réalités. L’examinateur doit comprendre l’intention de routage, pas seulement la syntaxe du registre.

Un troisième contrôle porte sur l’expiration et la santé du dépôt. Une ROA peut devenir invalide ou indisponible à cause de problèmes de certificats ou de dépôt, pas seulement à cause d’erreurs de maxLength. Les validateurs ont des comportements de cache et des modes de défaillance. Les détenteurs de ressources devraient surveiller si leur dépôt RPKI est accessible et si les vues des parties utilisatrices correspondent aux objets attendus. Un objet signé que personne ne peut récupérer n’est pas un contrôle fiable.

La pensée en mode commun affecte aussi la communication. Si une ROA défectueuse invalide une route critique, de nombreux réseaux valideurs peuvent la rejeter indépendamment. Le détenteur de ressources a besoin d’un canal de statut public ou d’un contact expliquant la correction. Sinon, chaque fournisseur peut ouvrir des tickets séparés et perdre du temps à diagnostiquer la même cause. Une note publique concise peut réduire le travail en double et accélérer la convergence.

Le problème des incitations peut être résolu si les preuves s'améliorent

L’adoption de RPKI fait face à un problème d’incitation car les avantages du rejet des routes invalides sont diffus, tandis que la douleur causée par une route invalide bénigne peut être immédiate et locale. Un fournisseur qui rejette les invalides peut être blâmé par ses clients lorsque quelqu’un d’autre publie une mauvaise ROA. Un fournisseur qui accepte les invalides peut éviter l’appel au support mais contribuer à un système de routage mondial peu sûr. De meilleures preuves peuvent réduire cette tension.

Si les alertes d’invalidité identifient clairement la ROA responsable, le préfixe affecté, l’origine, le maxLength et le propriétaire probable, le fournisseur valideur peut expliquer le problème et indiquer la solution. Si les outils des RIR préviennent avant la publication, moins d’invalidations bénignes se produisent. Si les détenteurs de ressources reçoivent des alertes immédiates, ils peuvent corriger avant que de nombreux utilisateurs ne s’en aperçoivent. Si les rapports d’incidents publics normalisent le nettoyage, les organisations sont moins tentées de cacher leurs erreurs.

Chaque amélioration des preuves réduit le coût de la validation stricte.

Les achats peuvent aider. Les grands acheteurs devraient demander aux fournisseurs de transit et de cloud s’ils rejettent les routes invalides et comment ils gèrent les événements d’invalidité bénigne. Ils devraient aussi demander qui gère leurs propres ROA s’ils possèdent de l’espace d’adressage. Un acheteur qui fait pression sur les fournisseurs pour qu’ils acceptent les routes invalides à chaque erreur sape la sécurité du routage. Un acheteur qui maintient des ROA propres et attend une validation stricte améliore l’écosystème.

Les régulateurs et les réseaux gouvernementaux devraient adopter la même position. Les ressources d’adressage du secteur public devraient avoir une propriété des ROA, une politique de maxLength, une surveillance des routes et une correction d’urgence. Les achats gouvernementaux peuvent exiger des fournisseurs une validation RPKI tout en exigeant des processus de support pour le diagnostic des routes invalides. La sécurité et la disponibilité doivent être gérées ensemble plutôt qu’être opposées sous la pression.

L’incident de la ROA défectueuse en Corée du Nord est un rappel compact que la sécurité du routage ne consiste plus seulement à empêcher les attaquants d’entrer. Elle consiste aussi à maintenir l’exactitude des données d’autorité. La déclaration signée a du pouvoir. Ce pouvoir mérite un contrôle des modifications, une surveillance et une redevabilité.

La décision du lecteur pour la gouvernance des ROA

Le lecteur ne devrait pas traiter le cas de la ROA défectueuse comme une raison de se méfier de RPKI. La meilleure décision est de traiter la gouvernance des ROA comme une gouvernance de production. Si une organisation possède de l’espace d’adressage, elle a besoin d’un propriétaire pour les données de ROA, d’une cartographie des annonces normales et d’urgence, d’une politique de maxLength, d’une simulation avant publication, d’alertes d’invalidité, d’un chemin de retour arrière et d’un contact capable de corriger les objets rapidement. Sans ces contrôles, l’organisation a une politique de route signée, mais pas une politique de route gérée.

Pour les détenteurs de ressources, la question immédiate est de savoir si chaque route visible est couverte par une ROA intentionnelle et exacte. Cela inclut l’AS d’origine, la longueur du préfixe et le maxLength. Cela inclut également les cas exceptionnels: fournisseurs DDoS, transit de secours, anycast, ingénierie de trafic, fenêtres de migration et désagrégation d’urgence. Si le plan de routage et le plan de ROA vivent dans des outils différents avec des propriétaires différents, le risque est déjà présent.

Pour les réseaux valideurs, la décision est de rejeter les invalides tout en construisant un diagnostic humain. Une validation stricte améliore l’Internet, mais les clients ont besoin de preuves claires lorsqu’une route invalide est bénigne. Les opérateurs devraient être capables d’expliquer l’invalidité, de pointer l’objet responsable et d’aider le détenteur de ressources à corriger la source de vérité. Cela protège la sécurité sans transformer chaque erreur en pression pour désactiver la validation.

Pour les fournisseurs d’outils et les RIR, la décision est de rendre les changements de ROA dangereux difficiles à publier silencieusement. Montrez les annonces actuelles. Simulez la validité. Avertissez avant d’invalider des routes vivantes. Conservez des pistes d’audit. Encouragez les alertes. Fournissez des conseils de correction d’urgence. Une bonne interface peut empêcher une panne de routage avant que l’objet cryptographique ne quitte le portail.

L’incident nord-coréen est compact parce que l’empreinte publique était assez petite pour être analysée. La leçon est grande parce que la dépendance est mondiale. Avec la généralisation de RPKI, la qualité des données signées devient aussi importante que la décision de valider. L’Internet doit continuer à progresser vers le rejet des routes invalides, mais cet avenir exige un plus grand soin des données d’autorité qui rendent les routes valides.

La classe de défaillance dépasse un seul pays

L’exemple nord-coréen est utile parce qu’il est visible, mais la classe de défaillance n’est pas propre à un pays. Tout détenteur de ressources qui annonce des routes plus spécifiques sous une allocation globale peut créer le même problème avec un maxLength étroit. Toute organisation qui déplace des préfixes entre des AS d’origine peut créer une discordance d’origine. Tout fournisseur de réseau géré qui modifie des ROA sans se coordonner avec le centre d’opérations réseau peut invalider le trafic de production. Le schéma commun est une déclaration signée qui ne correspond plus à la réalité opérationnelle.

Cela signifie que chaque programme RPKI devrait inclure un travail périodique de réconciliation. Prenez les routes visibles dans le BGP mondial. Prenez les ROA actuellement publiées. Comparez l’origine et le maxLength. Signalez chaque route invalide et chaque route non trouvée qui devrait être couverte. Examinez chaque autorisation trop large qui permet des routes plus spécifiques que le réseau n’a pas l’intention d’annoncer. Cette réconciliation n’est pas une tâche ponctuelle d’intégration. Le routage change. Les fournisseurs changent. L’atténuation DDoS change.

Les fusions, les cessions et les migrations vers le cloud modifient les plans d’origine. Le plan d’autorisation doit suivre le plan de routage.

Le meilleur résultat à long terme est culturel. Les opérateurs devraient devenir aussi mal à l’aise avec les ROA obsolètes qu’avec les enregistrements DNS périmés pour les services critiques ou les certificats expirés sur les points de terminaison publics. L’objet signé est petit, mais la dépendance peut être grande. Le traiter comme une infrastructure vivante fait la différence entre une sécurité du routage qui gagne la confiance et une sécurité du routage qui est désactivée après la première erreur douloureuse.

Cette culture a aussi besoin d’une habitude de revue des changements. Une modification de ROA ne devrait pas être traitée comme une simple mise à jour de registre alors qu’elle peut modifier la connectivité sous une validation stricte. L’examinateur devrait demander quelle route est vivante actuellement, quelle route sera vivante après un changement de fournisseur, si les routes plus spécifiques sont autorisées intentionnellement, si un fournisseur DDoS ou une origine de secours a besoin d’une autorisation temporaire, et comment l’organisation saura si l’objet publié a rendu le trafic invalide.

Le plan de retour arrière devrait être aussi explicite que le plan de changement. Si la réponse est « attendre que quelqu’un se plaigne », les données signées ne sont pas sous contrôle de production. Les fournisseurs de cloud, les registres, les opérateurs de serveurs de routes et les grandes entreprises ont tous intérêt à normaliser cette habitude, car la validation stricte fonctionne mieux lorsque les données d’autorité sont d’une exactitude ennuyeuse.

La même habitude devrait couvrir les transferts de propriété. Les ressources d’adressage se déplacent via des acquisitions, des mises à jour de registre, des changements de fournisseur, des migrations vers le cloud et des conceptions de reprise après sinistre. Une ROA qui était correcte dans un modèle d’exploitation peut devenir nuisible dans le suivant. La gouvernance nécessite donc une liste de contrôle pour le transfert: qui possède les objets, qui reçoit les alertes, qui approuve le maxLength, qui peut révoquer une autorisation obsolète, et qui vérifie la visibilité globale des routes après le changement.

Le dossier nord-coréen est utile parce qu’il rend la défaillance assez petite pour être comprise. La prochaine défaillance pourrait concerner une banque, une agence publique, un client de CDN ou un service d’urgence dont le plan de routage change en période de stress. L’autorité de route signée devrait être prête pour ce stress avant que la validation ne l’applique.

Typographie

En résumé

La norme de redevabilité est un contrôle pratique associé à des preuves publiques. Le meilleur bilan ne prétend pas que chaque acteur contrôlait tous les résultats. Il identifie qui aurait pu prévenir la défaillance, qui aurait pu la détecter, qui aurait pu en limiter le rayon d’action, qui aurait pu avertir les parties affectées, qui aurait pu réparer la relation de confiance et quelles preuves démontrent que la réparation a atteint les systèmes et les personnes qui en dépendaient.