3. Pacchetti IPv6.

 

3.1 Frammentazione

 

La frammentazione è il processo di divisione di un datagram IP in pezzi più piccoli (frammenti), quando essi devono viaggiare su una rete che non può gestire il datagram della dimensione originaria. Ogni frammento ha lo stesso formato di un datagram; i campi dell'Header IP specificano se un datagram è un frammento oppure no. Il protocollo IP del nodo destinazione deve riassemblare i frammenti per produrre il datagram originale.

In IPv4 la frammentazione avviene all'occorrenza: ogni router intermedio deve frammentare i datagram che risultano troppo grandi per attraversare il link successivo; il mittente non viene a conoscenza di tali frammentazioni intermedie.

In IPv6, a differenza della versione 4, la frammentazione viene effettuata in modalità end-to-end: la sorgente si occupa di dimensionare opportunamente i datagram e la destinazione si occupa di riassemblarli, senza coinvolgere i router intermedi.

 IPv6 richiede che ogni link consenta il passaggio di pacchetti pari almeno a 1280 byte. 

In caso di frammentazione viene inserito nel pacchetto IPv6 il Fragment Header, che contiene informazioni che vengono esaminate solo dalla destinazione. In pratica, prima di inviare un pacchetto, il nodo sorgente ha due possibilità:

esegue un algoritmo per scoprire la dimensione massima (dei pacchetti) consentita sul percorso che porta alla destinazione;

oppure

invia solo pacchetti di al più 1280 byte.

L'IETF raccomanda tuttavia di utilizzare il primo metodo.

La motivazione che ha portato ad utilizzare la frammentazione end-to-end, è data dalla volontà di ridurre l’overhead dei router, così che essi possano gestire più pacchetti per unità di tempo. Tuttavia questa tecnica altera un principio base di IPv4, in base al quale i percorsi seguiti dai pacchetti possono variare dinamicamente senza che la sorgente sia avvisata. Nel nuovo scenario fornito da IPv6, invece, modificare un percorso non è più così semplice. Pertanto quando un router non riesce ad instradare un pacchetto su un link, poiché scopre che ha una dimensione massima (dei pacchetti che lo attraversano) consentita inferiore alla dimensione del pacchetto stesso, deve inviare alla sorgente un messaggio di errore. La sorgente a questo punto riapplica l’algoritmo per scoprire la nuova dimensione massima dei pacchetti consentita e frammenta il pacchetto di conseguenza.

 

 

 

 

3.2 Formato del pacchetto IPv6

 

Un pacchetto IPv6 ha la seguente forma generale: 

 

Header IPv6

di base

Extension

 Header 1

...

Extension

 Header N

DATI

 

un Header di base di IPv6, sempre presente con tutti i suoi campi;

un insieme di Extension Header che definiscono opzioni del protocollo IPv6;

i dati;

 

L'Header di base è a sua volta costituito da un insieme di campi, che adesso vediamo in dettaglio:

 

Version

Traffic Class

Flow Label

Payload Lenght

Next Header

Hop Limit

 

Source Address

 

 

Destination Address

 

 

  

  1. Version, che ha valore 6;

  2. Traffic Class, che sostituisce il campo Type of service della versione 4;

  3. Flow Label, viene utilizzato dalla sorgente per etichettare sequenze di pacchetti per i quali viene richiesta una gestione speciale da parte dei router. La sequenza (o flusso) si riferisce a pacchetti che vanno da una particolare sorgente a una certa destinazione. La gestione di tali pacchetti deve essere indicata o in un apposito protocollo, o nell’opzione hop-by-hop. In particolare, ci possono essere più flussi attivi contemporaneamente per una certa coppia sorgente-destinazione;

  4. Payload Length, contiene la dimensione del payload, ossia la dimensione di tutto il pacchetto escluso l’Header di base (che è sempre di 40 byte);

  5. Next Header, identifica il tipo di header immediatamente successivo a quello di IPv6;

  6. Hop Limit, determina il numero di hop che un pacchetto può attraversare prima di poter essere scartato (equivale al campo Time-to-live della versione 4);

  7. Source Address;

  8. Destination Address;

 

