IPsec: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Guam (discussione | contributi)
Guam (discussione | contributi)
m disambiguati e tolti link ridondanti
Riga 1:
IPsec è l'abbreviazione di '''IP Security''' ed è uno standard per ottenere connessioni basate su IP sicure.
La sicurezza viene raggiunta attraverso la cifratura e l'autenticazione dei pacchetti [[Internet Protocol|IP]]. La sicurezza viene fornita, quindi, a [[Livello di rete|livello rete]].
 
==Panoramica dello standard==
Riga 82:
; Dimensione Payload: Indica la dimensione del pacchetto AH contata in word di 32 bit.
; RISERVATO: Spazio lasciato per sviluppi futri. Tutti i bit di questo campo vengono settati a 0.
; Security Parameter Index: Questo campo identifica i parametri di sicurezza in cmbinazione con l'indirizzo [[IP]]. In genere è un numero pseudo-casuale che identica la [[Security association|security association]] cui fa parte questo pacchetto.
; Numero di sequenza : Una successione di numeri monatonicamente crescenti che serve ad impedire [[replay-attack]].
; Dati per l'autenticazione : Contiene le informazioni necessarie ad autenticare la i dati.
Riga 88:
====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 ([[TCP]], [[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.
 
{| border="1" width="50%" cellspacing=0
Riga 122:
 
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)===
Riga 160:
Authentication Data (variable)
|}
; Security Parameters Index (SPI) : Al pari di quanto avviene in [[AH]], questo campo, in combinazione con l'[[IP|indirizzo IP]], individua la [[Security Association]] cui appartiene il pacchetto.
; Sequence Number : Una successione di numeri monoticamente crescente, che identifica il pacchetto all'interno delle Security Association e previene da [[replay-attack]].
; Payload : I dati che devono essere trasferiti
Riga 214:
 
====Scenario====
Il [[Network_address_translationNetwork 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'''.