IPsec: differenze tra le versioni

Versione delle 16:30, 3 ago 2005

Versione attuale delle 15:55, 8 mar 2025

(197 versioni intermedie di oltre 100 utenti non mostrate)

Riga 1:

IPsecIn è[[telecomunicazioni]] e [[informatica]] l'''IPsec''', abbreviazione di '''IP Security''' ed, è uno [[standard (informatica)|standard]] per [[rete informatica|reti]] a [[commutazione di pacchetto|pacchetto]] che si prefigge di ottenere [[connessione (informatica)|connessioni]] basatesicure su IP[[Rete sicureinformatica|reti]] [[Internet Protocol|IP]].

LaTale [[sicurezza informatica|sicurezza]] viene raggiunta attraverso lal'aggiunta di funzionalità di [[autenticazione]], [[cifratura]] e l'autenticazionecontrollo di [[integrità dei pacchettidati|integrità]] dei [[Internetpacchetto Protocol(reti)|pacchetti]] IP ([[datagramma|datagrammi]]). La capacità di fornire protezione o sicurezza viene dunque fornita a [[livello di rete]] (diversamente da [[HTTPS]], quindi[[Transport Layer Security|SSL/TLS]]), afatto che rende questo [[Livelloprotocollo di rete|protocollo]] trasparente al [[livello reteapplicazioni|livello delle applicazioni]] che quindi non devono essere modificate.

== Panoramica dello standard ==

=== Scopo del progetto ===

