Résumé

  • Le RR HIP de RFC 8005 contient une identité publique HI, son HIT et, éventuellement, des noms de serveurs de rendez-vous. Il fournit des données de découverte, pas une preuve de présence.
  • DNSSEC et le TTL répondent à deux questions précises : l’authenticité des données DNS selon la chaîne de validation et la durée de réutilisation en cache. Ils ne certifient pas l’inscription courante auprès du RVS.
  • Une décision opérationnelle doit relier le RR choisi à l’inscription HIT-adresse, au relais de I1, à l’authentification fondée sur HI, à l’association HIP et au résultat applicatif.

Cinquante minutes de vert après le changement d’adresse

À 9 h, un résolveur obtient le RR HIP d’un nœud mobile. L’ensemble contient la HI attendue, son HIT et le nom d’un RVS. DNSSEC valide la réponse et le TTL vaut une heure. Une console transforme ces observations en un seul statut : « identité vérifiée et joignable ».

Douze minutes plus tard, le nœud change de réseau. La notification de sa nouvelle adresse au RVS échoue. Le DNS n’a pas menti : le nom de rendez-vous reste celui qui a été publié, la signature reste valide et le cache peut encore employer le RR. Lorsqu’un initiateur envoie I1, le RVS relaie toutefois vers l’ancienne adresse.

Ce scénario est construit ; il ne décrit ni produit ni panne réelle. Son intérêt vient de la coexistence de deux vérités. L’état DNS est frais. L’état d’acheminement ne l’est pas. La faute se trouve dans la console, qui fait répondre une publication à une question de fonctionnement instantané.

Des données publiques ne sont pas une démonstration privée

RFC 5205 a défini en 2008, avec le statut Experimental, le type DNS 55 destiné à HIP. RFC 8005 l’a remplacé en 2016 sur la Standards Track. Le RR peut transporter la composante publique de l’identité cryptographique, son identifiant dérivé et des noms de RVS.

Ces valeurs préparent l’échange. La HI permet à l’initiateur de connaître la clé publique du répondant ; le HIT en fournit un identifiant compact. La réponse DNS ne contient pas la clé privée et ne montre pas qu’elle est disponible au moment de la requête.

RFC 8005 recommande explicitement de ne pas authentifier un pair uniquement à partir d’un HIT obtenu par DNS. L’implémentation doit procéder à une authentification fondée sur la HI. Cette étape ultérieure montre l’usage cryptographique dans un échange donné. Elle ne peut pas être anticipée par une ligne de cache.

Ainsi, « HIT trouvé » et « pair authentifié » doivent rester deux événements. Les réunir dans un champ identity_ok supprime le moment où le pair aurait dû démontrer la clé.

DNSSEC garantit le transport d’une affirmation bornée

Sans protection, un adversaire qui modifie le RR HIP peut substituer une HI ou orienter I1 vers une autre destination. RFC 8005 demande donc un canal garantissant intégrité et authenticité et cite DNSSEC.

Le texte en fixe aussitôt la portée. La garantie va du serveur DNS qui publie la zone jusqu’au nœud HIP. Elle n’établit pas que l’entité qui publie la zone est digne de confiance. La signature RRSIG du RRset ne doit pas être interprétée comme un certificat liant la HI ou le HIT au nom propriétaire.

Un verdict DNSSEC secure est donc précieux, mais spécialisé. Il faut conserver l’ancre de confiance, les algorithmes, l’heure, la politique de validation et l’ensemble exact signé. On ne peut pas ajouter à ce verdict l’état électrique du nœud, la possession présente de la clé privée ou l’existence d’une route de paquets.

Une signature plus forte augmente la confiance dans l’énoncé ; elle n’agrandit pas l’énoncé.

Le TTL loue un cache, pas un service

RFC 8005 précise que le RR HIP doit être supprimé lorsque le temps écoulé depuis sa récupération dépasse son TTL. Si les données sont nécessaires pour communiquer, une nouvelle requête doit alors obtenir une copie fraîche.

