La confiance RPKI commune du NRO et la concentration sous cinq logos

Résumé

• RPKI n'est pas simplement une fonctionnalité de sécurité dans cinq portails membres. C'est un système de confiance dans lequel l'autorité de certification, la publication du dépôt, la gestion des ROA, la configuration des validateurs, la distribution des TAL, la dépendance aux services hébergés, la disponibilité des services délégués et la gouvernance des registres peuvent tous devenir des facteurs de dépendance pour le routage.
• Le programme RPKI du NRO vise ouvertement un service RPKI plus cohérent, uniformément sécurisé et fiable dans l'ensemble des cinq RIR, tandis que ses objectifs 2025 incluent la transparence, la robustesse, la sécurité et une préoccupation concernant la configuration actuelle des ancres de confiance. La coordination est utile, mais elle signifie également que la résilience doit être mesurée par les domaines de défaillance partagés plutôt que par le nombre de marques de RIR.
• Une norme de résilience RPKI sérieuse devrait se demander quelles défaillances sont indépendantes, lesquelles sont communes, lesquelles peuvent être déléguées hors d'un registre, lesquelles nécessitent un soutien d'opérateur d'urgence, et lesquelles exigent un examen public avant que les changements d'état des certificats n'affectent l'acceptation du routage.

Le nombre de logos n'est pas une mesure de résilience

La carte publique de RPKI semble rassurante à première vue. Il existe cinq registres Internet régionaux. Chacun a sa propre région, son site public, son portail membre, ses pages de certification de ressources et son matériel d'ancrage de confiance. Le dépôt de contenu RPKI du NRO renvoie vers des portails RPKI distincts, des pages de certification de ressources, des informations sur les Trust Anchor Locator et des déclarations de pratiques de certification pour AFRINIC, APNIC, ARIN, LACNIC et RIPE NCC. La surface semble distribuée parce qu'elle est visiblement plurielle.

L'apparence plurielle n'est pas la même chose que la résilience indépendante. Cinq marques publiques peuvent partager une même hypothèse de gouvernance. Cinq ancres de confiance peuvent converger à travers une direction de programme commune. Cinq portails peuvent encore dépendre de pratiques de contrôle des comptes similaires, d'incitations de services hébergés similaires, d'interprétations juridiques similaires de l'autorité du titulaire et d'attentes de continuité d'urgence similaires. Cinq dépôts peuvent encore être consommés par le même écosystème de validateurs et acheminés vers les mêmes décisions de filtrage en aval.

Une défaillance qui semble régionale au point de signature peut devenir mondiale au point de la partie qui se fie si les opérateurs ingèrent le résultat via des outils communs et des politiques de routage communes.

C'est le problème central sous la confiance RPKI commune. RPKI a été conçu pour rendre l'autorisation d'origine de route plus vérifiable. Il lie les ressources numériques à un certificat cryptographique et permet à un titulaire légitime d'autoriser un système autonome à originer un préfixe. C'est une amélioration majeure par rapport à la confiance aveugle dans les annonces de route et les objets de route obsolètes. Mais une fois que l'acceptation du routage commence à reposer sur l'état du certificat, la gouvernance de cet état de certificat devient une partie de la surface de contrôle d'Internet.

La question n'est plus simplement de savoir si chaque RIR a un logo et un portail. La question est de savoir quelles défaillances peuvent supprimer, périmer, mal déclarer ou retarder les preuves que les routeurs et les filtres de route consomment.

Leprogramme RPKI du NROrend explicite la couche de coordination. Il indique que le NRO a accepté de travailler à un service RPKI robuste, coordonné et sécurisé, dans le but de fournir un service plus cohérent, uniformément sécurisé, résilient et fiable, et de supprimer les obstacles rencontrés par les opérateurs qui créent des objets RPKI via plusieurs RIR. C'est un objectif judicieux. Les opérateurs ayant des ressources dans plusieurs régions ne devraient pas avoir à apprendre cinq cultures de sécurité incompatibles. Une couche mondiale de sécurité de routage bénéficie de la cohérence.

La cohérence modifie cependant la question de la résilience. Lorsqu'un service est intentionnellement rendu plus uniforme, un observateur doit se demander si l'uniformité réduit l'erreur ou la concentre. Une base commune peut éliminer les pratiques locales faibles. Elle peut aussi propager une hypothèse erronée dans toutes les régions. Un ensemble de documentation commune peut faciliter l'adoption. Il peut également masquer des différences régionales qui comptent pour le service délégué, l'accès d'urgence, la récupération de compte, la révocation de ROA et l'autorité légale. Un programme commun peut renforcer la sécurité.

Il peut aussi faire en sorte que les choix de politique semblent techniques parce qu'ils arrivent dans un langage opérationnel.

La bonne métrique est donc le domaine de défaillance, pas le nombre de logos. Un domaine de défaillance est l'ensemble des composants, autorités, hypothèses, personnes, règles juridiques, dépendances logicielles, points de publication et chemins de révision qui peuvent échouer ensemble. Si cinq institutions partagent le même domaine pour un risque particulier, les compter comme cinq unités de résilience est trompeur. Si une institution a deux domaines véritablement séparés pour un risque, la compter comme une seule est également trompeur. L'audit doit suivre la décision et la dépendance, pas l'emblème sur la page.

RPKI transforme l'autorité de registre en preuve de routage

RPKI commence comme une architecture technique, mais elle ne reste pas en dehors de la gouvernance.RFC 6480décrit une infrastructure pour soutenir une sécurité de routage améliorée. Sa base est une infrastructure de clé publique de ressources représentant la hiérarchie d'allocation des adresses IP et des numéros AS, avec des dépôts distribués pour les objets signés utilisés dans la sécurité du routage. Il décrit comment un titulaire légitime peut autoriser un ou plusieurs AS à originer des routes pour un espace d'adressage et comment ces autorisations vérifiables peuvent soutenir les filtres de route.

