Summary

  • Un relying party RPKI fabrique une vue locale et datée à partir de dépôts distribués, d’ancres de confiance configurées, de règles de validation, d’échecs de synchronisation et, parfois, d’exceptions locales.
  • draft-su-sidrops-rpki-rp-requirements-00 propose d’ajouter l’export stable du cache validé, l’explication des rejets et la conservation des états passés : le résultat ne suffit plus sans sa provenance opérationnelle.
  • Daniel Kade propose un reçu d’état de validation reliant exécution, entrées, échecs, empreinte du cache, contrôle local, livraison aux routeurs et conservation. Ce reçu est une recommandation éditoriale, pas une exigence de l’IETF.

Le vert décrit un résultat, pas son histoire

La chaîne RPKI est souvent résumée en trois verbes : publier, valider, distribuer. Ce raccourci masque précisément la zone où se forme la décision locale. Les objets sont répartis entre des points de publication. Le logiciel de relying party choisit et traite des ancres de confiance, découvre les dépôts, synchronise les données, vérifie certificats, CRL, manifestes et objets signés, puis construit un cache validé. Un opérateur peut encore appliquer des filtres ou assertions SLURM. Enfin, un protocole distinct transmet des charges utiles aux routeurs.

Une signature correcte ne prouve pas que tous les dépôts étaient accessibles. Un manifeste courant décrit l’inventaire courant d’un point de publication, pas la complétude de toute l’observation. Un numéro de série de cache n’est intelligible qu’avec la version du protocole et l’identifiant de session. RFC 8210 précise qu’il n’est pas comparable entre caches et qu’il peut disparaître lors d’une réinitialisation. Même une livraison réussie ne démontre pas la décision de routage prise ensuite.

Parler de « l’état RPKI » au singulier gomme donc une série d’autorités. L’énoncé défendable est plus étroit : telle exécution, sous telle configuration, a observé tels dépôts et tels échecs, appliqué telles transformations locales et offert tel état à tels consommateurs pendant telle période.

Ce que le projet de juin 2026 ajoute réellement

Le projet individuel draft-su-sidrops-rpki-rp-requirements-00, daté du 12 juin 2026, veut actualiser le point de référence constitué par RFC 8897. Depuis 2020, les textes applicables se sont multipliés : clés successeures d’ancres de confiance, contrôle de même origine pour RRDP, détection de désynchronisation, nouveaux profils de manifestes et de ROA, traitement des CRL, ASPA, RSC, TAK, distribution du cache et contrôle local.

Son statut ne doit pas être grossi. Datatracker le classe comme Internet-Draft individuel, sans flux RFC, Area Director responsable ni date de telechat. Son en-tête vise un texte informatif qui mettrait à jour RFC 8897 s’il était approuvé. Les références à des travaux SIDROPS encore actifs sont expressément provisoires. Il ne prouve ni adoption par le groupe de travail, ni consensus IETF, ni mise en œuvre.

L’intérêt du texte tient néanmoins à une inflexion nette. Une nouvelle section opérationnelle demande que le logiciel puisse exporter l’état validé dans une forme stable et lisible par machine, fournir assez de diagnostic pour expliquer les échecs de récupération, de synchronisation, d’analyse ou de validation, et conserver les anciens résultats pour comparaison, relecture ou analyse ultérieure.

Ces capacités forment ensemble une piste de décision. L’export dit ce que contenait l’état. Le diagnostic dit pourquoi d’autres objets n’y figuraient pas. L’historique dit quand cette frontière a changé.

Plusieurs horloges, plusieurs possibilités de divergence

Certificats, CRL et ROA sont sensibles au temps. Les manifestes deviennent périmés. RRDP possède ses propres sessions et chemins de récupération. La relation cache-routeur ajoute période de rafraîchissement, délai de nouvelle tentative et expiration. L’horloge du serveur de cache compte elle aussi. Deux validateurs lancés à quelques minutes d’écart peuvent ainsi produire des vues différentes sans qu’un seul bit cryptographique soit faux.

Le projet renforce quelques limites. Un client RRDP doit appliquer la politique de même origine de RFC 9674 et devrait détecter puis corriger la désynchronisation selon RFC 9697. L’absence, l’invalidité ou la péremption d’un manifeste, l’impossibilité de récupérer un fichier annoncé, une empreinte incorrecte ou un mauvais emplacement doivent provoquer un échec de récupération selon les règles référencées. Le manifeste courant et la CRL sont liés pour déterminer la révocation d’un certificat.

