2.23. NAT Traversal (Attraversamento NAT)

2.23. NAT Traversal (Attraversamento NAT)

I gateway di traduzione degli indirizzi di rete (NAT) sono controversi. Questa sezione descrive brevemente cosa sono e come probabilmente agiscono sul traffico IKE. Molti ritengono i NAT dannosi e che i protocolli non dovrebbero essere progettati per funzionare meglio con essi. IKEv2 definisce infatti alcune regole di elaborazione poco intuitive affinché i NAT funzionino più spesso.

I NAT esistono soprattutto a causa della scarsità di indirizzi IPv4. I nodi «dietro» un NAT non hanno indirizzi globalmente unici; sono unici nella rete dietro il NAT ma spesso riutilizzati dietro altri NAT. In generale, i nodi dietro un NAT comunicano con altri dietro lo stesso NAT e con nodi a indirizzi globalmente unici, ma non con nodi dietro altri NAT (eccezioni possibili). Quando si connettono a Internet, il gateway NAT «traduce» l'indirizzo IP sorgente in un indirizzo instradabile verso il gateway. I messaggi da Internet al gateway hanno l'indirizzo di destinazione «tradotto» verso l'indirizzo interno che instrada al nodo finale.

I NAT sono progettati per essere «trasparenti» agli endpoint. Né il software dietro il NAT né il nodo su Internet richiedono modifiche per comunicare attraverso il NAT. Ottenere questa trasparenza è più difficile per alcuni protocolli. I protocolli che includono indirizzi IP degli endpoint nel payload falliscono se il gateway NAT non comprende il protocollo e non modifica i riferimenti interni e gli header. Tale conoscenza è intrinsecamente inaffidabile, viola il modello a strati e spesso causa problemi sottili.

Aprire una connessione IPsec attraverso un NAT introduce problemi speciali. In modalità transport, modificare gli indirizzi IP fa fallire i checksum e il NAT non può correggerli perché sono protetti crittograficamente. Anche in modalità tunnel, tradurre in modo trasparente gli indirizzi dei pacchetti AH ed ESP richiede logica speciale nel NAT, euristica e inaffidabile. Per questo IKEv2 usa incapsulamento UDP di IKE ed ESP. È leggermente meno efficiente ma più facile per i NAT. Inoltre i firewall possono essere configurati per far passare solo traffico IPsec incapsulato UDP o viceversa.

È pratica comune dei NAT tradurre anche le porte TCP e UDP oltre agli indirizzi e usare le porte dei pacchetti in ingresso per decidere quale nodo interno riceva un dato pacchetto. Per questo, anche se i pacchetti IKE DEVONO essere inviati da e verso le porte UDP 500 o 4500, DEVONO essere accettati da qualsiasi porta e le risposte DEVONO essere inviate alla porta di provenienza, perché le porte possono essere modificate attraversando i NAT. Analogamente, gli indirizzi degli endpoint IKE in genere non sono inclusi nei payload IKE perché i payload sono protetti crittograficamente e non potrebbero essere modificati in modo trasparente dai NAT.

La porta 4500 è riservata a ESP e IKE incapsulati UDP. Un endpoint IPsec che scopre un NAT tra sé e il corrispondente (come sotto) DEVE inviare tutto il traffico successivo dalla porta 4500, che i NAT non dovrebbero trattare in modo speciale come la 500.

L'iniziatore PUÒ usare la porta 4500 per IKE ed ESP fin dall'inizio, con o senza NAT. Quando una delle due parti usa la 4500, l'invio di ESP con incapsulamento UDP non è richiesto, ma la comprensione degli ESP ricevuti incapsulati UDP sì. L'incapsulamento UDP NON DEVE essere fatto sulla porta 500. Se è supportato l'attraversamento NAT (NAT_DETECTION_*_IP scambiati durante IKE_SA_INIT), tutti i dispositivi DEVONO poter ricevere ed elaborare in qualsiasi momento sia ESP incapsulati UDP sia non incapsulati. Ogni lato decide in modo indipendente se usare l'incapsulamento UDP per ESP. Se viene rilevato un NAT, entrambi i dispositivi DEVONO usare l'incapsulamento UDP per ESP.

I requisiti specifici [NATREQ] per il supporto dell'attraversamento NAT sono elencati sotto. Il supporto è opzionale. Solo in questa sezione, i requisiti indicati come MUST si applicano solo alle implementazioni che supportano l'attraversamento NAT.

