3 Prestazioni di IPsec

Per prima cosa si sono analizzate le prestazioni di varie modalità di IPsec (per quanto riguarda la fase di trasferimento dei dati), ovvero:

• ESP in modalità trasporto
• ESP in modalità tunnel
• AH più ESP in modalità trasporto
• AH più ESP in modalità tunnel
• AH in modalità trasporto (trasmissione non cifrata)
• AH in modalità tunnel (trasmissione non cifrata)

Gli algoritmi utilizzati sono il triplo DES per la cifratura (con chiavi di 192 bit e vettore di inizializzazione di 64 bit) e SHA1 per l'autenticazione (che produce una stringa di 160 bit, poi troncata a 96 bit).

In tabella 6.1 sono illustrati i risultati relativi a TCP su IPsec su rete a 10 Mbit/s. Dai dati nella terza colonna si può notare che, in termini di carico sul processore, non vi è una grande differenza tra le varie modalità di IPsec, ovvero tra tunnel oppure trasporto e tra l'autenticazione con AH oppure con ESP, infatti lo scostamento tra il valore minimo e quello massimo, considerando anche il margine di approssimazione, è sostanzialmente nullo. Si ha invece una differenza notevole, come ci si poteva attendere, tra una connessione cifrata e una connessione solo autenticata: l'overhead sul processore nel primo caso è infatti circa triplo rispetto al secondo. In questo caso il collo di bottiglia è costituito dalla rete, per cui il throughput riflette il carico su di essa: i risultati ottenuti non danno grosse sorprese, e riflettono più o meno il diverso overhead sul pacchetto dato dalle diverse modalità, che precisamente è:

ESP trasporto:

header ESP: 8 byte, IV: 8 byte, trailer ESP: 2 byte, autenticazione: 12 byte. Totale: 30 byte più padding.

ESP tunnel:

come il precedente più 20 byte per l'header IP. Totale: 50 byte più padding.

AH + ESP trasporto:

header AH: 12 byte; autenticazione: 12 byte; header ESP: 8 byte; IV: 8 byte; trailer ESP: 2 byte. Totale: 42 byte più padding.

AH + ESP tunnel:

come il precedente più 20 byte per l'header IP. Totale: 62 byte più padding.

AH trasporto:

header AH: 12 byte; autenticazione: 12 byte. Totale: 24 byte.

AH tunnel:

come il precedente più 20 byte per l'header IP. Totale: 44 byte.

Le differenze di overhead di rete tra le varie modalità, sia a livello teorico che a livello sperimentale, non sono molto grandi. Per una connessione non cifrata la scelta ovvia appare AH in modalità trasporto (dato che il tunnel non aggiunge nessuna funzione ad AH) ma nel caso gateway-to-gateway è necessario il tunnel. Nel caso cifrato la cosa più semplice è utilizzare il solo ESP, magari in modalità tunnel anche nel caso host-to-host in modo da autenticare anche l'header IP.

Tabella 6.1: Prestazioni TCP su IPsec con 3DES e SHA1 a 10 Mbit/s

Test	[KB/s]	[%]	[ s/KB]
chiaro	888,30	3,52	39,616
ESP trasporto	841,45	40,70	483,714
ESP tunnel	817,16	40,10	490,702
AH+ESP trasporto	821,14	39,59	482,112
AH+ESP tunnel	814,75	40,90	501,945
AH trasporto	862,02	15,53	180,112
AH tunnel	843,22	15,40	182,625

Tabella 6.2: Prestazioni UDP su IPsec con 3DES e SHA1 a 10 Mbit/s

Test	[KB/s]	[%]	[ s/KB]
chiaro	1159,0	4,57	39,431
ESP trasporto	1136,4	48,47	426,546
ESP tunnel	1124,3	49,99	450,674
AH+ESP trasporto	1126,7	49,29	437,485
AH+ESP tunnel	1126,3	49,98	459,494
AH trasporto	1142,8	17,37	152,006
AH tunnel	1126,5	17,39	154,345

In tabella 6.2 sono invece mostrati i dati relativi al test su UDP nelle stesse condizioni: anche in questo caso non si notano grosse differenze, per cui valgono le considerazioni del caso precedente.

Il test su UDP è tuttavia interessante perché in questo caso non entrano in gioco i meccanismi di ritrasmissione e controllo di flusso di TCP, per cui il sistema si può modellare semplicemente come la serie di due code rappresentanti il processore e la rete, come illustrato in figura 6.2. Per come funzionano i test di netperf che sono stati utilizzati il sistema viene saturato, per cui $\max\left(U_{CPU}, U_{NET}\right)=1$. Questo significa che, se $D_{CPU}$ e $D_{NET}$ sono le domande di servizio del processore e della rete, e $D_{MAX}=\max\left(D_{CPU}, D_{NET}\right)$, si ha che $X \simeq 1/D_{MAX}$. In questo caso il collo di bottiglia è la rete, per cui si può ipotizzare che $D_{NET} \simeq 1/X$. Si è allora provato a ripetere i test su rete a 100 Mbit/s (solo per alcune modalità): i risultati sono illustrati in tabella 6.3.

Figura 6.2: Modello a code per i test con UDP.

Tabella 6.3: Prestazioni UDP su IPsec con 3DES e SHA1 a 100 Mbit/s

Test	[KB/s]	[%]	[ s/KB]
chiaro	11619,5	32,09	27,623
ESP trasporto	2384,74	99,90	418,928
AH+ESP trasporto	2324,30	97,89	421,154

Come si può vedere, in questo caso (a parte per la connessione in chiaro) il collo di bottiglia è costituito dal processore, infatti si è misurato $U_{CPU} \simeq 100\%$. A conferma di quanto detto in precedenza, si può verificare che in questo caso $X \simeq 1/D_{CPU}$. La domanda di servizio è uguale a quella misurata nel caso a 10 Mbit/s (tenendo conto delle imperfezioni nella misura che probabilmente si accentuano in caso di saturazione del processore), il che è corretto e convalida il metodo di misurazione del carico sul processore (in quanto in questo caso si ha una misura indiretta di $D_{CPU}$ calcolabile dal throughput, la cui misurazione non presenta problemi).

Anche i dati sui test a 100 Mbit/s per TCP, riportati in tabella 6.4, confermano una domanda di servizio sul processore uguale a quella del caso a 10 Mbit/s. In questo caso però, per la presenza dei meccanismi di TCP citati sopra, non si può adottare il semplice modello prima proposto per cui il throughput risulta inferiore all'inverso della domanda di servizio del processore.

Tabella 6.4: Prestazioni TCP su IPsec con 3DES e SHA1 a 100 Mbit/s

Test	[KB/s]	[%]	[ s/KB]
chiaro	11489,81	47,92	41,712
ESP trasporto	2018,46	97,48	482,957
AH+ESP trasporto	2004,45	96,60	481,950