Équipe d'ingénierie de l'Internet (IETF)	R. Moskowitz, éd., HTT Consulting	
Request for Comments : 7401	T. Heer, Hirschmann Automation et Control	
RFC rendue obsolète : 5201	P. Jokela, Ericsson Research NomadicLab	
Catégorie : Sur la voie de la normalisation	T. Henderson, University of Washington	
ISSN : 2070-1721	avril 2015	
Traduction Claude Brière de L'Isle		

Protocole d'identité d'hôte version 2 (HIPv2)

Résumé
Le présent document spécifie les détails du protocole d'identité d'hôte (HIP). HIP permet à des hôtes consentants d'établir en toute sécurité et de maintenir un état de couche IP partagé, permettant la séparation des rôles d'identifiant et de localisateur des adresses IP, permettant par là la continuité des communications à travers des changement d'adresse IP. HIP se fonde sur un échange de clé Diffie-Hellman, en utilisant des identifiants à clé publique à partir d'un nouvel espace de noms d'hôte pour une authentification mutuelle des homologues. Le protocole est conçu pour être résistant aux attaques de déni de service (DoS) d'interposition (MitM, man-in-the-middle). Lorsque il est utilisé avec un autre protocole de sécurité convenable, comme l'encapsulation de charge utile de sécurité (ESP, Encapsulating Security Payload) il assure la protection de l'intégrité et un chiffrement facultatif pour les protocoles de couche supérieure, tels que TCP et UDP.

Le présent document rend obsolète la RFC 5201 et répond aux questions soulevées par l'IESG, en particulier celle de la "crypto agilité". Il incorpore aussi les leçons tirées des mises en œuvre de la RFC 5201.

Statut de ce mémoire
Ceci est un document de l’Internet en cours de normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc7401 

Notice de droits de reproduction
Copyright (c) 2015 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.
Table des matières
1. Introduction	2
1.1 Nouvel espace de noms et identifiants	3
1.2 Échange de base HIP (BEX)	3
1.3 Structure du mémoire	4
2. Termes et définitions	4
2.1 Terminologie des exigences	4
2.2 Notation	4
2.3 Définitions	4
3. Structure de l'identité d'hôte (HI)	5
3.1 Étiquette d'identité d'hôte (HIT)	5
3.2 Génération d'une HIT à partir d'une HI	6
4. Vue d'ensemble du protocole	6
4.1 Création d'une association HIP	6
4.2 Mise à jour d'une association HIP	13
4.3 Traitement d'erreur	13
4.4 Automate à états HIP	14
4.5 Considérations sur les données d'utilisateur	17
4.6 Distribution de certificat	18
5. Formats de paquet	18
5.1. Format de charge utile	18
5.2 Paramètres HIP	20
5.3 Paquets HIP	36
5.4 Messages ICMP 	42
6. Traitement de paquet	42
6.1 Traitement des données d'application sortantes	43
6.2 Traitement des données d'application entrantes	43
6.3 Résolution du puzzle	44
6.4 Calcul et vérification de HIP_MAC et SIGNATURE 	44
6.5 Génération de KEYMAT HIP	47
6.6 Initialisation d'un échange HIP de base	48
6.7 Traitement de paquets I1 entrants	49
6.8 Traitement de paquets R1 entrants	50
6.9 Traitement de paquets I2 entrants	51
6.10 Traitement de paquets R2 entrants	53
6.11 Envoi de paquets UPDATE	53
6.12 Réception de paquets UPDATE	54
6.13 Traitement des paquets NOTIFY	55
6.14 Traitement des paquets CLOSE	55
6.15 Traitement des paquets CLOSE_ACK	55
6.16 Traitement de la perte d'état	56
7. Politiques HIP	56
8. Considérations sur la sécurité	56
9. Considérations relatives à l'IANA	58
10. Différences avec la RFC 5201	59
11. Références	61
11.1 Références normatives	61
11.2 Références pour information	62
Appendice A. Utilisation des puzzles de répondant	64
Appendice B. Génération d'un codage de clé publique à partir d'un HI	64
Appendice C. Exemples de somme de contrôle pour paquets HIP	65
C.1 Exemple de HIP IPv6 (paquet I1)	65
C.2 Paquet HIP IPv4	65
C.3 Segment TCP	66
Appendice D. Groupes ECDH et ECDSA de 160 bits	66
Appendice E. Suites HIT et génération de HIT	66
Remerciements	66
Adresse des auteurs	67
 	1.	Introduction
Le présent document spécifie les détails du protocole d'identité d'hôte (HIP, Host Identity Protocol). Une description générale du protocole et des idées architecturales sous-jacentes est disponible dans le document séparé sur l'architecture de HIP [HIP-ARCH]. En bref, l'architecture de HIP propose une solution de remplacement à la double utilisation des adresses IP comme "localisateurs" (étiquettes d'acheminement) et "identifiants" (identifiants de point d'extrémité, ou d'hôte). Dans HIP, des clés cryptographiques publiques, d'une paire de clés publique/privée, sont utilisées comme identifiants d'hôte, auxquels les protocoles de couche supérieure sont liés, au lieu d'une adresse IP. En utilisant des clés publiques (et leurs représentations) comme identifiants d'hôte, les changements dynamiques des ensemble d'adresses IP peuvent être directement authentifiés entre les hôtes, et si désiré, une authentification forte entre les hôtes au niveau de la pile TCP/IP peut être obtenue.

Le présent mémoire spécifie le protocole HIP de base ("échange de base") utilisé entre les hôtes pour établir des contextes de communications de couche IP, appelés une association HIP, avant les communications. Il définit aussi un format de paquet et les procédures pour mettre à jour et terminer une association HIP active. Les autres éléments de l'architecture HIP sont spécifiés dans d'autres documents, tels que :

o	"Utilisation du format de transport de charge utile de sécurité par encapsulage (ESP) avec le protocole d'identité d'hôte (HIP)" [RFC7402] : comment utiliser l'encapsulation de charge utile de sécurité (ESP) pour la protection de l'intégrité et le chiffrement facultatif.

o	"Mobilité d'hôte avec le protocole d'identité d'hôte" [RFC8046] : comment prendre en charge la mobilité de l'hôte dans HIP.

o	"Extension au système des noms de domaines pour le protocole d'identité d'hôte (HIP)" [RFC8005] : comment étendre le DNS pour contenir les informations d'identité d'hôte.

o	"Extension Rendez-vous au protocole d'identité d'hôte (HIP)" [RFC8004] : utilisation d'un mécanisme de rendez-vous pour contacter des hôtes HIP mobiles.

Depuis le premier développement de l'échange de base HIP, il y a eu quelques avancées en cryptographie et dans les attaques contre les systèmes cryptographiques. Par suite, tous les protocoles cryptographiques doivent être agiles. C'est-à-dire qu'avoir la capacité de passer d'une primitive cryptographique à une autre devrait faire partie de ces protocoles. Il est important de prendre en charge un ensemble raisonnable d'algorithmes principaux pour faire face aux différents cas d’utilisation et permettre de se débarrasser des algorithmes dont on découvre ensuite qu'ils sont vulnérables. Cette mise à jour de l'échange de base inclut cette nécessaire agilité cryptographique tout en contrant les attaques en dégradation qu'introduit une telle souplesse. De plus, la prise en charge des courbes elliptiques via DSA à courbe elliptique (ECDSA) et Diffie-Hellman à courbe elliptique (ECDH) a été ajoutée.

 	1.1	Nouvel espace de noms et identifiants
Le protocole d'identité d'hôte introduit un nouvel espace de noms, l'espace de noms Identité d'hôte. Certaines ramifications de ce nouvel espace de noms sont expliquée dans le document d'architecture HIP [HIP-ARCH].

Il y a deux représentations principales de l'identité d'hôte, la pleine identité d'hôte (HI) et l'étiquette d'identité d'hôte (HIT, Host Identity Tag). La HI est une clé publique et représente directement l’identité d'un hôte. Comme il y a différents algorithmes de clé publique qui peuvent être utilisés avec différentes longueurs de clés, la HI, en tant que telle, ne convient pas comme identifiant de paquet, ou comme indice dans diverses structures de mise en œuvre en rapport avec l'état nécessaires pour prendre en charge HIP. Par conséquent, un hachage de la HI, l'étiquette d'identité d'hôte (HIT) est utilisé comme représentation opérationnelle. La HIT fait 128 bits et est utilisée dans les en-têtes HIP et pour indexer l'état correspondant dans les hôtes d'extrémité. La HIT a une importante propriété de sécurité en ce qu'elle est auto certifiante (voir la Section 3).

 	1.2	Échange de base HIP (BEX)
L'échange de base HIP est un protocole de chiffrement en deux parties utilisé pour établir un contexte de communications entre des hôtes. L'échange de base est un échange de quatre paquets conforme à SIGMA [KRA03]. La première partie est appelée l'initiateur et la seconde partie le répondant. Le protocole échange des clés Diffie-Hellman [DIF76] dans le second et le troisième paquets, et authentifie les parties dans le troisième et le quatrième paquets. Le concept en quatre paquets aide à rendre HIP résistant aux attaques de déni de service (DoS ). Il permet au répondant de rester sans état jusqu'à ce que l'adresse IP et le puzzle cryptographique soient vérifiés. Le répondant commence l'échange de puzzle dans le second paquet, l'initiateur le complétant dans le troisième paquet avant que le répondant ne mémorise aucun état provenant de l'échange.

L'échange peut utiliser le résultat Diffie-Hellman pour chiffrer l'identité d'hôte de l'initiateur dans le troisième paquet (bien que Aura, et autres [AUR05] note qu'une telle opération peut interférer avec le fonctionnement des boîtiers de médiation qui inspectent les paquets) ou bien l'identité d'hôte peut aussi être envoyée non chiffrée. L'identité d'hôte du répondant n’est pas protégée. On devrait cependant noter que les HIT de l'initiateur et du répondant sont transportées telles quelles (en clair) dans les paquets, permettant à un espion, avec une connaissance a priori des parties, de les identifier par leurs HIT. Donc, chiffrer la HI de toute partie n'assure pas la confidentialité contre un tel attaquant.

Les paquets de données commencent à s'écouler après le quatrième paquet. Les troisième et quatrième paquets HIP pourront porter une charge utile de données à l'avenir. Cependant, les détails seront définis plus tard.

Une association HIP existante peut être mise à jour en utilisant le mécanisme d'actualisation défini dans le présent document, et quand l'association n'est plus nécessaire, elle peut être close en utilisant le mécanisme de clôture défini.

Finalement, HIP est conçu comme un protocole d'authentification de bout en bout et d'établissement de clé, à utiliser avec l'encapsulation de charge utile de sécurité (ESP) [RFC7402] et d'autres protocoles de sécurité de bout en bout. Le protocole de base ne couvre pas tout le contrôle de politique fin qui se trouve dans l'échange de clés Internet (IKE) [RFC7296] qui permet à IKE de prendre en charge des politiques de passerelle complexes. Donc, HIP ne remplace pas complètement IKE.

 	1.3	Structure du mémoire
Le reste du présent mémoire est structuré comme suit : la Section 2 définit les mots clé centraux, la notation, et les termes utilisés tout au long du reste du document, la Section 3 définit la structure de l'identité d'hôte et ses diverses représentations, la Section 4 donne une vue d'ensemble du protocole d'échange de base HIP, les Sections 5 et 6 définissent les formats détaillés de paquet et les règles du traitement de paquet. Finalement, les Sections 7, 8, et 9 discutent respectivement la politique, la sécurité, et les considérations relatives à l'IANA

 	2.	Termes et définitions
 	2.1	Terminologie des exigences
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	2.2	Notation
[x] indique que x est facultatif.
{x} indique que x est chiffré.
X(y) indique que y est un paramètre de X.
<x>i indique que x existe i fois.
-->  signifie "communication de l'initiateur au répondant" (demandes).
<--  signifie "communication du répondant à l'initiateur" (réponses).
|  signifie un enchaînement des informations (par exemple, X | Y est l'enchaînement de X avec Y).
Ltrunc (H(x), #K) note les #K bits de moindre points du résultat de la fonction de hachage H sur le résultat x.

 	2.3	Définitions
échange de base HIP (BEX) :  prise de contact pour établir une nouvelle association HIP.

identité d'hôte (HI) : clé publique de l'algorithme de signature qui représente l'identité de l'hôte. Dans HIP, un hôte prouve son identité en créant une signature avec la clé privée qui appartient à sa HI (cf. Section 3).

étiquette d'identité d'hôte (HIT) : abrégé pour la HI en format IPv6. Elle est générée par hachage de la HI (paragraphe 3.1).

suite HIT : une suite HIT groupe tous les algorithmes cryptographiques qui sont requis pour générer et utiliser une HI et sa HIT. En particulier, ces algorithmes sont 1) l'algorithme de signature de clé publique, 2) la fonction de hachage, et 3) la troncature (cf. Appendice E).

association HIP : état partagé entre deux homologues après achèvement du BEX.

paquet HIP : paquet de commande portant un paquet d'en-tête HIP relatif à l'établissement, la maintenance, ou la terminaison de l'association HIP.

initiateur : hôte qui initie le BEX. Ce rôle est normalement oublié une fois le BEX achevé.

répondant : hôte qui répond à l'initiateur dans le BEX. Ce rôle est normalement oublié une fois le BEX achevé.

algorithme de hachage de HIT du répondant (RHASH) : algorithme de hachage utilisé pour divers calculs de hachage dans ce document. L'algorithme est le même que celui utilisé pour générer la HIT du répondant. Le RHASH est la fonction de hachage définie par la suite HIT de la HIT du répondant (paragraphe 5.2.10).

longueur de l'algorithme de hachage de HIT du répondant (RHASH_len) : longueur naturelle du résultat de RHASH en bits.

données signées : les données signées sont protégées par une signature numérique qui a été créée par l'envoyeur des données en utilisant la clé privée de sa HI.

KDF : fonction de déduction de clé (KDF, Key Derivation Function) utilisée pour déduire les clés symétriques de l'échange de clé Diffie-Hellman.

KEYMAT : matériel de chiffrement déduit de l'échange de clés Diffie-Hellman en utilisant la KDF. Les clés symétriques pour le chiffrement et la protection de l'intégrité des paquets HIP et des paquets de données d'utilisateur chiffrées sont tirées de ce matériel de chiffrement.

 	3.	Structure de l'identité d'hôte (HI)
Dans cette section, on expose les propriétés de l'identité d'hôte et de l'étiquette d'identité d'hôte, et on définit leur format exact. Dans HIP, la clé publique d'une paire de clés asymétriques est utilisée comme identité d'hôte (HI). De même, l'hôte lui-même est défini comme l'entité qui détient la clé privée de la paire de clés. Voir dans le document d'architecture HIP [HIP-ARCH] les détails de la différence entre une identité et l'identifiant correspondant.

Les mises en œuvre de HIP DOIVENT prendre en charge l'algorithme de clé publique de Rivest Shamir Adleman [RSA] et l'algorithme de signature numérique à courbe elliptique (ECDSA, Elliptic Curve Digital Signature Algorithm) pour générer la HI comme défini au paragraphe 5.2.9. Des algorithmes supplémentaires PEUVENT être pris en charge.

Un codage haché de la HI, l'étiquette d'identité d'hôte (HIT) est utilisé dans les protocoles pour représenter l'identité d'hôte.  La HIT fait 128 bits et a les trois propriétés clés suivantes : i) elle fait la même longueur qu'une adresse IPv6 et peut être utilisée dans les champs de taille d'adresse fixe dans les API et protocoles ; ii) elle est auto certifiante (c'est-à-dire, pour une certaine HIT, il est difficile par le calcul de trouver une clé d'identité d'hôte qui corresponde à cette HIT) ; et iii) la probabilité d'une collision de HIT entre deux hôtes est très faible ; donc, il est infaisable pour un attaquant de trouver une collision avec une HIT utilisée. Pour les détails sur les propriétés de sécurité de la HIT, voir [HIP-ARCH].

La structure de la HIT est définie dans la [RFC7343]. La HIT est un identifiant de hachage cryptographique à recouvrement d'acheminement (ORCHID, Overlay Routable Cryptographic Hash Identifier) et comporte trois parties : d'abord un préfixe alloué par l'IANA pour la distinguer des autres adresses IPv6 ; ensuite, un codage sur quatre bits des algorithmes qui ont été utilisés pour générer la HI et la représentation hachée de la HI ; enfin une représentation hachée de 96 bits de l'identité d'hôte. Le codage de l'algorithme de génération de l'ORCHID et l'algorithme exact pour générer la représentation hachée sont spécifiées à l'Appendice E et dans la [RFC7343].

Porter les HI et les HIT dans l'en-tête des paquets de données d'utilisateur augmenterait les frais généraux des paquets. Donc, on ne s'attend pas à ce qu'ils soient portés dans chaque paquet, mais d'autres méthodes sont utilisées pour transposer les paquets de données en les HI correspondantes. Dans certains cas, cela rend possible d'utiliser HIP sans aucun en-tête supplémentaire dans les paquets de données d'utilisateur. Par exemple, si ESP est utilisé pour protéger le trafic de données, L'indice de paramètre de sécurité (SPI, Security Parameter Index) porté dans l'en-tête ESP peut être utilisé pour transposer le paquet de données chiffrées en l'association HIP correcte.

 	3.1	Étiquette d'identité d'hôte (HIT)
L'étiquette d'identité d'hôte est une valeur de 128 bits -- un codage haché de l'identifiant d'hôte. Il y a deux avantages à utiliser un codage haché plutôt que la clé publique d'identité d'hôte réelle de taille variable dans les protocoles. D'abord, la longueur fixe de la HIT garde aux paquet une taille gérable et facilite le codage de protocole. Ensuite, cela présente un format cohérent pour le protocole, indépendamment de la technologie d'identité sous-jacente utilisée.

La [RFC7343] spécifie des identifiants fondés sur le hachage de 128 bits, appelés des ORCHID. Leur préfixe, alloué à partir du bloc d'adresse IPv6, est défini dans la [RFC7343]. L'étiquette d'identité d'hôte est un type d'ORCHID.

Le présent document étend la spécification expérimentale HIP d'origine [RFC5201] avec des mesures pour prendre en charge l'agilité de chiffrement. Une de ces mesures permet différentes fonctions de hachage pour créer une HIT. Les suites HIT groupent les ensembles d'algorithmes qui sont exigés pour générer et utiliser une HIT particulière. Les suites sont codées en identifiants de suite HIT. Ces identifiants de suite HIT sont transmis dans le champ Algorithme de génération de ORCHID (OGA, ORCHID Generation Algorithm) dans l'ORCHID. Avec l'identifiant de suite HIT dans le champ ID d'OGA, un hôte peut dire, à partir de la HIT d'un autre hôte, si il prend en charge les hachages et algorithmes de signature nécessaires pour établir une association HIP avec cet hôte.

 	3.2	Génération d'une HIT à partir d'une HI
La HIT DOIT être générée conformément à la méthode de génération d'ORCHID décrite dans la [RFC7343] en utilisant une valeur d'identifiant de contexte de 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (cette valeur d'étiquette a été générée au hasard par l'éditeur de la présente spécification) et une entrée qui code le champ Identité d'hôte (voir au paragraphe 5.2.9) présent dans un paquet de charge utile HIP. L'ensemble de la fonction de hachage, de l'algorithme de signature, et de l'algorithme utilisé pour générer la HIT à partir de la HI, dépend de la suite HIT (voir au paragraphe 5.2.10) et est indiqué par les quatre bits du champ Identifiant d'OGA dans l'ORCHID. Actuellement, SHA-1 tronqué, SHA-384 tronqué, et SHA-256 tronqué [FIPS.180-4.2012] sont définis comme hachages pour générer une HIT.

Pour les identités qui sont des clés publiques RSA, DSA [FIPS.186-4.2013], ou DSA à courbe elliptique (ECDSA) l'entrée d'ORCHID consiste en le codage de clé publique spécifié pour le champ Identité d'hôte du paramètre HOST_ID (voir au paragraphe 5.2.9). Le présent document définit quatre profils d'algorithme : RSA, DSA, ECDSA, et ECDSA_LOW. Le profil ECDSA_LOW est destiné aux appareils qui ont de faibles capacités de calcul. Donc, un des profils suivants s'applique :

La clé publique RSA est codée comme défini à la Section 2 de la [RFC3110], en prenant les champs Longueur d'exposant (e_len), Exposant (e), et module (n) enchaînés. La longueur (n_len) du module (n) peut être déterminée à partir de la longueur HI totale et les champs précédant HI incluant l'exposant (e). Donc, les données qui servent d'entrée pour la génération de HIT ont la même longueur que la HI. Les champs DOIVENT être codés dans l'ordre des octets du réseau, comme défini dans la [RFC3110].

La clé publique DSA est codée comme défini à la Section 2 de la [RFC2536], en prenant les champs T, Q, P, G, et Y, enchaînés en entrée. Donc, les données à hacher sont longues de 1 + 20 + 3 * 64 + 3 * 8 * T octets, où T est le paramètre de taille comme défini dans la [RFC2536]. Le paramètre taille T, qui affecte les longueurs de champs, DOIT être choisi comme la valeur minimum qui est assez longue pour accommoder P, G, et Y. Les champs DOIVENT être codés dans l'ordre des octets du réseau, comme défini dans la [RFC2536].

Les clés publiques ECDSA sont codées comme défini au paragraphe 4.2 et à la Section 6 de la [RFC6090].

Dans l'Appendice B, le processus de codage de clé publique est illustré en utilisant un pseudo-code.

 	4.	Vue d'ensemble du protocole
Cette section est une vue d'ensemble simplifiée du fonctionnement du protocole HIP, et ne contient pas tous les détails des formats de paquet ou toutes les étapes de traitement de paquet. Les Sections 5 et 6 décrivent plus en détails respectivement les formats de paquet et les étapes de traitement de paquet, et sont normatives en cas de conflit avec cette section.

Le numéro de protocole 139 a été alloué par l'IANA au protocole d'identité d'hôte.

L'en-tête Charge utile HIP (paragraphe 5.1) pourrait être porté dans chaque datagramme IP. Cependant, comme les en-têtes HIP sont relativement grands (40 octets) il est souhaitable de "compresser" l'en-tête HIP afin qu'il n'apparaisse que dans les paquets de contrôle utilisés pour établir ou changer l'état de l'association HIP. La méthode réelle pour la "compression" d'en-tête et pour confronter les paquets de données aux associations HIP existantes (s'il en est) est définie dans d'autres documents, qui décrivent les formats et méthodes de transport. Toutes les mises en œuvre de HIP DOIVENT au minimum prendre en charge le format de transport ESP pour HIP [RFC7402].

 	4.1	Création d'une association HIP
Par définition, le système qui initie un échange de base HIP est l'initiateur, et l'homologue est le répondant. Cette distinction est normalement oubliée une fois que l'échange de base est achevé, et l'une ou l'autre partie peut devenir l'initiateur dans les futures communications.

L'échange de base HIP sert à gérer l'établissement de l'état entre un initiateur et un répondant. Le premier paquet, I1, initie l'échange, et les trois derniers paquets, R1, I2, et R2, constituent un échange de clés authentifié Diffie-Hellman [DIF76] pour la génération des clés de session. Dans les deux premiers paquets, les hôtes s'accordent sur un ensemble d'identifiants et algorithmes cryptographiques qui sont alors utilisés dans et après l'échange. Durant l'échange de clés Diffie-Hellman, une partie du matériel de chiffrement est générée. Les clés de l'association HIP sont tirées de ce matériel de chiffrement en utilisant une fonction de déduction de clé (KDF, Key Derivation Function). Si d'autres clés de chiffrement sont nécessaires, par exemple, pour être utilisées avec ESP, elles sont supposées être tirées du même matériel de chiffrement en utilisant la KDF.

L'initiateur envoie d'abord un paquet déclencheur, I1, au répondant. Le paquet contient la HIT de l'initiateur et éventuellement la HIT du répondant, si elle est connue. De plus, le paquet I1 initialise la négociation du groupe Diffie-Hellman qui est utilisé pour générer le matériel de chiffrement. Donc, le paquet I1 contient une liste d'identifiants de groupes Diffie-Hellman pris en charge par l'initiateur. Noter que dans certains cas, il est possible de remplacer le paquet déclencheur par une autre forme de déclencheur, et dans ce cas, le protocole commence avec l'envoi par le répondant du paquet R1. Dans ce cas, un autre mécanisme doit être spécifié pour porter les groupes DH supportés par l'initiateur (par exemple, en utilisant un groupe par défaut).

Le second paquet, R1, commence l'échange authentifié Diffie-Hellman réel. Il contient un puzzle -- un défi cryptographique que l'initiateur doit résoudre avant de continuer l'échange. Le niveau de difficulté du puzzle peut être ajusté sur la base du niveau de confiance avec l'initiateur, la charge actuelle, ou d'autres facteurs. De plus, la R1 contient le paramètre Diffie-Hellman du répondant et fait la liste des algorithmes de chiffrement supportés par le répondant. Sur la base de ces listes, l'initiateur peut continuer, interrompre, ou recommencer l'échange de base avec une sélection différente d'algorithmes de chiffrement. Aussi, le paquet R1 contient une signature qui couvre les parties choisies du message. Certains champs restent en dehors de la signature pour prendre en charge des R1 pré-créés.

Dans le paquet I2, l'initiateur DOIT afficher la solution du puzzle reçu. Sans une solution correcte, le message I2 est éliminé. Le paquet I2 contient aussi un paramètre Diffie-Hellman qui porte les informations nécessaires pour le répondant. Le paquet I2 est signé par l'initiateur.

Le paquet R2 accuse réception du paquet I2 et achève l'échange de base. Le paquet est signé par le répondant.

L'échange de base est illustré par la Figure 1. Le terme de "clé" se réfère à la clé publique d'identité d'hôte, et "sig" représente une signature utilisant cette clé. Les paquets contiennent d'autres paramètres qui ne sont pas montrés sur la figure.

Initiateur                                  Répondant
             I1 : liste DH
          -------------------------->
                                                  choisit le R1 pré calculé
                 R1 : puzzle, DH, clé, sig
              <-------------------------
Vérifie sig                                 reste sans état
Résout le puzzle
             I2 : solution, DH, {clé}, sig
                 -------------------------->
Calcule DH                               vérifie le puzzle
                                                  vérifie sig
                           R2 : sig
                 <--------------------------
Vérifie sig                                 calcule DH

Figure 1

 	4.1.1	Mécanisme de puzzle HIP
L'objet du mécanisme de puzzle HIP est de protéger le répondant contre un certain nombre de menaces de déni de service. Il permet au répondant de retarder la création d'état jusqu'à la réception du paquet I2. De plus, le puzzle permet au répondant d'utiliser un calcul très bon marché pour vérifier que l'initiateur est "sincère" au sens où il aura brassé assez de cycles de CPU à résoudre le puzzle.

Le puzzle permet à une mise en œuvre de répondant de retracer complètement la création d'état spécifique de l'association jusqu'à ce qu'un paquet I2 valide soit reçu. Un paquet I2 sans une solution valide du puzzle peut être rejeté immédiatement une fois que le répondant a vérifié la solution. La solution peut être vérifiée en calculant seulement une fonction de hachage, et les solutions invalides peuvent être rejetées avant que l'état soit créé, et avant que soient effectuée une vérification de signature de clé publique consommatrice de CPU et une génération de clé Diffie-Hellman. En variant la difficulté du puzzle, le répondant peut déjouer des attaques de DoS ciblées sur la CPU ou la mémoire.

Le répondant peut rester sans état et éliminer la plupart des paquets I2 contrefaits parce que le calcul du puzzle se fonde sur l'étiquette d'identité d'hôte de l'initiateur. L'idée est que le répondant a un certain nombre (qui peut varier) de paquets R1 pré-calculés, et il choisit un de ceux-ci sur la base des informations portées dans le paquet I1. Quand le répondant reçoit ensuite le paquet I2, il peut vérifier que le puzzle a été résolu en utilisant la HIT de l'initiateur. Cela rend impraticable à l'attaquant d'échanger d'abord un paquet I1/R1, et ensuite générer un grand nombre de paquets I2 contrefaits qui sembleraient venir de HIT différentes. Cette méthode ne protège cependant pas le répondant d'un attaquant qui utilise des HIT fixes. Contre un tel attaquant, une approche viable peut être de créer un élément d'état local, et de se souvenir que la vérification du puzzle a d'abord échoué. Voir à l'Appendice A une mise en œuvre possible. Les mises en œuvre de répondant DEVRAIENT inclure un aléa suffisant dans les valeurs de puzzle pour que les attaques de complexité algorithmique deviennent impossibles [CRO03].

Le répondant peut régler la difficulté du puzzle pour l'initiateur, sur la base du niveau de confiance de l'initiateur. Comme le puzzle n'est pas inclus dans le calcul de la signature, le répondant peut utiliser des paquets R1 pré calculés et inclure le puzzle juste avant d'envoyer le R1 à l'initiateur. Le répondant DEVRAIT utiliser une heuristique pour déterminer quand il est soumis à une attaque de déni de service, et régler la valeur de difficulté du puzzle #K de façon appropriée, comme expliqué plus loin.

 	4.1.2	Échange de puzzle
Le répondant commence l'échange de puzzle quand il reçoit un paquet I1. Le répondant fournit un nombre aléatoire #I, et demande à l'initiateur de trouver un nombre #J. Pour choisir un #J approprié, l'initiateur doit créer l'enchaînement de #I, des HIT des parties, et de #J, et calculer un hachage sur cet enchaînement en utilisant l'algorithme RASH. Les #K bits de moindre poids du résultat DOIVENT être des zéros. La valeur #K règle la difficulté du puzzle.

Pour générer un nombre #J approprié, l'initiateur va devoir générer un certain nombre de #J jusqu'à ce qu'un d'eux produise la cible de hachage de zéros. L'initiateur DEVRAIT abandonner après avoir dépassé la durée de vie du puzzle dans le paramètre PUZZLE (comme décrit au paragraphe 5.2.4). Le répondant doit re-créer l'enchaînement de #I, des HIT, et du #J fourni, et calculer le hachage une fois pour prouver que l'initiateur a achevé la tâche qui lui a été assignée.

Pour empêcher les attaques par calcul préalable, le répondant DOIT choisir le nombre #I d'une façon telle que l'initiateur ne puisse pas le deviner. De plus, la construction DOIT permettre au répondant de vérifier que la valeur #I a bien été choisie par lui et non par l'initiateur. Voir à l'Appendice A un exemple de la façon de mettre cela en œuvre.

En utilisant le champ de données Opaque dans le PUZZLE (voir au paragraphe 5.2.4) dans un paramètre ECHO_REQUEST_SIGNED (voir au paragraphe 5.2.20) ou ECHO_REQUEST_UNSIGNED (voir au paragraphe 5.2.21) le répondant peut inclure dans le R1 des données que l'initiateur DOIT copier non modifiées dans le paquet I2 correspondant. Le répondant peut utiliser les données opaques pour transférer une partie des informations d'état local à l'initiateur et retour -- par exemple, pour reconnaître que le I2 est une réponse à un précédemment envoyé. Le répondant peut générer les données opaques de diverses façons, par exemple, en utilisant le chiffrement ou le hachage avec un secret, le #I envoyé, et éventuellement en utilisant d'autres données en rapport. Avec le même secret, le #I reçu (du paquet I2) et les autres données en rapport (si il en est) le répondant peut vérifier qu'il a lui-même envoyé le #I à l'initiateur. Le répondant DOIT périodiquement changer ce secret.

Il est RECOMMANDÉ que le répondant génère de nouveaux secrets pour le puzzle et de nouveaux R1 une fois toutes les quelques minutes. De plus, il est RECOMMANDÉ que le répondant soit capable de vérifier une solution de puzzle valide au moins Durée de vie secondes après que le puzzle secret a été déconseillé. Cette valeur de temps garantit que le puzzle est valide pendant au moins Durée de vie et au plus pendant 2 * Durée de vie secondes. Cela limite la capacité d'utilisation d'un vieux puzzle résolu pour un attaquant. De plus, cela évite des problèmes avec la validité des puzzles si la durée de vie est relativement courte comparée aux délais du réseau et au temps nécessaire à la résolution du puzzle.

La valeur de puzzle #I et la solution #J sont des entrées pour déduire le matériel de chiffrement à partir de l'échange de clés Diffie-Hellman (voir au paragraphe 6.5). Donc, pour s'assurer que le matériel de chiffrement déduit diffère, un répondant NE DEVRAIT PAS utiliser deux fois le même puzzle #I avec les mêmes clés DH pour le même initiateur. Une telle unicité peut être réalisée, par exemple, en utilisant un compteur comme entrée supplémentaire pour générer #I. Ce compteur peut être augmenté pour chaque paquet I1 traité. L'état du compteur peut être transmis dans le champ Données opaques dans le PUZZLE (voir au paragraphe 5.2.4), dans un paramètre ECHO_REQUEST_SIGNED (voir au paragraphe 5.2.20), ou dans un paramètre ECHO_REQUEST_UNSIGNED (voir au paragraphe 5.2.21) sans qu'il soit besoin d'établir son état.

