Résumé

  • En avril 2026, le rapport d’ingénierie d’ARIN a classé les contraintes d’ancres RPKI parmi ses améliorations prévues, tout en les liant à des travaux IETF encore à l’état de brouillon.
  • La donnée quotidienne du registre ne devient pas automatiquement la politique du réseau : elle passe par un état éventuel du NRO, un compilateur, un canal de paquet, une installation et le choix du relying party.
  • Un reçu de distribution, fondé sur versions, horodatages et empreintes, peut rendre ces passages auditables sans confier à un acteur central la décision de routage.

Le vieux fichier dans une machine à jour

Un serveur peut recevoir ses correctifs de sécurité chaque semaine et conserver pendant des mois le même périmètre de confiance RPKI. Ce paradoxe n’a rien d’exotique. Le brouillon IETF en cours demande aux responsables de listes diffusées dans les paquets d’un système d’exploitation ou d’un tiers de prévoir jusqu’à six mois avant que les utilisateurs ne mettent à jour. Ce délai est une hypothèse prudente pour les mainteneurs, pas une statistique sur les installations réelles. Il suffit néanmoins à montrer où se déplace le risque.

La fraîcheur du fichier publié par ARIN ne dit pas celle du fichier chargé par le validateur. Entre les deux, quelqu’un choisit les sources, interprète les transferts, compile une liste, signe ou publie un résultat, construit un paquet, l’introduit dans un dépôt puis attend qu’une organisation l’installe. L’opérateur peut aussi geler volontairement sa version, appliquer une exception locale ou revenir au dernier état qu’il juge sûr. Une contrainte RPKI n’est donc pas « actuelle » parce que sa matière première l’est. Elle l’est si l’on peut relier la matière première au fichier effectivement utilisé.

Le mécanisme mérite cette précision parce qu’il peut invalider un certificat d’entité finale. Dans la chaîne de validation, un paquet ancien n’est pas un simple défaut documentaire : il peut modifier la frontière entre un objet accepté et un objet écarté. Le scénario est plausible, mais les sources ne signalent aucun incident de ce type chez ARIN. Il faut analyser le contrôle sans inventer le sinistre.

Ce qu’ARIN 57 a annoncé — et ce qu’il n’a pas annoncé

Lors d’ARIN 57, en avril 2026, le rapport d’ingénierie a mentionné les contraintes d’ancres de confiance parmi les évolutions publiques prévues pour le RPKI. Le calendrier restait dépendant de la normalisation à l’IETF. La diapositive suivante rattachait le chantier au Number Resource Organization : les statistiques étendues décriraient ce que détient chaque registre, les futurs journaux étendus de transfert suivraient le déplacement des ressources entre RIR, et l’ensemble soutiendrait le brouillon IETF, avec une mise en œuvre déjà présente dans rpki-client.

La transcription de la réunion parlait d’une liste de ressources autorisées sous chaque registre régional, comparable à une liste de contrôle d’accès à l’intérieur du RPKI. Elle confirmait l’existence de brouillons et de code. Elle ne démontrait ni une activation en production, ni une population de relying parties équipée, ni une procédure commune d’installation. Une feuille de route, un programme multi-registres et un binaire utilisable sont trois indices différents.

La distinction demeure importante en septembre. draft-ietf-sidrops-constraining-rpki-trust-anchors-01, daté du 9 août 2026, est un Internet-Draft actif du groupe SIDROPS ; son état IESG est « I-D Exists ». Ce n’est pas une RFC. Le texte du NRO sur la construction et la signature d’un état de distribution est lui aussi un brouillon. Une expérimentation peut précéder la norme finale, mais la communication opérationnelle doit montrer à quel stade se trouve chaque élément.

La largeur voulue des ancres

Le problème actuel vient en partie d’une mesure de continuité prise neuf ans plus tôt. En septembre 2017, ARIN a coordonné avec les autres RIR le passage de son certificat d’ancre vers une forme couvrant toutes les ressources, résumée dans l’annonce par 0/0. Le TAL n’a pas changé. Cette largeur évitait qu’une incohérence temporaire pendant un transfert inter-RIR ne rende massivement invalides des produits situés plus bas dans la hiérarchie.