Un voyant agrège ces cas. Une piste d’audit doit les séparer. Il faut savoir quel dépôt a échoué, avec quel protocole, à quelle heure, si un instantané a remplacé les deltas et quels objets ont été rejetés. Autrement, la synchronisation suivante transforme une divergence explicable en mystère rétrospectif.

Le contrôle local n’est pas la vérité globale

SLURM permet à un opérateur d’ajouter ou de filtrer localement des données de validation d’origine. L’architecture accepte donc que la continuité opérationnelle et la politique locale produisent une vue différente de celle issue des seuls dépôts. Cette latitude peut être prudente. Elle devient dangereuse lorsqu’elle n’est pas nommée.

Une assertion locale ne modifie pas l’objet publié. Elle modifie la vue remise au réseau de cet opérateur. La distinction protège les deux côtés : l’opérateur peut justifier et retirer son exception ; l’autorité de certification ou le détenteur de ressources ne se voit pas attribuer une décision qu’il n’a pas prise.

Le même principe vaut pour les ancres de confiance, la version du logiciel et la stratégie de reprise. Deux caches verts ne sont pas nécessairement équivalents. Leur égalité doit être démontrée par une représentation canonique, des configurations comparables et des chemins de validation documentés.

Le reçu d’état de validation

Le projet ne définit pas ce reçu. La proposition de Daniel Kade vise à relier des preuves sans publier un fichier de configuration secret ni concentrer le contrôle dans une plateforme mondiale.

Le premier bloc identifie l’exécution : produit, version, profil de validation, empreinte de configuration, familles d’objets activées, ensemble d’ancres et état de l’horloge. Toute modification substantielle ouvre une nouvelle époque.

Le deuxième décrit l’acquisition : points de publication tentés, protocole utilisé, dernière observation réussie, tentative courante, repli ou récupération et catégorie d’échec. Une information sensible peut être regroupée, mais une absence ne doit jamais être maquillée en succès.

Le troisième fixe la validation : état des manifestes et CRL, nombres d’objets acceptés et rejetés par type, motifs de rejet, transition d’ancre et empreinte canonique du cache. Le profil normatif doit être référencé, faute de quoi la relecture appliquerait peut-être d’autres règles.

Le quatrième isole le contrôle local : identifiant de politique, approbation, période d’effet et empreinte de la transformation. Le cinquième décrit la livraison : version RPKI-to-Router, session, série, heure d’export et périmètre des consommateurs. Le dernier pointe l’état précédent, la durée de conservation, le système responsable et le mécanisme de correction.

Ce qui reste hors preuve

Ce reçu ne prouverait ni la correction de chaque publication, ni le choix ultérieur d’un routeur, ni le motif humain d’une exception. Il ne ferait pas d’un projet individuel une norme. Il ne départagerait pas automatiquement deux implémentations divergentes. Il rendrait seulement leur divergence examinable.

La retenue compte aussi pour la confidentialité. Clés privées, identifiants d’accès et topologie inutile n’ont rien à faire dans le reçu. Une empreinte, une classe d’erreur ou une référence conservée peut suffire. L’objectif est une preuve portable sous politique de divulgation, pas un nouveau centre de commande.

Passer du voyant à la preuve signifie accepter qu’un relying party est un composant continu : il a des époques, des reprises, des exceptions et des consommateurs. Si son résultat influence la sécurité du routage, ces transitions font partie de la gouvernance. Le cache vert reste utile. La piste d’audit explique ce qu’il veut dire.

Sources

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification
  3. Lu Heng — Why BTW Media Exists
  4. Projet RPKI RP, révision 00
  5. Statut Datatracker
  6. Historique Datatracker
  7. Groupe SIDROPS
  8. RFC 8897 — Exigences des relying parties RPKI
  9. RFC 6480 — Infrastructure pour sécuriser le routage
  10. RFC 9286 — Manifestes RPKI
  11. RFC 9674 — Politique de même origine pour RRDP
  12. RFC 9697 — Désynchronisation des sessions RRDP
  13. RFC 9691 — Clés d’ancre de confiance RPKI
  14. RFC 8416 — SLURM
  15. RFC 8210 — Protocole RPKI-to-Router v1
  16. RFC 9582 — Autorisations d’origine de route
  17. RFC 9829 — Extensions de numéro de CRL RPKI