Initiale releaseHEADmaster

1 files changed, 47 insertions, 0 deletions

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)