Résumé

  • Le RPKI hébergé retire au détenteur de ressources les tâches complexes de certificats, de renouvellement, de manifeste, de liste de révocation et de gestion du dépôt. Il a permis à des organisations ne disposant pas d'équipes spécialisées en cryptographie à clé publique de créer et de maintenir des autorisations d'origine de route.
  • Le service regroupe également les contrôles. Selon le RIR, le registre peut détenir la clé privée de l'autorité de certification (CA) hébergée, traduire les paramètres du portail en objets signés, publier ces objets, mettre à jour la portée du certificat à partir des enregistrements de ressources et les supprimer lorsque le service prend fin.
  • Une panne du portail n'invalide pas automatiquement les ROA existantes. Le risque le plus aigu est la perte de la capacité de modification et de récupération, ou une décision du registre qui révoque la CA hébergée ou supprime ses objets. À ce stade, l'utilisateur peut ne disposer d'aucune clé indépendante ni d'aucune voie de publication pour préserver les autorisations prévues.
  • Le RPKI délégué donne au détenteur sa propre CA et sa clé privée. Il peut améliorer l'automatisation, la gestion multi-RIR et l'indépendance vis-à-vis d'une interface de signature hébergée. Mais il n'échappe pas au parent: le RIR émet toujours le certificat de ressource et peut le restreindre ou le révoquer.
  • Les configurations hybrides séparent la garde des clés de l'exploitation du dépôt. Elles offrent souvent le meilleur équilibre pratique, mais la publication par le parent reste une dépendance de service et une CA déléguée obsolète peut elle-même devenir un risque pour les parties utilisatrices.
  • Les opérateurs doivent choisir un modèle en fonction des conséquences, et non de la mode. Les services publics critiques, les réseaux complexes à origines multiples et les grandes délégations en aval méritent un contrôle plus fort et une transition éprouvée; les petits réseaux simples peuvent rationnellement rester en mode hébergé si les garanties procédurales et les moyens de récupération sont crédibles.
  • La Number Resource Society peut aider en publiant un registre de comparaison des modèles, des tests de continuité et des questions destinées aux conseils d'administration des RIR. Elle devrait renforcer le choix éclairé plutôt que de présenter l'auto-hébergement comme une simple souveraineté.

La panne commence lorsqu'un changement valide ne peut être effectué

Un réseau déplace un service d'un AS d'origine à un autre. Ses ingénieurs ont configuré la nouvelle annonce BGP et ont l'intention de créer la nouvelle ROA avant de retirer l'ancienne route. En RPKI hébergé, ils doivent utiliser le portail ou l'interface du RIR. Si le compte est inaccessible, si l'interface est indisponible ou si le RIR a suspendu la certification, l'opérateur ne peut pas signer lui-même un remplacement. Il ne possède pas la clé de la CA hébergée.

Cela ne signifie pas que la route existante échoue instantanément. La ROA existante peut rester publiée et valide tant que le portail est indisponible. Dans ce cas, le danger immédiat est la paralysie du changement. La nouvelle origine peut devenir Invalide si l'ancienne ROA couvrante n'autorise que l'ancien AS. Les ingénieurs peuvent reporter une migration nécessaire, faire fonctionner une route que certains réseaux rejettent ou demander au registre de rétablir l'accès sous pression.

Un événement plus grave se produit si la CA hébergée est révoquée ou si ses objets signés sont supprimés. L'opérateur ne peut pas republier les mêmes objets sous la même clé à partir d'une sauvegarde, car la clé n'a jamais été sous son contrôle. Il ne peut pas créer d'enfant délégué après que le parent a mis fin au service sans la coopération du parent. L'institution qui fournit la commodité est devenue le chemin obligé vers la récupération.

C'est là le piège de la commodité. Ce n'est pas l'affirmation que le RPKI hébergé est toujours peu fiable, ni que chaque interruption de service supprime les ROA. C'est la concentration de l'autorité au moment où l'utilisateur a le plus besoin d'une option indépendante. Un service peut être simple en temps normal, mais fragile en cas de litige, de transfert, de compromission ou de changement de routage urgent.

La comparaison correcte commence donc par les chemins de contrôle, et non par des slogans. Qui peut exprimer l'intention de routage? Qui possède la clé de signature? Qui détermine les ressources certifiées? Qui publie les objets? Qui peut les révoquer? Qui peut maintenir une autorisation valide visible pendant une migration? Le RPKI hébergé et le RPKI délégué répondent différemment à ces questions.

La commodité a résolu un véritable problème d'adoption

Exploiter une CA RPKI n'est pas la même chose que créer un certificat de connexion ordinaire. La CA doit protéger les clés, demander et renouveler les certificats de ressource, émettre des objets signés, maintenir les manifestes et les listes de révocation, publier du matériel à jour, survivre aux pannes et interagir correctement avec les systèmes parents. Son dépôt doit être accessible aux parties utilisatrices, directement ou via un fournisseur de publication. Les erreurs peuvent modifier la validation d'origine de route.

La plupart des opérateurs de petite et moyenne taille n'ont pas constitué d'équipes pour cette tâche. Ils voulaient autoriser leurs préfixes, sans devenir des spécialistes de l'infrastructure à clé publique. Le RPKI hébergé leur a permis de choisir un AS d'origine et un préfixe dans un portail membre familier, tandis que le RIR prenait en charge l'émission, la signature, le renouvellement et la publication des certificats.

Les services régionaux décrivent ouvertement cet avantage. ARIN qualifie le RPKI hébergé d'option la plus facile et indique qu'il exploite la CA et un dépôt à haute disponibilité. Le RIPE NCC indique que les utilisateurs hébergés ont principalement besoin de maintenir les ROA alignées sur le routage BGP prévu, tandis que son système gère les opérations cryptographiques et la publication. APNIC gère l'infrastructure de certificat et de publication pour les utilisateurs hébergés et génère les clés privées en leur nom. LACNIC propose un service hébergé depuis 2011.

