summaryrefslogtreecommitdiff
path: root/RFC_8003_Host_Identity_Protocol_HIP_Registration_Extension.txt
blob: 9a79012e07cac6f7178fe8a2b5b39c871ec84095 (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
38
39
40
41
42
43
44
45
46
47
Titre: RFC 8003: Host Identity Protocol (HIP) Registration Extension
Auteur: 
Date: Sat 26 Nov 2016 01:00:00 +0100
Lien: https://www.bortzmeyer.org/8003.html

Le protocole HIP, décrit dans le RFC 7401 est très bien adapté au cas où 
l'adresse IP (le localisateur) change après l'établissement d'une association. 
Mais cela laisse ouvert le grand problème de la connexion initiale. Comment 
trouver une machine HIP ? Par le mécanisme de rendez-vous du RFC 8004 ? C'est 
certainement une bonne solution mais, alors, comment les machines HIP 
sont-elles connues du serveur de rendez-vous ? C'est là que notre RFC rentre en
jeu pour normaliser un mécanisme d'enregistrementauprès d'un service. C'est un 
mécanisme générique, qui peut servir à d'autres choses que le rendez-vous, 
d'ailleurs. (Il était à l'origine spécifié dans le RFC 5203, que notre RFC 
remplace.)

Le mécanisme est très simple et le RFC court. On réutilise simplement les 
établissements d'associations de HIP, avec de nouveaux types de paramètres, 
notamment REG_INFO (pour l'hôte qui accepte d'être registrar, c'est-à-dire 
d'enregistrer) et REG_REQUEST (pour celui qui demande un enregistrement). Le 
mécanisme exact est détaillé dans la section 3 et les nouveaux paramètres[1] 
dans la section 4.

HIP authentifiant les deux parties bien plus solidement que IP seul, le 
registrar (terme d'ailleurs mal choisi, on risque de confondre avec les bureaux
d'enregistrement de noms de domaine) peut alors décider s'il accepte 
l'enregistrement ou pas (sections 3.3 et 6).

Le rendez-vous, normalisé dans le RFC 8004 est donc une simple application de 
notre RFC mais d'autres pourront apparaître à l'avenir (comme celle du RFC 
5770).

Quels sont les changements depuis le premier RFC, le RFC 5203 ? La principale 
est qu'HIP, qui avait le statut « Expérimental » est désormais sur le chemin 
des Normes et que les références de notre RFC ont donc changé (nouveau 
protocole HIP en RFC 7401). Mais ce nouveau RFC ajoute aussi la possibilité 
d'authentifier le registrar par certificat (RFC 8002), ainsi qu'un nouveau type
d'erreur[2], le numéro 2, « ressources insuffisantes chez le registrar ».

Question mise en œuvre, je n'ai pas vérifié mais, normalement, HIP for Linux[3]
et OpenHIP[4] devraient s'adapter aux nouveaux RFC HIP.

Liens:
[1]: http://www.iana.org/assignments/hip-parameters (lien)
[2]: http://www.iana.org/assignments/hip-parameters/hip-parameters.xml#hip-parameters-13 (lien)
[3]: http://hipl.hiit.fi/ (lien)
[4]: http://openhip.sourceforge.net/ (lien)