Note : Les développeurs de protocole ont explicitement discuté si R1 devrait inclure un horodatage afin de protéger l'initiateur contre les attaques en répétition. La décision a été de NE PAS inclure d'horodatage, pour éviter des problèmes de synchronisation globale.

Note : Les développeurs de protocole ont explicitement discuté si une fonction liée à la mémoire devrait être utilisée pour le puzzle à la place d'une fonction liée à la CPU. La décision a été de ne pas utiliser de fonctions liées à la mémoire.

 	4.1.3	Protocole Diffie-Hellman authentifié avec négociation de groupe DH
Les paquets R1, I2, et R2 mettent en œuvre un échange standard Diffie-Hellman authentifié. Le répondant envoie une de ses clés publiques Diffie-Hellman et sa clé publique d'authentification, c'est-à-dire, son identité d'hôte, dans R1. La signature dans le paquet R1 permet à l'initiateur de vérifier que le R1 a été généré par le répondant. Cependant, comme le R1 est pré calculé et donc ne couvre pas les informations spécifiques de l'association dans le paquet I1, il ne protège pas contre les attaques en répétition.

Avant l'échange authentifié Diffie-Hellman réel, l'initiateur exprime sa préférence concernant son choix de groupes DH dans le paquet I1. La préférence est exprimée comme une liste triée d'identifiants de groupe DH. Le paquet I1 n'est pas protégé par une signature. Donc, cette liste est envoyée non authentifiée pour éviter des calculs coûteux pour traiter le paquet I1 du côté répondant. Sur la base des préférences de l'initiateur, le répondant envoie un paquet R1 contenant la valeur publique DH qui convient le mieux. Le répondant joint aussi une liste de ses propres préférences au R1 pour porter les bases du choix de groupe DH à l'initiateur. Cette liste est portée dans la partie signée du paquet R1. Si le choix de valeur de groupe DH dans le R1 ne correspond pas aux préférences de l'initiateur et du répondant, l'initiateur peut détecter que la liste des identifiants de groupe DH dans le I1 a été manipulée (voir les détails au paragraphe suivant).

Si aucun des identifiants de groupe DH dans le paquet I1 n'est pris en charge par le répondant, le répondant choisit le groupe DH qui lui convient le mieux, sans considération de la préférence de l'initiateur. Il envoie alors le R1 contenant ce groupe DH et sa liste d'identifiants de groupe DH pris en charge à l'initiateur.

Quand l'initiateur reçoit un R1, il reçoit une des valeurs publiques Diffie-Hellman du répondant et la liste des identifiants de groupe DH pris en charge par le répondant. Cette liste est couverte par la signature dans le paquet R1 pour éviter les contrefaçons. L'initiateur compare l'identifiant de groupe de la valeur publique DH dans le paquet R1 à la liste des identifiants de groupe DH pris en charge dans les paquets R1 et ses propres préférences exprimées dans la liste des identifiants de groupe DH pris en charge. L'initiateur ne continue le BEX que si l'identifiant de groupe de la valeur publique DH du répondant est le préféré des identifiants pris en charge à la fois par l'initiateur et le répondant. Autrement, la communication est soumise à une attaque en dégradation, et l'initiateur DOIT soit redémarrer l'échange de base avec un nouveau paquet I1, soit interrompre l'échange de base. Si le choix du répondant de groupe DH n'est pas supporté par l'initiateur, l'initiateur PEUT interrompre la prise de contact ou envoyer un nouveau paquet I1 avec une liste différente de groupes DH pris en charge. Cependant, l'initiateur DOIT vérifier la signature du paquet R1 avant de redémarrer ou d'interrompre la prise de contact. Il DOIT ignorer en silence le paquet R1 si la signature n'est pas valide.

Si les préférences concernant l'identifiant de groupe DH correspondent, l'initiateur calcule la clé de session Diffie-Hellman (Kij). L'initiateur crée une association HIP en utilisant le matériel de chiffrement provenant de la clé de session (voir au paragraphe 6.5) et peut utiliser l'association HIP pour chiffrer sa clé publique d'authentification, c'est-à-dire, l'identité d'hôte. Le paquet I2 résultant contient la clé Diffie-Hellman de l'initiateur et sa clé publique d'authentification (facultativement chiffrée). La signature du message I2 couvre tous les paramètres des gammes de paramètres signés (voir au paragraphe 5.2) dans le paquet sans exception, comme dans le R1.

Le répondant extrait la clé publique Diffie-Hellman de l'initiateur du paquet I2, calcule la clé de session Diffie-Hellman, crée une association HIP correspondante, et déchiffre la clé publique d'authentification de l'initiateur. Il peut alors vérifier la signature en utilisant la clé d'authentification.

Le message final, R2, complète le BEX et protège l'initiateur des attaques en répétition, parce que le répondant utilise la clé partagée de l'échange Diffie-Hellman pour créer un code d'authentification de message haché (HMAC, Hashed Message Authentication Code) et utilise aussi la clé privée de son identité d'hôte pour signer le contenu du paquet.

 	4.1.4.	Protection HIP contre la répétition
HIP inclut les mécanismes suivants pour protéger contre les répétitions malveillantes de paquets. Les répondants sont protégés contre les répétitions de paquets I1 par l'effet des réponses sans état aux paquets I1 avec des messages R1 pré signés. Les initiateurs sont protégés contre les répétitions de R1 par un "compteur de génération de R1" à accroissement monotone inclus dans le R1. Les répondants sont protégés contre les répétitions de paquets I2 falsifiés par le mécanisme de puzzle (voir au paragraphe 4.1.1) et l'utilisation facultative de données opaques. Les hôtes sont protégés contre les répétitions des paquets R2 et UPDATE par l'utilisation de la vérification moins coûteuse de HMAC qui précède la vérification de signature HIP.

Le compteur de génération de R1 est un compteur de 64 bits à accroissement monotone qui peut être initialisé à toute valeur. La portée du compteur PEUT être le système, mais il DEVRAIT y avoir un compteur séparé pour chaque identité d'hôte, si il y a plus d'une identité d'hôte locale. La valeur de ce compteur DEVRAIT être préservée lors des réamorçages du système et des invocations de l'échange de base HIP. Ce compteur indique la génération actuelle des puzzles. Les mises en œuvre DOIVENT accepter les puzzles à partir de la génération en cours et PEUVENT accepter des puzzles de générations antérieures. Le compteur local d'un système DOIT être incrémenté au moins aussi souvent que chaque fois que les vieilles R1 cessent d'être valides. Le compteur local NE DEVRAIT jamais être décrémenté ; autrement, l'hôte expose ses homologues à la répétition de R1 générés précédemment avec des numéros plus élevés.

Un hôte peut recevoir plus d'un R1, soit à cause de l'envoi de plusieurs paquets I1 (voir au paragraphe 6.6.1) soit à cause de la répétition d'un vieux R1. Quand il envoie plusieurs paquets I1 au même hôte, un initiateur DEVRAIT attendre un petit moment (un temps raisonnable peut être 2 * le RTT attendu) après la réception du premier R1 pour permettre qu'éventuellement plusieurs R1 arrivent, et il DEVRAIT répondre à un R1 parmi l'ensemble avec le plus grand compteur de génération de R1. Si un initiateur traite un R1 ou a déjà envoyé un paquet I2 (toujours en attente du paquet R2) et si il reçoit un autre R1 avec un plus grand compteur de génération de R1, il PEUT choisir de recommencer le traitement de R1 avec le R1 plus frais, comme si c'était le premier R1 à arriver.

Le compteur de génération de R1 peut revenir à zéro ou peut être réinitialisée. Il est important pour un initiateur d'être robuste face à la perte d'état sur le compteur de génération de R1 d'un homologue ou d'une réinitialisation du compteur de l'homologue. Il est recommandé que, quand il choisit entre plusieurs R1, l'initiateur préfère utiliser le R1 qui correspond au compteur de génération de R1 courant, mais que si il est incapable de faire des progrès avec ce R1, l'initiateur puisse essayer les autres R1, en commençant avec le paquet R1 qui a le plus fort numéro de compteur.

 	4.1.5	Refus d'un échange HIP de base
Un hôte à capacité HIP peut choisir de ne pas accepter un échange de base HIP. Si la politique de l'hôte est d'être seulement un initiateur et si la politique permet l'établissement d'une association HIP avec l'initiateur original, il devrait commencer son propre échange de base HIP. Un hôte PEUT choisir d'avoir une telle politique car seule la confidentialité de la HI de l'initiateur est protégée dans l'échange. On devrait noter qu'un tel comportement peut introduire le risque d'une condition de compétition si la politique de chaque hôte est d'être seulement un initiateur, ce qui va conduire à l'échec de l'échange de base HIP.

Si la politique de l'hôte ne lui permet pas d'entrer dans un échange HIP avec l'initiateur, il devrait envoyer un message ICMP "Destination injoignable, interdite administrativement". Un paquet HIP plus complexe n'est pas utilisé ici parce qu'il ouvrirait plus d'attaques potentielles de DoS qu'un simple message ICMP. Un message HIP NOTIFY n'est pas utilisé parce qu'aucune association HIP n'existe entre les deux hôtes à ce moment.

 	4.1.6	Interruption d'un échange HIP de base
Deux hôtes HIP peuvent se trouver dans des situations où ils ne peuvent pas achever un échange de base HIP à cause d'une prise en charge insuffisante des algorithmes de chiffrement, en particulier les suites HIT et les groupes DH. Après la réception du paquet R1, l'initiateur peut déterminer si le répondant prend en charge les opérations cryptographiques requises pour réussir à établir une association HIP. L'initiateur peut interrompre le BEX en silence après la réception d'un paquet R1 qui indique un ensemble d'algorithmes non pris en charge. Les conditions spécifiques sont décrites ci-après.

Le paquet R1 contient une liste signée d'identifiants de suite HIT pris en charge par le répondant. Donc, l'initiateur peut déterminer si sa HIT source est supportée par le répondant. Si l'identifiant de suite HIT de l'HIT de l'initiateur n'est pas contenu dans la liste des suites HIT dans le R1, l'initiateur PEUT interrompre la prise de contact en silence, ou PEUT recommencer la prise de contact avec un nouveau paquet I1 qui contient une HIT de source supportée par le répondant.

Durant la prise de contact, l'initiateur et le répondant s'accordent sur un seul groupe DH. Le répondant choisit le groupe DH et sa valeur publique DH dans le R1 sur la base de la liste des identifiants de groupe DH dans le paquet I1. Si le répondant ne prend en charge aucun des groupes DH demandés par l'initiateur, le répondant choisit un DH arbitraire et répond avec un R1 contenant sa liste des identifiants de groupe DH pris en charge. Dans ce cas, l'initiateur reçoit un paquet R1 contenant la valeur publique DH pour un groupe DH non demandé et aussi la liste de groupes DH du répondant dans la partie signée du paquet R1. À ce point, l'initiateur PEUT interrompre la prise de contact ou PEUT recommencer la prise de contact en envoyant un nouveau paquet I1 contenant une sélection d'identifiants de groupes DH qui sont pris en charge par le répondant.

 	4.1.7	Protection contre la dégradation de HIP
Dans une attaque en dégradation, un attaquant tente de manipuler sans se faire remarquer les paquets d'un initiateur et/ou d'un répondant pour influencer en sa faveur le résultat de la négociation cryptographique dans le BEX. Il en résulte que les victimes choisissent des algorithmes de chiffrement plus faibles que ce qu'ils auraient choisi sans l'interférence de l'attaquant. Les attaques en dégradation ne peuvent réussir que si elles ne sont pas détectées par les victimes et si celles-ci supposent faussement que le canal de communication est sûr.

Dans HIP, presque tous les paramètres de paquet relatifs aux négociations cryptographiques sont couverts par les signatures. Ces paramètres ne peuvent pas être directement manipulés dans une attaque en dégradation sans invalider la signature. Cependant, des paquets signés peuvent être soumis à des attaques de répétition.

Dans une telle attaque de répétition, l'attaquant pourrait utiliser un vieux paquet de BEX avec une sélection d'algorithmes de chiffrement faibles et dépassés et le répéter à la place d'un paquet plus récent avec une collection d'algorithmes de chiffrement plus forts. Les paquets signés qui pourraient être l'objet de cette attaque en répétition sont les paquets R1 et I2. Cependant, les paquets R1 et I2 répétés ne peuvent pas être utilisés pour réussir pleinement à établir une BEX HIP parce que ces paquets contiennent aussi les valeurs publiques DH de l'initiateur et du répondant. Les vieilles valeurs DH provenant de paquets répétés conduisent à du matériel de chiffrement invalide et des secrets partagés discordants parce que l'attaquant est incapable de déduire du matériel de chiffrement valide des clés publiques DH dans le R1 et ne peut pas générer un HMAC et une signature valides pour un I2 répété.

À la différence de la première version de HIP [RFC5201], la version 2 de HIP définie dans le présent document commence la négociation des groupes DH dans le premier paquet de BEX, le I1. Le paquet I1 est, délibérément, non protégé par une signature, pour éviter des opérations cryptographiques grosses consommatrices de CPU de flots de paquets I1 ciblés sur le répondant. Donc, la liste des identifiants de groupe DH dans le paquet I1 est vulnérable à la contrefaçon et la manipulation.  Pour déjouer une manipulation non détectée du paquet I1, le répondant choisit le groupe DH de façon déterministe et inclut sa propre liste d'identifiants de groupe DH dans la partie signée du paquet R1. L'initiateur peut détecter une tentative d'attaque en dégradation en comparant la liste des identifiants de groupe DH dans le paquet R1 à ses propres préférences dans le paquet I1. Si le choix du groupe DH dans le paquet R1 n'est pas égal à la meilleure correspondance des deux listes (l'identifiant DH de plus haute priorité du répondant qui est présent dans la liste DH de l'initiateur) l'initiateur peut conclure que sa liste dans le paquet I1 a été altérée par un attaquant. Dans ce cas, l'initiateur peut redémarrer ou interrompre le BEX.  Comme on l'a mentionné précédemment, la détection de l'attaque en dégradation est suffisante pour l'empêcher.

 	4.1.8	Mode HIP opportuniste
Il est possible d'initier un BEX HIP même si la HI (et HIT) du répondant n'est pas connue. Dans ce cas, le paquet I1 initial contient des zéros comme HIT de destination. Cette sorte d'établissement de connexion est appelé le mode opportuniste.

Le répondant peut avoir plusieurs HIT à cause de plusieurs suites HIT prises en charge. Comme la suite HIT du répondant en mode opportuniste n'est pas déterminée par la HIT de destination du paquet I1, le répondant peut librement choisir une HIT de toute suite HIT. L'ensemble complet de suites HIT prises en charge par l'initiateur n'est pas connu du répondant. Donc, le répondant DEVRAIT choisir sa HIT dans la même suite HIT que la HIT de l'initiateur (indiquée par les informations de suite HIT dans le champ Identifiant d'OGA de la HIT de l'initiateur) parce que cette suite HIT est évidemment prise en charge par l'initiateur. Si le répondant choisit une HIT différente qui n'est pas supportée par l'initiateur, l'initiateur PEUT recommencer le BEX avec un paquet I1 d'une HIT source qui est contenue dans la liste des suites HIT du répondant dans le paquet R1.

Noter que l'initiateur ne peut pas vérifier la signature du paquet R1 si la suite HIT du répondant n'est pas prise en charge. Donc, l'initiateur DOIT traiter les paquets R1 avec des HIT de répondant non prises en charge comme potentiellement contrefaites et NE DOIT PAS utiliser de paramètres provenant du R1 non vérifié en dehors de HIT_SUITE_LIST. De plus, un initiateur qui utilise une HIT_SUITE_LIST non vérifiée provenant du paquet R1 pour déterminer une possible HIT de source DOIT vérifier que la HIT_SUITE_LIST dans le premier paquet R1 non vérifié correspond à la HIT_SUITE_LIST dans le second paquet R1 pour lequel l'initiateur prend en charge l'algorithme de signature. L'initiateur DOIT recommencer le BEX avec un nouveau paquet I1 pour lequel l'algorithme était mentionné dans le R1 vérifiable si les deux listes ne correspondent pas. Cette procédure est nécessaire pour atténuer les attaques en dégradation.

Le mode opportuniste implique des problèmes de sécurité et d'API. Ces problèmes sont décrits dans la suite de cette section.

Étant donné que la HI du répondant n'est pas connue de l'initiateur, il doit y avoir des invocations d'API convenables pour permettre à l'initiateur de demander, directement ou indirectement, que le système sous-jacent initie l'échange de base HIP sur la seule base de localisateurs. La HI du répondant va pouvoir être disponible dans le paquet R1, et sous une forme authentifiée une fois que le paquet R2 aura été reçu et vérifié. Donc, la HIT du répondant pourrait être communiquée à l'application via de nouveaux mécanismes d'API. Cependant, avec une API rétro compatible, l'application voit seulement les localisateurs utilisés pour le contact initial. Selon la sémantique désirée de l'API, cela peut soulever les problèmes suivants :

o	Les localisateurs actuels peuvent changer ultérieurement si un message UPDATE est utilisé, même si du point de vue de l'API, l'association paraît toujours être entre deux localisateurs spécifiques. Cependant, la mise à jour de localisateur est toujours sûre, et l'association est toujours entre les mêmes nœuds.

o	Des associations différentes entre les deux mêmes localisateurs peuvent résulter en des connexions à des nœuds différents, si la mise en œuvre ne se souvient plus de l'identifiant que l'homologue avait dans une association antérieure. Cela est possible quand le localisateur de l'homologue a changé pour des raisons légitimes ou quand un attaquant prétend être un nœud qui a le localisateur de l'homologue. Donc, en mode opportuniste, les mises en œuvre de HIP NE DOIVENT PAS s'attendre à ce que la HI de l'homologue retournée dans le message R1 corresponde à une HI vue précédemment pour cette adresse.

Si la mise en œuvre HIP et l'application n'ont pas la même compréhension de ce que constitue une association, cela peut même arriver au sein de la même association. Par exemple, une mise en œuvre peut ne pas savoir quand l'état HIP peut être purgé pour des applications fondées sur UDP.

De plus, les considérations de sécurité suivantes s'appliquent. Le mécanisme de compteur de génération va être moins efficace dans la protection contre les répétitions du paquet R1, étant donné que le répondant peut choisir une répétition qui utilise une HI arbitraire, pas seulement celle donnée dans le paquet I1.

Plus important, l'échange opportuniste est vulnérable aux attaques par interposition, parce que l'initiateur n'a aucune information de clé publique sur l'homologue. Pour établir les impacts de cette vulnérabilité, on la compare aux vulnérabilités dans les communications courantes, sans capacité HIP.

Un attaquant sur le chemin entre des deux homologues peut s'insérer pour s'interposer en fournissant son propre identifiant à l'initiateur et ensuite en initiant une autre association HIP avec le répondant. Pour que cela soit possible, l'initiateur doit employer le mode opportuniste, et le répondant doit être configuré à accepter une connexion à partir de tout nœud à capacité HIP.

Un attaquant qui n'est pas sur le chemin ne sera pas capable de faire cela, car il ne peut pas répondre aux messages dans l'échange de base.

Ces propriétés de sécurité sont caractéristiques aussi des communications dans l'Internet courant. Un client qui contacte un serveur sans employer la sécurité de bout en bout peut se trouver parler au serveur via un attaquant interposé, en supposant là encore que le serveur veuille parler à quiconque.

Si la sécurité de bout en bout est en place, alors le pire qui puisse arriver dans les deux modes HIP opportuniste et non HIP (IP normal) est le déni de service ; une entité sur le chemin peut perturber les communications, mais va être incapable de réussir à s'insérer comme interposée.

Cependant, une fois l'échange opportuniste mené à bonne fin, HIP assure la protection de la confidentialité et de l'intégrité pour les communications, et peut en toute sécurité changer les localisateurs des points d'extrémité.

Par suite, le mode opportuniste dans HIP offre un modèle de sécurité "mieux que rien". Initialement, un échange de base authentifié dans le mode opportuniste implique une "fuite de confiance" du fait de possibles attaques par interposition, mais les datagrammes suivants relatifs à la même association HIP ne peuvent pas être compromis par une nouvelle attaque par interposition. De plus, si l'interposé s'en va du chemin de l'association active, l'attaque peut être exposée après coup à la vue des parties. Donc, on peut déclarer que le mode opportuniste dans HIP est au moins aussi sûr que les communications non protégées fondées sur IP.

 	4.2	Mise à jour d'une association HIP
Une association HIP entre deux hôtes peut devoir être mise à jour de temps en temps. Des exemples incluent le besoin de changer les clés arrivées à expiration dans les associations de sécurité, d'ajouter de nouvelles associations de sécurité, ou de changer les adresses IP associées aux hôtes. Le paquet UPDATE est utilisé pour cela et autres besoins similaires. Le présent document spécifie seulement le format du paquet UPDATE et les règles de traitement de base, avec les paramètres obligatoires. L'utilisation réelle est définie dans d'autres spécifications.

HIP fournit un paquet UPDATE d'utilisation générale, qui peut porter plusieurs paramètres HIP, pour mettre à jour l'état HIP entre deux homologues. Le mécanisme UPDATE a les propriétés suivantes :

-	Les messages UPDATE portent un numéro de séquence à accroissement monotone et sont explicitement acquittés par l'homologue. Les UPDATE ou accusés de réception perdus peuvent être récupérés via retransmission. Plusieurs messages UPDATE peuvent être en cours dans certaines circonstances.

-	UPDATE est protégé par les deux paramètres HIP_MAC et HIP_SIGNATURE, car le traitement des signatures UPDATE seules est une potentielle attaque de DoS contre les systèmes intermédiaires.

-	Les paquets UPDATE sont explicitement acquittés par l'utilisation d'un paramètre d'accusé de réception qui fait écho au numéro de séquence individuel reçu de l'homologue. Un seul paquet UPDATE peut contenir à la fois un numéro de séquence et un ou plusieurs numéros d'accusé de réception (c'est-à-dire, porter des accusés de réception pour le UPDATE de l'homologue). Le paquet UPDATE est défini au paragraphe 5.3.5.

 	4.3	Traitement d'erreur
Le comportement de traitement d'erreur HIP dépend de si il existe ou non une association HIP active. En général, si une association HIP existe entre l'envoyeur et le receveur d'un paquet causant une condition d'erreur, le receveur DEVRAIT répondre avec un paquet NOTIFY. Par ailleurs, si il n'y a pas d'association HIP existante entre l'envoyeur et le receveur, ou si le receveur ne peut pas raisonnablement déterminer l'identité de l'envoyeur, le receveur PEUT répondre avec un message ICMP convenable ; voir plus de détails au paragraphe 5.4.

Le protocole HIP et l'automate à états sont conçus pour récupérer de la défaillance des parties et de la perte de l'état. Les scénarios suivants décrivent les principaux cas d'utilisation couverts par cette conception.

Pas d'état préalable entre les deux systèmes.
Le système avec des données à envoyer est l'initiateur. Le processus suit l'échange de base standard à quatre paquets, pour établir l'association HIP.

Le système avec des données à envoyer n'a pas d'état avec le receveur, mais le receveur a une association HIP résiduelle.
Le système avec des données à envoyer est l'initiateur. L'initiateur agit comme en l'absence d'état antérieur, envoyant un paquet I1 et recevant un paquet R1. Quand le répondant reçoit un paquet I2 valide, la vieille association est "découverte" et supprimée, et la nouvelle association est établie.

Le système avec des données à envoyer a une association HIP, mais pas le receveur.
Le système envoie les données sur l'association de sécurité sortante de données d'utilisateur. Le receveur "détecte" la situation quand il reçoit un paquet de données d'utilisateur qu'il ne peut faire correspondre à aucune association HIP. L'hôte receveur DOIT éliminer ce paquet. L'hôte receveur DEVRAIT envoyer un paquet ICMP, avec le type "Problème de paramètre", pour informer l'envoyeur que l'association HIP n'existe pas (voir au paragraphe 5.4) et il PEUT initier un nouveau BEX HIP. Cependant, répondre avec ces mécanismes facultatifs dépend de la mise en œuvre ou de la politique. Si l'application envoyeuse n'attend pas de réponse, le système pourrait éventuellement envoyer un grand nombre de paquets dans cet état, donc pour cette raison, l'envoi d'un ou plusieurs paquets ICMP est RECOMMANDÉ. Cependant, toutes ces réponses DOIVENT être limitées en débit pour empêcher les abus (voir au paragraphe 5.4).

 	4.4	Automate à états HIP
HIP a peu d'état par lui-même. Dans l'échange de base HIP, il y a un initiateur et un répondant. Une fois les associations de sécurité (SA) établies, cette distinction est perdue. Si l'état HIP doit être rétabli, les paramètres de contrôle sont quel homologue a encore l'état et qui a un datagramme à envoyer à son homologue. L'automate à états suivant tente de capturer ces processus.

L'automate à états est symétrique et est présenté dans une seule vue du système, représentant soit un initiateur, soit un répondant. L'automate à états n'est pas une pleine représentation de la logique de traitement. Des règles de traitement supplémentaires sont présentées dans les définitions de paquets. Donc, toutes deux sont nécessaires pour mettre complètement en œuvre HIP.

Le présent document étend l'automate à états défini dans la [RFC5201] et introduit une option de redémarrage pour permettre la négociation des algorithmes de chiffrement. L'extension de l'automate à états de la [RFC5201] est une transition de l'état I1-SENT avec retour à I1-SENT ; à savoir, l'option de redémarrage. Un initiateur est obligé de redémarrer l'échange de base HIP si le répondant ne prend pas en charge la suite HIT de l'initiateur. Dans ce cas, l'initiateur redémarre l'échange de base HIP en envoyant un nouveau paquet I1 avec une HIT de source HIT supportée par le répondant. Une mise en œuvre doit comprendre que l'automate à états, tel que décrit ici, est pour information. Les mises en œuvre spécifiques sont libres d'effectuer le traitement réel suivant une logique différente. La Section 6 décrit les règles de traitement de paquet plus en détail. Cet automate à états se concentre sur les seuls paquets HIP I1, R1, I2, et R2. De nouveaux états et transitions d'état peuvent être introduits par des mécanismes d'autres spécifications (comme la mobilité et le multi rattachements).

 	4.4.1	Terminologie de l'automate à états
Durée de vie d'association non utilisée (UAL, Unused Association Lifetime) : durée spécifique de la mise en œuvre pour laquelle, si aucun paquet n'est envoyé ou reçu pendant cet intervalle de temps, un hôte PEUT commencer à supprimer une association HIP active.

Durée de vie maximum de segment (MSL, Maximum Segment Lifetime) : durée maximum pendant laquelle un paquet HIP est supposé rester dans le réseau. Une valeur par défaut de 2 minutes a été empruntée à la [RFC0793] parce que c'est l'hypothèse prévalente des durées de vie de paquets.

Échange complet (EC) : temps que l'hôte passe dans l'état R2-SENT avant de passer à l'état ESTABLISHED. Ce temps est n * I2 temporisation de retransmission, où n est environ I2_RETRIES_MAX.

Tout autre reçu : tout paquet reçu pour lequel aucune transition d'état ou règle de traitement n'est définie pour un certain état.

 	4.4.2	États HIP
État	Explication
UNASSOCIATED	Début de l'automate à états
I1-SENT	Initialisation de l'échange de base
I2-SENT	Attente de l'achèvement de l'échange de base
R2-SENT	Attente de l'achèvement de l'échange de base
ESTABLISHED	Association HIP établie
CLOSING	Fermeture de l'association HIP, aucune donnée ne peut être envoyée
CLOSED	Association HIP fermée, aucune donnée ne peut être envoyée
E-FAILED	Échec de l'échange de base HIP

Tableau 1 : états HIP

 	4.4.3	Traitement des états HIP
Comportement du système dans l'état UNASSOCIATED, Tableau 2.
Déclencheur	Action	
Données d'utilisateur à envoyer, exige une nouvelle association HIP	envoie I1 et passe à I1-SENT	
Reçoit I1	envoie R1 et reste à UNASSOCIATED	
Reçoit I2, traitement	Si réussi, envoie R2 et passe à R2-SENT	
	Si échec, reste à UNASSOCIATED	
Reçoit des données d'utilisateur 
pour une association HIP inconnue	Envoie facultativement un message ICMP comme défini au paragraphe 5.4 et reste à UNASSOCIATED	
Reçoit CLOSE	Envoie facultativement un message ICMP Problème de paramètre et reste à UNASSOCIATED	
Reçoit ANYOTHER	Élimine et reste à UNASSOCIATED	

Tableau 2 : UNASSOCIATED - État de départ

Comportement du système dans l'état I1-SENT, Tableau 3.
Déclencheur 	Action	
Reçoit I1 du répondant	Si la HIT locale est inférieure à celle de l'homologue, élimine I1 et reste à I1-SENT (voir au paragraphe 6.5 la comparaison de HIT).	
	Si la HIT locale est supérieure à celle de l'homologue, envoie R1 et reste à I1-SENT.	
Reçoit I2, traitement	Si réussite, envoie R2 et passe à R2-SENT. Si échec, reste à I1-SENT.	
Reçoit R1, traitement	Si la suite HIT de la HIT locale n'est pas supportée par l'homologue, choisit la HIT locale acceptée, envoie I1, et reste à I1-SENT.	
	Si réussite, envoie I2 et passe à I2-SENT. Si échec, reste à I1-SENT.	
Reçoit ANYOTHER	Élimine et reste à I1-SENT.	
Fin de temporisation 	Incrémente le compteur d'essais. Si le compteur est à moins que I1_RETRIES_MAX, envoie I1 et reste à I1-SENT. Si le compteur est à plus de I1_RETRIES_MAX, passe à E-FAILED.	

Tableau 3 : I1-SENT - Initialisation de l'échange de base HIP

Comportement du système dans l'état  I2-SENT, Tableau 4.
Déclencheur	Action	
Reçoit I1	Envoie R1 et reste à I2-SENT.	
Reçoit R1, traitement	Si réussite, envoie I2 et reste à I2-SENT.	
	Si échec, reste à I2-SENT.	
Reçoit I2, traitement	Si réussite et si HIT locale inférieure à HIT d'homologue, élimine I2 et reste à I2-SENT.	
	Si réussite et si HIT locale supérieure à HIT d'homologue, envoie R2 et passe à R2-SENT.	
	Si échec, reste à I2-SENT.	
Reçoit R2, traitement	Si réussite, passe à ESTABLISHED.	
	Si échec, reste à I2-SENT.	
Reçoit CLOSE, traitement	Si réussite, envoie CLOSE_ACK et passe à CLOSED.	
	Si échec, reste à I2-SENT.	
Reçoit ANYOTHER	Élimine et reste à I2-SENT.	
Fin de temporisation	Incrémente le compteur d'essais. Si le compteur est à moins que I2_RETRIES_MAX, envoie I2 et reste à I2-SENT. Si le compteur est à plus de I2_RETRIES_MAX, passe à E-FAILED.	

Tableau 4 : I2-SENT - Attente de l'achèvement de l'échange HIP de base

Comportement du système dans l'état  R2-SENT, Tableau 5.
Déclencheur	Action	
Reçoit I1	Envoie R1 et reste à R2-SENT.	
Reçoit I2, traitement	Si réussite, envoie R2 et reste à R2-SENT. Si échec, reste à R2-SENT.	
Reçoit R1	Élimine et reste à R2-SENT.	
Reçoit R2	Élimine et reste à R2-SENT.	
Reçoit données ou UPDATE	Passe à ESTABLISHED.	
Fin de temporisation d'échange	Passe à ESTABLISHED.	
Reçoit CLOSE, traitement	Si réussite, envoie CLOSE_ACK et passe à CLOSED. Si échec, reste à ESTABLISHED.	
Reçoit CLOSE_ACK	Élimine et reste à R2-SENT.	
Reçoit NOTIFY	Traite et reste à R2-SENT.	

Tableau 5 : R2-SENT - attente pour finir HIP

Comportement du système dans l'état ESTABLISHED, Tableau 6.
Déclencheur 	Action	
Reçoit I1	Envoie R1 et reste à ESTABLISHED.	
Reçoit I2	Traite avec puzzle et possible vérification données opaques.	
	Si réussite, envoie R2, élimine la vieille association HIP, établit une nouvelle association HIP, et passe à R2-SENT. Si échec, reste à ESTABLISHED.	
