3. Requisiti per la compatibilità IPsec-NAT

3. Requisiti per la compatibilità IPsec-NAT

L'obiettivo di una soluzione di compatibilità IPsec-NAT è espandere la gamma di funzionalità IPsec utilizzabili oltre quella disponibile nella soluzione in modalità tunnel IPsec compatibile con NAT descritta nella Sezione 2.3.

Nel valutare una soluzione all'incompatibilità IPsec-NAT, i seguenti criteri dovrebbero essere tenuti a mente:

Distribuzione

Poiché IPv6 affronterà i problemi di scarsità di indirizzi che portano frequentemente all'uso di NA(P)T con IPv4, il problema di compatibilità IPsec-NAT è un problema transitorio che deve essere risolto nel periodo di tempo precedente alla distribuzione diffusa di IPv6. Pertanto, per essere utile, una soluzione di compatibilità IPsec-NAT DEVE essere distribuibile su una scala temporale più breve di IPv6.

Poiché la distribuzione di IPv6 richiede modifiche ai router così come agli host, una potenziale soluzione di compatibilità IPsec-NAT, che richiede modifiche sia ai router che agli host, sarà distribuibile su approssimativamente la stessa scala temporale di IPv6. Pertanto, una soluzione di compatibilità IPsec-NAT DOVREBBE richiedere modifiche solo agli host, e non ai router.

Tra le altre cose, ciò implica che la comunicazione tra l'host e il NA(P)T NON DOVREBBE essere richiesta da una soluzione di compatibilità IPsec-NAT, poiché ciò richiederebbe modifiche ai NA(P)T e test di interoperabilità tra le implementazioni di host e NA(P)T. Al fine di consentire la distribuzione a breve termine, è necessario che la soluzione funzioni con i prodotti router e NA(P)T esistenti all'interno dell'infrastruttura distribuita.

Compatibilità del protocollo

Non ci si aspetta che una soluzione di attraversamento NAT IPsec risolva problemi con protocolli che non possono attraversare NA(P)T quando non sono protetti con IPsec. Pertanto, potrebbero essere ancora necessari ALG per alcuni protocolli, anche quando è disponibile una soluzione di attraversamento NAT IPsec.

Sicurezza

Poiché la direzionalità NA(P)T svolge una funzione di sicurezza, le soluzioni di attraversamento IPsec NA(P)T non dovrebbero consentire che traffico IPsec o IKE in arrivo arbitrario da qualsiasi indirizzo IP venga ricevuto da un host dietro il NA(P)T, sebbene lo stato di mappatura debba essere mantenuto una volta stabilita la comunicazione IKE e IPsec bidirezionale.

Scenario telelavoratore

Poiché uno degli usi principali di IPsec è l'accesso remoto alle Intranet aziendali, una soluzione di attraversamento NA(P)T DEVE supportare l'attraversamento NA(P)T, tramite modalità tunnel IPsec o L2TP su modalità trasporto IPsec [RFC3193]. Questo include il supporto per l'attraversamento di più di un NA(P)T tra il client remoto e il gateway VPN.

Il client può avere un indirizzo instradabile e il gateway VPN può essere dietro almeno un NA(P)T, o in alternativa, sia il client che il gateway VPN possono essere dietro uno o più NA(P)T. I telelavoratori possono utilizzare lo stesso indirizzo IP privato, ciascuno dietro il proprio NA(P)T, o molti telelavoratori possono risiedere su una rete privata dietro lo stesso NA(P)T, ciascuno con il proprio indirizzo privato univoco, connettendosi allo stesso gateway VPN. Poiché IKE utilizza la porta UDP 500 come destinazione, non è necessario abilitare più gateway VPN che operano dietro lo stesso indirizzo IP esterno.

Scenario gateway-to-gateway

In uno scenario gateway-gateway, una rete indirizzata privatamente (DMZ) può essere inserita tra la rete aziendale e Internet. In questo design, i gateway di sicurezza IPsec che collegano porzioni della rete aziendale possono risiedere nella DMZ e avere indirizzi privati sulle loro interfacce esterne (DMZ). Un NA(P)T collega la rete DMZ a Internet.

Scenario end-to-end

Una soluzione NAT-IPsec DEVE consentire la comunicazione TCP/IP host-to-host sicura tramite IPsec, così come le comunicazioni host-gateway. Un host su una rete privata DEVE essere in grado di stabilire una o più connessioni TCP protette da IPsec o sessioni UDP verso un altro host con uno o più NA(P)T tra loro. Ad esempio, i NA(P)T possono essere distribuiti all'interno di filiali che si collegano alla rete aziendale, con un NA(P)T aggiuntivo che collega la rete aziendale a Internet. Allo stesso modo, i NA(P)T possono essere distribuiti all'interno di una LAN o WAN di rete aziendale per collegare client wireless o di posizione remota alla rete aziendale. Ciò può richiedere un'elaborazione speciale del traffico TCP e UDP sull'host.

