Résumé

  • La RFC 9507 adapte traceroute à CCNx et NDN : les requêtes suivent un nom, les données reviennent grâce à l’état hop par hop de la table des intérêts en attente, et le nom ne désigne pas un point final unique.
  • Un nonce empêche l’agrégation ordinaire des sondes ; quatre codes distinguent un saut, un nom administratif, une application locale et un objet en cache ; un Path Label peut maintenir la sonde suivante sur la branche observée.
  • La séquence prouve une route de réponse dans des conditions données. Elle ne prouve ni l’origine du contenu, ni toutes les routes disponibles, ni le comportement d’un intérêt ordinaire, ni le résultat du service.

Le dernier relais répondit en moins de dix millisecondes. Son nom était signé, les six sauts formaient une chaîne propre et la sonde s’arrêtait sur l’objet demandé. L’écran suggérait une conclusion simple : le réseau avait trouvé le chemin vers le contenu.

En réalité, il avait trouvé une copie en cache. Une autre requête portant le même nom pouvait être dirigée vers un producteur différent, une autre mémoire intermédiaire ou une autre branche. Le diagnostic avait réussi sans atteindre ce que l’équipe appelait, par habitude, « le serveur d’origine ». Dans un réseau centré sur l’information, ce décalage n’est pas une anomalie ; il est la propriété même que l’outil doit rendre visible.

La RFC 9507, publiée en mars 2024 dans le flux IRTF avec le statut Experimental, décrit cet outil pour CCNx et NDN. Ce n’est pas une norme de l’IETF. Le texte propose un protocole d’expérimentation et de dépannage dont la prudence est essentielle : il observe au moins une route vers un nom, dans un environnement où le nom, la source et la route ne se confondent pas.

Le nom change la géométrie du diagnostic

Dans le traceroute IP classique, le client augmente progressivement le TTL. Le routeur où le paquet expire renvoie un message ICMP vers l’adresse source. Malgré les asymétries et les politiques de filtrage, l’instrument s’organise autour d’une adresse de destination.

Un intérêt ICN n’a pas d’adresse source. Il désigne une unité de données, et la réponse reprend en sens inverse l’état installé dans les tables PIT des relais. Un même nom peut être servi par une application, plusieurs producteurs ou des Content Stores placés dans le réseau. Deux intérêts successifs peuvent donc suivre des routes différentes et rencontrer des détenteurs différents de la même donnée.

À cela s’ajoute l’agrégation. Plusieurs intérêts identiques arrivant au même relais peuvent partager une entrée PIT. Le mécanisme économise des transmissions, mais il compromet une expérience qui suppose que chaque sonde a réellement parcouru son propre trajet. La durée d’une entrée et la requête déjà en vol peuvent raccourcir le temps apparent, même si la charge n’a pas changé.

La sonde de la RFC 9507 ajoute alors un segment de nom contenant un nonce de 64 bits en CCNx. La forme NDN combine le nom cible, un nonce et le suffixe traceroute. Chaque requête devient unique pour la PIT et chaque réponse peut être rattachée à sa sonde. Le nonce reste toutefois ignoré lors de la recherche dans le Content Store : la sonde est distincte, mais la vérification de l’objet porte toujours sur le nom visé.

Cette distinction mérite d’être conservée dans les journaux. Le nonce identifie l’expérience ; il ne crée ni une nouvelle ressource ni une origine.

Quatre codes, quatre réalités

Le client commence avec une HopLimit de 1, puis l’augmente. Chaque relais vérifie et décrémente cette limite. S’il reste des sauts, il consulte le cache, crée l’état PIT, applique la plus longue correspondance de préfixe et, le cas échéant, la valeur de guidage. En l’absence de prochain saut valable, CCNx renvoie « No Route » et NDN un NACK réseau.

Quand la limite atteint zéro, le relais répond avec son nom administratif : le code 4 signifie uniquement que la sonde a atteint la distance demandée. Ce n’est pas un acquittement du contenu.

