Appendix A. Summary of Changes from IKEv1 (Résumé des changements par rapport à IKEv1)

Appendix A. Summary of Changes from IKEv1 (Résumé des changements par rapport à IKEv1)

Les objectifs de cette révision d'Internet Key Exchange (échange de clés Internet, IKE) sont les suivants :

1. Définir l'intégralité du protocole IKE dans un seul document, en remplaçant les RFC 2407, 2408 et 2409 et en intégrant les changements ultérieurs pour prendre en charge le traversal NAT (Network Address Translation), l'Extensible Authentication Protocol (protocole d'authentification extensible) et l'acquisition d'adresse distante ;

2. Simplifier IKE en remplaçant les huit échanges initiaux différents par un seul échange en quatre messages (les changements des mécanismes d'authentification n'affectant qu'un seul payload AUTH plutôt que de restructurer l'échange entier), voir [EXCHANGEANALYSIS] ;

3. Supprimer les champs Domain of Interpretation (DOI), Situation (SIT) et Labeled Domain Identifier (identificateur de domaine étiqueté), ainsi que les bits Commit (engagement) et Authentication only (authentification seule) ;

4. Réduire la latence d'IKE dans le cas courant en faisant de l'échange initial 2 allers-retours (4 messages), et en permettant de greffer (piggyback) l'établissement d'une Child Security Association (association de sécurité enfant, Child SA) sur cet échange ;

5. Remplacer la syntaxe cryptographique protégeant les messages IKE eux-mêmes par une syntaxe étroitement calquée sur Encapsulating Security Payload (ESP) afin de simplifier l'implémentation et l'analyse de sécurité ;

6. Réduire le nombre d'états d'erreur possibles en rendant le protocole fiable (tous les messages sont acquittés) et séquencé. Cela permet de raccourcir les échanges CREATE_CHILD_SA de 3 messages à 2 ;

7. Accroître la robustesse en permettant au répondeur de ne pas effectuer de traitement significatif tant qu'il n'a pas reçu un message prouvant que l'initiateur peut recevoir des messages à l'adresse IP qu'il déclare ;

8. Corriger des faiblesses cryptographiques telles que le problème des symétries dans les hachages utilisés pour l'authentification (documenté par Tero Kivinen) ;

9. Spécifier les Traffic Selectors (sélecteurs de trafic) dans leur propre type de payload plutôt que de surcharger les payloads ID, et rendre plus flexibles les Traffic Selectors pouvant être spécifiés ;

10. Spécifier le comportement requis dans certaines conditions d'erreur ou lorsque des données non comprises sont reçues, afin de faciliter les révisions futures sans rompre la compatibilité ascendante ;

11. Simplifier et clarifier le maintien de l'état partagé en présence de défaillances réseau et d'attaques par déni de service (DoS) ; et

12. Conserver autant que possible la syntaxe existante et les nombres magiques (magic numbers), afin qu'il soit probable que les implémentations d'IKEv1 puissent être étendues pour prendre en charge IKEv2 avec un effort minimal.