Résumé

  • Le LSI de RFC 5338 emprunte la forme d’une adresse pour transporter localement une identité d’hôte dans une application ancienne ; sa signification dépend de la machine et de l’époque de traduction.
  • Un audit fiable conserve ensemble LSI, HIT, localisateurs, nom DNS, processus, horodatage et génération de table, sans confondre cette corrélation avec l’achèvement de l’association HIP.

La perte de contexte est une mutation de preuve

L’incident commence après coup. Un opérateur recherche une connexion et trouve 1.0.0.42 dans un journal d’application. La valeur ressemble à une adresse IPv4. L’équipe de réponse l’interroge dans les tables actuelles, découvre une identité HIP et conclut que cette identité était le pair observé la veille.

La conclusion peut être fausse même si chaque système fonctionne conformément à sa conception. La valeur était peut-être un Local Scope Identifier attribué par la pile HIP. Elle désignait un Host Identity dans la table locale à l’instant de l’événement. Après collecte, redémarrage ou réattribution, la même valeur peut ne plus rien désigner, ou désigner un autre hôte. Le journal n’est pas mensonger ; il est devenu incomplet.

RFC 5338 rend visible une erreur de gouvernance courante : la forme d’une donnée est prise pour son autorité. Une colonne nommée « adresse IP » donne à un jeton local l’apparence d’un fait mondial. Or le LSI est un index de compatibilité. Sans machine émettrice et sans génération de mapping, il ne possède pas une histoire autonome.

Le contrat de compatibilité s’arrête à l’appel système

Le document traite d’un système qui connaît HIP et d’une application qui ne le connaît pas. L’application continue d’utiliser une API fondée sur les adresses. Un agent de résolution peut lui remettre un LSI ou un HIT ; la pile maintient la correspondance et transforme la valeur lors de connect(), sendto() ou d’un appel voisin.

Ce dispositif est ingénieux parce qu’il évite de réécrire l’application. Il est limité pour la même raison : l’application n’a aucun vocabulaire pour exprimer la portée du jeton, l’identité cryptographique demandée ou le choix de chemin. Elle voit une structure familière et réutilise les comportements historiques associés aux adresses.

Pour un usage immédiat — obtenir une valeur de getaddrinfo(), puis la rendre au noyau — le modèle peut être exact. La pile productrice contrôle les deux extrémités de l’échange local. Dès que l’application conserve la valeur, la compare comme une identité, l’insère dans un protocole ou la transmet à une autre machine, elle sort du contrat qui rendait l’illusion sûre.

RFC 9063 précise qu’un LSI de trente-deux bits est une représentation locale de l’identité et qu’il n’est pas envoyé sur le réseau comme localisateur. La traduction vers le HIT appartient à la couche HIP. Ce n’est donc pas une adresse spéciale dont la route resterait à découvrir ; c’est un nom local dont l’interprète doit rester présent.

Une réponse DNS ne distribue pas la table locale

RFC 5338 envisage un agent local dans le processus DNS. Quand des informations HIP existent, l’agent peut remettre à l’application un identifiant au format d’adresse et conserver la correspondance avec l’identité d’hôte. Cette réponse est souvent le premier reçu visible, mais elle n’emporte pas les reçus suivants.

Le nom a été consulté. Une identité a été trouvée. Un handle a été attribué. Rien de cela ne prouve que les localisateurs sont encore joignables, que l’échange de base aboutira, que le trafic protégé passera ou que l’opération applicative sera acceptée. Le handle ne condense pas la chaîne ; il en ouvre une branche locale.

Le classement des résultats ne décide pas non plus du chemin réel. Le système peut placer les identifiants HIP avant les adresses ordinaires. Une application qui lance plusieurs tentatives en parallèle peut néanmoins terminer d’abord sur le chemin non-HIP. L’ordre de la liste représente une préférence du résolveur, pas un verdict d’exécution.

Une politique qui exige HIP doit donc observer ou imposer la sélection, au lieu de déduire le résultat de la réponse DNS. Elle doit aussi distinguer les outils de diagnostic qui demandent des localisateurs réels des applications auxquelles un handle convient. Interposer partout le même sens dans un champ ancien produit des mesures ambiguës.

La référence à un tiers casse silencieusement l’autorité

Dans une référence, B transmet à C l’adresse qu’il utilise pour joindre A. Si cette « adresse » est le LSI que B a reçu de sa propre pile, C ne reçoit pas l’identité de A. Il reçoit le numéro d’une case dans la table de B.

C peut échouer proprement. Il peut aussi traiter les bits comme une destination ordinaire ou posséder le même numéro pour une autre identité. Le risque le plus sérieux est ce succès apparent : une structure valide, un appel accepté, puis une destination qui n’est pas celle que B croyait déléguer.

La correction ne consiste pas à rendre tous les LSI globalement routables. Elle consiste à faire porter au protocole applicatif une référence adaptée à son destinataire : identité d’hôte, nom et méthode de résolution, ou objet signé contenant la portée. Si un handle local doit circuler pour l’observabilité, il doit être qualifié par la machine, l’espace de noms et l’époque de mapping.

Le parallèle avec la traduction d’adresses est utile. Les applications qui mettent des adresses locales dans leurs messages sont déjà fragiles face aux NAT. HIP n’invente pas cette dette ; il montre que l’ancien champ mélangeait emplacement, identité et pointeur local. La transition devient fiable lorsqu’on cesse de demander à une seule valeur de remplir ces trois rôles.

L’identité explicite est plus forte, mais pas totale

Le texte distingue connect(ip) d’une demande explicite portant un HIT. Dans le premier cas, l’intention peut n’être que de joindre le système actuellement accessible à cette adresse. Une politique locale peut tenter HIP, mais la liaison initiale entre l’adresse et l’identité reste faible et invisible pour l’application.

Le HIT nomme plus directement un hôte cryptographique. Cette sémantique renforce la demande. Elle ne rend pas inutiles la résolution des localisateurs, l’établissement d’association, l’observation des paquets protégés et le reçu applicatif. Un nom fort ne signifie pas que le service a répondu.

Cette borne évite de répéter d’autres sujets HIP. Ici, la question n’est pas de savoir si un serveur de rendez-vous a relayé un paquet, si un enregistrement DNS est frais ou si ESP dispose d’un chemin. La question est antérieure : quelle autorité le symbole remis à l’application possède-t-il, et cette autorité survit-elle à la sortie de la machine ?

Le serveur générique choisit encore une identité

Un service ancien écoute souvent sur une adresse générique. Sur un hôte muni de plusieurs Host Identities, ce bind ne prescrit pas nécessairement le HIT utilisé pour la réponse. RFC 5338 décrit le cas UDP où une réception puis un sendto() peuvent sélectionner une autre identité sortante que celle attendue par le client.

Le bind réussi prouve que le service écoute. Il ne prouve pas la continuité de l’identité entre réception et réponse. Si l’application lie explicitement un HIT, la pile peut restreindre les connexions à cette identité. Si elle ne le peut pas, la politique locale et la publication doivent éviter de promettre plusieurs identités que le chemin de réponse ne sait pas préserver.

Là encore, l’événement important se produit sous l’application. L’exploitation doit rendre le choix visible : identité locale reçue, identité sortante sélectionnée, socket, interface et politique. Sans ces éléments, une perte de réponse est diagnostiquée comme problème réseau alors qu’elle provient d’un changement d’autorité.

Sources et limite de preuve

Ces sources établissent les textes de normes, l’architecture déclarée et un bilan historique d’expérimentation. Elles ne prouvent ni déploiement actuel, ni produit affecté, ni incident, ni fréquence mesurée.