L'istituzione di connessioni SCTP a un altro host con uno o più NA(P)T tra loro può presentare sfide speciali. SCTP supporta il multi-homing. Se viene utilizzato più di un indirizzo IP, questi indirizzi vengono trasportati come parte del pacchetto SCTP durante la configurazione dell'associazione (nei chunk INIT e INIT-ACK). Se vengono utilizzati solo endpoint SCTP single-homed, [RFC2960] sezione 3.3.2.1 afferma:

  Si noti che non utilizzare alcun parametro di indirizzo IP nell'INIT e
  nell'INIT-ACK è un'alternativa per rendere un'associazione più probabile
  di funzionare attraverso un box NAT.

Ciò implica che gli indirizzi IP non dovrebbero essere inseriti nel pacchetto SCTP a meno che non sia necessario. Se i NAT sono presenti e gli indirizzi IP sono inclusi, la configurazione dell'associazione fallirà. Recentemente è stato proposto [AddIP], che consente la modifica dell'indirizzo IP una volta stabilita un'associazione. I messaggi di modifica hanno anche indirizzi IP nel pacchetto SCTP, e quindi saranno influenzati negativamente dai NAT.

Compatibilità firewall

Poiché i firewall sono ampiamente distribuiti, una soluzione di compatibilità NAT-IPsec DEVE consentire a un amministratore di firewall di creare regole di accesso semplici e statiche per consentire o negare il traffico di attraversamento IKE e IPsec NA(P)T. Ciò implica, ad esempio, che l'allocazione dinamica delle porte di destinazione IKE o IPsec deve essere evitata.

Scalabilità

Una soluzione di compatibilità IPsec-NAT dovrebbe essere in grado di essere distribuita all'interno di un'installazione composta da migliaia di telelavoratori. In questa situazione, non è possibile assumere che solo un singolo host stia comunicando con una data destinazione alla volta. Pertanto, una soluzione di compatibilità IPsec-NAT DEVE affrontare il problema delle voci SPD sovrapposte e del demultiplexing dei pacchetti in arrivo.

Supporto delle modalità

Come minimo, una soluzione di compatibilità IPsec-NAT DEVE supportare l'attraversamento delle modalità IKE e IPsec richieste per il supporto all'interno di [RFC2409] e [RFC2401]. Ad esempio, un gateway IPsec DEVE supportare l'attraversamento della modalità tunnel ESP NA(P)T, e un host IPsec DEVE supportare l'attraversamento della modalità trasporto IPsec NA(P)T. Lo scopo di AH è proteggere i campi immutabili all'interno dell'intestazione IP (inclusi gli indirizzi), e NA(P)T traduce gli indirizzi, invalidando il controllo di integrità AH. Di conseguenza, NA(P)T e AH sono fondamentalmente incompatibili e non c'è alcun requisito che una soluzione di compatibilità IPsec-NAT supporti la modalità trasporto o tunnel AH.

Compatibilità all'indietro e interoperabilità

Una soluzione di compatibilità IPsec-NAT DEVE essere interoperabile con le implementazioni IKE/IPsec esistenti, in modo che possano comunicare quando non è presente alcun NA(P)T. Ciò implica che una soluzione di compatibilità IPsec-NAT DEVE essere retrocompatibile con IPsec come definito in [RFC2401] e IKE come definito in [RFC2409]. Inoltre, DOVREBBE essere in grado di rilevare la presenza di un NA(P)T, in modo che il supporto per l'attraversamento NA(P)T venga utilizzato solo quando necessario. Ciò implica che DEVE essere possibile determinare che un'implementazione IKE esistente non supporta l'attraversamento NA(P)T, in modo che possa verificarsi una conversazione IKE standard, come descritto in [RFC2407], [RFC2408] e [RFC2409]. Si noti che mentre ciò implica l'avvio di IKE alla porta 500, non c'è alcun requisito per una porta di origine specifica, quindi la porta di origine UDP 500 può essere utilizzata o meno.

Sicurezza

Una soluzione di compatibilità IPsec-NAT NON DEVE introdurre ulteriori vulnerabilità di sicurezza IKE o IPsec. Ad esempio, una soluzione accettabile deve dimostrare di non introdurre nuove vulnerabilità di denial of service o spoofing. IKE DEVE essere consentito di ri-chiave in modo bidirezionale come descritto in [RFC2408].