Cette architecture suit l'allocation des ressources. L'IANA se trouve à la racine de la hiérarchie d'allocation. Les RIR gèrent l'allocation des adresses et des numéros AS dans des régions définies. Les certificats de ressources attestent des avoirs; les ROA fournissent l'autorisation d'origine. Le certificat n'est pas un artefact décoratif. C'est une déclaration qui peut affecter si une route est considérée comme valide, invalide ou non trouvée par les opérateurs utilisant la validation d'origine RPKI. Un enregistrement de registre devient ainsi une preuve de routage.

La conséquence en matière de gouvernance est directe. Lorsqu'un registre contrôle le service RPKI hébergé pour un titulaire, il ne se contente pas de maintenir une fonctionnalité de site web. Il exploite une partie de la preuve d'origine de route du titulaire. Lorsqu'un registre modifie l'état du certificat après un transfert, une compromission de compte, une ordonnance judiciaire, un non-paiement, un examen de sanctions, le décès du titulaire, une fusion d'entreprise, un litige ou une fraude présumée, ce changement peut passer du bureau du registre au cache du validateur, puis au filtre de route.

La distance entre la gouvernance et le routage se réduit.

Cela ne signifie pas que les RIR devraient éviter l'autorité RPKI. La structure d'allocation existante rendait naturelle l'implication des RIR. La RFC 6480 indique que la structure de l'ICP correspond à l'allocation de ressources existante, faisant de la gestion une extension naturelle des organisations déjà responsables de l'allocation de ressources. Elle indique également que les certificats de ressources ne vérifient pas l'identité personnelle ou organisationnelle au sens habituel de l'ICP publique; ils attestent des avoirs en ressources.

Cette limite réduit une certaine responsabilité tout en soulevant une autre question: quel fait de registre le certificat est-il compétent pour exprimer?

La réponse devrait être étroite. Un certificat de ressources devrait exprimer l'autorité de détention de ressources et l'état de délégation associé, et non le point de vue d'un registre sur chaque problème commercial, politique ou moral entourant le titulaire. Un ROA devrait exprimer l'autorisation d'origine de route dans un état de ressources reconnu, et non régler chaque litige sous-jacent. Un dépôt RPKI devrait publier des preuves cryptographiques actuelles, et non devenir un outil disciplinaire opaque. Plus les opérateurs s'appuient sur le résultat, plus il devient important de garder l'autorité d'entrée précise.

L'analyse des domaines de défaillance commence ici. Une défaillance de gouvernance de registre peut devenir une défaillance RPKI si le registre peut révoquer de manière incorrecte, ne pas publier, refuser de mettre à jour, retarder le transfert, mal gérer la publication déléguée, perdre le contrôle du compte, mal interpréter l'autorité du titulaire ou appliquer une hypothèse de politique commune trop largement. Une défaillance de validateur peut devenir une défaillance de routage même si le registre est correct. Une panne de dépôt peut devenir une défaillance de données périmées.

Un renouvellement d'ancre de confiance peut devenir une défaillance de configuration mondiale. Un litige juridique peut devenir un retard d'état de certificat.

Aucun de ces risques n'est résolu en disant qu'il y a cinq RIR. Le même opérateur peut dépendre des cinq. Le même validateur peut aller chercher les cinq. Le même réseau majeur peut appliquer des filtres de route basés sur les cinq. Le même programme du NRO peut pousser les cinq vers une documentation et des fonctionnalités communes. Le système est distribué à certains égards et concentré à d'autres. La carte de résilience doit montrer les deux.

Le TAL est un petit fichier avec une grande signification institutionnelle

Le Trust Anchor Locator est l'un des exemples les plus clairs de concentration cachée.RFC 6490explique qu'une ancre de confiance dans RPKI est représentée par un certificat d'autorité de certification X.509 auto-signé, et que le TAL spécifie les données utilisées pour récupérer et vérifier l'authenticité d'une ancre de confiance. Le TAL contient une URI et le matériel de clé publique utilisé par le logiciel de la partie qui se fie. L'objectif est d'éviter de redistribuer l'ancre de confiance elle-même chaque fois que l'ensemble des ressources de numéros Internet associées à l'ancre de confiance change, tant que la clé publique et l'emplacement restent stables.

Cette description semble technique, mais le TAL est aussi un objet de dépendance institutionnelle. Une partie qui se fie et qui configure un TAL décide à quelle autorité faire confiance pour les certificats de ressources d'une région. Si l'emplacement du TAL change, si la clé change, si le dépôt est indisponible, si le certificat de l'AC est mal géré, si un renouvellement est mal communiqué, ou si une crise soulève des questions sur qui peut autoriser les changements, le problème n'est pas seulement cryptographique. C'est une question de gouvernance de la confiance.

Le dépôt de contenu RPKI du NRO rend cette dépendance visible en listant les informations TAL pour chaque RIR. Il renvoie également vers le matériel CPS et les ressources d'assistance. C'est une transparence utile. Cela permet aux opérateurs de trouver les éléments dont ils ont besoin. Mais cela ne répond pas aux questions plus profondes de résilience. Qui décide quand un TAL doit changer? Quel préavis est nécessaire? Que se passe-t-il si un opérateur d'urgence doit maintenir le service? Une ordonnance d'un tribunal local peut-elle affecter le matériel d'ancre de confiance? Comment les revendications contradictoires sont-elles traitées?

Que se passe-t-il si un registre est opérationnel mais affaibli dans sa gouvernance? Comment les validateurs traitent-ils l'ancien et le nouveau matériel pendant la transition?

