summaryrefslogtreecommitdiff
path: root/RFC_8004_Host_Identity_Protocol_HIP_Rendezvous_Extension.txt
blob: 520ba667edd51acd69f7f0f5417c5415821480a2 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Titre: RFC 8004: Host Identity Protocol (HIP) Rendezvous Extension
Auteur: 
Date: Sat 26 Nov 2016 01:00:00 +0100
Lien: https://www.bortzmeyer.org/8004.html

HIP, par défaut, nécessite que l'initiateur d'une association connaisse le 
localisateur, l'adresse IP du répondeur. Si celui-ci bouge souvent, et qu'il 
n'est donc pas pratique de mettre cette adresse dans le DNS, une solution est 
d'utiliser le mécanisme de rendez-vous, décrit par ce RFC, où l'initiateur 
contacte un serveur de rendez-vous qui relaie vers le répondeur.

Le schéma est clairement expliqué dans la section 3 du RFC. En fonctionnement 
habituel de HIP, l'initiateur trouve l'identificateur et le localisateur du 
répondeur (typiquement, dans le DNS, cf. RFC 8005), puis le contacte 
directement. Si le localisateur n'est pas connu (ce qui est fréquent si le 
répondeur est un engin mobile, changeant souvent d'adresse IP), l'initiateur 
envoie le premier paquet (I1) au serveur de rendez-vous, qui le relaie au 
répondeur. Les autres paquets (R1, I2 et R2) seront transmis directement entre 
les deux machines HIP. Le mécanisme est détaillé dans la section 3.3 (il faut 
notamment procéder avec soin à la réécriture des adresses IP, en raison entre 
autre du RFC 2827).

Et comment l'initiateur trouve-t-il le serveur de rendez-vous ? En général dans
le DNS, via les enregistrements de type HIP. Et comment le répondeur avait-il 
fait connaitre au serveur de rendez-vous son adresse IP ? Via le protocole 
d'enregistrement du RFC 8003, comme l'explique la section 4.

Comme toute indirection, le système de rendez-vous ouvre des problèmes de 
sécurité amusants. Si l'initiateur connaissait déjà l'identificateur du 
répondeur (donc sa clé publiqué), pas de problème, le passage par le serveur de
rendez-vous ne diminue pas la sécurité. Si ce n'est pas le cas, alors, il n'y a
rien à faire, l'initiateur n'a aucun moyen de vérifier l'identité du répondeur 
(section 5 du RFC).

Aucun changement depuis la première spécification, le RFC 5204, juste 
l'alignement avec la nouvelle version de HIP, celle du RFC 7401, désormais 
norme complète (et pas juste « expérimentale »).