Ce modèle crée des externalités positives. Un détenteur de ressources qui ne déploierait jamais une CA déléguée peut néanmoins publier des autorisations exactes. Les interfaces des RIR peuvent avertir lorsqu'une ROA proposée rendrait une annonce connue Invalide. Les systèmes centraux peuvent automatiser le renouvellement, le basculement de clés, les manifestes et la disponibilité du dépôt. Le personnel d'assistance peut aider les membres à corriger leurs erreurs.

Il serait pervers de définir la maturité comme l'obligation pour chaque réseau communautaire, université ou fournisseur local d'exploiter une CA. Une sécurité que seuls les grands opérateurs peuvent gérer restera incomplète. La critique de la dépendance excessive doit préserver la voie d'accès facile au RPKI.

L'objectif politique est l'optionalité avec des paramètres par défaut sûrs. Le service hébergé doit rester une option par défaut accessible. Le service délégué et le service hybride doivent rester des sorties pratiques pour les utilisateurs dont le risque exige plus de contrôle. Passer de l'un à l'autre ne doit pas créer de lacune évitable. La commodité est précieuse lorsqu'elle est un choix, elle l'est moins lorsqu'elle devient silencieusement une captivité.

Cinq contrôles sont cachés derrière un seul portail

L'interface hébergée présente un seul service, mais au moins cinq contrôles se cachent en dessous.

Le premier est la portée de l'enregistrement. Le RIR décide quels blocs d'adresses IP et numéros d'AS ses enregistrements associent au détenteur et placeront dans un certificat de ressource. Un portail ne peut pas autoriser un préfixe en dehors de cette portée.

Le deuxième est l'intention de routage. Le détenteur choisit l'AS d'origine, le préfixe et éventuellement la longueur maximale. Dans un service hébergé bien conçu, le personnel n'invente pas cette intention. L'utilisateur la soumet par le biais de contrôles authentifiés, et le système avertit des conflits évidents.

Le troisième est la garde des clés et la signature. Le fournisseur hébergé génère ou stocke la clé privée et l'utilise pour créer des objets signés. Les conditions du RIPE NCC définissent une CA hébergée comme une CA pour laquelle il est responsable des opérations cryptographiques et héberge la paire de clés publique et privée du détenteur. APNIC indique de même qu'il génère les clés privées pour le compte des utilisateurs hébergés.

Le quatrième est la publication. Le dépôt du RIR met les certificats, manifestes, listes de révocation et objets signés à la disposition des parties utilisatrices. La publication doit rester à jour et accessible mondialement. Une signature correcte qui n'est pas accessible aux validateurs a peu de valeur opérationnelle.

Le cinquième est l'autorité de cycle de vie. Le service renouvelle, remplace et révoque les certificats et supprime les objets lorsque les ressources ou le statut du service changent. C'est là que se rencontrent l'enregistrement, les contrats et les preuves de routage.

Le portail cache cette complexité pour de bonnes raisons. Le problème surgit lorsque la gouvernance la cache aussi. Un utilisateur peut croire qu'il contrôle le RPKI parce qu'il peut cliquer sur Créer une ROA, tandis que le fournisseur contrôle la clé, la publication et la résiliation. Le fournisseur peut souligner que les routeurs prennent des décisions locales, tout en minimisant la manière dont son action de cycle de vie modifie les données que ces routeurs reçoivent.

Un accord de service utile devrait nommer chaque contrôle et attribuer une responsabilité. Sans cette carte, la responsabilité n'apparaît qu'après un incident, lorsque chaque partie pointe une couche différente.

La garde des clés hébergée n'est pas une externalisation ordinaire

Les organisations externalisent couramment la messagerie, la paie et l'informatique en nuage. Le RPKI hébergé diffère sur un point: le fournisseur de service est également l'autorité parente qui détermine la portée du certificat. Il peut donc combiner le pouvoir de définir ce qui peut être signé avec la capacité d'effectuer la signature.

Cette concentration est efficace. Le fournisseur peut automatiquement mettre à jour les certificats lorsque les avoirs changent, renouveler les objets avant leur expiration et supprimer les autorisations pour les ressources qui ne sont plus enregistrées au nom de l'utilisateur. Il peut conserver les clés dans un module de sécurité matériel et séparer les rôles opérationnels plus efficacement qu'un petit opérateur.

Elle modifie également le modèle de menace. Un compte utilisateur compromis pourrait créer des intentions de routage nuisibles si l'authentification et l'approbation sont faibles. Un environnement de signature hébergé compromis pourrait affecter de nombreuses CA. Une mise à jour erronée de l'enregistrement pourrait supprimer des ressources et déclencher des modifications d'objets. Un administrateur interne pourrait avoir des pouvoirs qu'aucun employé ne devrait posséder. Une décision juridique ou contractuelle peut être mise en œuvre sans que le détenteur n'effectue une action de signature distincte.

Il ne s'agit pas d'accusations selon lesquelles les RIR utilisent mal les clés. Ce sont les conséquences de la concentration des contrôles. La réponse réside dans une conception de service solide: authentification multifacteur, approbation basée sur les rôles, modifications à haut risque différées, audit indépendant, protection matérielle, historique immuable et séparation entre les modifications d'enregistrement et l'exécution ayant un impact sur les certificats.

Le détenteur doit pouvoir exporter un compte rendu complet et signé de ses intentions de routage et de l'ensemble actuel des objets. Il ne peut pas exporter la clé privée si le service conserve correctement cette clé non récupérable, mais il peut conserver suffisamment d'informations pour recréer les autorisations sous une CA déléguée ou une CA hébergée successeur. La portabilité des données n'est pas la portabilité des clés.

Le fournisseur doit également divulguer si un administrateur de compte, un membre du personnel du RIR ou un événement automatisé peut révoquer l'intégralité de la CA hébergée; quelles approbations sont requises; et dans quel délai une révocation erronée peut être annulée. Un service de sécurité devient digne de confiance lorsque les contrôles autour de l'utilisation des clés sont aussi visibles que l'étiquette verte Valide dans le portail.

