Résumé

  • Le couple session_id/serial situe un état RRDP, mais ne prouve pas que tous les relying parties ont reçu les mêmes octets. Si le hash d’un delta déjà observé change sous la même session et le même serial, l’historique incrémental n’est plus reproductible.
  • La réparation consiste à conserver la contradiction, avertir, charger le snapshot le plus récent et reprendre la validation RPKI. Un snapshot accepté ne valide pas un ROA et ne commande pas un routeur : manifest, certificats, CRL, objets signés, payloads validés et politique BGP gardent leurs compétences propres.

La salle de contrôle ouvre la journée sur une apparente unanimité. Les deux validateurs RPKI, placés dans des sites différents, indiquent la même session RRDP et le même serial courant. Les compteurs de VRP sont proches. Aucun téléchargement n’est marqué en échec. Le tableau de bord conclut que le dépôt est synchronisé.

Ce scénario est illustratif ; il ne décrit pas un incident attribué. Sur le premier site, le journal conservé la veille associe le delta 1774 à un hash A. Sur le second, une notification obtenue plus tard associe le même delta 1774, dans la même session, à un hash B. Chaque fichier téléchargé peut correspondre au hash visible au moment de sa propre récupération. Chaque validateur peut donc produire un journal local parfaitement vert.

Ils ne possèdent pourtant pas le même dépôt. Une publication, un remplacement ou un retrait peut avoir été appliqué sur un site et pas sur l’autre. Les Validated Payloads qui en résultent peuvent diverger, puis modifier différemment l’état d’origine d’une même route.

RFC 9697 donne un nom et une méthode à ce défaut. Le relying party garde les couples serial/hash d’une notification précédemment récupérée avec succès. Lorsqu’une nouvelle notification contient encore certains de ces serials, il compare les hash. Une différence pour un serial déjà vu signale une mutation inattendue. Le client devrait avertir et charger le dernier snapshot pour retrouver un état synchronisé.

La règle ne demande pas de croire davantage le dépôt. Elle demande au client de rendre une contradiction prouvable.

RRDP transforme une suite de publications en histoire rejouable

L’architecture exposée par RFC 6480 combine certificats de ressources, listes de révocation, objets signés et dépôts distribués. Ces dépôts rendent les données accessibles aux relying parties. Ils constituent un lieu de passage public, non la source de l’autorité cryptographique contenue dans les données.

RFC 8182 organise ce passage. Une URL stable de notification indique la session, le serial actuel, l’URI et le hash du snapshot, ainsi que les deltas encore disponibles. Le snapshot contient l’ensemble des éléments publish d’un état. Un delta décrit les ajouts, remplacements et retraits d’un seul incrément de serial.

Un validateur peut reconstruire le dépôt depuis le snapshot. S’il connaît déjà la session et si tous les deltas manquants forment une chaîne continue, il peut les appliquer dans l’ordre. Le session_id du delta doit correspondre à la notification. Son serial doit suivre immédiatement le dernier serial traité. Les octets téléchargés doivent produire le hash annoncé.

Lors d’un retrait ou d’un remplacement, le client vérifie aussi que la donnée visée avait été obtenue depuis ce même repository server. Une publication ne reçoit ainsi aucun droit implicite de supprimer ce qui provenait d’un autre dépôt.

Ces conditions rendent une transition locale vérifiable. Elles ne créent pas de transaction mondiale. Deux validateurs peuvent poller à des instants différents ou garder des caches d’âges différents. RFC 6811 reconnaît cette cohérence lâche de la vue RPKI mondiale.

Le temps explique qu’un validateur soit à 1774 et l’autre à 1775. Il n’explique pas que 1774 désigne deux contenus. Dans le premier cas, la progression peut faire converger les copies. Dans le second, continuer à incrémenter ne répare pas le passé dont elles sont parties.

Le nom d’une session ne suffit pas à identifier son auteur

Le UUID de session_id paraît universel. RFC 8182 interdit pourtant de l’utiliser seul. Un serveur malveillant pourrait reprendre la valeur d’un autre. La session est identifiée avec l’emplacement de la notification.