Cette règle borne la réutilisation DNS. Elle ne réserve aucune ressource chez le RVS et n’oblige pas le répondant à garder sa clé disponible pendant toute la durée. Un TTL d’une heure n’est ni une promesse de disponibilité, ni un bail de chemin, ni un objectif de service.

Même une nouvelle requête peut rendre le même RR correctement signé alors que l’inscription HIT-adresse du RVS reste périmée. Elle renouvelle la connaissance de la publication, pas l’observation du système d’exécution.

L’automatisation aime pourtant le TTL parce qu’il produit une échéance calculable sans contacter le service. La règle sûre est : cacheAge < ttl autorise l’usage de la donnée DNS. Elle ne permet pas d’écrire endpointLive=true.

Le nom RVS et la table RVS ne relèvent pas de la même autorité

Pour la mobilité, le nœud publie dans DNS les noms de ses RVS et tient séparément ces serveurs au courant de ses adresses actuelles. RFC 8004 décrit l’inscription que le RVS consulte avant de relayer I1. Un RR HIP n’est donc pas une copie de cette table dynamique.

Le nom peut être correct tandis que l’inscription a expiré. Le RVS peut répondre au réseau mais ne plus connaître le HIT. Il peut aussi posséder une entrée qui pointe vers l’adresse précédente. Chaque situation exige un reçu différent : résolution du nom, état de l’inscription, décision de relais et réception au nœud.

La chaîne utile est :

RR publié → DNSSEC validé → TTL courant → RVS sélectionné → inscription courante → I1 relayé → HI authentifiée → association achevée → effet observé.

Un tableau de bord peut joindre ces colonnes. Il ne doit pas propager le vert de gauche à droite lorsqu’une colonne n’est pas observée.

Plusieurs RR interdisent l’aplatissement

Un même nom peut porter plusieurs RR HIP. RFC 8005 ne définit pas l’algorithme de choix. Il impose en revanche, lorsque plusieurs possibilités existent, de vérifier que le RVS employé est associé à la HI choisie.

Une base qui extrait toutes les identités dans une liste et tous les RVS dans une autre peut inventer des couples absents de la zone. Cette erreur devient probable pendant une rotation de clés ou une migration, quand ancien et nouveau parcours coexistent.

Le reçu doit donc garder l’unité du RR : HI, HIT, noms RVS, algorithme, durée, source et raison du choix. La provenance au niveau de l’enregistrement est une condition de diagnostic, pas un détail de stockage.

Le reçu qui manque au badge vert

Une preuve exploitable comprend le nom interrogé, le résolveur, le serveur faisant autorité, les horodatages et l’empreinte de la réponse ; chaque RR et ses associations ; le résultat DNSSEC et son ancre ; l’âge du cache et le TTL ; les A/AAAA du RVS avec leur propre état ; l’identifiant d’inscription, le HIT, les adresses, rafraîchissements et expirations ; les observations de I1 ; la transcription d’authentification HIP ; enfin le chemin de charge utile et le résultat applicatif.

Cette liste ne demande pas à un composant de tout voir. Le DNS atteste sa publication. Le RVS atteste sa table et son relais. Le pair atteste son usage de clé. L’application atteste l’effet. Là où la collecte s’arrête, la valeur honnête est inconnu.

RFC 8005 a ajouté le support ECDSA, clarifié le renouvellement après TTL, les RR multiples et le format de plusieurs RVS. Ces améliorations décrivent une spécification. Elles ne prouvent pas qu’un binaire déployé a migré. Version, build, configuration et trace réseau restent nécessaires.

La découverte HIP n’est pas affaiblie par cette discipline. Elle gagne une place claire dans la chaîne. Dans le scénario, une console exacte aurait affiché : « RR HIP sécurisé ; TTL courant ; inscription RVS non confirmée ; joignabilité inconnue ». C’est moins séduisant qu’un voyant unique, mais cela indique immédiatement où mesurer.

Sources