Les certificats d'ancrage de confiance à courte durée de vie, les méthodes de publication en dépôt, la prise en charge des services délégués et la conception des services hébergés affectent tous ce tableau. Lafeuille de route du NRO pour les services RPKI de baseliste le service hébergé comme disponible auprès des cinq RIR, le service délégué de APNIC, ARIN, LACNIC et RIPE NCC avec tous les RIR visés pour la fin du premier trimestre 2026, les objectifs de gestion d'API, les objets ROA via interface et API, et les certificats TA à courte durée de vie proposés par APNIC, ARIN et LACNIC avec un objectif pour tous d'ici la fin 2025. Ces écarts et objectifs de fonctionnalités sont des faits de gouvernance, pas seulement des notes de produit.

Si chaque RIR propose à terme le même ensemble de fonctionnalités de base, certains obstacles à l'adoption tombent. Un titulaire multi-région peut concevoir de meilleurs contrôles internes. Les attentes des parties qui se fient deviennent plus prévisibles. La documentation peut s'améliorer. Mais des dates cibles communes ne créent pas automatiquement des domaines de défaillance indépendants. Si la même hypothèse sur le renouvellement des ancres de confiance est intégrée partout, une erreur peut se propager. Si toutes les régions adoptent un service hébergé par défaut similaire, l'autonomie déléguée peut rester sous-utilisée.

Si toutes les régions alignent la terminologie mais pas les droits de recours, les opérateurs peuvent mieux comprendre un refus sans pouvoir le contester.

Le TAL est donc un bon test de résilience. Comptez le nombre de TAL configurés, puis demandez-vous combien de chemins de gouvernance indépendants les protègent. Comptez le nombre de dépôts, puis demandez-vous si les parties qui se fient traitent les défaillances différemment. Comptez le nombre de marques de RIR, puis demandez-vous si un programme commun du NRO ou une décision de mise en œuvre commune pourrait changer toutes les attentes des opérateurs en une seule fois. Comptez le nombre de certificats, puis demandez-vous quel acteur juridique peut autoriser la continuité d'urgence.

La réponse variera selon le risque. La disponibilité du dépôt peut être plus distribuée que l'interprétation juridique. Les contrôles multi-facteurs du portail peuvent être spécifiques à la région. Le comportement de mise en œuvre du validateur peut être mondial. La communication sur les ancres de confiance peut être partiellement coordonnée. La continuité d'urgence peut être sous-définie. L'important est de cartographier explicitement ces domaines, et non de supposer que des logos pluriels égalent une résilience plurielle.

La commodité du service hébergé n'est pas la même chose que le contrôle de l'opérateur

La page de référence du NRO sur les services RPKI indique que le service hébergé est disponible dans les cinq RIR. Le service hébergé est précieux car de nombreux détenteurs de ressources manquent de personnel, de temps ou d'ingénierie de sécurité pour exécuter le RPKI délégué. Un petit réseau peut créer des ROA via un portail de registre familier. Un opérateur plus important peut gérer la preuve d'origine de route sans exploiter sa propre AC.

Le service hébergé accélère l'adoption, et l'adoption est importante car RPKI n'améliore la sécurité du routage que lorsque suffisamment de détenteurs publient des objets corrects et que suffisamment de réseaux les valident.

Le coût de gouvernance est la dépendance. En mode hébergé, le portail du registre, l'authentification du compte, le modèle d'autorisation, la journalisation des modifications, le support, le processus du personnel, la gestion des pannes et l'interprétation juridique se trouvent entre le titulaire et sa preuve d'origine de route. Si le compte du titulaire est compromis, le processus du registre importe. Si un transfert est clôturé, le processus de transfert importe. Si une correction urgente de maxLength est nécessaire, le service d'assistance importe.

Si le filtrage des sanctions ou un examen juridique bloque un compte, l'état du certificat peut devenir des dégâts collatéraux. Si une crise de registre perturbe l'accès du personnel ou les systèmes de paiement, le service RPKI hébergé fait partie du problème de continuité de service.

Le RPKI délégué modifie l'équilibre. Il permet au titulaire d'exécuter sa propre AC ou son propre arrangement de publication sous un certificat émis par le registre. Il peut réduire la dépendance au portail et donner aux opérateurs avertis un contrôle plus direct. Mais le service délégué n'est pas une échappatoire au registre. Le certificat parent, l'ancre de confiance, la reconnaissance des ressources, les mises à jour de transfert et les limites de politique comptent toujours. La délégation déplace certains domaines de défaillance opérationnels loin du registre, tout en en laissant d'autres avec lui.

L'aperçu des services RPKI du NRO montre que la disponibilité du service délégué et les fonctionnalités de publication hybride ne sont pas uniformes. Le service hébergé est universel. Le service délégué est répertorié pour quatre RIR dans l'aperçu de décembre 2025, AFRINIC étant indiqué comme ne le proposant pas à ce moment-là. Le service de publication hybride varie également. Le support API, l'historique des transactions, les suggestions de collecteurs de routes et l'alignement entre les sources RPKI et IRR varient.

Ces différences sont importantes car elles indiquent aux opérateurs quelles défaillances sont locales, lesquelles sont évitables et lesquelles sont inhérentes à la structure de confiance parente.

Un audit de résilience devrait donc poser trois questions pour chaque titulaire de ressources. Premièrement, que peut faire le titulaire sans le personnel du registre si quelque chose se casse aujourd'hui? Deuxièmement, que peut faire le titulaire sans le portail du registre si les identifiants, le statut de paiement, l'examen des sanctions, une procédure judiciaire locale ou les files d'attente de support deviennent problématiques? Troisièmement, qu'est-ce qui ne peut pas être fait sans l'action du registre parent, quelle que soit la compétence du titulaire?

Pour un petit utilisateur hébergé, la réponse peut être: presque tout dépend de l'interface du registre et du modèle de support. Pour un opérateur délégué, la réponse peut être: la publication de routine des ROA est indépendante, mais l'état du certificat parent, les changements de ressources, le transfert de transfert et les événements d'ancre de confiance restent dépendants du registre. Pour un titulaire multi-région, la réponse peut différer selon les RIR. Pour un fournisseur cloud ou de transit en aval, la réponse peut être invisible à moins que le titulaire ne la documente.