• Sia l'iniziatore IKE sia il rispondente DEVONO includere nei pacchetti IKE_SA_INIT payload Notify di tipo NAT_DETECTION_SOURCE_IP e NAT_DETECTION_DESTINATION_IP. Servono a rilevare se c'è NAT tra gli host e quale estremità è dietro il NAT. La posizione è subito dopo Ni e Nr (prima del CERTREQ opzionale).

• I dati NAT_DETECTION_SOURCE_IP sono un digest SHA-1 degli SPI (nell'ordine in cui compaiono nell'header), indirizzo IP e porta da cui è stato inviato il pacchetto.

  POSSONO esserci più payload NAT_DETECTION_SOURCE_IP se il mittente non sa quale interfaccia invierà il pacchetto.

• I dati NAT_DETECTION_DESTINATION_IP sono un digest SHA-1 degli SPI, indirizzo IP e porta a cui il pacchetto è stato inviato.

• Il destinatario di NAT_DETECTION_SOURCE_IP o NAT_DETECTION_DESTINATION_IP PUÒ confrontare il valore fornito con un hash SHA-1 di SPI, indirizzo IP sorgente o destinatario e porta; se non coincidono, DOVREBBE abilitare l'attraversamento NAT. Se l'hash SOURCE non coincide con nessuno dei payload SOURCE ricevuti, il destinatario PUÒ rifiutare il tentativo di connessione se l'attraversamento NAT non è supportato. In caso di hash DESTINATION non corrispondente, il sistema che riceve il payload NAT_DETECTION_DESTINATION_IP è dietro un NAT e DOVREBBE iniziare a inviare pacchetti keepalive come in [UDPENCAPS]; in alternativa PUÒ rifiutare se l'attraversamento NAT non è supportato.

• Se nessuno dei payload NAT_DETECTION_SOURCE_IP ricevuti corrisponde al valore atteso di IP e porta sorgente dall'header IP del pacchetto che contiene il payload, il sistema che invia quei payload è dietro un NAT. In tal caso il sistema che riceve dovrebbe consentire aggiornamenti dinamici dell'indirizzo IP dell'altro sistema, come descritto più avanti.

• L'iniziatore IKE DEVE controllare i payload NAT_DETECTION_SOURCE_IP o NAT_DETECTION_DESTINATION_IP se presenti; se non corrispondono agli indirizzi nel pacchetto esterno, DEVE incapsulare in tunnel tutti i futuri pacchetti IKE ed ESP associati a questa IKE SA sulla porta UDP 4500.

• Per tunnelizzare IKE sulla 4500: quattro ottetti zero prima dell'header IKE, subito dopo l'header UDP. Per ESP: l'header ESP segue immediatamente l'header UDP. Poiché i primi quattro ottetti dell'header ESP contengono lo SPI e lo SPI non può essere validamente zero, si possono sempre distinguere IKE ed ESP.

• Le implementazioni DEVONO elaborare i pacchetti ESP ricevuti incapsulati UDP anche quando non è stato rilevato alcun NAT.

• Gli indirizzi IP sorgente e destinazione originali richiesti per la correzione dei checksum TCP e UDP in modalità transport ([UDPENCAPS]) si ottengono dai Traffic Selector associati allo scambio. In caso di attraversamento NAT in modalità transport, i Traffic Selector DEVONO contenere esattamente un indirizzo IP, usato come indirizzo originale. Maggior dettaglio in 2.23.1.

• Ci sono casi in cui un NAT rimuove mapping ancora attivi (intervallo keepalive troppo lungo, riavvio del NAT). Un host se ne accorge se riceve un pacchetto la cui protezione di integrità è valida ma con porta e/o indirizzo diversi da quelli associati alla SA nel pacchetto validato. In tal caso, un host che non supporta altri metodi di ripristino come MOBIKE [MOBIKE] e non è dietro un NAT DOVREBBE inviare tutti i pacchetti (inclusi i ritrasmetti) all'indirizzo IP e alla porta nel pacchetto validato e DOVREBBE memorizzare questa nuova combinazione per la SA. Un host dietro un NAT NON DOVREBBE fare questo tipo di aggiornamento dinamico dell'indirizzo se un pacchetto validato ha porte e/o indirizzi diversi, perché apre un possibile attacco DoS. Inoltre l'aggiornamento dinamico va fatto solo in risposta a un nuovo pacchetto; altrimenti un attaccante può ripristinare gli indirizzi con vecchi pacchetti replayati. Per questo gli aggiornamenti dinamici sono sicuri solo se la protezione anti-replay è abilitata. Quando IKEv2 è usato con MOBIKE, aggiornare dinamicamente gli indirizzi come sopra interferisce con il ripristino MOBIKE; vedere [MOBIKE] sezione 3.8.

