2.5. Version Numbers and Forward Compatibility (Numeri di versione e compatibilità in avanti)
2.5. Version Numbers and Forward Compatibility (Numeri di versione e compatibilità in avanti)
Questo documento descrive IKE versione 2.0 (maggiore 2, minore 0) e sostituisce [IKEV2]. Alcune implementazioni vorranno supportare 1.0 e 2.0 e versioni future.
Il numero maggiore va incrementato solo se formati o azioni richieste cambiano così tanto che un nodo vecchio non potrebbe interoperare ignorando i campi sconosciuti. Il minore indica nuove capacità: un nodo con minore inferiore DEVE ignorarlo; con minore superiore può usarlo informativamente (es. nuovo tipo di Notify).
Se la versione maggiore ricevuta è superiore, l'endpoint DEVE scartare il messaggio e DOVREBBE inviare Notify non autenticato INVALID_MAJOR_VERSION con la versione più alta supportata. Se supporta i maggiori n e m, DEVE supportare tutte le versioni tra n e m. Per un maggiore supportato, la risposta DEVE usare quel maggiore. Un flag indica capacità di parlare una versione maggiore più alta per evitare downgrade ingannevoli.
Il maggiore nell'intestazione IKE è quello del messaggio, non il massimo supportato dal trasmettitore. Se negoziano erroneamente una versione più bassa pur potendo entrambi di più, DEVONO interrompere e riconnettersi con la versione superiore.
IKEv1 non segue queste regole; un attaccante può far parlare due nodi v2 in v1; va annotato nei log.
Per compatibilità futura, i campi RESERVED DEVONO essere zero in 2.0 e ignorati in 2.0 [IP]. I tipi di payload non definiti sono riservati; le implementazioni DEVONO saltarli e ignorarne il contenuto.
IKEv2 aggiunge il flag « critical »: se critical è impostato e il tipo è sconosciuto, il messaggio DEVE essere rifiutato e la risposta DEVE includere UNSUPPORTED_CRITICAL_PAYLOAD con l'ottetto del tipo nei dati. Senza critical e tipo non supportato, ignorare il payload. I payload di risposta NON DEVONO avere critical. Se il tipo è riconosciuto ma il contenuto no, critical è ignorato.
Nuovi tipi di payload possono essere intercalati; le implementazioni DOVREBBERO inviare nell'ordine delle figure delle Sezioni 1 e 2, ma NON DEVONO rifiutare altri ordini come non validi.