C'est pourquoi « cinq RIR proposent RPKI » ne suffit pas. Un système peut être largement disponible et rester concentré dans les droits de décision. La question n'est pas seulement de savoir si une fonctionnalité existe. C'est qui peut l'exercer en période de stress, qui peut l'annuler, qui peut la récupérer, qui peut l'auditer, et qui supporte le coût lorsque le registre et l'opérateur ne sont pas d'accord.

La coordination améliore la cohérence et concentre les hypothèses

Le programme RPKI du NRO est franc quant à ses objectifs. Pour 2025, il indique que le programme s'est concentré sur la transparence, la robustesse et la sécurité du système RPKI, y compris une solution de consultation avec la communauté technique pour répondre aux préoccupations concernant la configuration actuelle des ancres de confiance.

Il vise également à accroître la cohérence de l'expérience utilisateur grâce à une documentation consolidée, une terminologie standardisée, des meilleures pratiques recommandées, une analyse des écarts des interfaces RPKI entre les RIR et une feuille de route pour un ensemble convenu de fonctionnalités de base.

C'est exactement ce qu'un organisme de coordination mature devrait faire. RPKI est trop important pour être laissé à cinq cultures de produits sans lien. Les opérateurs ont besoin de clarté. Les validateurs ont besoin d'un comportement prévisible. Les titulaires multi-régions ont besoin de concepts similaires. Les chercheurs en sécurité ont besoin d'artefacts comparables. La confusion augmente les erreurs de configuration, et une mauvaise configuration peut rendre des routes légitimes invalides. La coordination peut réduire ce risque.

Le risque de concentration réside dans le mot « convenu ». Un ensemble convenu de fonctionnalités de base peut renforcer la région la plus faible. Il peut également faire hériter à chaque région le même angle mort. Si la base convenue dit peu de choses sur les droits de recours après la suspension du certificat, toutes les régions peuvent considérer ce silence comme normal. Si la base convenue favorise la commodité de l'hébergement au détriment de l'autonomie déléguée, l'adoption peut augmenter tandis que le contrôle de l'opérateur reste faible.

Si la base convenue améliore la transparence mais pas l'autorité d'urgence, une crise peut être bien documentée tout en restant non résolue. Si la base convenue normalise la terminologie sans normaliser le signalement public des incidents, les opérateurs peuvent parler des pannes de manière plus cohérente tout en manquant de meilleures preuves.

RPKI est particulièrement sensible aux hypothèses communes car les parties qui se fient ont tendance à automatiser. Une erreur juridique ou de gouvernance n'a pas besoin de convaincre chaque opérateur humain individuellement une fois qu'elle est exprimée comme état de certificat et consommée par les validateurs. Le résultat d'origine de route peut voyager à travers les caches, les routeurs et les filtres. Cette automatisation est l'objectif de RPKI; c'est aussi pourquoi la gouvernance doit être précise.

La bonne réponse n'est pas de garder chaque RIR différent. La différence arbitraire est aussi un échec. Si une région manque de service délégué, d'accès API, d'historique des transactions ou de support fiable, les opérateurs en souffrent. Si une région utilise une terminologie confuse, l'adoption en souffre. Si une région a des contrôles de sécurité faibles, l'ensemble du système est moins crédible. La bonne réponse est de classer quelles différences sont nuisibles et quelles différences apportent de la résilience.

Les différences nuisibles incluent une gestion de ROA peu claire, une authentification faible, un historique de transactions manquant, une mauvaise disponibilité du dépôt, un support instable, des conseils incohérents sur maxLength, des instructions TAL floues et une mauvaise visibilité entre le mode hébergé et le mode délégué.

Les différences de résilience incluent un examen indépendant des incidents, des garanties juridiques spécifiques à la région, des arrangements de publication alternatifs, la capacité d'exécuter des services délégués, des équipes opérationnelles séparées, des piles logicielles diverses, des voies de recours locales, des mesures de service public et des plans de transfert publiés.

Le NRO peut coordonner la première catégorie sans effacer la seconde. Il peut exiger que chaque RIR prenne en charge une base de référence sécurisée tout en permettant différentes conceptions de responsabilisation. Il peut aligner la terminologie tout en préservant les divulgations juridiques locales. Il peut normaliser les étiquettes de gravité des incidents tout en exigeant que chaque RIR publie sa propre déclaration de cause racine. Il peut recommander le service délégué sans forcer chaque opérateur à une architecture identique.

Il peut consulter sur la configuration des ancres de confiance tout en publiant une analyse des domaines de défaillance pour les options.

L'expression « système RPKI mondial unique » doit donc être maniée avec précaution. La couche de sécurité du routage est mondiale dans son effet. La hiérarchie d'allocation est mondiale dans sa structure. L'écosystème des parties qui s'appuient est mondial dans sa consommation. Mais la résilience s'améliore lorsque le système contient une diversité contrôlée: des chemins de publication indépendants, un examen indépendant, des raisons régionales indépendantes et la capacité de l'opérateur à déléguer loin d'une dépendance hébergée inutile. Un système mondial unique ne devrait pas signifier une hypothèse de gouvernance unique et incontestée.

Domaines de défaillance qui devraient être mesurés

Le premier domaine de défaillance est l'autorité. Qui a le droit de créer, révoquer, modifier ou refuser des objets RPKI? La réponse peut impliquer le titulaire des ressources, l'utilisateur du portail, le représentant légal, le personnel du registre, l'organisation parrainante, le NIR, la contrepartie de transfert, le fonctionnaire nommé par le tribunal ou l'opérateur d'urgence. Si ces rôles sont confus, le risque n'est pas technique. C'est une ambiguïté d'autorité exprimée par l'état technique.

