From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- ...dentity_Protocol_HIP_Registration_Extension.txt | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 RFC_8003_Host_Identity_Protocol_HIP_Registration_Extension.txt (limited to 'RFC_8003_Host_Identity_Protocol_HIP_Registration_Extension.txt') diff --git a/RFC_8003_Host_Identity_Protocol_HIP_Registration_Extension.txt b/RFC_8003_Host_Identity_Protocol_HIP_Registration_Extension.txt new file mode 100644 index 0000000..9a79012 --- /dev/null +++ b/RFC_8003_Host_Identity_Protocol_HIP_Registration_Extension.txt @@ -0,0 +1,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) -- cgit v1.2.1