Chaque élément apporte une limite différente. L’URL situe le repository server. La session sépare une histoire d’initialisation d’une autre à cet endroit. Le serial ordonne les événements de cette histoire. Le hash attache un snapshot ou un delta à des octets particuliers.

Un outil qui ne compare que les UUID peut fusionner deux principaux distincts. Un outil qui ne compare que le serial maximal peut déclarer égales deux histoires divergentes. Un outil qui ne regarde que le dernier hash peut ignorer qu’un delta plus ancien, encore présent dans la fenêtre de notification, a changé.

La preuve utile comprend donc l’origine et l’URL de notification, la session, le serial courant, le snapshot, tous les couples serial/hash annoncés, le chevauchement avec la récupération précédente et le résultat d’application local. La santé n’est pas une couleur posée sur un nombre ; c’est une relation entre des traces.

L’immutabilité paie le coût de l’échelle

RRDP a été conçu pour une structure asymétrique : relativement peu de publications, beaucoup de relying parties. RFC 8182 permet de servir snapshots et deltas par HTTP et CDN parce que leur contenu et leur URL ne changent plus après leur apparition dans la notification. Un fichier pré-calculé peut être réutilisé par des milliers de clients.

Cette immutabilité est la contrepartie de l’économie réalisée. Si un même repère historique peut changer d’octets, un hit de cache ne garantit plus la reproduction de la même transition. Un edge CDN peut conserver A, un autre B. Les validateurs entrent alors dans des réalités différentes selon leur moment et leur chemin d’accès.

RFC 9697 ne transforme pas chaque client en archiviste permanent. Il suffit de garder les couples visibles dans la notification précédente et de les comparer à la zone de chevauchement suivante. Cette petite mémoire retire au distributeur la capacité de modifier silencieusement un passé encore actif.

Le message d’alerte doit conserver cette précision. « Échec RRDP » ne dit pas si le réseau est indisponible, si un delta manque ou si l’histoire a été réécrite. La constatation décisive est : pour la même URL, la même session et le même serial déjà vu, le hash annoncé n’est plus le même.

Revenir au snapshot réinitialise le transport, pas la confiance

Lorsqu’un delta manque ou échoue à ses contrôles, RFC 8182 impose le traitement du snapshot courant. RFC 9697 applique ce retour à la mutation d’un delta historique. Le validateur reçoit directement une image complète et cesse de composer les incréments contestés.

Le snapshot n’est pas un passage privilégié. Son format doit être accepté, ses octets doivent correspondre au hash de la notification, sa session doit être la bonne et son serial doit satisfaire les règles de progression. Si le snapshot échoue, RRDP ne fournit pas un nouvel état utilisable.

Le mot « fallback » dissimule aussi un changement de coût. Une flotte habituée à de petits deltas peut soudain demander des snapshots complets. Origine, CDN, liens, mémoire et CPU subissent la même pointe. Le backoff, le phasage, la capacité et une condition d’arrêt deviennent des contrôles de disponibilité.

Avant de remplacer l’état local, l’opérateur conserve les anciennes et nouvelles notifications ou leurs empreintes, les heures de récupération, la vérification d’origine, les couples en conflit et la cause du rejet. Sans ce dossier, le service peut revenir alors que l’organisation perd la possibilité de distinguer erreur de publication, incohérence CDN, défaut logiciel ou intervention hostile.

Un snapshot traité prouve seulement que ce validateur a reconstruit un dépôt cohérent avec cette notification. Il ne prouve ni la fraîcheur mondiale, ni la validité de tous les objets, ni la convergence des autres clients.

Same-Origin relie une annonce au coût de ses fichiers

La première version de RRDP utilisait des URI absolues sans interdire explicitement une référence ou une redirection vers une autre origine. RFC 9674 exige désormais que notification, snapshot et deltas partagent scheme, host et port, et interdit les redirections qui franchissent cette origine.

Une publication ne peut donc pas employer les validateurs pour imposer sa charge à un autre repository server. Le même principal qui annonce les ressources nécessaires à une session doit les servir. Le client qui rencontre une référence cross-origin rejette la session RRDP et enregistre l’événement.