Le deuxième domaine est le contrôle des comptes. Le RPKI hébergé dépend des portails. Les portails dépendent des identifiants, de l'authentification multi-facteurs, de l'attribution des rôles, du support du personnel et de la récupération. L'aperçu des services du NRO rapporte des fonctionnalités d'authentification multi-facteurs sur les portails des RIR, avec différentes méthodes et des seuils obligatoires. Un audit de sécurité ne devrait pas simplement demander si l'authentification multi-facteurs existe.

Il devrait demander qui peut ajouter un utilisateur, réinitialiser un facteur, approuver un rôle, récupérer d'une compromission et voir la piste des transactions.

Le troisième domaine est la publication. RPKI utilise des dépôts pour les certificats, les ROA, les manifestes et les objets associés. Une défaillance du dépôt, un contenu périmé, des problèmes de manifeste, des problèmes RRDP ou rsync, et le comportement de récupération du validateur peuvent tous affecter les informations d'origine de route. Le domaine ne se limite pas au centre de données du RIR. Il inclut la distribution de contenu, le support des protocoles, la surveillance, les avis d'incident et le comportement de cache des parties qui s'appuient.

Le quatrième domaine est la configuration des ancres de confiance. Les TAL doivent être distribués de manière sécurisée, configurés par les parties qui s'appuient et maintenus à travers les changements de clé ou d'emplacement. Une préoccupation relative à une ancre de confiance peut affecter tous les opérateurs qui dépendent d'un TAL donné. Si plusieurs RIR coordonnent les changements d'ancres de confiance via le même programme et le même calendrier, la communication s'améliore, mais un risque de chronométrage commun apparaît. S'ils ne coordonnent pas du tout, les parties qui s'appuient sont confrontées à la confusion.

La conception de la résilience doit équilibrer ces risques.

Le cinquième domaine est le mode de service. Les arrangements hébergés et délégués imposent des responsabilités différentes au registre et au titulaire. Un audit mature devrait indiquer le pourcentage de ressources en service hébergé, en service délégué et en publication hybride lorsque disponible, et non simplement si l'option existe. Une fonctionnalité inutilisée par la plupart des titulaires n'est pas une couche de résilience efficace.

Le sixième domaine est l'intervention juridique. Les ordonnances judiciaires, les listes de sanctions, l'insolvabilité, la mise sous séquestre, les fusions, les réclamations des créanciers, les enquêtes pour fraude et les demandes gouvernementales peuvent toutes créer une pression sur l'état du certificat. Le registre doit savoir quels faits il peut vérifier et lesquels nécessitent un jugement externe.

Il a également besoin de recours réversibles: des gels temporaires, des annotations, des gels étroits, des audits indépendants, des suspensions d'urgence et des mises à jour échelonnées plutôt qu'une révocation irréversible lorsque les preuves sont incomplètes.

Le septième domaine est la direction commune du programme. Si le programme du NRO définit une feuille de route des fonctionnalités, une terminologie, une meilleure pratique et une posture de réponse, ce programme devient un domaine de défaillance pour les hypothèses. Il devrait donc publier non seulement les résultats, mais aussi les alternatives envisagées, les options rejetées, les compromis de risque et les points de vue techniques divergents lorsqu'ils existent.

Le huitième domaine est le comportement des validateurs. Les RIR publient du contenu signé, mais les logiciels des parties qui s'appuient et les filtres des opérateurs décident comment ce contenu affecte le routage. Si les principaux validateurs interprètent différemment les cas limites, le même état de dépôt peut produire des résultats opérationnels différents. Si les principaux réseaux convergent vers une seule implémentation, la diversité logicielle diminue. Si les serveurs de route appliquent le filtrage RPKI de manière localisée, l'effet diffère du filtrage de niveau 1.

Ces domaines en aval se trouvent au-delà des logos des RIR mais façonnent la résilience réelle.

Le neuvième domaine est la continuité d'urgence. Le projet de document de gouvernance des RIR 2025 définit les concepts de continuité d'urgence et d'opérateur d'urgence, et le Fonds de stabilité du NRO décrit le soutien mutuel en cas de perturbations graves. La continuité RPKI devrait faire partie de tout plan d'urgence. Le public devrait savoir ce qui continue, ce qui est gelé, qui peut signer, qui peut publier, comment les anciens objets sont traités et comment l'autorité revient à la normale.

Le dernier domaine est la preuve publique. Les opérateurs ont besoin de preuves, pas de réconfort. Les mesures de disponibilité des services, la santé des dépôts, les rapports d'incidents, les avis de changement de TAL, l'historique des transactions, les temps de réponse du support, l'adoption du service délégué, les résultats des recours et les exercices d'urgence devraient être suffisamment visibles pour permettre au marché d'évaluer la résilience. Sans preuves, cinq logos deviennent du théâtre.

Ce qui se passe lorsque la gouvernance devient un état de certificat

Prenons un transfert. Le vendeur a des ROA. L'acheteur a besoin d'une autorisation d'origine de route. Le registre doit reconnaître le transfert, mettre à jour les enregistrements de ressources, préserver la continuité et éviter que les anciens ROA ne persistent trop longtemps. Si le transfert est ordinaire, le processus est administratif. Si le transfert est contesté, financé, transfrontalier, affecté par un tribunal, filtré par les sanctions ou retardé par la documentation, l'état RPKI devient une surface à risque. L'ancienne autorisation peut survivre trop longtemps. La nouvelle autorisation peut arriver trop tard.

Une erreur de maxLength peut rendre invalides les routes plus spécifiques légitimes. Un retard de support peut créer une panne chez le client.

Prenons maintenant une succession d'entreprise. Un titulaire historique change de nom, fusionne ou se dissout dans une filiale. Le registre doit identifier qui peut agir. Un utilisateur du portail peut encore avoir des identifiants mais pas d'autorité. Un directeur peut avoir l'autorité mais pas d'accès au portail. Une banque peut exiger des preuves. Un tribunal peut émettre une ordonnance. Le service RPKI hébergé peut devenir l'endroit où ces rôles entrent en collision. L'état du certificat ne devrait pas changer tant que l'autorité n'est pas claire, mais un retard indéfini peut nuire au routage.

