1.7. Significant Differences between RFC 4306 and RFC 5996
1.7 Significant Differences between RFC 4306 and RFC 5996
Ce document apporte des clarifications et des précisions à IKEv2 [IKEV2]. Beaucoup s'appuient sur [Clarif]. Les changements y listés ont été discutés dans le groupe de travail IPsec puis, après sa dissolution, sur la liste de diffusion IPsec. Ce document détaille des zones obscures d'IKEv2 et est utile aux implémenteurs.
Le protocole décrit ici conserve les numéros de version majeur (2) et mineur (0) du RFC 4306. Le numéro de version n'est pas modifié par rapport au RFC 4306. Les quelques changements techniques listés ici ne devraient pas affecter les déploiements RFC 4306 existants à la publication.
Les figures et références sont un peu plus cohérentes qu'en [IKEV2].
Les développeurs IKEv2 ont noté que les exigences de niveau SHOULD du RFC 4306 ne précisent souvent pas quand il est acceptable de ne pas les suivre. Il existe aussi des MUST sans lien avec l'interopérabilité. Ce document explique davantage certaines de ces exigences. Les emplois non capitalisés de SHOULD et MUST ont désormais leur sens anglais ordinaire, pas celui de [MUSTSHOULD].
Les développeurs IKEv2 (et IKEv1) ont noté la masse de matériel dans les tableaux de codes, section 3.10.1 du RFC 4306, ce qui privait le corps principal d'informations nécessaires. Une grande partie a été déplacée dans les sections correspondantes du corps.
Ce document supprime la discussion sur l'imbrication AH et ESP. C'était une erreur du RFC 4306 due au décalage entre la finalisation du RFC 4306 et le RFC 4301. IKEv2 repose sur le RFC 4301, qui n'inclut pas les « SA bundles » du RFC 2401. Un paquet peut subir IPsec plusieurs fois, mais chaque passage utilise une SA distincte, coordonnée par les tables de transfert. Chaque SA doit être créée par un échange CREATE_CHILD_SA séparé.
Ce document supprime INTERNAL_ADDRESS_EXPIRY, dont l'implémentation posait de graves problèmes. Les implémentations conformes DOIVENT ignorer les propositions avec l'attribut de configuration type 5 (ancienne valeur INTERNAL_ADDRESS_EXPIRY). INTERNAL_IP6_NBNS est aussi retiré des attributs de configuration.
Ce document supprime la possibilité de rejeter des messages dont les charges ne sont pas dans le « bon » ordre ; les implémentations NE DOIVENT PAS les rejeter, faute de clarté sur ces ordres.
Les listes issues du RFC 4306 dans le registre IANA ont été réduites aux éléments réellement définis dans le RFC 4306. De nombreuses listes sont précédées d'un rappel aux développeurs de consulter le registre IANA au moment du développement, de nouveaux éléments ayant été ajoutés depuis.
Des précisions sont ajoutées sur le chiffrement ou non des notifications selon l'état de la négociation.
Ce document approfondit la négociation des chiffres en mode combiné.
À la section 1.3.2, « The KEi payload SHOULD be included » devient « The KEi payload MUST be included », avec des changements en section 2.18.
La section 2.1 contient du nouveau matériel sur l'utilisation du SPI et/ou de l'IP de l'initiator pour distinguer une IKE SA « half-open » d'une nouvelle requête.
Le drapeau critical est clarifié en section 2.5.
En section 2.8, « Note that, when rekeying, the new Child SA MAY have different Traffic Selectors and algorithms than the old one » devient « Note that, when rekeying, the new Child SA SHOULD NOT have different Traffic Selectors and algorithms than the old one ».
La nouvelle section 2.8.2 traite du rekey simultané des IKE SA.
La section 2.13 impose que toutes les PRF utilisées avec IKEv2 acceptent des clés de taille variable. Aucune PRF normalisée à clé fixe n'existait, donc l'impact devrait être nul.
La section 2.18 exige un échange Diffie-Hellman lors du rekey de l'IKE_SA. Le RFC 4306 permettait en théorie un DH optionnel, peu utile ni approprié pour le rekey IKE_SA.
La section 2.21 a été largement étendue pour les cas d'erreur et les réponses appropriées.
La section 2.23 précise qu'en traversée NAT, la réception doit gérer à la fois les paquets IPsec encapsulés UDP et non encapsulés.
La section 2.23.1 décrit la traversée NAT en mode transport demandé.
La section 2.25 explique les collisions temporelles lors de suppressions et/ou rekeys de SA, avec deux nouvelles notifications TEMPORARY_FAILURE et CHILD_SA_NOT_FOUND.
En section 3.6, il est ajouté : « Implementations MUST support the http: scheme for hash-and-URL lookup. The behavior of other URL schemes is not currently specified, and such schemes SHOULD NOT be used in the absence of a document specifying them ».
En section 3.15.3, un pointeur vers un nouveau document sur la configuration d'adresses IPv6 est ajouté.
L'annexe C est étendue et clarifiée.