Cette règle ne transforme pas HTTPS en validation RPKI. Le bon hôte peut livrer un objet expiré ou révoqué. Une erreur de certificat de transport ne permet pas non plus à un intermédiaire de produire une signature RPKI valide. L’origine identifie le serveur qui répond ; le hash RRDP relie le fichier à la notification ; les règles RPKI déterminent ensuite si le contenu peut être utilisé.

Publier, distribuer et valider sont trois verbes

RFC 8181 définit le protocole par lequel un moteur de CA demande à un service de publication d’ajouter, remplacer ou retirer une donnée RPKI. Les deux fonctions peuvent appartenir à des organisations différentes. La BPKI qui authentifie la demande de publication est distincte de la RPKI qui authentifie les données publiques.

Une réponse de succès signifie qu’un client autorisé a accompli une opération de dépôt. Elle ne signifie pas que le relying party acceptera le certificat, la CRL ou le ROA. À l’inverse, une intention de retrait correctement signée n’assure pas que le chemin repository–CDN–RRDP présentera immédiatement une histoire unique à tous les clients.

Cette distinction évite l’expression trop large « RPKI est cassé ». L’intention du CA peut être correcte et la distribution incohérente. La distribution peut être cohérente et l’objet invalide. La validation peut être correcte et le payload ne jamais atteindre les routeurs. Le routeur peut recevoir l’état et une politique locale décider de ne pas rejeter la route.

La réparation dépend du verbe qui a échoué.

Une signature ne prouve ni présence ni actualité

RFC 6488 définit les contrôles génériques des objets signés RPKI : structure CMS, certificat EE, type de contenu, digest et signature. Ils sont nécessaires mais pas suffisants ; chaque type d’objet ajoute ses propres conditions.

Un fichier correctement signé peut être ancien tout en restant dans sa période cryptographique. Une version plus récente peut être cachée. Un fichier attendu peut être omis. La signature révèle une modification non autorisée ; elle ne révèle pas seule l’absence ou le replay.

RFC 9286 donne au manifest ce rôle complémentaire. Il énumère les fichiers d’un CA publication point et le hash de chacun. Si le RP ne peut obtenir tous les fichiers énumérés, la récupération a échoué ; il ne peut pas appeler état normal le sous-ensemble arrivé par hasard.

Le manifest possède son propre manifestNumber, ses temps thisUpdate et nextUpdate, son nom et ses hash. RFC 9981 met à jour les contrôles de replay liés au numéro et encadre certains resets. Aucun de ces nombres n’est le serial RRDP.

RFC 6481 décrit la structure des publication points et la nécessité d’éviter qu’un RP observe un état intermédiaire où répertoire et manifest se contredisent. RRDP transporte une vue ponctuelle ; il ne peut pas réparer une séquence de publication incohérente à la source.

Le relying party mérite confiance en exposant son raisonnement

RFC 8897 rassemble les responsabilités de validation dispersées entre trust anchors, certificats, dépôts, manifests, objets signés et cache routeur. L’acquisition et la validation peuvent être séparées en composants, mais l’opérateur doit pouvoir relier les octets obtenus aux Validated Payloads produits.

Face à deux validateurs divergents, la question n’est pas « lequel est l’autorité ? ». Il faut comparer notifications, hash de delta, snapshot, manifest, certificats, CRL, rejets, trust anchors et versions logicielles. Le chemin reproductible, actuel selon les règles applicables et doté d’un retour sûr mérite une confiance provisoire.

La décision finale demeure locale. RFC 6811 impose de revalider les routes touchées lorsque les mappings prefix/origin changent et de relancer si nécessaire le processus de décision BGP. Il exige aussi que la politique puisse agir sur l’état de validation. Rejeter Invalid, diminuer sa préférence ou l’observer reste le choix du réseau.

Une mutation RRDP ne doit donc pas commander directement une purge de routes. Snapshot, manifest, certificat, objet signé, diff de payload, livraison au routeur, RIB, FIB puis paquets forment la chaîne de preuve. Le vert du validateur n’en est pas la dernière case.

Sources