Initiale releaseHEADmaster

1 files changed, 68 insertions, 0 deletions

diff --git a/RFC_8005_Host_Identity_Protocol_HIP_Domain_Name_System_DNS_Extensions.txt b/RFC_8005_Host_Identity_Protocol_HIP_Domain_Name_System_DNS_Extensions.txt
new file mode 100644
index 0000000..f0147af
--- /dev/null
+++ b/RFC_8005_Host_Identity_Protocol_HIP_Domain_Name_System_DNS_Extensions.txt
@@ -0,0 +1,68 @@
+Titre: RFC 8005: Host Identity Protocol (HIP) Domain Name System (DNS) Extensions
+Auteur: 
+Date: Sat 26 Nov 2016 01:00:00 +0100
+Lien: https://www.bortzmeyer.org/8005.html
+
+Le protocole HIP n'avait pas à l'origine de mécanisme pour trouver l'
+identificateur d'une machine distante. Cela avait été fait dans le RFC 5205, 
+qui permettait de trouver l'identificateur dans le DNS. Ce nouveau RFC remplace
+le RFC 5205.
+
+HIP fait partie de la famille des protocoles qui visent à séparer 
+l'identificateur du localisateur[1]. Les identificateurs HIP se nomment les HI 
+(Host Identifier) et, autrefois, le seul moyen de trouver l'HI d'une autre 
+machine était d'attendre qu'elle vous contacte, ou bien de le configurer 
+manuellement. Avec ce RFC, on peut trouver l'HI, comme une adresse IP, dans le 
+DNS.
+
+Notre RFC crée donc un nouveau type d'enregistrement DNS, nommé logiquement HIP
+(numéro 55[2]), qui stocke, en échange d'un nom de domaine, le HI, son 
+condensat (résumé) cryptographique - le HIT (Host Identifier Tag) - et les 
+éventuels serveurs de rendez-vous, serveurs qui, dans le protocole HIP, servent
+d'intermédiaires facultatifs lorsqu'on veut contacter une machine distante (cf.
+RFC 8004).
+
+Notre RFC permet de trouver l'identificateur à partir du nom mais pas le 
+localisateur ; les serveurs de rendez-vous sont une solution possible pour cela
+; une autre est d'utiliser les traditionnels enregistrements A et AAAA du DNS, 
+le localisateur HIP étant une adresse IP.
+
+Les localisateurs peuvent changer fréquemment alors que le DNS n'est pas 
+temps-réel et ne change pas instantanément[3]. Si un hôte HIP veut pouvoir être
+contacté malgré des changements d'adresse IP rapides, il vaut peut-être mieux 
+qu'il utilise le système de rendez-vous du RFC 8004.
+
+Curieusement (pour moi), le HIT est donc stocké dans les données DNS, alors que
+celles-ci n'offrent aucune sécurité au point que le RFC exige en section 4.1 de
+recalculer le HIT qui vient d'être obtenu dans le DNS.
+
+Le tout ressemble donc aux enregistrements IPSECKEY du RFC 4025, ce qui est 
+normal, le HI étant une clé cryptographique publique.
+
+Voici un exemple d'enregistrement HIP tel qu'il apparaitrait dans un fichier de
+zone (sections 5 et 6 de notre RFC). On y trouve l'algorithme cryptographique 
+utilisé (2 = RSA), le HIT (en hexadécimal), le HI (encodé en Base64) et les 
+éventuels serveurs de rendez-vous (ici, deux, indiqués à la fin) : 
+
+www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
+                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
+                                9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
+                                b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
+                                rvs1.example.com.
+                                rvs2.example.com. )
+Par contre, je n'ai pas réussi à trouver encore ce genre d'enregistrement dans 
+la nature.
+
+L'ensemble du RFC est assez court, ce mécanisme d'annuaire qu'est le DNS étant 
+simple et bien connu.
+
+Quels sont les changements depuis le premier RFC, le RFC 5205 ? Évidement le 
+passage sur le chemin des normes, faisant de HIP une norme complète. Mais aussi
+l'ajout de l'algorithme de cryptographie asymétrique ECDSA, et plusieurs 
+clarifications du RFC original sur le format des enregistrements DNS, aussi 
+bien leur format sur le réseau que dans le fichier de zone.
+
+Liens:
+[1]: http://www.bortzmeyer.org/separation-identificateur-localisateur.html (lien)
+[2]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xml#dns-parameters-4 (lien)
+[3]: http://www.bortzmeyer.org/dns-propagation.html (lien)