2. Incompatibilità note tra NA(P)T e IPsec

Le incompatibilità tra NA(P)T e IPsec possono essere divise in tre categorie:

Problemi intrinseci di NA(P)T. Queste incompatibilità derivano direttamente dalla funzionalità NA(P)T descritta in [RFC3022]. Queste incompatibilità saranno quindi presenti in qualsiasi dispositivo NA(P)T.
Debolezze di implementazione NA(P)T. Queste incompatibilità non sono intrinseche a NA(P)T, ma sono presenti in molte implementazioni NA(P)T. In questa categoria sono inclusi problemi nella gestione di frammenti in entrata o in uscita. Poiché questi problemi non sono intrinseci a NA(P)T, possono, in linea di principio, essere affrontati nelle future implementazioni NA(P)T. Tuttavia, poiché i problemi di implementazione sembrano essere diffusi, devono essere presi in considerazione in una soluzione di attraversamento NA(P)T.
Problemi degli helper. Queste incompatibilità sono presenti nei dispositivi NA(P)T che tentano di fornire attraversamento IPsec NA(P)T. Ironicamente, questa funzionalità "helper" crea ulteriori incompatibilità, rendendo un problema già difficile ancora più difficile da risolvere. Sebbene la funzionalità "helper" di attraversamento IPsec non sia presente in tutti i NA(P)T, queste funzionalità stanno diventando sufficientemente popolari da dover essere prese in considerazione anche in una soluzione di attraversamento NA(P)T.

2.1. Problemi intrinseci di NA(P)T

Le incompatibilità intrinseche a NA(P)T includono:

a) Incompatibilità tra IPsec AH [RFC2402] e NAT. Poiché l'intestazione AH incorpora gli indirizzi IP di origine e di destinazione nel controllo di integrità del messaggio con chiave, i dispositivi NAT o NAT inverso che apportano modifiche ai campi di indirizzo invalideranno il controllo di integrità del messaggio. Poiché IPsec ESP [RFC2406] non incorpora gli indirizzi IP di origine e di destinazione nel suo controllo di integrità del messaggio con chiave, questo problema non si presenta per ESP.

b) Incompatibilità tra checksum e NAT. I checksum TCP e UDP hanno una dipendenza dagli indirizzi IP di origine e di destinazione attraverso l'inclusione del "pseudo-header" nel calcolo. Di conseguenza, quando i checksum vengono calcolati e controllati alla ricezione, verranno invalidati dal passaggio attraverso un dispositivo NAT o NAT inverso.

Di conseguenza, IPsec Encapsulating Security Payload (ESP) passerà attraverso un NAT senza ostacoli solo se i protocolli TCP/UDP non sono coinvolti (come nella modalità tunnel IPsec o GRE protetto da IPsec), o i checksum non vengono calcolati (come è possibile con UDP IPv4). Come descritto in [RFC793], il calcolo e la verifica del checksum TCP sono richiesti in IPv4. Il calcolo e la verifica del checksum UDP/TCP sono richiesti in IPv6.

Lo Stream Control Transmission Protocol (SCTP), come definito in [RFC2960] e [RFC3309], utilizza un algoritmo CRC32C calcolato solo sul pacchetto SCTP (intestazione comune + chunk), in modo che l'intestazione IP non sia coperta. Di conseguenza, i NAT non invalidano il CRC SCTP, e il problema non si presenta.

Si noti che poiché il traffico IPsec in modalità trasporto è protetto in integrità e autenticato utilizzando crittografia forte, le modifiche al pacchetto possono essere rilevate prima di controllare i checksum UDP/TCP. Pertanto, la verifica del checksum fornisce solo garanzia contro errori commessi nell'elaborazione interna.