Le remède n'est pas un large pouvoir discrétionnaire. C'est une échelle de preuves avec une continuité temporaire.

Prenons une crise de registre. Si un registre ne peut pas fonctionner normalement, des questions RPKI se posent immédiatement. Les certificats existants peuvent-ils rester valides? Qui surveille la fraîcheur du dépôt? Qui répond aux demandes de correction urgentes de ROA? Qui peut suspendre les changements dangereux sans geler le service ordinaire? Qui communique avec les parties qui s'appuient? Un opérateur d'urgence a-t-il l'autorité de signature, l'autorité de publication ou seulement l'autorité de support? Comment les clés sont-elles protégées? Comment la restitution est-elle auditée?

Le projet de gouvernance du cycle de vie du NRO est pertinent car il reconnaît que le fonctionnement des RIR et une éventuelle perte de reconnaissance nécessitent plus que des critères d'entrée. Mais RPKI a besoin d'une annexe de continuité encore plus détaillée. Un registre peut être reconnu en général et avoir toujours un problème temporaire de signature RPKI. Un registre peut avoir RPKI en fonctionnement et manquer encore de confiance des membres. Une proposition de perte de reconnaissance peut prendre du temps alors que la preuve de routage doit être maintenue quotidiennement.

La couche de certificat n'attend pas que la théorie institutionnelle se calme.

Il en va de même pour les sanctions et les restrictions légales. Un registre peut avoir besoin de se conformer à la loi applicable. Il peut avoir besoin d'empêcher les services à une partie sanctionnée. Il peut avoir besoin d'éviter de faciliter la fraude. Mais une retenue légale doit être précise. Elle doit dire si les ROA existants restent en place, si les nouveaux ROA sont bloqués, si une révocation est requise, si la publication déléguée continue, si un tribunal ou un régulateur s'est prononcé, si les préfixes non affectés continuent et si le titulaire dispose d'une voie de recours.

Sinon, l'état du certificat devient une application cachée.

La norme de gouvernance devrait être la preuve de routage la moins destructrice. Lorsque les faits sont incertains, préserver le dernier état sûr connu si possible. Quand une autorisation de route est clairement non autorisée, corrigez-la. Quand l'autorité est contestée, marquez et suspendez l'action contestée plutôt que de casser le service non affecté. En cas de contrainte légale, décrivez la conséquence sur le service aussi étroitement que le permet la confidentialité. En cas d'erreur du registre, publiez la correction et le calendrier.

Lorsqu'une action d'urgence est prise, rendez-la réversible à moins que la sécurité immédiate ne l'exige autrement.

Cette norme n'affaiblirait pas RPKI. Elle renforcerait la confiance en rendant l'état du certificat crédible. Les opérateurs n'ont pas besoin d'un confort parfait. Ils ont besoin de savoir si un changement de validité reflète une autorisation de routage, des données périmées, une restriction légale, une compromission de compte, un délai de transfert, une panne de registre ou une crise de gouvernance. Ce sont des faits différents avec des remèdes différents.

La confiance commune a besoin de preuves indépendantes

Le rôle de coordination du NRO peut produire un système RPKI plus fort s'il insiste sur des preuves indépendantes dans le cadre de normes communes. Une base de référence partagée ne devrait pas simplement dire que tous les RIR fournissent un service hébergé. Elle devrait publier des mesures de service comparables: disponibilité du dépôt, latence de mise à jour, nombre d'incidents, temps de réponse du support, délais de préavis de changement de TAL, disponibilité de l'historique des transactions, adoption du service délégué, exercices d'urgence et publication des causes racines.

Des preuves comparables permettent aux opérateurs de voir où la résilience est réelle et où elle est aspirationnelle.

La base de référence devrait également publier des cartes des domaines de défaillance. Pour chaque RIR, la carte devrait montrer le portail hébergé, le chemin délégué, la publication du dépôt, la gestion des TAL, les CPS, la récupération de compte, le transfert de transfert, la retenue légale, l'opérateur d'urgence, l'escalade de support et le canal d'incident public.

Pour le programme du NRO dans son ensemble, la carte devrait montrer quelles décisions sont conjointes, lesquelles sont régionales, lesquelles nécessitent l'ICANN, lesquelles impliquent l'IANA, lesquelles reposent sur un comportement défini par RFC et lesquelles dépendent du déploiement d'opérateurs privés.

L'examen indépendant devrait faire partie de la carte. Si un titulaire de ressources estime qu'un changement de ROA a été refusé à tort, qui examine? Si un point de publication délégué est mal classé, qui examine? Si un transfert laisse une autorisation périmée, qui examine? Si un registre invoque une restriction légale, un titulaire affecté peut-il voir suffisamment pour contester la conséquence sur le service? Si une pratique commune de RPKI du NRO cause un préjudice, y a-t-il une voie pour contester la pratique commune ou seulement cinq tickets de support locaux?

L'organe d'examen n'a pas besoin d'être un tribunal. De nombreux problèmes sont techniques et urgents. Le premier examinateur peut être une équipe d'escalade interne. Le deuxième peut être un panel technique indépendant. Le troisième peut être un recours institutionnel si le problème concerne l'autorité ou l'équité. Les tribunaux restent pertinents pour les droits légaux, la fraude, l'autorité de l'entreprise ou la contrainte légale. Le point est que la preuve de routage automatisée ne devrait pas supprimer la contestabilité humaine lorsque le litige porte sur l'autorité du registre plutôt que sur la syntaxe cryptographique.

La dissidence devrait également être visible. Si un RIR estime qu'une base de référence RPKI commune proposée crée un risque juridique dans sa région, cette dissidence devrait être publiée avec des raisons. Si un RIR ne peut pas mettre en œuvre une fonctionnalité en raison de la loi locale, l'écart devrait être nommé. Si un RIR dépasse la base de référence avec une autonomie de service délégué plus forte ou des droits de recours, cette amélioration ne devrait pas être cachée dans la documentation régionale. La confiance commune est plus forte lorsque les opérateurs peuvent voir la variation et la juger.

