Résumé

  • Dans l’architecture HIP de 2006, Robert Moskowitz et Pekka Nikander proposent une identité fondée sur une clé publique pour désigner l’extrémité, tandis que l’adresse IP sert à la localiser pour l’acheminement.
  • Cette séparation peut préserver une association lorsque l’adresse change et que les deux hôtes utilisent HIP. Elle ne transfère pas une inscription d’adresse et ne met pas à jour toutes les règles applicatives.

Un ordinateur quitte un réseau, en rejoint un autre et reçoit une nouvelle adresse. Le chemin des paquets a changé ; l’hôte auquel ils sont destinés, non. Pendant longtemps, les protocoles ont demandé au même nombre de décrire à la fois un lieu dans le réseau et une extrémité de communication. C’est cette confusion que Robert Moskowitz et Pekka Nikander ont mise au premier plan dans la RFC 4423.

Le Host Identity Protocol ajoute un espace d’identité distinct entre la couche Internet et la couche transport. Dans cette architecture, l’identifiant d’hôte est une clé publique ; l’identité qu’il représente est une notion abstraite. Le Host Identity Tag, ou HIT, en est une représentation condensée de 128 bits. L’adresse IP garde son rôle essentiel de localisateur : elle indique aux routeurs où envoyer les paquets. Elle n’a simplement plus à porter seule l’identité de l’extrémité à laquelle une association de transport est rattachée.

La portée de l’idée apparaît dans le changement de liaison. La RFC 4423 décrit des associations de transport attachées aux identités d’hôte. Quand un hôte change d’adresse après une mobilité, une nouvelle connexion d’accès ou un renumérotage, un pair compatible avec HIP peut mettre à jour le localisateur tout en conservant l’association fondée sur l’identité. Plusieurs interfaces peuvent aussi correspondre à un même hôte. La continuité est donc déplacée vers l’état cryptographique partagé par les extrémités qui participent au protocole.

La chronologie documentaire évite de donner à Moskowitz un rôle plus large que celui que les sources attestent. Publiée en mai 2006, la RFC 4423 est informative. Son résumé la présente comme un état de la réflexion des auteurs à l’automne 2003 et précise que l’architecture a pu évoluer ; le texte ne définit pas de norme Internet. La RFC 7401, éditée par Moskowitz avec d’autres auteurs, spécifie ensuite HIP version 2 dans la voie Standards Track. Elle décrit des hôtes consentants qui établissent un état partagé au niveau IP et un échange cryptographique en quatre paquets. En 2021, la RFC 9063, signée par Moskowitz et Miika Komu, actualise l’architecture, remplace la RFC 4423 et intègre les leçons des implémentations de la RFC 7401, notamment sur l’agilité cryptographique et la confiance à la première utilisation.

Cette succession montre qu’une proposition a été précisée ; elle ne montre pas que l’Internet a cessé de dépendre des adresses. HIP maintient l’association que les deux extrémités gèrent. Une règle de pare-feu peut encore autoriser une adresse source précise. Une entrée DNS peut continuer de renvoyer vers l’ancien localisateur. Un correspondant peut ne pas parler HIP. Une application peut conserver une adresse dans sa configuration ou s’en servir comme signal de réputation. Une association qui survit au changement ne met aucun de ces éléments à jour automatiquement.

note 68 de Heng Lu apporte un angle économique distinct : une adresse peut devenir une mémoire d’entreprise lorsque clients, partenaires et équipes de sécurité bâtissent des attentes autour d’elle. Ce n’est ni une description de HIP ni une preuve de son déploiement. Cette idée aide à distinguer deux continuités. HIP sépare l’identité utilisée dans un échange de protocole du localisateur utilisé pour le routage ; il ne réécrit pas les relations externes qui se sont accumulées autour d’une adresse.

La contribution de Moskowitz se comprend ainsi comme une frontière d’architecture. Un hôte peut déclarer : « mon chemin peut changer ; mon identité d’extrémité authentifiée relève d’un autre état ». La portée est réelle, mais circonscrite. HIP peut réduire la dépendance à une adresse fixe pour la mobilité et le multi-hébergement, sans remplacer le DNS, le routage, l’administration des ressources, les politiques applicatives ni les engagements de continuité envers les clients.

Sources