c) Incompatibilità tra identificatori di indirizzo IKE e NAT. Quando gli indirizzi IP vengono utilizzati come identificatori nell'Internet Key Exchange Protocol (IKE) Fase 1 [RFC2409] o Fase 2, la modifica degli indirizzi IP di origine o di destinazione da parte di NAT o NAT inversi risulterà in una mancata corrispondenza tra gli identificatori e gli indirizzi nell'intestazione IP. Come descritto in [RFC2409], le implementazioni IKE sono tenute a scartare tali pacchetti.

Al fine di evitare l'uso di indirizzi IP come identificatori IKE Fase 1 e Fase 2, è possibile utilizzare invece userID e FQDN. Quando è desiderata l'autenticazione dell'utente, può essere utilizzato un tipo di ID di ID_USER_FQDN, come descritto in [RFC2407]. Quando è desiderata l'autenticazione della macchina, può essere utilizzato un tipo di ID di ID_FQDN. In entrambi i casi, è necessario verificare che l'identificatore proposto sia autenticato come risultato dell'elaborazione di un certificato di entità finale, se i certificati vengono scambiati nella Fase 1. Sebbene l'uso dei tipi di identità USER_FQDN o FQDN sia possibile all'interno di IKE, esistono scenari di utilizzo (ad esempio, voci del Security Policy Database (SPD) che descrivono subnet) che non possono essere gestiti in questo modo.

Poiché l'indirizzo di origine nell'identificatore di Fase 2 viene spesso utilizzato per formare un selettore SA in entrata completo a 5 tuple, l'indirizzo di destinazione, il protocollo, la porta di origine e la porta di destinazione possono essere utilizzati nel selettore in modo da non indebolire l'elaborazione SA in entrata.

d) Incompatibilità tra porte di origine IKE fisse e NAPT. Quando più host dietro il NAPT avviano SA IKE allo stesso risponditore, è necessario un meccanismo per consentire al NAPT di demultiplare i pacchetti IKE in arrivo dal risponditore. Questo viene tipicamente realizzato traducendo la porta di origine UDP IKE sui pacchetti in uscita dall'iniziatore. Pertanto, i risponditori devono essere in grado di accettare il traffico IKE da una porta di origine UDP diversa da 500 e devono rispondere a quella porta. Si deve fare attenzione ad evitare comportamenti imprevedibili durante le ri-chiavi. Se la porta di origine flottante non viene utilizzata come porta di destinazione per la ri-chiave, il NAT potrebbe non essere in grado di inviare i pacchetti di ri-chiave alla destinazione corretta.

e) Incompatibilità tra voci SPD sovrapposte e NAT. Quando gli host iniziatori dietro un NAT utilizzano i loro indirizzi IP di origine negli identificatori di Fase 2, possono negoziare voci SPD sovrapposte con lo stesso indirizzo IP del risponditore. Il risponditore potrebbe quindi inviare pacchetti attraverso la SA IPsec sbagliata. Questo si verifica perché per il risponditore, le SA IPsec sembrano essere equivalenti, poiché esistono tra gli stessi endpoint e possono essere utilizzate per far passare lo stesso traffico.

f) Incompatibilità tra selezione SPI IPsec e NAT. Poiché il traffico IPsec ESP è crittografato e quindi opaco al NAT, il NAT deve utilizzare elementi dell'intestazione IP e IPsec per demultiplare il traffico IPsec in arrivo. La combinazione dell'indirizzo IP di destinazione, del protocollo di sicurezza (AH/ESP) e del SPI IPsec viene tipicamente utilizzata per questo scopo.

Tuttavia, poiché gli SPI in uscita e in entrata vengono scelti indipendentemente, non c'è modo per il NAT di determinare quale SPI in entrata corrisponde a quale host di destinazione semplicemente ispezionando il traffico in uscita. Pertanto, se due host dietro il NAT tentassero di creare SA IPsec alla stessa destinazione simultaneamente, è possibile che il NAT consegni i pacchetti IPsec in arrivo alla destinazione sbagliata.