Le brouillon SIDROPS rappelle ainsi que les cinq certificats d’ancre des RIR incluent l’ensemble d’IPv4, d’IPv6 et des numéros de système autonome. Ce choix ne signifie pas que chaque registre revendique administrativement toutes ces ressources. Il donne à la hiérarchie cryptographique assez de jeu pour résister à un décalage des registres. Sa contrepartie est claire : en fonctionnement normal, un certificat d’ancre peut techniquement couvrir des ressources qui ne figurent pas dans les avoirs du registre.

La contrainte locale resserre cet espace. Elle dit quelles ressources l’opérateur du relying party s’attend à voir sous une ancre donnée. Le principe ressemble au moindre privilège, appliqué après une exception de continuité volontaire. RFC 6480 laisse déjà à chaque relying party le choix de ses ancres ; RFC 8211 décrit les risques d’actions nuisibles de la part d’autorités de certification ou de gestionnaires de dépôts. Aucun de ces textes ne transforme une statistique opérationnelle d’ARIN en décision de routage locale.

Une syntaxe courte, des conséquences étendues

Dans le projet actuel, une contrainte est l’union de préfixes ou plages IP et d’identifiants ou plages d’ASN que l’opérateur anticipe sous l’ancre. La syntaxe emploie allow et deny. Un refus l’emporte, les entrées du même type ne doivent pas se chevaucher, l’ordre ne compte pas et tout ce qui n’est pas explicitement permis est implicitement refusé.

Le contrôle intervient au certificat d’entité finale. Si les ressources énumérées dans ce certificat ne sont pas entièrement contenues dans la contrainte locale, le validateur devrait cesser son traitement et considérer le certificat comme invalide. L’effet peut toucher les ROA, les ASPA, les RSC, les certificats de routeur BGPsec et les objets geofeed. Le brouillon exclut de ce contrôle les objets dont les ressources sont héritées, notamment les manifestes, les Ghostbusters records et les TAL signés.

Le manuel OpenBSD de rpki-client montre où la règle vit : un fichier .constraints porte le même nom de base que le .tal correspondant. Ce voisinage sur disque ne doit pas masquer deux fonctions. Le TAL mène à l’ancre. La contrainte exprime l’attente locale concernant les émissions de cette ancre. Lorsque l’un évolue sans preuve sur l’autre, l’explication d’une invalidation devient fragile.

Le texte contient aussi des décisions de politique précises. La communauté ARIN ayant abandonné ARIN-2019-4 sur les transferts IPv6 interrégionaux, une ressource IPv6 allouée par ARIN ne devrait normalement pas apparaître sous l’ancre d’un autre RIR. Les ressources privées, documentaires et certaines réserves ne devraient se trouver sous aucune ancre régionale. Compiler une contrainte revient donc à appliquer des règles et des exceptions, pas à recopier une colonne.

Un fichier quotidien ne raconte pas le transfert

ARIN met à jour chaque jour ses statistiques étendues de délégation. Elles couvrent les distributions IPv4, IPv6 et ASN selon le format du NRO. ARIN précise cependant qu’elles ne comprennent ni les réallocations ni les réassignations. L’union des rapports régionaux peut faire ressortir des recouvrements et des trous, signaler le statut d’adresses transférées et attribuer la responsabilité administrative de ressources non allouées. C’est une excellente source. Ce n’est pas encore un .constraints installé.

La cadence quotidienne répond seulement à une question : à quelle fréquence ARIN régénère-t-il ce rapport ? Elle ne donne pas l’heure d’arrivée de chaque événement, ni la date de collecte par le compilateur, ni l’âge du paquet chez l’opérateur. Elle ne décrit pas non plus, à elle seule, l’étape exacte d’un transfert. Voilà pourquoi ARIN 57 associait aux statistiques des journaux étendus de transfert dont la spécification restait en cours.

Une vue des avoirs et une vue des mouvements doivent se rejoindre sans perdre leur chronologie. Si un compilateur bascule trop tôt la ressource vers le destinataire, il peut écarter les objets encore légitimement produits sous l’ancre source. S’il bascule trop tard, il conserve une permission devenue inutile. Le certificat d’ancre très large évite une rupture cryptographique brutale ; la contrainte, si elle est mal synchronisée, peut réintroduire une rupture au niveau local.