Le point unique est la révocation et la récupération, pas chaque panne

Qualifier le RPKI hébergé de point de défaillance unique peut être trop grossier. Le dépôt peut être répliqué. Les objets existants ont des périodes de validité. Le logiciel des parties utilisatrices met en cache les données validées et dispose de règles pour les dépôts indisponibles. Une courte interruption du portail peut laisser la validation de route inchangée. Un RIR peut exploiter une infrastructure bien plus résiliente que ce que le membre pourrait s'offrir.

Le point unique le plus critique est l'autorité de révocation et de récupération. Si le RIR révoque la CA hébergée ou met fin à l'accès à la certification, l'utilisateur ne peut plus continuer à signer sous cette CA. Si le RIR supprime les objets hébergés à la fin du service, l'opérateur ne peut pas contraindre l'ancien dépôt à les servir indéfiniment. Le parent doit émettre un nouveau certificat délégué ou restaurer le service hébergé pour que l'utilisateur puisse retrouver un chemin valide.

Les conditions actuelles illustrent le problème. Les conditions du RIPE NCC indiquent que tous les objets signés sont supprimés à la fin du service de certification et autorisent la révocation lorsqu'un certificat est en conflit avec les enregistrements d'enregistrement, pour des raisons techniques ou de sécurité, en cas de violation des conditions ou lorsque le détenteur met fin au service. L'accord d'ARIN énumère plusieurs motifs de résiliation immédiate, lie l'éligibilité au RPKI à d'autres accords et réserve également un droit de résiliation avec préavis.

Le langage juridique diffère selon les régions et ne doit pas être aplati en une règle mondiale unique. Un droit contractuel ne prouve pas non plus qu'il a été utilisé de manière injuste. Le point est structurel: les utilisateurs hébergés dépendent de la même contrepartie pour la signature continue et pour la transition hors de cet arrangement de signature.

Un service hébergé crédible a besoin d'une garantie de sortie. En cas de résiliation non urgente, il devrait offrir une période définie pour établir une CA déléguée ou de remplacement, exporter les configurations, vérifier la publication et coordonner les changements de route. Une révocation d'urgence devrait inclure une réinscription rapide sous une clé propre lorsque le détenteur reste admissible à la certification. Les litiges sur le paiement ou l'identité devraient bénéficier d'une voie de révision rapide avant que les preuves de routage ne soient inutilement détruites.

Sans ces facilités, la haute disponibilité en période ordinaire ne répond pas au mode de défaillance le plus conséquent.

Le RPKI délégué change qui peut signer

En RPKI délégué, le détenteur exploite une CA enfant et contrôle sa clé privée. Le RIR parent émet un certificat de ressource à cet enfant. Le détenteur peut alors créer des ROA et d'autres objets autorisés, automatiser les modifications à partir de ses systèmes réseau et, lorsque cela est pris en charge, émettre d'autres certificats enfants.

Cela donne à l'opérateur trois formes d'indépendance. Il n'a pas besoin du portail de signature hébergé pour chaque changement de routage. Il peut protéger la clé selon sa propre politique de sécurité. Il peut gérer les ressources reçues de plusieurs parents RIR via un seul système local, réduisant les actions manuelles incohérentes entre les interfaces régionales.

L'indépendance est cryptographiquement significative. Le parent RIR ne peut pas signer un faux objet avec la clé de l'enfant simplement parce qu'il a émis le certificat enfant. Un historique d'audit conservé localement peut montrer exactement ce que le détenteur a signé et quand. L'opérateur peut décider à quel point les changements dans l'intention BGP et les objets RPKI sont étroitement couplés.

La délégation ne fait pas du détenteur sa propre ancre de confiance pour les ressources. Le parent décide toujours des ressources dans le certificat. Il peut remplacer un certificat par un certificat plus étroit après un transfert ou une restitution. Il peut révoquer le certificat enfant. Si le détenteur signe au-delà de la portée valide, les parties utilisatrices rejettent la revendication excessive.

Cette limite est importante en cas de litige. La délégation protège contre la dépendance à la clé hébergée et à l'interface utilisateur du parent; elle ne permet pas à un ancien détenteur de préserver la certification après un transfert légitime. Elle ne rend pas les enregistrements du registre inutiles. Elle donne à l'opérateur le contrôle sur les déclarations à l'intérieur de la portée que le parent certifie actuellement.

La délégation doit donc être présentée comme une séparation des tâches, et non comme une sécession. Sa valeur réside dans le fait qu'aucune institution unique ne possède à la fois toutes les clés de signature et ne contrôle toutes les décisions parentes. Sa limite est que la hiérarchie des ressources a encore besoin d'un parent autoritaire.

La publication crée un troisième modèle

La comparaison habituelle entre RPKI hébergé et délégué passe à côté d'un juste milieu utile. Un détenteur peut exploiter sa propre CA et sa clé privée tout en utilisant le service de publication du dépôt du RIR. ARIN appelle cela le Service de Publication de Dépôt (Repository Publication Service). Le RIPE NCC propose Publish in Parent. APNIC propose la publication pour les clients auto-hébergés.

Ce modèle hybride sépare la garde des signatures de la distribution. L'opérateur peut créer des objets sans la CA hébergée du RIR, tandis que le RIR fournit un dépôt à haute disponibilité déjà consulté par les parties utilisatrices. Cela évite d'exiger de chaque détenteur qu'il expose et défende un service de publication mondial.

Le service hybride offre souvent le meilleur équilibre pour un opérateur compétent. Le contrôle local des clés réduit la dépendance à l'interface de signature hébergée. La publication par le parent réduit la charge opérationnelle et la prolifération de dépôts fragiles. Des normes telles que la RFC 8181 définissent des demandes de publication et de retrait authentifiées, permettant à la CA et au dépôt d'être gérés par des parties différentes.

