1.7. Différences significatives entre le RFC 4306 et ce document

1.7. Différences significatives entre le RFC 4306 et ce document

Ce document contient des clarifications et des amplifications d'IKEv2 [IKEV2]. Un grand nombre des clarifications sont fondées sur [Clarif]. Les changements énumérés dans ce document ont été discutés au sein de l'IPsec Working Group et, après la dissolution du groupe de travail, sur la liste de diffusion IPsec. Ce document contient des explications détaillées des domaines qui n'étaient pas clairs dans IKEv2, et est donc utile aux implémenteurs d'IKEv2.

Le protocole décrit dans ce document conserve le même numéro de version majeure (2) et le même numéro de version mineure (0) que ceux utilisés dans le RFC

4306. C'est-à-dire que le numéro de version n'est pas modifié par rapport

au RFC 4306. Le petit nombre de changements techniques énumérés ici ne devrait pas affecter les implémentations du RFC 4306 qui avaient déjà été déployées au moment de la publication de ce document.

Ce document rend les figures et les références un peu plus cohérentes qu'elles ne l'étaient dans [IKEV2].

Les développeurs d'IKEv2 ont noté que les exigences de niveau SHOULD du RFC 4306 sont souvent peu claires dans la mesure où elles ne précisent pas quand il est acceptable de ne pas obéir aux exigences. Ils ont également noté qu'il existe des exigences de niveau MUST qui ne sont pas liées à l'interopérabilité. Ce document fournit davantage d'explications sur certaines de ces exigences. Toutes les utilisations non capitalisées des mots SHOULD et MUST signifient désormais leur sens anglais normal, et non le sens d'interopérabilité de [MUSTSHOULD].

Les développeurs d'IKEv2 (et d'IKEv1) ont noté qu'il existe une grande quantité de matériel dans les tableaux de codes de la section 3.10.1 du RFC 4306. Cela conduit les implémenteurs à ne pas disposer de toutes les informations nécessaires dans le corps principal du document. Une grande partie du matériel de ces tableaux a été déplacée vers les parties associées du corps principal du document.

Ce document supprime la discussion sur l'imbrication d'AH et d'ESP. Il s'agissait d'une erreur du RFC 4306 causée par le décalage entre la finalisation du RFC 4306 et du RFC 4301. Fondamentalement, IKEv2 est fondé sur le RFC 4301, qui n'inclut pas les « paquets de SA » (SA bundles) qui faisaient partie du RFC 2401. Bien qu'un seul paquet puisse passer plusieurs fois par le traitement IPsec, chacune de ces passes utilise une SA distincte, et les passes sont coordonnées par les tables de transfert. Dans IKEv2, chacune de ces SA doit être créée à l'aide d'un échange CREATE_CHILD_SA distinct.

Ce document supprime la discussion sur l'attribut de configuration INTERNAL_ADDRESS_EXPIRY car son implémentation était très problématique. Les implémentations conformes à ce document DOIVENT ignorer les propositions qui ont l'attribut de configuration de type 5, l'ancienne valeur d'INTERNAL_ADDRESS_EXPIRY. Ce document a également supprimé INTERNAL_IP6_NBNS en tant qu'attribut de configuration.

Ce document supprime l'autorisation de rejeter les messages dans lesquels les charges utiles n'étaient pas dans l'ordre « correct » ; désormais, les implémentations NE DOIVENT PAS les rejeter. Cela est dû au manque de clarté concernant les endroits où les ordres des charges utiles sont décrits.

Les listes d'éléments du RFC 4306 qui ont abouti dans le registre IANA ont été réduites pour n'inclure que les éléments qui étaient effectivement définis dans le RFC # 4306. De plus, beaucoup de ces listes sont désormais précédées de l'instruction très importante à l'intention des développeurs selon laquelle ils devraient réellement consulter le registre IANA au moment du développement, car de nouveaux éléments ont été ajoutés depuis le RFC 4306.

Ce document ajoute des clarifications sur le moment où les notifications sont ou ne sont pas envoyées chiffrées, en fonction de l'état de la négociation à ce moment-là.

Ce document aborde davantage la manière de négocier les chiffreurs en mode combiné.

Dans la section 1.3.2, « La charge utile KEi DEVRAIT être incluse » a été changé en « La charge utile KEi DOIT être incluse ». Cela a également conduit à des changements dans la section 2.18.

Dans la section 2.1, un nouveau matériel couvre la manière dont le SPI et/ou l'adresse IP de l'initiateur est utilisé pour différencier s'il s'agit d'une SA IKE « à demi ouverte » ou d'une nouvelle requête.

Ce document clarifie l'utilisation du drapeau critique dans la section 2.5.

Dans la section 2.8, « Notez que, lors du renouvellement, la nouvelle SA enfant PEUT avoir des sélecteurs de trafic et des algorithmes différents de ceux de l'ancienne » a été changé en « Notez que, lors du renouvellement, la nouvelle SA enfant NE DEVRAIT PAS avoir des sélecteurs de trafic et des algorithmes différents de ceux de l'ancienne ».

La nouvelle section 2.8.2 couvre le renouvellement simultané de la SA IKE.

La nouvelle section 2.9.2 couvre les sélecteurs de trafic lors du renouvellement.

Ce document ajoute la restriction dans la section 2.13 selon laquelle toutes les fonctions pseudo-aléatoires (PRF) utilisées avec IKEv2 DOIVENT accepter des clés de taille variable. Cela ne devrait pas affecter les implémentations car il n'existait aucune PRF normalisée à clés de taille fixe.

La section 2.18 exige d'effectuer un échange Diffie-Hellman lors du renouvellement de l'IKE_SA. En théorie, le RFC 4306 autorisait une politique où l'échange Diffie-Hellman était facultatif, mais cela n'était pas utile (ni approprié) lors du renouvellement de l'IKE_SA.

La section 2.21 a été considérablement développée pour couvrir les différents cas où des réponses d'erreur sont nécessaires et les réponses appropriées à leur égard.

La section 2.23 a clarifié que, dans la traversée NAT, désormais à la fois les paquets IPsec encapsulés en UDP et les paquets IPsec non encapsulés en UDP doivent être compris lors de la réception.

Une section 2.23.1 a été ajoutée pour décrire la traversée NAT lorsque le mode transport est demandé.

Une section 2.25 a été ajoutée pour expliquer comment agir en cas de collisions de synchronisation lors de la suppression et/ou du renouvellement de SA, et deux nouvelles notifications d'erreur (TEMPORARY_FAILURE et CHILD_SA_NOT_FOUND) ont été définies.

Dans la section 3.6, « Les implémentations DOIVENT prendre en charge la méthode HTTP pour la recherche de hachage-et-URL. Le comportement des autres méthodes d'URL n'est actuellement pas spécifié, et ces méthodes NE DEVRAIENT PAS être utilisées en l'absence d'un document les spécifiant » a été ajouté.

Dans la section 3.15.3, un pointeur vers un nouveau document lié à la configuration des adresses IPv6 a été ajouté.

L'appendice C a été développé et clarifié.