Reçoit R1	Élimine et reste à ESTABLISHED.	
Reçoit R2	Élimine et reste à ESTABLISHED.	
Reçoit données d'utilisateur pour association HIP	Traite et reste à ESTABLISHED.	
Pas de paquet envoyé/reçu durant UAL minutes	Envoie CLOSE et passe à CLOSING.	
Reçoit UPDATE	Traite et reste à ESTABLISHED.	
Reçoit CLOSE, traitement	Si réussite, envoie CLOSE_ACK et passe à CLOSED. Si échec, reste à ESTABLISHED.	
Reçoit CLOSE_ACK	Élimine et reste à ESTABLISHED.	
Reçoit NOTIFY	Traite et reste à ESTABLISHED.	

Tableau 6 : ESTABLISHED - Association HIP établie

Comportement du système dans l'état CLOSING, Tableau 7.
Déclencheur 	Action	
Données d'utilisateur à envoyer, exige la création d'une autre incarnation de l'association HIP	Envoie I1 et passe à I1-SENT.	
Reçoit I1	Envoie R1 et reste à CLOSING.	
Reçoit I2, traitement	Si réussite, envoie R2 et passe à R2-SENT. Si échec, reste à CLOSING.	
Reçoit R1, traitement	Si réussite, envoie I2 et passe à I2-SENT. Si échec, reste à CLOSING.	
Reçoit CLOSE, traitement	Si réussite, envoie CLOSE_ACK, élimine l'état, et passe à CLOSED. Si échec, reste à CLOSING.	
Reçoit CLOSE_ACK, traitement	Si réussite, élimine l'état et passe à UNASSOCIATED. Si échec, reste à CLOSING.	
Reçoit ANYOTHER	Élimine et reste à CLOSING.	
Fin de temporisation	Incrémente la somme de temporisation et réinitialise le temporisateur. Si somme de temporisation est moins que UAL+MSL minutes, retransmet CLOSE et reste à CLOSING. Si somme de temporisation est supérieur à UAL+MSL minutes, passe à UNASSOCIATED.	

Tableau 7 : CLOSING - L'association HIP n'a pas été utilisée depuis UAL minutes

Comportement du système dans l'état CLOSED, Tableau 8.
Déclencheur 	Action	
Datagramme à envoyer, exige la création d'une autre incarnation de l'association HIP.	Envoie I1 et reste à CLOSED.	
Reçoit I1	Envoie R1 et reste à CLOSED.	
Reçoit I2, traitement	Si réussite, envoie R2 et passe à R2-SENT. Si échec, reste à CLOSED.	
Reçoit R1, traitement	Si réussite, envoie I2 et passe à I2-SENT. Si échec, reste à CLOSED.	
Reçoit CLOSE, traitement	Si réussite, envoie CLOSE_ACK et reste à CLOSED. Si échec, reste à CLOSED.	
Reçoit CLOSE_ACK, traitement	Si réussite, élimine l'état et passe à UNASSOCIATED. Si échec, reste à CLOSED.	
Reçoit ANYOTHER	Élimine et reste à CLOSED.	
Fin de temporisation (UAL+2MSL)	Élimine l'état et passe à UNASSOCIATED.	

Tableau 8 : CLOSED - CLOSE_ACK envoyé, renvoie CLOSE_ACK si nécessaire

Comportement du système dans l'état E-FAILED, Tableau 9.
Déclencheur	Action	
Attente d'une durée spécifique de la mise en œuvre	Passe à UNASSOCIATED. La renégociation est possible après être passé à l'état UNASSOCIATED.	

Tableau 9 : E-FAILED - HIP échoue à établir l'association avec l'homologue

 	4.4.4	Diagramme simplifié d'état HIP
Le diagramme suivant (Figure 2) montre les transitions d'état majeures. Les transitions sur la base des paquets reçus supposent implicitement que les paquets sont bien authentifiés ou traités.

                               +--+       +----------------------------+
          reçoit I1, envoie R1 |  |       |                            |
                               |  v       v                            |
                             +--------------+  reçoit I2, envoie R2    |
            +----------------| UNASSOCIATED |----------------+         |
 datagramme |  +--+          +--------------+                |         |
 à envoyer, |  |  | Alg. non accepté,                        |         |
  envoie I1 |  |  | envoie I1                                |         |
     .      v  |  v                                          |         |
     .   +---------+  reçoit I2, envoie R2                   |         |
   +---->| I1-SENT |--------------------------------------+  |         |
   |     +---------+            +----------------------+  |  |         |
   |          | reçoit R1,      | reçoit I2, envoie R2 |  |  |         |
   |          v envoie I2       |                      v  v  v         |
   |       +---------+          |                    +---------+       |
   |  +--->| I2-SENT |----------+     +--------------| R2-SENT |<---+  |
   |  |    +---------+                |              +---------+    |  |
   |  |          |  | reçoit R2       |     Fin tempo.|             |  |
   |  |reçoit R1,|  |                 |  données ou EC|             |  |
   |  | envoie I2+--|-----------------+               |  reçoit I2, |  |
   |  |          |  |       +-------------+           |    envoie R2|  |
   |  |          |  +------>| ESTABLISHED |<----------+             |  |
   |  |          |          +-------------+                         |  |
   |  |          |            |  |  |      reçoit I2, envoie R2     |  |
   |  |          +------------+  |  +-------------------------------+  |
   |  |          |               +-----------+                      |  |
   |  |          | pas de paquet env/reçu    |    +---+             |  |
   |  |          | depuis UAL min, env. CLOSE|    |   |fin tempo.   |  |
   |  |          |                           v    v   |(UAL+MSL)    |  |
   |  |          |                        +---------+ |retransmet   |  |
   +--|----------|------------------------| CLOSING |-+CLOSE        |  |
      |          |                        +---------+               |  |
      |          |                         | |   | |                |  |
      +----------|-------------------------+ |   | +----------------+  |
      |          |               +-----------+   +------------------|--+
      |          |               | reçoit CLOSE,   reçoit CLOSE_ACK |  |
      |          +-------------+ |envoie CLOSE_ACK   ou fin tempo.  |  |
      |   reçoit CLOSE,        | |                 (UAL+MSL)        |  |
      |   envoie CLOSE_ACK     v v                                  |  |
      |                     +--------+  reçoit I2, envoie R2        |  |
      +---------------------| CLOSED |------------------------------+  |
                            +--------+                                 |
                              ^ |  |                                   |
reçoit CLOSE, envoie CLOSE_ACK| |  |   Fin de temporisation (UAL+2MSL) |
                              +-+  +-----------------------------------+

Figure 2

 	4.5	Considérations sur les données d'utilisateur
 	4.5.1	Calcul du pseudo en-tête TCP et UDP pour les données d'utilisateur
Quand on calcule les sommes de contrôle TCP et UDP sur les paquets de données d'utilisateur qui s'écoulent à travers les prises liées aux HIT, le format de pseudo en-tête IPv6 [RFC2460] DOIT être utilisé, même si les adresses réelles dans l'en-tête du paquet sont des adresses IPv4. De plus, les HIT DOIVENT être utilisées à la place des adresses IPv6 dans le pseudo en-tête IPv6. Noter que le pseudo en-tête pour les charges utiles HIP réelles est calculé différemment ; voir au paragraphe  5.1.1.

 	4.5.2	Envoi de données sur les paquets HIP
D'autres documents pourront définir comment inclure les données d'utilisateur dans divers paquets HIP. Cependant, actuellement l'en-tête HIP est un en-tête terminal, et n'est suivi par aucun autre en-tête.

 	4.5.3	Formats de transport
Le format réel de transmission des données, utilisé pour les données d'utilisateur après l'échange de base HIP, n'est pas défini dans le présent document. De tels formats et méthodes de transport sont décrits dans des spécifications distinctes. Toutes les mises en œuvre de HIP DOIVENT appliquer, au minimum, le format de transport ESP pour HIP [RFC7402]. Le format de transport à choisir est négocié dans l'échange de base. Le répondant exprime sa préférence de format de transport dans le TRANSPORT_FORMAT_LIST dans le paquet R1, et l'initiateur choisit un format de transport et ajoute le paramètre HIP approprié au paquet I2.

 	4.5.4	Réamorçage, fin de temporisation, rédémarrage de HIP
La simulation d'une perte d'état est une potentielle attaque de déni de service. Le processus suivant a été imaginé pour gérer la récupération d'état sans offrir d'opportunité de DoS.

Si un hôte réamorce ou si l'association HIP arrive en fin de temporisation, il a perdu son état HIP. Si l'hôte qui a perdu son état a un datagramme à envoyer à l'homologue, il redémarre simplement l'échange de base HIP. Après l'achèvement de l'échange de base, l'initiateur peut créer une nouvelle association de charge utile et commencer à envoyer des données. L'homologue ne réinitialise pas son état tant qu'il n'a pas reçu un paquet I2 valide.

Si un système reçoit un paquet de données d'utilisateur qui ne peut pas être mis en correspondance avec une association HIP existante, il est possible qu'il ait perdu l'état et que son homologue l'ait conservé. Il PEUT envoyer un paquet ICMP avec le type "Problème de paramètre", et avec le pointeur sur les informations d'association qui se réfèrent à HIP. La réaction à ce trafic dépend de la mise en œuvre et de l'environnement où la mise en œuvre est utilisée.

Si l'hôte qui a apparemment perdu son état décide de redémarrer l'échange de base HIP, il envoie un paquet I1 à l'homologue. Après l'achèvement réussi de l'échange de base, l'initiateur peut créer une nouvelle association HIP, et l'homologue abandonne ses vieilles associations de charge utile et en crée une nouvelle.

 	4.6	Distribution de certificat
Le présent document ne définit pas comment utiliser les certificats ou comment les transférer entre les hôtes. Ces fonctions sont supposées être définies dans une future spécification, comme il a été fait pour HIP version 1 (voir la [RFC6253]). Une valeur de type de paramètre, destinée à être utilisée pour porter les certificats, est réservée, mais : CERT, Type 768 ; voir au paragraphe 5.2.

 	5.	Formats de paquet
 	5.1.	Format de charge utile
Tous les paquets HIP commencent par un en-tête fixe.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Proch. en-tête | Longueur en-t.|0| Type paquet |Version| Rés.|1|
+---------------+---------------+-+-------------+-------------+-+
|      Somme de contrôle        |           Contrôles           |
+---------------+---------------+---------------+---------------+
|               Étiquette d'identité d'hôte envoyeur (HIT)      |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|               Étiquette d'identité d'hôte receveur (HIT)      |
|                                                               |
|                                                               |
|                                                               |
+---------------+---------------+---------------+---------------+
|                                                               |
/                        Paramètres HIP                         /
/                                                               /
|                                                               |
+---------------+---------------+---------------+---------------+

L'en-tête HIP est logiquement un en-tête d'extension IPv6. Cependant, le présent document ne décrit pas le traitement des valeurs de "Prochain en-tête" autres que le décimal 59, IPPROTO_NONE, la valeur de "'pas de prochain en-tête" IPv6. De futurs documents POURRONT définir le comportement pour d'autres valeurs. Cependant, les mises en œuvre courantes DOIVENT ignorer les données à la suite si une valeur "Prochain en-tête" non mise en œuvre est reçue.

Le champ Longueur d'en-tête contient la longueur combinée de l'en-tête HIP et des paramètres HIP en unités de 8 octets, excluant les huit premiers octets. Comme tous les en-têtes HIP DOIVENT contenir les champs HIT de l'envoyeur et du receveur, la valeur minimum de ce champ est 4, et à l'inverse, la longueur maximum du champ Paramètres HIP est (255 * 8) - 32 = 2008 octets (voir au paragraphe 5.1.3 concernant la fragmentation HIP). Noter que cela fixe une limite supplémentaire à la taille des paramètres inclus dans le champ Paramètres, indépendamment des longueurs maximales des paramètres individuels.

Le type de paquet indique le type de paquet HIP. Les types de paquet individuels sont définis dans les paragraphes qui s'y rapportent. Si un hôte HIP reçoit un paquet HIP qui contient un type de paquet non reconnu, il DOIT éliminer le paquet.

Le champ Version HIP fait quatre bits. La version définie dans le présent document est 2. Le numéro de version est supposé n'être incrémenté que si il y a des changements incompatibles au protocole. La plupart des extensions peuvent être traitées en définissant de nouveaux types de paquet, de nouveaux types de paramètres, ou de nouveaux contrôles (voir au paragraphe 5.1.2).

Les trois bits suivants sont réservés pour une utilisation future. Ils DOIVENT être à zéro à l'émission, et ils DOIVENT être ignorés lors du traitement d'un paquet reçu.

Les deux bits fixes de l'en-tête sont réservés pour la compatibilité avec SHIM6 [RFC5533], paragraphe 5.3. Pour les mises en œuvre qui adhèrent (seulement) à la présente spécification, ils DOIVENT être réglés comme indiqué à l'envoi et DOIVENT être ignorés en réception. Ceci est pour assurer une compatibilité future optimale. Noter que pour les mises en œuvre qui appliquent d'autres spécifications compatibles en plus de la présente spécification, les règles correspondantes peuvent bien être différentes. Par exemple, une mise en œuvre qui applique à la fois la présente spécification et le protocole SHIM6 peut avoir besoin de vérifier ces bits afin de déterminer comment traiter le paquet.

Le champ HIT fait toujours 128 bits (16 octets).

 	5.1.1	Somme de contrôle
Comme la somme de contrôle couvre les adresses de source et de destination dans l'en-tête IP, elle DOIT être recalculée sur les appareils de NAT à capacité HIP.

Si IPv6 est utilisé pour porter le paquet HIP, le pseudo en-tête [RFC2460] contient les adresses IPv6 de source et de destination, la longueur de paquet HIP dans le champ Longueur du pseudo en-tête, un champ de zéros, et le numéro de protocole HIP (voir au paragraphe 5.1) dans le champ "Prochain en-tête". Le champ Longueur est en octets et peut être calculé à partir du champ Longueur d'en-tête HIP :