La séparation n'est pas une indépendance totale. Le fournisseur de publication peut ne pas accepter un changement, devenir indisponible ou supprimer du matériel selon ses conditions. Le parent émet toujours le certificat de ressource enfant. Un opérateur qui a besoin de l'autonomie la plus forte peut exploiter à la fois la CA et le dépôt, tout en acceptant les responsabilités de disponibilité et de sécurité qui en découlent.

La discussion d'APNIC de 2025 sur la disponibilité du RPKI énonce directement le compromis. Une CA déléguée donne au détenteur un plus grand contrôle sur son état RPKI et la responsabilité de l'émission et du renouvellement des objets. Pourtant, il reste dépendant de l'ancre de confiance d'APNIC et, s'il utilise la publication d'APNIC, de ce dépôt. Le document avertit également que de nombreux dépôts délégués sont des instances uniques en un seul endroit.

Le modèle utile est donc un spectre. Le mode hébergé place la signature et la publication chez le RIR. Le mode hybride garde la signature locale et la publication chez un fournisseur. Le mode entièrement délégué garde les deux en local. La certification parente reste au-dessus des trois. Les organisations doivent choisir délibérément la dépendance qu'elles sont équipées pour absorber.

L'auto-hébergement a son propre piège de révocation

Un argument en faveur du RPKI délégué qui ignore les défaillances opérationnelles est incomplet. Une CA doit émettre des manifestes et des listes de révocation à jour avant leurs heures de prochaine mise à jour. Son dépôt doit servir un matériel cohérent. Les clés doivent survivre aux pannes matérielles sans devenir faciles à voler. Le personnel doit comprendre la revendication excessive, le basculement de clés et les échanges avec le parent.

Une CA déléguée négligée peut peser sur les parties utilisatrices et rendre ses propres objets inutilisables. Le document RIPE-847 traite d'un cas extrême: lorsque le RIPE NCC ne peut pas découvrir et valider le manifeste et la liste de révocation actuels d'une CA déléguée pendant plus de trois mois, il doit révoquer le certificat de ressource après des efforts raisonnables de découverte et de notification. La politique cible explicitement les CA constamment non fonctionnelles plutôt que les pannes courtes ordinaires.

Cette politique révèle le devoir réciproque. La délégation donne au détenteur le contrôle de la signature, mais le parent et la communauté des parties utilisatrices ont besoin de l'assurance que l'enfant ne restera pas indéfiniment cassé. Le parent doit pouvoir élaguer une branche morte. Le détenteur doit recevoir la preuve de l'échec de validation, un préavis et un chemin de restauration.

L'opérateur est également confronté au risque de continuité humaine. Le seul ingénieur qui a construit la CA peut partir. Les clés de sauvegarde peuvent exister mais être illisibles. Une acquisition d'entreprise peut séparer l'équipe réseau du dispositif de sécurité. Une crise peut révéler que la souveraineté locale dépendait d'un seul ordinateur portable et d'une seule mémoire.

Le service délégué n'est pas nécessairement coûteux en termes de calcul; les logiciels de CA modernes peuvent fonctionner sur du matériel modeste. Le coût réel est institutionnel: la propriété, la responsabilité de l'astreinte, la révision des changements, le test des sauvegardes, la surveillance du dépôt et la succession. Les grands opérateurs peuvent échouer à ces tâches, tandis qu'un petit opérateur discipliné peut les accomplir correctement.

La comparaison avec le service hébergé doit donc compter les deux points uniques de révocation. Les utilisateurs hébergés risquent la dépendance à la décision et à la récupération du fournisseur. Les utilisateurs délégués risquent de devenir l'autorité défaillante à l'intérieur de leur propre branche. Une conception hybride et un processus parent solide peuvent réduire, mais pas éliminer, l'un ou l'autre risque.

La migration est là où l'optionalité est testée

Un marché offre un choix seulement si les utilisateurs peuvent changer leur choix. La migration entre RPKI hébergé et délégué est techniquement délicate car l'ancienne et la nouvelle CA peuvent couvrir les mêmes ressources, tandis que les parties utilisatrices récupèrent les données à des moments différents.

La documentation du RIPE NCC sur l'hébergement indique qu'un utilisateur passant à un service délégué doit d'abord révoquer la CA hébergée et qu'une migration de type « make-before-break » n'y est actuellement pas possible. APNIC indique que les modes hébergé et auto-hébergé peuvent fonctionner en parallèle pendant les transitions. ARIN demande aux utilisateurs de contacter les Services d'Enregistrement lorsqu'ils changent de déploiement. Ce sont des expériences opérationnelles matériellement différentes.

La transition idéale préserve les intentions de routage valides pendant que les clés et les points de publication changent. L'utilisateur doit exporter ses autorisations actuelles, préparer la nouvelle CA, tester les échanges avec le parent et le dépôt, publier des objets équivalents et les observer à partir de validateurs indépendants avant la disparition de l'ancienne CA. Si la politique régionale interdit le chevauchement, le service doit prendre en charge un basculement programmé avec une restauration rapide.

La certification parallèle n'est pas automatiquement bénigne. Des objets dupliqués ou incohérents peuvent embrouiller les opérateurs, et une ancienne clé ne doit pas conserver l'autorité plus longtemps que nécessaire. Un chevauchement sûr nécessite une durée fixe, une portée de ressources équivalente, une responsabilité claire et une fermeture automatique. L'alternative, cependant, ne devrait pas être une période inexpliquée pendant laquelle l'utilisateur n'a ni contrôle hébergé ni contrôle délégué.

La migration compte également lors d'un transfert, d'une fusion ou d'une restructuration d'entreprise. Un acheteur peut vouloir un contrôle délégué alors que le vendeur utilisait un service hébergé. Un groupe opérant à travers plusieurs RIR peut consolider ses CA. Le RIR devrait traiter la transition RPKI comme une partie standard du mouvement des ressources, et non comme une réflexion après coup laissée au jour de la clôture.

