1 IKE

Si è misurato l'handshake IKE secondo la modalità delle firme digitali, mostrato in figura 2.5 per la fase 1 (main mode) e in figura 2.7 per la fase 2 (quick mode)⁷⁰. La sequenza dei pacchetti, con i timestamp (presi su S) e gli intertempi tra pacchetti successivi, è mostrata in tabella 6.8.

I primi due pacchetti del main mode non necessitano di elaborazioni significative (il primo può anche essere un pacchetto precalcolato), e infatti i relativi tempi sono molto piccoli e comparabili con il RTT⁷¹. Il terzo e il quarto contengono i dati per effettuare lo scambio Diffie-Hellman, il cui valore segreto deve essere calcolato dall'iniziatore tra la ricezione del quarto pacchetto e l'invio del quinto (mentre il ricevitore può farlo tra l'invio del quarto e la ricezione del quinto, ed ha dunque più tempo). Questo fatto, unito al fatto che il quinto pacchetto deve essere firmato (altra operazione di crittografia asimmetrica), determina per esso un tempo di elaborazione maggiore (circa 100 ms); anche il sesto pacchetto viene firmato, e dunque anch'esso comporta un tempo significativo. Per quanto riguarda il quick mode, i primi due pacchetti presentano tempi poco maggiori rispetto al terzo e al quarto del main mode: presentano in effetti funzionalità simili (scambio dei valori per il Diffie-Hellman e dei nonce) anche se hanno alcuni payload in più e soprattutto sono cifrati, la cifratura è però effettuata con un algoritmo simmetrico, dunque molto più leggero dal punto di vista computazionale. Si nota infine un tempo significativo sull'ultimo messaggio, probabilmente dovuto al calcolo del valore Diffie-Hellman.

Come detto, i tempi misurati sono sostanzialmente i tempi di elaborazione, dato che la durata totale dell'handshake è risultata di circa 470 ms a fronte di un RTT tra H1 e H2 di circa 480 s (ovvero inferiore di tre ordini di grandezza). È però importante notare che, al di fuori di una rete locale, il RTT può essere molto maggiore e diventare il fattore dominante, considerato che al tempo di elaborazione misurato bisogna aggiungere $\frac{9}{2}RTT$ (essendo l'handshake composto in totale da 9 pacchetti). Con un RTT di 100 ms, ad esempio, si può stimare un handshake di circa ms (per cui la laenza di rete ha più o meno lo stesso peso dei tempi di elaborazione), mentre con un RTT di 200 ms si avrebbe una durata totale di circa ms (per cui la latenza di rete pesa per due terzi del totale, e i tempi di elaborazione per un terzo).

Tabella 6.8: Timestamp dell'handshake di IKE.

Timestamp [ms]	Pacchetto	Direzione	Intertempo [ms]
0	IKE main mode 1	H1 $\rightarrow$ H2	-
0,9	IKE main mode 2	H2 $\rightarrow$ H1	0,9
35,6	IKE main mode 3	H1 $\rightarrow$ H2	34,7
81,5	IKE main mode 4	H2 $\rightarrow$ H1	45,9
181,6	IKE main mode 5	H1 $\rightarrow$ H2	100,1
271,5	IKE main mode 6	H2 $\rightarrow$ H1	89,9
312,4	IKE quick mode 1	H1 $\rightarrow$ H2	40,9
363,4	IKE quick mode 2	H2 $\rightarrow$ H1	51,0
469,9	IKE quick mode 3	H1 $\rightarrow$ H2	106,5

Footnotes

... mode)⁷⁰: Si è utilizzata la perfect forward secrecy, per cui sono presenti i payload KE.
... RTT ⁷¹: Dato che la misurazione inizia da quando il primo pacchetto è intercettato dallo sniffer, in realtà il suo tempo di elaborazione non viene misurato. Questo è comunque molto piccolo, infatti il pacchetto ha una struttura analoga al secondo (che ha un intertempo di 0,9 ms sul primo) e in più, a differenza di questo, può essere precalcolato.