(Longueur d'en-tête HIP + 1) * 8.

En cas d'utilisation de IPv4, le format de pseudo en-tête UDP IPv4 [RFC0768] est utilisé. Dans le pseudo en-tête, les adresses de source et de destination sont celles utilisées dans l'en-tête IP, le champ de zéros est évidemment zéro, le protocole est le numéro de protocole HIP (voir la Section 4), et la longueur est calculé comme dans le  cas de IPv6.

 	5.1.2	Contrôles HIP
Le champ Contrôles HIP porte les informations sur la structure du paquet et les capacités de l'hôte.

La champ suivant a été défini :

+---------------+-------------+-+
|               |             |A|
+---------------+-------------+-+

A - Anonyme : si il est établi, la HI de l'envoyeur dans ce paquet est anonyme, c'est-à-dire, ne figure pas dans un répertoire.  Les HI anonymes NE DEVRAIENT PAS être mémorisées. Ce contrôle est établi dans les paquets qui utilisent des HI d'envoyeur anonymes. L'homologue qui reçoit une HI anonyme dans un R1 ou I2 peut choisir de le refuser.

Le reste des champs est réservé pour une utilisation future, et DOIT être réglé à zéro à l'émission et ignoré à réception.

 	5.1.3	Prise en charge de la fragmentation HIP
Une mise en œuvre HIP DOIT prendre en charge la fragmentation/réassemblage IP. Le réassemblage de fragment DOIT être mis en œuvre dans IPv4 et IPv6, mais la génération de fragments est EXIGÉE dans IPv4 (les piles et réseaux IPv4 vont généralement faire cela par défaut) et RECOMMANDÉ dans IPv6. Dans les réseaux IPv6, la MTU minimum est plus grande, 1280 octets, que dans les réseaux IPv4. La plus grande taille de MTU est généralement suffisante pour la plupart des paquets HIP, et donc la génération de fragments peut n'être pas nécessaire. Si il est prévu qu'un hôte envoie des paquets HIP supérieurs à la MTU IPv6, la mise en œuvre DOIT appliquer la génération de fragment même pour IPv6.

Dans les réseaux IPv4, les paquets HIP peuvent rencontrer des MTU faibles le long de leur chemin. Comme le HIP de base, défini dans le présent document, ne fournit pas de mécanisme pour utiliser plusieurs datagrammes IP pour un seul paquet HIP, la prise en charge de la découverte de la MTU de chemin n'apporte aucune valeur à HIP dans les réseaux IPv4. Les appareils de NAT à capacité HIP DEVRAIENT effectuer le réassemblage/fragmentation IPv4 pour les paquets HIP.

Toutes les mises en œuvre HIP devront être prudentes dans l'emploi d'un algorithme de réassemblage pour qu'il soit suffisamment résistant aux attaques de DoS.

Les chaînes de certificats peuvent causer la fragmentation du paquet, et la fragmentation peut ouvrir les mises en œuvre à des attaques de déni de service [KAU03]. Les schémas de "hachage et URL" comme défini dans la [RFC6253] pour HIP version 1 peuvent être utilisés pour éviter la fragmentation et atténuer les attaques de DoS résultantes.

 	5.2	Paramètres HIP
Les paramètres HIP portent les informations qui sont nécessaires pour établir et maintenir une association HIP. Par exemple, les clés publiques de l'homologue aussi bien que la signalisation pour négocier le traitement des chiffrements et des charges utiles sont encapsulées dans les paramètres HIP. Des informations supplémentaires, significatives pour les hôtes d'extrémité ou les boîtiers de médiation, peuvent aussi être incluses dans les paramètres HIP. La spécification des paramètres HIP et leur transposition en paquets HIP et types de paquet est assez souple pour permettre que des extensions à HIP définissent de nouveaux paramètres et comportements de protocole.

Dans les paquets HIP, les paramètres HIP sont ordonnés selon leur numéro de type et codés en format de TLV.

Les types de paramètre suivants sont actuellement définis.

TLV	Type	Longueur	Données	
R1_COUNTER	129	12	Compteur de génération de puzzle	
PUZZLE	257	12	#K et #I aléatoire	
SOLUTION	321	20	#K, #I aléatoire et solution de puzzle #J	
SEQ	385	4	Numéro d'identifiant de paquet UPDATE.	
ACK	449	variable	Numéro d'identifiant de paquet UPDATE.	
DH_GROUP_LIST	511	variable	Liste ordonnée d'identifiants de groupe DH supportés par un hôte.	
DIFFIE_HELLMAN	513	variable	Clé publique.	
HIP_CIPHER	579	variable	Liste des algorithmes de chiffrement HIP.	
ENCRYPTED	641	variable	Partie chiffrée d'un paquet HIP.	
HOST_ID	705	variable	Identité d'hôte avec nom de domaine pleinement qualifié (FQDN) ou Identifiant d'accès réseau (NAI).	
HIT_SUITE_LIST	715	variable	Liste ordonnée des suites HIT supportées par le répondant.	
CERT	768	variable	Certificat HI ; utilisé pour transférer les certificats. Spécifié dans un document distinct.	
NOTIFICATION	832	variable	Données d'information.	
ECHO_REQUEST_SIGNED	897	variable	Données opaques à faire écho ; signées.	
ECHO_RESPONSE_SIGNED	961	variable	Données opaques à faire écho par demande ; signées.	
TRANSPORT_FORMAT_LIST	2049	ordonnée	Liste variable des numéros de type de transport HIP préférés.	
HIP_MAC	61505	variable	Code d'authentification de message fondé sur HMAC, avec matériel de chiffrement tiré de KEYMAT.	
HIP_MAC_2	61569	variable	Code d'authentification de message fondé sur HMAC, avec matériel de chiffrement tiré de KEYMAT. À la différence de HIP_MAC, le paramètre HOST_ID est inclus dans le calcul de HIP_MAC_2.	
HIP_SIGNATURE_2	61633	variable	Signature utilisée dans le paquet R1.	
HIP_SIGNATURE	61697	variable	Signature du paquet.	
ECHO_REQUEST_UNSIGNED	63661	variable	Données opaques à faire écho ; après signature.	
ECHO_RESPONSE_UNSIGNED	63425	variable	Données opaques à faire écho par demande ; après signature.	

Comme l'ordre (du plus bas au plus haut) des paramètres HIP est strictement appliqué (voir au paragraphe 5.2.1) les valeurs de type de paramètre pour les paramètres existants ont été espacées pour permettre de futures extensions du protocole.

Les gammes de numéro de type de paramètre suivantes sont définies.

Gamme de type	Objet
        0  -  1023	Prise de contact
  1024  -  2047	Réservé
  2048  -  4095	Paramètres relatifs aux formats de transport HIP.
  4096  -  8191	Paramètres signés alloués par des documents de spécification.
  8192 - 32767	Réservé
32768 - 49151	Réservé pour utilisation privée. Paramètres signés.
49152 - 61439	Réservé
61440 - 62463	Signatures et MAC signés
62464 - 63487	Paramètres qui ne sont ni signés ni l'objet d'un MAC.
63488 - 64511	Rendez-vous et relais.
64512 - 65023	Paramètres qui ne sont ni signés ni l'objet d'un MAC.
65024 - 65535	Réservé

Le processus pour définir de nouveaux paramètres est décrit au paragraphe 5.2.2 de ce document.

La gamme entre 32768 (2^15) et 49151 (2^15 + 2^14) est réservée pour utilisation privée. Les types de cette gamme DEVRAIENT être choisis de façon aléatoire pour réduire la probabilité de collisions.

 	5.2.1	Format de TLV
Les paramètres codés en TLV sont décrits dans les paragraphes qui suivent. La valeur du champ Type décrit aussi l'ordre de ces champs dans le paquet. Les paramètres DOIVENT être inclus dans le paquet de telle sorte que leur type forme un ordre croissant. Si plusieurs paramètres avec le même numéro de type sont dans un paquet, les paramètres de même type DOIVENT être consécutifs dans le paquet. Si l'ordre ne suit pas cette règle, le paquet est considéré comme mal formé et DOIT être éliminé.

Les paramètres qui utilisent des valeurs de type de 2048 à 4095 sont relatifs aux formats de transport. Actuellement, un seul format de transport est défini : le format de transport ESP [RFC7402].

Tous les paramètres codés en TLV sont d'une longueur (incluant les champs Type et Longueur) qui est un multiple de 8  octets. Quand nécessaire, un bourrage DOIT être ajouté à la fin du paramètre pour que la longueur totale soit un multiple de 8 octets. Cette règle assure un bon alignement des données. Tous les octets de bourrage ajoutés DOIVENT être mis à zéro par l'envoyeur, et leur valeur NE DEVRAIT PAS être vérifiée par le receveur.

Le champ Longueur indique la longueur du champ Contenu (en octets). Par conséquent, la longueur totale du paramètre TLV (incluant Type, Longueur, Contenu, et Bourrage) est relative au champ Longueur selon la formule suivante :

Longueur totale = 11 + Longueur - (Longueur + 3) % 8 ;

où % est l'opérateur modulo.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type            |C|             Longueur          |
+---------------+-------------+-+---------------+---------------+
|                                                               |
/                          Contenu                              /
/                                               +-+-+-+-+-+-+-+-+
|                                               |   Bourrage    |
+---------------+---------------+---------------+---------------+

Type : code de type pour le paramètre. Long de 16 bits, le bit C fait partie du code de type.
C : Critique. À 1 si ce paramètre est critique et DOIT être reconnu par le receveur, zéro autrement. Le bit C est considéré comme faisant partie du champ Type. Par conséquent, les paramètres critiques sont toujours impairs, et les non critiques ont une valeur paire.
Longueur : longueur du contenu, en octets, excluant Type, Longueur, et Bourrage.
Contenu : spécifique du paramètre, défini par le Type.
Bourrage : de 0 à 7 octets, ajouté si nécessaire.

Les paramètres critiques (indiqués par une valeur de numéro de type impaire) DOIVENT être reconnus par le receveur. Si un receveur rencontre un paramètre critique qu'il ne reconnaît pas, il NE DOIT PAS poursuivre le traitement du paquet. Il PEUT envoyer un message ICMP ou NOTIFY, comme défini au paragraphe 4.3.

Les paramètres non critiques PEUVENT être ignorés en toute sécurité. Si un receveur rencontre un paramètre non critique qu'il ne reconnaît pas, il DEVRAIT poursuivre comme si le paramètre était absent du paquet reçu.

 	5.2.2	Définition de nouveaux paramètres
De futures spécifications pourront définir de nouveaux paramètres comme nécessaire. Quand on définit de nouveaux paramètres, il faut s'assurer que les valeurs de type de paramètre sont appropriées et laissent un espace convenable pour les autres extensions futures. On doit se rappeler que les paramètres DOIVENT toujours être rangés en ordre numérique croissant de code de type, limitant par là l'ordre des paramètres (voir au paragraphe 5.2.1).

Les règles suivantes DOIVENT être appliquées lors de la définition de nouveaux paramètres.

1. 	Le bit C de moindre poids du code de type est utilisé pour distinguer entre paramètres critiques et non critiques. Donc, les numéros de type de paramètre pairs indiquent des paramètres non critiques tandis que les numéros de type de paramètre impairs indiquent des paramètres critiques.

2.	Un nouveau paramètre ne PEUT être critique que si une ancienne mise en œuvre qui l'ignore causerait des problèmes de sécurité. En général, les nouveaux paramètres DEVRAIENT être définis comme non critiques, et attendre une réponse du receveur.

3.	Si un système met en œuvre un nouveau paramètre critique, il DOIT fournir la capacité de désactiver la caractéristique associée, de telle sorte que le paramètre critique ne soit pas envoyé du tout. L'option de configuration DOIT être bien documentée. Les mises en œuvre qui opèrent dans un mode qui adhère à la présente spécification DOIVENT désactiver par défaut l'envoi de nouveaux paramètres critiques. En d'autre termes, l'interface de gestion DOIT permettre un mode ordinaire comme réglage de configuration par défaut, et PEUT permettre que de nouvelles charges utiles critiques soient configurées (et désactivées).

4.	Voir à la Section 9 les règles d'allocation concernant les codes de type.

 	5.2.3	R1_COUNTER
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Longueur          |
+---------------+---------------+---------------+---------------+
|                       Réservé, 4 octets                       |
+---------------+---------------+---------------+---------------+
|          Compteur de génération de R1, 8 octets               |
|                                                               |
+---------------+---------------+---------------+---------------+

Type : 129
Longueur : 12
Compteur de génération de R1 : la génération actuelle de puzzles valides.

Le paramètre R1_COUNTER contient un entier non signé de 64 bits dans l'ordre des octets du réseau, indiquant la génération actuelle de puzzles valides. L'envoyeur DEVRAIT incrémenter ce compteur périodiquement. Il est RECOMMANDÉ que la valeur du compteur soit incrémentée au moins aussi souvent que les vieilles valeurs de PUZZLE sont déconseillées afin que les solutions pour elles ne soient plus acceptées.

La prise en charge du paramètre R1_COUNTER est obligatoire, bien que son inclusion dans le paquet R1 soit facultative. Il DEVRAIT être inclus dans le R1 (et dans ce cas il est couvert par la signature) et si présent dans le R1, il DOIT y être fait écho (incluant le champ Réservé tel quel) par l'initiateur dans le paquet I2.

 	5.2.4	PUZZLE
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|  #K, 1 octet  | Durée de vie  |        Opaque, 2 octets       |
+---------------+---------------+---------------+---------------+
|                      #I aléatoire, RHASH_len / 8 octets       |
/                                                               /
+---------------+---------------+---------------+---------------+

Type : 257
Longueur : 4 + RHASH_len / 8
#K : #K est le nombre de bits vérifiés
Durée de vie : durée de vie du puzzle 2^(valeur - 32) secondes
Opaque : données établies par le répondant, indexant le puzzle
#I aléatoire : nombre aléatoire de taille RHASH_len bits

#I aléatoire est représenté comme un entier de n bits (où n est RHASH_len) et #K et Durée de vie sont des entiers de 8 bits, tous dans l'ordre des octets du réseau.

Le paramètre PUZZLE contient la difficulté #K du puzzle et un entier aléatoire de n bits #I. La durée de vie du puzzle indique le temps durant lequel la solution du puzzle est valide, et établit une limite de temps qui ne devrait pas être excédée par l'initiateur quand il tente de résoudre le puzzle. La durée de vie est indiquée comme puissance de 2 en utilisant la formule 2^(Durée de vie - 32) secondes. Un puzzle PEUT être augmenté avec un paramètre ECHO_REQUEST_SIGNED ou ECHO_REQUEST_UNSIGNED inclus dans le R1 ; le contenu de la demande d'écho est alors renvoyé en écho dans le paramètre ECHO_RESPONSE_SIGNED ou ECHO_RESPONSE_UNSIGNED, ce qui permet au répondant d'utiliser les informations incluses au titre du traitement de son puzzle.

Les champs Opaque et #I aléatoire ne sont pas couverts par le paramètre HIP_SIGNATURE_2.

 	5.2.5	SOLUTION
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|  #K, 1 octet  |   Réservé     |        Opaque, 2 octets       |
+---------------+---------------+---------------+---------------+
|                      #I aléatoire, n octets                   |
/                                                               /
+---------------+---------------+---------------+---------------+
|           Solution du puzzle #J, RHASH_len / 8 octets         |
/                                                               /
+---------------+---------------+---------------+---------------+

Type : 321
Longueur : 4 + RHASH_len / 4
#K : #K est le nombre de bits vérifiés
Réservé : zéro en envoi, ignoré à réception
Opaque : copié sans modification du paramètre PUZZLE reçu
#I aléatoire : nombre aléatoire de taille RHASH_len bits
Solution du puzzle #J : nombre aléatoire de taille RHASH_len bits

#I aléatoire et #J aléatoire sont représentés par des entiers non signés de n bits (où n est RHASH_len) et #K par un entier non signé de 8 bits, tous dans l'ordre des octets du réseau.

Le paramètre SOLUTION contient une solution d'un puzzle. Il fait aussi écho à la difficulté aléatoire #K, au champ Opaque, et à l'entier de puzzle #I.

 	5.2.6	DH_GROUP_LIST
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|ID GROUPE DH #1|ID GROUPE DH #2|ID GROUPE DH #3|ID GROUPE DH #4|
+---------------+---------------+---------------+---------------+
|ID GROUPE DH #n|               Bourrage                        |
+---------------+---------------+---------------+---------------+

Type : 511
Longueur : nombre d'identifiants de groupe DH
ID GROUPE DH : identifie un groupe DH accepté par l'hôte. La liste des identifiants est ordonnée par préférence de l'hôte.  Les identifiants de groupe DH possibles sont définis dans le paramètre DIFFIE_HELLMAN. Chaque identifiant de groupe DH est long d'un octet.

Le paramètre DH_GROUP_LIST contient la liste de identifiants de groupe DH acceptés par un hôte. L'initiateur envoie le DH_GROUP_LIST dans le paquet I1, et le répondant envoie sa propre liste dans la partie signée du paquet R1. Les identifiants de groupe DH dans le paramètre DH_GROUP_LIST sont mentionnés dans l'ordre de leur préférence pour l'hôte qui envoie la liste. Les identifiants de groupe DH qui sont en premier sur la liste sont préférés à ceux qui sont après. Les informations dans le DH_GROUP_LIST permettent au répondant de choisir le groupe DH préféré par lui-même et accepté par l'initiateur. Sur la base du DH_GROUP_LIST dans le paquet R1, l'initiateur peut déterminer si le répondant a choisi le meilleur choix possible sur la base des préférences de l'initiateur et du répondant. Si le choix du répondant diffère du meilleur choix, l'initiateur peut conclure qu'il y a une tentative d'attaque en dégradation (voir au paragraphe 4.1.7).

Quand il choisit le groupe DH pour le paramètre DIFFIE_HELLMAN dans le paquet R1, le répondant DOIT choisir le premier identifiant de groupe DH dans sa DH_GROUP_LIST qui dans le paquet R1 est compatible avec un des identifiants de la suite dans la DH_GROUP_LIST de l'initiateur dans le paquet I1. Le répondant NE DOIT PAS choisir d'autre identifiant de groupe DH que contenu dans les deux listes, parce qu'alors une attaque en dégradation ne peut pas être détectée.

En général, les hôtes DEVRAIENT préférer les groupes plus forts aux plus faibles si les frais généraux de calcul ne sont pas prohibitifs pour l'application.

 	5.2.7	DIFFIE_HELLMAN
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
| ID de groupe  |  Longueur de valeur publique  |Valeur publique/
+---------------+---------------+---------------+---------------+
/                                                               /
+---------------+---------------+---------------+---------------+
/                               |            Bourrage           |
+---------------+---------------+---------------+---------------+

Type : 513
Longueur : longueur en octets, excluant Type, Longueur, et Bourrage.
ID de groupe : identifie les valeurs pour p et g ainsi que la KDF.
Longueur de valeur publique : longueur de la valeur publique suivante en octets.
Valeur publique : clé publique Diffie-Hellman de l'envoyeur.

Un seul paramètre DIFFIE_HELLMAN peut être inclus dans les paquets HIP choisis sur la base de l'identifiant de groupe DH choisi (paragraphe 5.2.6). Les identifiants de groupe suivants ont été définis (valeurs allouées par ce document) :

Valeur	Groupe	KDF
0	Réservé
1	Déconseillé
2	Déconseillé
3	Groupe MODP à 1536 bits [RFC3526]	HKDF [RFC5869]
4	Groupe MODP à 3072 bits [RFC3526]	HKDF [RFC5869]
5	Déconseillé
6	Déconseillé
7	NIST P-256 [RFC5903]	HKDF [RFC5869]
8	NIST P-384 [RFC5903]	HKDF [RFC5869]
9	NIST P-521 [RFC5903]	HKDF [RFC5869]
10	SECP160R1 [SECG]	HKDF [RFC5869]
11	Groupe MODP à 2048 bits [RFC3526]	HKDF [RFC5869]

Les groupes Diffie-Hellman MODP sont définis dans la [RFC3526]. Les groupes ECDH 7 à 9 sont définis dans les [RFC5903] et [RFC6090]. Le groupe ECDH 10 est couvert dans l'Appendice D. Tout ECDH utilisé avec HIP DOIT avoir un co-facteur de 1.

L'identifiant de groupe définit aussi la fonction de déduction de clé à utiliser pour déduire les clés symétriques pour le HMAC et le chiffrement symétrique à partir du matériel de chiffrement provenant de l'échange de clés Diffie-Hellman (voir au paragraphe 6.5).

Une mise en œuvre HIP DOIT utiliser l'identifiant de groupe 3. Le groupe SECP160R1 à 160 bits peut être utilisé quand une sécurité inférieure est suffisante (par exemple, pour naviguer sur la Toile) et quand l'équipement n'est pas assez puissant (par exemple, certaines tablettes). Les mises en œuvre DEVRAIENT utiliser les identifiants de groupe 4 et 8.

Pour éviter des défaillances inutiles durant l'échange de base, le reste des groupes DEVRAIT être mis en œuvre dans des hôtes où les ressources sont adéquates.

 	5.2.8	HIP_CIPHER
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|Identifiant de chiffrement n° 1|Identifiant de chiffrement n° 2|
+---------------+---------------+---------------+---------------+
|Identifiant de chiffrement n° n|            Bourrage           |
+---------------+---------------+---------------+---------------+

Type : 579
Longueur : longueur en octets, excluant Type, Longueur, et Bourrage.
Identifiant de chiffrement : identifie l'algorithme de chiffrement à utiliser pour chiffrer le contenu du paramètre ENCRYPTED.

Les identifiants de chiffrement suivants sont définis :

Valeur	Identifiant de suite
0	Réservé
1	NULL-ENCRYPT ([RFC2410])
2	AES-128-CBC  ([RFC3602])
3	Réservé (valeur non utilisée)
4	AES-256-CBC ([RFC3602])

L'envoyeur d'un paramètre HIP-CIPHER DOIT s'assurer qu'il n'y a pas plus de six (6) identifiants de chiffrement dans un paramètre HIP-CIPHER.

À l'inverse, un receveur DOIT être prêt à traiter les paramètres de transport reçus qui contiennent plus de six identifiants de chiffrement en acceptant les six premiers et en éliminant le reste. Le nombre limité d'identifiants de chiffrement fixe la taille maximum du paramètre HIP-CIPHER. Comme configuration par défaut, le paramètre HIP-CIPHER DOIT contenir au moins un des identifiants de chiffrement obligatoires. Il PEUT y avoir une option de configuration qui permet à l'administrateur d'outrepasser cette configuration par défaut.

Le répondant fait la liste des identifiants de chiffrement pris en charge et désirés dans leur ordre de préférence dans le R1, jusqu'au maximum de six identifiants de chiffrement. L'initiateur DOIT choisir seulement un des identifiants de chiffrement correspondants. Cet identifiant de chiffrement sera utilisé pour générer le paramètre ENCRYPTED.

AES-128-CBC est de mise en œuvre obligatoire. 

Les mises en œuvre DEVRAIENT prendre en charge le chiffrement nul pour les seuls besoins d'essai/débogage mais NE DOIVENT PAS offrir ou accepter cette valeur sauf si elle est explicitement configurée pour l'essai/débogage de HIP.

 	5.2.9	HOST_ID
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|         Longueur de HI        |Type DI|     Longueur de DI    |
+---------------+---------------+-------+-------+---------------+
|          Algorithme           |         Identité d'hôte       /
+---------------+---------------+---------------+---------------+
/                               |       Identifiant de domaine  /
+---------------+---------------+---------------+---------------+
/                                               |   Bourrage    |
+---------------+---------------+---------------+---------------+

Type : 705
Longueur : longueur en octets, excluant Type, Longueur, et Bourrage.
Longueur de HI : longueur de l'identité d'hôte en octets.
Type de DI : type du champ Identifiant de domaine suivant.
Longueur de DI : longueur du champ Identifiant de domaine en octets.
Algorithme : indice de l'algorithme employé.
Identité d'hôte : identité d'hôte réelle.
Identifiant de domaine : identifiant de l'envoyeur.

Les types d'identifiant de domaine suivants ont été définis :

Valeur	Type
0 	aucun inclus
1	FQDN (nom de domaine pleinement qualifié, en format binaire)
2	NAI (identifiant d'accès réseau)

Le format de FQDN est défini dans la [RFC1035], paragraphe 3.1. Le format de NAI est défini dans la [RFC4282].

Un hôte PEUT facultativement associer l'identité d'hôte avec un seul identifiant de domaine dans le paramètre HOST_ID. Si il n'y a pas d'identifiant de domaine, c'est-à-dire, si le champ Type de DI est zéro, le champ Longueur de DI est réglé aussi à zéro.

Les algorithmes d'identité d'hôte suivants ont été définis :

Valeur	Profil d'algorithme
0	Réservé
3	DSA [FIPS.186-4.2013] (RECOMMANDÉ)
5	RSA [RFC3447] (EXIGÉ)
7	ECDSA [RFC4754] (EXIGÉ)
9	ECDSA_LOW [SECG] (RECOMMANDÉ)

Pour les types de clé DSA, RSA, et ECDSA, les profils qui contiennent au moins 112 bits de force de sécurité (comme défini par [NIST.800-131A]) devraient être utilisés. Pour le bourrage de signature RSA, la méthode de bourrage du schéma de signature probabiliste (PSS, Probabilistic Signature Scheme) [RFC3447] DOIT être utilisée.

L'identité d'hôte est dérivée du format DNSKEY pour RSA et DSA. Il utilise le champ Clé publique de la partie RDATA de la [RFC4034]. Pour le chiffrement à courbe elliptique (ECC) on distingue deux profils différents : ECDSA et ECDSA_LOW. ECC contient les courbes approuvées par le NIST et définies dans la [RFC4754]. ECDSA_LOW est défini pour les appareils avec de faibles capacités de calcul et utilise des courbes plus courtes des normes pour le groupe de chiffrement efficace (SECG, Standards for Efficient Cryptography Group) [SECG]. Tout ECDSA utilisé avec HIP DOIT avoir un co facteur de 1.

Pour ECDSA et ECDSA_LOW, les identités d'hôte sont représentées par les champs suivants :

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Courbe ECC            |                               /
+---------------+---------------+---------------+---------------+
/                        Clé publique                           |
+---------------+---------------+---------------+---------------+

Courbe ECC : étiquette de la courbe.
Clé publique : représentée en format de chaîne d'octets [RFC6090].

Pour les hôtes qui mettent en œuvre l'algorithme ECDSA, les courbes ECC suivantes sont exigées :

Valeur	Algorithme	Courbe
0	ECDSA	Réservé
1	ECDSA	NIST P-256 [RFC4754]
2	ECDSA	NIST P-384 [RFC4754]

Pour les hôtes qui mettent en œuvre le profil d'algorithme ECDSA_LOW, la courbe suivante est exigée :

Valeur	Algorithme	Courbe
0	ECDSA_LOW	Réservé
1	ECDSA_LOW	SECP160R1 [SECG]

 	5.2.10	HIT_SUITE_LIST
Le paramètre HIT_SUITE_LIST contient une liste des identifiants de suite HIT pris en charge par le répondant. Le répondant envoie le HIT_SUITE_LIST dans la partie signée du paquet R1. Sur la base du HIT_SUITE_LIST, l'initiateur peut déterminer quels identifiants de suite HIT de source sont acceptés par le répondant.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|     ID n° 1   |     ID n° 2   |     ID n° 3   |     ID n° 4   |
+---------------+---------------+---------------+---------------+
|     ID n° n   |               Bourrage                        |
+---------------+---------------+---------------+---------------+

Type : 715
Longueur : nombre d'identifiants de suite HIT.
ID : identifie un identifiant de suite HIT supporté par l'hôte. La liste des identifiants est ordonnée par préférence de l'hôte. Chaque identifiant de suite HIT est long d'un octet. Les quatre bits de plus fort poids du champ ID correspondent à l'identifiant de suite HIT dans le champ ID OGA ORCHID. Les quatre bits de moindre poids sont réservés et réglés à 0 par l'envoyeur. La réception d'un ID avec les quatre bits de moindre poids non réglés à 0 DEVRAIT être considérée comme une erreur qui PEUT résulter en une NOTIFICATION de type UNSUPPORTED_HIT_SUITE.

L'identifiant de suite HIT indexe une suite HIT. Les suites HIT sont composées d'algorithmes de signature comme défini au paragraphe 5.2.9, et de fonctions de hachage.

Le champ ID dans le HIT_SUITE_LIST est défini comme un champ de huit bits, par opposition au champ de quatre bits de l'identifiant de suite HIT et au champ ID OGA dans le ORCHID. Cette différence est une mesure pour s'accommoder de plus grands identifiants de suite HIT si les 16 valeurs disponibles se révèlent insuffisantes. Dans ce cas, une des 16 valeurs, zéro, va être utilisée pour indiquer que quatre bits supplémentaires de ORCHID vont être utilisés pour coder l'identifiant de suite HIT. Donc, les identifiants de suite HIT actuels de quatre bits utilisent seulement les quatre bits de poids fort dans le champ ID. De futurs documents pourront définir l'utilisation des quatre bits de moindre poids dans le champ ID.

Les identifiants de suite HIT suivants sont définis, et les relations entre la valeur d'identifiant de quatre bits utilisée dans le champ ID OGA et le codage de huit bits au sein du champ d'identifiant HIT_SUITE_LIST sont clarifiées :

Suite HIT	Identifiant de quatre bits	Codage sur huit bits
Réservé	0	0x00
RSA,DSA/SHA-256	1	0x10 (EXIGÉ)
ECDSA/SHA-384	2	0x20 (RECOMMANDÉ)
ECDSA_LOW/SHA-1	3	0x30 (RECOMMANDÉ)

Le tableau suivant donne des détails sur les combinaisons de suite HIT ci-dessus. L'entrée pour chaque algorithme de génération est le codage de la HI comme défini au paragraphe 3.2. Le résultat est long de 96 bits et est directement utilisé dans le ORCHID.

Index	Fonction de hachage	Famille d'alg. HMAC	Signature	Description	
0				Réservé	
1	SHA-256	HMAC-SHA-256	RSA, DSA	RSA ou DSA HI haché avec SHA-256, tronqué à 96 bits	
2	SHA-384	HMAC-SHA-384	ECDSA	HI ECDSA haché avec SHA-384, tronqué à 96 bits	
3	SHA-1	HMAC-SHA-1	ECDSA_LOW	HI ECDSA_LOW haché avec SHA-1, tronqué à 96 bits	

Tableau 10 : suites HIT

Le hachage du répondant comme défini dans la suite HIT détermine le HMAC à utiliser pour la fonction RHASH. Les HMAC actuellement définis sont HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], et HMAC-SHA-1 [RFC2404].

 	5.2.11	TRANSPORT_FORMAT_LIST
Le paramètre TRANSPORT_FORMAT_LIST contient une liste des formats de transport (TF) HIP supportés par le répondant. Le répondant envoie le TRANSPORT_FORMAT_LIST dans la partie signée du paquet R1. Sur la base du TRANSPORT_FORMAT_LIST, l'initiateur choisit un format de transport convenable et inclut le paramètre de format de transport HIP pertinent dans son paquet de réponse.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|          type TF n°           |           type TF n° 2        /
+---------------+---------------+---------------+---------------+
/          type TF n° n         |           Bourrage            |
+---------------+---------------+---------------+---------------+

Type : 2049
Longueur : 2 x nombre de types TF
Type TF : identifie un type de format de transport (TF) pris en charge par l'hôte. Le numéro de type TF correspond au numéro de type de paramètre HIP des paramètres respectifs de format de transport. La liste des types de TF est ordonnée par préférence de l'envoyeur.

Les numéros de type de TF indexent les paramètres HIP respectifs pour les formats de transport dans la gamme de numéros de type entre 2050 et 4095. Les paramètres et leur utilisation sont définis dans des documents distincts. Actuellement, le seul format de transport défini est IPsec ESP [RFC7402].

Pour chaque type de TF mentionné, l'envoyeur du paramètre TRANSPORT_FORMAT_LIST DOIT inclure le paramètre de format de transport pertinent dans le paquet HIP. Le receveur DOIT ignorer le type de TF dans le TRANSPORT_FORMAT_LIST si aucun paramètre de format de transport correspondant n'est présent dans le paquet.

 	5.2.12	HIP_MAC
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|                                                               |
|                             HMAC                              |
/                                                               /
/                               +-------------------------------+
|                               |            Bourrage           |
+---------------+---------------+---------------+---------------+

Type : 61505
Longueur : longueur en octets, excluant Type, Longueur, et Bourrage.
HMAC : HMAC calculé sur le paquet HIP, excluant le paramètre HIP_MAC et tous les paramètres suivants, tels que HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST_UNSIGNED, ou ECHO_RESPONSE_UNSIGNED. Le champ Somme de contrôle DOIT être réglé à zéro, et la longueur d'en-tête HIP dans l'en-tête HIP commun DOIT être calculé en ne couvrant aucun des paramètres exclus quand le HMAC est calculé. La taille du HMAC est la taille naturelle du résultat du calcul de hachage selon la fonction de hachage utilisée.

Le HMAC utilise RHASH comme algorithme de hachage. Le processus de calcul et de vérification est présenté au paragraphe 6.4.1.

 	5.2.13	HIP_MAC_2
HIP_MAC_2 est un MAC du paquet et de la HI de l'envoyeur sous la forme d'un paramètre HOST_ID quand ce paramètre n'est pas réellement inclus dans le paquet. La structure du paramètre est la même que la structure montrée au paragraphe 5.2.12. Les champs sont :

Type : 61569
Longueur : longueur en octets, excluant Type, Longueur, et Bourrage
HMAC : HMAC calculé sur le paquet HIP, excluant le paramètre HIP_MAC_2 et tous les paramètres suivants tels que HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST_UNSIGNED, ou ECHO_RESPONSE_UNSIGNED, et incluant tout paramètre HOST_ID supplémentaire d'envoyeur durant le calcul du HMAC. Le champ Somme de contrôle DOIT être réglé à zéro, et la longueur d'en-tête HIP dans l'en-tête HIP commun DOIT être calculée en ne couvrant aucun paramètre exclu quand le HMAC est calculé. La taille du HMAC est la taille naturelle du résultat du calcul du hachage selon la fonction de hachage utilisée.

Le HMAC utilise RHASH comme algorithme de hachage. Le processus de calcul et de vérification est présenté au paragraphe 6.4.1.

 	5.2.14	HIP_SIGNATURE
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|  Algorithme de signature      |            Signature          /
+---------------+---------------+---------------+---------------+
/                               |             Bourrage           |
+---------------+---------------+---------------+---------------+

Type : 61697
Longueur  : longueur en octets, excluant Type, Longueur, et Bourrage
Algorithme de signature : algorithme de signature
Signature : la signature est calculée sur le paquet HIP, excluant le paramètre HIP_SIGNATURE et tous les paramètres qui suivent le paramètre HIP_SIGNATURE. Quand la signature est calculée, le champ Somme de contrôle DOIT être réglé à zéro, et la longueur d'en-tête HIP dans l'en-tête HIP commun DOIT être calculée seulement jusqu'au début du paramètre HIP_SIGNATURE.

Les algorithmes de signature sont définis au paragraphe 5.2.9. La signature dans le champ Signature est codée en utilisant la méthode dépendante de l'algorithme de signature (par exemple, selon la [RFC3110] dans le cas de RSA/SHA-1, [RFC5702] dans le cas de RSA/SHA-256, [RFC2536] dans le cas de DSA, ou [RFC6090] dans le cas de ECDSA).

Le calcul et la vérification de HIP_SIGNATURE suivent le processus défini au paragraphe 6.4.2.

 	5.2.15	HIP_SIGNATURE_2
HIP_SIGNATURE_2 exclut les paramètres variables dans le paquet R1 pour permettre la pré création de R1. La structure de paramètre est la même que celle montrée au paragraphe 5.2.14. Les champs sont :

Type : 61633
Longueur : longueur en octets, excluant Type, Longueur, et Bourrage
SIG alg  : algorithme de signature
Signature : au sein du paquet R1 qui contient le paramètre HIP_SIGNATURE_2, la HIT de l'initiateur, le champ Somme de contrôle, et les champs Opaque et #I aléatoire dans le paramètre PUZZLE DOIVENT être réglés à zéro lors du calcul de la signature HIP_SIGNATURE_2. De plus, la longueur de paquet HIP dans l'en-tête HIP DOIT être ajustée comme si la HIP_SIGNATURE_2 n'était pas dans le paquet durant le calcul de la signature, c'est-à-dire que la longueur du paquet HIP pointe sur le début du paramètre HIP_SIGNATURE_2 durant la signature et la vérification.

Mettre à zéro la HIT de l'initiateur rend possible de créer des paquets R1 à l'avance, pour minimiser les effets de possibles attaques de DoS. Mettre à zéro les champs #I aléatoire et Opaque au sein du paramètre PUZZLE permet que ces champs soient remplis de façon dynamique sur les R1 pré calculés. Le calcul et la vérification de signature suivent le processus défini au paragraphe 6.4.2.

 	5.2.16	SEQ
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|                         Identifiant de mise à jour            |
+---------------+---------------+---------------+---------------+

Type : 385
Longueur : 4
Identifiant de mise à jour : numéro de séquence de 32 bits
L'identifiant de mise à jour est un entier non signé, dans l'ordre des octets du réseau, initialisé par un hôte à zéro en passant à l'état ESTABLISHED. Identifiant de mise à jour a sa portée sur une seule association HIP, et pas à travers plusieurs associations ou hôtes. L'identifiant de mise à jour est incrémenté de un avant chaque nouvel UPDATE envoyé par l'hôte ; le premier paquet UPDATE généré par un hôte a un identifiant de mise à jour de 0.

 	5.2.17	ACK
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|                Identifiant 1 de mise à jour d'homologue       |
+---------------+---------------+---------------+---------------+
/                Identifiant n de mise à jour d'homologue       |
+---------------+---------------+---------------+---------------+

Type : 449
Longueur : longueur en octets, excluant Type et Longueur
Identifiant de mise à jour d'homologue : numéro de séquence de 32 bits correspondant à l'identifiant de mise à jour acquitté.

Le paramètre ACK inclut un ou plusieurs identifiants de mise à jour qui ont été reçus de l'homologue. Le nombre d'identifiants de mise à jour d'homologue peut être déduit de la longueur en la divisant par 4.

 	5.2.18	ENCRYPTED
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|                           Réservé                             |
+---------------+---------------+---------------+---------------+
|                              IV                               /
/                                                               /
/                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------+---------------+                               /
/                        Données chiffrées                      /
/                                                               /
/                               +-------------------------------+
/                               |            Bourrage           |
+---------------+---------------+---------------+---------------+

Type : 641
Longueur : longueur en octets, excluant Type, Longueur, et Bourrage.
Réservé : zéro à l'envoi, ignoré à réception.
IV : valeur d'initialisation, si nécessaire, autrement non existant. La longueur de l'IV est déduite du HIP_CIPHER.
Données chiffrées : les données sont chiffrées en utilisant l'algorithme défini dans le paramètre HIP-CIPHER.

Le paramètre ENCRYPTED encapsule d'autres paramètres, les données chiffrées, qui contiennent un ou plusieurs paramètres HIP en format de chiffrement de bloc. Par conséquent, les premiers champs dans le ou les paramètres encapsulés sont Type et Longueur du premier de ces paramètres, permettant que le contenu soit facilement analysé après déchiffrement.

Le champ étiqueté "Données chiffrées" consiste en le résultat d'un ou plusieurs paramètres HIP enchaînés à la suite qui ont été passés par un algorithme de chiffrement. Chacun de ces paramètres internes est bourré conformément aux règles du paragraphe 5.2.1 sur le bourrage des paramètres individuels. Par suite, les paramètres enchaînés vont être un bloc de données aligné sur 8 octets.

Certains algorithmes de chiffrement exigent que les données chiffrées soient un multiple de la taille de bloc de l'algorithme de chiffrement. Dans ce cas, le bloc de données DOIT inclure un bourrage supplémentaire, comme spécifié par l'algorithme de chiffrement. La taille du bourrage supplémentaire est choisie de telle sorte que la longueur du bloc de données non chiffrées soit un multiple de la taille du bloc de chiffrement. L'algorithme de chiffrement peut spécifier des octets de bourrage autres que zéro ; par exemple, AES [FIPS.197.2001] utilise le schéma de bourrage PKCS5 (voir au paragraphe 6.1.1 de la [RFC2898]) où les n octets restants pour remplir le bloc ont chacun la valeur de n. Cela donne un bloc de "données non chiffrées" qui est transformé en un bloc de "données chiffrées" par la suite de chiffrement. Ce bourrage supplémentaire ajouté à l'ensemble de paramètres pour satisfaire aux règles d'alignement sur le bloc de chiffrement n'est pas compté dans les champs HIP Longueur de TLV, et ce bourrage supplémentaire devrait être retiré par la suite de chiffrement au moment du déchiffrement.

Noter que la longueur du résultat de la suite de chiffrement peut être plus petite ou plus grande que la longueur de l'ensemble de paramètres à chiffrer, car le processus de chiffrement peut compresser les données ou leur ajoure un bourrage supplémentaire. Une fois ce processus de chiffrement achevé, le champ Données chiffrées est prêt à être inclus dans le paramètre. Si nécessaire, un bourrage supplémentaire pour l'alignement sur huit octets est alors ajouté conformément aux règles du paragraphe 5.2.1.

 	5.2.19	NOTIFICATION
Le paramètre NOTIFICATION est utilisé pour transmettre des données d'information, comme des conditions d'erreur et des transitions d'état, à un homologue HIP. Un paramètre NOTIFICATION peut apparaître dans des paquets NOTIFY. L'utilisation du paramètre NOTIFICATION dans d'autres types de paquets fera l'objet d'études ultérieures.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|          Réservé              |     Type de message Notify    |
+---------------+---------------+---------------+---------------+
|                                                               /
/                 Données de la notification                    /
/                                               +---------------+
/                                               |    Bourrage   |
+---------------+---------------+---------------+---------------+

Type : 832
Longueur : longueur en octets, excluant Type, Longueur, et Bourrage.
Réservé : zéro à l'envoi, ignoré à réception.
Type de message Notify : spécifie le type de notification.
Données de la notification : données d'information ou d'erreur transmises en plus du type de message Notify. Les valeurs de ce champ sont spécifiques du type (voir ci-dessous).

Les informations de notification peuvent être des messages d'erreur qui spécifient pourquoi une association de sécurité HIP n'a pas pu être établie. Elles peuvent aussi être des données d'état qu'une mise en œuvre de HIP souhaite communiquer à un processus d'homologue. Le tableau ci-dessous fait la liste des messages de notification et de leurs types de message Notify. Les paquets HIP PEUVENT contenir de multiples paramètres NOTIFICATION si plusieurs problèmes existent ou si plusieurs éléments d'information indépendants doivent être transmis.

Pour éviter certains types d'attaques, un répondant DEVRAIT éviter d'envoyer une NOTIFICATION à un hôte avec lequel il n'a pas réussi à vérifier une solution de puzzle.

Les types de message Notify dans la gamme 0-16383 sont destinés aux rapports d'erreurs, et ceux dans la gamme 16384-65535 sont pour d'autres informations d'état. Une mise en œuvre qui reçoit un paquet NOTIFY avec un type de message Notify qui indique une erreur dans la réponse à un paquet de demande (par exemple, I1, I2, UPDATE) DEVRAIT supposer que la demande correspondante a entièrement échoué. Les types d'erreur non reconnus DOIVENT être ignorés, mais ils DEVRAIT être enregistrés.

Comme elles sont actuellement définies, les valeurs de type de message Notify de 1 à 10 sont utilisées pour informer d'erreurs dans les structures de paquet , et les valeurs de 11 à 20 pour informer de problèmes dans les paramètres.

Les données de notification dans les paramètres NOTIFICATION où le type de message Notify est dans la gamme d'état DOIVENT être ignorés si elles ne sont pas reconnues.

Valeur	Types de message Notify - Erreurs	Signification	
1	UNSUPPORTED_CRITICAL
_PARAMETER_TYPE	Envoyé si le type de paramètre a le bit "critique" établi et si le type de paramètre n’est pas reconnu. Données de notification contient le type de paramètre de deux octets.	
7	INVALID_SYNTAX	Indique que le message HIP reçu était invalide à cause d'une valeur de type, longueur, ou valeur hors gamme ou parce que la demande était par ailleurs mal formée. Pour éviter une attaque de déni de service utilisant des messages contrefaits, cet état ne peut être retourné que pour des paquets dont les HIP_MAC (si présent) et SIGNATURE ont été vérifiés. Cet état DOIT être envoyé dans des réponses à toute erreur non couverte par un des autres types d'état et NE DEVRAIT PAS contenir de détails, pour éviter de faire fuir des informations à quelqu'un qui sonde un nœud. Pour aider au débogage, une information d'erreur plus détaillée DEVRAIT être écrite à la console ou enregistrée.	
14	NO_DH_PROPOSAL_CHOSEN	Aucun des identifiants de groupe proposé n'est acceptable.	
15	INVALID_DH_CHOSEN	Le champ Identifiant de groupe DH ne correspond pas à un de ceux offerts par le répondant.	
16	NO_HIP_PROPOSAL_CHOSEN	Aucune des suites HIT ou algorithmes de chiffrement HIP proposés n'est acceptable.	
17	INVALID_HIP_CIPHER_CHOSEN	L'identifiant de chiffrement ne correspond pas à un de ceux offerts par le répondant.	
20	UNSUPPORTED_HIT_SUITE	Envoyé dans une réponse à un paquet I1 ou R1 pour lequel la suite HIT n'est pas supportée.	
24	AUTHENTICATION_FAILED	Envoyé dans une réponse à un échec de signature HIP, excepté quand la vérification de signature échoue dans un message NOTIFY.	
26	CHECKSUM_FAILED	Envoyé dans une réponse à un échec de somme de contrôle HIP.	
28	HIP_MAC_FAILED	Envoyé dans une réponse à un échec de HMAC HIP.	
32	ENCRYPTION_FAILED	Le répondant n'a pas réussi à déchiffrer le paramètre ENCRYPTED.	
40	INVALID_HIT	Envoyé dans une réponse à un échec de validation de la HIT de l'homologue à partir de la HI correspondante.	
42	BLOCKED_BY_POLICY	Le répondant ne veut pas établir une association pour une raison de politique (par exemple, la HIT reçue est NULL et la politique ne permet pas le mode opportuniste).	
44	RESPONDER_BUSY
_PLEASE_RETRY	Le répondant ne veut pas établir une association, car il souffre de surcharge et a choisi  de diminuer la charge en rejetant la demande de l'initiateur. L'initiateur peut réessayer ; cependant, l'initiateur DOIT trouver une autre (différente) solution de puzzle pour chacun de ces essais. Noter que l'initiateur peut devoir obtenir un nouveau puzzle avec un nouvel échange I1/R1.	

Valeur	Types de message Notify - État	Signification	
16384	I2_ACKNOWLEDGEMENT	Le répondant a un paquet I2 de l'initiateur mais doit mettre en file d'attente le paquet I2 pour le traiter. Le puzzle a été correctement résolu, et le répondant veut établir une association mais a actuellement un certain nombre de paquets I2 dans la file d'attente de traitement. Le paquet R2 est envoyé après que le paquet I2 est traité.	

 	5.2.20	ECHO_REQUEST_SIGNED
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|                Données opaques (longueur variable)            |
+---------------+---------------+---------------+---------------+

Type : 897
Longueur : longueur des données opaques en octets.
Données opaques : données opaques, supposée n'avoir de signification que pour le nœud qui a envoyé ECHO_REQUEST_SIGNED et reçu une ECHO_RESPONSE_SIGNED ou ECHO_RESPONSE_UNSIGNED correspondante.

Le paramètre ECHO_REQUEST_SIGNED contient un bloc opaque de données que l'envoyeur veut recevoir en écho dans le paquet de réponse correspondant.

Le paramètre ECHO_REQUEST_SIGNED et les réponses d'écho correspondantes PEUVENT être utilisés pour toute occasion où un nœud veut porter un état dans un paquet de demande et l'avoir en retour dans un paquet de réponse. Le ECHO_REQUEST_SIGNED est couvert par HIP_MAC et SIGNATURE. Un paquet HIP ne peut contenir qu'un paramètre ECHO_REQUEST_SIGNED et PEUT contenir plusieurs paramètres ECHO_REQUEST_UNSIGNED. On DOIT répondre au paramètre ECHO_REQUEST_SIGNED avec un ECHO_RESPONSE_SIGNED.

 	5.2.21	ECHO_REQUEST_UNSIGNED
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|                Données opaques (longueur variable)            |
+---------------+---------------+---------------+---------------+

Type : 63661
Longueur : longueur des données opaques en octets.
Données opaques :  données opaques, supposées n'avoir de signification que pour le nœud qui envoie ECHO_REQUEST_UNSIGNED et reçoit une ECHO_RESPONSE_UNSIGNED correspondante.

Le paramètre ECHO_REQUEST_UNSIGNED contient un bloc opaque de données que l'envoyeur veut recevoir en écho dans le paquet de réponse correspondant.

Le paramètre ECHO_REQUEST_UNSIGNED et la réponse en écho correspondante PEUVENT être utilisés pour toute occasion où un nœud veut porter un état dans un paquet de demande et l'avoir en retour dans un paquet de réponse. Le ECHO_REQUEST_UNSIGNED n'est pas couvert par le HIP_MAC et la SIGNATURE. Un paquet HIP peut contenir un ou plusieurs paramètres ECHO_REQUEST_UNSIGNED. Il est possible que des boîtiers de médiation ajoutent des paramètres ECHO_REQUEST_UNSIGNED dans les paquets HIP qui y passent. Le créateur (hôte d'extrémité ou boîtier de médiation) de la ECHO_REQUEST_UNSIGNED doit créer le champ Opaque afin qu'il puisse ultérieurement identifier et retirer le paramètre ECHO_RESPONSE_UNSIGNED correspondant.

La réponse à un paramètre ECHO_REQUEST_UNSIGNED DOIT avoir un paramètre ECHO_RESPONSE_UNSIGNED.

 	5.2.22	ECHO_RESPONSE_SIGNED
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|                Données opaques (longueur variable)            |
+---------------+---------------+---------------+---------------+

Type : 961
Longueur : longueur des données opaques en octets.
Données opaques :  données opaques, copiées non modifiées du paramètre ECHO_REQUEST_SIGNED ou ECHO_REQUEST_UNSIGNED qui a déclenché cette réponse.

Le paramètre ECHO_RESPONSE_SIGNED contient un bloc opaque de données que l'envoyeur du ECHO_REQUEST_SIGNED veut recevoir en écho. Les données opaques sont copiées non modifiées du paramètre ECHO_REQUEST_SIGNED.

Les paramètres ECHO_REQUEST_SIGNED et ECHO_RESPONSE_SIGNED PEUVENT être utilisés pour toute occasion où un nœud veut porter un état dans un paquet de demande et le recevoir en retour dans un paquet de réponse. Le ECHO_RESPONSE_SIGNED est couvert par le HIP_MAC et la SIGNATURE.

 	5.2.23	ECHO_RESPONSE_UNSIGNED
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |           Longueur            |
+---------------+---------------+---------------+---------------+
|                Données opaques (longueur variable)            |
+---------------+---------------+---------------+---------------+

Type : 63425
Longueur : longueur des données opaques en octets.
Données opaques :  données opaques, copiées non modifiées du paramètre ECHO_REQUEST_SIGNED ou ECHO_REQUEST_UNSIGNED qui a déclenché cette réponse.

Le paramètre ECHO_RESPONSE_UNSIGNED contient un bloc opaque de données que l'envoyeur du ECHO_REQUEST_SIGNED ou ECHO_REQUEST_UNSIGNED veut recevoir en écho. Les données opaques sont copiées non modifiées du paramètre de demande d'écho correspondant.

La demande d'écho et les paramètres ECHO_RESPONSE_UNSIGNED PEUVENT être utilisés pour toute occasion où un nœud veut porter un état dans un paquet de demande et le recevoir en retour  dans un paquet de réponse. Le ECHO_RESPONSE_UNSIGNED n'est pas couvert par le HIP_MAC et la SIGNATURE.

 	5.3	Paquets HIP
Il y a huit paquets HIP de base (voir le Tableau 11). Quatre sont pour l'échange de base HIP, un est pour la mise à jour, un est pour l'envoi des notifications, et deux sont pour clore une association HIP. La prise en charge du type de paquet NOTIFY est facultative, mais la prise en charge de tous les autres types de paquet HIP mentionnés ci-dessous est obligatoire.

Type de paquet	Nom de paquet
1	I1 - paquet HIP initiateur
2	R1 - paquet HIP répondant
3	I2 - second paquet HIP initiateur
4	R2 - second paquet HIP répondant
16	UPDATE - paquet HIP de mise à jour
17	NOTIFY - paquet HIP de notification
18	CLOSE - paquet de clôture d'association HIP
19	CLOSE_ACK - paquet d'accusé de réception de clôture de HIP

Tableau 11 : Paquets HIP et valeurs de type de paquet

Les paquets consistent en l'en-tête fixe décrit au paragraphe 5.1, suivi par les paramètres. La partie paramètre, consiste en zéro, un ou plusieurs paramètres codés en TLV.

En plus des paquets de base, d'autres types de paquet peuvent être définis plus tard dans des spécifications distinctes. Par exemple, la prise en charge de la mobilité et du multi rattachements n'est pas incluse dans la présente spécification. Voir dans "Notation" (paragraphe 2.2) la notation utilisée dans les opérations.

À l'avenir, une charge utile facultative de couche supérieure POURRA permettre l'en-tête HIP. Le champ "Prochain en-tête" dans l'en-tête indique si il y a des données supplémentaires qui suivent l'en-tête HIP. Le paquet HIP NE DOIT cependant PAS être fragmenté dans plusieurs en-têtes d'extension en réglant le champ Prochain en-tête dans un en-tête HIP au numéro de protocole HIP. Cela limite la taille des données supplémentaires possibles dans le paquet.

 	5.3.1	I1 - paquet initiateur HIP
Valeurs d'en-tête HIP pour le paquet I1 :

En-tête :
Type de paquet = 1
SRC HIT = HIT de l'initiateur
DST HIT = HIT du répondant, ou NULL

IP ( HIP ( DH_GROUP_LIST ) )

Le paquet I1 contient l'en-tête HIP fixe et le DH_GROUP_LIST de l'initiateur.

Bits de contrôle valides : aucun

L'initiateur reçoit la HIT du répondant d'une recherche DNS sur le FQDN du répondant (voir la [RFC8005]) de quelque autre répertoire, ou d'un tableau local. Si l'initiateur ne connaît pas la HIT du répondant, il peut tenter d'utiliser le mode opportuniste avec NULL (que des zéros) comme HIT du répondant. Voir aussi "Mode HIP opportuniste" (paragraphe  4.1.8).

Comme le paquet I1 est si facile à contrefaire même si il est signé, aucune tentative n'est faite pour augmenter son coût de génération ou de traitement.

L'initiateur inclut un paramètre DH_GROUP_LIST au paquet I1 pour informer le répondant de ses identifiants de groupe DH préférés. Noter que la DH_GROUP_LIST dans le paquet I1 n'est pas protégée par une signature.

Les mises en œuvre DOIVENT être capables de traiter une tempête de réception de paquets I1 qui arrivent dans un petit intervalle de temps, les éliminant avec le contenu commun.

 	5.3.2	R1 - paquet de répondant HIP
Valeurs d'en-tête HIP pour le paquet R1 :

En-tête :
Type de paquet = 2
SRC HIT = HIT du répondant
DST HIT = HIT de l'initiateur

IP ( HIP ( [ R1_COUNTER, ]
                PUZZLE,
                DIFFIE_HELLMAN,
                HIP_CIPHER,
                HOST_ID,
                HIT_SUITE_LIST,
                DH_GROUP_LIST,
                [ ECHO_REQUEST_SIGNED, ]
                TRANSPORT_FORMAT_LIST,
                HIP_SIGNATURE_2 )
                <, ECHO_REQUEST_UNSIGNED >i)

Bits de contrôle valides : A

Si la HI du répondant est anonyme, le contrôle A DOIT être établi.

La HIT de l'initiateur DOIT correspondre à celle reçue dans le paquet I1 si le R1 est une réponse à une I1. Si le répondant a plusieurs HI, la HIT de répondant utilisée DOIT correspondre à celle de la demande de l'initiateur. Si l'initiateur a utilisé le mode opportuniste, le répondant peut choisir librement parmi ses HI. Voir aussi "Mode HIP opportuniste" (paragraphe  4.1.8).

Le compteur de génération de paquets R1 est utilisé pour déterminer la génération de puzzles actuellement valides. La valeur est augmentée périodiquement, et il est RECOMMANDÉ qu'elle soit augmentée au moins aussi souvent que les solutions aux vieux puzzles ne sont plus acceptées.

Le puzzle contient un #I aléatoire et la difficulté #K. La difficulté #K indique le nombre de bits de moindre poids, dans le résultat du hachage de puzzle, qui doivent être des zéros ; voir au paragraphe 4.1.2. Le #I aléatoire n'est pas couvert par la signature et doit être mis à zéro durant le calcul de signature, permettant à l'envoyeur de choisir et régler le #I dans un paquet R1 pré calculé juste avant de l'envoyer à l'homologue.

Le répondant choisit l'identifiant de groupe DIFFIE_HELLMAN et la valeur publique sur la base de la préférence de l'initiateur exprimée dans le paramètre DH_GROUP_LIST dans le paquet I1. Le répondant renvoie sa propre préférence sur la base de laquelle il choisit la valeur publique DH comme DH_GROUP_LIST. Cela permet à l'initiateur de déterminer si sa propre DH_GROUP_LIST dans le paquet I1 envoyé a été manipulée par un attaquant.

La valeur publique Diffie-Hellman est éphémère, et les valeurs NE DEVRAIENT PAS être réutilisées sur différentes associations HIP. Une fois que le répondant a reçu une réponse valide à un paquet R1, cette valeur Diffie-Hellman DEVRAIT être déconseillée. Il est possible que le répondant ait envoyé la même valeur Diffie-Hellman à différents hôtes simultanément dans des paquets R1 correspondants, et ces réponses devraient aussi être acceptées. Cependant, comme défense contre une tempête de paquets, une mise en œuvre PEUT proposer, et réutiliser sauf si c'est évitable, la même valeur Diffie-Hellman pendant un certain temps -- par exemple, 15 minutes. En utilisant un petit nombre de puzzles différents pour une certaine valeur Diffie-Hellman, les paquets R1 peuvent être pré calculés et délivrés aussi rapidement que les paquets I1 arrivent. Un processus de nettoyage devrait éliminer les valeurs Diffie-Hellman et puzzles non utilisés.

Réutiliser les valeurs publiques Diffie-Hellman ouvre le risque potentiel qu'un initiateur se retrouve avec le même matériel de chiffrement (du fait d'un générateur de nombres aléatoires défectueux). Aussi, plus d'un initiateur utilisant la même moitié de clé publique de répondant peut conduire à faciliter des attaques cryptographiques potentielles et à une imparfaite sécurité vers l'avant.

Cependant, ces risques impliqués dans la réutilisation de la même valeur publique sont statistiques ; c'est-à-dire que les auteurs n'ont pas connaissance d'un mécanisme qui permettrait la manipulation du protocole de telle sorte que le risque de la réutilisation d'une certaine clé publique Diffie-Hellman de répondant différerait de la probabilité de base. Par conséquent, il est RECOMMANDÉ que les répondants évitent de réutiliser la même clé DH avec plusieurs initiateurs, mais parce que le risque est considéré d'un point de vue statistique et non connu pour être manipulable, les mises en œuvre PEUVENT réutiliser une clé afin de faciliter les mises en œuvre à ressource restreintes et augmenter la probabilité de communication réussie avec des clients légitimes même en cas de tempête de paquets I1. En particulier, quand il est trop coûteux de générer assez de paquets R1 pré calculés pour fournir à chaque initiateur potentiel une clé DH différente, le répondant PEUT envoyer la même clé DH à plusieurs initiateurs, créant par là la possibilité de multiples initiateurs légitimes finissant par utiliser la même clé publique côté répondant. Cependant, aussitôt que le répondant sait qu'il va utiliser une clé DH particulière, il DEVRAIT arrêter de l'offrir. Ce schéma est destiné à permettre aux répondants à ressources restreintes d'offrir le service sous une tempête de paquets I1 et simultanément de rendre la probabilité de réutilisation de clé DH statistiquement aussi faible que possible.

Si le répondant utilise la même paire de clés DH pour plusieurs prises de contact, il doit faire attention à éviter les attaques de petit sous groupe [RFC2785]. Pour éviter ces attaques, quand il reçoit le message I2, le répondant DEVRAIT valider la clé publique DH de l'initiateur comme décrit dans la [RFC2785], paragraphe 3.1. Si la validation échoue, le répondant NE DOIT PAS générer une clé DH partagée et DOIT interrompre en silence le BEX HIP.

Le paramètre HIP-CIPHER contient les algorithmes de chiffrement acceptés par le répondant pour chiffrer le contenu du paramètre ENCRYPTED, dans l'ordre de préférence. Toutes les mises en œuvre DOIVENT accepter AES [RFC3602].

Le paramètre HIT_SUITE_LIST est une liste ordonnée des suites de HIT préférées et prises en charge du répondant. La liste permet à l'initiateur de déterminer si sa propre HIT de source correspond à une suite acceptée par le répondant.

Les paramètres ECHO_REQUEST_SIGNED et ECHO_REQUEST_UNSIGNED contiennent des données que l'envoyeur veut recevoir non modifiées dans le paquet de réponse correspondant dans le paramètre ECHO_RESPONSE_SIGNED ou ECHO_RESPONSE_UNSIGNED. Comme décrit au paragraphe 5.2.21, le paquet R1 peut contenir zéro, un ou plusieurs paramètres ECHO_REQUEST_UNSIGNED.

Le paramètre TRANSPORT_FORMAT_LIST est une liste ordonnée des types de format de transport préférés et pris en charge du répondant. La liste permet à l'initiateur et au répondant de s'accorder sur un type commun pour la protection de charge utile. Ce paramètre est décrit au paragraphe 5.2.11.

La signature est calculée sur la totalité du paquet HIP comme décrit au paragraphe 5.2.15. Cela permet au répondant d'utiliser des R1 pré calculés. L'initiateur DEVRAIT valider cette signature. Il DOIT vérifier que la HI du répondant correspond à celle attendue, s'il en est.

 	5.3.3	I2 - second paquet d'initiateur HIP
Valeurs d'en-tête HIP pour le paquet I2 :

En-tête :
Type de paquet = 3
SRC HIT = HIT de l'initiateur
DST HIT = HIT du répondant

IP ( HIP ( [R1_COUNTER,]
                SOLUTION,
                DIFFIE_HELLMAN,
                HIP_CIPHER,
                ENCRYPTED { HOST_ID } ou HOST_ID,
                [ ECHO_RESPONSE_SIGNED, ]
                TRANSPORT_FORMAT_LIST,
                HIP_MAC,
                HIP_SIGNATURE
                <, ECHO_RESPONSE_UNSIGNED>i ) )

Bits de contrôle valides : A

Les HIT utilisées DOIVENT correspondre à celles utilisées dans le R1.

Si la HI de l'initiateur est anonyme, le bit de contrôle A DOIT être établi.

Si il est présent dans le paquet I1, l'initiateur DOIT inclure dans le paquet I2 une copie non modifiée du paramètre R1_COUNTER reçu dans le paquet R1 correspondant.

La solution contient le #I aléatoire provenant du R1 et le #J calculé. Les #K bits de moindre poids de RHASH( #I | ... | #J ) DOIVENT être à zéro.

La valeur Diffie-Hellman est éphémère. Si elle est pré calculée, un processus de nettoyage devrait éliminer les valeurs Diffie-Hellman non utilisées. Le répondant PEUT réutiliser les valeurs Diffie-Hellman sous certaines conditions comme spécifié au paragraphe 5.3.2.

Le paramètre HIP_CIPHER contient la seule suite de chiffrement choisie par l'initiateur, qu'il utilise pour chiffrer les paramètres ENCRYPTED. Le chiffrement choisi DOIT correspondre à un des chiffrements offerts par le répondant dans le R1. Toutes les mises en œuvre DOIVENT accepter AES [RFC3602].

La HI de l'initiateur PEUT être chiffrée en utilisant l'algorithme de chiffrement HIP_CIPHER. Le matériel de chiffrement est déduit de l'échange Diffie-Hellman comme défini au paragraphe 6.5.

Les paramètres ECHO_RESPONSE_SIGNED et ECHO_RESPONSE_UNSIGNED contiennent les données opaques copiées non modifiées des paramètres correspondants de la demande d'écho.

Le paramètre TRANSPORT_FORMAT_LIST contient le seul type de format de transport choisi par l'initiateur. Le type choisi DOIT correspondre à un des types offerts par le répondant dans le R1. Actuellement, le seul format de transport défini est le format de transport ESP ([RFC7402]).

La valeur de HMAC dans le paramètre HIP_MAC est calculée sur le paquet HIP entier, excluant tous les paramètres après le HIP_MAC, comme décrit au paragraphe 6.4.1. Le répondant DOIT valider le HIP_MAC.

La signature est calculée sur le paquet HIP entier, en excluant tous les paramètres après le HIP_SIGNATURE, comme décrit au paragraphe 5.2.14. Le répondant DOIT valider cette signature. Le répondant utilise la HI dans le paquet ou une HI acquise par d'autres moyens pour vérifier la signature.

 	5.3.4	R2 - second paquet de répondant HIP
Valeurs d'en-tête HIP pour le paquet R2 :

En-tête :
Type de paquet = 4
SRC HIT = HIT du répondant
DST HIT = HIT de l'initiateur

IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) )