Les ingénieurs en sécurité craignent parfois qu'une trop grande discussion sur la gouvernance ne ralentisse le déploiement. Ce risque est réel. L'adoption de RPKI a déjà pris des années, et les fuites de routes et les détournements restent des menaces opérationnelles. Mais le risque de gouvernance caché ralentit également l'adoption. Les opérateurs hésitent lorsqu'ils craignent des erreurs de certificat unilatérales, une révocation peu claire, une garde hébergée, une récupération faible ou un retrait légal. Un modèle de domaine de défaillance plus clair peut accroître l'adoption car il montre ce qui est contrôlé et ce qui reste risqué.

Le meilleur argument pour le programme du NRO n'est donc pas « faites-nous confiance, les cinq RIR sont d'accord ». C'est « voici les bases communes, voici les domaines indépendants, voici les lacunes connues, voici la voie de recours, voici le plan d'urgence, voici les preuves ». C'est un message de sécurité plus fort car il traite la confiance comme vérifiable.

La résilience devrait être testée par des exercices, pas par des déclarations

La continuité RPKI a besoin d'exercices. Les exercices devraient être suffisamment publics pour améliorer la confiance et suffisamment privés pour protéger les clés et les surfaces d'attaque. Un exercice de communication des ancres de confiance peut tester si les parties qui s'appuient reçoivent l'avis, comprennent le calendrier et mettent à jour les validateurs en toute sécurité. Un exercice de panne de dépôt peut tester le comportement du cache périmé et la messagerie des opérateurs. Un exercice de compromission du portail hébergé peut tester le gel des comptes, l'examen des transactions et la notification au titulaire.

Un exercice de transfert peut tester le nettoyage des anciens ROA et le calendrier des nouveaux ROA. Un exercice de défaillance du service délégué peut tester la coordination parent sans saisir de contrôle inutile.

Un exercice d'urgence de registre est particulièrement important. Il devrait demander ce qui se passe si un registre perd du personnel critique, fait face à l'insolvabilité, perd l'autorité du conseil d'administration, subit un scénario de gardien nommé par le tribunal, ou ne peut pas exploiter son portail. Le Fonds de stabilité conjoint des RIR reconnaît des scénarios tels que la détresse financière, la perte de personnel critique, les catastrophes naturelles, l'instabilité politique, l'activité criminelle et les problèmes d'infrastructure structurelle. RPKI devrait être un service nommé dans tout événement de ce type.

L'exercice devrait identifier qui peut maintenir le matériel existant valide, qui peut publier des avis d'urgence, qui peut traiter les corrections de sécurité urgentes, et quelles actions sont gelées jusqu'à ce que l'autorité soit restaurée.

Le résultat ne devrait pas révéler de détails sensibles sur la gestion des clés. Il devrait révéler des classes de service. Par exemple: la publication du dépôt existant continue; la création de nouveaux ROA est disponible pour les titulaires authentifiés; la récupération de compte à haut risque nécessite une double approbation; les changements de certificat liés au transfert sont traités sous examen d'urgence; les changements juridiques contestés sont suspendus; les ressources non affectées continuent; les mises à jour publiques apparaissent à une cadence définie.

De telles déclarations transforment la résilience d'une assurance en une promesse opérationnelle.

Les exercices devraient également inclure les titulaires multi-RIR. Une entreprise ayant des ressources dans plusieurs régions peut être confrontée à des contrôles de portail, des options déléguées, des heures de support et des exigences légales différents. Un incident mondial peut nécessiter des changements dans plus d'une région. Si le programme du NRO veut supprimer les obstacles pour les opérateurs qui créent des objets RPKI via plusieurs RIR, il devrait tester le parcours d'urgence multi-région de l'utilisateur.

Les parties qui s'appuient devraient faire partie de l'exercice. RPKI n'est complet que lorsque les validateurs et les réseaux consomment les données. Un registre peut publier correctement tandis que les validateurs mettent en cache de manière incorrecte, interprètent mal les cas limites ou ne parviennent pas à alerter les opérateurs. Un exercice devrait impliquer les principales implémentations de validateurs, les serveurs de route, les fournisseurs de transit, les points d'échange et les grands réseaux cloud le cas échéant. Le NRO ne les contrôle pas, mais il peut coordonner la communication et publier les leçons.

L'audit devrait rejeter les mesures de vanité. Le nombre de ROA est utile mais incomplet. Le pourcentage de préfixes routés couverts est utile mais incomplet. Le nombre de RIR offrant une fonctionnalité est utile mais incomplet. La résilience exige le temps de détection, le temps de correction, le comportement en cas de données périmées, le chemin de support, la contestabilité du titulaire, le repli délégué, la transparence des incidents et l'autorité d'urgence.

La métrique la plus sérieuse est le rayon de l'explosion. Si un registre prend une mauvaise décision RPKI, jusqu'où l'effet se propage-t-il? Si une base de référence du NRO contient une hypothèse erronée, combien de régions en héritent? Si un comportement de validateur est erroné, combien de réseaux l'appliquent? Si une communication d'ancre de confiance échoue, combien de parties qui s'appuient sont affectées? Si une théorie juridique gèle les changements de certificat, combien de préfixes perdent leur flexibilité opérationnelle? Un système qui ne peut pas répondre aux questions sur le rayon de l'explosion n'est pas assez résilient.

Le public ne devrait pas avoir à déduire le modèle de confiance

La confiance RPKI devrait être expliquée dans un langage public. Tous les opérateurs ne sont pas des spécialistes de l'ICP. Tous les avocats ne comprennent pas les ROA. Tous les tribunaux ne comprennent pas les validateurs. Tous les conseils d'administration ne connaissent pas la différence entre service hébergé et délégué. Un système de registre mature devrait rendre le modèle de confiance lisible sans le simplifier à l'excès.

