IPsec: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
punteggiatura e digitazione |
m Bot: fix citazione web (v. discussione) |
||
Riga 13:
Per quanto riguarda il secondo aspetto, esistono due protocolli: [[Authentication Header]] (AH) e [[Encapsulating Security Payload]] (ESP).
'''AH''' fornisce autenticazione e [[integrità dei dati|integrità del messaggio]], ma non offre la [[confidenzialità]] ed è il protocollo IP 51.<br />
'''ESP''' fornisce invece autenticazione, [[confidenzialità]] e controllo di [[integrità dei dati|integrità del messaggio]] ed è il protocollo IP 50. Per questi motivi ESP è molto più usato di AH.
Attualmente esiste un solo protocollo per lo ''scambio delle chiavi'', il protocollo '''[[Internet key exchange
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 Comments|RFC]] 2401-2412.
Riga 44:
====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; ovviamente 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.
Riga 62:
===IKE===
====Descrizione====
[[
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.
Riga 69:
===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.
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;
Riga 241:
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 negoziazione '''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.
Una volta stabilito chi subisce il NAT, la comunicazione si sposta su una nuova coppia di porte UDP e l'entità "''nat-tata''" comincia a inviare delle frame '''keepalive'''; queste frame servono a mantenere fisse le porte di comunicazione sul router e ad impedirgli di riassegnarle ad una nuova comunicazione.
Riga 292:
==Collegamenti esterni==
*http://www.ipsec-howto.org/italian/x151.html
*
*
{{IPstack}}
| |||