Bits de contrôle valides : aucun

Le HIP_MAC_2 est calculé sur le paquet HIP entier, avec le paramètre HOST_ID du répondant enchaîné avec le paquet HIP. Le paramètre HOST_ID est retiré après le calcul du HMAC. La procédure est décrite au paragraphe 6.4.1.

La signature est calculée sur le paquet HIP entier.

L'initiateur DOIT valider le HIP_MAC et la signature.

 	5.3.5	UPDATE - paquet de mise à jour HIP
Valeurs d'en-tête HIP pour le paquet UPDATE :

En-tête :
       Type de paquet = 16
       SRC HIT = HIT d'envoyeur
       DST HIT = HIT du receveur

IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) )

Bits de contrôle valides : aucun

Le paquet UPDATE contient les paramètres obligatoires HIP_MAC et HIP_SIGNATURE et d'autres paramètres facultatifs.

Le paquet UPDATE contient zéro ou un paramètre SEQ. La présence d'un paramètre SEQ indique que le receveur DOIT accuser réception du UPDATE. Un UPDATE qui ne contient pas de SEQ mais seulement un paramètre ACK est simplement un accusé de réception d'un UPDATE antérieur et NE DOIT PAS être lui-même l'objet d'un accusé de réception par un paramètre ACK distinct. De tels paquets UPDATE contenant seulement un paramètre ACK n'exigent pas de traitement par rapport aux autres paquets UPDATE. Un paquet UPDATE sans un paramètre SEQ ou ACK est invalide ; une telle mise à jour non acquittée DOIT plutôt utiliser un paquet NOTIFY.

Un paquet UPDATE contient zéro ou un paramètre ACK. Le paramètre ACK fait écho au numéro de séquence SEQ du paquet UPDATE qui fait l'objet de l'accusé de réception. Un hôte PEUT choisir d'accuser réception de plus d'un paquet UPDATE à la fois ; par exemple, le paramètre ACK peut contenir les deux dernières valeurs de SEQ reçues, pour la résilience à la perte de paquet. Les valeurs de ACK ne sont pas cumulatives ; chaque valeur unique de SEQ reçue exige au moins une valeur correspondante de ACK dans la réponse. Les paramètres ACK reçus qui sont redondants sont ignorés. Les hôtes DOIT mettre en œuvre le traitement des paramètres ACK avec plusieurs numéros de séquence SEQ même si ils ne mettent pas en œuvre l'envoi de paramètres ACK avec plusieurs numéros de séquence SEQ.

Le paquet UPDATE peut contenir à la fois un paramètre SEQ et un paramètre ACK. Dans ce cas, le paramètre ACK est porté comme un UPDATE sortant. En général, les UPDATE qui portent des SEQ DEVRAIT faire l'objet d'un accusé de réception à l'achèvement du traitement du UPDATE. Un hôte PEUT choisir de conserver le UPDATE qui porte un paramètre ACK pendant un bref instant pour permettre la possibilité d'un portage du paramètre ACK, d'une façon similaire aux accusé de réception de TCP retardés.

Un envoyeur PEUT choisir d'avancer la transmission fiable d'un UPDATE particulier (par exemple, il est surchargé par les événements). La sémantique est telle que le receveur DOIT accuser réception du UPDATE, mais l'envoyeur PEUT choisir de ne pas se soucier de recevoir le paramètre ACK.

Les UPDATE PEUVENT être retransmis sans incrémenter SEQ. Si le même sous ensemble de paramètres est inclus dans plusieurs UPDATE avec des SEQ différents, l'hôte DOIT s'assurer que le traitement plusieurs fois des paramètres par le receveur ne va pas résulter en une erreur du protocole.

 	5.3.6	NOTIFY - paquet de notification HIP
Le paquet Notify PEUT être utilisé pour fournir des informations à un homologue. Normalement, NOTIFY est utilisé pour indiquer un type d'erreur de protocole ou un échec de négociation. Les paquets Notify ne font pas l'objet d'un accusé de réception. Le receveur peut traiter le paquet comme seulement pour information, et NE DEVRAIT PAS changer son état HIP (voir au paragraphe 4.4.2) sur la seule base d'un paquet Notify reçu.

Valeurs d'en-tête HIP pour le paquet NOTIFY :

En-tête :
       Type de paquet = 17
       SRC HIT = HIT d'envoyeur
       DST HIT = HIT du receveur, ou zéro si inconnu

     IP ( HIP (<NOTIFICATION>i, [HOST_ID, ] HIP_SIGNATURE) )

Bits de contrôle valides : aucun

Le paquet Notify est utilisé pour porter un ou plusieurs paramètres NOTIFICATION.

 	5.3.7	CLOSE - paquet de clôture d’association HIP
Valeurs d'en-tête HIP pour le paquet CLOSE :

En-tête :
       Type de paquet = 18
       SRC HIT = HIT d'envoyeur
       DST HIT = HIT du receveur

     IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) )

Bits de contrôle valides : aucun

L'envoyeur DOIT inclure un ECHO_REQUEST_SIGNED utilisé pour valider le CLOSE_ACK reçu en réponse, et un HIP_MAC et une signature (calculés sur le paquet HIP entier).

L'homologue receveur DOIT répondre avec un CLOSE_ACK contenant un ECHO_RESPONSE_SIGNED correspondant au ECHO_REQUEST_SIGNED reçu.

 	5.3.8	CLOSE_ACK - paquet d'accusé de réception de clôture de HIP
Valeurs d'en-tête HIP pour le paquet CLOSE_ACK :

En-tête :
Type de paquet = 19
SRC HIT = HIT d'envoyeur
DST HIT = HIT du receveur

IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) )

Bits de contrôle valides : aucun

L'envoyeur DOIT inclure un HMAC et une signature (calculés sur le paquet HIP entier).

L'homologue receveur DOIT valider le ECHO_RESPONSE_SIGNED et valider le HIP_MAC et la signature si le receveur a un état pour une association HIP.

 	5.4	Messages ICMP 
Quand une mise en œuvre HIP détecte un problème avec un paquet entrant, et qu'elle ne peut pas déterminer l'identité de l'envoyeur du paquet ou n'a aucune association HIP existante avec l'envoyeur du paquet, elle PEUT répondre avec un paquet ICMP. Une telle réponse DOIT être limitée en débit comme décrit dans la [RFC4443]. Dans la plupart des cas, le paquet ICMP a le type "Problème de paramètre" (12 pour ICMPv4, 4 pour ICMPv6) avec le pointeur sur le champ qui a causé la génération du message ICMP.

 	5.4.1	Version invalide
Si une mise en œuvre HIP reçoit un paquet HIP qui a un numéro de version HIP non reconnu, elle DEVRAIT répondre, en débit limité, par un paquet ICMP de type "Problème de paramètre", avec le pointeur sur l'octet Version/Réservé dans l'en-tête HIP.

 	5.4.2	Autres problèmes avec l'en-tête HIP et la structure de paquet
Si une mise en œuvre HIP reçoit un paquet HIP qui a d'autres problèmes irrécupérables dans l'en-tête ou le format de paquet, elle PEUT répondre en débit limité, avec un paquet ICMP de type "Problème de paramètre ", avec le pointeur sur le champ qui n'a pas réussi à satisfaire aux vérifications de format. Cependant, une mise en œuvre NE DOIT PAS envoyer un message ICMP si la somme de contrôle échoue ; à la place, elle DOIT abandonner le paquet en silence.

 	5.4.3	Solution de puzzle invalide
Si une mise en œuvre HIP reçoit un paquet I2 qui a une solution de puzzle invalide, le comportement dépend de la version IP sous-jacente. Si IPv6 est utilisé, la mise en œuvre DEVRAIT répondre avec un paquet ICMP de type "Problème de paramètre", avec le pointeur sur le début du champ "solution de puzzle #J" dans la charge utile SOLUTION du message HIP. Si IPv4 est utilisé, la mise en œuvre PEUT répondre avec un paquet ICMP de type "Problème de paramètre", en copiant assez d'octets du message I2 pour que le paramètre SOLUTION tienne dans le message ICMP, avec le pointeur sur le début du champ "solution de puzzle #J", comme dans le cas IPv6. Noter cependant que le message ICMPv4 résultant excède la taille normale de message ICMPv4, comme défini dans la [RFC0792].

 	5.4.4	Association HIP non existante
Si une mise en œuvre HIP reçoit un paquet CLOSE ou UPDATE, ou tout autre paquet dont le traitement exige une association existante, qui a une HIT de receveur ou d'envoyeur qui ne correspond pas à une association HIP existante, la mise en œuvre PEUT répondre, en débit limité, avec un paquet ICMP de type "Problème de paramètre". Le pointeur du paquet ICMP "Problème de paramètre" est réglé à pointer sur le début de la première HIT qui ne correspond pas.

Un hôte NE DOIT PAS répondre avec un tel message ICMP si il reçoit un des messages suivants : paquet I1, R2, I2, R2, et NOTIFY. Si elle introduit de nouveaux types de paquet, une spécification DEVRAIT définir les règles appropriées pour envoyer ou non cette sorte de réponse ICMP.

 	6.	Traitement de paquet

Chaque hôte est supposé avoir une seule mise en œuvre de HIP qui gère les associations HIP de l'hôte et traite les demandes de nouvelles associations. Chaque association HIP est gouvernée par un automate à états conceptuel, avec les états définis au paragraphe  4.4. La mise en œuvre de HIP peut entretenir simultanément des associations HIP avec plusieurs hôtes. De plus, la mise en œuvre HIP peut avoir plus d'une association HIP active avec un autre hôte ; dans ce cas, les associations HIP sont distinguées par leurs HIT respectives. Il n'est pas possible d'avoir plus d'une association HIP entre une certaine paire de HIT. Par conséquent, la seule façon que deux hôtes aient plus d'une association en parallèle est d'utiliser des HIT différentes, au moins à une extrémité.

Le traitement des paquets dépend de l'état de la ou des associations HIP par rapport à l'origine authentifiée ou apparente du paquet. Une mise en œuvre de HIP détermine si elle a une association active avec le générateur du paquet sur la base des HIT. Dans le cas de données d'utilisateur portées dans un format de transport spécifique, le document de format de transport spécifie comment les paquets entrants sont confrontés aux associations actives.

 	6.1	Traitement des données d'application sortantes
Dans un hôte HIP, une application peut envoyer des données de niveau application en utilisant un identifiant spécifié via l'API sous-jacente. L'API peut être  rétro compatible (voir la [RFC5338]) utilisant des identifiants qui ressemblent à des adresses IP, ou une API complètement nouvelle, fournissant des services améliorés aux identités d'hôte. Selon la mise en œuvre de HIP, l'identifiant fourni à l'application peut être différent ; par exemple, il peut être une HIT ou une adresse IP.

Le format et méthode exacts pour transférer les données d'utilisateur de l'hôte HIP de source à l'hôte HIP de destination sont définis dans le document de format de transport correspondant. Les données réelles sont transférées dans le réseau en utilisant les adresses IP appropriées de source et destination.

Dans le présent document, les règles conceptuelles de traitement ne sont définies que pour le cas de base où les deux hôtes ont seulement une adresse IP utilisable ; le multi rattachements multi-adresses est spécifié séparément.

L'algorithme conceptuel suivant décrit les étapes nécessaires pour traiter les datagrammes sortants destinés à une HIT.

1. Si le datagramme a une adresse de source spécifiée, il DOIT être une HIT. Si il ne l'est pas, la mise en œuvre PEUT remplacer l'adresse de source par une HIT. Autrement, elle DOIT abandonner le paquet.

2. Si le datagramme a une adresse de source non spécifiée, la mise en œuvre DOIT choisir une HIT de source convenable pour le datagramme. Le choix de la HIT de source est soumis à la politique locale.

3. Si il n'y a pas d'association HIP active avec la paire de HIT <source, destination> donnée, il DOIT en être créé une en faisant un échange de base. Tout en attendant que l'échange de base s'achève, la mise en œuvre DEVRAIT mettre en file d'attente au moins un paquet de données d'utilisateur par association HIP à former, et elle PEUT en mettre plus d'un en file d'attente.

4.  Une fois qu'il y a une association HIP active pour la paire <source, destination> HIT donnée, le datagramme sortant est passé au traitement du transport. Les formats de transport possibles sont définis dans des documents distincts, mais le format de transport ESP pour HIP est obligatoire pour toutes les mises en œuvre de HIP.

5.  Avant d'envoyer le paquet, les HIT dans le datagramme sont remplacées par des adresses IP convenables. Pour IPv6, les règles définies dans [la RFC6724] DEVRAIENT être suivies. Noter que cette étape de conversion de HIT en adresse IP PEUT aussi être effectuée à un autre point de la pile, par exemple, avant d'envelopper le paquet dans le format de sortie.

 	6.2	Traitement des données d'application entrantes
L'algorithme conceptuel suivant décrit le traitement du datagramme entrant quand les HIT sont utilisées chez l'hôte receveur comme identifiants de niveau application. Les étapes plus détaillées du traitement des paquets sont définies dans les documents de format de transport correspondants.

1.  Le datagramme entrant est transposé en une association HIP existante, normalement en utilisant des informations provenant du paquet. Par exemple, une telle transposition peut se fonder sur l'indice de paramètre de sécurité (SPI, Security Parameter Index) de ESP.

2.  Le format de transport spécifique est non enveloppé, d'une façon qui dépend du format de transport, donnant un paquet qui ressemble à un paquet IP standard (non chiffré). Si possible, cette étape DEVRAIT aussi vérifier que le paquet a bien été envoyé par l'hôte HIP distant, comme identifié par l'association HIP. Selon le mode de transport utilisé, la méthode de vérification peut varier. Alors que la HI (ainsi que la HIT) est utilisée comme identifiant de couche supérieure, la méthode de vérification doit vérifier que le paquet de données a été envoyé par l'identité correcte de nœud et que l'identité réelle se transpose en cette HIT particulière. Quand on utilisé le format de transport ESP [RFC7402], la vérification est faite en utilisant la valeur de SPI dans le paquet de données pour trouver la SA correspondant à la HIT et clé associées, et en déchiffrant le paquet avec cette clé associée.

3.  Les adresses IP dans le datagramme sont remplacées par les HIT associées à l'association HIP. Noter que cette étape de conversion d'adresse IP en HIT PEUT aussi être effectuée à un autre point de la pile.

4.  Le datagramme est livré à la couche supérieure (par exemple, UDP ou TCP). Quand on démultiplexe le datagramme, la prise de la couche immédiatement supérieure est choisie sur la base des HIT.

 	6.3	Résolution du puzzle
Ce paragraphe décrit les détails de la résolution du puzzle.

Dans le paquet R1, les valeurs #I et #K sont envoyées dans l'ordre des octets du réseau. De même, dans le paquet I2, les valeurs #I et #J sont envoyées dans l'ordre des octets du réseau. Le hachage est créé en enchaînant, dans l'ordre des octets du réseau, les données suivantes, dans l'ordre suivant et en utilisant l'algorithme RASH :

-	la valeur aléatoire du bit n #I (où n est RHASH_len), dans l'ordre des octets du réseau, comme elle apparaît dans les paquets R1 et I2.

-	la HIT de 128 bits de l'initiateur, dans l'ordre des octets du réseau, comme elle apparaît dans la charge utile HIP des paquets R1 et I2.

-	la HIT de 128 bits du répondant, dans l'ordre des octets du réseau, comme elle apparaît dans la charge utile HIP dans les paquets R1 et I2.

-	la valeur aléatoire de n bit #J (où n est RHASH_len), dans l'ordre des octets du réseau, comme elle apparaît dans le paquet  I2.

Dans une réponse valide de puzzle, les #K bits de moindre poids du résumé RHASH résultant DOIVENT être à zéro.

Notes :
i)	La longueur des données à hacher est variable, selon la longueur du résultat de la fonction de hachage RHASH du répondant.
ii)	Toutes les données dans l'entrée de hachage DOIVENT être dans l'ordre des octets du réseau.
iii)	L'ordre des HIT de l'initiateur et du répondant est différent dans les paquets R1 et I2 ; voir au paragraphe 5.1. Il faut veiller à copier les valeurs dans le bon ordre dans l'entrée du hachage.
iv)	Pour un puzzle #I, il peut exister plusieurs solutions valides du puzzle #J.

La procédure suivante décrit les étapes du traitement, en supposant que le répondant choisisse de pré calculer les paquets R1 :

Pré calcul par le répondant :
      établir la difficulté du puzzle #K,
      créer un R1 signé et le mettre en antémémoire.

Le répondant :
      choisit un R1 convenable dans l'antémémoire,
      génère un nombre aléatoire #I,
      envoie #I et #K dans un R1,
      sauvegarde #I et #K pendant une durée delta.

L'initiateur :
      génère des tentatives répétées de résolution du puzzle jusqu'à ce qu'un #J correspondant soit trouvé :
      Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0
      envoie #I et #J dans un I2.

Le répondant :
      vérifie que le #I reçu est un de ceux sauvegardés,
      trouve le bon #K sur la base de #I,
      calcule V : = Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K )
      rejet si V != 0
      accepte si V == 0

 	6.4	Calcul et vérification de HIP_MAC et SIGNATURE 
Les paragraphes qui suivent définissent les actions pour traiter les paramètres HIP_MAC, HIP_MAC_2, HIP_SIGNATURE, et HIP_SIGNATURE_2. Le paramètre HIP_MAC_2 est contenu dans le paquet R2. Le paramètre HIP_SIGNATURE_2 est contenu dans le paquet R1. Les paramètres HIP_SIGNATURE et HIP_MAC sont contenus dans d'autres paquets HIP.

 	6.4.1	Calcul de HMAC
Le HMAC utilise RHASH comme fonction de hachage sous-jacente. Le type de RHASH dépend de la suite HIT du répondant. Donc, HMAC-SHA-256 [RFC4868] est utilisé pour la suite HIT RSA/DSA/SHA-256, HMAC-SHA-1 [RFC2404] est utilisé pour la suite HIT ECDSA_LOW/SHA-1, et HMAC-SHA-384 [RFC4868] est utilisé pour la suite HIT ECDSA/SHA-384.

Le processus suivant s'applique aux deux paramètres HIP_MAC et HIP_MAC_2. Lors du traitement de HIP_MAC_2, la différence est que le calcul de HIP_MAC inclut un pseudo champ HOST_ID contenant les informations du répondant comme elles ont été envoyées antérieurement dans le paquet R1.