Des mesures de portabilité amélioreraient la responsabilisation. Chaque RIR pourrait publier les étapes normales, le préavis minimum, la période attendue sans accès aux modifications, la disponibilité du chevauchement et le contact pour escalade en cas d'échec du basculement. Si l'optionalité ne peut pas être exercée en toute sécurité, le défaut hébergé comporte plus de verrouillage que son interface simple ne le suggère.

Les réseaux critiques ont besoin d'un choix basé sur les conséquences

Il n'y a pas de modèle de déploiement unique correct pour chaque détenteur. Le choix doit dépendre de la conséquence d'être incapable de changer une autorisation, de la complexité du routage et de la capacité de l'organisation à exploiter une CA.

Un petit fournisseur avec quelques préfixes stables et une origine unique peut rationnellement utiliser le service hébergé. Le RIR peut protéger les clés, renouveler les objets et exploiter la publication de manière plus fiable que le fournisseur. La délégation pourrait ajouter des modes de défaillance sans gain significatif. Le fournisseur devrait néanmoins exporter son inventaire de ROA, maintenir des contacts d'urgence et comprendre les conditions de résiliation.

Un opérateur multi-RIR avec des changements de routage fréquents, des origines multiples, des clients et une atténuation automatisée a un argument plus fort pour la signature déléguée. Il peut intégrer l'autorisation aux changements de réseau approuvés, garder une surface de contrôle unique à travers les parents et réduire la dépendance à plusieurs portails. La publication hybride peut éviter d'exploiter de nombreux dépôts publics.

Les réseaux du secteur public exigent une attention particulière. Les hôpitaux, les communications d'urgence, les systèmes fiscaux, les nuages publics et les réseaux de recherche peuvent subir un préjudice disproportionné en cas de fragmentation de la joignabilité. Cela ne signifie pas que chaque agence doit s'auto-héberger. Cela signifie que le modèle choisi doit avoir des objectifs de continuité explicites, une récupération d'accès testée, plus d'un administrateur formé et un chemin d'escalade préétabli avec le parent.

La responsabilité en aval compte également. Un détenteur direct peut créer des ROA pour des clients qui ne peuvent pas participer directement à un service RIR. Si un seul compte hébergé contrôle de nombreuses origines en aval, la suspension ou la prise de contrôle du compte a un rayon d'impact plus large. Les sous-CA déléguées peuvent répartir le contrôle, mais seulement là où le parent et le détenteur peuvent les soutenir en toute sécurité.

Les conseils d'administration devraient poser une question simple: si le fournisseur actuel ou la CA locale devenait indisponible pendant un changement de routage, comment l'autorisation valide serait-elle rétablie? La réponse devrait nommer les personnes, les clés, les contacts du parent, les chemins de publication et le délai maximum tolérable. Un modèle choisi uniquement parce que son écran de configuration était facile n'a pas réussi ce test.

La gouvernance des membres devrait façonner le défaut

Les RIR ne sont pas des fournisseurs de logiciels ordinaires. Ils coordonnent des ressources uniques au sein d'institutions régionales régies par la communauté. Leurs conditions de RPKI hébergé peuvent affecter des membres qui ne peuvent pas emporter les mêmes adresses chez un parent concurrent. Cela place la responsabilité de l'adhésion au cœur de la conception du service.

Les membres devraient approuver ou examiner les catégories d'événements qui permettent la révocation, le préavis attaché à chaque catégorie, le traitement des comptes contestés et le chemin de sortie vers le service délégué. Les communautés techniques devraient examiner les pratiques de certificat et de dépôt; les communautés juridiques et de gouvernance devraient examiner le langage de résiliation et de responsabilité. Aucune discipline n'est suffisante à elle seule.

Le défaut devrait être le mode hébergé parce que l'adoption importe, et non parce que la concentration institutionnelle est invisible. Lors de l'inscription, l'utilisateur devrait recevoir une comparaison claire des contrôles. Le mode hébergé signifie que le fournisseur gère la clé et le dépôt. Le mode délégué signifie que le détenteur gère la clé et peut-être la publication. Le mode hybride divise ces tâches. Tous restent sous le certificat parent.

Les utilisateurs ne devraient pas avoir besoin de prouver un statut exceptionnel pour choisir la délégation s'ils satisfont aux exigences techniques publiées. Un conseil d'administration ne devrait pas non plus imposer la délégation aux membres incapables d'opérer en toute sécurité. Les frais de service devraient refléter le coût réel sans tarifer l'indépendance cryptographique comme un luxe réservé aux grands acteurs historiques.

Les modifications des conditions méritent un préavis à la communauté, sauf si une sécurité urgente ou la loi le rend impossible. Les conditions 2026 du RIPE NCC, par exemple, définissent la garde hébergée et déléguée et précisent les conditions de révocation. Une clarté comparable devrait être disponible dans chaque région, même lorsque la règle exacte diffère.

L'institution devrait publier les classes d'incidents et les performances de restauration. Les membres ne peuvent pas juger si l'accord de commodité reste solide s'ils ne connaissent que la disponibilité du service. Un portail peut être disponible alors qu'un détenteur est à tort incapable de modifier les objets; un dépôt peut être accessible alors qu'une erreur d'enregistrement a supprimé les bons.

Les contrats doivent distinguer l'usage abusif du désaccord

Des clauses de résiliation larges protègent les fournisseurs contre la fraude, la compromission et l'utilisation illégale. Elles peuvent également combiner des litiges sans rapport avec la continuité de la certification. Une facture impayée, une question sur un document d'entreprise, une allégation d'abus et une clé privée volée ne présentent pas le même risque de routage.

Les conditions de service doivent les séparer. Une compromission confirmée de la clé peut nécessiter une révocation immédiate. La perte du droit après un transfert achevé nécessite un changement rapide de certificat. Une suspicion de prise de contrôle de compte appelle un gel des nouvelles signatures, une réauthentification forte et la préservation des objets valides existants lorsque cela est sûr. Un frais contesté peut justifier des recours de service, mais la destruction automatique des autorisations de route devrait être un dernier recours si la ressource reste enregistrée au nom du détenteur.

