2.5. Numeri di versione e compatibilità con le versioni future
2.5. Numeri di versione e compatibilità con le versioni future
Questo documento descrive la versione 2.0 di IKE, il che significa che il numero di versione principale è 2 e il numero di versione minore è 0. Questo documento è un sostituto di [IKEV2]. È probabile che alcune implementazioni vorranno supportare la versione 1.0 e la versione 2.0, e in futuro, altre versioni.
Il numero di versione principale dovrebbe essere incrementato solo se i formati dei pacchetti o le azioni richieste sono cambiati in modo così drastico che un nodo con una versione più vecchia non sarebbe in grado di interoperare con un nodo con una versione più nuova se semplicemente ignorasse i campi che non capisce e intraprendesse le azioni specificate nella specifica più vecchia. Il numero di versione minore indica nuove capacità, e DEVE essere ignorato da un nodo con un numero di versione minore più piccolo, ma usato a scopo informativo dal nodo con il numero di versione minore più grande. Per esempio, potrebbe indicare la capacità di elaborare un tipo di messaggio Notify appena definito. Il nodo con il numero di versione minore più grande noterebbe semplicemente che il suo corrispondente non sarebbe in grado di capire quel messaggio e quindi non lo invierebbe.
Se un endpoint riceve un messaggio con un numero di versione principale più alto, DEVE scartare il messaggio e DOVREBBE inviare un messaggio Notify non autenticato di tipo INVALID_MAJOR_VERSION contenente il numero di versione più alto (più vicino) che supporta. Se un endpoint supporta la versione principale n e la versione principale m, DEVE supportare tutte le versioni comprese tra n e m. Se riceve un messaggio con una versione principale che supporta, DEVE rispondere con quel numero di versione. Per impedire a due nodi di essere indotti a comunicare con un numero di versione principale più basso del massimo che entrambi supportano, IKE ha un flag che indica che il nodo è in grado di parlare un numero di versione principale più alto.
Quindi, il numero di versione principale nell'header IKE indica il numero di versione del messaggio, non il numero di versione più alto che il trasmettitore supporta. Se l'iniziatore è in grado di parlare le versioni n, n+1 e n+2, e il risponditore è in grado di parlare le versioni n e n+1, allora negozieranno di parlare n+1, dove l'iniziatore imposterà un flag che indica la sua capacità di parlare una versione più alta. Se erroneamente (forse attraverso un attaccante attivo che invia messaggi di errore) negoziano la versione n, allora entrambi noteranno che l'altra parte può supportare un numero di versione più alto, e DEVONO interrompere la connessione e riconnettersi usando la versione n+1.
Si noti che IKEv1 non segue queste regole, perché in v1 non c'è modo di segnalare che sei in grado di parlare un numero di versione più alto. Quindi un attaccante attivo può indurre due nodi capaci di v2 a parlare v1. Quando un nodo capace di v2 negozia al ribasso fino a v1, dovrebbe annotare quel fatto nei suoi log.
Inoltre, per la compatibilità con le versioni future, tutti i campi marcati RESERVED DEVONO essere impostati a zero da un'implementazione che esegue la versione 2.0, e il loro contenuto DEVE essere ignorato da un'implementazione che esegue la versione 2.0 ("Sii conservativo in ciò che invii e liberale in ciò che ricevi" [IP]). In questo modo, le versioni future del protocollo possono usare quei campi in un modo che è garantito essere ignorato dalle implementazioni che non
li capiscono. Allo stesso modo, i tipi di payload che non sono definiti sono riservati per uso futuro; le implementazioni di una versione in cui sono indefiniti DEVONO saltare oltre quei payload e ignorare i loro contenuti.
IKEv2 aggiunge un flag "critical" a ciascun header di payload per una maggiore flessibilità per la compatibilità con le versioni future. Se il flag critical è impostato e il tipo di payload non è riconosciuto, il messaggio DEVE essere rifiutato e la risposta alla richiesta IKE che contiene quel payload DEVE includere un payload Notify UNSUPPORTED_CRITICAL_PAYLOAD, indicando che è stato incluso un payload critico non supportato. In quel payload Notify, i dati di notifica contengono il tipo di payload di un ottetto. Se il flag critical non è impostato e il tipo di payload non è supportato, quel payload DEVE essere ignorato. I payload inviati nei messaggi di risposta IKE NON DEVONO avere il flag critical impostato. Si noti che il flag critical si applica solo al tipo di payload, non al contenuto. Se il tipo di payload è riconosciuto, ma il payload contiene qualcosa che non lo è (come un transform sconosciuto all'interno di un payload SA, o un Message Type Notify sconosciuto all'interno di un payload Notify), il flag critical viene ignorato.
Sebbene nuovi tipi di payload possano essere aggiunti in futuro e possano apparire intervallati con i campi definiti in questa specifica, le implementazioni DOVREBBERO inviare i payload definiti in questa specifica nell'ordine mostrato nelle figure delle Sezioni 1 e 2; le implementazioni NON DEVONO rifiutare come non valido un messaggio con quei payload in qualsiasi altro ordine.