L'initiateur et le répondant devrait tous deux faire attention quand ils vérifient ou calculent le HIP_MAC_2. Précisément, l'initiateur doit préserver le HOST_ID exactement comme il a été reçu dans le paquet R1 jusqu'à ce qu'il reçoive le HIP_MAC_2 dans le paquet R2.

La portée du calcul du HIP_MAC est la suivante : HMAC : { en-tête HIP | [ paramètres ] }

où "paramètres" inclut tous les paramètres HIP du paquet avec les valeurs de type allant de 1 à (valeur de type de HIP_MAC - 1) et en excluant les paramètres avec des valeurs de type supérieures ou égales à la valeur de type de HIP_MAC.

Durant le calcul de HIP_MAC, on applique ce qui suit :
o	dans l'en-tête HIP, le champ Somme de contrôle est réglé à zéro,
o	dans l'en-tête HIP, la valeur du champ Longueur d'en-tête est calculée depuis le début du le paramètre HIP_MAC.

L'ordre des paramètres est décrit au paragraphe 5.2.1.

La portée du calcul de HIP_MAC_2 est la suivante : HIP_MAC_2: { en-tête HIP | [ paramètres ] | HOST_ID }

où "paramètres" inclut tous les paramètres HIP du paquet avec les valeurs de type allant de 1 à (valeur de type de HIP_MAC_2 - 1) et en excluant les paramètres avec des valeurs de type supérieures ou égales à la valeur de type de HIP_MAC_2.

Durant le calcul de HIP_MAC_2, on applique ce qui suit :
o	dans l'en-tête HIP, le champ Somme de contrôle est réglé à zéro,
o	dans l'en-tête HIP, la valeur du champ Longueur d'en-tête est calculée depuis le début du paramètre HIP_MAC_2 et augmentée de la longueur du paramètre HOST_ID enchaîné (incluant les champs Type et Longueur),
o	le paramètre HOST_ID est exactement sous la forme reçue dans le paquet R1 provenant du répondant.

L'ordre des paramètres est décrit au paragraphe 5.2.1, excepté que le paramètre HOST_ID est ajouté à la fin dans ce calcul.