Cette distinction ne crée pas un droit inconditionnel à la certification. Elle aligne le remède sur la menace. Le RPKI ne devrait pas devenir un mécanisme général de recouvrement simplement parce qu'il est efficace. Un RIR ne devrait pas non plus continuer à signer pour une partie qui ne détient plus la ressource.

Les raisons écrites importent le plus pour les utilisateurs hébergés car ils ne peuvent pas agir autour du fournisseur. L'avis doit indiquer si la restriction affecte l'accès au portail, la création de nouveaux objets, la publication, la portée du certificat ou l'ensemble de la CA. Un gel d'accès temporaire est différent d'une révocation, et les utilisateurs ont besoin de savoir quelle condition s'applique.

La révision doit être assez rapide pour les opérations de routage. Un réviseur technique peut d'abord vérifier l'identité, la portée des ressources et la différence des objets. Un réviseur contractuel distinct peut décider du litige sous-jacent. Un contact d'urgence doit être disponible en dehors des heures de bureau habituelles en cas d'impact généralisé sur la validation.

Les conditions de responsabilité devraient également refléter le contrôle attribué. L'utilisateur hébergé est responsable des instructions incorrectes et de la sécurité des informations d'identification. Le fournisseur est responsable de la mise en œuvre fidèle des instructions acceptées, de la protection de la clé sous sa garde et du respect du processus de révocation publié. Les réseaux distants restent responsables de leur propre politique de routage. Une division claire est plus crédible qu'une clause impliquant que chaque conséquence incombe à la partie la plus faible.

La continuité a besoin de répétitions, pas d'une page de politique

Un opérateur devrait tester sa récupération RPKI avant une crise. L'exercice peut commencer sans modifier les objets publics. Les équipes devraient lister les préfixes actuels, les AS d'origine, les longueurs maximales, les CA parentes, les configurations hébergées, les enfants délégués et les fournisseurs de publication. Elles devraient comparer cet inventaire avec les annonces BGP réelles et les charges utiles validées.

Les utilisateurs hébergés devraient vérifier qu'au moins deux personnes autorisées peuvent accéder au service avec des informations d'identification indépendantes. Les contacts opérationnels et juridiques doivent être à jour. L'équipe doit savoir comment joindre le RIR lorsque l'accès normal échoue et comment l'identité sera rétablie. Elle doit conserver une copie lisible par machine des autorisations prévues.

Les utilisateurs délégués devraient tester la sauvegarde et la restauration des clés dans un environnement isolé, surveiller le renouvellement des certificats, valider les manifestes et les listes de révocation, et observer la publication depuis l'extérieur de leur propre réseau. Plus d'une personne doit comprendre les échanges avec le parent et le dépôt. La documentation doit survivre à une acquisition ou à un départ de personnel.

Les utilisateurs hybrides devraient tester les deux moitiés. Une signature locale réussie ne suffit pas si le service de publication rejette l'objet. Ils doivent savoir distinguer une panne de CA d'une panne de dépôt et si un dépôt alternatif peut être établi sous le parent à temps.

Tous les utilisateurs devraient répéter un changement d'AS d'origine. Le test devrait inclure la création de la nouvelle autorisation avant le changement de route, son observation à travers des validateurs indépendants, l'application des changements BGP, la vérification de l'état de validation et le retrait de l'autorisation obsolète après convergence. Lorsqu'un test en direct est dangereux, un environnement de test régional peut révéler les défaillances de processus.

Le résultat devrait être un objectif de continuité exprimé en heures, pas en adjectifs. Différentes organisations choisiront des tolérances différentes. L'exercice est réussi lorsqu'il révèle la dépendance exacte qui contrôle la récupération et attribue un propriétaire pour la corriger.

Les parties utilisatrices complètent le tableau des risques

Le détenteur de ressources et le RIR ne décident pas seuls de la joignabilité. Les parties utilisatrices récupèrent et valident le matériel RPKI. Les routeurs reçoivent les charges utiles validées et appliquent une politique locale. Cette conception distribuée limite le commandement central, mais elle rend également les conséquences inégales.

Si une CA hébergée disparaît et qu'aucune autorisation couvrante ne subsiste, une route précédemment Valide peut devenir NotFound. De nombreux réseaux continuent d'accepter NotFound. Si une autorisation couvrante survivante entre en conflit avec la route, elle peut devenir Invalide, et les réseaux qui rejettent Invalide peuvent la supprimer. Les caches et le calendrier de rafraîchissement font que le changement apparaît à des moments différents.

Les opérateurs ne doivent pas supposer que la disponibilité du dépôt ou la révocation de certificat produit un résultat mondial immédiat unique. Le document d'APNIC sur la disponibilité met en garde contre une confiance dans le RPKI plus forte que ce que l'architecture prévoit, comme exiger des ROA des clients et rejeter toute route non couverte par une ROA sans tenir compte des caractéristiques de disponibilité.

Cette prudence n'affaiblit pas l'argument en faveur de la validation d'origine. Elle appelle à une sécurité en couches. Les réseaux peuvent combiner le RPKI avec des contrats clients, des filtres de route, des données de l'Internet Routing Registry, une vérification directe et des exceptions d'urgence régies par des contrôles stricts. Une exception ne devrait pas devenir silencieusement une acceptation permanente de mauvaises données de routage.

La diversité des parties utilisatrices peut également aider à la récupération. Les détenteurs et les RIR devraient observer plus d'une implémentation de validateur et point de vue avant de déclarer un basculement terminé. Un dépôt peut sembler sain en local alors que les validateurs distants ne peuvent pas le récupérer. Un objet signé peut être présent mais rejeté pour revendication excessive ou matériel de support obsolète.