Si noti che questa non è un'incompatibilità con IPsec di per sé, ma piuttosto con il modo in cui è tipicamente implementato. Con sia AH che ESP, l'host ricevente specifica il SPI da utilizzare per una data SA, una scelta che è significativa solo per il ricevitore. Attualmente, la combinazione di IP di destinazione, SPI e Protocollo di sicurezza (AH, ESP) identifica univocamente un'Associazione di sicurezza. Inoltre, i valori SPI nell'intervallo 1-255 sono riservati a IANA e possono essere utilizzati in futuro. Ciò significa che, quando si negozia con lo stesso host esterno o gateway, gli host interni dietro lo stesso NAPT possono selezionare lo stesso valore SPI, in modo tale che una SA in entrata di un host sia (SPI=470, Internal Dest IP=192.168.0.4) e una SA in entrata di un host diverso sia (SPI=470, Internal Dest IP=192.168.0.5). Il NAPT ricevente non sarà in grado di determinare a quale host interno un pacchetto IPsec in entrata con SPI=470 dovrebbe essere inoltrato.

È anche possibile per l'host ricevente allocare un SPI unico a ciascuna Associazione di sicurezza unicast. In questo caso, l'indirizzo IP di destinazione deve solo essere controllato per vedere se è "qualsiasi IP unicast valido per questo host", non controllato per vedere se è l'indirizzo IP di destinazione specifico utilizzato dall'host mittente. Utilizzando questa tecnica, al NA(P)T può essere assicurata una probabilità bassa ma non nulla di inoltrare pacchetti all'host interno sbagliato, anche quando due o più host stabiliscono SA con lo stesso host esterno.

Questo approccio è completamente retrocompatibile e richiede solo che il particolare host ricevente apporti una modifica alla sua allocazione SPI e al codice IPsec_esp_input(). Tuttavia, i dispositivi NA(P)T potrebbero non essere in grado di rilevare questo comportamento senza problemi associati all'analisi dei payload IKE. E un host potrebbe ancora essere tenuto a utilizzare un SPI nell'intervallo riservato IANA per lo scopo assegnato.

g) Incompatibilità tra indirizzi IP incorporati e NAT. Poiché il payload è protetto in integrità, qualsiasi indirizzo IP racchiuso all'interno di pacchetti IPsec non sarà traducibile da un NAT. Questo rende inefficaci gli Application Layer Gateway (ALG) implementati all'interno dei NAT. I protocolli che utilizzano indirizzi IP incorporati includono FTP, IRC, SNMP, LDAP, H.323, SIP, SCTP (opzionalmente) e molti giochi. Per affrontare questo problema, è necessario installare ALG sull'host o sul gateway di sicurezza che possano operare sul traffico dell'applicazione prima dell'incapsulamento IPsec e dopo il decapsulamento IPsec.

h) Direzionalità implicita di NA(P)T. I NA(P)T spesso richiedono che un pacchetto in uscita iniziale fluisca attraverso di essi al fine di creare uno stato di mappatura in entrata. La direzionalità proibisce l'istituzione non richiesta di SA IPsec agli host dietro il NA(P)T.

i) Verifica del selettore SA in entrata. Supponendo che IKE negozi i selettori di fase 2, l'elaborazione SA in entrata eliminerà il pacchetto decapsulato, poiché [RFC2401] richiede che l'indirizzo di origine di un pacchetto corrisponda al valore del selettore SA, che l'elaborazione NA(P)T di un pacchetto ESP cambierebbe.

2.2. Debolezze di implementazione NA(P)T

I problemi di implementazione presenti in molti NA(P)T includono:

j) Incapacità di gestire il traffico non UDP/TCP. Alcuni NA(P)T scartano il traffico non UDP/TCP o eseguono solo la traduzione dell'indirizzo quando solo un host è dietro il NAT. Tali NAPT non sono in grado di abilitare il traffico SCTP, ESP (protocollo 50) o AH (protocollo 51).

k) Timeout di mappatura NAT. I NA(P)T variano nel tempo per il quale una mappatura UDP verrà mantenuta in assenza di traffico. Pertanto, anche quando i pacchetti IKE possono essere tradotti correttamente, lo stato di traduzione potrebbe essere rimosso prematuramente.