Le paramètre HIP_MAC est défini au paragraphe 5.2.12 et le paramètre HIP_MAC_2 au paragraphe 5.2.13. Le processus de calcul et de vérification du HMAC (le processus s'applique à HIP_MAC et HIP_MAC_2, sauf où HIP_MAC_2 est mentionné séparément) est le suivant :

Envoyeur du paquet :
1.	Crée le paquet HIP, sans le HIP_MAC, HIP_SIGNATURE, HIP_SIGNATURE_2, ou autre paramètre avec une valeur de type supérieure à celle du paramètre HIP_MAC.
2.	En cas de calcul de HIP_MAC_2, ajouter un paramètre HOST_ID (répondant) à la fin du paquet.
3.  Calculer le champ Longueur d'en-tête dans l'en-tête HIP, incluant le paramètre HOST_ID ajouté dans le cas de HIP_MAC_2.
4.	Calculer le HMAC en utilisant la clé d'intégrité HIP-gl ou HIP-lg restituée du KEYMAT comme défini au paragraphe  6.5.
5.	En cas de HIP_MAC_2, retirer le paramètre HOST_ID du paquet.
6.	Ajouter le paramètre HIP_MAC au paquet et tout paramètre qui a une valeur de type supérieure au HIP_MAC (HIP_MAC_2's) qui peut suivre, incluant les possibles paramètres HIP_SIGNATURE ou HIP_SIGNATURE_2.
7.	Recalculer le champ Longueur dans l'en-tête HIP.

Receveur du paquet :
1.	Vérifier le champ Longueur d'en-tête HIP.
2.	Retirer le paramètre HIP_MAC ou HIP_MAC_2, ainsi que tous autres paramètres qui le suivent avec une valeur de type supérieure incluant de possibles champs HIP_SIGNATURE ou HIP_SIGNATURE_2, en sauvegardant le contenu pour le cas où il serait nécessaire ultérieurement.
3.	Dans le cas de HIP_MAC_2, construire et ajouter un paramètre HOST_ID (avec informations du répondant) au paquet.  Le paramètre HOST_ID devrait être identique à celui précédemment reçu du répondant.
4.	Recalculer la longueur du paquet HIP dans l'en-tête HIP et remettre tout à zéro le champ Somme de contrôle. Dans le cas de HIP_MAC_2, la longueur est calculée avec l'ajout du paramètre HOST_ID.
5.	Calculer le HMAC en utilisant la clé d'intégrité HIP-gl ou HIP-lg comme défini au paragraphe 6.5 et le vérifier en le confrontant au HMAC reçu.
6.	Régler les champs Somme de contrôle et Longueur d'en-tête dans l'en-tête HIP aux valeurs d'origine. Noter que les champs Somme de contrôle et Longueur contiennent des valeurs incorrectes après cette étape.
7.	Dans le cas de HIP_MAC_2, retirer le paramètre HOST_ID du paquet avant la suite du traitement.

 	6.4.2	Calcul de signature
Le processus suivant s'applique aux deux paramètres HIP_SIGNATURE et HIP_SIGNATURE_2. Dans le traitement du paramètre HIP_SIGNATURE_2, la seule différence est qu'au lieu du paramètre HIP_SIGNATURE, le paramètre HIP_SIGNATURE_2 est utilisé, et la HIT de l'initiateur et les champs PUZZLE Opaque et #I aléatoire sont remis tout à zéro avant de calculer la signature. Le paramètre HIP_SIGNATURE est défini au paragraphe 5.2.14 et le paramètre HIP_SIGNATURE_2 au paragraphe 5.2.15.

La portée du calcul de HIP_SIGNATURE et de HIP_SIGNATURE_2 est la suivante :

HIP_SIGNATURE : { en-tête HIP | [ paramètres ] }

où "paramètres inclut tous les paramètres HIP du paquet avec des valeurs de type de 1 à (valeur de type de HIP_SIGNATURE - 1).

Durant le calcul de signature, on applique ce qui suit :
o	dans l'en-tête HIP, le champ Somme de contrôle est réglé à zéro,
o	dans l'en-tête HIP, la valeur du champ Longueur d'en-tête est calculée depuis le début du paramètre HIP_SIGNATURE.

L'ordre des paramètre est décrit au paragraphe 5.2.1.

HIP_SIGNATURE_2 : { en-tête HIP | [ paramètres ] }

où "paramètres" inclut tous les paramètres HIP du paquet avec les valeurs de type allant de 1 à (valeur de type de HIP_SIGNATURE_2 - 1).

Durant le calcul de signature, on applique ce qui suit :
o	dans l'en-tête HIP, les deux champs Somme de contrôle et HIT du receveur sont réglés à zéro,
o	dans l'en-tête HIP, la valeur du champ Longueur d'en-tête est calculé depuis le début du paramètre HIP_SIGNATURE_2,
o	les champs Opaque et #I aléatoire du paramètre PUZZLE sont réglés à zéro.

L'ordre des paramètres est décrit au paragraphe 5.2.1.

Le processus de calcul et de vérification de signature (le processus s'applique aux deux HIP_SIGNATURE et HIP_SIGNATURE_2, sauf dans le cas où HIP_SIGNATURE_2 est mentionné séparément) est le suivant :

Envoyeur du paquet :
1.	Crée le paquet HIP sans le paramètre HIP_SIGNATURE ni aucun autre paramètre qui suit le paramètre HIP_SIGNATURE.
2.	Calcule le champ Longueur et met à zéro le champ Somme de contrôle dans l'en-tête HIP. Dans le cas de HIP_SIGNATURE_2, règle le champ HIT de l'initiateur dans l'en-tête HIP ainsi que les champs Opaque et #1 aléatoire du paramètre PUZZLE à zéro.
3.	Calcule la signature en utilisant la clé privée correspondant à l'identifiant d'hôte (clé publique).
4.	Ajoute le paramètre HIP_SIGNATURE au paquet.
5.	Ajoute tous les paramètres qui suivent le paramètre HIP_SIGNATURE.
6.	Recalcule le champ Longueur dans l'en-tête HIP, et calcule le champ Somme de contrôle.

Receveur du paquet :
1.	Vérifie les champs Longueur d'en-tête HIP et Somme de contrôle.
2.	Sauvegarde le contenu du paramètre HIP_SIGNATURE et tous autres paramètres qui suivent le paramètre HIP_SIGNATURE, et les retire du paquet.
3.	Recalcule la longueur du paquet HIP dans l'en-tête HIP et met le champ Somme de contrôle tout à zéro). Dans le cas de HIP_SIGNATURE_2, règle le champ HIT de l'initiateur dans l'en-tête HIP ainsi que les champs Opaque et #1 aléatoire du paramètre PUZZLE à zéro.
4.	Calcule la signature et la vérifie par rapport à la signature reçue en utilisant l'identité d'hôte de l'envoyeur du paquet (clé publique).
5.	Restaure le paquet d'origine en ajoutant les paramètres retirés (dans l'étape 2) et remet les valeurs qui ont été mises à zéro (dans l'étape 3).

La vérification peut utiliser la HI reçue d'un paquet HIP ; la HI restituée d'une interrogation du DNS, si le FQDN a été reçu dans le paramètre HOST_ID ; ou une HI reçue par d'autres moyens.

 	6.5	Génération de KEYMAT HIP
Le matériel de chiffrement HIP est déduit de la clé de session Diffie-Hellman, Kij, produite durant l'échange de base HIP (voir au paragraphe 4.1.3). L'initiateur a Kij durant la création du paquet I2, et le répondant a Kij une fois qu'il a reçu le paquet I2. C'est pourquoi I2 peut déjà contenir des informations chiffrées.

Le KEYMAT est déduit en introduisant Kij dans la fonction de déduction de clé définie par l'identifiant de groupe DH. Actuellement, la seule fonction de déduction de clé définie dans le présent document est la fonction de déduction de clé fondée sur le hachage (HKDF, Hash-based Key Derivation Function) [RFC5869] utilisant la fonction de hachage RHASH.  D'autres documents pourront définir de nouveaux identifiants de groupe DH et les fonctions correspondantes de distribution de clés.

Dans ce qui suit, on donne les détails de la déduction du matériel de chiffrement utilisant HKDF où

info = tri(HIT-I | HIT-R)
sel =  #I | #J

tri(HIT-I | HIT-R) est défini comme l'enchaînement dans l'ordre des octets du réseau des deux HIT, avec la plus petite HIT précédant la plus grande HIT, résultant de la comparaison numérique des deux HIT interprétées comme des entiers positifs (non signés) de 128 bits dans l'ordre des octets du réseau. Les valeurs #I et #J viennent du puzzle et de sa solution qui ont été échangées dans les messages R1 et I2 quand cette association HIP a été établie. Les deux hôtes doivent mémoriser les valeurs #I et #J pour l'association HIP pour utilisation ultérieure.

Les clés initiales sont tirées à la suite dans l'ordre déterminé par la comparaison numérique des deux HIT, avec la méthode de comparaison décrite au paragraphe précédent. HOST_g note l'hôte avec la plus grande valeur d'HIT, et HOST_l l'hôte avec la plus petite.

L'ordre de tirage des quatre clés initiales est le suivant :
- clé de chiffrement HIP-gl pour le paramètre ENCRYPTED de HOST_g
- clé d'intégrité HIP-gl (HMAC) pour les paquets HIP sortants de HOST_g
- clé de chiffrement HIP-lg pour le paramètre ENCRYPTED de HOST_l
- clé d'intégrité HIP-lg (HMAC) pour les paquets HIP sortants de HOST_l.

Le nombre de bits tirés pour un algorithme donné est la taille "naturelle" des clés. Pour les algorithmes obligatoires, les taille suivantes s'appliquent :
AES : 128 ou 256 bits
SHA-1 : 160 bits
SHA-256 : 256 bits
SHA-384 : 384 bits
NULL : 0 bit

Si d'autres tailles de clés sont utilisées, elles DOIVENT être traitées comme des algorithmes de chiffrement différents et définies séparément.

 	6.6	Initialisation d'un échange HIP de base
Une mise en œuvre peut générer un échange de base HIP avec ua autre hôte sur la base d'une décision de politique locale, généralement déclenchée par un datagramme d'application, d'une façon assez semblable à celle dont un échange de clés IPsec IKE peut créer dynamiquement une association de sécurité. Autrement, un système peut initier un échange HIP si il a réamorcé ou est arrivé en fin de temporisation, ou a autrement perdu son état HIP, comme décrit au paragraphe 4.5.4.

La mise en œuvre prépare un paquet I1 et l''envoie à l'adresse IP qui correspond à l'hôte homologue. L'adresse IP de l'hôte homologue peut être obtenue via des mécanismes conventionnels, comme une recherche dans le DNS. Le contenu du paquet I1 est spécifié au paragraphe 5.3.1. Le choix de quelle identité d'hôte de source ou de destination utiliser, si un initiateur ou répondant en a plus d'une parmi lesquelles choisir, est normalement une décision de politique.

Les étapes suivantes définissent les règles de traitement conceptuel pour initier un échange de base HIP :

1.	L'initiateur reçoit une ou plusieurs HIT du répondant et une ou plusieurs adresses d'une recherche dans le DNS sur le FQDN du répondant, dans un autre répertoire, ou d'une base de données locale. Si l'initiateur ne connaît pas la HIT du répondant, il peut tenter le mode opportuniste en utilisant NULL (que des zéros) comme HIT du répondant (voir aussi "Mode opportuniste HIP" (paragraphe 4.1.8)). Si l'initiateur peut choisir parmi plusieurs HIT du répondant, il choisit une HIT pour laquelle l'initiateur supporte la suite HIT.

2.	L'initiateur envoie un paquet I1 à une des adresses du répondant. Le choix de l'adresse à utiliser est une décision de politique locale.

3.	L'initiateur inclut le DH_GROUP_LIST dans le paquet I1. Le choix et l'ordre des identifiants de groupe DH dans le DH_GROUP_LIST DOIT être mémorisé par l'initiateur, parce que cette liste est nécessaire pour le traitement ultérieur de R1. Dans la plupart des cas, les préférences concernant les groupes DH vont être statiques, de sorte qu'aucune mémorisation par association n'est nécessaire.

4.	À l'envoi d'un paquet I1, l'envoyeur passe à l'état I1-SENT et lance un temporisateur pour lequel la valeur de temporisation  DEVRAIT être plus grande que le pire des cas de RTT prévu. L'envoyeur DEVRAIT aussi incrémenter le compteur d'essais associé au I1.

5.	En fin de temporisation, l'envoyeur DEVRAIT retransmettre le paquet I1 et relancer le temporisateur, jusqu'à un maximum de I1_RETRIES_MAX essais.

 	6.6.1	Envoi de plusieurs paquets I1 en parallèle
Pour minimiser la latence d'établissement de l'association, une mise en œuvre PEUT envoyer le même paquet I1 à plus d'une des adresses du répondant. Cependant, il NE DOIT PAS envoyer à plus de trois (3) adresses du répondant en parallèle. De plus, à la fin de temporisation, la mise en œuvre DOIT s'interdire d'envoyer le même paquet I1 à plusieurs adresses. C'est-à-dire, si il réessaye d'initialiser la connexion après une fin de temporisation, il NE DOIT PAS envoyer le paquet I1 à plus d'une adresse de destination. Ces limitations sont fixées pour éviter l'encombrement du réseau, et de potentielles attaques de DoS qui pourraient se produire, par exemple, parce que quelqu'un qui prétendrait avoir des centaines ou des milliers d'adresses pourrait générer un énorme nombre de paquets I1 à partir de l'initiateur.

Comme il n'est pas garanti au répondant qu'il va distinguer les paquets I1 dupliqués qu'il reçoit à plusieurs de ses adresses (parce qu'il évite de mémoriser les états quand il répond à un paquet R1) l'initiateur peut recevoir plusieurs paquets R1 dupliqués.

L'initiateur DEVRAIT alors choisir l'adresse de destination initiale préférée en utilisant l'adresse de source de la R1 reçue choisie, et utiliser l'adresse préférée comme adresse de source pour le paquet I2. Les règles de traitement pour les R1 reçues sont discutées au paragraphe 6.8.

 	6.6.2	Traitement de messages ICMP "Protocole injoignable" entrants
Un hôte peut recevoir un message ICMP "Protocole de destination injoignable" en réponse à l'envoi d'un paquet I1 HIP. Un tel paquet peut être l'indication que l'homologue ne prend pas en charge HIP, ou ce peut être une tentative de lancement d'une attaque en faisant croire à l'initiateur que le répondant ne prend pas en charge HIP.

Quand un système reçoit un message ICMP "Protocole de destination injoignable" alors qu'il attend un paquet R1, il NE DOIT PAS cesser d'attendre. Il PEUT continue comme si il n'avait pas reçu le message ICMP, et envoyer quelques paquets I1 de plus. Autrement, il PEUT prendre le message ICMP comme l'indication que l'homologue ne prend probablement pas HIP en charge, et retourner à l'état UNASSOCIATED plus tôt que prévu. Cependant, au minimum, il DOIT continuer d'attendre un paquet R1 pendant une durée raisonnable avant de retourner à UNASSOCIATED.

 	6.7	Traitement de paquets I1 entrants
Une mise en œuvre DEVRAIT répondre à un I1 avec un paquet R1, sauf si la mise en œuvre est incapable de, ou ne veut pas, établir une association HIP. Si la mise en œuvre est incapable d'établir une association HIP, l'hôte DEVRAIT envoyer un message ICMP "Protocole de destination injoignable, interdit administrativement" à l'adresse de source du paquet I1. Si la mise en œuvre ne veut pas établir une association HIP, l'hôte PEUT ignorer le paquet I1. Ce dernier cas peut se produire durant une attaque de déni de service comme une inondation de paquets I1.

La mise en œuvre DEVRAIT être capable de traiter une tempête de réception de paquets I1, les éliminant avec le contenu commun quand ils arrivent dans un petit intervalle de temps.

Un paquet I1 contrefait peut résulter en une attaque de R1 sur un système. Un envoyeur de paquet R1 DOIT avoir un mécanisme pour limiter le débit de paquets R1 envoyés à une adresse.

Il est RECOMMANDÉ que l'automate à états HIP ne change pas d’état à l'envoi d'un paquet R1.

Les étapes suivantes définissent les règles de traitement conceptuelles pour répondre à un paquet I1 :

1.	Le répondant DOIT vérifier que la HIT du répondant dans le paquet I1 reçu est soit une de ses propres HIT, soit NULL. Autrement, il doit éliminer le paquet.

2.	Si le répondant est dans l'état ESTABLISHED, il PEUT y répondre avec un paquet R1, se préparer à éliminer une association de sécurité HIP existante avec l'homologue, et rester à l'état ESTABLISHED.

3.	Si le répondant est dans l'état I1-SENT, il DOIT faire une comparaison entre la HIT de l'envoyeur et la sienne propre (c'est-à-dire, celle du receveur). Si la HIT de l'envoyeur est supérieure à sa propre HIT, il devrait éliminer le paquet I1 et rester à I1-SENT. Si la HIT de l'envoyeur est plus petite que sa propre HIT, il DEVRAIT envoyer le paquet R1 et rester à I1-SENT. La comparaison de HIT est effectuée comme défini au paragraphe 6.5.

4.	Si la mise en œuvre choisit de répondre au paquet I1 avec un paquet R1, elle crée un nouveau R1 ou choisit un R1 pré calculé conformément au format décrit au paragraphe 5.3.2. Elle crée ou choisit un R1 qui contient sa valeur publique DH préférée qui est aussi contenue dans le DH_GROUP_LIST dans le paquet I1. Si aucun identifiant de groupe DH convenable n'est contenu dans le DH_GROUP_LIST dans le paquet I1, elle envoie un R1 avec toute clé publique DH convenable.

5.	Si la HIT reçue du répondant dans le I1 est NULL, le répondant choisit une HIT avec la même suite HIT que l'HIT de l'initiateur. Si cette suite HIT n'est pas supportée par le répondant, il DEVRAIT choisir une suite HIT EXIGÉE d'après le paragraphe 5.2.10, qui est actuellement RSA/DSA/SHA-256. À part cela, le choix de la HIT est une affaire de politique locale.

6.	Le répondant exprime ses formats de transport HIP pris en charge dans le paramètre TRANSPORT_FORMAT_LIST comme décrit au paragraphe 5.2.11. Le répondant DOIT fournit au moins un type de format de transport de charge utile.

7.	Le répondant envoie le paquet R1 à l'adresse IP de source du paquet I1.

 	6.7.1	Gestion de R1
Toutes les mises en œuvre conformes DOIVENT être capables de produire des paquets R1; même si un appareil est configuré par politique à seulement initier des associations, il doit être capable de traiter les I1 dans les cas de récupération de perte d'état ou d'épuisement de clés. Un paquet R1 PEUT être pré calculé. Un paquet R1 PEUT être réutilisé pour un court instant, noté ici "Delta T", qui dépend de la mise en œuvre, et DEVRAIT être déconseillé et n'être plus utilisé une fois qu'un paquet I2 de réponse valide a été reçu d'un initiateur. Durant une tempête de messages I1, un paquet R1 PEUT être réutilisé au delà du Delta T normal. Les informations de R1 NE DOIVENT PAS être éliminées tant qu'un délai "Delta S" (qui dépend, là encore, de la mise en œuvre) après que le paquet R1 n'est plus offert. Delta S est la durée maximum supposée pour que le dernier paquet I2 en réponse au paquet R1 revienne au répondant.

Les mises en œuvre qui acceptent plusieurs groupes DH PEUVENT pré calculer des paquets R1 pour chaque groupe pris en charge afin que les paquets I1 entrants avec des identifiants de groupe DH différents dans le DH_GROUP_LIST puissent être servis rapidement.

Une mise en œuvre PEUT conserver l'état des paquets I1 reçus et confronter les paquets I2 reçus à l'état, comme expliqué au paragraphe 4.1.1.

 	6.7.2	Traitement de messages mal formés
Si une mise en œuvre reçoit un paquet I1 mal formé, elle NE DEVRAIT PAS répondre avec un message NOTIFY, car une telle pratique pourrait ouvrir la voie à une potentielle attaque de déni de service. Elle PEUT plutôt répondre avec un paquet ICMP, comme défini au paragraphe 5.4.

 	6.8	Traitement de paquets R1 entrants
Un système qui reçoit un paquet R1 DOIT d'abord vérifier si il a envoyé un paquet I1 au générateur du paquet R1 (c'est-à-dire, si il est dans l'état I1-SENT). Si il en est ainsi, il DEVRAIT traiter le R1 comme décrit ci-dessus, envoyer un paquet I2, et transiter à l'état I2-SENT, en établissant un temporisateur pour protéger le paquet I2. Si le système est dans l'état I2-SENT, il PEUT répondre au paquet R1 si le paquet R1 a un compteur de génération de R1 supérieur ; si il en est ainsi, il devrait abandonner son état à cause du traitement du paquet R1 précédent et commencer à partir de l'état I1-SENT. Si le système est dans tout autre état par rapport à cet hôte, le système DEVRAIT éliminer en silence le paquet R1.

Quand il envoie plusieurs paquets I1, un initiateur DEVRAIT attendre un bref instant après la réception du premier R1 pour permettre l'arrivée de plusieurs possibles paquets R1, et il DEVRAIT répondre à un paquet R1 parmi l'ensemble avec le plus grand compteur de génération de R1.

Les étapes suivantes définissent les règles de traitement conceptuel de réponse à un paquet R1 :

1.	Un système qui reçoit un R1 DOIT d'abord vérifier si il a envoyé un paquet I1 au générateur du paquet R1 (c'est-à-dire, si il a une association HIP dans l'état I1-SENT et si elle est associée aux HIT dans le R1). Sauf si le paquet I1 a été envoyé en mode opportuniste (voir au paragraphe 4.1.8) les adresses IP dans le paquet R1 reçu DEVRAIENT être ignorées par le traitement du R1 et, quand il cherche la bonne association HIP, le paquet R1 reçu DEVRAIT être confronté aux associations en utilisant seulement les HIT. Si une correspondance existe, le système devrait traiter le paquet R1 comme décrit ci-dessus.

2.	Autrement, si le système est dans tout état autre que I1-SENT ou I2-SENT par rapport aux HIT incluses dans le paquet R1, il DEVRAIT éliminer en silence le paquet R1 et rester dans l'état en cours.

3.	Si l'état de l'association HIP est I1-SENT ou I2-SENT, la HIT reçue de l'initiateur DOIT correspondre à la HIT utilisée dans le I1 original. Aussi, la HIT du répondant DOIT correspondre à celle utilisée dans le I1, sauf si le paquet I1 contenait la HIT NULL.

4.	Le système DEVRAIT valider la signature du R1 avant d'appliquer d'autre traitement de paquet, conformément au paragraphe 5.2.15.

5.	Si l'état de l'association HIP est I1-SENT, et si plusieurs paquets R1 valides sont présents, le système DOIT choisir parmi les paquets R1 celui qui a le plus grand compteur de génération de R1.

6.	Le système DOIT vérifier que la suite HIT de l'initiateur est contenue dans le paramètre HIT_SUITE_LIST dans le paquet R1 (c'est-à-dire, que la suite HIT de l'initiateur est prise en charge par le répondant). Si la suite HIT est prise en charge par le répondant, le système procède normalement. Autrement, le système PEUT rester dans l'état I1-SENT et redémarrer le BEX en envoyant un nouveau paquet I1 avec une HIT d'initiateur prise en charge par le répondant et donc contenue dans la HIT_SUITE_LIST du paquet R1. Le système PEUT interrompre le BEX si aucune HIT de source convenable n'est disponible. Le système DEVRAIT attendre pendant un temps acceptable pour permettre l'arrivée d'autres paquets R1 avec de plus forts compteurs de génération R1 ou différentes HIT et suites HIT avant de redémarrer ou d'interrompre le BEX.

7.	Le système DOIT vérifier que l'identifiant de groupe DH dans le paramètre DIFFIE_HELLMAN du R1 correspond au premier identifiant de groupe DH dans la DH_GROUP_LIST du répondant dans le paquet R1, et aussi que cet identifiant de groupe correspond à une valeur incluse dans la DH_GROUP_LIST de l'initiateur dans le paquet I1. Si l'identifiant de groupe DH du paramètre DIFFIE_HELLMAN n'exprime pas le meilleur choix du répondant, l'initiateur peut conclure que le DH_GROUP_LIST dans le paquet I1 a été modifié de façon hostile. Dans ce cas, l'initiateur PEUT envoyer un nouveau paquet I1 ; cependant, il NE DEVRAIT PAS changer sa préférence dans le DH_GROUP_LIST du nouveau paquet I1. Autrement, l'initiateur PEUT interrompre l'échange de base HIP.

8.	Si l'état de l'association HIP est I2-SENT, le système PEUT ré-entrer à l'état I1-SENT et traiter le paquet R1 reçu si il a un compteur de génération de R1 supérieur à celui du paquet R1 auquel il a répondu précédemment.

9.	Le paquet R1 peut avoir le bit A établi -- dans ce cas, le système PEUT choisir de le refuser en éliminant le paquet R1 et en retournant à l'état UNASSOCIATED. Le système ne DEVRAIT envisager l'abandon du paquet R1 que si il utilise une HIT NULL dans le paquet I1. Si le bit A est établi, la HIT du répondant est anonyme et NE DEVRAIT PAS être mémorisée de façon permanente.

10.	Le système DEVRAIT tenter de valider la HIT par rapport à l'identité d'hôte reçue en utilisant l'identité d'hôte reçue pour construire une HIT et vérifier qu'elle correspond à celle de l'envoyeur.

11.	Le système DOIT mémoriser le compteur de génération de R1 reçu pour de futures références.

12.	Le système tente de résoudre le puzzle dans le paquet R1. Le système DOIT terminer la recherche après l'expiration de la durée de vie restante du puzzle. Si le puzzle n’est pas résolu, la mise en œuvre PEUT soit envoyer à nouveau le paquet I1, dans les limites de nombre d'essais, soit abandonner l'échange de base HIP.

13.	Le système calcule le matériel de chiffrement Diffie-Hellman standard selon la valeur publique et l'identifiant de groupe fournis dans le paramètre DIFFIE_HELLMAN. Le matériel de chiffrement Diffie-Hellman Kij est utilisé pour l'extraction de clé comme spécifié au paragraphe 6.5.

14.	Le système choisit l'identifiant de HIP_CIPHER parmi les choix présentés dans le paquet R1 et utilise ultérieurement les valeurs choisies quand il génère et utilise les clés de chiffrement, et quand il envoie le paquet I2. Si les solutions de remplacement proposées ne sont pas acceptables au système, il peut soit envoyer à nouveau un I1, dans les limites de nombre d'essais, soit abandonner l'échange de base HIP.

15.	Le système choisit un format de transport convenable dans la TRANSPORT_FORMAT_LIST et inclut le paramètre format de transport approprié dans le paquet I2 suivant.

16.	Le système initialise les variables restantes dans l'état associé, incluant les compteurs d’identifiant de mise à jour.

17.	Le système prépare et envoie un paquet I2, comme décrit au paragraphe 5.3.3.

18.	Le système DEVRAIT lancer un temporisateur dont la valeur DEVRAIT être supérieure au pire cas de RTT prévu, et DOIT incrémenter un compteur d'essais associé au paquet I2. L'envoyeur DEVRAIT retransmettre le paquet I2 à la fin de la temporisation et relancer le temporisateur, jusqu'à un maximum de I2_RETRIES_MAX essais.

19.	Si le système est dans l'état I1-SENT, il DEVRA passer à l'état I2-SENT. Si le système est dans un autre état, il reste dans l'état en cours.

 	6.8.1	Traitement de messages mal formés
Si une mise en œuvre reçoit un message R1 mal formé, elle DOIT éliminer le paquet en silence. L'envoi d'un NOTIFY ou ICMP ne sert à rien, car l'envoyeur du paquet R1 n'a normalement aucun état. Une mise en œuvre DEVRAIT attendre un certain temps un possible R1 bien formé, après quoi il PEUT essayer à nouveau d'envoyer un nouveau paquet I1.

 	6.9	Traitement de paquets I2 entrants
À réception d'un paquet I2, le système PEUT effectuer les vérifications initiales pour déterminer si le paquet I2 correspond à un paquet R1 récent qui a été envoyé, si le répondant a gardé cet état. Par exemple, l'envoyeur pourrait vérifier si le paquet I2 provient d'une adresse ou HIT pour laquelle le répondant a récemment reçu un I1. Le paquet R1 peut avoir eu des données opaques incluses auxquelles le paquet I2 a fait écho. Si le paquet I2 est considéré comme suspect, il PEUT être éliminé en silence par le système.

Autrement, la mise en œuvre HIP DEVRAIT traiter le paquet I2. Cela inclut la validation de la solution du puzzle, de générer la clé Diffie-Hellman, éventuellement de déchiffrer l'identité d'hôte de l'initiateur, de vérifier la signature, de créer l'état, et finalement d'envoyer un paquet R2.

Les étapes suivantes définissent les règles de traitement conceptuel pour répondre à un paquet I2 :

1.	Le système PEUT vérifier que le paquet I2 correspond à un paquet R1 envoyé récemment. Une telle vérification dépend de la mise en œuvre. Voir à l'Appendice A une description d'exemple de mise en œuvre.

2.	Le système DOIT vérifier que la HIT du répondant correspond à une de ses propres HIT et DOIT éliminer le paquet si ce n'est pas le cas.

3.	Le système DOIT de plus vérifier que la suite HIT de l'initiateur est prise en charge. Le répondant DEVRAIT éliminer en silence les paquets I2 avec une HIT d'initiateur non prise en charge.

4.	Si l'automate à états du système est dans l'état R2-SENT, le système PEUT vérifier si le nouveau paquet I2 reçu est similaire à celui qui a déclenché le passage à R2-SENT. Si c'est le cas, il PEUT retransmettre un paquet R2 envoyé précédemment et remettre à zéro le temporisateur R2-SENT, et l'automate à états reste à l'état R2-SENT.

5.	Si l'automate à états du système est dans l'état I2-SENT, le système DOIT faire une comparaison entre son HIT locale et celle de l'envoyeur (similaire à la méthode de comparaison décrite au paragraphe 6.5). Si la HIT locale est plus petite que celle de l'envoyeur, il devrait éliminer le paquet I2, utiliser la clé Diffie-Hellman de l'homologue et le nom occasionnel #I provenant du paquet R1 reçu antérieurement, et obtenir la clé locale Diffie-Hellman et le nom occasionnel #J provenant du paquet I2 envoyé antérieurement à l'homologue. Autrement, le système devrait traiter le paquet I2 reçu et éliminer tout matériel de chiffrement Diffie-Hellman Kij déduit précédemment qu'il pourrait avoir formé à l'envoi du paquet I2. La clé Diffie-Hellman d'homologue et le nom occasionnel #J sont tirés du paquet I2 juste arrivé. La clé Diffie-Hellman locale et le nom occasionnel #I sont ceux qui ont été envoyés antérieurement dans le paquet R1.

6.	Si l'automate à états du système est dans l'état I1-SENT, et si les HIT dans le paquet I2 correspondent à celles utilisées dans le paquet I1 envoyé précédemment, le système utilise celle reçue dans le paquet I2 comme base pour l'association HIP qu'il essayait de former, et arrête de retransmettre les paquets I1 (pourvu que le paquet I2 passe les vérifications supplémentaires décrites ci-dessous).

7.	Si l'automate à états du système est dans tout autre état que R2-SENT, le système DEVRAIT vérifier que le compteur de génération de R1 en écho dans le paquet I2 est dans la gamme acceptable si le compteur est inclus. Les mises en œuvre DOIVENT accepter les puzzles provenant de la génération en cours et PEUVENT accepter des puzzles provenant de générations antérieures. Si le compteur de génération dans le paquet I2 nouvellement reçu est en dehors de la gamme acceptée, le paquet I2 est périmé (et peut-être répété) et DEVRAIT être éliminé.

8.	Le système DOIT valider la solution du puzzle en calculant le hachage décrit au paragraphe 5.3.3 en utilisant le même algorithme RASH.

9.	Le paquet I2 DOIT avoir une seule valeur dans le paramètre HIP-CIPHER, qui DOIT correspondre à une des valeurs offertes à l'initiateur dans le paquet R1.

10.	Le système doit déduire le matériel de chiffrement Diffie-Hellman Kij fondé sur la valeur publique et l'identifiant de groupe dans le paramètre DIFFIE_HELLMAN. Cette clé est utilisée pour déduire les clés de l'association HIP, comme décrit au paragraphe 6.5. Si l'identifiant de groupe Diffie-Hellman n'est pas pris en charge, le paquet I2 est éliminé en silence.

11.	Le HOST_ID chiffré est déchiffré par la clé de chiffrement de l'initiateur définie au paragraphe 6.5. Si les données déchiffrées ne sont pas un paramètre HOST_ID, le paquet I2 est éliminé en silence.

12.	La mise en œuvre DEVRAIT aussi vérifier que la HIT de l'initiateur dans le paquet I2 correspond à l'identité d'hôte envoyée dans le paquet I2. (Noter que certains boîtiers de médiation peuvent n'être pas capables de faire cette vérification.)

13.	Le système DOIT traiter le paramètre TRANSPORT_FORMAT_LIST. D'autres documents qui spécifient les formats de transport (par exemple, [RFC7402]) contiennent les spécifications pour traiter tout transport choisi.

14.	Le système DOIT vérifier le HIP_MAC conformément aux procédures du paragraphe 5.2.12.

15.	Le système DOIT vérifier la HIP_SIGNATURE conformément aux paragraphes 5.2.14 et 5.3.3.

16.	Si les vérifications ci-dessus réussissent, le système procède alors à la suite du traitement de I2 ; autrement, il élimine le I2 et son automate à états reste dans le même état.

17.	Le paquet I2 peut avoir le bit A établi -- dans ce cas, le système PEUT choisir de le refuser en éliminant le I2 et l'automate à états retourne à l'état UNASSOCIATED. Si le bit A est établi, la HIT de l'initiateur est anonyme et ne devrait pas être mémorisée.

18.	Le système initialise les variables restantes dans l'état associé, incluant les compteurs d'identifiant de mise à jour.

19.	Si le traitement d'un message I2 réussit quand l'automate à états du système est dans l'état UNASSOCIATED, I1-SENT, I2-SENT, ou R2-SENT, un paquet R2 est envoyé et l'automate à états du système passe à l'état R2-SENT.

20.	Si le traitement d'un message I2 réussit quand l'automate à états du système est dans l'état ESTABLISHED, la vieille association HIP est abandonnée et une nouvelle est installée, un paquet R2 est envoyé, et l'automate à états du système passe à l'état R2-SENT.

21.	Quand  l'automate à états du système passe à l'état R2-SENT, le système lance un temporisateur. L'automate à états passe à l'état ESTABLISHED si certaines données ont été reçues sur l'association HIP entrante, ou un paquet UPDATE a été reçu (ou quelque autre paquet qui indique que l'automate à états du système homologue est passé à ESTABLISHED). Si le temporisateur arrive à expiration (permettant une quantité maximale de retransmissions de paquets I2) l'automate à états passe à ESTABLISHED.

 	6.9.1	Traitement de messages mal formés
Si une mise en œuvre reçoit un message I2 mal formé, le comportement DEVRAIT dépendre de à combien de vérifications le message a déjà satisfait. Si la solution du puzzle dans le message a déjà été vérifiée, la mise en œuvre DEVRAIT rapporter l'erreur en répondant avec un paquet Notify. Autrement, la mise en œuvre PEUT répondre avec un message ICMP comme défini au paragraphe 5.4.

 	6.10	Traitement de paquets R2 entrants
Un paquet R2 reçu dans l'état UNASSOCIATED, I1-SENT, ou ESTABLISHED résulte en l'élimination du paquet R2 et l'automate à états reste dans le même état. Si un paquet R2 est reçu dans l'état I2-SENT, il DOIT être traité.

Les étapes suivantes définissent les règles de traitement conceptuel pour un paquet R2 entrant :
1.	Si le système est dans tout état autre que I2-SENT, le paquet R2 est éliminé en silence.
2.	Le système DOIT vérifier que les HIT utilisées correspondent aux HIT qui ont été reçues dans le paquet R1 qui a causé la transition à l'état I1-SENT.
3.	Le système DOIT vérifier le HIP_MAC_2 conformément aux procédures du paragraphe 5.2.13.
4.	Le système DOIT vérifier la signature HIP conformément aux procédures du paragraphe 5.2.14.
5.	Si une des vérifications ci-dessus échoue, il est fort probable qu'il y a en cours une attaque par interposition ou autre attaque contre la sécurité. Le système DEVRAIT agir en conséquence, sur la base de sa politique locale.
6.	Le paquet R2 étant traité avec succès, l'automate à états passe à l'état ESTABLISHED.

 	6.11	Envoi de paquets UPDATE
Un hôte envoie un paquet UPDATE quand il a l'intention de mettre à jour des informations relatives à une association HIP. Un certain nombre de scénarios où cela peut se produire sont possibles, par exemple, la gestion de la mobilité et le changement de clés d'une association de sécurité ESP existante. Les paragraphes qui suivent définissent les règles conceptuelles pour l'envoi d'un paquet UPDATE à l'homologue. Des étapes supplémentaires peuvent être définies dans d'autres documents où le paquet UPDATE est utilisé.

La séquence de messages UPDATE est indiquée par leur paramètre SEQ. Avant d'envoyer un message UPDATE, le système détermine d'abord si il y a des messages UPDATE en instance qui pourraient entrer en conflit avec le nouveau message UPDATE considéré. Quand plusieurs UPDATE sont en instance (pas encore acquittés) l'envoyeur doit supposer que ces UPDATE peuvent être traités dans un ordre arbitraire par le receveur. Donc, tous les nouveaux UPDATE qui dépendent de la bonne réception d'un UPDATE antérieurement en instance et acquitté DOIVENT être différés jusqu'à la réception du ou des ACK nécessaires. Une façon d'empêcher les conflits est de ne permettre qu'un seul UPDATE en instance à la fois. Cependant, permettre plusieurs UPDATE peut améliorer les performances des protocoles de mobilité et de multi rattachements.

Les étapes suivantes définissent les règles de traitement conceptuel pour l'envoi de paquets UPDATE :
1.	Le premier paquet UPDATE est envoyé avec un identifiant de mise à jour de zéro. Autrement, le système incrémente sa valeur d'identifiant de mise à jour de un avant de continuer les étapes ci-dessous.
2.	Le système crée un paquet UPDATE qui contient un paramètre SEQ avec la valeur courante d'identifiant de mise à jour. Le paquet UPDATE PEUT aussi inclure zéro, un ou plusieurs ACK du ou des identifiant de mise à jour de l'homologue provenant des paramètres SEQ UPDATE précédemment reçus.
3.	Le système envoie le paquet UPDATE créé et lance un temporisateur UPDATE. La valeur par défaut pour le temporisateur est 2 * RTT environ. Si plusieurs UPDATE sont en instance, plusieurs temporisateurs sont activés.
4.	Si le temporisateur UPDATE arrive à expiration, le UPDATE est envoyé à nouveau. Le UPDATE peut être envoyé UPDATE_RETRY_MAX fois. Le temporisateur UPDATE DEVRAIT être retardé d'un délai à accroissement exponentiel pour les retransmissions suivantes. Si aucun accusé de réception n'est reçu de l'homologue après UPDATE_RETRY_MAX fois, l'association HIP est considérée comme cassée et l'automate à états DEVRAIT passer de  l'état ESTABLISHED à l'état CLOSING comme décrit au paragraphe 4.4.4. Le temporisateur UPDATE est annulé à réception d'un ACK de l'homologue qui accuse réception du UPDATE.

 	6.12	Réception de paquets UPDATE
Quand un système reçoit un paquet UPDATE, son traitement dépend de l'état de l'association HIP et de le présence et des valeurs des paramètres SEQ et ACK. Normalement, un message UPDATE porte aussi des paramètres facultatifs dont le traitement est défini dans des documents distincts.

Pour chaque association, un hôte mémorise le prochain identifiant de mise à jour attendu en séquence de l'homologue ("identifiant de mise à jour d'homologue"). Initialement cette valeur est zéro. Les comparaisons d'identifiant de mise à jour "moins que" et "supérieur à" sont effectuées par rapport à un espace de numéros de séquence circulaire. Donc, un retour à zéro après 2^32 mises à jour est à attendre et DOIT être traité en conséquence.

L'envoyeur PEUT envoyer plusieurs messages UPDATE en instance. Ces messages sont traités dans l'ordre dans lequel ils sont reçus chez le receveur (c'est-à-dire, aucun reséquençage n'est effectué). Lorsque il traite des UPDATE déclassés, le receveur DOIT garder trace des UPDATE qui ont été traités précédemment, afin que les dupliqués ou les retransmissions soient acquittés et non traités à nouveau. Un receveur PEUT choisir de définir une fenêtre de réception des identifiants de mise à jour qu'il veut traiter à tout moment et éliminer les UPDATE reçus qui tombent en dehors de cette fenêtre.

Les étapes suivantes définissent les règles de traitement conceptuel pour les paquets UPDATE reçus :
1.	Si il n'y a pas d'association HIP correspondante, la mise en œuvre PEUT répondre avec un "Problème de paramètre" ICMP, comme spécifié au paragraphe 5.4.4.
2.	Si l'association est dans l'état ESTABLISHED et si le paramètre SEQ (mais pas ACK) est présent, le UPDATE est traité et il y est répondu comme décrit au paragraphe 6.12.1.
3.	Si l'association est dans l'état ESTABLISHED et si le paramètre ACK (mais pas SEQ) est présent, le UPDATE est traité comme décrit au paragraphe 6.12.2.
4.	Si l'association est dans l'état ESTABLISHED et si il y a à la fois un ACK et un SEQ dans le UPDATE, le ACK est d'abord traité comme décrit au paragraphe 6.12.2, et ensuite le reste du UPDATE est traité comme décrit au paragraphe 6.12.1.

 	6.12.1	Traitement d'un paramètre SEQ dans un message UPDATE reçu
Les étapes suivantes définissent les règles de traitement conceptuel pour traiter un paramètre SEQ dans un paquet UPDATE reçu :
1.	Si le Update ID dans le SEQ reçu n'est pas le prochain dans la séquence des identifiants de mise à jour et est supérieur à la fenêtre du receveur pour les nouveaux UPDATE, le paquet DOIT être éliminé.
2.	Si le Update ID dans le SEQ reçu correspond à un UPDATE qui a été traité récemment, le paquet est traité comme une retransmission. La vérification de HIP_MAC (prochaine étape) NE DOIT PAS être sautée. (Une comparaison octet par octet du paquet reçu et d'un paquet mémorisé serait cependant acceptable.) Il est recommandé qu'un hôte mette en antémémoire les paquets UPDATE envoyés avec des ACK pour éviter le coût de génération d'un nouveau paquet ACK pour répondre à un UPDATE répété. Le système DOIT accuser réception, là encore, de telles retransmissions (apparentes) de message UPDATE mais DEVRAIT aussi considérer de limiter en débit de telles retransmission de réponses pour se garder contre les attaques de répétition.
3.	Le système DOIT vérifier le HIP_MAC dans le paquet UPDATE. Si la vérification échoue, le paquet DOIT être éliminé.
4.	Le système PEUT vérifier la SIGNATURE dans le paquet UPDATE. Si la vérification échoue, le paquet DEVRAIT être éliminé et un message d'erreur enregistré.
5.	Si un nouveau paramètre SEQ est traité, les paramètres dans le UPDATE sont alors traités. Le système DOIT enregistrer le Update ID dans le paramètre SEQ reçu, pour la protection contre la répétition.
6.	Un paquet d'accusé de réception de UPDATE avec le paramètre ACK est préparé et envoyé à l'homologue. Ce paramètre ACK PEUT être inclus dans un UPDATE séparé ou porté dans un UPDATE avec le paramètre SEQ, comme décrit au paragraphe 5.3.5. Le paramètre ACK PEUT accuser réception de plus d'un des identifiants de mise à jour de l'homologue.

 	6.12.2	Traitement d'un paramètre ACK dans un paquet UPDATE reçu
Les étapes suivantes définissent les règles de traitement conceptuel pour traiter un paramètre ACK dans un paquet UPDATE reçu :
1.	Le numéro de séquence rapporté dans le ACK doit correspondre à un paquet UPDATE envoyé antérieurement qui n'a pas encore été acquitté. Si aucune correspondance n'est trouvée ou si le ACK n'accuse pas réception d'un nouvel UPDATE, alors soit le paquet DOIT être éliminé si aucun paramètre SEQ n'est présent, soit les étapes de traitement du paragraphe 6.12.1 sont suivies.
2.	Le système DOIT vérifier le HIP_MAC dans le paquet UPDATE. Si la vérification échoue, le paquet DOIT être éliminé.
3.	Le système PEUT vérifier la SIGNATURE dans le paquet UPDATE. Si la vérification échoue, le paquet DEVRAIT être éliminé et un message d'erreur enregistré.
4.	Le temporisateur UPDATE correspondant est arrêté (voir au paragraphe 6.11) afin que le UPDATE maintenant acquitté ne soit plus retransmis. Si plusieurs UPDATE sont acquittés, plusieurs temporisateurs sont arrêtés.

 	6.13	Traitement des paquets NOTIFY
Le traitement des paquets Notify est FACULTATTIF. Si ils sont traités, toute erreur dans un paramètre NOTIFICATION reçu DEVRAIT être enregistré. Les erreurs reçues DOIVENT n'être considérées que comme des informations, et le receveur NE DEVRAIT PAS changer son état HIP (voir au paragraphe 4.4.2) sur la seule base du message NOTIFY reçu.

 	6.14	Traitement des paquets CLOSE
Quand l'hôte reçoit un message CLOSE, il répond avec un message CLOSE_ACK et passe à l'état CLOSED. (L'authenticité du message CLOSE est vérifiée en utilisant HIP_MAC et SIGNATURE.) Ce traitement s'applique que l'état de l'association HIP soit ou non CLOSING, afin de traiter les messages CLOSE simultanés provenant des deux extrémités qui se croisent en vol.

L'association HIP n'est pas dissoute avant que l'hôte passe à l'état UNASSOCIATED.

Une fois le processus de clôture commencé, tout nouveau besoin d'envoi de paquets de données déclenche la création et l'établissement d'une nouvelle association HIP, commençant par l'envoi d'un paquet I1.

Si il n'y a pas d'association HIP correspondante, le paquet CLOSE est éliminé.

 	6.15	Traitement des paquets CLOSE_ACK
Quand un hôte reçoit un message CLOSE_ACK, il vérifie qu'il est dans l'état CLOSING ou CLOSED et que le CLOSE_ACK était en réponse au CLOSE. Un hôte peut transposer les messages CLOSE_ACK en messages CLOSE en comparant la valeur du ECHO_REQUEST_SIGNED (dans le paquet CLOSE) à celle de ECHO_RESPONSE_SIGNED (dans le paquet CLOSE_ACK).

Le CLOSE_ACK contient les paramètres HIP_MAC et SIGNATURE pour la vérification. L'état est éliminé quand il passe à UNASSOCIATED et, après cela, l'hôte PEUT répondre avec un "problème de paramètre" ICMP à un message CLOSE entrant (voir au paragraphe 5.4.4).

 	6.16	Traitement de la perte d'état
Dans le cas d'une panne du système et d'une perte d'état imprévue, le système DEVRAIT supprimer l'état HIP correspondant, incluant le matériel de chiffrement. C'est-à-dire que l'état NE DEVRAIT PAS être mémorisé à long terme. Si la mise en œuvre élimine l'état (comme RECOMMANDÉ) elle DOIT aussi éliminer la valeur du compteur de génération de R1 de l'homologue, sauf si une politique locale définit explicitement que la valeur de cet hôte est mémorisée. Une mise en œuvre NE DOIT PAS mémoriser par défaut les compteurs de génération de R1 d'un homologue, mais la mémorisation des valeurs de compteur de génération de R1, si elle est faite, DOIT être configurée par des HIT explicites.

 	7.	Politiques HIP

Un certain nombre de variables vont influencer les échanges HIP de base que chaque hôte doit prendre en charge. Toutes les mises en œuvre de HIP DOIVENT prendre en charge plus d'une HI simultanée, dont au moins une DEVRAIT être réservée pour l'usage anonyme. Bien que les HI anonymes soient rarement utilisées comme HI de répondant, elles vont être courantes pour les initiateurs. La prise en charge de plus de deux HI est RECOMMANDÉE.

Les initiateurs PEUVENT utiliser une HI différente pour des répondants différents pour assurer la confidentialité de base. La politique locale décide si de telles HI privées sont utilisées de façon répétée avec le même répondant, et pendant combien de temps ces HI sont utilisées, et cela dépend des exigences de confidentialité de l'initiateur.

La valeur du #K utilisé dans le R1 HIP doit être choisie avec soin. Les valeurs de #K qui sont trop élevées vont exclure les clients avec des CPU faibles parce que ces appareils ne peuvent pas résoudre le puzzle dans un délai raisonnable. #K ne devrait être relevé que si un répondant est très chargé, c'est-à-dire qu'il ne peut plus traiter toutes les prises de contact HIP entrantes. Si un répondant n'est pas surchargé, #K DEVRAIT être 0.

Les répondants qui répondent seulement aux initiateurs choisis exigent une liste de contrôle d'accès (ACL, Access Control List) qui représente pour quels hôtes ils acceptent les échanges HIP de base, le format de transport préféré, et les durées de vie locales. L'utilisation de caractères génériques DEVRAIT être prise en charge pour de telles ACL, et aussi pour les répondants qui offrent des services publics ou anonymes.

 	8.	Considérations sur la sécurité

HIP est conçu pour fournir une authentification sûre des hôtes. HIP tente aussi de limiter l'exposition de l'hôte aux diverses attaques de déni de service et d'interposition (MitM). Ce faisant, HIP lui-même est soumis à ses propre attaques de DoS et MitM qui sont potentiellement plus dommageables à la capacité d'un hôte à conduire ses affaires normalement.

Les attaques de déni de service tirent souvent parti d'asymétries dans le coût du lancement d'une association. Un exemple d'une telle asymétrie est le besoin qu'a un répondant de mémoriser l'état local alors qu'un initiateur malveillant peut rester sans état. HIP ne tente pas d'augmenter le coût du début d'état chez l'initiateur, mais fait un effort pour réduire le coût pour le répondant. Cela se fait en ayant le répondant qui démarre l'échange en trois phase au lieu de l'initiateur, rendant l'échange HIP long de 4 paquets. Ce faisant, le premier paquet du répondant, R1, devient un paquet "souche" que le répondant PEUT utiliser de nombreuses fois, jusqu'à ce qu'un initiateur ait fourni une réponse valide à un tel paquet R1. Durant une tempête de paquets I1, l'hôte peut réutiliser aussi la même valeur DH, même si un initiateur a fourni une réponse valide en utilisant cette valeur DH particulière. Cependant, ce comportement est déconseillé et devrait être évité. Utiliser les mêmes valeurs Diffie-Hellman et valeur de puzzle #I aléatoire présente des risques. Ces risques doivent être évalués par rapport à de potentielles tempêtes de paquets I1 HIP.

Ce glissement du début du coût de l'état de l'initiateur dans la création du paquet I2 HIP présente un autre risque d'attaque de déni de service. L'attaquant peut contrefaire le paquet I1, et le répondant envoie le paquet R1 HIP. Cela peut lier "l'initiateur" à l'évaluation du paquet HIP R1, et à créer le paquet I2. La défense contre cette attaque est de simplement ignorer tout paquet R1 où un paquet I1 correspondant n'a pas été envoyé (comme défini au paragraphe 6.8, étape 1).

Le paquet R1 est considérablement plus grand que le paquet I1. Cette asymétrie peut être exploitée dans une attaque de réflexion. Un attaquant malveillant pourrait contrefaire l'adresse IP d'une victime et envoyer un flot de messages I1 à un répondant puissant. Pour chaque petit paquet I1, le répondant va envoyer un grand paquet R1 à la victime. La différence des tailles de paquet peut encore amplifier une attaque d'inondation contre la victime. Pour éviter de telles attaques de réflexion, le répondant DEVRAIT limiter le débit d'envoi des paquets R1 en général ou DEVRAIT limiter le débit d'envoi des paquets R1 à une adresse IP spécifique.

Les inondations de paquets I2 contrefaits forment une seconde sorte d'attaque de déni de service. Une fois que l'initiateur attaquant a résolu le puzzle, il peut envoyer des paquets avec des adresses IP de source contrefaites avec soit une signature HIP invalide soit une charge utile HIP chiffrée invalide (dans le paramètre ENCRYPTED). Cela va prendre des ressources dans la partie du répondant jusqu'à atteindre le moment où on découvre que le paquet I2 ne peut pas être complètement traité. La défense contre cette attaque est qu'après N mauvais paquets I2 avec la même solution de puzzle, le répondant va éliminer tout paquet I2 qui contient cette solution. Cela va clore l'attaque. L'attaquant devrait demander un autre paquet R1 et l'utiliser pour lancer une nouvelle attaque. Le répondant pourrait augmenter la valeur de #K lorsque il est attaqué. Tenir une liste des solutions provenant de paquets mal formés exige que le répondant conserve l'état pour ces paquets I2 mal formés. Cet état devrait être conservé jusqu'à ce que le compteur R1 soit augmenté. Comme les paquets mal formés sont généralement filtrés par leur somme de contrôle avant la vérification de signature, seules les solutions dans les paquets contrefaits pour réussir la somme de contrôle et le puzzle sont mis dans la liste noire. De plus, un puzzle valide est nécessaire avant qu'une nouvelle entrée soit créée dans la liste. Donc, les attaquants qui veulent inonder la liste noire doivent d'abord résoudre les puzzles.

Une troisième forme d'attaque de déni de service est d'émuler le redémarrage d'état après un réamorçage d'un des homologues. Un hôte qui redémarre va envoyer un paquet I1 à l'homologue, qui va répondre avec un paquet R1 même si il était dans l'état ESTABLISHED. Si le paquet I1 était contrefait, le paquet R1 résultant va être reçu de façon inattendue par l'hôte mystifié et va être éliminé, comme dans le premier cas ci-dessus.

Une quatrième forme d'attaque de déni de service est d'émuler la clôture de l'association HIP. HIP s'appuie sur des temporisateurs et une prise de contact CLOSE/CLOSE_ACK pour signaler explicitement la fin d'une association HIP. Comme les messages CLOSE et CLOSE_ACK contiennent tous deux un HIP_MAC, un intrus ne peut pas clore une connexion. La présence d'une SIGNATURE supplémentaire permet aux boîtiers de médiation d'inspecter ces messages et éliminer l'état associé (par exemple, pour les pare-feu, les NAT fondés sur le SPI, etc.). Cependant, le comportement facultatif de répondre à CLOSE avec un paquet ICMP "Problème de paramètre" (comme décrit au paragraphe 5.4.4) peut permettre à un attaquant qui contrefait l'adresse IP de source pour envoyer des messages CLOSE de lancer des attaques de réflexion.

Une cinquième forme d'attaque de déni de service est de répéter les R1 pour amener l'initiateur à résoudre des puzzles périmés et perdre la synchronisation avec le répondant. Le compteur de génération de R1 est un compteur à accroissement monotone conçu pour protéger contre cette attaque, comme décrit au paragraphe 4.1.4.

Il est difficile de se défendre contre les attaques par interposition, sans authentification par un tiers. Un interposé habile pourrait facilement traiter toutes les parties de HIP, mais HIP fournit indirectement la protection suivante contre une attaque par MitM. Si la HI du répondant est restituée d'une zone signée du DNS, un certificat, ou quelque autre moyen sûr, l'initiateur peut utiliser cela pour valider le paquet HIP R1.

De même, si la HI de l'initiateur est dans une zone sûre du DNS, un certificat de confiance, ou autrement disponible en toute sécurité, le répondant peut restituer la HI (après avoir obtenu le paquet I2 HIP) et vérifier que la HI peut être crue.

Le concept de "mode opportuniste" HIP a été introduit dans ce document, mais il ne spécifie pas la sémantique d'un tel établissement de connexion pour les applications. Le mode opportuniste pose certains problèmes, discutés au paragraphe  4.1.8.

Les messages NOTIFY ne sont utilisés qu'à des fins d'information, et ils ne font pas l'objet d'un accusé de réception. Une mise en œuvre de HIP ne peut pas s'appuyer seulement sur les informations reçues dans un message NOTIFY parce que le paquet peut avoir été répété. Une mise en œuvre NE DEVRAIT PAS changer d'informations d'état sur la seule base d'un message NOTIFY reçu.

Comme tous les hôtes ne vont pas prendre en charge HIP, les messages ICMP "Protocole de destination injoignable" sont à attendre et peuvent être utilisés pour une attaque de déni de service. Contre un initiateur, l'attaque va faire croire que le répondant ne prend pas en charge HIP, mais peu après avoir reçu le message ICMP, l'initiateur va recevoir un paquet HIP R1 valide. Donc, pour se protéger contre cette attaque, un initiateur NE DEVRAIT PAS réagir à un message ICMP jusqu'à ce qu'un délai raisonnable soit écoulé pour obtenir le vrai paquet HIP R1 du répondant. Une attaque similaire contre le répondant est plus préoccupante. Normalement, si un message I1 reçu par un répondant est bogué parce qu'envoyé par un attaquant, le répondant peut recevoir un message ICMP de l'adresse IP d'où le message R1 a été envoyé. Cependant, un attaquant sophistiqué peut essayer de tirer parti d'un tel comportement et essayer de casser l'échange de base HIP en envoyant un tel message ICMP au répondant avant que l'initiateur ait une chance d'envoyer un message I2 valide. Donc, le répondant NE DEVRAIT PAS réagir à un tel message ICMP. En particulier, il NE DEVRAIT PAS supprimer tout état minimal créé quand il a envoyé le paquet R1 HIP (si il en a créé un) mais devrait attendre un paquet I2 HIP valide ou la fin de temporisation naturelle (c'est-à-dire, si des paquets R1 sont suivis). De même, l'initiateur DEVRAIT ignorer tout message ICMP pendant qu'il attend un paquet R2 HIP, et DEVRAIT ne supprimer tout état en cours qu'après une fin de temporisation naturelle.

 	9.	Considérations relatives à l'IANA

L'IANA a réservé le numéro de protocole 139 pour le protocole d'identité d'hôte et l'a inclus dans le registre "Types d'en-têtes d'extension IPv6" [RFC7045] et le registre des "numéros alloués aux protocoles de l'Internet". La référence dans ces deux registres a été mise à jour de la [RFC5201] à la présente spécification.

La référence à la valeur de 128 bits de l'espace de noms Type de message CGA [RFC3972] de "0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA" a été changée de la [RFC5201] à la présente spécification.

Les changements suivants aux "paramètres du protocole d'identité d'hôte (HIP)" ont été faits. Dans de nombreux cas, les changements impliquent de mettre à jour la référence de la [RFC5201] à la présente spécification, mais il y a quelques différences qui sont mentionnées ci-dessous. La terminologie des allocations est définie dans la [RFC5226] ; toute référence existante au "consensus de l'IETF" peut être remplacée par "revue par l'IETF" selon la [RFC5226].

Version HIP : le présent document ajoute la valeur "2" au registre existant. La valeur de "1" a été laissée avec une référence à la [RFC5201].

Type de paquet : Le champ de 7 bits Type de paquet dans un paquet de protocole HIP décrit le type d'un message de protocole HIP. Il est défini au paragraphe 5.1. Toutes les valeurs existantes qui se réfèrent à la [RFC5201] ont été mises à jour pour se référer à la présente spécification. Les autres valeurs sont restées inchangées.

Identifiant de suite HIT : La présente spécification crée un nouveau registre pour "identifiant de suite HIT". Il est différent du registre existant pour "Suite ID", qui peut être laissé non modifié pour la version 1 du protocole [RFC5201]. Le registre a été clos aux nouveaux enregistrements. L'identifiant de suite HIT de quatre bits utilise le champ ID OGA dans le ORCHID pour exprimer le type de la HIT. Le présent document définit trois suites HIT (voir au paragraphe 5.2.10). L'identifiant de suite HIT est aussi porté dans les quatre bits de poids fort du champ ID dans le paramètre HIT_SUITE_LIST. Les quatre bits de moindre poids sont réservé pour de futures extensions de l'espace d’identifiant de suite HIT au delà de 16 valeurs. Pour l'instant, la suite HIT utilise seulement quatre bits parce que ces bits doivent être portés dans la HIT. Utiliser plus de bits pour l"identifiant de suite HIT réduirait la force cryptographique de la HIT. Les identifiants de suite HIT doivent être alloués avec prudence pour éviter l'épuisement de l'espace de noms. De plus, les identifiant déconseillés devraient être réutilisés après un intervalle de temps approprié. Si 15 identifiants de suite (la valeur zéro est initialement réservée) se révèlent être insuffisants et si plus d'identifiants de suite HIT sont nécessaires concurremment, plus de bits peuvent être utilisés pour l'identifiant de suite HIT en utilisant un identifiant de suite HIT (0) pour indiquer que plus de bits devraient être utilisés. Le paramètre HIT_SUITE_LIST prend déjà en charge des identifiants de suite HIT de huit bits, si des identifiants plus longs étaient nécessaires. Cependant, la [RFC7343] ne prend actuellement pas en charge une telle extension. On suggère d'essayer d'abord l'approche du retour à zéro décrite dans l'Appendice E. De possibles extensions de l'espace d'identifiant de suite HIT pour s'accommoder de huit bits et de nouveaux identifiants de suite HIT seront définis par revue de l'IETF. Les demandes d'enregistrement de valeurs réutilisées devraient inclure une note disant que la valeur est réutilisée après une période où elle est déconseillée, pour s'assurer d'une revue et approbation appropriées de l'IETF.

Type de paramètre : Le champ de 16 bits Type dans un paramètre HIP décrit le type du paramètre. Il est défini au paragraphe 5.2.1. Les valeurs courantes sont définie dans les paragraphes 5.2.3 à 5.2.23. Le registre existant "Types de paramètres" a été mis à jour comme suit. Une nouvelle valeur (129) pour R1_COUNTER a été introduite, avec une référence à la présente spécification, et la valeur existante (128) pour R1_COUNTER a été laissé en place avec une référence à la [RFC5201]. Cela rend compte du changement de valeur qui se produit dans la version 2 de ce protocole. En clair, le nom pour la valeur 128 a été changé de "R1_COUNTER" en "R1_Counter (seulement v1)". Une nouvelle valeur (579) pour un nouveau type de paramètre HIP_CIPHER a été ajouté, avec référence à la présente spécification. Ce type de paramètre remplace fonctionnellement le type de paramètre HIP_TRANSFORM  (valeur 577) qui a été laissé dans le tableau avec la référence à la [RFC5201]. En clair, le nom de la valeur 577 a été changé de "HIP_TRANSFORM" en "HIP_TRANSFORM (seulement v1)". Une nouvelle valeur (715) pour un nouveau type de paramètre HIT_SUITE_LIST a été ajouté, avec référence à la présente spécification. Une nouvelle valeur (2049) pour un nouveau type de paramètre TRANSPORT_FORMAT_LIST a été ajouté, avec référence à la présente spécification. Le nom du type de paramètre HMAC (valeur 61505) a été changé en HIP_MAC. Le nom du Type de paramètre HMAC_2 (valeur 61569) a été changé en HIP_MAC_2. La référence a été changée en la présente spécification. Tous les autres types de paramètre qui font référence à la [RFC5201] ont été mis à jour pour se référer à la présente spécification, et les types de paramètres qui font référence à d'autres RFC sont inchangés. Les codes de type de 32768 à 49151 (pas 49141 : valeur corrigée d'une version antérieure de ces tableau) ont été réservés pour utilisation privée. Les mises en œuvre DEVRAIENT choisir les types de façon aléatoire dans cette gamme, pour réduire la probabilité de collisions. Une méthode employant une aléation authentique (comme le jet d'une pièce) DEVRAIT être utilisée. Quand les gammes existantes disaient "premier arrivé, premier servi avec spécification exigée", cela a été changé en "spécification exigée".

Identifiant de groupe : les valeurs de huit bits d'identifiant de groupe apparaissent dans le paramètre DIFFIE_HELLMAN et le paramètre DH_GROUP_LIST, et sont définies au paragraphe 5.2.7. Ce registre a été mis à jour sur la base des nouvelles valeurs spécifiées au paragraphe 5.2.7 ; les valeurs notées comme DEPRECATED peuvent être laissées dans le tableau avec la référence à la [RFC5201]. Les nouvelles valeurs sont allouées par revue de l'IETF.

Identifiant de chiffrement HIP : les valeurs de 16 bits d'identifiant de chiffrement dans un paramètre HIP-CIPHER sont définies au paragraphe 5.2.8. C'est un nouveau registre. Les nouvelles valeurs des espaces réservé ou non alloué sont attribuées par revue de l'IETF.

Type d'identifiant de domaine : les valeurs de quatre bits de type d'identifiant de domaine dans un paramètre HOST_ID sont définies au paragraphe 5.2.9. Les nouvelles valeurs sont allouées par revue de l'IETF. Toutes les valeurs existantes qui se réfèrent à la [RFC5201] ont été mises à jour pour se référer à la présente spécification.

Algorithme d'identité d'hôte : les valeurs de 16 bits d'algorithme dans un paramètre HOST_ID sont définies au paragraphe 5.2.9. C'est un nouveau registre. Les nouvelles valeurs des espaces réservé ou non alloué sont attribuées par revue de l'IETF.

Étiquette de courbe ECC : quand les valeurs d'algorithme de HI dans un paramètre HOST_ID sont définies aux valeurs de "ECDSA" ou "ECDSA_LOW", un nouveau registre est nécessaire pour conserver les valeurs de l'étiquette de courbe ECC, comme défini au paragraphe 5.2.9.  Cela peut être traité en spécifiant deux sous registres spécifiques des algorithmes nommés "étiquette de courbe ECDSA" et "étiquette de courbe ECDSA_LOW". Les nouvelles valeurs sont à allouer par revue de l'IETF.

Type de message Notify : les valeurs de 16 bits de type de message Notify dans un paramètre NOTIFICATION sont définies au paragraphe 5.2.19. Les valeurs de type de message Notify de 1 à 10 sont utilisées pour des informations sur des erreurs dans les structures de paquet, les valeurs de 11 à 20 pour informer sur des problèmes de paramètres contenant du matériel en rapport avec le chiffrement, et les valeurs de 21 à 30 pour informer sur des problèmes d'authentification ou de vérification d'intégrité de paquet. Les numéros de paramètre au dessus de 30 peuvent être utilisés pour informer sur les autres types d'erreurs ou événements.

Les procédures existantes d'enregistrement ont été mises à jour comme suit. La gamme de 1 à 50 peut rester en "revue de l'IETF". La gamme de 51 à 8191 a été marquée "Spécification exigée". Les valeurs 8192 à 16383 restent en "Réservé pour utilisation privée". Les valeurs 16384 à 40959 ont été marquées "Spécification exigée". Les valeurs 40960 à 65535 restent "Réservé pour utilisation privée".

Les mises à jour suivantes aux valeurs ont été faites dans le registre existant. Toutes les valeurs existantes qui se réfèrent à la [RFC5201] ont été mises à jour pour se référer à la présente spécification.
- INVALID_HIP_TRANSFORM_CHOSEN a été appelé INVALID_HIP_CIPHER_CHOSEN avec la même valeur (17).
- Une nouvelle valeur de 20 a été ajoutée pour le type UNSUPPORTED_HIT_SUITE.
- HMAC_FAILED a été appelé HIP_MAC_FAILED avec la même valeur (28).
- SERVER_BUSY_PLEASE_RETRY a été appelé RESPONDER_BUSY_PLEASE_RETRY avec la même valeur (44).

 	10.	Différences avec la RFC 5201

Cette section résume les changements techniques faits depuis la [RFC5201]. Elle est seulement pour information, pour aider les mises en œuvre de la précédente version du protocole. Si du texte de cette section contredit du texte d'autres portions de la présente spécification, le texte des autres section devrait être considéré comme normatif.

Le présent document spécifie la version 2 du protocole HIP, qui n'est pas interopérable avec la version 1 du protocole HIP spécifié dans la [RFC5201]. Les principaux changements techniques sont l'inclusion de caractéristiques supplémentaires d'agilité cryptographique, et une mise à jour des algorithmes obligatoires et facultatifs, incluant la prise en charge des courbes elliptiques via les algorithmes de courbe elliptique DSA (ECDSA) et de courbe elliptique Diffie-Hellman (ECDH).  Les mises en œuvre d'algorithme de chiffrement obligatoires ont été mises à jour, avec le remplacement de HMAC-SHA-1 par HMAC-SHA-256 et de l'algorithme de signature RSA/SHA-1 par RSASSA-PSS, et l'ajout de ECDSA à RSA comme types obligatoires de clé publique. Cette version de HIP est aussi alignée sur la révision de ORCHID [RFC7343].

Les changements suivants ont été faits au fonctionnement du protocole :
o	Le paragraphe 4.1.3 décrit le nouveau traitement de la négociation de groupe Diffie-Hellman, un aspect de l'agilité cryptographique. L'initiateur peut exprimer une préférence pour un groupe DH dans le paquet I1 et peut suggérer plusieurs choix possibles. Le répondant réplique avec une préférence sur la base de sa politique locale et des options fournies par l'initiateur. L'initiateur peut recommencer l'échange de base si l'option choisie par le répondant ne convient pas (algorithmes non pris en charge).
o	Un autre aspect de l'agilité cryptographique qui a été ajouté est la capacité d'utiliser différentes fonctions de hachage cryptographique pour générer la HIT. La terminologie de l'algorithme de hachage de HIT (RHASH) du répondant a été introduite pour prendre en charge cela. De plus, les suites HIT ont été introduites pour grouper l'ensemble des algorithmes de chiffrement utilisés ensemble pour la signature de clé publique, la fonction de hachage, et le troncage de hachage. L'utilisation des suites HIT contraint les possibilités de combinaison de choix d'algorithmes pour les différentes fonctions. Les identifiants de suite HIT se rapportent à l'identifiant de champ OGA ORCHID ([RFC7343]).
o	Le mécanisme de puzzle a été légèrement changé, en ce que le paramètre #I dépend de la fonction de hachage de HIT (RHASH) choisi, et la spécification déconseille maintenant la réutilisation de la même valeur #I pour le même initiateur  ; plus de détails sont fournis aux paragraphes 4.1.2 et 5.2.4).
o	Le paragraphe 4.1.4 a été étendu pour couvrir les détails du retour à zéro ou de la réinitialisation du compteur de génération de R1.
o	Le paragraphe 4.1.6 a été ajouté pour décrire les procédures pour interrompre un échange de base HIP.
o	Le paragraphe 4.1.7 fournit des lignes directrices pour éviter les attaques en dégradation sur les algorithmes de chiffrement.
o	Le paragraphe 4.1.8 sur le mode opportuniste a été mis à jour pour tenir compte de l'agilité cryptographique en ajoutant les procédures de choix de HIT.
o	La génération de KEYMAT HIP a été mise à jour comme décrit au paragraphe 6.5 pour faire de la fonction de déduction de clé un aspect négociable du protocole.
o	Le traitement de paquet pour les paquets I1, R1, et I2 a été mis à jour pour tenir compte du nouveau traitement de paramètre.
o	Cette spécification ajoute l'exigence que les hôtes DOIVENT prendre en charge le traitement des paramètres ACK avec plusieurs numéros de séquence SEQ même quand ils ne prennent pas en charge l'envoi de tels paramètres.
o	Le présent document précise maintenant que plusieurs paramètres ECHO_REQUEST_UNSIGNED peuvent être présents dans un R1 et que plusieurs paramètres ECHO_RESPONSE peuvent être présents dans un I2.
o	Les procédures pour répondre aux discordances de versions avec un message ICMP "Problème de paramètre" ont été ajoutées.
o	La section des considérations sur la sécurité (Section 8) a été mise à jour pour supprimer de possibles attaques qui ne sont plus considérées comme applicables.
o	L'utilisation du bit Anonyme pour rendre anonyme l'identité d'hôte de l'envoyeur est maintenant acceptée dans les paquets autres que le R1 et I2.
o	La prise en charge de l'utilisation d'un chiffrement HIP NULL est explicitement limitée au débogage et aux essais HIP et n'est plus un algorithme de prise en charge obligatoire.

Les changements suivants ont été faits aux types et codages de paramètres (paragraphe 5.2) :
o	Quatre nouveaux types de paramètres ont été ajoutés : DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, et TRANSPORT_FORMAT_LIST.
o	Deux types de paramètres ont été renommés : HMAC est devenu HIP_MAC, et HMAC2 est devenu HIP_MAC_2.
o	Un type de paramètre est déconseillé : HIP_TRANSFORM. Fonctionnellement, il a été remplacé par HIP_CIPHER mais avec une sémantique légèrement différente (les hachages ont été supprimés et sont maintenant déterminés par RHASH).
o	Le paramètre TRANSPORT_FORMAT_LIST permet que les transports soient négociés avec la liste à la place de leur ordre dans le paquet HIP.
o	Le code de type pour le R1_COUNTER a été changé de 128 à 129 pour refléter qu'il est maintenant considéré comme un paramètre critique et qu'il doit y être fait écho quand il est présent dans R1.
o	Les longueurs des paramètres PUZZLE et SOLUTION sont maintenant variables et dépendent de la longueur RHASH.
o	Les identifiants de groupe Diffie-Hellman pris en charge ont été mis à jour.
o	Le paramètre HOST_ID exige maintenant la spécification d'un algorithme.
o	Le paramètre NOTIFICATION prend en charge de nouvelles valeurs de type de message Notify.
o	Le champ de l'algorithme HIP_SIGNATURE a été changé de 8 bits à 16 bits pour l'aligner sur les paramètres HOST_ID.
o	La spécification précise que le paramètre SEQ contient toujours un identifiant de mise à jour mais que le paramètre ACK peut accuser réception de plusieurs identifiants de mise à jour.
o	La restriction qu'un seul paramètre ECHO_RESPONSE_UNSIGNED doit être présent dans chaque paquet HIP a été supprimée.
o	Le document crée une nouvelle allocation de gamme de types pour les paramètres qui sont seulement couverts par une signature si une signature est présente et l'applique au paramètre DH_GROUP_LIST nouvellement créé.
o	Le document précise que plusieurs paramètres NOTIFY peuvent être présents dans un paquet.

Les changements suivants ont été faits au contenu du paquet (paragraphe 5.3) :
o	Le paquet I1 porte maintenant les DH_GROUP_LIST de l'initiateur.
o	Le paquet R1 porte maintenant les paramètres HIP_CIPHER, HIT_SUITE_LIST, DH_GROUP_LIST, et TRANSPORT_FORMAT_LIST.
o	Le paquet I2 porte maintenant les paramètres HIP_CIPHER et TRANSPORT_FORMAT_LIST.
o	Le présent document précise que les paquets UPDATE qui ne contiennent ni SEQ ni ACK sont invalides.

 	11.	Références
 	11.1	Références normatives

[FIPS.180-4.2012] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, mars  2012, <http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf>.

[NIST.800-131A]	National Institute of Standardsand Technology, "Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths", NIST SP 800-131A, janvier 2011, <http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf>.

[RFC0768]	J. Postel, "Protocole de datagramme d’utilisateur (UDP)", (STD 6), 28 août 1980.

[RFC0793]	J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7, septembre 1981.

[RFC1035]	P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, novembre 1987. (MàJ par RFC1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604, 7766, 8482, 8767

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC2404]	C. Madson, R. Glenn, "Utilisation de HMAC-SHA-1-96 au sein d'ESP et d'AH", novembre 1998. (P.S.)

[RFC2410]	R. Glenn, S. Kent, "L'algorithme de chiffrement NULL et son utilisation avec IPsec", novembre 1998. (P.S.)

[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre   1998. (MàJ par 5095, 6564   ; D.S ; Remplacée par RFC8200, STD 86)

[RFC2536]	D. Eastlake 3rd , "Clés DSA et SIG dans le système des noms de domaines (DNS)", mars 1999. (P.S.)

[RFC3110]	D. Easlake 3, "SIG RSA/SHA-1 et clés RSA dans le système des noms de domaine (DNS)", mai 2001. (MàJ par RFC6944) (PS)

[RFC3526]	T. Kivinen et M. Kojo, "Groupes supplémentaires d’exponentiation modulaire (MODP) Diffie-Hellman pour l’échange de clés Internet (IKE)", mai 2003.

[RFC3602]	S. Frankel, R. Glenn, S. Kelly, "Algorithme de chiffrement AES-CBC et utilisation avec IPsec", septembre  2003. (P.S.)

[RFC3972]	T. Aura, "Adresses générées cryptographiquement (CGA)", mars 2005. (MàJ par RFC4581, RFC4982) (P.S.)

[RFC4034]	R. Arends et autres, "Enregistrements de ressources pour les extensions de sécurité au DNS", mars 2005.

[RFC4282]	B. Aboba et autres, "L'identifiant d'accès réseau", décembre 2005. (P.S., Remplacée par RFC7542)

[RFC4443]	A. Conta et autres, "Spécification du protocole de message de contrôle Internet (ICMPv6) pour la version 6 du protocole Internet (IPv6)", mars 2006. (Remplace RFC2463) (MàJ RFC2780) (MàJ par RFC4884) (D.S.)

[RFC4754]	D. Fu, J. Solinas, "Authentification IKE et IKEv2 avec l'algorithme de signature numérique à courbe elliptique (ECDSA)", janvier 2007. (P.S.)

[RFC4868]	S. Kelly, S. Frankel, "Utilisation de HMAC-SHA-256, HMAC-SHA-384, et HMAC-SHA-512 avec IPsec", mai 2007. (P.S.)

[RFC5702]	J. Jansen, "Utilisation des algorithmes SHA-2 avec RSA dans les enregistrements de ressource DNSKEY et RRSIG pour DNSSEC", octobre 2009. (P. S.)

[RFC6724]	D. Thaler, R. Draves, A. Matsumoto, T. Chown, "Choix de l’adresse par défaut pour IPv6", septembre 2012. (Remplace la RFC3484) (P.S.)

[RFC7343]	J. Laganier, F. Dupont, "Préfixe IPv6 pour les identifiants de hachage cryptographique à recouvrement d'acheminement, version 2 (ORCHIDv2)", septembre 2014. (P.S.)

[RFC7402]	P. Jokela, et autres, "Utilisation du format de transport de charge utile de sécurité par encapsulage (ESP) avec le protocole d'identité d'hôte (HIP)", avril 2015. (P.S., Remplace RFC5202)

 	11.2	Références pour information

[AUR05]	Aura, T., Nagarajan, A., and A. Gurtov, "Analysis of le HIP Base Exchange Protocol", dans" Proceedings of the 10th Australasian Conference on Information Security and Privacy", juillet 2005.

[CRO03]    Crosby, S. and D. Wallach, "Denial of Service via Algorithmic Complexity Attacks", dans "Proceedings of the 12th USENIX Security Symposium", Washington, D.C., août 2003.

[DIF76]    Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory Volume IT-22, Number 6, pages 644-654, novembre 1976.

[FIPS.186-4.2013] National Institute of Standards andTechnology, "Digital Signature Standard (DSS)", FIPS PUB 186-4, juillet 2013, < http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf >.

[FIPS.197.2001]	National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", FIPS PUB 197, novembre 2001, < http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf >.

[HIP-ARCH] Moskowitz, R., Ed., et M. Komu, "Architecture du protocole d'identité d'hôte", Travail en cours, draft-ietf-hip-rfc4423-bis-09, octobre 2014.

[KAU03]	Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS protection for UDP-based protocols", dans les "Proceedings of the 10th ACM Conference on Computer and Communications Security", octobre 2003.

[KRA03]	Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols", dans Proceedings of CRYPTO 2003, pages 400-425, août 2003.

[RFC0792]	J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981. (MàJ par la RFC6633) 

[RFC2785]	R. Zuccherato, "Méthodes pour éviter les attaques de "petit sous-groupe" sur la méthode d'accord de clés Diffie-Hellman pour S/MIME", mars 2000. (Information)

[RFC2898]	B. Kaliski, "PKCS n° 5 : Spécification de la cryptographie fondée sur un mot de passe, version 2.0", septembre 2000. (Info. ; remplacée par RFC8018)

[RFC3447]	J. Jonsson et B. Kaliski, "Normes de cryptographie à clés publiques (PKCS) n° 1 : Spécifications de la cryptographie RSA version 2.1", février 2003. (Obsolète, remplacée par RFC8017) (Information)

[RFC3849]	G. Huston, A. Lord, P. Smith "Préfixe d'adresse IPv6 réservé pour la documentation", juillet 2004. (Information)

[RFC5201]	R. Moskowitz et autres, "Protocole d'identité d'hôte (HIP)", avril 2008. (Expérimentale)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5338]	T. Henderson et autres, "Utilisation du protocole d'identité d'hôte avec des applications traditionnelles", septembre  2008. (Expérimentale)

[RFC5533]	E. Nordmark, M. Bagnulo, "Shim6 : Protocole Shim de niveau 3 de multi rattachements pour IPv6", juin  2009. (P. S.)

[RFC5737]	J. Arkko, M. Cotton, L. Vegoda, "Blocs d'adresses IPv4 réservés pour la documentation" janvier 2010. (MàJ RFC1166) (Information)

[RFC5869]	H. Krawczyk, P. Eronen, "Fonction de déduction de clé par extraction et expansion fondée sur HMAC (HKDF)", mai  2010. (Information)

[RFC5903]	D. Fu, J. Solinas, "Groupes de courbes elliptiques modulo un nombre premier (groupes ECP) pour IKE et IKEv2", juin  2010. (Remplace RFC4753) (Information)

[RFC6090]	D. McGrew, K. Igoe, M. Salter, "Algorithmes fondamentaux de cryptographie par courbe élliptique", février  2011. (Info.)

[RFC6253]	T. Heer, S. Varjonen, "Certificats du protocole d’identité d’hôte", mai 2011. (MàJ la RFC5201) (Exp. Remplacée par RFC8002)

[RFC7045]	B. Carpenter, S. Jiang, "Transmission et traitement des en-têtes d’extension IPv6", décembre 2013. (MàJ RFC2460, RFC2780) (P.S.)

[RFC7296]	C. Kaufman, et autres, "Protocole d'échange de clé Internet version 2 (IKEv2)", octobre 2014. STD 79. (MàJ par RFC7670, RFC8247)

[RFC8004]	J. Laganier, L. Eggert, "Extension de rendez-vous au protocole d'identité d'hôte", octobre 2016. (P.S. ; Remplace RFC5204)

[RFC8005]	J. Laganier, "Extension au système des noms de domaines pour le protocole d'identité d'hôte (HIP)", octobre  2016. (P.S. ; Remplace RFC5205)

[RFC8046]	T. Henderson, C. Vogt, J. Arkko, "Mobilité d'hôte avec le protocole d'identité d'hôte", février 2017. (P.S. ; remplace RFC5206)

[RSA]	Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM 21 (2), pp. 120-126, février 1978.

[SECG]	SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2 Version 2.0, janvier 2010, <http://www.secg.org/>.

 	Appendice A.	Utilisation des puzzles de répondant

Comme mentionné au paragraphe 4.1.1, le répondant peut retarder la création d'état et quand même rejeter la plupart des paquets I2 contrefaits en utilisant un certain nombre de paquets R1 pré-calculés et une fonction de sélection locale. Le présent appendice définit une possible mise en œuvre en détails. L'objet de cet appendice est de donner aux mises en œuvre une idée de la façon d'appliquer le mécanisme. Si la mise en œuvre s'appuie sur cet appendice, elle PEUT contenir des modifications locales qui rendent plus difficile la tâche d'un attaquant.

Le répondant crée une valeur secrète S, qu'il régénère périodiquement. Le répondant doit se souvenir des deux dernières valeurs de S. Chaque fois que S est régénéré, le compteur de génération de R1 est incrémenté de un.

Le répondant génère un paquet R1 pré signé. La signature pour les R1 pré générés doit être recalculée quand la clé Diffie-Hellman est recalculée ou quand la valeur de R1_COUNTER change à cause de la régénération de la valeur de S.

Quand l'initiateur envoie le paquet I1 pour initialiser une connexion, le répondant reçoit la HIT et l'adresse IP du paquet, et génère une valeur #I pour le puzzle. La valeur #I est réglée au paquet R1 pré signé.

calcule de la valeur #I :
       #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n)
       où n = RHASH_len

L'algorithme RASH est le même que celui utilisé pour générer la valeur de la HIT du répondant.

D'un paquet I2 entrant, le répondant reçoit les informations requises pour valider le puzzle : les HIT, les adresses IP, et les informations sur la valeur S utilisée provenant du R1_COUNTER. En utilisant ces valeurs, le répondant peut régénérer le #I, et le vérifier par rapport au #I reçu dans le paquet I2. Si les valeurs de #I correspondent, il peut vérifier la solution en utilisant #I, #J, et la difficulté #K. Si les valeurs de #I ne correspondent pas, le I2 est éliminé.

vérification du puzzle _ :
    V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K )
    si V != 0, éliminer le paquet.

Si la solution du puzzle est correcte, les valeurs #I et #J sont mémorisées pour utilisation ultérieure. Elles sont utilisées comme matériel d'entrée quand le matériel de chiffrement est généré.

Garder l'état des solutions erronées de puzzle dépend de la mise en œuvre. Bien qu'il soit possible que le répondant ne garde aucune information d'état, il peut quand même le faire pour se protéger lui-même contre certaines attaques (voir au paragraphe 4.1.1).

 	Appendice B.	Génération d'un codage de clé publique à partir d'un HI

Le pseudo-code suivant illustre le processus de génération d'un codage de clé publique à partir d'une HI pour RSA et DSA.

Le symbole ":=" note l'allocation ; le symbole "+=" note l'ajout. La pseudo fonction "encode_in_network_byte_order" prend deux paramètres, un entier (bignum) et une longueur en octets, et retourne l'entier codé en chaîne d'octets de la longueur donnée.

switch ( HI.algorithm )
{

cas de RSA :
      buffer := encode_in_network_byte_order ( HI.RSA.e_len, ( HI.RSA.e_len > 255 ) ? 3 : 1 )
      buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len )
      buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len )

   break;

