2 IKE ``opportunistic''

Si è misurato un handshake IKE con la opportunistic encryption: i dati relativi sono presentati in tabella 6.9.

Questo è sostanzialmente un normale handshake IKE, con in più alcune interrogazioni al DNS. Gli intertempi tra i pacchetti IKE sono gli stessi del caso precedente, come era lecito attendersi, e le query al DNS non comportano tempi di elaborazione significativi. In un caso reale però le tre⁷² interrogazioni al DNS comprese nell'handshake hanno sicuramente un peso non trascurabile: sia per i tempi di risposta del DNS e per i tempi di trasmissione, sia perché l'implementazione attuale non utilizza DNSSEC, e dunque non verifica l'autenticità dei dati (che è un'operazione onerosa in quanto comporta l'utilizzo di crittografia asimmetrica).

Tabella 6.9: Timestamp dell'handshake di IKE ``opportunistic''.

Timestamp [ms]	Pacchetto	Direzione	Intertempo [ms]
0	DNS query TXT	H1 $\rightarrow$ S	-
0,5	DNS reply TXT	S $\rightarrow$ H1	0,5
1,3	DNS query KEY	H1 $\rightarrow$ S	0,8
1,8	DNS reply KEY	S $\rightarrow$ H1	0,5
7,2	IKE main mode 1	H1 $\rightarrow$ H2	5,4
8,3	IKE main mode 2	H2 $\rightarrow$ H1	1,1
42,5	IKE main mode 3	H1 $\rightarrow$ H2	34,2
88,4	IKE main mode 4	H2 $\rightarrow$ H1	45,9
188,2	IKE main mode 5	H1 $\rightarrow$ H2	99,8
188,9	DNS query KEY	H2 $\rightarrow$ S	0,7
189,4	DNS reply KEY	S $\rightarrow$ H2	0,5
279,8	IKE main mode 6	H2 $\rightarrow$ H1	90,4
320,8	IKE quick mode 1	H1 $\rightarrow$ H2	41,0
371,5	IKE quick mode 2	H2 $\rightarrow$ H1	50,7
478,0	IKE quick mode 3	H1 $\rightarrow$ H2	106,5

Footnotes

... tre⁷²

Potrebbero anche essere due, perché si potrebbe includere la chiave nel record TXT e dunque evitare la seconda query. Vale la pena di notare che qui si è considerato il caso end-to-end, perché nel caso gateway-to-gateway il ricevitore (security gateway della destinazione) dovrebbe fare anche una query TXT per accertarsi che l'iniziatore sia autorizzato a rappresentare la sorgente.