La parution régulière de RFC sur
HIP (Host Identity Protocol) me donne à penser qu'un petit résumé de ce
protocole est une bonne idée (ce texte est très inspiré du chapitre 3 du ). HIP est un protocole de séparation entre
l'identificateur et le localisateur. Avant HIP, les adresses IP servaient les deux rôles à
la fois : comme localisateur, elles identifient une position de la
machine sur l'Internet (pas une localisation physique, bien
sûr), et changent donc si la machine se déplace ou si le réseau change
de FAI. Comme identificateur, elles sont
utilisées par les protocoles des couches supérieures, notamment
TCP pour identifier une connexion en cours et,
si elles changent, la connexion est cassée. Cette dualité de rôle des
adresses IP rend certains problèmes comme la
mobilité, le renumérotage (cf. ) ou le
multihoming très durs à
traiter.
HIP, normalisé dans le , résout le problème en limitant les adresses IP au rôle de
localisateur. Ainsi, un paquet HIP est un paquet IP normal et les
routeurs n'ont pas besoin d'être modifiés. HIP est entièrement mis en
œuvre dans la machine terminale. Les identificateurs sont, eux,
des clés publiques, permettant une
authentification des machines (leur nom officiel est HI, pour
Host Identifier). Comme ces clés sont souvent très
longues, et, pire, de taille variable, HIP introduit également un
condensat cryptographique des clés, le HIT
(Host Identifier Tag), qui a la taille d'une
adresse IPv6 et peut donc être présenté aux
couches supérieures comme TCP, sans trop les traumatiser. (Sur
FreeBSD, vous trouverez le HIT de votre machine
sous /etc/hip.)
Les HIT sont rangés dans un préfixe IPv6 spécial, nommé
Orchid (),
2001:20::/28, avant d'éviter toute collision avec
les adresses IPv6 « normales ».
Pour établir une connexion, HIP utilise un échange de quatre
paquets (comme SCTP, alors que TCP n'en utilise que trois). Pour
envoyer ces paquets, le pair à l'initiative de la connexion doit
connaître le localisateur (l'adresse IP) du répondeur. Il peut la
trouver dans le DNS () ou bien via un serveur de rendez-vous (). En pair-à-pair, une
DHT pourrait être un bon moyen de résoudre un
identificateur en localisateur, et le explore cette piste. (Sur FreeBSD,
on peut même mettre HIT et adresse - identificateur et localisateur -
du pair dans /etc/hosts.) HIP dispose également d'un mécanisme
pour pouvoir fonctionner à travers les NAT
(). Une fois la connexion établie, les
localisateurs peuvent changer (), la
connexion continue.
HIP dispose d'une forte sécurité : protection contre les
usurpations d'identificateur par le fait que ceux-ci sont une clé
cryptographique et que les messages sont signés, protections contre les
DoS au moment de l'établissement de la
connexion (une faiblesse traditionnelle de TCP lorsqu'il est utilisé
seul). Le « certificat » que représente cette
clé est auto-signé par défaut (et est donc accepté par TOFU Trust
On First Use comme dans SSH) mais, si on veut avoir encore plus de
sécurité, on peut tout à fait avoir un serveur central qui alloue les
identificateurs et les lie à des identificateurs des applications. HIP
n'a pas qu'un seul modèle de sécurité pour authentifier les pairs.
Qu'est-ce que HIP change pour les applications ? Une application
traditionnelle peut tout à fait utiliser HIP (cf. ) mais une API standard figure dans le pour celles qui veulent aller plus loin.
Il
existe des mises en œuvres de HIP pour FreeBSD (le développement a stoppé en 2008) et Linux mais aucun des deux ne
semble
proche d'une intégration dans le système officiel (pour FreeBSD, rien n'est prévu). Le projet OpenHIP adapte également des
logiciels comme Wireshark pour qu'ils aient un
support HIP. InfraHIP
travaille également à l'infrastructure HIP et à des implémentations. Ils ont réalisé une bonne explication de
HIP en une page qui concurrence sérieusement cet article. Un
compte-rendu des expériencs pratiques avec HIP se trouve dans le .