Résumé

  • RFC 9674 impose aux URI de Snapshot et de Delta ainsi qu’aux cibles de redirection de conserver le schéma, l’hôte et le port du fichier de notification RRDP.
  • Le fait que deux noms appartiennent au même opérateur, utilisent HTTPS ou servent les mêmes octets ne leur donne pas la même autorité de protocole.
  • L’acceptation de l’origine précède d’autres contrôles : forme RRDP, session, série, hash, certificats, CRL, manifeste, objets signés, cache validé, routeur et politique de routage.

Le contrat d’hébergement disait que les deux domaines appartenaient à la même équipe. Le certificat TLS était valide sur chacun. La copie du Snapshot portait le hash attendu. Pour l’exploitation, il s’agissait d’un simple déplacement de CDN. Pour RRDP, la notification avait désigné un principal et la redirection en avait choisi un autre.

Le RFC 9674 oblige alors le Relying Party à refuser la session. La disponibilité de la cible n’est pas en cause. La règle demande si le document obtenu à une origine a le droit de provoquer une requête vers l’autre.

« Même opérateur » n’est pas un tuple de sécurité

Le RFC 6454 définit l’origine avec trois composantes : schéma, hôte et port. Changer https en http modifie la protection contre l’attaquant réseau. Changer le nom d’hôte déplace la requête vers un autre principal, même sous le même domaine supérieur. Changer de port expose un autre service. Une convention interne ne remplace aucune de ces composantes.

Le RFC 8182 part d’une URI rpkiNotify placée dans le SIA d’un certificat de ressources. Elle mène au fichier de notification qui indique session, série, Snapshot courant et Deltas disponibles. La première version exigeait HTTPS et des hashes, mais n’interdisait pas explicitement les références interorigines ni les redirections qui franchissaient cette limite.

RFC 9674 ajoute la règle symétrique. Le serveur doit garder chaque uri de Snapshot ou de Delta dans l’origine de la notification et ne doit pas rediriger ailleurs. Le client doit comparer, refuser le fichier ou la session en cas d’écart et devrait journaliser l’événement.

Il ne s’agit pas de transposer tout le navigateur dans RPKI. Cookies, scripts et CORS ne sont pas le sujet. Le mécanisme importé est la protection par URI : une référence certifiée à un fichier de notification ne devient pas une délégation silencieuse de consommation de ressources à n’importe quel serveur.

Une redirection reste une nouvelle décision

Le RFC 9110 décrit la redirection comme une demande d’action supplémentaire vers une autre URI. Dans un rapport de disponibilité, le détail peut disparaître derrière le statut final 200. Dans un rapport RRDP, cette disparition détruit la preuve principale.

Le journal utile conserve l’URI SIA, l’origine normalisée, la référence demandée, chaque code HTTP, chaque cible Location et la comparaison effectuée avant le prochain saut. Le dernier hôte seul ne suffit pas. Une première réponse autorisée ne bénit pas toutes les cibles qu’elle nomme.

Le hash ne corrige pas cette omission. Il peut montrer que les octets du Snapshot ou du Delta correspondent à ceux annoncés. Il ne retire pas la charge imposée au client ou au serveur tiers. RFC 9674 vise précisément le cas où un dépôt pourrait accroître la consommation d’autres dépôts et des clients par référence ou redirection interorigine.

Par conséquent, « téléchargement réussi » et « récupération autorisée » sont deux résultats. La même opération peut être verte pour le premier et rouge pour le second.

L’origine ne valide pas le dépôt

Une URI conforme ouvre seulement la porte aux contrôles du RFC 8182. La notification doit être bien formée et conforme au schéma. Le session_id n’a de sens qu’avec l’emplacement de la notification. Une chaîne de Deltas doit être continue lorsqu’elle est utilisée. Les octets récupérés doivent correspondre aux hashes annoncés. Session et série des fichiers doivent rester cohérentes.

Le rejet d’un Delta peut conduire au Snapshot ; le rejet du Snapshot rend RRDP inutilisable. La section consacrée aux pannes permet d’essayer un autre mécanisme publié dans le SIA. Ce nouvel essai n’absout pas la session rejetée : il ouvre une autre chaîne de récupération.

Surtout, RFC 8182 laisse la validation des objets RPKI hors de son périmètre. Le RFC 6480 sépare l’infrastructure de certificats, les objets signés et leur dépôt distribué. Le RFC 6487 fixe le profil des certificats et CRL. Le RFC 9286 donne au manifeste son numéro, ses dates et son inventaire de noms et hashes. Ces décisions ne sont pas contenues dans le test d’origine.

Un Snapshot peut donc être récupéré de la bonne origine et échouer ensuite sur un certificat, une CRL, un manifeste ou un objet signé. À l’inverse, refuser une cible interorigine ne dit rien sur l’intention de son opérateur. La trace établit une violation de politique, pas une attaque.

La route se trouve encore plusieurs reçus plus loin

Le RFC 7115 appelle cache validé l’ensemble effectivement vérifié par le RP. Le RFC 8210 décrit ensuite l’échange entre cache et routeur, avec version de protocole, session et série propres. Le RFC 6811 produit enfin un état de validation d’origine que la politique locale peut utiliser.

La chaîne professionnelle doit donc nommer ses sujets : autorité de récupération ; intégrité RRDP ; validation cryptographique ; payload validé ; ingestion du routeur ; décision de politique ; route sélectionnée ; trafic observé. Un voyant « RPKI OK » qui les fusionne ne simplifie pas la réalité. Il supprime la possibilité d’expliquer un désaccord.

La donnée historique du RFC 9674 doit elle aussi garder son sujet. Le texte indique qu’aucune référence interorigine n’avait été observée dans les archives examinées d’octobre 2021 à octobre 2024, et qu’un serveur utilisait une redirection de même origine dans la période d’avril à septembre 2024. Cela soutenait la déployabilité de la règle au moment de l’étude. Ce n’est pas un inventaire mondial actuel.

Gouverner la frontière avant le prochain déplacement

Une migration de CDN, une consolidation de noms ou un changement de port peut sembler neutre puisque les octets restent identiques. Pour RRDP, l’opération modifie l’autorité si le tuple change. Il faut donc tester les notifications et toutes les redirections avant bascule, puis observer les refus côté clients.

Le minimum commun défendu dans Spécification initiale minimale est ici très précis : une notification, une origine, aucune délégation implicite. Les couches de réalité empêchent ensuite de confondre le label organisationnel, l’URI, les octets et la décision de routage. La primauté du code exécuté exige enfin des traces du RP et du routeur avant de parler d’effet opérationnel.

RFC 9674 ne certifie pas le dépôt. Il oblige le dépôt à reconnaître où son pouvoir de récupération s’arrête. Cette modestie est sa force.

Sources