Le piège de la commodité est donc visible des deux côtés. Les producteurs peuvent devenir dépendants d'un seul fournisseur de signature. Les consommateurs peuvent devenir dépendants d'une seule classe de données de validation sans plan pour sa perte temporaire. Une sécurité de routage mature garde le RPKI autoritaire sur ce qu'il peut prouver tout en refusant de le traiter comme la seule preuve disponible dans chaque urgence.

Un meilleur accord hébergé a des conditions concrètes

Le modèle hébergé peut être amélioré sans le rendre lourd. La première réforme est un enregistrement de séquestre d'objets: une liste signée, exportable en continu, des intentions de routage actuelles, des ressources certifiées et des identifiants de publication. Elle n'exposerait pas la clé privée hébergée. Elle permettrait au détenteur de reconstruire des autorisations équivalentes sous une CA de remplacement.

La deuxième est une échelle de révocation. Les problèmes de compte à faible risque devraient restreindre les modifications tout en préservant les objets existants lorsque cela est sûr. Les événements d'enregistrement à plus haut risque devraient produire un préavis et une transition. Une compromission confirmée peut déclencher une révocation immédiate et une récupération de clé propre. Chaque barreau devrait avoir une approbation et une révision nommées.

La troisième est une inscription portable. Un utilisateur choisissant la délégation devrait pouvoir préparer l'échange d'identité, la publication et les objets équivalents avant que la CA hébergée ne soit supprimée, sous réserve de garanties contre un chevauchement incontrôlé. Les services régionaux qui ne peuvent pas soutenir cela devraient publier l'écart exact et un plan pour le réduire.

La quatrième est une confirmation indépendante pour les actions destructrices. La révocation d'une CA hébergée entière, la suppression de toutes les configurations ou la réduction des ressources certifiées devraient nécessiter un double contrôle, sauf lorsqu'un renouvellement automatisé ou un transfert préautorisé suit un événement vérifié. Le système devrait montrer l'effet attendu sur les annonces connues avant l'exécution.

La cinquième est un rapport de service qui mesure plus que la disponibilité. Les RIR devraient signaler les erreurs d'enregistrement ayant un impact sur les certificats, les migrations échouées, les révocations d'urgence, le temps de restauration et la performance de notification. Les petits nombres devraient être divulgués avec soin, sans prétendre soutenir des taux mondiaux.

La sixième est un recours étroit. Si l'erreur du fournisseur supprime une autorisation valide, il devrait offrir une restauration immédiate, un soutien spécialisé, un enregistrement d'incident préservé et une révision indépendante. Un échec répété grave devrait atteindre le conseil d'administration et les membres, et ne pas rester un ticket de support privé.

Ces garanties rendent le RPKI hébergé plus commode, et non moins. Elles réduisent la quantité de négociation sur mesure requise lorsque les hypothèses normales échouent.

Ce que peut ajouter la Number Resource Society

La Number Resource Society se présente comme un défenseur de l'enregistrement exact, des droits des détenteurs, de la participation et de la réduction des barrières bureaucratiques. Le RPKI hébergé est un endroit approprié pour transformer ces principes en un service mesurable pour les membres.

NRS pourrait publier un registre de choix de déploiement comparant les cinq RIR. Il devrait indiquer qui détient la clé privée, si le service délégué est disponible, si la publication par le parent est proposée, comment fonctionne la migration, quels motifs de révocation sont publiés, quel préavis s'applique et où un détenteur peut demander une révision. Chaque entrée devrait renvoyer au document RIR pertinent et mentionner les questions non résolues.

Il pourrait maintenir trois exercices de continuité: un pour les utilisateurs hébergés, un pour les CA déléguées et un pour la publication hybride. L'exercice hébergé testerait la récupération d'accès et l'exportation de configuration. L'exercice délégué testerait les clés, les manifestes, l'échange avec le parent et la succession. L'exercice hybride testerait la signature locale par rapport à la publication distante. Les résultats pourraient rester privés pour le entité tandis que les thèmes d'échec communs sont publiés sans taux non étayés.

NRS pourrait également amener les petits opérateurs dans les discussions de politique régionale. Les grands réseaux peuvent évaluer les logiciels de CA et négocier un soutien urgent par le biais de relations établies. Un fournisseur rural ou un réseau à but non lucratif peut ne pas savoir que l'accès au portail, la portée du certificat et la publication des objets sont des contrôles distincts. Des questions simples lors des réunions des membres peuvent améliorer le service pour tous.

La contribution devrait rester limitée. Le plaidoyer de NRS n'établit pas qu'il est une ancre de confiance RPKI, une autorité de certification, un opérateur de dépôt ou un arbitre neutre. Il ne devrait pas impliquer que chaque détenteur peut s'auto-héberger en toute sécurité ou que le service RIR est intrinsèquement suspect. Son rôle utile est de rendre le choix éclairé, la sortie pratique et la responsabilité comparable.

Une critique institutionnelle positive est plus durable que la suspicion. Un registre qui loue une conception de transition solide et identifie un préavis faible peut donner aux conseils d'administration des RIR une liste d'améliorations pratiques. Il peut également montrer aux opérateurs quand le service hébergé est le choix responsable, plutôt que de traiter la garde des clés locale comme un insigne de statut.

Les objections courantes manquent la question de l'allocation

Les défenseurs du RPKI hébergé disent souvent que les RIR contrôlent déjà l'enregistrement, de sorte que les clés déléguées n'ajoutent pas grand-chose. La prémisse est en partie correcte: le parent peut restreindre ou révoquer un certificat délégué. La conclusion est fausse. Le contrôle de la clé enfant empêche toujours le parent de signer les intentions de routage de l'enfant et permet à l'opérateur de faire des changements sans l'interface hébergée. La séparation n'efface pas la hiérarchie; elle réduit la concentration à l'intérieur de celle-ci.

Les critiques disent que le service hébergé n'est pas sûr parce que le RIR détient la clé. C'est également trop général. Un RIR bien géré peut protéger les clés, renouveler les objets et publier les dépôts de manière plus fiable que de nombreux membres. La question pertinente est de savoir si ses contrôles de sécurité, d'autorisation et de récupération correspondent à la concentration de pouvoir.

