IPsec: differenze tra le versioni

Versione delle 00:38, 26 ott 2005

Versione delle 00:59, 26 ott 2005

Riga 43:

===IKE===

====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 (reti)|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.

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]].

Riga 69:

<!-- | 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

Riga 80:

Dati per l'autenticazione (lunghezza variable)

|}

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

; Dimensione Payload: Indica la dimensione del pacchetto AH, calcolata in parole di 32 bit.

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

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

; Numero di successione: Una successione di numeri monotonicamente crescenti che serve ad impedire i [[replay-attack]].

Riga 151:

|--

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

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

|--

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

Riga 161:

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 monoticamente 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 bit, 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.

Riga 216:

====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 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 (reti)|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.