Résumé

  • Le 28 août 2026, l’IETF a ouvert jusqu’au 11 septembre le dernier appel sur un projet de bonne pratique pour les moteurs de publication RPKI et leurs dépôts RRDP et rsync. Le texte n’est pas encore une BCP approuvée.
  • La nouvelle notification RRDP ne doit pas être visible avant le snapshot et les deltas qu’elle désigne. Avec plusieurs serveurs, il faut maintenir le client sur une vue cohérente ou rendre les données présentes partout avant d’exposer la notification quelque part.
  • Un numéro de série reçu atteste la réponse d’un point de service. Il n’atteste ni la disponibilité globale des octets, ni leur validation RPKI, ni leur prise en compte par un routeur.

Le client reçoit une notification portant un nouveau numéro de série. Il demande le delta annoncé, mais le répartiteur l’envoie vers un autre serveur, encore vide. Le delta répond 404. À la connexion suivante, un ancien serveur renvoie un numéro inférieur. Le problème ne vient pas d’une signature cassée : le service a annoncé son futur avant d’avoir terminé son présent.

C’est le mécanisme le plus instructif du dernier appel du 28 août. Le projet de BCP dit qu’une notification ne peut précéder les fichiers qu’elle référence. Cette exigence porte sur la vue publique, pas seulement sur le disque du serveur d’origine.

La date compte. Les commentaires sont sollicités jusqu’au 11 septembre. Le texte reste à l’étude et ne démontre aucun incident chez un opérateur nommé. Il fournit une proposition de contrôle que la communauté peut encore préciser.

L’index est une promesse de disponibilité

RRDP sépare le fichier de notification des snapshots et deltas. Selon RFC 8182, la notification donne au relying party la session, le numéro de série et les références nécessaires à la synchronisation. Afficher ce fichier revient donc à déclarer que son contenu est utilisable.

Sur un serveur unique, il suffit en apparence d’écrire les données puis l’index. Avec plusieurs nœuds, deux stratégies deviennent possibles. L’affinité dirige les requêtes successives d’un client vers le même nœud et sa chronologie locale. L’autre stratégie diffuse d’abord tous les snapshots et deltas à tous les nœuds, puis seulement la notification. Dans les deux cas, la référence ne doit jamais dépasser le référent.

Un CDN fait partie de cette réalité. Un 404 mis en cache avant la création d’un delta peut survivre à sa publication. Une notification gardée trop longtemps peut retarder le client. Une connexion keepalive vers un nœud retiré peut encore livrer une ancienne session pendant que d’autres connexions voient la nouvelle. Le registre de déploiement décrit ce qui devait exister; les sondes externes montrent ce qu’un client pouvait obtenir.

Le recul d’un numéro de série illustre la limite de la norme. RFC 8182 ne dicte pas la réaction du relying party. Certains produits peuvent reprendre un snapshot complet. Cette réaction récupère peut-être une vue cohérente; elle ne décide pas quelle vue précédente représentait l’intention de la CA.

L’erreur d’ordre se transforme en charge

Un delta manquant ne produit pas seulement une erreur. Le client peut demander le snapshot, bien plus volumineux, puis basculer vers rsync si ce téléchargement échoue. Au cycle suivant, il peut recommencer par un snapshot. Multipliez cette séquence par les relying parties et une notification prématurée devient un amplificateur de trafic.

Le projet recommande donc de surveiller la capacité, la mémoire, les E/S disque et les bascules inattendues vers les snapshots depuis un RP témoin situé hors du réseau. Ces mesures doivent conserver la session, le numéro de série, le serveur, l’URI et le résultat HTTP. Sans cette jointure, une hausse de bande passante ne distingue pas la demande normale d’une reprise provoquée par une incohérence.

Les anciens snapshots et deltas devraient rester servis deux heures après leur disparition de la dernière notification. Ce délai aide les clients lents et les requêtes déjà engagées. Il ne corrige pas une notification nouvelle publiée trop tôt. Garder le passé ne crée pas les octets manquants du futur.

Chaque étape signe un reçu différent

En amont, une autorité de certification produit des objets signés et les soumet au moteur par RFC 8181. Une requête list préalable permet de comparer l’état attendu. Une requête multi-éléments réduit le risque de publier à moitié un changement conçu comme atomique.

Puis les responsabilités se séparent. La CA atteste son intention locale. La réponse RFC 8181 atteste ce que le moteur a accepté. La notification décrit ce qu’un point a annoncé. Le téléchargement atteste les octets remis. La validation atteste le résultat d’un RP sous ses ancres et son état. L’alimentation d’un routeur, sa politique et le passage d’un paquet restent trois faits supplémentaires.

Un objet disponible peut échouer à cause du manifeste, de la chaîne de certificats, de la CRL ou des règles propres à son type. Un ROA valide n’affirme pas qu’une route BGP est actuellement annoncée. Cette séparation rejoint les couches de réalité de Heng Lu : publication, validation et effet ne sont pas interchangeables.

La partie rsync du projet décrit un autre symptôme. Si l’arborescence change pendant une lecture, le client peut recevoir un mélange fantôme d’anciens et de nouveaux fichiers. Construire un répertoire complet, fixer ses horodatages puis déplacer un lien symbolique offre une bascule unique. RRDP et rsync n’emploient pas le même dispositif, mais appliquent la même discipline : préparer l’état avant de le rendre visible.

Un numéro croissant n’est pas une horloge

La monotonie aide à ordonner les mises à jour d’une session. Elle ne mesure ni l’âge réel ni la justesse. Un serveur peut augmenter ses numéros en diffusant tardivement. Après une restauration de sauvegarde, masquer une régression sous le numéro suivant ferait croire à une continuité inexistante.

Le projet exige alors une nouvelle session RRDP et recommande d’avertir les CA dépendantes afin qu’elles resynchronisent leur contenu. Le reset est un aveu contrôlé de rupture. Il ne recrée pas les changements perdus, les éditeurs récemment ajoutés ou les manifestes qui approchent de leur échéance.

La primauté du code exécuté impose donc des requêtes réelles sur les chemins réels. La distinction entre contrôle formel et pratique demande qui peut bloquer une notification, purger le CDN, vider les connexions anciennes, réinitialiser la session et conserver l’état précédent.

La règle « notification en dernier » ne résout pas toute la sécurité du routage. Elle garantit seulement qu’une promesse minimale commence par quelque chose de vérifiable : quand l’index paraît, les octets qu’il nomme existent déjà là où le public peut les demander.

Sources