Trois conditions terminent sémantiquement la session. Le code 1 indique que la cible correspond au nom administratif d’un relais. Le code 2 indique qu’une entrée FIB trouvée par plus long préfixe mène à une application locale. Le code 3 indique qu’un objet du Content Store correspond exactement au nom, sauf si le client a refusé les réponses de cache.

Réduire ces résultats à un indicateur « joignable » efface le mécanisme. Un cache accessible peut masquer un producteur indisponible. Une face d’application locale prouve une remise au processus, pas son travail utile. Un nom administratif validé permet de joindre le plan de gestion, pas d’attester la provenance d’une donnée. Et le code 4 ne prétend rien au-delà du saut observé.

Un Path Label fixe l’expérience, pas l’avenir

Le multipath pourrait fabriquer une trace incohérente : la sonde de limite 2 emprunte une branche, celle de limite 3 une autre. La liste finale mélangerait alors des relais qui n’ont jamais constitué une seule route.

La RFC s’appuie sur le guidage défini par la RFC 9531. Le relais qui produit la réponse initialise le Path Label ; chaque relais du chemin retour l’enrichit avec son choix de prochain saut. Le client peut reprendre cette valeur dans la requête suivante afin de suivre la même branche. Pour chercher un autre trajet, il peut omettre l’étiquette lors d’une nouvelle session.

L’étiquette améliore la reproductibilité. Elle n’est pourtant ni un identifiant éternel de route, ni une carte exhaustive. Elle condense des décisions prises à un instant précis, avec une FIB, une stratégie de transfert, des caches et une topologie déterminés. La rejouer teste la possibilité de reprendre cette branche. Ne pas trouver d’alternative ne démontre pas qu’elle n’existe pas.

Une conclusion fidèle mentionne le nom, le nonce, l’heure, les limites, l’étiquette et le code terminal. La phrase « voici le chemin du contenu » retire précisément ce qui rend la mesure interprétable.

La signature a elle aussi un périmètre

Le nom administratif retourné sert à demander ensuite des informations de gestion plus riches. Sans protection, un relais malveillant pourrait inscrire le nom d’une victime et détourner vers elle ces requêtes ultérieures. En CCNx, le producteur de la réponse doit donc signer son propre nom ; le client récupère sa clé publique et vérifie la signature.

Cette mesure bloque la substitution simple d’un nom innocent. Elle n’empêche pas un relais compromis déjà présent sur le chemin de remplacer le nom et sa signature par sa propre paire valide. Une signature couvrant la réponse complète offre une protection plus large, au prix d’un calcul qui peut lui-même devenir une cible. Le texte recommande de confier ce traitement à une application de gestion locale distincte du relais principal.

Il faut donc enregistrer l’objet exact de la signature, la clé admise, le résultat de vérification et la protection éventuelle du message entier. L’adjectif « signé » ne suffit pas.

Les noms locaux dévoilent une frontière cachée

Un nom limité à une région n’est pas directement routable depuis le client. Une première solution joint un Link Object NDN signé, qui contient des préfixes routables jusqu’à l’entrée dans la région adéquate. La manière dont le client obtient cet objet reste hors du périmètre de la RFC.

La seconde solution préfixe le nom local par un nom routable. Le relais de frontière retire ce préfixe à l’entrée et doit restaurer le contexte nécessaire au retour. Il maintient ainsi un état supplémentaire et peut subir une amplification lors d’une attaque par flot d’intérêts.

Une archive qui ne garde que le nom final efface cette transformation et l’autorité de la frontière. Elle doit conserver le Link Object ou le préfixe ajouté, sa signature, le relais de réécriture et la transition régionale.

La force de la RFC 9507 vient de cette précision. Elle rend le réseau par noms observable sans lui inventer une destination unique. La trace peut établir une requête distincte, une branche cohérente, un motif de réponse et une identité vérifiée. La provenance du contenu, la complétude des routes, le succès applicatif et l’effet pour l’utilisateur demeurent des preuves différentes.

Sources