cas de DSA :
      buffer := encode_in_network_byte_order ( HI.DSA.T , 1 )
      buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 )
      buffer += encode_in_network_byte_order ( HI.DSA.P , 64 + 8 * HI.DSA.T )
      buffer += encode_in_network_byte_order ( HI.DSA.G , 64 + 8 * HI.DSA.T )
      buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 + 8 * HI.DSA.T )

   break;
}

 	Appendice C.	Exemples de somme de contrôle pour paquets HIP

La somme de contrôle HIP pour les paquets HIP est spécifiée au paragraphe 5.1.1. Les sommes de contrôle pour les paquets TCP et UDP courant sur des associations de sécurité à capacité HIP sont spécifiées au paragraphe 4.5.1. Les exemples ci-dessous utilisent les adresses des [RFC3849] et [RFC5737], et les HIT avec le préfixe 2001:20 suivi par des zéros, suivi par un 1 ou 2 décimal, respectivement.

L'exemple suivant est défini seulement pour tester le calcul de somme de contrôle.

 	C.1	Exemple de HIP IPv6 (paquet I1)
Adresse de source : 	2001:db8::1
Adresse de destination : 	2001:db8::2
Longueur de paquet de couche supérieure :   	48	0x30
Prochain en-tête : 	139	0x8b
Protocole de charge utile : 	59	0x3b
Longueur d'en-tête :  	5	0x5
Type de paquet : 	1	0x1
Version : 	2	0x2
Réservé :  	1	0x1
Contrôle : 	0	0x0
Somme de contrôle : 	6750	0x1a5e
HIT d'envoyeur : 	2001:20::1
HIT de receveur : 	2001:20::2
Type de DH_GROUP_LIST :  	511	0x1ff
Longueur de DH_GROUP_LIST :  	3	0x3
Identifiants de groupe de DH_GROUP_LIST :  	3,4,8

 	C.2	Paquet HIP IPv4 (paquet I1)
La valeur de la somme de contrôle IPv4 pour l'exemple de paquet I1 est montré ci-dessous :

Adresse de source : 	192.0.2.1
Adresse de destination : 	192.0.2.2
Longueur de paquet de couche supérieure :	48	0x30
Prochain en-tête : 	139	0x8b
Protocole de charge utile : 	59 	0x3b
Longueur d'en-tête : 	5 	0x5
Type de paquet : 	1 	0x1
Version : 	2 	0x2
Réservé : 	1 	0x1
Contrôle : 	0 	0x0
Somme de contrôle :	61902	0xf1ce
HIT d'envoyeur : 	2001:20::1
HIT de receveur : 	2001:20::2
Type de DH_GROUP_LIST : 	511	0x1ff
Longueur de DH_GROUP_LIST : 	3	0x3
Identifiants de groupe de DH_GROUP_LIST : 	3,4,8

 	C.3	Segment TCP
Que ce soit avec IPv6 ou IPv4, les prises TCP et UDP utilisent le format de pseudo en-tête IPv6 [RFC2460], avec les HIT utilisées à la place des adresses IPv6.

HIT d'envoyeur : 	2001:20::1
HIT de receveur : 	2001:20::2
Longueur de paquet de couche supérieure : 	20	0x14
Prochain en-tête : 	6	0x06
Accès de source : 	65500	0xffdc
Accès de destination : 	22	0x0016
Numéro de séquence : 	1	0x00000001
Numéro d'accusé de réception : 	0	0x00000000
Décalage des données : 	5	0x5
Fanions :  	SYN 	0x02
Taille de fenêtre : 	65535	0xffff
Somme de contrôle : 	28586	0x6faa
Pointeur urgent :  	0	0x0000

 	Appendice D.	Groupes ECDH et ECDSA de 160 bits

Le groupe ECDH et ECDSA de 160 bits SECP160R1 est réglé à une force de 80 bits symétrique. Cela était considéré comme approprié pour une année de sécurité. Aujourd'hui, ces groupes ne devraient être utilisés que quand l'hôte n'est pas assez puissant (par exemple, des appareils incorporés) et quand les exigences de sécurité sont faibles (par exemple, lorsque la confidentialité à long terme n'est pas exigée).

 	Appendice E.	Suites HIT et génération de HIT

Une HIT comme ORCHID [RFC7343] comporte trois parties : un préfixe de 28 bits, un codage de 4 bits de l'algorithme de génération ORCHID (OGA, ORCHID generation algorithm), et un hachage qui inclut l'identité d'hôte et un identifiant de contexte. Le OGA est un indice qui pointe sur l'algorithme par lequel la clé publique et le codage haché de 96 bits sont générés. Le OGA est spécifique du protocole et est à interpréter comme défini ci-dessous pour tous les protocoles qui utilisent le même identifiant de contexte comme HIP. HIP groupe des ensembles de combinaisons valides de signature et d'algorithmes de hachage en suites HIT. Ces suites HIT sont accessibles par un indice, qui est transmis dans l'identifiant de champ OGA de l'ORCHID.

L'ensemble des suites HIT utilisées sera étendu pour contrer les progrès des capacités de calcul et les vulnérabilités des algorithmes employés. L'usage prévu des suites HIT est d'introduire une nouvelle suite HIT et d'en éliminer une vieille avant qu'elle ne devienne une source d'insécurité. Comme l'identifiant de champ OGA de 4 bits permet seulement que 15  suites HIT soient utilisée au même moment (la suite HIT avec l'identifiant 0 est réservée) les suites HIT périmées doivent être réutilisées à un certain moment. Dans ce cas, il va y avoir un retour à zéro de l'identifiant de suite HIT et la prochaine suite HIT nouvellement introduite va commencer avec un indice de suite HIT inférieur à celui de celle qui avait été introduite précédemment. Le retour au début déconseille effectivement la suite HIT réutilisée. Pour une transition en douceur, la suite HIT devrait être déconseillée longtemps avant que l'indice de suite HIT soit réutilisé.

Comme le nombre de suites HIT est strictement limité à 16, les suites HIT doit être allouées avec soin. Donc, les ensembles d'algorithmes convenables sont groupés dans une suite HIT.

La suite HIT de la HIT du répondant détermine le RHASH et la fonction de hachage à utiliser pour le HMAC dans les paquets HIP ainsi que la famille d'algorithmes de signature utilisés pour générer la HI. La liste des suites HIT est définie au Tableau 10.

 	Remerciements
L'impulsion de la création de HIP est née de la participation à la réunion MALLOC à la 43ème session de l'IETF. Baiju Patel et Hilarie Orman ont réellement donné à l'auteur d'origine, Bob Moskowitz, l'aide pour faire passer HIP au delà de cinq paragraphes d'idées. Il a considérablement mûri depuis les premières versions grâce aux apports des membres de l'IETF. Le plus important est que ses objectifs de conception ont été articulés et sont différents des autres efforts dans cette direction. Une mention particulière va aux membres du groupe de recherche sur l'espace de noms de l'IRTF. Noel Chiappa a fourni de précieux apports aux premiers stades des discussions sur le traitement d'identifiant et Keith Moore a donné l'impulsion pour fournir la résolvabilité. Steve Deering a fourni des encouragements pour poursuivre le travail, car une proposition solide peut agir comme une preuve d'idées pour un groupe de recherche.

De nombreux autres ont contribué ; Steve Bellovin a fourni de nombreux éléments relatifs à la sécurité. Rob Austein s'est occupé de la partie DNS. Paul Kocher à enseigné à Bob Moskowitz comment rendre coûteuse la réponse à l'échange de puzzle pour l'initiateur, mais facile à valider pour le répondant. Bill Sommerfeld a fourni le concept de l'anniversaire, qui a ensuite évolué en compteur de génération de R1, pour simplifier la gestion de réamorçage. Erik Nordmark a fourni le mécanisme CLOSE pour fermer les connexions. Rodney Thayer et Hugh Daniels ont fourni de nombreux retours. Dans les premiers temps de ce document, John Gilmore et Bob Moskowitz rivalisaient d'efforts pour fournir un document de valeur. Durant les dernières étapes du document, quand le relais de l'édition a été passé à Pekka Nikander, les retours des premières mises en œuvre a été précieux. Sans ces mises en œuvre réelles, le présent document n'aurait pu être au niveau où il est.

Comme il est de coutume à l'IETF, un grand nombre de personnes ont contribué au texte et aux idées. Ce sont Jeff Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Xin Gu, Rene Hummen, Miika Komu, Mika Kousa, Julien Laganier, Andrew McGregor, Jan Melen, Henrik Petander, Michael Richardson, Tim Shepard, Jorma Wall, et Jukka Ylitalo. Nos excuses à toute personne oubliée.

Une fois le groupe de travail HIP fondé au début 2004, un certain nombre de changements ont été introduits dans le fonctionnement du groupe. Le plus digne d'être noté est que le document d'origine a été coupé en deux, l'un contenant l'échange de base et l'autre définissant comment utiliser ESP. Certaines modifications au protocole proposées par Aura, et autres [AUR05] ont été ajoutées à un stade ultérieur.

 	Adresse des auteurs

Robert Moskowitz (editor)	Tobias Heer	Petri Jokela	
HTT Consulting	Hirschmann Automation et Control	Ericsson Research NomadicLab	
Oak Park, MI	Stuttgarter Strasse 45-51	Jorvas  FIN-02420	
United States	Neckartenzlingen  72654	Finland	
mél : rgm@labs.htt-consult.com 	Germany	téléphone : +358 9 299 1	
	mél : tobias.heer@belden.com	mél : petri.jokela@nomadiclab.com 	

Thomas R. Henderson
University of Washington
Campus Box 352500
Seattle, WA
United States
mél : tomhend@u.washington.edu