1.7. Differenze significative tra RFC 4306 e questo documento

Questo documento contiene chiarimenti e ampliamenti a IKEv2 [IKEV2]. Molti dei chiarimenti si basano su [Clarif]. Le modifiche elencate in quel documento sono state discusse nel Working Group IPsec e, dopo lo scioglimento del Working Group, sulla mailing list IPsec. Quel documento contiene spiegazioni dettagliate di aree che erano poco chiare in IKEv2, ed è quindi utile per gli implementatori di IKEv2.

Il protocollo descritto in questo documento mantiene lo stesso numero di versione maggiore (2) e numero di versione minore (0) utilizzato in RFC

4306. Cioè, il numero di versione non è cambiato rispetto a RFC

Il piccolo numero di modifiche tecniche elencate qui non dovrebbe influire sulle implementazioni RFC 4306 già distribuite al momento della pubblicazione di questo documento.

Questo documento rende le figure e i riferimenti un po' più coerenti di quanto non fossero in [IKEV2].

Gli sviluppatori IKEv2 hanno notato che i requisiti di livello SHOULD in RFC 4306 sono spesso poco chiari in quanto non dicono quando è lecito non obbedire ai requisiti. Hanno anche notato che ci sono requisiti di livello MUST che non sono correlati all'interoperabilità. Questo documento ha una spiegazione maggiore di alcuni di questi requisiti. Tutti gli usi non maiuscoli delle parole SHOULD e MUST ora significano il loro senso normale in inglese, non il senso di interoperabilità di [MUSTSHOULD].

Gli sviluppatori IKEv2 (e IKEv1) hanno notato che c'è molto materiale nelle tabelle dei codici nella Sezione 3.10.1 in RFC 4306. Questo porta gli implementatori a non avere tutte le informazioni necessarie nel corpo principale del documento. Gran parte del materiale di quelle tabelle è stato spostato nelle parti associate del corpo principale del documento.

Questo documento rimuove la discussione sull'annidamento di AH e ESP. Questo era un errore in RFC 4306 causato dal ritardo tra il completamento di RFC 4306 e RFC 4301. Sostanzialmente, IKEv2 si basa su RFC 4301, che non include i "SA bundle" che facevano parte di RFC 2401. Sebbene un singolo pacchetto possa attraversare l'elaborazione IPsec più volte, ciascuno di questi passaggi utilizza una SA separata, e i passaggi sono coordinati dalle tabelle di inoltro. In IKEv2, ciascuna di queste SAs deve essere creata utilizzando un separato scambio CREATE_CHILD_SA.

Questo documento rimuove la discussione sull'attributo di configurazione INTERNAL_ADDRESS_EXPIRY perché la sua implementazione era molto problematica. Le implementazioni conformi a questo documento DEVONO ignorare le proposte che hanno l'attributo di configurazione di tipo 5, il vecchio valore per INTERNAL_ADDRESS_EXPIRY. Questo documento ha inoltre rimosso INTERNAL_IP6_NBNS come attributo di configurazione.

Questo documento rimuove la possibilità di rifiutare messaggi in cui i payload non erano nell'ordine "corretto"; ora le implementazioni NON DEVONO rifiutarli. Questo è dovuto alla mancanza di chiarezza dove gli ordini per i payload sono descritti.

Gli elenchi di voci da RFC 4306 che sono finiti nel registro IANA sono stati ridotti per includere solo le voci effettivamente definite in RFC

4306. Inoltre, molti di questi elenchi ora sono preceduti

dall'importante istruzione agli sviluppatori che dovrebbero davvero consultare il registro IANA al momento dello sviluppo perché nuove voci sono state aggiunte da RFC 4306.

Questo documento aggiunge chiarimenti su quando le notifiche sono e non sono inviate cifrate, a seconda dello stato della negoziazione al momento.

Questo documento discute maggiormente come negoziare cifrari in modalità combinata.

Nella Sezione 1.3.2, "The KEi payload SHOULD be included" è stato cambiato in "The KEi payload MUST be included". Questo ha anche portato a modifiche nella Sezione 2.18.

Nella Sezione 2.1, c'è nuovo materiale che copre come lo SPI e/o l'IP dell'iniziatore viene utilizzato per differenziare se questo è una IKE SA "a metà aperta" o una nuova richiesta.

Questo documento chiarisce l'uso del flag critico nella Sezione 2.5.

Nella Sezione 2.8, "Note that, when rekeying, the new Child SA MAY have different Traffic Selectors and algorithms than the old one" è stato cambiato in "Note that, when rekeying, the new Child SA SHOULD NOT have different Traffic Selectors and algorithms than the old one".

La nuova Sezione 2.8.2 copre il rekeying simultaneo della IKE SA.

La nuova Sezione 2.9.2 copre i Traffic Selector nel rekeying.

Questo documento aggiunge la restrizione nella Sezione 2.13 che tutte le funzioni pseudo-casuali (PRF) utilizzate con IKEv2 DEVONO accettare chiavi di dimensione variabile. Questo non dovrebbe influire su alcuna implementazione perché non c'erano PRF standardizzate con chiavi di dimensione fissa.

La Sezione 2.18 richiede di effettuare uno scambio Diffie-Hellman quando si riesegue il rekeying della IKE_SA. In teoria, RFC 4306 consentiva una politica in cui lo scambio Diffie-Hellman era opzionale, ma questo non era utile (né appropriato) durante il rekeying della IKE_SA.

La Sezione 2.21 è stata notevolmente ampliata per coprire i diversi casi in cui sono necessarie risposte di errore e le risposte appropriate a queste.

La Sezione 2.23 ha chiarito che, nel NAT traversal, ora sia i pacchetti IPsec incapsulati in UDP che quelli non incapsulati in UDP devono essere compresi alla ricezione.

Aggiunta la Sezione 2.23.1 per descrivere il NAT traversal quando è richiesta la modalità transport.

Aggiunta la Sezione 2.25 per spiegare come agire quando ci sono collisioni di tempistica nell'eliminazione e/o nel rekeying delle SAs, e sono state definite due nuove notifiche di errore (TEMPORARY_FAILURE e CHILD_SA_NOT_FOUND).

Nella Sezione 3.6, è stato aggiunto "Le implementazioni DEVONO supportare il metodo HTTP per la ricerca hash-and-URL. Il comportamento di altri metodi URL non è attualmente specificato, e tali metodi NON DOVREBBERO essere utilizzati in assenza di un documento che li specifichi".

Nella Sezione 3.15.3, è stato aggiunto un puntatore a un nuovo documento relativo alla configurazione degli indirizzi IPv6.

L'Appendice C è stata ampliata e chiarita.