IPsec: differenze tra le versioni

Versione delle 10:57, 4 lug 2005

Versione delle 19:56, 4 lug 2005

Riga 194:

Il controllo di integrità e autenticità viene eseguito tramite [[HMAC]] (funzioni di [[hash]]);

l'hash viene calcolato tramite una funzione di hash ([[MD5]] o [[SHA1]]), utilizzando una chiave condivisa; l'hash ottenuto viene allegato al messaggio e inviato. In ricezione viene controllata l'integrità del messaggio. Dagli schemi visti prima si nota che l'indirizzo IP più esterno non viene coperto dal controllo di integrità. Tale opzioni rende il protocollo ESP adatto ad essere utilizzato in alcuni tipi di [[NAT]], in particolare in quelli statici. Tuttavia esistono soluzioni ''ad-hoc'' per il funzionamento congiunto di IPsec e NAT come il [[NAT Traversal]].

===NAT Traversal===

====Descrizione====

NAT traversal (o più in breve NAT-T) è il nome di un protocollo facente parte della suite IPsec e standardizzato in diversi [[RFC]], di cui quello ufficiale è RFC 3947. L'obiettivo di questo protocollo è fornire la possibilità di stabilire un tunnel IPsec anche quando uno dei due ''peer'' coinvolti subisce un'operazione di nat per raggiungere l'altra entità coinvolta nella comunicazione.

====Scenario====

Il [[Network_address_translation|NAT]] è una tecnica molto utilizzata per il riuso degli indirizzi IP. Tuttavia gli host dietro un [[router]] (o un [[firewall]]) che effettua operazioni di NAT non godono di [[connettività end-to-end]]. Sebbene esistano diversi tipi di [[NAT]], l'obiettivo generale è l'alterazione degli header del pacchetto. Questo comportamento è in netto contrasto con IPsec che ha tra i suoi obiettivi il controllo dell''''integrità''' del pacchetto.

In particolare il NAT è incompatibile con AH sia in tunnel mode che in transport mode, in quanto AH verifica l'integrità di tutto il pacchetto IP. ESP, invece, non copre l'header IP con controlli di sorta nè in Tunnel mode nè in Transport mode, per cui risulta adatto nel caso in cui il nat eseguito sia di tipo [[SNAT]]; in altre parole, la modifica apportata dal router deve coinvolgere '''solamente''' l'header IP e non anche la [[Porta (protocolli di trasporto)|porta]] del livello superiore.

Il NAT crea problemi anche con IKE e soprattutto con IKE in '''main mode'''. Il main mode usato congiuntamente al metodo delle ''preshared-keys'' richiede l'autenticazione degli host coinvolti nella comunicazione e tale autenticazione prevede un controllo sugli indirizzi [[IP]]; per cui l'alterazione dell'indirizzo da parte di un apparecchiatura di NAT provoca il fallimento dell'autenticazione.

In genere, nei dispositivi preposti alla gestione dei tunnel IPsec e nei client VPN, il NAT-T non è abilitato di default ma deve essere impostato a mano; tuttavia il suo utilizzo rimane opzionale: difatti durante la creazione della '''security association''', i peer determinano se uno dei due subisce operazioni di NAT e solo in questo caso viene usato il NAT-T; questa operazione viene fatta durante la prima fase della negaziazione '''IKE'''.

In prima battuta, i ''peer'' verificano che entrambi siano in grado di supportare in NAT-T; questa verifica è eseguita nella primissima fase del protocollo IKE, per mezzo di un pacchetto con un campo ''Vendor-ID'', che contiene un valore [[hash]] noto.<br>

Una volta stabilito che entrambi supportano il NAT-T, vengono inviate delle frame "NAT-Discovery" (NAT-D), in modo da verificare chi dei due subisca il NAT, o al limite se lo subiscano entrambi. <br>

Una volta stabilito chi subisce il NAT, la comunicazione si sposta su una nuova coppia di porti UDP e l'entità "''nat-tata''" comincia a inviare delle frame '''keepalive'''; queste frame servono a mantenere fisso il porto di comunicazione sul router e ad impedirgli di riassegnarlo ad una nuova comunicazione.

Descriviamo come viene incapsulato il pacchetto originale ESP.

{|width="80%" cellspacing="0" border="1"

|style="width:12%;" | Header IP

|style="width:12%;background-color:orange;" | Header ESP

|style="width:17%;background-color:lime" | Header IP interno

|style="width:17%;background-color:lime" | Header TCP

|style="width:18%;background-color:lime" | Dati

|style="width:12%;background-color:orange;" | Trailer ESP

|style="width:12%;background-color:orange;" | ESP auth

|}

<small>ESP in Tunnel mode</small>

{|width="100%" cellspacing="0" border="1"

|style="width:9%;" | Header IP

|style="width:10%;background-color:green;font-weight:bold" | Header UDP

|style="width:11%;background-color:green;font-weight:bold" | Header NAT-T

|style="width:12%;background-color:orange;" | Header ESP

|style="width:14%;background-color:lime" | Header IP interno

|style="width:11%;background-color:lime" | Header TCP

|style="width:15%;background-color:lime" | Dati

|style="width:10%;background-color:orange;" | Trailer ESP

|style="width:10%;background-color:orange;" | ESP auth

|}

<small>ESP in Tunnel mode con incapsulamento UDP per NAT-T</small>

I campi segnati in <font style="background-color:green;font-weight:bold">verde scuro</font> sono quelli relativi al NAT-T; questi campi vengono inseriti subito dopo l'header IP esterno, che non viene alterato, così come non vengono alterati i campi successivi. In ricezione viene fatta l'operazione inversa.

== Elenco degli RFC relativi ad IPsec==

Riga 205 ⟶ 247:

; RFC 2411: IP Security Document Roadmap

; RFC 2412: The OAKLEY Key Determination Protocol

; RFC 3974: Negotiation of NAT-Traversal in the IKE

==Collegamenti esterni==

*http://www.ipsec-howto.org/italian/x151.html<br>

*[http://www.linux.it/~davide/doc/tesi_html/index.html IPsec e TLS a confronto: funzioni, prestazioni ed estensioni]

*[http://www.isaserver.org/articles/IPSec_Passthrough.html How to pass IPSec traffic through ISA Server]

[[Categoria:Standard Internet]]