Le moment honnête où deux ancres acceptent

draft-nro-sidrops-ta-constraints-00 propose des objets signés de type Resource Distribution State, Event et Consensus. Les ensembles initiaux doivent être disjoints. Pour un transfert, le protocole sépare l’initiation, l’acceptation par le destinataire et la finalisation par la source.

Entre l’acceptation et la finalisation, les deux ancres peuvent être considérées comme détentrices. Ce chevauchement temporaire permet au destinataire de créer des objets signés correspondants sans trou de disponibilité. Après finalisation, lui seul doit conserver la ressource aux fins de validation de la contrainte. Une finalisation erronée n’est pas simplement effacée : un transfert compensatoire peut ramener la ressource.

Ces phases donnent au temps une valeur sémantique. Une liste compilée pendant le chevauchement et une liste compilée après la finalisation peuvent toutes deux être correctes pour leur instant. La version du paquet ne suffit pas à expliquer l’écart. Il faut connaître l’identifiant du transfert, sa phase, les empreintes des sources, la règle de compilation et le moment d’installation.

Si le NRO parvient à signer cet état commun, il renforcera la provenance avant compilation. Il ne supprimera pas l’autonomie du relying party. Le brouillon IETF présente l’état NRO comme une entrée possible. Chaque opérateur conserve ses critères, son calendrier et sa configuration. La coordination peut établir ce que les registres affirment ensemble ; elle ne doit pas imposer silencieusement la politique de chaque réseau.

Un reçu qui suit les mains

Le reçu utile commence par les fichiers sources : nom, horodatage et empreinte. Il ajoute la version du schéma et de la spécification, l’identité du compilateur et une référence de construction reproductible. Lorsqu’un état signé du NRO intervient, il indique l’autorité de signature et le résultat de la vérification.

Pour chaque ancre, il publie séparément l’empreinte de l’ensemble IPv4, IPv6 et ASN. Il associe aux ressources en mouvement l’identifiant et la phase du transfert, y compris l’acceptation temporaire sous deux ancres. Puis il suit le produit : nom du paquet, version, heure de construction, canal de distribution, heure d’installation, provenance d’une éventuelle dérogation locale, version du validateur et empreinte du fichier réellement chargé.

Le dernier volet mesure l’effet. Combien d’objets ont été acceptés ou rejetés à cause de la contrainte, par classe ? Quelle alerte a été déclenchée ? Quel seuil d’ancienneté, quel dernier état fiable, quelle solution de repli et quel test de retour arrière ? Qui a pris la décision locale et à quelle heure est-elle devenue effective ? Des empreintes et des comptages agrégés répondent à ces questions sans divulguer la configuration des routeurs.

Ce reçu corrige aussi l’attribution. Dire « ARIN a rejeté ce ROA » peut être faux lorsque le rejet provient d’un validateur local utilisant un fichier compilé, emballé et distribué par d’autres. Le registre produit des preuves, le NRO peut consolider un état, un mainteneur fabrique, un logiciel contrôle, un opérateur décide. L’enregistrement doit conserver cette grammaire des responsabilités.

Les limites à ne pas franchir

Les documents ne prouvent pas qu’ARIN a activé une contrainte chez des relying parties. Ils ne prouvent pas non plus que tous les validateurs recevront un état NRO identique, qu’un paquet a été périmé six mois, ni qu’une route a disparu en conséquence. Le délai de six mois est une hypothèse de diffusion. Les statistiques quotidiennes ont un périmètre déclaré. Les journaux de transfert étaient encore en spécification lors d’ARIN 57.

Enfin, l’invalidation d’un certificat dans la validation RPKI n’ordonne pas mécaniquement le retrait d’une route. Elle modifie les informations disponibles pour la politique locale. Le résultat sur le routage dépend des autres objets valides, du logiciel et de la règle de l’opérateur. Le reçu proposé ici n’est ni une exigence actuelle d’ARIN ni une obligation de l’IETF. C’est une manière limitée de rendre le dernier kilomètre vérifiable.

Sources