l) Incapacità di gestire frammenti in uscita. La maggior parte dei NA(P)T può frammentare correttamente i pacchetti IP in uscita nel caso in cui la dimensione del pacchetto IP superi l'MTU sull'interfaccia in uscita. Tuttavia, la traduzione corretta dei pacchetti in uscita che sono già frammentati è difficile e la maggior parte dei NAPT non gestisce questo correttamente. Come notato nella Sezione 6.3 di [RFC3022], quando due host originano pacchetti frammentati alla stessa destinazione, gli identificatori di frammento possono sovrapporsi. Poiché l'host di destinazione si affida all'identificatore di frammentazione e all'offset del frammento per il riassemblaggio, il risultato sarà la corruzione dei dati. Pochi NA(P)T proteggono contro le collisioni di identificatori supportando la traduzione degli identificatori. Le collisioni di identificatori non sono un problema quando i NAT eseguono la frammentazione, poiché l'identificatore di frammento deve essere unico solo all'interno di una coppia di indirizzi IP origine/destinazione.

Poiché un frammento può essere piccolo come 68 ottetti [RFC791], non c'è garanzia che il primo frammento contenga un'intestazione TCP completa. Pertanto, un NA(P)T che cerca di ricalcolare il checksum TCP potrebbe dover modificare un frammento successivo. Poiché i frammenti possono essere riordinati e gli indirizzi IP possono essere incorporati e possibilmente persino divisi tra frammenti, il NA(P)T dovrà eseguire il riassemblaggio prima di completare la traduzione. Pochi NA(P)T supportano questo.

m) Incapacità di gestire frammenti in entrata. Poiché solo il primo frammento conterrà tipicamente un'intestazione IP/UDP/SCTP/TCP completa, i NAPT devono essere in grado di eseguire la traduzione basandosi solo sull'indirizzo IP origine/dest e sull'identificatore di frammento. Poiché i frammenti possono essere riordinati, le intestazioni di un dato identificatore di frammento potrebbero non essere note se un frammento successivo arriva prima di quello iniziale, e le intestazioni potrebbero essere divise tra frammenti. Di conseguenza, il NAPT potrebbe dover eseguire il riassemblaggio prima di completare la traduzione. Pochi NAPT supportano questo. Si noti che con NAT, l'indirizzo IP origine/dest è sufficiente per determinare la traduzione, quindi questo non si presenta. Tuttavia, è possibile che le intestazioni IPsec o IKE siano divise tra frammenti, quindi il riassemblaggio potrebbe comunque essere necessario.

2.3. Incompatibilità degli helper

Le incompatibilità tra IPsec e la funzionalità "helper" NAT includono:

n) Ispezione dell'intestazione Internet Security Association and Key Management Protocol (ISAKMP). Oggi alcune implementazioni NAT tentano di utilizzare i cookie IKE per demultiplare il traffico IKE in arrivo. Come con il demultiplexing della porta di origine, il demultiplexing dei cookie IKE provoca problemi con la ri-chiave, poiché le ri-chiavi di Fase 1 tipicamente non useranno gli stessi cookie del traffico precedente.

o) Trattamento speciale della porta 500. Poiché alcune implementazioni IKE non sono in grado di gestire porte di origine UDP diverse da 500, alcuni NAT non traducono pacchetti con una porta di origine UDP di 500. Ciò significa che questi NAT sono limitati a un client IPsec per gateway di destinazione, a meno che non ispezionino i dettagli dell'intestazione ISAKMP per esaminare i cookie, il che crea il problema sopra notato.

p) Ispezione del payload ISAKMP. Le implementazioni NA(P)T che tentano di analizzare i payload ISAKMP potrebbero non gestire tutte le combinazioni di ordinamento dei payload, o supportare payload vendor_id per la negoziazione delle opzioni IKE.