Résumé

  • La RFC 8210 définit le numéro de série comme une version logique croissante et cyclique dans une lignée de cache; les valeurs ne sont pas comparables entre caches, sessions ou versions du protocole.
  • La réception complète par le routeur, la session, les temporisations de rafraîchissement et d’expiration et l’observation de validation amont sont des preuves distinctes.
  • La fraîcheur exige un registre de synchronisation daté, pas un classement mondial des caches par numéro de série.

Le piège paraît évident après coup. Le cache A affiche 90 000 et le cache B 12 000; un tableau de bord déclare A plus récent. Chaque nombre peut être juste, mais la conclusion ne l’est pas.

Selon la RFC 8210, le Serial Number est un entier non signé de 32 bits, strictement croissant et cyclique. Il représente la version logique d’un cache. Celui-ci l’incrémente après une mise à jour réussie depuis un cache parent ou les données RPKI primaires, et ne doit pas diffuser le nouvel état avant la fin de la récupération.

Cette chronologie n’existe que dans son périmètre. Les numéros ne sont pas commensurables entre caches ou versions du protocole et ne doivent pas être conservés après chaque réinitialisation. Le Session ID identifie une instance du cache et relie cette instance à sa suite de numéros. Une comparaison valide exige donc version du protocole, session et numéro.

Un cache récemment démarré peut détenir des données actuelles avec un faible numéro. Un cache ancien peut avoir un numéro élevé alors que sa dernière récupération amont est plus vieille. La valeur seule n’est qu’une position dans une séquence locale.

Le dialogue RTR ajoute une autre limite. Le routeur demande les changements depuis son numéro courant. Le cache renvoie l’ensemble minimal nécessaire ou impose un Cache Reset s’il ne possède plus l’historique. Le routeur n’adopte le numéro de l’End Of Data qu’après avoir reçu la réponse complète. Une notification n’est qu’une invitation à interroger le cache.

La RFC 8210 sépare aussi explicitement temps et séquence. Refresh et Retry règlent les interrogations ultérieures. Expire limite la durée pendant laquelle des données déjà reçues peuvent rester en usage sans nouvelle requête réussie. Le compte à rebours commence à la réception de l’End Of Data; le numéro n’indique pas le temps restant.

La RFC 9286 confirme cette séparation. Un manifeste possède un manifestNumber croissant, mais aussi thisUpdate et nextUpdate, avec des règles propres aux manifestes périmés ou prématurés. Ordre logique et validité temporelle sont deux éléments de preuve.

Un registre de fraîcheur doit donc conserver identité du cache, version du protocole, Session ID, numéro, heure de réception complète, intervalles de rafraîchissement et d’expiration, dernière validation amont et contexte des ancres de confiance. Il peut prouver ce qu’un routeur avait reçu à une heure donnée; il ne peut déduire du numéro seul l’état des autres caches ou la convergence de tous les dépôts.

Aucun cache réel ni incident de données périmées n’est allégué. Le numéro est fiable précisément lorsqu’il reste dans la lignée qui lui donne son sens.

Sources