Une autre objection est que la migration parallèle affaiblit l'unicité. Cela peut être le cas si elle est mal conçue. Un chevauchement court et contrôlé pour des autorisations équivalentes est différent d'une certification concurrente indéfinie. Lorsque même un court chevauchement est inacceptable, un basculement programmé et une restauration rapide restent possibles.

Certains soutiennent que la politique locale des parties utilisatrices rend la continuité du producteur moins urgente. La politique locale adoucit ou varie la conséquence, certes. Elle ne peut pas recréer une autorisation valide manquante, et elle n'empêche pas une perte de joignabilité sélective. Les producteurs ont toujours besoin de preuves exactes et continues.

Enfin, certains membres diront que les options sophistiquées augmentent les frais pour tout le monde. Les communautés régionales peuvent garder le service hébergé simple tout en facturant un coût supplémentaire transparent pour le soutien délégué ou la publication. Les garanties essentielles - raisons, préavis, exportation et restauration - ne sont pas des fonctionnalités de luxe. Ce sont des obligations de base d'un service lié à des ressources uniques.

Chaque objection devient plus claire lorsqu'elle est formulée en termes d'allocation. Quelle partie contrôle le risque, quelle partie peut le prévenir et quelle partie peut récupérer? Les modèles hébergés et délégués doivent être jugés par ces réponses plutôt que par une préférence idéologique pour une opération centrale ou locale.

Les preuves devraient s'améliorer avant que la confiance ne devienne absolue

Le matériel public explique les architectures, les conditions et les incidents individuels, mais il ne fournit pas un dossier complet entre RIR des CA hébergées révoquées, des migrations échouées, des modifications bloquées, des temps de restauration ou des effets de route. Les pages de service divulguent les capacités, pas chaque résultat opérationnel. Les cas de support privés et les événements de sécurité ne sont pas tous publics, à juste titre.

Cela limite les affirmations empiriques. Il n'est pas possible d'estimer une probabilité globale que le RPKI hébergé cause une perte de route. Les preuves publiques ne peuvent pas non plus prouver que l'opération déléguée est plus fiable pour tous les détenteurs. Les modèles de service régionaux et les chemins de contrôle sont observables; les taux de défaillance comparatifs ne le sont pas.

Les rapports des RIR peuvent combler une partie de l'écart. Ils devraient distinguer l'indisponibilité du portail, l'échec de signature, l'indisponibilité du dépôt, l'erreur de certificat parent, la mauvaise configuration de l'utilisateur et la résiliation involontaire. Ils devraient enregistrer si les objets actuels sont restés valides, si l'état de route a changé et combien de temps la restauration a pris.

Les opérateurs peuvent contribuer des comptes rendus anonymisés avec des chronologies vérifiables. Les chercheurs peuvent observer les changements de certificats et d'objets publics, mais devraient éviter de déduire une intention de la seule disparition. Un transfert, un basculement de clés ou un retrait délibéré de ROA peut ressembler à un échec vu de l'extérieur.

La confiance devrait donc être la plus forte sur l'architecture et plus faible sur la prévalence. Le service hébergé concentre les contrôles nommés. Le service délégué redistribue certains d'entre eux. Les deux restent sous un parent RIR. Ce sont des faits documentés. La fréquence à laquelle chaque arrangement cause un préjudice matériel reste insuffisamment mesurée.

Un programme de gouvernance qui admet cette limite est plus crédible que celui qui sélectionne quelques pannes ou chiffres de disponibilité pour prouver un cas universel. De meilleures preuves permettront aux communautés futures d'ajuster le défaut sans conjectures.

La commodité devrait être réversible

Le RPKI hébergé a fait ce que fait souvent une bonne infrastructure: il a rendu ordinaire une pratique de sécurité difficile. Les opérateurs peuvent créer des autorisations de route sans construire de CA, gérer des manifestes ou défendre un dépôt public. Cette réalisation devrait être préservée.

Le danger apparaît lorsque la facilité d'entrée est associée à l'absence de sortie sûre. Si le registre détient la clé, publie les objets, modifie la portée du certificat et contrôle la réinscription, un litige ou une erreur peut laisser l'opérateur incapable de maintenir sa propre intention de routage. Une disponibilité normale élevée ne supprime pas cette dépendance structurelle.

Le RPKI délégué fournit un contrepoids significatif. Le détenteur signe avec sa propre clé, peut automatiser les changements locaux et gérer plusieurs parents de manière cohérente. La publication hybride réduit la charge. Aucune option n'élimine la CA parente ou les devoirs d'une exploitation fiable.

Le compromis mature est la pluralité. Le service hébergé reste le défaut pour les utilisateurs simples. La signature déléguée est un droit standard pour les détenteurs capables. La publication par le parent est disponible comme voie médiane. La migration est testée et, lorsque cela est sûr, de type « make-before-break ». Les motifs de révocation sont précis, les litiges ordinaires ne déclenchent pas de conséquences de routage disproportionnées, et l'action d'urgence comporte une révision et une récupération rapides.

La commodité n'est pas l'opposé du contrôle. C'est une façon d'emprunter le contrôle d'une autre institution pour une opération de routine. L'accord n'est solide que lorsque l'emprunteur peut voir les conditions, récupérer ses intentions, choisir un arrangement différent et récupérer lorsque le prêteur de commodité commet une erreur.

Le RPKI demande aux réseaux de s'appuyer sur des déclarations cryptographiques. Sa gouvernance devrait appliquer la même discipline aux promesses institutionnelles. Qui détient la clé, qui peut révoquer, qui publie et qui restaure devrait être aussi clair que le préfixe et l'AS d'origine dans une ROA. Lorsque ces réponses sont explicites et réversibles, le service hébergé est une rampe d'accès. Lorsqu'elles sont cachées et inéluctables, c'est un piège.

Sources