Tutte le informazioni aggiuntive, non previste nell’Header di base, possono essere inserite utilizzando i cosiddetti extension header. Essi sono dei campi opzionali e che pertanto sono presenti nel pacchetto solo quando necessario. In particolare le informazioni contenute nelle estensioni, devono essere esaminate soltanto dalla sorgente e dalla destinazione, ma non dai nodi intermedi. Questo rende più veloce l’instradamento. L’unica eccezione a questa regola è costituita dall’opzione Hop-by-Hop, che contiene informazioni che devono essere esaminate da tutti i nodi lungo il cammino.

Ogni pacchetto può contenere zero, una o più estensioni. In particolare il contenuto di ogni opzione determina se l’estensione successiva debba essere o meno esaminata. Questo vuol dire che le estensioni devono essere esaminate rispettando strettamente l’ordine in cui esse compaiono nel pacchetto. Non a caso, se più estensioni sono presenti nello stesso pacchetto, si raccomanda di rispettare il seguente ordine:

  1. IPv6 Header;

  2. Hop-by-hop options Header: definisce opzioni particolari che richiedono l’hop-by-hop;

  3. Routing Header: fornisce informazioni ausiliari per il routing;

  4. Fragment Header: contiene informazioni per la frammentazione ed il riassemblaggio;

  5. Authentication Header: fornisce integrità ed autenticazione al pacchetto;

  6. Encapsulating Security Payload Header: fornisce privacy;

  7. Destination options Header: contiene informazioni opzionali che vengono esaminate nel nodo destinazione;

  8. Header dello strato superiore (TCP o UDP).

 

L’elenco precedente include tutte le estensioni attualmente esistenti.

Da notare che il rispetto dell’ordine prima indicato è, come detto, solo una raccomandazione e non un obbligo, pertanto i nodi IPv6, devono accettare e cercare di esaminare le estensioni in qualsiasi ordine esse compaiano. Quanto detto non vale per la Hop-by-Hop che deve obbligatoriamente essere inserita dopo l’Header di IPv6.

Ogni extension header include al proprio interno un campo Next Header che identifica il tipo di header che segue immediatamente dopo. Ad esempio, se il campo Next Header dell’estensione Hop-by-Hop vale 43, allora significa che la successiva estensione è il Routing Header. Se un nodo non riconosce il valore del campo Next Header, deve scartare il pacchetto ed inviare un messaggio di errore alla sorgente, dichiarando di non riconoscere la successiva estensione presente nel pacchetto.

 

 

 

 

3.3 Sicurezza in IPv6

La sicurezza in Internet è affidata ad una suite di protocolli che prende il nome di IPsec. Essa offre servizi di autenticazione e privacy e può essere usata sia con IPv4 che con IPv6. 

In particolare in  IPv6 ci sono due specifici extension header che forniscono servizi di sicurezza: “IP Authentication Header (AH)” e “IP Encapsulation Security Payload” (ESP).

IP Authentication Header (AH) ha il compito di fornire ai datagrammi IP integrità e autenticazione, ma non confidenzialità. AH non fornisce confidenzialità affinché possa essere usato anche in luoghi dove l’importazione, l’esportazione e l’uso della crittografia è limitato. AH supporta sicurezza tra due o più host, tra due o più gateway, tra host e gateway (vedere "Approfondimento I: gateway di sicurezza")

 

IP Encapsulation Security Payload (ESP) fornisce integrità, autenticazione e confidenzialità ai datagrammi IP. ESP supporta sicurezza tra due o più host, tra due o più gateway, tra host e gateway (vedere "Approfondimento I: gateway di sicurezza").

 

