2.23. NAT Traversal

Questa sezione descrive i meccanismi che le implementazioni IKEv2 DEVONO supportare per garantire l'interoperabilità attraverso i NAT (Network Address Translators). I nomi dei messaggi, delle trasformazioni e delle notifiche definiti in questa sezione figurano nel registry IANA "IKEv2 Parameters" (vedere la sezione 2.23.4).

2.23.1. Rilevamento delle capacità NAT

Quando entrambi i peer supportano il NAT traversal, DOVREBBERO includere il payload di notifica NAT_DETECTION_SOURCE_IP o NAT_DETECTION_DESTINATION_IP nei messaggi IKE_SA_INIT. L'iniziatore e il risponditore DOVREBBERO inviare il payload NAT_DETECTION_SOURCE_IP. L'iniziatore DOVREBBE inviare il payload NAT_DETECTION_DESTINATION_IP, e il risponditore DOVREBBE inviarlo se il suo indirizzo è cambiato dall'invio del messaggio IKE_SA_INIT.

Il contenuto di questi payload di notifica è il seguente hash degli indirizzi e delle porte di origine o destinazione del pacchetto:

NAT_DETECTION_SOURCE_IP = HASH(Address of Initiator | Port of Initiator) NAT_DETECTION_DESTINATION_IP = HASH(Address of Responder | Port of Responder)

dove l'indirizzo e la porta sono quelli utilizzati per inviare il pacchetto contenente il messaggio IKE_SA_INIT, e l'algoritmo di hash è la prf definita dal gruppo di trasformazione Pseudo-random Function della Proposal 2.1.1. L'uso di prf come funzione di hash garantisce che solo le parti in possesso della chiave SK_e possano verificare questi valori.

Se gli hash calcolati dall'iniziatore e dal risponditore differiscono, si suppone che sia presente un NAT. Se gli hash coincidono, si suppone che non sia presente alcun NAT.

2.23.2. Parametri di NAT traversal

Se viene rilevato un NAT, o i peer si aspettano di incontrarne uno, si applicano i seguenti parametri:

o I messaggi IKE DEVONO essere inviati sulla porta UDP 4500.

o I messaggi IKE DEVONO essere incapsulati in UDP con un header che include quattro ottetti di zeri come prefisso.

o I payload ESP e AH DEVONO essere incapsulati in UDP (cioè, NAT traversal UDP-ESP, [UDPENCAP]).

o Le implementazioni DEVONO essere pronte a ricevere messaggi IKE sulla porta UDP 4500 con o senza il prefisso di quattro ottetti di zeri, ma DOVREBBERO accettare messaggi sulla porta 500 o 4500 senza prefisso.

2.23.3. Gestione delle modifiche di indirizzo

Se un'implementazione riceve un pacchetto su un indirizzo o una porta diversi da quelli attesi, DEVE trattarlo come un'indicazione di cambiamento di indirizzo. DOVREBBE quindi inviare notifiche NAT_DETECTION_SOURCE_IP e NAT_DETECTION_DESTINATION_IP per rilevare eventuali modifiche e, se necessario, aggiornare le proprie informazioni di indirizzamento.

Se un'implementazione rileva che l'indirizzo del peer è cambiato, DOVREBBE inviare un messaggio INFORMATIONAL con un payload Notify di tipo NAT_DETECTION_DESTINATION_IP per informare il peer del nuovo hash dell'indirizzo di destinazione.

2.23.4. Registri IANA

IANA ha creato registri per i messaggi di NAT traversal e le notifiche associate, come descritto in [IKEV2IANA]. Le implementazioni DEVONO utilizzare i tipi di notifica e i numeri di messaggio definiti in tali registri.