2.5. Numéros de version et compatibilité ascendante
2.5. Numéros de version et compatibilité ascendante
Ce document décrit la version 2.0 de IKE, ce qui signifie que le numéro de version majeur est 2 et le numéro de version mineur est 0. Ce document remplace [IKEV2]. Il est probable que certaines implémentations voudront supporter la version 1.0 et la version 2.0, et à l'avenir, d'autres versions.
Le numéro de version majeur ne doit être incrémenté que si les formats de paquets ou les actions requises ont changé si dramatiquement qu'un nœud de version plus ancienne ne serait pas capable d'interopérer avec un nœud de version plus récente s'il ignorait simplement les champs qu'il ne comprenait pas et prenait les actions spécifiées dans la spécification plus ancienne. Le numéro de version mineur indique de nouvelles capacités, et DOIT être ignoré par un nœud avec un numéro de version mineur plus petit, mais utilisé à des fins d'information par le nœud avec le numéro de version mineur plus grand. Par exemple, il pourrait indiquer la capacité à traiter un type de message Notify nouvellement défini. Le nœud avec le numéro de version mineur plus grand noterait simplement que son correspondant ne serait pas capable de comprendre ce message et ne l'enverrait donc pas.
Si un point final reçoit un message avec un numéro de version majeur plus élevé, il DOIT abandonner le message et DEVRAIT envoyer un message Notify non authentifié de type INVALID_MAJOR_VERSION contenant le plus haut (le plus proche) numéro de version qu'il supporte. Si un point final supporte la version majeure n, et la version majeure m, il DOIT supporter toutes les versions entre n et m. S'il reçoit un message avec une version majeure qu'il supporte, il DOIT répondre avec ce numéro de version. Afin d'empêcher deux nœuds d'être induits en erreur pour correspondre avec un numéro de version majeur plus bas que le maximum qu'ils supportent tous deux, IKE a un drapeau qui indique que le nœud est capable de parler un numéro de version majeur plus élevé.
Ainsi, le numéro de version majeur dans l'en-tête IKE indique le numéro de version du message, et non le plus haut numéro de version que le émetteur supporte. Si l'initiateur est capable de parler les versions n, n+1, et n+2, et que le répondeur est capable de parler les versions n et n+1, alors ils négocieront de parler n+1, où l'initiateur définira un drapeau indiquant sa capacité à parler une version plus élevée. S'ils négocient par erreur (peut-être via un attaquant actif envoyant des messages d'erreur) vers la version n, alors les deux remarqueront que l'autre côté peut supporter un numéro de version plus élevé, et ils DOIVENT rompre la connexion et se reconnecter en utilisant la version n+1.
Notez que IKEv1 ne suit pas ces règles, car il n'y a aucun moyen en v1 de noter que vous êtes capable de parler une version plus élevée. Ainsi, un attaquant actif peut induire deux nœuds capables de v2 à parler v1. Lorsqu'un nœud capable de v2 négocie vers v1, il devrait noter ce fait dans ses journaux.
Aussi, pour la compatibilité ascendante, tous les champs marqués RESERVED DOIVENT être mis à zéro par une implémentation exécutant la version 2.0, et leur contenu DOIT être ignoré par une implémentation exécutant la version 2.0 (« Soyez conservateur dans ce que vous envoyez et libéral dans ce que vous recevez » [IP]). De cette façon, les versions futures du protocole peuvent utiliser ces champs d'une manière garantie d'être ignorée par les implémentations qui ne les comprennent pas. De même, les types de payload non définis sont réservés pour un usage futur ; les implémentations d'une version où ils sont indéfinis DOIVENT sauter ces payloads et ignorer leur contenu.
IKEv2 ajoute un drapeau « critique » à chaque en-tête de payload pour une plus grande flexibilité de compatibilité ascendante. Si le drapeau critique est défini et que le type de payload n'est pas reconnu, le message DOIT être rejeté et la réponse à la requête IKE contenant ce payload DOIT inclure un payload Notify UNSUPPORTED_CRITICAL_PAYLOAD, indiquant qu'un payload critique non supporté a été inclus. Dans ce payload Notify, les données de notification contiennent le type de payload d'un octet. Si le drapeau critique n'est pas défini et que le type de payload n'est pas supporté, ce payload DOIT être ignoré. Les payloads envoyés dans les messages de réponse IKE NE DOIVENT PAS avoir le drapeau critique défini. Notez que le drapeau critique s'applique uniquement au type de payload, et non au contenu. Si le type de payload est reconnu, mais que le payload contient quelque chose qui ne l'est pas (comme une transform inconnue à l'intérieur d'un payload SA, ou un type de message Notify inconnu à l'intérieur d'un payload Notify), le drapeau critique est ignoré.
Bien que de nouveaux types de payload puissent être ajoutés à l'avenir et apparaître entrelacés avec les champs définis dans cette spécification, les implémentations DEVRAIENT envoyer les payloads définis dans cette spécification dans l'ordre montré dans les figures des Sections 1 et 2 ; les implémentations NE DOIVENT PAS rejeter comme invalide un message avec ces payloads dans un ordre différent.