Sia AH che ESP possono essere utilizzati in due modalità: Transport Mode e Tunnel Mode; nel primo caso viene fornita protezione solo ai dati, mentre nel secondo caso viene fornita protezione all'intero datagramma IP.

 

Un concetto fondamentale sia per AH che per ESP è quello di Security Association (SA): una SA è una relazione, fra due entità in comunicazione, che identifica particolari condizioni di sicurezza.

Vediamo adesso in maggior dettaglio dettaglio ciascuno di questi oggetti. 

 

 

 

 

3.4 Security Association

 

Un’associazione di sicurezza è una relazione one-way tra il mittente ed il destinatario. Se è richiesto uno scambio bidirezionale sicuro, allora sono necessarie due associazioni di sicurezza.

Ogni SA è identificata univocamente dalla combinazione dell'indirizzo del destinatario e di un determinato Security Parameter Index (SPI)

Ogni implementazione di AH e di ESP deve supportare il concetto di Security Association, sebbene possa supportare anche ulteriori parametri come componenti di una SA. Della creazione, gestione e distruzione delle SA si occupa  l’Internet Security Association and Key Management Protocol (ISAKMP).

(Per maggiori dettagli vedere l' "Approfondimento II: Security Association").

 

 

 

 

3.5 Authentication Header

 

L'AH contiene informazioni per l'autenticazione dei datagrammi IP. L'autenticazione avviene attraverso il calcolo con chiave segreta di una funzione di autenticazione crittografica sul datagramma IP. Il mittente calcola l'autenticazione dei dati prima di spedire il pacchetto IP autenticato. 

L’Header di autenticazione è composto dai seguenti campi: 

 

Next Header

Payload Length

Reserved

Security Parameters Index

Sequence Number to Replay Prevention

...

Authentication Data

(Lunghezza Variabile)

 

 Next Header (8 bit): identifica il tipo di header seguente all’header corrente. Il valore di questo campo è scelto in un insieme di numeri assegnati dall’Internet Assigned Numbers Authority (IANA);

Payload Length (8 bit): lunghezza del campo dati autenticazione; 

Reserved (16 bit): riservato per eventuali usi futuri. Viene settato a zero; 

Security Parameters Index (SPI) (32 bit): in combinazione con l’indirizzo IP di destinazione ed il protocollo di sicurezza (AH), identifica univocamente l’associazione di sicurezza per questo datagramma. L’insieme dei valori SPI nell’intervallo da 1 a 255 sono riservati dalla IANA per usi futuri; un valore SPI riservato non sarà assegnato; 

Sequence Number to Replay Prevention: è un campo di 64 bit usato per garantire che ogni pacchetto scambiato fra due parti sia differente. Ogni associazione di sicurezza di IPsec specifica se la replay prevention è usata per un’associazione di sicurezza. Se esso non è in uso il campo di autenticazione di dati seguirà direttamente il campo SPI. Il campo di 64 bit è un contatore che inizia con il valore 1. La chiave segreta condivisa non deve essere usata per un periodo di tempo maggiore del ciclo del contatore, cioè 264 pacchetti useranno una singola chiave. Dopo la ricezione, il valore di replay viene incrementato; 

Authentication Data (variabile): contiene il valore per il controllo d’integrità del pacchetto (Integrity Check Value – ICV). Il campo deve essere un intero di lunghezza multipla di 32 bit. Questo campo potrebbe includere un padding esplicito utilizzato per assicurare che la lunghezza dell’Header AH sia un intero multiplo di 64 bit. Tutte le implementazioni devono supportare tale padding. Il valore di questo campo dipende dallo specifico algoritmo di cifratura utilizzato.

 

Il non ripudio può essere fornito da alcuni algoritmi di autenticazione (algoritmi asimmetrici) usati con l'AH, ma non è necessariamente supportato da tutti gli algoritmi che possono essere usati con AH. L'algoritmo di default è MD5 con chiave, che da solo non fornisce il non ripudio.

 

La confidenzialità e la protezione dall'analisi del traffico non sono supportati da AH. 

L'uso di AH aumenta i costi dell'IP processing nei sistemi condivisi e aumenta la latenza delle comunicazioni. Ciò è dovuto principalmente al calcolo dell'autenticazione dei dati da parte del mittente e al calcolo dell'autenticazione e al confronto dei dati di ogni datagramma IP contenente AH, da parte di ogni ricevente.

AH fornisce una sicurezza maggiore di quella che esiste attualmente in Internet, e non influenza la portabilità e non aumenta significativamente i costi implementativi.

Sebbene sia possibile implementare AH su un gateway di sicurezza che protegge una trusted network (vedere anche l' "Approfondimento I: gateway di sicurezza"), questa modalità operativa non è incoraggiata. AH dovrebbe piuttosto essere usato dall'origine fino alla destinazione. 

Tutti gli host abilitati ad usare IPv6 devono implementare AH almeno con l'algoritmo MD5 con una chiave a 128 bit. In ogni caso una implementazione può supportare anche altri algoritmi di autenticazione oltre a MD5 (vedere "Approfondimento III: Autenticazione con HMAC e MD5").

 

 

3.5.1 AH in Transport Mode

 

Nel transport Mode l'AH fornisce protezione al datagram proveniente dal livello superiore (quindi TCP Header + dati) ed ad alcuni campi dell'Header di base di IPv6.

Il pacchetto IP con l'Authentication Header si presenta così:

 

Header IPv6

di base

Authentication

 Header 

TCP Header

DATI

 

I dati per l'autenticazione vengono calcolati escludendo alcuni campi dell'Header di IPv6 che devono subire cambiamenti durante il tragitto (come hop-limit). L'esclusione di questi campi comunque non influenza la sicurezza.  Questi campi vengono inizializzati a zero sia dalla sorgente che dalla destinazione nel calcolo dell'autenticazione. Il calcolo dell’autenticazione viene effettuato prima della frammentazione al sito sorgente e dopo il riassemblaggio al sito destinazione; quindi, i campi interessati alla frammentazione possono essere inclusi nel calcolo. 

 

 

3.5.2 AH in Tunnel Mode

 

In questa modalità l'AH fornisce protezione all'intero datagramma IP, incapsulando l'Header di IPv6 e ponendo un Header IP esterno, per consentire il trasporto del pacchetto.

Il datagramma con AH in Tunnel Mode si presenta così:

 

Header IP

esterno

Authentication

Header

datagramma IP interno

(incluso Header IP)

 

Poiché l’Header IP contiene l’indirizzo destinazione, eventuali direttive di routing ed informazioni sulle opzioni hop-by-hop, non è possibile trasmettere semplicemente il pacchetto IP cifrato preceduto dall’Header AH, quindi, è necessario incapsulare l’intero blocco (Header AH più l'intero pacchetto IP cifrato) con un nuovo Header IP che conterrà informazioni sufficienti per il routing ma non per l’analisi del traffico. Mentre la modalità trasporto bene si adatta a proteggere connessioni tra host che supportano l’AH, la modalità tunnel è utile per le configurazioni che includono un firewall o gateway di sicurezza che proteggono una rete privata da reti esterne. In quest’ultimo caso, la cifratura è necessaria solo tra un host esterno ed il gateway di sicurezza, oppure fra due gateway di sicurezza. Questo alleggerisce gli host della rete interna dal carico di lavoro della cifratura e semplifica anche il processo di distribuzione delle chiavi riducendo il numero delle chiavi richieste. 

 

 

 

 

3.6 Encapsulating Security Payload

 

L'ESP è progettato per fornire integrità, autenticazione e confidenzialità ai datagrammi IP. Esso può proteggere o l'intero datagramma IP o il datagram del protocollo dello strato superiore (TCP, UDP, ICMP).

L'ESP, diversamente da AH, non è costituito da un unico header che precede le informazioni da proteggere, ma piuttosto è costituito da tre blocchi che "abbracciano" i dati protetti. Vedremo meglio cosa significa quando specificheremo le modalità operative (Transport e Tunnel) di ESP. In ogni caso i campi dei tre blocchi, più i dati protetti, costituiscono l'Header ESP. Vediamo in dettaglio i vari campi:

 

Security Parameters Index (SPI) (32 bit): in combinazione con l’indirizzo IP di destinazione ed il protocollo di sicurezza, identifica univocamente l’associazione di sicurezza per questo datagramma. L’insieme dei valori SPI nell’intervallo da 1 a 255 sono riservati dalla IANA per usi futuri; un valore SPI riservato non sarà assegnato. (Notare che questo campo è uguale a quello presente nell’Authentication Header);

Sequence number (32 bit): contiene un contatore crescente. Il mittente deve sempre trasmettere questo campo mentre il ricevente non ha bisogno di effettuare particolari azioni su di esso. Il contatore del mittente e del ricevente devono essere inizializzati a zero al momento della creazione di un’associazione di sicurezza (il primo pacchetto trasmesso utilizzando una certa SA avrà il Sequence Number pari a 1);

 Payload data (variabile): contiene i dati protetti. Tale campo è obbligatorio. Se l’algoritmo di cifratura utilizzato per cifrare i dati richiede l’utilizzo di un vettore di inizializzazione (IV), questo può essere inglobato esplicitamente nel campo Payload Data. L’algoritmo di cifratura deve specificare la lunghezza di tale informazione. Ci sono due modi per utilizzare l’IV all’interno del campo Payload Data:

per alcune modalità basate su IV il ricevente considera l’IV come la parte iniziale del testo cifrato utilizzandolo nell’algoritmo direttamente;

In alcuni casi il ricevente legge l’IV separatamente dal testo cifrato. In questo caso le specifiche dell’algoritmo devono indicare come effettuare l’allineamento del testo cifrato.

Padding (variabile): è richiesto da alcuni fattori; in primo luogo alcuni algoritmi di decifratura richiedono che il messaggio cifrato sia seguito da zeri; in secondo luogo, il padding può essere necessario per ragioni di allineamento dei campi successivi; infine, il padding può essere utilizzato per allungare arbitrariamente il pacchetto, per confondere l'analisi del traffico;

Pad Length: indica il numero di byte di padding (presenti nel campo precedente). L’intervallo dei valori validi va da 0 a 255, dove il valore 0 indica che non ci sono byte di padding. Il campo pad length è obbligatorio;

Next Header (8 bit): identifica il tipo di dati contenuto nel campo Payload Data, per esempio, un header di estensione di IPv6 oppure un identificatore di protocollo di uno strato superiore;

Authentication Data (variabile): contiene un valore di controllo di integrità (Integrity Check Value - ICV) calcolato sul pacchetto ESP escludendo l’Authentication Data. La lunghezza di questo campo è specificata dalla funzione di autenticazione selezionata. Tale campo è opzionale ed è incluso solo se è stato selezionato un servizio di autenticazione per la SA in questione.

 

ESP funziona tra host, tra host e security gateway e tra security gateway. Il supporto per security gateway permette a reti protette da un security gateway di evitare la crittografia, e quindi di evitarne i costi. Quando entrambi gli host implementano ESP, e non c'è l'intervento di un security gateway, allora essi possono usare il Transport Mode. Questa modalità riduce sia l'ampiezza di banda consumata, sia i costi di processing per entrambi gli utenti, quando questi non hanno necessità di tenere l'intero datagramma IP protetto.

 

L'incapsulamento usato da ESP può influenzare notevolmente le performance di sistemi condivisi, mentre non dovrebbe influire sulle prestazioni dei router o di altri intermediari che non partecipano alla ESP association.

L'IP processing è notevolmente più complesso in sistemi condivisi che usano ESP, e richiede più tempo e più potenza computazionale. L'uso della crittografia, inoltre, aumenta la latenza delle comunicazione. Ciò è dovuto principalmente alla cifratura e decifratura necessarie per ogni datagramma IP contenente ESP. Il costo preciso dell'ESP varia a seconda della specifica implementazione, e dipende dall'algoritmo usato, dalla dimensione della chiave e da altri fattori. Ogni implementazione dell'ESP  deve supportare l'uso del Data Encryption Standard (DES) in modalità  Cipher Block Chaining (CBC). Oltre al DES in CBC mode, altri algoritmi e modalità possono essere supportate per garantire la confidenzialità.

 

 

3.6.1  ESP in Transport Mode

 

La modalità trasporto ESP viene utilizzata per cifrare il datagram proveniente dal livello superiore (quindi TCP Header + dati). Il pacchetto si presenta così:

 

Header 

base di IPv6

ESP

Header

TCP

Header

Dati protetti

Esp trailer

Auth.

data

L'ESP Header contiene quindi il Security Parameter Index ed il Sequence Number, mentre il TCP Header e i dati costituiscono il campo Payload Data, infine l'ESP trailer contiene i campi Padding, Pad Lenght e Next Header, seguiti dal campo Authentication Data. Il campo Next Header indica che il contenuto del campo Payload Data è un datagramma del livello superiore ad IP (in particolare è un datagram TCP).

La modalità di trasporto fornisce privacy ad ogni applicazione che ne fa uso, in modo tale da evitare di implementare un meccanismo di privacy in ogni singola applicazione. Questo modo di operare è anche ragionevolmente efficiente, allungando di poco il pacchetto IP. 

 

 

3.6.2 ESP in Tunnel Mode

 

La modalità tunnel ESP è usata per cifrare l’intero pacchetto IP (compreso l'Header IP), che costituirà il campo Payload Data. A questo punto è necessario incapsulare l’intero blocco (Header ESP più il pacchetto IP cifrato) con un nuovo Header IP che conterrà informazioni sufficienti per il routing ma non per l’analisi del traffico.

 

Header IP

esterno

ESP

Header

datagramma IP interno

(incluso Header IP)

ESP trailer

Auth.

data

 

 Mentre la modalità trasporto bene si adatta a proteggere connessioni tra host che supportano l’ESP, la modalità tunnel è utile per le configurazioni che includono un firewall o gateway di sicurezza che proteggono una rete privata da reti esterne. In quest’ultimo caso, la cifratura occorre solo tra un host esterno ed il gateway di sicurezza oppure fra due gateway di sicurezza. Questo alleggerisce gli host della rete interna dal carico di lavoro della cifratura e semplifica anche il processo di distribuzione delle chiavi riducendo il numero delle chiavi richieste. 

 

Esempio: comunicazione tramite un tunnel ESP fra un host esterno ed un host di una rete privata protetto da firewall.

Consideriamo il caso in cui un host esterno desideri comunicare con un host di una rete interna protetto da un firewall ed in cui l’ESP sia implementato sia nell’host esterno che nel firewall. I passi seguenti sono necessari per il trasferimento di un segmento allo strato di trasporto dall’host esterno all’host interno: 

La sorgente prepara un pacchetto IP interno con l’indirizzo di destinazione dell’host interno che deve ricevere il pacchetto. Il pacchetto è preceduto da un Header ESP; quindi il pacchetto e la porzione dell’Header ESP vengono cifrati. Il blocco risultante è incapsulato con un nuovo Header IP (Header di base più estensioni opzionali come il routing e le opzioni hop-by-hop) il cui indirizzo di destinazione è il firewall; questo forma il pacchetto IP uscente;

Il pacchetto IP uscente è portato al firewall di destinazione. Ogni router intermedio ha la necessità di esaminare ed elaborare l’Header  IP più esterno ed ogni altro header di estensione più esterno, ma non ha la necessità di esaminare il testo cifrato; 

Il firewall destinazione esamina e processa l’Header IP più esterno e ogni altro header di estensione più esterno. Quindi sulla base dell’SPI nell’Header ESP, il firewall decifra la parte restante del pacchetto per ricostruire l’indirizzo IP del pacchetto interno. Il pacchetto è quindi trasmesso sulla rete interna. 

Il pacchetto interno attraversa zero o più router della rete interna fino all’host destinazione. 

 

 

 

 

3.7 Combinazione di AH ed ESP

 

In alcuni casi AH può essere combinato con ESP per ottenere le proprietà di sicurezza desiderate.

AH fornisce sempre integrità e autenticazione, e può fornire non ripudio se usato con determinati algoritmi di autenticazione (per es. RSA).

 

ESP fornisce sempre integrità e confidenzialità e può fornire autenticazione se usato con determinati algoritmi crittografici di autenticazione.

Aggiungere AH ad un datagramma IP prima di usare L'Encapsulating Security Payload può essere indicato per utenti che hanno bisogno di proprietà forti di integrità, autenticazione, confidenzialità e non ripudio.

Quando i due meccanismi sono combinati, la posizione di AH (dentro o fuori l'ESP) rende chiaro quale parte dei dati è stata autenticata.

 

Nessuno dei meccanismi descritti precedentemente fornisce protezione dall'analisi del traffico. Non è chiaro se è possibile fornire una protezione significativa dall'analisi del traffico a livello IP, dato che comunque pochi utenti di internet sono interessati all'analisi del traffico. Una tecnica tradizionale per questo tipo di protezione è crittografare la maggior parte del traffico, come pure spedire falso traffico allo scopo di aumentare il rumore nei dati forniti agli analizzatori.

 

 

 

 

3.8 Scambio delle chiavi

 

Ogni implementazione di IPv6 deve supportare l'uso degli algoritmi di default:

 

DES-CBC per la cifratura;

HMAC con MD5 per l'autenticazione;

 

L’utilizzo di altri algoritmi è comunque consentito, e dipende dalle diverse implementazioni. Per linux la scelta degli algoritmi viene effettuata in fase di progetto del sistema operativo, e di conseguenza dipende dalle diverse distribuzioni.

 

Poiché gli algoritmi utilizzati per cifrare e autenticare i dati richiedono l’uso di una chiave condivisa, è necessario un metodo per lo scambio di tale chiave.

Da questo punto di vista, IPv6 non è stato ancora completamente definito, e lo standard fa riferimento a quanto stabilito per IPsec [rif. 4] [rif. 5].

 

 

3.8.1 IPsec: Oakley / ISAKMP

 

IPsec prevede due metodi di gestione delle chiavi:

 

Manuale: l’amministratore di sistema configura il sistema con le proprie chiavi e con quelle degli altri sistemi comunicanti;

Automatico: la creazione delle chiavi per le SA avviene su richiesta;

 

Il metodo automatico è detto Oakley / ISAKMP, poiché consiste di due elementi:

 

Oakley Key Determination Protocol: è un protocollo per lo scambio della chiave segreta condivisa basato sull’algoritmo Diffie-Hellmann, ma che fornisce maggiore sicurezza;

Internet Security Association and Key Management Protocol: fornisce supporto per la negoziazione degli attributi di sicurezza.

 

Più precisamente Oakley serve per scambiarsi le chiavi ed accordarsi sugli algoritmi da utilizzare, mentre ISAKMP definisce il formato in cui tali informazioni devono viaggiare.

 

Prima di analizzare il protocollo Oakley, rivediamo brevemente Diffie-Hellmann; supponiamo di avere due utenti A e B che vogliono concordare una chiave segreta condivisa; i passi previsti da Diffie-Hellmann sono i seguenti:

 

  1. A e B si accordano su due valori q e α;

  2. ognuno sceglie un numero casuale X come chiave privata, e calcola il valore

        Y = αX  come chiave pubblica;

  1. A e B si scambiano le chiavi pubbliche e calcolano la chiave segreta di sessione

        K = (Yb)Xamod q = (Ya) Xb mod q= αXaXbmod q

 

Diffie-Hellmann presenta però alcune debolezze: non fornisce garanzie sull’identità delle parti, è soggetto all’attacco “man in the middle” ed all’attacco di clogging.

 

Oakley, rispetto a Diffie-Hellmann, introduce la possibilità di evitare attacchi di clogging attraverso un meccanismo noto come cookies (sono numeri casuali); inoltre, nei messaggi scambiati vengono inseriti dei numeri casuali (nonces), per contrastare gli attacchi di replay, ed infine i messaggi vengono autenticati per evitare l'attacco man in the middle.

 

Oakley prevede tre possibili metodi per autenticare i messaggi necessari per lo scambio delle chiavi:

Firma digitale: viene calcolato un hash su importanti parametri e il valore ottenuto viene poi cifrato con la chiave privata;

Cifratura a chiave pubblica: si cifrano alcuni parametri (ID utente, i nonces, …) con la chiave privata del mittente;

Cifratura a chiave simmetrica: i due utenti si scambiano una chiave privata, attraverso un canale sicuro (che non è la rete).

 

 

Esempio di avvio di una connessione tra A e B:

 

  

Messaggio contenente l’ID di A, un cookie, la chiave pubblica di A (per Diffie –Hellman), il nonce, alcuni algoritmi di cifratura di autenticazione e di funzioni hash che possono essere usate in questo scambio. Il messaggio è firmato usando la chiave privata di A.

B verifica la firma di A, e gli spedisce un messaggio contenente il cookie, l’ID ed il nonce di A, il cookie, la chiave pubblica, il nonce, e l’ID di B, e gli algoritmi usati, scelti fra quelli che A gli aveva mandato. Il tutto è firmato da B.

A verifica la firma di B. Per completare lo scambio, A deve inviare un messaggio a B, che serve a B per verificare che la sua chiave pubblica sia stata ricevuta da A.

 

Osserviamo che, ai fini dell’autenticazione, è necessario che A e B conoscano preventivamente le rispettive chiavi pubbliche.

In realtà questo aspetto non è ancora definito dallo standard IPv6 e attualmente non è ancora chiaro come vengano generate e scambiate le chiavi Oakley-Diffie-Hellmann.

 

Un esempio di implementazione dello scambio delle chiavi si può vedere alla pagina <Configuring_Isakmp> <copia_locale> e si riferisce alla configurazione di ISAKMP su un router CISCO.

 

I messaggi dell’esempio precedente, vengono scambiati rispettando il formato dei pacchetti del protocollo ISAKMP; tale formato è descritto nella seguente figura:

 

Initiator Cookie

Responder Cookie
Next Payload Mj Ver Mn Ver Exchange Type Flags
Message ID
Lenght

Descriviamo brevemente i vari campi:

Initator Cookie: è il cookie dell'utente che ha avviato la creazione della SA;
Responder Cookie: è il cookie dell'utente che accetta la SA;
Next Payload: indica il tipo di payload successivo;
Mj Ver: indica la versione più recente di ISAKMP in uso;
Mn Ver: indica le versine più vecchia di ISAKMP in uso;
Exchange Type: indica il tipo di scambio effettuato;
Flags: indica le opzioni settate per questo scambio di messaggi;
Message ID: è un identificativo unico del messaggio;
Lenght: indica la lunghezza totale del messaggio (header più tutti i payload);

L'header di un generico payload ha il seguente formato:

Next Payload Reserved Payload Lenght

I payload più importanti sono:

SA Payload, per la creazione di una SA;
Key Exchange Payload, contiene i dati richiesti per generare una chiave di sessione;
Hash Payload, contiene i dati generati dall’applicazione di una funzione hash sul messaggio;
Signature Payload, contiene i dati generati da una funzione di firma digitale;