2.5. Version Numbers and Forward Compatibility
2.5. Version Numbers and Forward Compatibility
Ce document décrit IKE version 2.0 (majeur 2, mineur 0) et remplace [IKEV2]. Certaines implémentations voudront supporter 1.0 et 2.0, et d'autres versions à l'avenir.
Le numéro majeur ne devrait augmenter que si les formats ou actions requis changent au point qu'un nœud ancien ne pourrait pas interopérer avec un nœud récent en ignorant les champs inconnus. Le mineur indique de nouvelles capacités : un nœud au mineur inférieur DOIT l'ignorer ; un nœud au mineur supérieur peut l'utiliser à titre informatif (ex. : nouveau type de Notify). Le nœud au mineur supérieur saura que son correspondant ne comprendra pas certains messages et ne les enverra pas.
Si la version majeure reçue est supérieure, l'extrémité DOIT abandonner le message et DEVRAIT envoyer un Notify non authentifié INVALID_MAJOR_VERSION avec la plus haute version supportée. Si elle supporte les majeurs n et m, elle DOIT supporter toutes les versions entre n et m. Pour une version majeure supportée, la réponse DOIT utiliser ce numéro majeur. Un drapeau indique la capacité de parler une version majeure plus élevée afin d'éviter qu'un attaquant force une version trop basse.
Le majeur dans l'en-tête IKE est celui du message, pas le maximum supporté par l'émetteur. Si l'initiateur parle n, n+1, n+2 et le répondant n et n+1, ils négocient n+1 avec drapeau de capacité supérieure. S'ils tombent à n par erreur ou attaque, ils DOIVENT rompre et se reconnecter en n+1.
IKEv1 ne suit pas ces règles (pas de signal de version supérieure) : un attaquant peut forcer deux nœuds v2 à parler v1. Les nœuds v2 devraient journaliser une telle dégradation.
Pour la compatibilité future, les champs RESERVED DOIVENT être mis à zéro en 2.0 et ignorés en 2.0 (« soyez conservateurs en émission, libéraux en réception » [IP]). Les types de charge non définis sont réservés ; les implémentations DOIVENT les sauter et ignorer leur contenu.
IKEv2 ajoute un drapeau « critical » sur chaque en-tête de charge. Si critical est positionné et le type inconnu, le message DOIT être rejeté et la réponse DOIT inclure UNSUPPORTED_CRITICAL_PAYLOAD avec l'octet de type dans les données de notification. Si critical est absent et le type non supporté, la charge DOIT être ignorée. Les réponses NE DOIVENT PAS avoir critical. Si le type est reconnu mais le contenu inconnu (transform inconnue dans une SA, type de Notify inconnu), critical est ignoré.
De nouveaux types de charges pourront être entrelacés ; les implémentations DEVRAIENT envoyer les charges dans l'ordre des figures des Sections 1 et 2, mais NE DOIVENT PAS rejeter un autre ordre comme invalide.