Résumé
- Un transfert comporte au moins trois horloges: l'accord commercial, le changement de titulaire dans le registre et l'état RPKI perçu par chaque partie utilisatrice. Déclarer le succès sur une seule horloge peut laisser la route du destinataire invalide ou l'ancien AS d'origine du cédant autorisé cryptographiquement.
- Une ROA autorise un AS d'origine pour des préfixes et des longueurs maximales spécifiés. Elle n'est ni un instrument de transfert ni une déclaration complète de contrôle opérationnel, mais la validation d'origine de route peut rendre sa survie ou sa disparition immédiatement conséquente pour l'accessibilité.
- La RFC 6480 a établi la bonne direction en 2012: établir avant de rompre. Avant de révoquer une ancienne ROA, une autre ROA valide doit couvrir la route destinée à rester accessible, et l'origine prévue doit effectivement l'annoncer.
- Lors d'un transfert coopératif, le cédant peut créer une autorisation de pont temporaire pour l'AS d'origine prévu du destinataire, car le numéro d'AS autorisé n'a pas besoin d'appartenir au titulaire signataire. Le destinataire doit ensuite créer une ROA équivalente sous son propre nouveau certificat avant que ce pont ne soit retiré.
- Une passation sûre nécessite un enregistrement d'événement verrouillé contenant les ressources exactes, les origines prévues, les longueurs maximales, les anciens et nouveaux chemins de certification, le point effectif, les observations requises et l'autorité d'abandon. L'achèvement de l'enregistrement, la publication et la révocation doivent être indivisibles du point de vue des parties, même si les caches mondiaux ne peuvent pas se mettre à jour simultanément.
- Le chevauchement n'est utile que lorsqu'il est explicite, étroit et temporaire. Une ancienne autorisation qui subsiste après le transfert sans objectif de pont déclaré crée un pouvoir résiduel; un écart entre l'ancienne révocation et la nouvelle validation peut faire passer une route de Valide à Invalide ou NotFound selon ce que chaque partie utilisatrice a récupéré.
- Plusieurs validateurs et points d'observation doivent confirmer à la fois les faits positifs et négatifs: la nouvelle charge utile est visible via l'ancre de confiance attendue, l'ancienne charge utile n'est plus valide, l'origine BGP en direct correspond à l'état autorisé et aucune autorisation de couverture inattendue ne modifie le résultat.
- Une Société des ressources numériques peut contribuer positivement en définissant un reçu de passation portable, des preuves minimales, des règles d'observation indépendante et de responsabilité entre les fournisseurs. Elle ne devrait pas prétendre qu'une période d'attente universelle rend chaque transfert sûr; le timing des dépôts, le fonctionnement hébergé ou délégué et la coordination interrégionale diffèrent.
Un transfert échoue dans l'intervalle entre les horloges institutionnelles
Le transfert le plus simple à décrire est instantané. Une organisation cesse de détenir un préfixe, une autre devient le titulaire reconnu et le bon AS d'origine apparaît dans le routage. L'événement réel est réparti entre des institutions et des machines qui ne partagent pas la même horloge. Un contrat peut entrer en vigueur à minuit. Un agent du registre peut approuver le changement de titulaire plus tard. Une autorité de certification peut émettre un nouveau certificat de ressources et révoquer un ancien lors d'une action de publication distincte. Les parties utilisatrices récupèrent ces objets selon leurs propres calendriers.
Les routeurs reçoivent des charges utiles validées à partir de caches locaux et appliquent une politique locale.
Cette séquence crée deux risques opposés. La rupture avant l'établissement survient lorsque l'autorisation du cédant est retirée avant qu'une alternative pour la route prévue ne soit devenue valide et visible. Si une autorisation de couverture existe toujours pour une autre origine, la nouvelle annonce peut être Invalide. Si aucune charge utile validée de couverture ne subsiste, la route peut être à la place NotFound. Les opérateurs traitent ces états différemment, de sorte que la même transition peut préserver l'accessibilité dans un réseau et la perdre dans un autre.
L'établissement sans rupture est l'image miroir. Le destinataire reçoit un certificat et publie la nouvelle autorisation, mais l'ancienne autorisation du cédant reste valide plus longtemps que ne l'exige la passation. Les deux AS d'origine peuvent alors produire des routes qui passent la validation d'origine. RPKI ne choisit pas entre deux origines autorisées séparément simplement parce que la transaction commerciale est terminée. L'ancien chemin peut survivre dans certains caches après avoir disparu d'autres, prolongeant le désaccord au-delà de l'heure effective déclarée par le registre.
La question déterminante n'est donc pas de savoir si un formulaire de transfert a été approuvé. Il s'agit de savoir si l'autorité a été transférée selon une séquence contrôlée sans écart inexpliqué et sans résidu inexpliqué. Un registre qui enregistre l'identité du titulaire et une autorité de certification qui modifie l'autorité cryptographique participent à un seul événement important. Leurs contrôles devraient être conçus en conséquence.
Une ROA prouve moins qu'un transfert et importe plus qu'une note de bas de page
Une autorisation d'origine de route est une déclaration signée selon laquelle un système autonome est autorisé à annoncer des routes pour un ou plusieurs préfixes, sous réserve de toute valeur de longueur maximale. Sa validité dépend de l'objet signé, de son certificat d'entité finale, de la chaîne de certification de l'émetteur, des manifestes, des informations de révocation et de l'ancre de confiance acceptée par la partie utilisatrice. Le profil actuel est défini dans la RFC 9582, s'appuyant sur l'architecture RPKI établie en 2012.
La déclaration est délibérément étroite. Elle ne transmet pas le préfixe, ne règle pas le paiement, n'identifie pas tous les intérêts bénéficiaires et ne prouve pas que l'AS nommé annonce actuellement une route. Un vendeur peut autoriser l'ASN de l'acheteur ou du fournisseur avant un transfert, car l'ASN d'origine n'a pas besoin d'être contenu dans le certificat de ressources du titulaire signataire. Inversement, un acheteur peut détenir le préfixe mais utiliser un réseau tiers comme origine autorisée.
L'étroitesse ne rend pas l'objet périphérique. La validation d'origine de route transforme les charges utiles de ROA valides en entrées pour la politique de routage. Un réseau rejetant les routes invalides peut cesser d'accepter une annonce lorsque l'autorisation correspondante change. Une autorisation périmée peut permettre à une origine qui aurait dû perdre sa permission de conserver une classification Valide. L'objet n'est pas un titre, mais c'est une déclaration opérationnellement puissante provenant de l'institution qui reconnaît le titulaire.
Cette distinction devrait discipliner les deux côtés du marché des transferts. Les acheteurs ne devraient pas supposer que recevoir l'enregistrement préserve automatiquement toutes les autorisations de routage. Les vendeurs ne devraient pas supposer que l'accord de vente éteint automatiquement un ancien objet signé partout. Les registres ne devraient pas décrire les mises à jour automatiques de certificats comme l'intégralité de la continuité. Les validateurs ne devraient pas déduire la légitimité de la transaction; ils ne peuvent évaluer que les chemins de certification et les charges utiles qu'ils reçoivent.
La passation doit relier la revendication cryptographique étroite à l'événement plus large sans demander à l'une de se faire passer pour l'autre. L'instrument de transfert fournit l'autorité pour le changement de titulaire. L'action d'enregistrement modifie qui peut contrôler la certification des ressources. La ROA autorise la route prévue. Une transaction sûre prouve que ces actes connexes se sont produits dans le bon ordre.
Valide, Invalide et NotFound sont des résultats de transition, pas des verdicts moraux
La validation d'origine compare une annonce BGP avec des charges utiles validées. Une route est Valide lorsqu'une charge utile couvre le préfixe annoncé, permet sa longueur et nomme l'AS d'origine observé. Elle est Invalide lorsque des charges utiles de couverture pertinentes existent mais qu'aucune n'autorise cette combinaison. Elle est NotFound lorsqu'aucune charge utile validée ne couvre l'annonce. Ces catégories expriment une comparaison, pas un jugement sur la propriété, la fraude ou le mérite commercial.
Pendant le transfert, la distinction devient un outil de diagnostic. Supposons que l'ancienne ROA autorise AS-A et que le destinataire ait l'intention d'annoncer depuis AS-B. Si AS-B commence alors que les validateurs ne détiennent toujours que la charge utile AS-A, sa route est Invalide. Si l'ancienne charge utile a disparu et que la charge utile AS-B n'est pas arrivée, la route est NotFound. Si les deux charges utiles sont présentes, les deux origines peuvent être Valides.
Si le destinataire continue d'utiliser AS-A par le biais d'un accord de transit commun, la route peut rester Valide même si l'autorité du titulaire a changé, mais la continuité opérationnelle devrait être déclarée plutôt que devinée.
Aucune observation unique ne prouve l'état global. Une partie utilisatrice peut avoir récupéré un nouveau delta RRDP. Une autre peut utiliser un cache valide antérieur après une défaillance du dépôt. Une troisième peut obtenir des données par un transport différent ou rejeter un point de publication après des vérifications de manifeste. Leur logiciel peut également différer dans la façon de gérer une condition de dépôt exceptionnelle dans les limites laissées à la politique locale. Un transfert peut donc produire une mosaïque temporaire de résultats.
La réponse correcte n'est pas de promettre une simultanéité universelle. C'est de définir des états de transition acceptables et de les mesurer. Un chevauchement planifié dans lequel AS-A et AS-B sont tous deux valides peut être acceptable pour un court pont déclaré. Un chevauchement inexpliqué après que l'autorité du cédant aurait dû prendre fin ne l'est pas. Un court intervalle NotFound peut préserver l'accessibilité dans les réseaux qui rejettent uniquement les routes invalides, mais il s'agit tout de même d'un échec de continuité de l'autorisation. Un intervalle Invalide est plus critique, en particulier lorsque le filtrage est appliqué.
La gouvernance commence par nommer ces états avec précision. Elle attribue ensuite la responsabilité de prévenir, d'observer et de clore chacun d'eux.
L'architecture de 2012 a déjà fourni le verbe directeur: établir avant de rompre
La RFC 6480 ne traite pas la révocation de la ROA comme une suppression administrative. Elle avertit que la révocation peut amener les parties utilisatrices à considérer les annonces associées comme non autorisées et potentiellement modifier le comportement de transfert. Elle indique donc aux détenteurs de ressources de suivre le principe « établir avant de rompre »: s'assurer qu'une autre ROA valide existe pour le préfixe, s'assurer que l'AS nommé par l'alternative annonce effectivement les annonces prévues, et exiger que les parties utilisatrices récupèrent de nouveaux objets avant d'agir sur la révocation.
Cette séquence reste le point de départ solide. Sa signification est facile à obscurcir dans les interfaces modernes où un utilisateur clique sur un contrôle de transfert ou de certificat et le service met à jour plusieurs objets. L'automatisation peut exécuter le principe, mais elle ne l'abroge pas. L'existence d'un contrôle web marqué comme terminé ne dit rien sur le moment où des validateurs indépendants ont observé le remplacement et la révocation.
Le principe « établir avant de rompre » est également plus précis que de simplement laisser l'ancienne ROA en ligne pendant une période de grâce arbitraire. Ce qui doit être établi est une alternative valide correspondant à la route qui sera effectivement annoncée. Un remplacement avec le mauvais ASN d'origine, un préfixe trop étroit, une longueur maximale inadaptée ou un chemin de certification invalide ne satisfait pas la condition. Pas plus qu'un objet correct qui a été généré mais pas publié de manière cohérente.
Ce qui doit être rompu est l'ancienne autorité, pas simplement un nom de fichier. La révocation standard implique le certificat d'entité finale, les informations de révocation actuelles et la suppression de l'objet obsolète. Si la ressource elle-même quitte un ancien certificat de ressources, l'ancienne chaîne ne doit plus valider cette autorité. Les manifestes doivent décrire le point de publication actuel avec précision. L'état résultant doit être consommable par les parties utilisatrices plutôt que visible uniquement à l'intérieur du service émetteur.
L'expression devrait donc être lue comme une règle institutionnelle: établir une autorité successeur utilisable, l'observer indépendamment, puis éteindre l'autorité prédécesseur et observer cette extinction. Un transfert est inachevé tant que les deux moitiés ne sont pas attestées.
Le changement d'enregistrement et le changement de route sont des événements liés, pas le même événement
Un transfert peut conserver le même AS d'origine. Une entreprise peut acheter un bloc d'adresses mais continuer à utiliser temporairement le réseau du vendeur. Une réorganisation de groupe peut changer l'organisation enregistrée tandis que le réseau opérationnel reste constant. Une vente intermédiée peut nécessiter un nouveau titulaire mais utiliser un fournisseur de transit établi avant que le destinataire n'ait son propre ASN. Dans chaque cas, l'enregistrement change tandis que la route peut ne pas changer.
L'inverse peut également se produire. La route prévue peut passer de AS-A à AS-B avant que le transfert légal ne prenne effet, le titulaire existant autorisant AS-B pour une période de migration. Il s'agit d'une délégation opérationnelle, pas d'une preuve que la ressource a déjà été transférée. Traiter le changement d'origine comme un changement de titulaire reviendrait à mal interpréter ce que dit une ROA.
Une passation sûre nécessite donc deux plans liés. Le plan d'enregistrement identifie le cédant, le destinataire, les ressources exactes, la politique applicable, les preuves, la condition effective et l'autorité pour approuver ou restreindre le changement. Le plan d'autorité de routage identifie chaque préfixe prévu et sa longueur maximale, l'origine avant et après, toute relation de fournisseur, l'objet à créer et le point auquel l'ancienne autorité devrait prendre fin. Si aucun changement de route n'est prévu, le plan le dit et teste la continuité de l'origine existante sous le certificat du nouveau titulaire.
Le lien est important car un plan peut invalider les hypothèses de l'autre. Un certificat peut changer automatiquement lorsque l'objet d'organisation du registre change. La documentation du RIPE NCC indique qu'une ressource déplacée ou transférée modifie le certificat, supprime les ROA sous-jacentes et nécessite leur recréation. Un acheteur qui n'avait prévu que l'enregistrement peut donc découvrir qu'une route continue a perdu sa base de validation. Un ingénieur de routage qui a préparé une nouvelle ROA sans connaître le point d'enregistrement effectif peut découvrir que le destinataire ne peut pas encore signer pour le préfixe.
L'enregistrement de l'événement ne devrait pas réduire ces actes à une seule étiquette de statut. Il devrait montrer que l'enregistrement a été autorisé, que l'autorité de route successeur a été préparée, que la publication a été observée, que l'autorité prédécesseur a été retirée et que la route en direct correspondait à l'état prévu.
Un transfert coopératif peut utiliser un pont sans renoncer à la finalité
Le dispositif de continuité le plus utile est une ROA de pont étroitement définie. Avant l'achèvement du transfert, le titulaire actuel peut autoriser l'AS d'origine prévu du destinataire. Cet objet est légitime car une ROA lie un préfixe à un ASN d'origine; le signataire n'a pas besoin de détenir l'ASN. Le destinataire ou son réseau peut alors commencer ou préparer l'annonce prévue pendant que l'ancien chemin de certification existe toujours.
Le pont ne résout que la première moitié. Une fois que le destinataire devient le titulaire reconnu et reçoit l'autorité de certification pour la ressource, il doit publier une autorisation équivalente sous sa propre chaîne. Des validateurs indépendants doivent observer cette charge utile successeur. Le pont du cédant et toute autorisation pour son ancienne origine doivent ensuite être révoqués via l'ancienne chaîne à mesure que la ressource quitte ce certificat.
Cela crée un intervalle contrôlé dans lequel des autorisations équivalentes peuvent exister sous deux chaînes. L'équivalence devrait être testée champ par champ: famille d'adresses, préfixe, longueur maximale et ASN d'origine. Un pont qui permet des annonces plus spécifiques au-delà du plan convenu par le destinataire accorde une autorité supplémentaire. Un objet successeur qui omet un plus spécifique de production peut rendre cette route Invalide même lorsque l'agrégat reste Valide.
Le pont a également besoin d'une condition d'expiration en dehors de l'objet lui-même. Son enregistrement de gouvernance devrait indiquer qu'il existe uniquement pour la continuité de la transaction, identifier la référence du transfert, interdire les modifications non liées et exiger la révocation après la validation du successeur. Si le transfert ne s'achève pas, le titulaire actuel devrait pouvoir retirer le pont selon une procédure d'abandon définie.
Si le transfert s'achève mais que l'ancienne autorité ne peut pas être retirée, l'escalade devrait commencer immédiatement plutôt que de transformer un chevauchement temporaire en une commodité indéfinie.
Tous les transferts ne sont pas coopératifs. Un transfert ordonné par un tribunal, une vente pour insolvabilité ou une succession contestée peut rendre impossible l'action du titulaire précédent. Dans ces cas, le registre a besoin d'un chemin de continuité qui puisse émettre la nouvelle autorité du destinataire dans le cadre du changement effectif de titulaire et révoquer l'ancienne chaîne de manière cohérente. L'absence de pont accroît le besoin d'une préparation plus rigoureuse de la publication et d'une annulation explicite; cela ne justifie pas de prétendre que les caches se mettent à jour de manière atomique.
La passation a besoin d'une machine d'états, pas d'un email d'achèvement
Un événement crédible peut être représenté en six états. Le premier est l'intention déclarée. Les parties spécifient les ressources exactes, les schémas d'origine actuels et prévus, les longueurs maximales pertinentes, les anciens et nouveaux arrangements de certification, les autorités de contact et les preuves autorisant le transfert. Le registre renvoie une référence unique et gèle les modifications de certification conflictuelles pour les ressources concernées.
Le deuxième état est la préparation du successeur. Lorsque la coopération le permet, le cédant publie l'autorisation de pont. Le destinataire prépare son service de certification hébergé ou délégué, l'accès au dépôt et la configuration de la ROA. Des vérifications automatisées confirment que l'objet prévu serait valide s'il était émis sous le certificat de ressources attendu.
Le troisième état est la préparation de la route. L'observation confirme que l'origine prévue annonce les routes exactes attendues, ou que l'origine existante continuera. Cela ne nécessite pas de déplacer prématurément le trafic; cela nécessite des preuves que le plan opérationnel et les autorisations proposées concordent. Les erreurs de longueur de préfixe et d'ASN d'origine doivent être corrigées avant le changement d'autorité.
Le quatrième état est le transfert effectif. Le registre change le titulaire reconnu, la hiérarchie d'émission met à jour les certificats de ressources et l'autorisation successeur est publiée avec le manifeste actuel et le matériel de révocation. Pour un transfert interrégional, les actions source et destination nécessitent une référence d'événement commune et des conditions de libération et d'acceptation convenues, même si elles se produisent sous différentes ancres de confiance.
Le cinquième état est le retrait du prédécesseur. L'ancien certificat de ressources ne peut plus valider l'autorité pour la ressource transférée, les certificats d'entité finale pertinents sont révoqués, les objets obsolètes sont retirés et l'ancien manifeste décrit le nouvel état de publication. Les informations d'identification du cédant ne permettent plus de nouvelles actions de certification pour le préfixe.
Le sixième état est la clôture observée. Les parties utilisatrices indépendantes voient la charge utile successeur, ne valident plus les charges utiles prédécesseurs et classent la route en direct comme prévu. Les exceptions sont enregistrées par point d'observation et cause. Ce n'est qu'alors que l'événement doit être marqué comme clos cryptographiquement. L'achèvement commercial peut avoir eu lieu plus tôt, mais l'enregistrement doit préserver la distinction plutôt que de masquer le décalage.
Un verrou est nécessaire car une correction concurrente peut produire un ensemble erroné
Chaque action individuelle dans un transfert peut être autorisée et pourtant se combiner en un résultat dangereux. Un vendeur peut modifier une ROA pendant qu'un agent du registre examine le transfert. Un acheteur peut changer de fournisseurs de transit après avoir soumis son origine prévue. Un renouvellement automatique de certificat peut entrer en concurrence avec la suppression de ressources. Une autorité de certification déléguée peut publier un nouveau manifeste pendant que son parent modifie l'ensemble de ressources certifiées. Les actions sont localement valides mais globalement incohérentes.
Un verrouillage de transaction devrait donc couvrir les modifications de certification pour les ressources exactes affectées, depuis la vérification finale jusqu'au retrait du prédécesseur. Le verrou n'arrête pas le routage ni la réponse aux incidents ordinaires. Il empêche la création, la modification ou la suppression non coordonnées d'autorisations qui modifieraient l'état de passation convenu. Les changements d'urgence nécessitent une autorité nommée, une raison enregistrée et une revalidation du plan.
Le verrou doit être granulaire. Un transfert d'un préfixe ne doit pas immobiliser les ressources non liées détenues par la même organisation. Lorsqu'une ROA contient plusieurs préfixes, l'émetteur peut avoir besoin de la remplacer par des objets distincts avant le transfert afin que la révocation de l'autorité pour une ressource ne perturbe pas les autres. Les recommandations actuelles favorisant les ROA ciblées soutiennent la clarté opérationnelle ici: un objet multi-préfixes crée une surface de changement plus grande que nécessaire pour la transaction.
Le verrou devrait également lier à la fois les interfaces et l'autorité sous-jacente. Empêcher un vendeur de cliquer sur un contrôle d'édition est insuffisant si des informations d'identification déléguées peuvent encore publier un objet conflictuel. Empêcher de nouveaux objets tout en permettant à un renouvellement planifié de recréer une configuration obsolète est tout aussi faible. Les systèmes hébergés et délégués nécessitent une application différente, mais les deux devraient produire la même garantie: l'état de passation approuvé ne peut pas être modifié silencieusement par une action concurrente.
La libération du verrou nécessite des preuves, et non le seul temps écoulé. L'objet successeur est valide, l'ancienne autorité a disparu, la route prévue est observée et les exceptions non résolues ont un responsable. Si la libération se produit automatiquement après une période fixe, une publication retardée peut transformer un dispositif de sécurité en une fausse assurance.
La publication doit être cohérente avant de pouvoir être rapide
Les dépôts RPKI distribuent des certificats, des listes de révocation, des manifestes et des objets signés. Une ROA de remplacement copiée à un emplacement sans manifeste actuel correspondant n'est pas une publication terminée. Une liste de révocation que les validateurs ne peuvent pas associer à l'état de publication prévu n'éteint pas l'autorité de manière fiable. La vue du dépôt doit être cohérente en interne.
La RFC 9286 exige un nouveau manifeste lorsque les modifications d'un point de publication sont finalisées, avec les hachages mis à jour pour les objets remplacés et les certificats d'entité finale pertinents révoqués. RRDP représente les modifications du dépôt par des instantanés et des deltas sérialisés; la RFC 8182 recommande que les modifications pour une paire de clés d'une autorité de certification, y compris les objets mis à jour, le manifeste et la liste de révocation, soient envoyées sous forme d'un seul message de mise à jour atomique.
Ces contrôles fournissent une cohérence de publication locale, ce qui est indispensable mais plus étroit que l'atomicité globale du transfert.
La distinction est importante. Une autorité de certification source peut publier un retrait parfaitement cohérent alors qu'une autorité de certification de destination n'a pas encore publié son ajout cohérent. Deux dépôts peuvent chacun être corrects en interne et créer conjointement un écart. Inversement, l'ajout de destination peut arriver alors que le retrait source est retardé, créant un chevauchement. Un déplacement interrégional peut également faire passer la ressource entre des arbres d'ancres de confiance, de sorte qu'aucun numéro de série de dépôt unique ne contient le changement complet.
Le coordinateur de passation devrait consommer les reçus de dépôt des deux côtés. Chaque reçu devrait identifier le chemin de certification, le numéro de manifeste ou un marqueur d'état actuel équivalent, le hachage de l'objet, l'heure de publication et la charge utile affectée. Il devrait ensuite obtenir des observations de validateurs indépendants. Cela ne rend pas l'Internet synchrone; cela transforme une séquence incertaine en une séquence vérifiable.
La rapidité reste précieuse. Des intervalles plus courts réduisent l'exposition aux écarts et à l'autorité résiduelle. Mais une mise à jour partielle rapide n'est pas plus sûre qu'une mise à jour cohérente légèrement plus lente. Les objectifs de performance devraient commencer une fois les entrées complètes, distinguer la génération par l'autorité de certification de la publication dans le dépôt et de l'observation par le validateur, et rapporter les cas inclus. Une promesse de propagation globale ne peut pas être déduite du cache d'un seul opérateur.
La révocation est un acte de gouvernance car elle modifie ce à quoi les parties utilisatrices peuvent faire confiance
L'ancienne ROA peut cesser d'être valide de plusieurs manières connexes. Son certificat d'entité finale peut être révoqué. Son certificat de ressources émetteur peut être remplacé ou révoqué lorsque la ressource quitte l'ancien titulaire. L'objet peut être retiré du point de publication et le manifeste mis à jour. L'expiration peut éventuellement le supprimer, mais attendre l'expiration après un transfert effectif n'est pas une stratégie de passation responsable.
La révocation devrait cibler l'autorité minimale nécessaire tout en garantissant que la ressource transférée n'est plus couverte par l'ancienne chaîne. Si un certificat ou un objet couvre des ressources non liées, une séparation préparatoire peut être nécessaire. Une révocation large qui supprime accidentellement des autorisations valides pour des préfixes conservés transforme la sécurité du transfert en panne collatérale.
Le timing est tout aussi exigeant. Révoquer avant la visibilité du successeur risque une rupture. Révoquer longtemps après la visibilité du successeur accorde un chevauchement inutile. Le bon déclencheur est un ensemble d'observations: la nouvelle chaîne de certification valide, la charge utile prévue est présente, l'origine en direct concorde et la destination peut répondre aux incidents. L'ancienne autorité devrait alors être retirée sans délai et le retrait observé.
La RFC 8211 est utile car elle analyse les actions défavorables des autorités de certification et des dépôts sans supposer d'intention malveillante. Une erreur d'autorité de certification, une erreur de dépôt ou une action politique peut diminuer les ressources certifiées d'un titulaire; une ROA concurrente peut également affecter les résultats de routage. Les contrôles de transfert devraient donc fonctionner en cas d'erreurs ordinaires ainsi que de comportement hostile. La double approbation, les références d'événements signées et la validation indépendante réduisent la capacité d'une seule action erronée à définir l'ensemble de l'événement.
Une ancienne autorisation qui survit trop longtemps doit être traitée comme une exception avec une horloge et un responsable redevable. L'enregistrement doit identifier pourquoi elle subsiste, quelles origines elle autorise, qui peut la supprimer et quelle surveillance intérimaire s'applique. L'appeler cohérence à terme n'est pas un remède. La cohérence à terme sans état terminal imposé est simplement une autorité résiduelle avec un nom technique.
Les caches des validateurs rendent la convergence observable mais jamais universelle
Les parties utilisatrices ne consultent pas le service émetteur à nouveau pour chaque mise à jour BGP. Elles récupèrent les données du dépôt, valident les chemins de certification et les objets signés, conservent un état utilisable dans des conditions définies et fournissent des charges utiles validées aux routeurs. Les intervalles d'interrogation, la disponibilité du dépôt, le comportement du transport, les versions logicielles et la politique locale créent des moments d'observation différents.
RRDP est conçu pour aider une partie utilisatrice à déterminer si sa copie locale est synchronisée avec un dépôt en utilisant un identifiant de session et un numéro de série. Les deltas peuvent transporter des objets nouveaux, remplacés et retirés dans un seul ensemble de modifications. Pourtant, un validateur peut récupérer le dernier delta tandis qu'un autre subit un échec de récupération et continue à partir d'un cache antérieur utilisable. Un troisième peut rejeter le nouvel état parce qu'un contrôle de manifeste, de hachage ou de certificat échoue.
Ce ne sont pas des violations théoriques de l'enregistrement du transfert; elles font partie de l'environnement que l'enregistrement doit prendre en compte.
Pour cette raison, un registre ne devrait pas estampiller un temps de propagation universel sur chaque passation. Il peut publier des mesures de niveau de service pour sa propre autorité de certification et son dépôt. Un service de transfert peut définir un ensemble d'observations minimal à travers des implémentations, des transports et des emplacements indépendants. Un opérateur peut choisir une période de maintien prudente basée sur les cycles de validation mesurés et la criticité de la route. Aucun ne fournit le dénominateur de chaque partie utilisatrice sur Internet.
L'observation devrait préserver les désaccords. Si quatre validateurs sélectionnés voient la nouvelle charge utile et qu'un conserve l'ancienne, le rapport devrait montrer cinq résultats, les versions logicielles, les chemins d'ancres de confiance, les heures de récupération et les erreurs pertinentes. Les moyenner en un pourcentage vert dissimulerait l'échec précis qui importe. Le résultat périmé peut identifier une bordure de dépôt, un défaut de validateur, une mauvaise configuration opérationnelle ou une règle de cache attendue.
L'affirmation terminale doit être limitée: tous les points d'observation nommés ont validé le successeur et rejeté le prédécesseur aux heures indiquées. C'est une preuve solide. Ce n'est pas la preuve qu'aucun validateur déconnecté, abandonné ou modifié à titre privé ne conserve d'anciennes données.
Les transferts intrarégionaux et interrégionaux nécessitent une chorégraphie différente
Au sein d'un même RIR, une ressource peut passer d'une organisation à l'autre sous la même ancre de confiance régionale. L'autorité parente peut mettre à jour les ensembles de ressources des certificats source et destination au sein d'un même domaine institutionnel. Les services hébergés peuvent automatiser une grande partie du changement. Même alors, des points de publication distincts et les caches des parties utilisatrices empêchent une véritable simultanéité mondiale, et les autorités de certification déléguées ajoutent de la coordination opérationnelle.
Un transfert interrégional change davantage. Le RIR source doit retirer la ressource de sa hiérarchie certifiée et le RIR de destination doit l'ajouter sous une autre hiérarchie. Les validateurs partent de différents TAL et traversent différents dépôts. La libération source et l'acceptation destination sont régies par des procédures régionales, des relations juridiques et des équipes opérationnelles distinctes. La route peut rester la même tandis que son chemin de validation se déplace entre les ancres de confiance.
La référence de transaction commune est donc plus précieuse entre les régions. Elle devrait lier le préfixe exact, les autorités source et destination, la charge utile de route prévue, la condition de libération, la condition d'acceptation et la limite d'annulation. Chaque RIR devrait émettre son propre reçu signé ou autrement vérifiable. Les parties au transfert devraient pouvoir démontrer que la destination était prête avant que la source n'effectue un retrait irréversible, ou qu'un mécanisme de continuité convenu a couvert l'intervalle.
Le chevauchement interrégional mérite une interprétation prudente. La même charge utile prévue se validant brièvement sous les deux chemins régionaux peut soutenir la continuité. Des charges utiles d'origine différentes sous les deux chemins créent une double autorisation et devraient être limitées dans le temps. Une ressource apparaissant sous les deux ancres de confiance au-delà de la passation contrôlée peut indiquer une incohérence de certification que les validateurs et les RIR doivent résoudre.
Aucune règle juridique ou opérationnelle universelle ne peut être déduite de l'interface d'un seul RIR. La norme partagée devrait définir des preuves d'événements interopérables et des résultats de sécurité tout en laissant chaque autorité responsable de ses décisions politiques. La coordination n'est pas une centralisation; c'est la structure minimale nécessaire lorsque l'autorité d'une route traverse deux arbres institutionnels.
La certification hébergée et déléguée échouent de différentes manières
Le RPKI hébergé donne au registre ou à l'opérateur de service la capacité directe de mettre à jour les certificats et les configurations de ROA lorsque l'enregistrement change. Cela peut réduire les étapes de coordination. La documentation du RIPE NCC explique que les ressources certifiées sont mises à jour automatiquement lorsque les ressources sont déplacées et que les ROA publiées sont ajustées lorsque les ressources sont supprimées. L'avantage est le couplage étroit entre l'enregistrement du titulaire et la certification hébergée.
Ce même couplage peut surprendre un destinataire qui n'a pas préparé d'autorisations de remplacement. La suppression automatique est correcte du point de vue de l'autorité de l'ancien titulaire, mais peut néanmoins créer un écart opérationnel. Le service devrait donc exiger une déclaration de routage prévue ou fournir un avertissement pré-transfert et un chemin de préparation du successeur plutôt que de compter sur l'acheteur pour découvrir l'effet après coup.
Le RPKI délégué transfère le contrôle des clés et de la publication au détenteur de la ressource ou à son fournisseur de services. Le registre modifie le certificat parent, tandis que les parties au transfert doivent coordonner leurs autorités de certification enfants, leurs points de publication et leurs objets. Cela peut améliorer l'autonomie opérationnelle mais élargit la surface de passation. Une autorité de certification déléguée source peut être injoignable. Un dépôt de destination peut ne pas encore être accepté. Les mises à jour du parent et la publication de l'enfant peuvent entrer en concurrence.
Le résultat en matière de sécurité devrait être le même. L'ancienne chaîne cesse de valider la ressource; la nouvelle chaîne valide la charge utile prévue; aucun intervalle imprévu ne laisse la route en direct Invalide; et l'autorisation résiduelle est limitée. Les preuves diffèrent. Les systèmes hébergés peuvent fournir des reçus d'événements internes et des observations de validateurs externes. Les systèmes délégués ont également besoin de preuves des serveurs de publication et de la confirmation que l'autorité de certification de destination était opérationnelle avant le déplacement de l'autorité parente.
Les contrats de transfert devraient nommer le mode. Un acheteur qui suppose une automatisation hébergée tout en recevant une responsabilité déléguée peut ne pas posséder les clés, l'arrangement de service ou l'expertise nécessaires au basculement. Un vendeur qui suppose que le registre supprimera tous les anciens objets peut conserver un état de publication délégué qui devient invalide mais reste opérationnellement confus. La clarté sur le contrôle est une condition préalable à la continuité.
L'annulation doit préserver l'autorité plutôt que de recréer le passé de manière inexacte
Avant le changement effectif de titulaire, l'annulation est relativement simple. Arrêter le transfert, supprimer toute autorité de pont qui n'est plus nécessaire, libérer le verrou de certification et confirmer que l'état de route d'origine reste valide. Même ici, la suppression du pont nécessite la même discipline de publication et d'observation que toute autre révocation.
Après que la ressource a été déplacée et que l'ancien certificat a été révoqué, l'annulation ne consiste pas à restaurer des fichiers à partir d'un cache précédent. Les objets antérieurs peuvent ne plus posséder de chemin de certification valide. La réutilisation d'anciennes clés ou la republication d'états expirés pourrait créer une autorité trompeuse. Si la transaction elle-même doit être inversée, le registre a besoin d'un nouveau changement autorisé qui rétablisse l'ancien titulaire et émette des certificats et des ROA actuels par une nouvelle séquence.
Le point de non-retour doit être explicite. Il peut s'agir de la libération finale du RIR source, de l'émission du certificat de destination, d'un transfert légalement effectif ou d'une combinaison selon la procédure applicable. Avant ce point, un abandon ramène à l'état d'origine. Après, un transfert correctif ou une correction crée un nouvel état. Cette distinction préserve l'historique et empêche les opérateurs de dissimuler un événement échoué par une restauration silencieuse.
La continuité opérationnelle pendant la remédiation peut nécessiter une autorisation temporaire par le titulaire reconnu actuel pour l'origine qui peut maintenir le service en fonctionnement. Cette décision doit être séparée du litige sur la titularité ultime. Un tribunal ou un registre peut restreindre un transfert ultérieur tout en autorisant une autorisation de route limitée pour protéger les clients. La ROA enregistre la permission de route; elle ne règle pas le litige.
Les exercices devraient tester les deux voies. Un service qui n'a répété qu'un basculement réussi ne sait pas s'il peut s'arrêter en toute sécurité avant l'achèvement ou récupérer par la suite. Les cas de test devraient inclure un mauvais ASN, une mauvaise longueur maximale, une défaillance du dépôt de destination, une autorité source périmée, un cédant qui ne répond pas et un désaccord entre les points d'observation.
Les restrictions légales et les sanctions devraient limiter l'action, pas corrompre la séquence
Un transfert peut être retardé ou restreint par un litige, une insolvabilité, un examen des sanctions, une enquête pour fraude ou un différend sur l'autorité. Ces conditions n'éliminent pas le besoin d'une autorité de routage précise. Elles modifient qui peut ordonner quelle action et quand l'état du titulaire peut évoluer.
L'enregistrement de l'événement doit représenter une restriction avec précision. Une interdiction de changer le titulaire reconnu n'est pas automatiquement une instruction de révoquer la ROA actuelle. Une ordonnance préservant le service réseau n'est pas nécessairement une autorisation de finaliser la vente. Une restriction de sanctions sur un destinataire n'autorise pas un intermédiaire privé à prendre la ressource. Chaque condition doit identifier sa source, sa portée, son examinateur et sa date d'expiration ou de révision.
Lorsqu'un transfert est suspendu avant le changement effectif, les autorisations valides existantes peuvent continuer si elles sont légales et opérationnellement prévues. Tout pont créé pour le destinataire proposé doit être examiné car son objectif peut ne plus exister. Lorsqu'une restriction arrive après le changement effectif mais avant que l'ancienne autorité ne soit retirée, laisser la ROA du cédant active n'est pas une réponse neutre. Le décideur compétent doit préciser si la continuité nécessite une origine particulière pendant que l'état d'enregistrement reste actuel.
La séquence cryptographique doit suivre l'état institutionnel autorisé, et non tenter de le décider. Les autorités de certification vérifient que la partie reconnue selon leurs règles peut faire la déclaration. Elles doivent maintenir un historique précis, préserver les preuves et exécuter des décisions limitées. Elles ne doivent pas transformer une large incertitude juridique en deux autorités actuelles indéfinies.
C'est une autre raison de séparer le chevauchement du langage de propriété. Deux ROA peuvent être temporairement valides parce que la continuité était planifiée ou qu'une restriction l'exigeait. Cela ne signifie pas que deux parties possèdent la ressource. Une ROA peut être révoquée parce que l'autorité de certification a été déplacée. Cela ne prouve pas que toutes les obligations commerciales ont été satisfaites. Des déclarations exactes réduisent à la fois les excès techniques et juridiques.
L'observation indépendante doit tester la route, la charge utile et la chaîne
Un moniteur de transfert qui vérifie seulement si un nom de fichier ROA existe passera à côté des échecs qui importent. Il devrait valider la chaîne complète depuis l'ancre de confiance acceptée jusqu'aux certificats de ressources et au certificat d'entité finale de la ROA, au manifeste actuel et à l'état de révocation. Il devrait dériver la charge utile résultante et comparer cette charge utile avec la route BGP observée.
Le moniteur devrait répondre à quatre questions. Premièrement, le tuple préfixe-origine-longueur maximale prévu est-il valide sous la chaîne actuelle du destinataire? Deuxièmement, une ancienne chaîne ou une chaîne inattendue produit-elle encore une charge utile pour la ressource transférée? Troisièmement, quel état de validation la route en direct reçoit-elle à chaque point d'observation? Quatrièmement, les reçus d'enregistrement et de certification identifient-ils la même ressource et le même événement effectif?
Des implémentations multiples sont utiles car un défaut d'analyseur ou une décision de condition exceptionnelle dans un validateur ne devrait pas définir le rapport. Des emplacements multiples sont utiles car les dépôts et les chemins réseau peuvent échouer différemment. Des moments multiples sont nécessaires car une seule récupération réussie ne montre pas que l'autorité prédécesseur a été retirée par la suite. L'ensemble d'observations doit être déclaré avant le basculement afin que les parties ne sélectionnent pas uniquement des résultats favorables après coup.
Les documents commerciaux bruts n'ont pas besoin d'être publics. L'enregistrement public ou destiné aux membres peut divulguer le préfixe, les anciens et nouveaux états d'autorisation, les heures des événements, les autorités participantes, la méthode d'observation et les réserves non résolues. Les preuves d'identité sensibles et les termes de la transaction peuvent rester protégés avec un accès d'audit. L'objectif est une clôture opérationnelle vérifiable, pas une divulgation sans discernement.
Les alertes doivent être spécifiques à l'événement. Une notification indiquant qu'une ancienne charge utile reste valide après sa date limite est différente d'un avis indiquant que la nouvelle route est Invalide chez un validateur. La première exige une révocation ou une enquête sur le certificat parent; la seconde peut indiquer une erreur de propagation, de dépôt ou de configuration de route. Des alertes exactes raccourcissent le remède et clarifient la responsabilité.
La Société des ressources numériques peut standardiser le reçu sans prétendre être la racine
Une future Société des ressources numériques a un rôle constructif entre la pratique fragmentée des transactions et l'autorité de certification concentrée. Elle peut définir un reçu de passation commun que les RIR, les fournisseurs qualifiés, les titulaires et les moniteurs indépendants peuvent produire et vérifier. Le reçu ne remplacerait pas un certificat de ressources ni ne deviendrait une nouvelle ROA. Il lierait les preuves que ces changements faisant autorité se sont produits comme un seul événement gouverné.
Les champs minimaux sont concrets: référence du transfert, ressources exactes, autorités d'enregistrement source et destination, anciennes et nouvelles origines prévues, longueurs maximales, mode hébergé ou délégué, objectif du pont, point effectif, libération source, acceptation destination, observations de publication du successeur, observations de révocation du prédécesseur, exceptions et examinateur final. Chaque déclaration doit identifier son émetteur et son heure.
La NRS peut également publier des tests de conformité. Un fournisseur devrait démontrer une continuation avec la même origine, un changement d'origine, un déplacement interrégional, une défaillance d'autorité de certification déléguée, un abandon de pont et une correction post-effective. Les résultats des tests devraient montrer les résultats de validation à travers des implémentations nommées plutôt qu'une simple étiquette de réussite. Une revendication d'accréditation ferait alors référence aux capacités testées et à l'audit actuel, et non à l'affiliation institutionnelle.
C'est une décentralisation positive. De multiples fournisseurs et observateurs peuvent mettre en œuvre la norme tandis que les autorités de certification des RIR restent responsables de leurs actes de certification faisant autorité. Les titulaires reçoivent des preuves portables de ce qui s'est produit. Les opérateurs reçoivent un ensemble commun d'états de basculement. Les chercheurs peuvent comparer les performances délimitées sans exiger les conditions de vente privées.
La NRS ne devrait pas promettre que son reçu entraîne la mise à jour des validateurs mondiaux, et elle ne devrait pas acquérir le pouvoir de signer chaque route. Sa légitimité viendrait du fait de rendre les transitions d'autorité plus visibles, exactes et contestables. Une norme qui expose une ancienne ROA persistante est utile même lorsque la NRS n'a pas le pouvoir de la révoquer; l'exposition indique à l'autorité de certification responsable et aux parties au transfert précisément ce qui reste inachevé.
L'économie des transferts s'améliore lorsque l'autorité résiduelle devient une responsabilité divulguée
Les acheteurs évaluent ce qu'ils ne peuvent pas contrôler. Si un vendeur peut rester autorisé cryptographiquement après la clôture, l'acheteur hérite d'un risque d'origine de route que le langage de titre ordinaire peut ne pas guérir. Si la nouvelle route de l'acheteur peut devenir Invalide pendant le basculement, les clients peuvent subir une perturbation juste au moment où l'acheteur prend ses responsabilités. Les prêteurs, les assureurs et les partenaires opérationnels devraient donc traiter la passation RPKI comme faisant partie des preuves d'achèvement pour les ressources routées.
Le remède n'est pas une remise de prix universelle. La réputation du préfixe, la conception de la route, les droits contractuels, la politique régionale et les conditions du marché diffèrent. Il n'y a pas de dénominateur commun mondial complet pour les transferts avec des lacunes de ROA, des autorisations périmées ou un impact sur les clients. Les ventes privées et les accords de routage ne sont pas entièrement observables. Toute affirmation selon laquelle une part fixe de la valeur des adresses est attribuable à une passation RPKI propre dépasserait les preuves.
La transaction peut néanmoins répartir clairement les responsabilités. Le vendeur garantit qu'il a divulgué les autorisations existantes et coopère à la création et au retrait du pont. L'acheteur fournit les données de routage prévues et maintient la préparation de la certification de destination. Le registre ou le fournisseur s'engage à des changements cohérents de titulaire et de certificat. Une condition de clôture exige des observations de validateurs nommés. Un montant retenu ou une indemnité peut traiter l'incapacité à retirer l'autorité prédécesseur, sous réserve de la loi applicable.
Ces termes convertissent l'ambiguïté technique en obligations gérables. Ils rendent également la qualité de service comparable. Un fournisseur d'enregistrement qui peut produire des reçus de passation délimités, une publication rapide et cohérente et une réponse efficace aux exceptions offre plus qu'un portail. Un observateur qui préserve les résultats divergents offre plus qu'un badge vert. Un courtier qui vérifie l'autorité de route avant et après la clôture réduit un risque opérationnel réel.
L'avantage économique provient d'une incertitude moindre, et non de la transformation des ROA en titres de propriété. Plus la séparation est nette entre le changement de titulaire, la permission de route et la clôture observée, plus il est facile pour chaque partie d'accepter le risque qu'elle peut contrôler.
La responsabilité exige de publier les exceptions, pas seulement la médiane
Un service de transfert mature doit rapporter ses performances en utilisant la population qu'il a effectivement traitée. Pour chaque période, il peut indiquer combien de transferts ont utilisé une continuation avec la même origine, ont changé d'origine, ont traversé des RIR, ont utilisé une certification déléguée ou ont nécessité une exception. Il peut rapporter les intervalles d'achèvement à partir d'événements de début et de fin définis et montrer l'autorité prédécesseur non résolue à la date de clôture du rapport.
Les cas exceptionnels sont les plus importants. Une seule ancienne ROA qui reste valide après le transfert peut exposer la faiblesse cachée par de nombreux succès de routine. Les rapports devraient expliquer si la cause était l'inaction du cédant, un défaut du service hébergé, un échec de publication déléguée, le timing du certificat parent, le manque de préparation de la destination, une restriction légale ou un désaccord des validateurs. Les détails personnels et commerciaux peuvent être minimisés sans effacer la cause institutionnelle.
Les dénominateurs doivent rester locaux au rapport. Les transferts entités ne révèlent pas tous les transferts dans le monde, tous les baux privés ou toutes les interruptions non signalées. Les observations des validateurs ne révèlent pas la politique de routage de chaque réseau. La visibilité BGP ne prouve pas la relation contractuelle complète. Des limites honnêtes rendent les conclusions plus utiles car les opérateurs savent ce qui peut et ne peut pas être déduit.
L'examen indépendant devrait échantillonner des historiques d'événements complets, et non des captures d'écran de l'état final. L'examinateur doit voir le plan déclaré, le verrou, les preuves d'autorité, les reçus de publication, les observations, la révocation et la gestion des exceptions. Il doit vérifier que les horodatages proviennent de systèmes identifiés et que l'examinateur final n'a pas approuvé un cas avec une autorité résiduelle inexpliquée.
Les membres devraient pouvoir contester un rapport. Si une partie au transfert montre qu'une ancienne charge utile est restée valide à un point d'observation nommé, le service devrait enquêter plutôt que de rejeter le résultat parce que la plupart des moniteurs étaient verts. La légitimité institutionnelle se construit en réparant la valeur aberrante qui expose une lacune de contrôle.
L'état terminal sûr est simple même lorsque le chemin ne l'est pas
À la fin d'un transfert, le destinataire est le titulaire reconnu selon l'arrangement de registre applicable. Le chemin de certification du destinataire couvre la ressource transférée. La charge utile d'origine de route prévue valide par ce chemin. La route BGP en direct correspond au préfixe, à l'origine et à la longueur autorisée prévus. L'ancien chemin du cédant ne valide plus l'autorité pour la ressource, sauf pour aucun objectif déclaré car le pont a pris fin. Les observations indépendantes enregistrent le résultat et tout point de vue inaccessible honnêtement.
Atteindre cet état peut nécessiter une coordination régionale, un examen juridique, des opérateurs délégués et plusieurs cycles de validation. La complexité n'est pas une raison pour affaiblir la condition terminale. C'est une raison pour définir des états intermédiaires, attribuer des responsables et préserver les preuves.
La leçon de l'ancienne ROA n'est pas que le chevauchement ne doit jamais se produire. Le principe « établir avant de rompre » nécessite souvent un chevauchement. La leçon est que le chevauchement doit avoir un but, une portée étroite et une fin forcée. La leçon n'est pas non plus que chaque écart déconnectera le préfixe. Certains réseaux peuvent accepter les routes NotFound, et le routage peut persister pendant un intervalle Invalide là où le filtrage est absent. L'objectif n'est pas de parier sur une politique incohérente; c'est de préserver l'autorisation prévue.
Depuis 2012, l'architecture technique contient la séquence essentielle. La tâche institutionnelle est de l'appliquer au transfert dans son ensemble. Les agents d'enregistrement, les autorités de certification, les dépôts, les parties au transfert, les opérateurs et les parties utilisatrices ne voient chacun qu'une partie de l'événement. Une norme de passation fait en sorte que ces parties répondent à un seul test d'achèvement.
Le transfert n'est pas clos cryptographiquement lorsque le registre envoie sa confirmation. Il est clos lorsque l'autorité successeur fonctionne, que l'autorité prédécesseur ne fonctionne plus, que la route en direct concorde et que les preuves peuvent être rejouées par un examinateur indépendant. Tout ce qui est en deçà laisse soit une lacune d'accessibilité, soit l'ombre d'un ancien titulaire à la table de routage.
Sources
- RFC 6480: Une infrastructure pour soutenir le routage Internet sécurisé
- RFC 9582: Un profil pour les autorisations d'origine de route
- RFC 9286: Manifestes pour l'infrastructure de clé publique de ressources
- RFC 8182: Le protocole Delta du dépôt RPKI
- RFC 8897: Exigences pour les parties utilisatrices RPKI
- RFC 8211: Actions défavorables par une autorité de certification RPKI ou un gestionnaire de dépôt
- RIPE NCC: Utilisation du système RPKI
- RIPE NCC: Utilisation de l'autorité de certification hébergée
- ARIN: Autorisations d'origine de route
- Documentation RPKI: Utilisation des données RPKI
- Société des ressources numériques: À propos de nous
- Charte de la Société des ressources numériques

