Résumé

  • Le relevé du 14 septembre 2026 montre 32 deltas RRDP consécutifs, des numéros 96961 à 96992, sous un même identifiant de session.
  • Les en-têtes publics Last-Modified des deux extrémités sont séparés de 425 minutes ; cet intervalle observé ne constitue ni une garantie de sept heures ni un délai de service.
  • Selon le RFC 8182, un client ne peut rejouer les deltas que si toute la suite manquante est disponible ; sinon, il traite l’instantané courant.
  • Une fiche de continuité, limitée au temps, aux volumes, aux changements de session et aux essais de repli, rendrait cette frontière exploitable sans surveiller les utilisateurs.

Un redémarrage, deux chemins

La question apparaît souvent après une opération parfaitement banale. Un validateur RPKI a été arrêté pour une mise à jour, une bascule de site ou une intervention sur le stockage. À son retour, il connaît encore trois éléments : l’adresse de la notification RRDP, l’identifiant de session précédemment vu et le dernier numéro de série appliqué.

Le nouveau fichier de notification lui présente l’état courant. Si la session n’a pas changé et si tous les numéros intermédiaires figurent encore dans la liste, le validateur télécharge les deltas nécessaires, vérifie leurs empreintes et avance étape par étape. Si un seul maillon indispensable manque ou est rejeté, il ne peut pas fabriquer l’état intermédiaire. Il doit alors récupérer l’instantané complet indiqué par la notification.

Ce repli n’est pas une panne. C’est une fonction normale du protocole. Il modifie cependant la quantité de données à transférer, le travail local et le temps de retour à un état frais. Pour l’exploitant, la différence entre les deux chemins est concrète, même si le résultat cryptographique final doit être le même.

Le relevé public du 14 septembre

La capture bornée de la notification RRDP d’AFRINIC, effectuée à 16 h 49 UTC, porte l’identifiant de session 8fe3109e-2561-4627-8850-83ab94b9bb91 et le numéro courant 96992. Elle référence exactement 32 deltas. Une fois classés par numéro, ils forment une suite complète de 96961 à 96992.

La notification était servie avec max-age=60 et une possibilité de contenu périmé en cas d’erreur. Ce délai d’une minute correspond à la recommandation du RFC 8182 pour le fichier que les clients consultent afin de découvrir un nouvel état. Il n’y a pas ici de décalage à dénoncer.

Les métadonnées HTTP donnent aussi deux repères. Le delta 96961 affiche comme dernière modification le 14 septembre à 07 h 40 min 05 s UTC ; le delta 96992, 14 h 45 min 06 s. L’écart est de 425 minutes. L’instantané courant se trouvait sur le même domaine rrdp.afrinic.net et a répondu HTTP 200 au contrôle limité.

Ces éléments décrivent fidèlement une photographie. Ils ne promettent pas que 32 deltas couvriront toujours sept heures et cinq minutes.

Le nombre de versions ne mesure pas le temps

Un numéro de série progresse avec les événements de publication. Son rythme dépend donc des certificats, listes de révocation, manifestes, ROA et autres objets effectivement mis à jour. Trente-deux versions peuvent s’accumuler lors d’une rafale ou s’étaler pendant une période calme. La prochaine chaîne de même longueur peut couvrir un horizon très différent.

Le protocole lie en outre la conservation à un arbitrage de volume. Le RFC 8182 demande au serveur d’écarter les anciens deltas dès que leur taille cumulée avec tous les deltas plus récents dépasserait celle de l’instantané. Le point de départ est choisi par le dépôt selon cet équilibre. Il n’est pas défini comme un engagement en heures ou en jours.

Cette règle est rationnelle : il serait absurde de forcer un client à télécharger une série différentielle plus lourde que l’état complet. Elle signifie aussi qu’un simple compteur ne permet pas de budgéter une reprise. Il manque au moins les octets de l’instantané, les octets cumulés des deltas et le rythme temporel auquel la frontière se déplace.

Une preuve publique adaptée à l’exploitation

La déclaration de pratiques de certification RPKI d’AFRINIC confirme la prise en charge de RRDP et nomme précisément l’URL de notification. C’est un engagement de méthode. Le fichier courant prouve, lui, la chaîne disponible à un instant donné. Entre les deux manque un objet de continuité destiné à l’exploitant.

Cette fiche pourrait être courte. Elle indiquerait la date d’observation, la session, le numéro courant, le premier numéro conservé, le nombre de deltas et l’intervalle temporel observé. Elle ajouterait les tailles compressées et décodées de l’instantané, le volume total des deltas conservés, les changements récents de session et le résultat d’essais contrôlés des deux chemins de reprise.

La présentation devrait empêcher les confusions. L’intervalle serait une mesure, pas un SLA. La réussite d’un téléchargement ne prouverait pas la validité de chaque objet signé. Une validation correcte ne dicterait pas la politique BGP de l’opérateur. L’état du CDN, la publication du dépôt, le traitement du validateur et la décision de routage conserveraient chacun leur colonne.

Ce que les données ne permettent pas d’affirmer

Rien dans cette capture ne démontre que 32 deltas sont insuffisants ou contraires au standard. Aucun validateur réel n’a été observé hors de la chaîne. Aucun échec d’empreinte, retard de route, objet invalide, indisponibilité du dépôt ou dommage à un membre n’est établi. Les deux deltas échantillonnés et la référence d’instantané répondaient au moment du contrôle.

La limite est informationnelle. La machine dispose de ce qu’il lui faut pour choisir entre deltas et instantané. L’être humain responsable d’une fenêtre de maintenance ne dispose pas encore d’une mesure stable du travail associé à ce choix. Une fiche datée ferait ce lien sans transformer une observation en promesse.

Sources principales