2.23.1. Transport Mode NAT Traversal (Modalità transport e attraversamento NAT)

La modalità transport usata con attraversamento NAT richiede un'elaborazione speciale dei Traffic Selector in IKEv2. Lo scenario completo:

+------+        +------+            +------+         +------+
|Client| IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Server|
|node  |<------>|  A   |<---------->|  B   |<------->|      |
+------+        +------+            +------+         +------+

(Altri scenari sono semplificazioni di questo caso complesso.)

In questo scenario ci sono due NAT che traduono indirizzi: NAT A e NAT B. NAT A è dinamico e mappa l'indirizzo sorgente del client IP1 su IPN1. NAT B è statico e configurato in modo che le connessioni verso IPN2 siano mappate sull'indirizzo IP2 del gateway, cioè l'indirizzo di destinazione IPN2 è mappato su IP2. Ciò consente al client di connettersi al server connettendosi a IPN2. NAT B non deve necessariamente essere statico, ma il client deve sapere come connettersi al server, e può farlo solo se conosce in qualche modo l'indirizzo esterno di NAT B, cioè IPN2. Se NAT B è statico, l'indirizzo può essere configurato sul client. Un'altra opzione è trovarlo con un altro protocollo (come DNS), ma è fuori ambito IKEv2.

In questo scenario, sia il client sia il server sono configurati per usare la modalità transport per il traffico dal nodo client verso il server.

Quando il client inizia a creare l'IKEv2 SA e la Child SA per inviare traffico al server, può avere un pacchetto di attivazione con indirizzo IP sorgente IP1 e indirizzo di destinazione IPN2. Il suo PAD e SPD devono avere una configurazione che corrisponda a quegli indirizzi (o voci jolly). Poiché è modalità transport, usa esattamente gli stessi indirizzi dei Traffic Selector e dell'IP esterno dei pacchetti IKE. In modalità transport DEVE usare esattamente un indirizzo IP nei payload TSi e TSr. Può avere più Traffic Selector se ha, ad esempio, più intervalli di porte da negoziare, ma tutte le voci TSi devono usare l'intervallo IP1-IP1 come indirizzi IP e tutte le voci TSr devono avere l'intervallo IPN2-IPN2. Il primo Traffic Selector di TSi e TSr DOVREBBE essere molto specifico, inclusi protocollo e numeri di porta, ad esempio dal pacchetto che attiva la richiesta.

NAT A sostituisce quindi l'indirizzo sorgente del pacchetto IKE da IP1 a IPN1, e NAT B sostituisce l'indirizzo di destinazione da IPN2 a IP2, così quando il pacchetto arriva al server ha ancora esattamente gli stessi Traffic Selector inviati dal client, ma l'indirizzo IP del pacchetto IKE è stato sostituito con IPN1 e IP2.