Les documents de base du NRO sont un bon début. Ils comparent les modes de service, le support des objets, les API, l'authentification et les fonctionnalités connexes. Le dépôt de contenu renvoie vers les portails, les informations TAL et les documents CPS. La page du programme explique pourquoi la cohérence est un objectif. La feuille de route nomme les dates cibles. Ces documents rendent le système plus facile à inspecter.

La couche manquante est la traduction de la gouvernance.

Chaque RIR devrait publier un court document public qui répond: que prouve notre certificat RPKI; que ne prouve-t-il pas; qui peut demander des modifications; comment les rôles sont-ils vérifiés; comment traitons-nous les transferts; comment traitons-nous les litiges; comment traitons-nous la compromission de compte; que se passe-t-il en cas de restriction légale; que se passe-t-il en cas d'urgence du registre; comment un titulaire peut-il obtenir un examen urgent; comment une partie qui s'appuie peut-elle signaler des problèmes de dépôt ou de TAL; en quoi les services hébergé et délégué diffèrent-ils en matière de contrôle?

Cette traduction devrait éviter les revendications juridiques excessives. Un certificat est une preuve de l'état reconnu de détention de ressources et de la relation d'autorisation, et non un justificatif d'identité universel. Un ROA est une autorisation d'origine de route, et non une garantie de sécurité complète. Un résultat d'origine de route valide ne signifie pas que le chemin est sûr. Un résultat invalide peut provenir d'une mauvaise configuration autant que d'une attaque. RPKI améliore la preuve de routage; il ne supprime pas le jugement opérationnel.

L'explication publique devrait également éviter la sous-estimation institutionnelle. Si l'action du registre peut affecter la validité de l'origine de route, le registre devrait le dire. Si un retard de support peut affecter le routage, dites-le. Si le service délégué réduit une certaine dépendance mais pas la dépendance à la confiance parente, dites-le. Si un changement de TAL nécessite l'attention des parties qui s'appuient, dites-le. Les utilisateurs font davantage confiance aux institutions lorsque les limites sont visibles.

Le langage doit être cohérent mais pas vide. « Robuste, coordonné et sécurisé » est une déclaration de mission. Les opérateurs ont besoin des noms qui se cachent derrière: clé, TAL, dépôt, ROA, manifeste, compte, rôle, journal, incident, recours, contact d'urgence, restitution, audit. La gouvernance devient crédible lorsque ces noms sont liés aux décisions.

Une meilleure norme pour le programme du NRO

Le NRO devrait continuer à coordonner RPKI. L'alternative est pire: cinq services inégaux, une confusion évitable, des contrôles de sécurité plus faibles et une adoption multi-région plus difficile. Mais la coordination devrait être jugée selon une norme plus élevée que le simple alignement des fonctionnalités. Le programme devrait publier un registre des domaines de défaillance.

Le registre énumérerait chaque fonction RPKI de base et classerait son indépendance. Création de ROA hébergés: portail régional avec base de référence commune. Service délégué: disponibilité régionale avec confiance parente. Configuration des ancres de confiance: TAL régionaux avec risque de consultation conjointe. Publication du dépôt: infrastructure régionale avec consommation mondiale des parties qui s'appuient. Gestion des API: mise en œuvre régionale avec objectif de fonctionnalité commune. Signalement des incidents: devoir régional avec termes de gravité communs. Continuité d'urgence: soutien conjoint avec autorité régionale.

Restriction légale: droit régional avec conséquences de routage mondiales. Communication des validateurs: écosystème partagé au-delà du contrôle des RIR.

Pour chaque fonction, le registre devrait nommer la défaillance principale, les dépendances secondaires, l'atténuation du titulaire, l'atténuation de la partie qui s'appuie, la mesure publique et le chemin d'examen. Cela rendrait la résilience testable. Cela montrerait également où les normes communes réduisent le risque et où elles le concentrent.

Le programme devrait également publier une taxonomie commune des incidents. Une panne de dépôt n'est pas la même chose qu'une panne de portail. Un échec de notification TAL n'est pas la même chose qu'un mauvais ROA. Un ROA de transfert périmé n'est pas la même chose qu'une compromission de compte. Une retenue légale n'est pas la même chose qu'une défaillance technique. Les opérateurs ont besoin de ces distinctions car les remédiations diffèrent.

Enfin, le programme devrait protéger les preuves régionales indépendantes. Chaque RIR devrait publier ses propres CPS, l'historique des incidents, les mesures de service, l'adoption du service délégué, les engagements de support et les contraintes juridiques locales. Le NRO devrait agréger sans effacer. L'intérêt des cinq RIR n'est pas d'afficher cinq emblèmes. C'est de préserver suffisamment d'indépendance régionale pour que les échecs, l'apprentissage et la réforme ne se produisent pas tous dans une seule pièce fermée.

Sources et limites

Cette analyse s'appuie sur la RFC 6480 pour l'architecture RPKI, la RFC 6490 pour la structure du Trust Anchor Locator, la page du programme RPKI du NRO pour les objectifs du programme commun, les documents de base RPKI communs du NRO et l'aperçu des services pour les fonctionnalités inter-RIR, le dépôt de contenu RPKI du NRO pour les références TAL et CPS, et la feuille de route du NRO pour l'alignement des fonctionnalités cibles. Elle utilise également les documents de gouvernance du NRO uniquement pour encadrer le contexte de continuité d'urgence et de reconnaissance.

Les sources soutiennent l'affirmation selon laquelle RPKI est coordonné entre les cinq RIR et que les fonctionnalités de service varient. Elles ne prouvent pas une panne commune réelle, une décision cachée sur les ancres de confiance ou une concentration illicite. L'argument est une norme de résilience: comptez les domaines de défaillance, pas les logos.