2 Formato e sequenza dei pacchetti

Il payload di HIP segue direttamente l'header IP⁵². Teoricamente potrebbe comparire in ogni pacchetto IP, tuttavia, dopo il completamento dell'handshake, le informazioni incluse in ESP sono sufficienti a mantenerne lo stato, per cui viene usato solamente nei pacchetti che servono a stabilire o modificare lo stato della connessione HIP.

Il formato del payload è illustrato in figura 5.2. Il primo campo indica il ``next header'' (con il significato usuale), il secondo contiene la lunghezza del ``key payload'', il terzo serve ad identificare il tipo di pacchetto HIP; seguono un campo che contiene il numero di versione e un campo riservato per usi futuri. I 128 bit successivi contengono lo HIT del mittente, segue il ``key payload'', e infine l'header ESP seguito dal payload IP⁵³.

Figura 5.2: Formato del payload HIP.

Il key payload contiene le informazioni necessarie per portare a termine l'handshake, e il suo contenuto varia a seconda del tipo di messaggio. Il formato, illustrato in figura 5.3, è una semplificazione di un messaggio DNS e contiene infatti una sequenza di resource record (RR). Il campo RCOUNT contiene il numero di record presenti, FQDNLGTH fornisce la lunghezza del nome di dominio (Fully Qualified Domain Name), che è contenuto nel campo successivo insieme con un eventuale padding. Segue la serie dei resource record⁵⁴ (RDLENGTH contiene la lunghezza della parte RDATA e TYPE ne indica il tipo), che possono essere di tipo KEY (contengono le chiavi o gli HIT), SIG (contengono le firme) oppure OPT (contengono informazioni di altro tipo, quali cookie, SPI, LSI, informazioni sulle trasformazioni⁵⁵).

Figura 5.3: Formato dello HIP key payload.

L'handshake HIP, come già detto, è costituito da quattro pacchetti, e consente ai due interlocutori di scambiarsi le informazioni relative alle identità (intese come HI) e di stabilire una security association IPsec ESP. L'handshake comprende uno scambio di ``cookie'', che contrariamente a quanto avviene solitamente è iniziato dal ricevitore e non dall'iniziatore: questo aumenta di un messaggio la durata dell'handshake, ma offre il vantaggio di una maggiore robustezza verso attacchi di denial of service. Il primo pacchetto inviato dal ricevitore può essere infatti sostanzialmente precalcolato (in quanto contiene informazioni che non devono necessariamente cambiare ogni volta) e necessita di pochissime informazioni di stato da mantenere (ambedue le cose non sono vere per IKE), inoltre permette al ricevitore di formulare un ``indovinello'' di difficoltà variabile all'iniziatore: il ricevitore fornisce infatti un numero $I$ di 64 bit, un numero $K$ ( che dovrebbe essere compreso tra 1 e 8) e un target, e l'iniziatore deve trovare un numero $J$ tale per cui i $K$ bit meno significativi ottenuti dall'hash del concatenamento di $I$ e $J$ coincidano con i $K$ bit meno significativi del target⁵⁶.

La struttura dell'handshake è la seguente: l'iniziatore ottiene indirizzo IP, HI e HIT del ricevitore dal DNS⁵⁷ e invia il primo pacchetto. Il ricevitore replica fornendo, tra l'altro, il valore per lo scambio Diffie-Hellman, il cookie (con l'indovinello) e le proprie proposte per le trasformazioni crittografiche per HIP ed ESP, e firmando il tutto. Nel terzo pacchetto della sequenza l'iniziatore inserisce il cookie (con la risposta all'indovinello), LSI e SPI che ha assegnato al ricevitore, il proprio valore per lo scambio Diffie-Hellman, la proposta scelta per le trasformazioni HIP e, cifrate, la proposta scelta per le trasformazioni ESP e la propria HI; infine firma il tutto. Nell'ultimo pacchetto (anch'esso firmato e in parte cifrato) il ricevitore inserisce tra l'altro LSI e SPI che ha assegnato all'iniziatore, completando così l'handshake: i pacchetti successivi saranno protetti dalla ESP SA negoziata.

Oltre ai quattro pacchetti dell'handshake, HIP ne prevede altri per cambiare chiavi e SPI, per notificare il cambio di indirizzo, e per il ``bootstrap''.

Footnotes

... IP⁵²

In alcuni casi, corrispondenti a pacchetti con funzioni particolari successive all'handshake, può seguire l'header ESP.

... IP⁵³

HIP supporta ESP in modalità trasporto e non in modalità tunnel.

... record⁵⁴

Per i dettagli su di essi si vedano [32], [33] e [14].

... trasformazioni⁵⁵

Queste ultime sono inserite utilizzando un formato preso in prestito da ISAKMP.

... target⁵⁶

Questo potrebbe richiedere all'iniziatore $2^{K}$ operazioni di hash prima di trovare un numero adatto, mentre la verifica da parte del ricevitore necessita di una sola operazione di hash.

... DNS⁵⁷

Per cui anche per HIP è importante DNSSEC. Eventualmente è possibile ottenere i dati anche da una tabella locale, il che in ambiti limitati può essere utile ma non è ovviamente praticabile su larga scala.