IPsec è stato progettato per rendere sicure sia comunicazioni ''portal-to-portal'' sia comunicazioni ''end-to-end''. Nella prima configurazione il traffico viene reso "''sicuro''" a diversi computer (in alcuni casi ad un'intera [[LAN]]); nella seconda solo i ''peer'' che stabiliscono la connessione scambiano pacchetti protetti.

Tuttavia l'uso predominante di IPsec è la creazione di [[Rete privata virtuale|reti private virtuali]]; per conseguire tale scopo possono essere utilizzati entrambi i metodi prima esposti.

=== Introduzione ===

IPsec è una collezione di [[protocollo di rete|protocolli]] formata da:

* Protocolli che fornisconoimplementano lalo cifraturascambio deldelle flussochiavi diper realizzare il flusso daticrittografato.

* Protocolli che implementanoforniscono loautenticazione, ''scambiointegrità dellee chiavi''riservatezza perdel realizzareflusso il flussodi crittografatodati.

Per quanto riguarda il primo aspetto, esistono due protocolli: [[Authentication Header]] (AH) e [[Encapsulating Security Payload]] (ESP).

Esiste un solo protocollo per lo scambio delle chiavi, il protocollo ''[[Internet key exchange|IKE]]''.

'''ESP''' fornisce autenticazione, confidenzialità e controllo di integrità del messaggio ed è il protocollo IP 50. '''AH''', invece, garantisce l'autenticazione e l'integrità del messaggio ma non offre la confidenzialità; per questo motivo ESP è molto più usato di AH; AH è il protocollo IP 51.<br>

Attualmente esiste un solo protocollo per lo ''scambio delle chiavi'', il protocollo '''IKE'''.

IPsec è parte integrante di [[IPv6]], mentre è opzionale in [[IPv4]]. Di conseguenza, ci si aspetta che sarà maggiormente utilizzato quando IPv6 acquisterà popolarità.

Il protocollo è definito negli [[Request_for_CommentsRequest for Comments|RFC]]s 2401-2412.

Dal [[2004]], sono in corso studi per l'aggiornamento dei protocolli.

==Scopo del progetto==

IPsec è stato progettato per rendere sicure sia comunicazioni ''portal-to-portal'' che comunicazioni ''end-to-end''. Nella prima configurazione il traffico viene reso "''sicuro''" a diversi computer (in alcuni casi ad un intera [[LAN]]); nella seconda solo i ''peer'' che stabiliscono la connessione scambiano pacchetti protetti.

Tuttavia l'uso predominante di IPsec è la creazione di VPN ([[virtual private network]]); per conseguire tale scopo possono essere utilizzati entrambi i metodi prima esposti.

Per quanto riguarda il secondo aspetto, esistono due protocolli: [[Authentication Header]] (AH) e [[Encapsulating Security Payload]] (ESP).

==Dettagli Tecnici==

'''AH''' fornisce autenticazione e [[integrità dei dati|integrità del messaggio]], ma non offre la riservatezza ed è il protocollo IP 51.<br />

'''ESP''' fornisce invece autenticazione, riservatezza e controllo di [[integrità dei dati|integrità del messaggio]] ed è il protocollo IP 50. Per questi motivi ESP è molto più usato di AH.

=== Dettagli tecnici ===

IPsec supporta due modalità di funzionamento:

* Tunnel''Transport mode''

*#connessione [[host]]-to-host;

* Transport mode

*#usato dagli end-point, non dai [[gateway (informatica)|gateway]];

a seconda della modalità scelta, vengono protetti solo i protocolli di livello superiore o l'intero pacchetto [[IP]]. In Transport mode, viene coperto da IPsec solo il payload del pacchetto IP originale, in quanto l'header IPsec viene inserito dopo l'header del pacchetto IP.

*#in caso di cifratura, viene cifrato solo il [[Carico utile (informatica)|payload]] dei datagrammi IP, non l'[[header]];

In Tunnel mode, IPsec incapsula il pacchetto IP originale in un nuovo pacchetto IP.

*#computazionalmente leggero;

*#ogni host che vuole comunicare deve avere tutto il software necessario ad implementare IPsec;

*#si aggiunge solo l'header IPsec; gli indirizzi mittente e destinatario degli end-point sono rilevabili.

* ''Tunnel mode''

*#connessione gateway-to-gateway;

*#in caso di cifratura, viene cifrato tutto il pacchetto IP originale;

*#utilizzato per realizzare le VPN;

*#computazionalmente oneroso;

*#solo i gateway devono avere il software IPsec;

*#si hanno punti di centralizzazione, quindi single point of failure;

*#utilizza un doppio [[imbustamento|incapsulamento]], ponendo come payload della comunicazione tra indirizzi gateway quanto si ottiene cifrando l'unione di indirizzi mittente e destinatario degli end-point col payload effettivo; adottando il protocollo Encapsulating Security Payload, gli indirizzi mittente e destinatario degli end-point non sono quindi più rilevabili (restano invece rilevabili adottando AH).

Le due modalità sono supportate sia da AH che da ESP.

===Security Association e Security Policy===

IPsec può essere utilizzato anche per connessioni tra gateway e host.

Il concetto di '''Security Association''' (in breve '''SA''') è alla base del funzionamento di IPsec. Una SA è un "contratto" fra le due entità coinvolte nella comunicazione; in essa vengono stabiliti i meccanismi di protezione e le chiavi da utilizzare durante il successivo trasferimento dei dati. Nell'ambito di IPsec, stabilire le security association è compito del protocollo IKE, sebbene sia possibile anche impostarle manualmente; ovviamente la procedura manuale è sconsigliata in quanto può introdurre errori che indeboliscono il tunnel. <br>

==== Security Association e Security Policy ====

Il concetto di '''Security Association''' (in breve '''SA''') è alla base del funzionamento di IPsec. Una SA è un "contratto" fra le due entità coinvolte nella comunicazione; in essa vengono stabiliti i meccanismi di protezione e le chiavi da utilizzare durante il successivo trasferimento dei dati. Nell'ambito di IPsec, stabilire le security association è compito del protocollo [[Internet key exchange|IKE]], sebbene sia possibile anche impostarle manualmente; la procedura manuale è sconsigliata in quanto può introdurre errori che indeboliscono il tunnel.

Una peculiarità delle SA è che individuano una comunicazione unidirezionale; quindi durante la creazione della connessione le entità coinvolte creano e gestiscono una SA per ognuno dei versi della comunicazione, quindi 2 SA individuano un canale [[full-duplex]]. Al fine di semplificare la gestione delle SA, viene utilizzato un apposito [[database]] detto '''SAD''' ('''S'''ecurity '''A'''ssociation '''D'''atabase), dove viene tenuta traccia delle SA attive.

UnaIn particolare una SA è costituita dai seguenti parametri:

* Gli [[indirizzo IP|indirizzi IP]] dei ''peer'' coinvolti nella comunicazione;

* Il protocollo che verrà utilizzato per il tunnel (AH o ESP);

* le tecniche di cifratura utilizzate e le relative chiavi;

* Un intero a 32 bit chiamato '''SPI''', acronimo per '''S'''ecurity '''P'''arameter '''I'''ndex.

Dall'esame dei parametri di una SA, si deducededucono chequindi vi sono contenutetutte le informazioni necessarie per stabilire le modalità in che modocui il traffico debba essere protetto; il passo successivo è definire ''quale'' traffico debba essere protetto: di questo si occupa la '''S'''ecuritySecurity Policy'''P'''olicy (in breve '''SP'''). Una SP è una regola che stabilisce che tipo di traffico deve essere instradato nel tunnel e quindi essere coperto da IPsec; in modo analogo alle SA, le SP sono contenute in un SPD ('''S'''securityecurity '''P'''olicy '''D'''atabase).

La security policy contiene:

* Indirizzo sorgente e indirizzo destinazione del pacchetto. Tale informazione è già contenuta nella SA e quindi può sembrare ridondante. In realtà questa informazione ha senso quando viene utilizzato il Tunnel mode.

* Il protocollo e la relativa porta da instradare nel tunnel. Questa opzione dipende dall'implementazione del protocollo e non è sempre contemplata; nel caso non sia disponibile, tutto il traffico prodotto viene veicolato nel tunnel.

* Un identificativo della SA da utilizzare per processare i dati.

Una volta stabilita la ''security association'' e la ''security policy'', può cominciare la comunicazione che sfrutterà il protocollo AH o il protocollo ESP cui verrà passato il parametro SPI, che permetterà di risalire alle tecniche crittografiche da utilizzare per la trasmissione.

== Protocolli di IPsec ==

=== IKE ===

{{vedi anche|Internet key exchange}}

====Descrizione====

IKE è un [[acronimo]] per '''I'''nternet '''k'''ey '''ex'''change ed è il protocollo usato per stabilire una '''security association''' nella suite di protocolli '''IPsec'''. Questo protocollo è definito in RFC 2409. E' un protocollo di livello applicazione e utilizza il protocollo [[UDP]] come [[Livello di trasporto|protocollo di trasporto]]; la [[Porta (protocolli di trasporto)|porta]] su cui viene stabilita la connessione è 500.<br> L'obiettivo di IKE è stabilre uno ''shared session secret'', ossia una chiave condivisa corrispondente alla sessione da instaurare e a tal fine utilizza l'algoritmo di [[Diffie-Hellman]]; dallo ''shared secret'' vengono successivamente derivate le chiavi crittografiche che verranno utilizzate per la successiva comunicazione.

==== Descrizione ====

Al fine di autenticare le entità coinvolte nella comunicazione possono essere utilizzate tecniche a chiave simmetrica o, alternativamente, a chiave asimmetrica; in quest'ultimo caso si fa ricorso a strutture [[PKI]] e all'uso di [[Certificato digitale|certificati digitali]].

IKE è un [[acronimo]] per '''I'''nternet '''k'''ey '''e'''xchange ed è il protocollo usato per stabilire una '''security association''' nella suite di protocolli '''IPsec'''. Questo protocollo è definito in RFC 4306. È un protocollo di [[livello applicazioni|livello applicazione]] e utilizza il protocollo [[User Datagram Protocol|UDP]] come [[Livello di trasporto|protocollo di trasporto]]; la [[Porta (reti)|porta]] su cui viene stabilita la [[connessione (informatica)|connessione]] è 500.

L'obiettivo di IKE è stabilire uno ''shared session secret'', ossia una chiave condivisa corrispondente alla sessione da instaurare e a tal fine utilizza l'algoritmo di [[Scambio di chiavi Diffie-Hellman|Diffie-Hellman]]; dallo ''shared secret'' vengono successivamente derivate le chiavi crittografiche che verranno utilizzate per la successiva comunicazione.

Al fine di autenticare le entità coinvolte nella comunicazione possono essere utilizzate tecniche a chiave simmetrica o, alternativamente, a chiave asimmetrica; in quest'ultimo caso si fa ricorso a [[infrastrutture a chiave pubblica]] (PKI) e all'uso di [[Certificato digitale|certificati digitali]].

=== Authentication Header (AH) ===

==== Descrizione ====

'''Authentication Header''' (abbreviato '''AH'''), è un protocollo che fa parte della suite IPsec. Il suo compito è quello di fornire un controllo di integrità pacchetto per pacchetto, verifica dell'autenticità del mittente e protezione contro i [[replay attack]]. AH non garantisce in alcun modo la confidenzialità del messaggio.

L'autenticità è garantita tramite funzioni di hash a chiave simmetrica, ossia tramite il meccanismo delle pre-shared keys. Per poter comunicare, due entità devono condividere la medesima chiave; tale chiave viene combinata con il messaggio originale e quindi viene calcolato il [[checksum]] tramite una funzione di hash crittografico(MD5 o SHA). Il messaggio e il checksum vengono, infine, inviati al ''peer'' remoto.

Il ''peer'' remoto riceve il messaggio; dato che questo è in chiaro, lo può leggere, combinare con la chiave di cui è a conoscenza e calcolare il checksum. Se il checksum corrisponde a quello inviato, il messaggio è autentico e viene accettato altrimenti viene scartato in quanto è stato modificato in un modo non consentito dallo standard.

===Authentication Header===

====Descrizione====

L''''A'''uthentication '''H'''eader (abbreviato '''AH'''), è un protocollo che fa parte della suite

[[IPsec]]. Il suo compito è quello di fornire un controllo di integrità pacchetto per

pacchetto, verifica dell'autenticità del mittente e protezione contro i

[[replay-attack]]. Facciamo notare che AH '''non''' garantisce in alcun modo la confidenzialità del messaggio.<br/>

L'autenticità è garantita tramite funzioni di [[hash]] a chiave simmetrica, ossia tramite il meccanismo delle pre-shared keys. Per poter comunicare, due entità devono condividere la medesima chiave; tale chiave viene combinata con il messaggio originale e quindi viene calcolata la [[checksum]] tramite una funzione di '''one-way hash'''. Il messaggio e la checksum vengono, infine, inviati al ''peer'' remoto.

Il ''peer'' remoto riceve il messaggio; dato che questo è in chiaro, lo può leggere, combianre con la chiave di cui è a conoscenza e calcolare la checksum. Se la checksum corrisponde a quella inviata, il messaggio è autentico e viene accettato altrimenti viene scartato in quanto è stato modificato in un modo non consentito dallo standard.<br/>

Il protocollo AH è progettato per proteggere l'intero pacchetto IP inviato; tuttavia bisogna considerare che alcuni campi dell'header IP, come il '''TTL''', variano durante la trasmissione;

queste modifiche devono essere necessariamente consentite, per cui prima di calcolare lail checksum, i campi cui è permesso variare vengono posti a '''0'''.

====Formato del pacchetto====

==== Formato del pacchetto ====

Di seguito viene illustrata la struttura del pacchetto AH (ogni casella rappresenta 1 [[byte]]).

{| border="1" cellspacing="0" cellpadding="2px"

| style="text-align:center;border:0;width:25%" | 0

| style="text-align:center;border:0;width:25%" | 1

| style="text-align:center;border:0;width:25%" | 2

| style="text-align:center;border:0;width:25%" | 3

|--

<!-- | 0 1 2 3 4 5 6 7 -->

Riga 69 ⟶ 93:

<!-- | 0 1 2 3 4 5 6 7 -->

<!-- |-- -->

| style="text-align:center;" | Header Successivosuccessivo

| style="text-align:center;" | Dimensione Payload

| colspan="2" style="text-align:center;" | RISERVATO

|--

| colspan="4" style="text-align:center;" | SecuitySecurity Parameter Index (SPI)

|--

| colspan="4" style="text-align:center;" | NumeroSequence di SequenzaNumber

|--

| colspan="4" style="text-align:center;" |

Dati per l'autenticazione (lunghezza variable)

|}

; Header Successivosuccessivo: Indica che tipo di protocollo verrà dopo.

; Dimensione Payload (8 bit): La lunghezza dell'AH in word (1 word = 32 bit) meno 2. Per esempio, 96 sono i bit di default del campo Authentication Data, più altri 96 bit per i campi di lunghezza fissa di AH fanno 6 word (96+96 = 192 bit, diviso per 32 = 6). Sottraendo 2 risulta quindi 4 il valore contenuto della dimensione del payload standard.

; Dimensione Payload: Indica la dimensione del pacchetto AH contata in word di 32 bit.

; RISERVATO: Spazio lasciato per sviluppi futrifuturi. Tutti i bit di questo campo vengono settatiimpostati a 0.

; Security Parameter Index: Questo campo identifica i parametri di sicurezza in cmbinazionecombinazione con l'indirizzo IP. In genere è un numero pseudo-casuale che identicaidentifica la [[Security association|security association]] cui fa parte questo pacchetto.

; Numero di sequenzaSequence Number: Una successione di numeri monatonicamente[[Funzione crescentimonotona|monotonicamente]] checrescenti. serve adPer impedire i [[replay- attack]], il sequence number quando raggiunge il valore massimo (2^{32}-1) non deve ritornare a 0, ma una nuova SA deve essere creata.

; Dati per l'autenticazione: Contiene l'Integrity Check Value (ICV) e rappresenta l'[[HMAC]] calcolato dal mittente del messaggio. L'HMAC viene calcolato utilizzando i campi dell'header IP (con il [[Time to live|TTL]] originario), i campi dell'header AH tranne i dati dell'autenticazione (viene considerato a 0) e infine tutti i dati degli header di livello superiore, compresi quelli applicativi, che non vengono modificati durante il trasporto.

; Dati per l'autenticazione : Contiene le informazioni necessarie ad autenticare la i dati.

==== Transport mode e Tunnel mode ====

AH supporta nativamente sia il ''transport mode'' che il ''tunnel mode''. In transport mode vengono protetti solo i protocolli di livello superiore a quello di rete ([[Transmission Control Protocol|TCP]], [[User Datagram Protocol|UDP]], etc); in tunnel mode il pacchetto IP originale viene incapsulato in un nuovo pacchetto IP, dopo essere stato elaborato da AH. Ne spieghiamo il funzionamento con l'ausilio di alcuni disegni.

Il metro di confronto è senza dubbio il pacchetto IP originale; in presenza di un collegamento basato su IPsec il pacchetto viene, ovviamente, alterato.

Riga 98 ⟶ 122:

<small>Pacchetto IP originale</small>

A seconda della modalità di funzionamento di [[IPsec]] (tunnel mode o transport mode), il pacchetto originale viene alterato in modo diverso.

{| border="2" width="60%" cellspacing=0

|style="width:17%"| Header IP

Riga 123 ⟶ 147:

La linea azzurra indica le zone del pacchetto che sono autenticate. Dal punto di vista della protezione, in entrambi i casi, i pacchetti vengono protetti completamente. Notiamo che nell'header IP, alcuni campi variano durante il transito nella rete, ad esempio il [[Time to live|TTL]].

Questi campi vengono posti a '''0''' prima di calcolare la [[funzione di [[hash]], necessaria per la protezione del pacchetto. Da quanto appena detto si evince subito che il protocollo AH è incompatibile con le varie tecniche di [[Network address translation|NAT]]; difatti se vengono alterati i campi indirizzo nell'header IP (in entrambe le modalità), in ricezione la checksum fallisce subito.

=== Encapsulating Security Payload (ESP) ===

==== Descrizione ====

'''Encapsulating Security Payload''', denotato con l'[[acronimo]] '''ESP''', è un protocollo che fa parte della suite IPsec. Il suo obiettivo è fornire autenticità, confidenzialità e controllo di integrità alla comunicazione. Contrariamente a quanto fa [[Authentication Header|AH]], l'header IP non viene coperto dai controlli. Al pari di AH, però, supporta sia il tunnel mode che il transport mode.

====Descrizione Formato del pacchetto ====

'''Encapsulating Security Payload''', denotato con l'[[acronimo]] '''ESP''', è un protocollo che fa parte della suite [[IPsec]]. Il suo obiettivo è fornire confidenzialità e controllo di integrità e autenticità alla comunicazione. Contrariamente a quanto fa [[AH]], l'header IP non viene coperto dai controlli. Al pari di [[AH]], però, supporta sia il tunnel mode che il transport mode.

====Formato del pacchetto====

Di seguito viene riportato il formato del pacchetto '''ESP''' (ogni casella rappresenta 1 [[byte]]).

{| border="1" cellspacing="0" cellpadding="2px" width="50%"

| style="text-align:center;" width="25%"| '''0'''

| style="text-align:center;" width="25%"| '''1'''

| style="text-align:center;" width="25%"| '''2'''

| style="text-align:center;" width="25%"| '''3'''

|--

<!-- | 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7

Riga 150 ⟶ 173:

Payload * (variable)

|--

| style="border-top:none;" | &nbsp;

| colspan="3" style="text-align:center;border-bottom:none;" | Padding (0-255 bytesbyte)

|--

| style="border-right:none;" | &nbsp;

| style="border-left:none;border-top:none;" | &nbsp;

| style="text-align:center;" | Pad Length

| style="text-align:center;" | Next Header

|--

| colspan="4" style="text-align:center;" |

Authentication Data (variable)

|}

; Security Parameters Index (SPI) : Al pari di quanto avviene in [[AH]], questo campo, in combinazione con l'indirizzo IP, individua la [[Security Association]] cui appartiene il pacchetto.

; Sequence Number : Una successione di numeri monoticamentemonotonicamente crescente, che identifica il pacchetto all'interno delle Security Association e previene da [[replay- attack]].

; Payload : I dati che devono essere trasferiti

; Padding : È un campo di riempimento. È necessario in quanto alcuni codici di cifratura lavorano su blocchi di lunghezza fissa. Serve a far crescere la dimensione dei dati fino a divenire multiplo del blocco che l'algoritmo in uso riesce a gestire.

; Pad Length : Rappresenta, in bitottetti, la dimensione dei dati di padding aggiunti.

; Next Header : Identifica il protocollo dei dati trasferiti

; Authentication Data : Contiene i dati usati per autenticare il pacchetto.

Come si può vedere dalla struttura del pacchetto (ma sarà illustrato meglio in seguito), ESP "''avvolge''" i dati dei protocolli di livello superiore, contrariamente a quanto fa AH che antepone un header.

==== Tunnel mode e Transport mode ====

Essendo un protocollo per il trasferimento dati della usitesuite IPsec, ESP supporta sia il Tunnel mode che il Transport mode. A seconda della modalità tratta i dati in modo differente. Prima di descrivere l'incpsulamentoincapsulamento dei dati mostriamo il pacchetto IP originale, che transiterebbe sulla rete in assenza di IPsec

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

|style="width:2523%;background-color:gainsboro"| Header IP

|style="width:25%;background-color:gainsboro"| Header TCP

|style="width:5052%;background-color:gainsboro"| Dati

|}<small>Pacchetto IP originale</small>

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

|style="width:13%;border:1;background-color:gainsboro" | Header IP

|style="width:13%;background-color:orange;font-weight:bold" | Header ESP

|style="width:13%;background-color:limegainsboro" | Header TCP

|style="width:35%;background-color:limegainsboro" | Dati

|style="width:13%;background-color:orange;font-weight:bold" | Trailer ESP

|style="width:13%;background-color:orange;font-weight:bold" | ESP auth

|}

{| width="85%"

|style="width:26%;"| &nbsp;

|style="background-color:lime;text-align:center"| Dati crittografati

|style="width:13%;"| &nbsp;

|}

{| width="85%"

Riga 189 ⟶ 217:

|style="background-color:cyan;text-align:center"| Dati autenticati

|style="width:13%;"| &nbsp;

|}<small>ESP in TrasportTransport mode</small>

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

|style="width:1112%;background-color:yellow" | Nuovo Header IP

|style="width:11%;background-color:orange;font-weight:bold" | Header ESP

|style="width:1611%;background-color:limegainsboro" | Header IP interno

|style="width:1612%;background-color:limegainsboro" | Header TCP

|style="width:2432%;background-color:limegainsboro" | Dati

|style="width:11%;background-color:orange;font-weight:bold" | Trailer ESP

|style="width:11%;background-color:orange;font-weight:bold" | ESP auth

|}

{|width="9095%"

|style="width:23%"| &nbsp;

| style="background-color:lime;text-align:center;"| Dati crittografati

|style="width:11%"| &nbsp;

|}

{|width="95%"

|style="width:12%"| &nbsp;

| style="background-color:cyan;text-align:center;"| Dati autenticati

|style="width:11%"| &nbsp;

|} <small>ESP in Tunnel mode</small>

Le linee verdi sottendono la parte di pacchetto che viene sottoposta a crittografia, mentre le linee azzurre sottendono la parte di pacchetto che viene sottoposta a controllo di autenticità e integrità;. leNella zonemodalità verditrasporto indicanol'header leIP zoneoriginale dirimane in chiaro (quindi non protetto) per l'instradamento del pacchetto fino all'endpoint destinatario che vengonosarà protetteanche tramiteresponsabile algoritmidi processare l'autenticazione e la decrittazione del payload ESP. Diversamente, nella modalità tunnel l'header IP originale viene crittografato (quindi protetto) assieme all'header TCP e ai dati, ed è quindi necessario introdurre un nuovo IP header (in giallo) con le informazioni necessarie per l'instradamento fino al dispositivo delegato ( [[Gateway (informatica)|gateway]] / [[firewall]] ) alla chiusura del tunnel IPsec con decrittazione del payload ESP, dispositivo che provvederà a sua volta ad inoltrare il pacchetto autenticato e decifrato verso l'endpoint dichiarato nell'header IP originale (in crittograficigrigio). Per quanto riguarda gli algoritmi di cifratura possono essere utilizzati [[DESData Encryption Standard]] (DES), [[3DES]], [[Advanced Encryption Standard|AES]] e [[Blowfish]].

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. DagliCome schemiillustrato vistinegli prima si nota cheschemi, 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 [[Network address translation|NAT]], in particolare in quelli statici. Tuttavia esistono soluzioni ''ad-hoc'' per il funzionamento congiunto di IPsec e NAT, come il [[NAT Traversal]]traversal.

=== NAT Traversaltraversal ===

==== Descrizione ====

[[Attraversamento NAT|NAT traversal]] (o più in breve NAT-T) è il nome di un protocollo facente parte della suite IPsec e standardizzato in diversi [[Request for Comments|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 natNAT 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èné in Tunnel mode nèné in Transport mode, per cui risulta adatto nel caso in cui il natNAT 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 trasportoreti)|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 negaziazionenegoziazione '''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 portiporte UDP e l'entità "''nat-tata''" comincia a inviare delle frame '''keepalive'''; queste frame servono a mantenere fissofisse ille portoporte di comunicazione sul router e ad impedirgli di riassegnarloriassegnarle ad una nuova comunicazione.

Descriviamo come viene incapsulato il pacchetto originale ESP.

Riga 250 ⟶ 283:

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

I campi segnati in <fontspan style="background-color:green;font-weight:bold">verde scuro</fontspan> 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 ==

;* RFC 24014301: Security Architecture for the Internet Protocol

;* RFC 2402: Authentication Header

;* RFC 2406: Encapsulating Security Payload

;* RFC 2407: IPsec Domain of Interpretation for ISAKMP (IPsec DoI)

;* RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)

;* RFC 2409: Internet Key Exchange (IKE)

;* RFC 2410: The NULL Encryption Algorithm and Its Use With IPsec

;* RFC 2411: IP Security Document Roadmap

;* RFC 2412: The OAKLEY Key Determination Protocol

;* RFC 39743947: Negotiation of NAT-Traversal in the IKE

== Voci correlate ==

==Collegamenti esterni==

* [[Sicurezza informatica]]

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

* [[HTTPS]]

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

* [[Transport Layer Security]]

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

* [[Secure Shell]]

* [[IP spoofing]]

== Altri progetti ==

{{interprogetto}}

== Collegamenti esterni ==

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

*{{cita web|https://www.linux.it/~davide/doc/tesi_html/index.html|IPsec e TLS a confronto: funzioni, prestazioni ed estensioni}}

*{{cita web | 1 = http://www.isaserver.org/articles/IPSec_Passthrough.html | 2 = How to pass IPSec traffic through ISA Server | accesso = 4 luglio 2005 | dataarchivio = 3 maggio 2005 | urlarchivio = https://web.archive.org/web/20050503121918/http://www.isaserver.org/articles/ipsec_passthrough.html | urlmorto = sì }}

{{IPstack}}

{{Controllo di autorità}}

{{Portale|Crittografia|Sicurezza informatica|Telematica}}

[[Categoria:Standard Internet]]

[[Categoria:ProtocolliInternet di reteProtocol]]

[[Categoria:Protocolli livello rete]]

[[Categoria:Sicurezza di rete]]

[[Categoria:Protocolli crittografici]]

[[de:IPsec]]

[[en:IPsec]]

[[es:IPsec]]

[[fi:IPsec]]

[[fr:IPsec]]

[[ja:IPsec]]

[[nl:IPSec]]

[[pl:IPsec]]

[[zh:安全IP]]