Quando il server riceve il pacchetto, di norma consulta il PAD descritto in RFC 4301 [IPSECARCH] in base all'ID e poi cerca nell'SPD in base ai Traffic Selector. Poiché IP1 non ha significato reale per il server (è l'indirizzo del client dietro il NAT), è inutile fare una ricerca basata su quello se si usa la modalità transport. D'altra parte, il server non può sapere se la modalità transport è consentita dalla policy prima di trovare la voce SPD corrispondente.

In questo caso, il server dovrebbe prima verificare che l'iniziatore abbia richiesto la modalità transport, poi fare sostituzione degli indirizzi sui Traffic Selector. Deve prima memorizzare i vecchi indirizzi IP dei Traffic Selector per la correzione incrementale dei checksum (l'IP in TSi può essere memorizzato come indirizzo sorgente originale e l'IP in TSr come destinazione originale). Dopo, se l'altra estremità è stata rilevata dietro un NAT, il server sostituisce l'indirizzo IP nei payload TSi con l'indirizzo ottenuto dall'indirizzo sorgente del pacchetto IKE ricevuto (sostituisce IP1 in TSi con IPN1). Se l'estremità del server è stata rilevata dietro NAT, sostituisce l'indirizzo IP nei payload TSr con l'indirizzo ottenuto dall'indirizzo di destinazione del pacchetto IKE ricevuto (sostituisce IPN2 in TSr con IP2).

Dopo questa sostituzione, sia i Traffic Selector sia gli indirizzi UDP sorgente/destinazione IKE coincidono, e il server fa ricerca SPD su quei nuovi Traffic Selector. Se trova una voce e consente la modalità transport, usa quella voce. Se trova una voce ma non consente la modalità transport, il server PUÒ annullare la sostituzione degli indirizzi e rifare la ricerca SPD con i Traffic Selector originali. Se la seconda ricerca ha successo, il server creerà una SA in modalità tunnel con i Traffic Selector reali inviati dall'altra estremità.

Questa sostituzione degli indirizzi in modalità transport è necessaria perché l'SPD è consultato con gli indirizzi che vedrà l'host locale. Ciò garantisce anche che le voci SAD per i controlli all'uscita del tunnel e i pacchetti di ritorno siano aggiunte con gli indirizzi visti dallo stack del sistema operativo locale.

Il caso più comune è che l'SPD del server contenga voci jolly che corrispondono a qualsiasi indirizzo, ma ciò consente anche voci SPD diverse, ad esempio per indirizzi esterni noti di NAT diversi.

Dopo la ricerca SPD, il server restringe i Traffic Selector in base alla voce SPD trovata. Userà di nuovo i Traffic Selector già sostituiti e quindi invierà indietro Traffic Selector con IPN1 e IP2 come indirizzi IP; può ancora restringere numero di protocollo o intervalli di porta. La voce SAD creata per la Child SA avrà gli indirizzi visti dal server, cioè IPN1 e IP2.

Quando il client riceve la risposta del server alla Child SA, farà elaborazione simile. Se è stata creata la SA in modalità transport, il client può memorizzare i Traffic Selector restituiti originali come indirizzi sorgente e destinazione originali. Sostituirà gli indirizzi IP nei Traffic Selector con quelli dall'header IP del pacchetto IKE: sostituirà IPN1 con IP1 e IP2 con IPN2. Poi userà quei Traffic Selector quando verifica la SA rispetto ai Traffic Selector inviati e quando installa la voce SAD.

Riassunto delle regole per l'attraversamento NAT in modalità transport:

Per il client che propone la modalità transport:

• Le voci TSi DEVONO avere esattamente un indirizzo IP, che DEVE corrispondere all'indirizzo sorgente dell'IKE SA.

• Le voci TSr DEVONO avere esattamente un indirizzo IP, che DEVE corrispondere all'indirizzo di destinazione dell'IKE SA.

• I primi Traffic Selector TSi e TSr DOVREBBERO essere molto specifici, inclusi protocollo e porte, ad esempio dal pacchetto di attivazione.

• POSSONO esserci più voci TSi e TSr.

• Se per la SA è stata selezionata la modalità transport (cioè se il server ha incluso la notifica USE_TRANSPORT_MODE nella risposta):

  • Memorizzare i Traffic Selector originali come indirizzi sorgente e destinazione ricevuti.

  • Se il server è dietro un NAT, sostituire l'indirizzo IP nelle voci TSr con l'indirizzo remoto dell'IKE SA.

  • Se il client è dietro un NAT, sostituire l'indirizzo IP nelle voci TSi con l'indirizzo locale dell'IKE SA.

  • Effettuare la sostituzione degli indirizzi prima di usare quei Traffic Selector per qualsiasi scopo diverso dal memorizzarne il contenuto originale, inclusa la verifica che l'altra estremità abbia ristretto correttamente, la creazione della voce SAD, ecc.

Per il rispondente, quando il client propone la modalità transport:

• Memorizzare gli indirizzi IP originali dei Traffic Selector come sorgente e destinazione ricevute, nel caso serva annullare la sostituzione, per usare come «indirizzi sorgente e destinazione reali» in [UDPENCAPS] e per la correzione checksum TCP/UDP.

• Se il client è dietro un NAT, sostituire l'indirizzo IP nelle voci TSi con l'indirizzo remoto dell'IKE SA.

• Se il server è dietro un NAT, sostituire l'indirizzo IP nelle voci TSr con l'indirizzo locale dell'IKE SA.

• Eseguire ricerca PAD e SPD usando l'ID e i Traffic Selector sostituiti.

• Se non è stata trovata alcuna voce SPD, o (se trovata) la voce non consente la modalità transport, annullare le sostituzioni dei Traffic Selector. Eseguire di nuovo ricerca PAD e SPD con l'ID e i Traffic Selector originali, cercando anche voci SPD in modalità tunnel (fallback a tunnel).

• Se invece è stata trovata una voce SPD in modalità transport, eseguire il restringimento normale dei traffic selector in base ai Traffic Selector sostituiti e alla voce SPD. Usare i Traffic Selector risultanti quando si creano le voci SAD e quando si inviano i Traffic Selector al client.