Studio degli acceleratori crittograﬁci per IPsec: alternative di...

POLITECNICO DI MILANOV Facoltà di Ingegneria di Milano

Corso di Laurea in Ingegneria delle Telecomunicazioni

Studio degli acceleratori crittografici per IPsec:

alternative di design

e scheduling efficiente dei pacchetti

Relatore: Chiar.ma Prof.ssa Maria Giovanna SAMI

Corelatore: Dott. Ing. Alberto FERRANTE

Tesi di Laurea di:

Antonio Vincenzo TADDEO

Mat. 635338

Anno Accademico 2004–2005

a mia nonna Nina ...

Ringraziamenti

I ringraziamenti...

Come si può essere originali quando si vuole dire grazie a qualcuno? Ho pen-

sato molto a cosa scrivere in questo spazio cercando di non cadere nel banale e

nel ridicolo. Più mi sforzo di trovare una qualche alternativa al solito elenco di

persone, più mi rendo conto di quanta gente abbia contribuito al raggiungimento

di questo mio traguardo universitario. Ogni giorno, ogni istante, qualcuno mi ha

versato una goccia di sè, spesso senza neanche accorgersene. Chi direttamen-

te, chi a distanza, chi con l’amicizia e l’amore o con la semplice presenza, tutti

quanti hanno riempito questi miei anni. Sono sicuro che se leggessi questa tesi

cercando di dare un volto ad ogni pagina, riuscirei a trovare a chi appartiene.

Capisco che la cosa possa sembrare strana vista con occhi indifferenti ma non lo

è se si pensa che se sono arrivato fino a questo punto lo devo anche alla serie di

causa ed effetto del vivere e del relazionarsi quotidiano.

Perchè non provare a risalire lungo il fiume del tempo e tentare di far riaffio-

rare un grazie per ognuno? Non credo sia un’impresa impossibile, l’unica mia

paura è quella di trascurare qualcuno. Ebbene eccomi ripercorrere il mio passato

per donare di cuore il mio GRAZIE ...

Il primo gradino è tutto dei miei zii e delle mie cugine di Cantù. Loro è il

primo appoggio; con loro i primi passi. GRAZIE.

Un tempo che non sembra finire mai è tutto di Luca. Inaspettata e sorpren-

dente l’amicizia che ci lega. Suoi sono i lunghi anni vissuti tra Como e Milano.

2

Gli devo molto anche se non lo sa. GRAZIE.

Ad intervalli imprevedibili ma sempre indimenticabili trova posto Diego. La

sua speciale personalità e la sua generosa disponibilità sono qualcosa di unico

ed indispensabile. GRAZIE.

I primi tre anni di week end comaschi sono tutti delle mie “sorelline” del

nord, Laura e Valeria. Non si può vivere l’università se non si vive la città; a loro

il merito di avermi mostrato le dolci notti comasche. GRAZIE

E poi...

E poi saltiamo... saltiamo lo scoglio di Milano e viaggiamo al di là dei confini.

In svizzera sono i 10 mesi più lunghi mai vissuti, per la loro intensità emotiva

e per l’enorme crescita professionale. Sono i giorni del Master ALaRI a Lugano.

Ho girato per il mondo standomene comodamente seduto sul divano ad ascoltare

i racconti dei miei “compagni di classe”. Non me ne vogliano male se cito solo

due esemplari come un valido campione rappresentativo.

Di Giuseppe sono le notti insonni. Suoi sono le lezioni su Linux e i tanti

progetti insieme. Un grande esempio professionale. GRAZIE.

Un’immedita intesa e una prolungata amicizia è invece di Leandro. Sua è

la grande bontà d’animo e l’appoggio costante nei giorni finali. Con lui è il

rimpianto di tante partite mai più giocate. GRAZIE

E poi... marginali ma sempre punti di riferimento sono Francesco e la sua

pazzia, Marco e i suoi ragionamenti e Luca ed il suo bluetooth, Umberto ed i suoi

incubi, Yum e Carola per la loro gentilezza. GRAZIE.

E se gli ultimi istanti sono quelli che si ricordano di più come dimenticare

Alberto. Con lui ho condiviso il mio lavoro di tesi. Indispensabile la sua sapienza

e la disponibilità dimostrata. Sua è la mia sopportazione. GRAZIE.

Fondamentale l’apporto della Prof.ssa Sami. Sua è la possibilità offertami al

master, così come la disponibilità ad avermi come tesista. Suoi sono i precisi sug-

gerimenti scientifici. Sue le mirate osservazioni. GRAZIE.

Tutto questo rivivere il mio tempo rischia di distrarmi dalle cose importanti.

3

Per fortuna so a chi devo tutto ciò.

Tutto dall’origini ad adesso è della mia famiglia. Loro è la mia crescita. Con

loro è la mia gioia ed il mio dolore. Loro è il continuo apporto e l’interminabile

fiducia data e ricevuta. Loro sono i sacrifici e loro è l’orgoglio di accogliermi da

ingegnere. GRAZIE

Un pezzettino di tutto è di mio fratello Adriano. Suo è il periodo milanese.

Suo è il merito di essere stato presente nel bene e nel male. GRAZIE.

E monica?

Lei è qualcosa di speciale. Onnipresente in ogni periodo dei miei studi, dai

precorsi fino ad ora. Onnipresente in ogni forma, da collega ad amica ad amante.

Onnipresente in ogni emozione. GRAZIE.

4

Indice

1 Introduzione 14

2 IPsec 21

2.1 Introduzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2 Architettura di IPsec . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.2 Security Association (SA). . . . . . . . . . . . . . . . . 23

2.2.3 Modalità Trasporto e Tunnel. . . . . . . . . . . . . . . . 25

2.2.4 Security Policy Database (SPD). . . . . . . . . . . . . . 27

2.2.5 Security Association Database (SAD). . . . . . . . . . . 29

2.2.6 Il protocollo ESP. . . . . . . . . . . . . . . . . . . . . . 29

2.2.7 Il protocollo AH . . . . . . . . . . . . . . . . . . . . . . 32

2.3 I protocolli IKE e ISAKMP. . . . . . . . . . . . . . . . . . . . . 33

2.3.1 IKE phase_1. . . . . . . . . . . . . . . . . . . . . . . . 35

2.3.2 IKE phase_2. . . . . . . . . . . . . . . . . . . . . . . . 37

2.4 Implementazioni di IPsec. . . . . . . . . . . . . . . . . . . . . . 39

2.5 Gestione ed elaborazione del traffico IPsec. . . . . . . . . . . . . 39

2.5.1 Traffico Inbound . . . . . . . . . . . . . . . . . . . . . . 39

2.5.2 Traffico outbound. . . . . . . . . . . . . . . . . . . . . . 41

2.5.3 Elaborazione IPsec dei pacchetti. . . . . . . . . . . . . . 42

2.6 IPSec in azione. . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.6.1 Le reti private virtuali (VPN). . . . . . . . . . . . . . . . 45

5

INDICE

2.6.2 La rete Road Warrior. . . . . . . . . . . . . . . . . . . . 48

3 Stato dell’arte 49

3.1 Introduzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.2 Broadcom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.3 Corrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.4 Hifn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.5 IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.6 Motorola/FreeScale. . . . . . . . . . . . . . . . . . . . . . . . . 58

3.7 Sun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4 Approccio metodologico al design degli acceleratori hardware 63

4.1 Introduzione. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2 Metodologia di design per l’acceleratore. . . . . . . . . . . . . . 64

4.2.1 Panoramica esterna. . . . . . . . . . . . . . . . . . . . . 64

4.2.1.1 Design generale e posizionamento del modulo. 64

4.2.1.2 Tipologie di posizionamento, pro e contro. . . 67

4.2.1.3 Interfaccia fisica di comunicazione. . . . . . . 69

4.2.2 Struttura Interna. . . . . . . . . . . . . . . . . . . . . . 71

4.2.2.1 Design dell’architettura, approccio multi-livello71

4.2.2.1.1 Il livello STACK . . . . . . . . . . . 71

4.2.2.1.2 Il livello APPLICATION . . . . . . . 72

4.2.2.1.3 Il livello CORE . . . . . . . . . . . . 73

4.2.2.1.4 Rappresentazione grafica. . . . . . . 74

4.2.2.2 Selezione di un design. . . . . . . . . . . . . . 75

4.2.3 Visione d’uso. . . . . . . . . . . . . . . . . . . . . . . . 78

4.2.3.1 Design del firmware e del software. . . . . . . 78

4.3 Metodologie di valutazione per un acceleratore. . . . . . . . . . 79

4.3.1 Criterio ad uso pratico. . . . . . . . . . . . . . . . . . . 80

4.3.2 La certificazione NIST, FIPS PUB 140-1. . . . . . . . . 80

6

INDICE

5 Acceleratore crittografico, sistema di riferimento e modello 84

5.1 Analisi del problema e scelte progettuali. . . . . . . . . . . . . . 85

5.1.1 Specifiche dell’acceleratore crittografico. . . . . . . . . . 87

5.2 Sistema di riferimento. . . . . . . . . . . . . . . . . . . . . . . . 90

5.3 Architettura del modello . . . . . . . . . . . . . . . . . . . . . . 91

5.3.1 I processori. . . . . . . . . . . . . . . . . . . . . . . . . 92

5.3.2 Il bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.3.3 La memoria. . . . . . . . . . . . . . . . . . . . . . . . . 94

5.3.4 Lo scheduler. . . . . . . . . . . . . . . . . . . . . . . . 94

5.4 Algoritmo di scheduling . . . . . . . . . . . . . . . . . . . . . . 95

5.5 Funzionamento del sistema. . . . . . . . . . . . . . . . . . . . . 96

5.6 Analisi ed obiettivi del modello. . . . . . . . . . . . . . . . . . . 98

6 Simulazioni sul modello e sliding window 103

6.1 Design space exploration. . . . . . . . . . . . . . . . . . . . . . 103

6.1.1 I pattern di traffico . . . . . . . . . . . . . . . . . . . . . 103

6.1.2 Velocità di elaborazione relativa per i processori. . . . . 107

6.2 Test preliminari e scheduling efficiente. . . . . . . . . . . . . . . 109

6.3 Ulteriore ottimizzazione del sistema. . . . . . . . . . . . . . . . 120

6.3.1 La sliding window . . . . . . . . . . . . . . . . . . . . . 122

6.3.2 Il nuovo scheduling con la sliding window. . . . . . . . . 125

6.4 Test post ottimizzazione. . . . . . . . . . . . . . . . . . . . . . 128

6.5 Esempio e test di scalabilità del modello. . . . . . . . . . . . . . 138

7 Conclusioni 143

7.1 Sviluppi futuri. . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

A Cenni di crittografia 147

A.1 Algoritmi a chiave simmetrica. . . . . . . . . . . . . . . . . . . 147

A.2 Algoritmi a chiave pubblica. . . . . . . . . . . . . . . . . . . . . 148

A.3 Il protocollo Diffie-Hellman . . . . . . . . . . . . . . . . . . . . 148

7

INDICE

A.4 Algoritmi di identificazione. . . . . . . . . . . . . . . . . . . . . 149

Bibliografia 150

8

Elenco delle figure

2.1 IPsec Roadmap: protocolli e loro relazioni. . . . . . . . . . . . . 22

2.2 Modello UML di IPsec . . . . . . . . . . . . . . . . . . . . . . . 24

2.3 Modalità Tunnel e Trasporto per AH e ESP, combinazioni possibili.26

2.4 Header ESP.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.5 Header e Trailer EPS per crittografia ed autenticazione dei pac-

chetti IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.6 Header AH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.7 Autenticazione del pacchetto IP tramite AH.. . . . . . . . . . . . 34

2.8 IKE phase_1: Scambio messaggi in modalità Main Mode (sx) e

Aggressive Mode (dx) [12]. . . . . . . . . . . . . . . . . . . . . . 37

2.9 IKE phase_2: Scambio di messaggi in modalità Quick Mode [12]. 38

2.10 Elaborazione pacchetti IPsec: Inbound [13] . . . . . . . . . . . . 40

2.11 Elaborazione pacchetti IPsec: Outbound [13]. . . . . . . . . . . . 41

2.12 Elaborazione IPsec in dattaglio: sequenza di operazioni.. . . . . 42

2.13 Mappatura del datagramma IP all’interno del protocollo ESP [14]. 43

2.14 Diagramma UML degli Stati per la creazione dell’Header ESP.. . 45

2.15 Diagramma UML degli stati per la creazione del Trailer ESP.. . . 46

2.16 Diagramma UML degli stati per l’elaborazione IPsec in modalità

Tunnel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.17 La rete privata virtuale con IPsec [13]. . . . . . . . . . . . . . . . 48

3.1 Processore Broadcom 5841. . . . . . . . . . . . . . . . . . . . . 51

9

ELENCO DELLE FIGURE

3.2 Applicazioni VPN che usano il Broadcom 5841. . . . . . . . . . 52

3.3 Corrent CR7110, schema a blocchi. . . . . . . . . . . . . . . . . 52

3.4 Esempio di uso del chip CR7110 all’interno di una scheda PCI. . 54

3.5 Hifn HIPP III 8350 Security Processor. . . . . . . . . . . . . . . 54

3.6 Diagramma a blocchi del chip Hifn HIPP III 8350. . . . . . . . . 55

3.7 Esempio di uso di Hifn HIPP III 8350 in una scheda PCI.. . . . . 56

3.8 IBM 4753 Cryptographic Coprocessor. . . . . . . . . . . . . . . 57

3.9 IBM 4753 Module . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.10 Schema a blocchi dell’ IBM 4758 Cryptographic Coprocessor. . 59

3.11 Diagramma a blocchi del MPC190. . . . . . . . . . . . . . . . . 60

3.12 Sun Crypto Acceleretor 4000 board. . . . . . . . . . . . . . . . 61

4.1 Il modulo Acceleratore (ACC). . . . . . . . . . . . . . . . . . . 65

4.2 Fabric Side Connection – Inline. . . . . . . . . . . . . . . . . . 66

4.3 Fabric Side – Look-aside Mode (Off-line). . . . . . . . . . . . . 67

4.4 Network Side Connection – In-line. . . . . . . . . . . . . . . . . 67

4.5 Network Side Connection – Look-aside Mode (Off-Line). . . . . 68

4.6 Spazio di design interno di un acceleratore hardware. . . . . . . 75

4.7 Partizionamento HW/SW dello stack IPsec in funzione del posi-

zionamento: In-line, Off-line[30]. . . . . . . . . . . . . . . . . . 77

5.1 Rete VPN fra secure gateway con canale sicuro protetto tramite ESP84

5.2 Modello di riferimento del sistema.. . . . . . . . . . . . . . . . . 91

5.3 Schema di funzionamento in realtime.. . . . . . . . . . . . . . . 97

5.4 IPsec Throughput in funzione delle dimensioni dei pacchetti [36]. 99

5.5 Distribuzione cumulativa della lunghezza dei pacchetti su internet

[37]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.6 Media e mediano, e rispettive varianze, dei pacchetti su internet

in 11 mesi di osservazioni. [37]. . . . . . . . . . . . . . . . . . . 101

5.7 Flusso di analisi e generazione obiettivi.. . . . . . . . . . . . . . 102

6.1 Istogramma della distribuzione esponenziale.. . . . . . . . . . . 105

10

ELENCO DELLE FIGURE

6.2 Istogramma della distribuzione uniforme.. . . . . . . . . . . . . 105

6.3 Istogramma del traffico reale.. . . . . . . . . . . . . . . . . . . . 107

6.4 Throughtput della CPU senza algoritmo di scheduling in funzione

di Eratio, per diversi pattern di traffico. In (a)Iratio = 1, in (b)

Iratio = 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.5 Latenza media del sistema con la sola CPU operativa.. . . . . . . 112

6.6 Confronto tra throughput del sistema: (a) solo CPU vs (b) CPU +

acceleratore.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.7 Confronto sulla latenza media del sistema: (a) solo CPU vs (b)

CPU + acceleratore.. . . . . . . . . . . . . . . . . . . . . . . . . 115

6.8 Percentuale di pacchetti processati dalla CPU.. . . . . . . . . . . 116

6.9 Dimensione media dei pacchetti processati: (a) dall’acceleratore,

(b) dalla CPU.. . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.10 Istogrammi dei pacchetti processati (a) dall’acceleratore e (b) dal-

la CPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6.11 La sliding window. . . . . . . . . . . . . . . . . . . . . . . . . . 123

6.12 Schema di principio di funzionamento dello scheduler con sliding

window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.13 Percentuale sul totale dei pacchetti merged, per diverse dimen-

sione della finestra, con distribuzione di SA (a) 4-equal, (b) 4-

incremental.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.14 Percentuale di pacchetti processati dalla CPU per ogni pattern di

traffico. (a)W = 1 e (b)W = 5. . . . . . . . . . . . . . . . . . . 131

6.15 Percentuale di pacchetti processati dalla CPU. Confronto tra si-

stema con sliding window (W = 5) e senza (W = 1) nel caso di

pattern ’real’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.16 Confronto tra le lunghezze medie dei pacchetti elaborati dai pro-

cessori e la dimensione media di un pacchetto merged.. . . . . . 133

6.17 Confronto tra i throughput del sistema (a) senza sliding window e

(b) con sliding windowW = 5. . . . . . . . . . . . . . . . . . . . 134

11

ELENCO DELLE FIGURE

6.18 Confronto dei tempi medi di latenza per il sistema (a) senza sli-

ding window e (b) con sliding windowW = 5. . . . . . . . . . . 135

6.19 Variazione percentuale relativa del throughput calcolata rispetto al

sistema senza sliding window, per dimensioni della finestra pari a

“1” e “5”, diversificata per pattern di traffico.. . . . . . . . . . . 136

6.20 Variazione percentuale relativa della latenza media calcolata ri-

spetto al sistema senza sliding window, per dimensioni della fine-

stra pari a “1” e “5”, diversificata per pattern di traffico.. . . . . . 137

6.21 Variazione percentuale relativa dell’uso della CPU calcolata ri-

spetto al sistema senza sliding window, per dimensioni della fine-

stra pari a “1” e “5”, diversificata per pattern di traffico.. . . . . . 137

6.22 Throughput del sistema multi-acceleratore.. . . . . . . . . . . . 139

6.23 Sistema multi-acceleratore: percentuale sul totale di pacchetti pro-

cessati (a) nella CPU e (b) nell’acceleratore-1.. . . . . . . . . . . 140

6.24 Percentuale di conflitti sul numero di richieste di accesso al bus

per l’acceleratore-1 con (a)W = 1 e (b) conW = 5. . . . . . . . 141

12

Elenco delle tabelle

4.1 Interfacce di comunicazione per un generico acceleratore hardware70

4.2 Criteri di valutazione di un acceleratore hardware [21] . . . . . . 81

5.1 Performance degli algoritmi crittografici per un tipico general-

purpose [14]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.1 Pattern di traffico usati nelle simulazioni. Distribuzione del pay-

load dei pacchetti.. . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.2 Dettagli sulle singole distribuzioni dei pattern di traffico.. . . . . 106

6.3 Caratterizzazione del traffico in base alla SA.. . . . . . . . . . . 106

6.4 Range dei parametri per i pattern di traffico usati nelle simulazioni.108

6.5 Range dei valori perIratio edEratio. . . . . . . . . . . . . . . . . 108

6.6 Throughput dell’acceleratore senza algoritmo di scheduling in fun-

zione dei pattern di input.. . . . . . . . . . . . . . . . . . . . . . 109

6.7 Range di valori per i parametri della sliding window.. . . . . . . 125

6.8 Numero medio di pacchetti con la stessa SA in funzione delle

dimensioni della finestra, per le due distribuzioni di traffico4-

equale4-incremental. . . . . . . . . . . . . . . . . . . . . . . . 128

13

Capitolo 1

Introduzione

Portato alla ribalta dalla tecnologia (Information Technology - IT) e reso globale

dal diffondersi di internet, il trattamento dell’informazione ha risvegliato antiche

paure quali quella dell’ignoto o quella di essere spiati. Si intuisce come in ambiti

quali militare o, più semplicemente, aziendale, la protezione dell’informazione

rappresenta un elemento di vitale importanza. Comprensibile è la reazione che ne

consegue: si escogitano soluzioni in grado di proteggere i dati e rendere sicure le

comunicazioni.

Nato come appendice al trattamento dei dati, oggi il problema della sicurezza

dell’informazione si è ritagliato uno spazio tutto suo andando a costituire parte

essenziale di ogni nuovo sviluppo tecnologico.

Da dove proviene la maggiore fonte di rischio? Dalla miscela esplosiva di tre

fattori: dalla diffusione capillare della rete e dal conseguente aumento del valore

complessivo delle informazioni, dallo sviluppo della tecnologia e dal differenziale

di conoscenza tra vittime e aggressori.

Il primo fattore, la crescita esponenziale del numero degli utenti, è certo il

fenomeno piú evidente. Molti di questi nuovi utenti non hanno la minima consa-

pevolezza dei rischi legati alla connessione in rete; sono attratti dalle potenzialità

e dalla quantità di informazioni disponibili ma del tutto indifferenti alla protezione

della comunicazione e della privacy.

14

1. Introduzione

Al contrario una moltitudine di aziende, appartenenti a svariati settori, sono

interessate ad instaurare canali di comunicazione sicuri. Il loro obiettivo si scon-

tra, però, con la realtà della rete internet che risulta essere di pubblico dominio.

In generale esistono due modi di rendere il canale privato:separazione fisica

con controllo di accesso; tramiteoffuscamentodove solo l’interlocutore abilitato

è in grado di comprendere l’informazione, ai più incomprensibile.

L’offuscamento dei dati è alla base delle modernevirtual private network

(VPN). Lo scopo delle VPN è usare la rete pubblica di internet per stabilire co-

municazioni private, mantenendo la qualità del canale intatta, ed offrendo servizi

di sicurezza ed affidabilità.

L’utilizzo delle Internet-based VPN networks ha parecchi vantaggi riassumi-

bili in:

• uso dell’infrastruttura flessibile e ad accesso multiplo offerta da internet.

• riduzione dei costi legati alle economie di scala del sistema internet ed eli-

minazione dei costi di gestione legati ad una comunicazione special-purpose

realizzata ad hoc.

• uso della crittografia per la confidenzialità ed integrità dei dati trasmessi.

• facilitazione e sviluppo dell’E-commerce B2B e B2C offrendo un alto grado

di sicurezza delle transazioni.

• possibilità di realizzazioni e gestione delle VPN sia hardware che software.

• scelta tra una multitudine di tecnologie e protocolli (IPSec, SSL, etc..) in

grado di costituire differenti architetture di sicurezza.

Il cardine su cui si fondano le VPN, la crittografia dei dati, è anche il suo punto

debole, inteso in termini di prestazioni del sistema. Stabilire e gestire una connes-

sione sicura (sia usando SSL o IPSec) richiede infatti un complesso meccanismo

di scambio di chiavi, l’elaborazione dei pacchetti, la verifica dell’autenticità, la

15

1. Introduzione

crittografia dei dati e ciò risulta particolarmente intenso per qualsiasi processo-

re general-purpose. Inoltre, con reti ad alta velocità, la capacità del server di

processare i pacchetti diviene il collo di bottiglia del sistema. Ottenere delle buo-

ne performance in questo contesto diventa abbastanza complicato. Non si deve

dimenticare che l’innovazione tecnologica di internet è indirizzata verso la tra-

smissione ad alte velocità di pacchetti dati con dimensioni ben superiori a 4 KB,

quindi, con ulteriore sovraccarico di lavoro per il server che espleta l’algoritmo di

crittaggio.

La necessità di gestire la crescente richiesta di connessioni simultanee allo

stesso server, il fabbisogno di trasmissioni ad elevata velocità, la volontà di man-

tenere un elevato livello di riservatezza delle comunicazioni porta alla richiesta di

dispositivi ed algoritmi in grado di accrescere le performance del sistema VPN.

L’interesse, mostrato in questo settore, è principalmente rivolto verso lo svi-

luppo di dispositivi hardware col compito di accelerare o la cifratura dei dati, o

l’intero protocollo di sicurezza. Giustificare la presenza di un acceleratore crit-

tografico è abbastanza semplice: il costo per aggiungere un acceleratore, al fine

d’incrementare il volume di dati processati, è significativamente minore rispet-

to ad avere un nuovo server; inoltre, alleggerisce il carico di lavoro del server

“ospitante” liberandolo dall’onere di crittare i dati.

L’approccio da adottare nella progettazione di un acceleratore hardware deve

far fronte ad una serie di scelte spesso fra loro contrastanti, e trovare un giusto

equilibrio tra performance, costi di sviluppo e vincoli architetturali. Alcuni fattori

chiave da tenere in considerazione nella realizzazione e/o analisi di un acceleratore

sono riassunti di seguito:

• Protocollo di sicurezza supportato (tipicamente SSL o IPSec).

• Acceleratore“protocol-aware” oppure“packet-aware”.

• Capacità di memorizzazione delle informazioni di sicurezza per ogni ses-

sione.

• Gestione delle chiavi e delle sessioni.

16

1. Introduzione

• Livello di interazione con le risorse del sistema (processore dell’host, me-

moria, etc..).

• Tipo di implementazione, p.e., in-line/off-line col flusso di dati.

• Performance dell’acceleratore in funzione del traffico e dimensione dei pac-

chetti.

Tutti gli aspetti più interssanti che caratterizzano gli acceleratori hardware sono

stati esaminati e discussi in questa tesi analizzandoli da un punto di vista ad “alto

livello”.

Un primo contributo innovativo che si riscontra in questo lavoro di tesi è, ap-

punto, rappresentato da un approccio metodologico di carattere generale appli-

cabile al design degli acceleratori hardware. Si vuole offrire in questo modo un

quadro schematico e chiaro sulla vastità di proposte provenienti dal mercato degli

acceleratori hardware. L’idea di una metodologia di design per gli acceleratori

nasce quindi dall’osservazione del lavoro svolto in ambito aziendale e si mescola

con le opere nella letteratura per dare un aspetto formale e scientifico ai contenuti.

Facendo uso della metodologia di design proposta si è poi considerato un acce-

leratore hardware da includere in un sistema di riferimento costituito da una secure

gateway che utilizzi tale acceleratore per il solo crittaggio dei dati. L’acceleratore

è modellizzato facendo avendo in mente unlight weigh accelerator. Volendolo

classificare secondo i criteri sopra esposti, il dispositivo è “packet-aware”, dedi-

cato alla sola elaborazione dei pacchetti, senza nessun tipo di memoria interna,

offline al flusso di dati e connesso tramite bus PCI alla CPU del sistema. L’idea

di base è quella di avere un chip estremamente semplice, di ridotte dimensioni ed

elevate performance crittografiche. La presenza di un dispositivo del genere ha il

vantaggio di essere versatile, adattabile a qualsiasi protocollo di sicurezza, di faci-

le installazione, eventualmente parametrico, riprogrammabile ed infine scalabile.

Di contro, come precedentemente accennato, fa uso di risorse limitate e condivi-

se, come bus e memoria; necessita di un continuo flusso di dati ed istruzioni di

controllo da/per la CPU.

17

1. Introduzione

Il modello del sistema, sviluppato inSystemC, si prefigge di essere indipen-

dente dalla piattaforma, con una profondità di dettagli che si colloca a livello di

System Design, e focalizzato sull’aspetto funzionale dei componenti. Particolarità

del modello è data dalla possibilità di cifrare i dati sia tramite l’acceleratore che

contemporaneamente tramite la CPU. Uno scheduler amministrerà i pacchetti di-

stribuendoli adeguatamente tra i due processori secondo un ben definito algoritmo

.

L’obiettivo è quello di studiare il comportamento dell’intero sistema (CPU e

acceleratore) sottoposto ad un flusso in ingresso ad elevato rate che necessita di es-

sere crittato secondo le regole dettate da IPSec. L’attenzione è posta su un aspetto

in particolare: vagliare l’effetto delle dimensioni dei pacchetti sulle performance

del sistema ed individuare un algoritmo di scheduling che ne ottimizzi il crittaggio

scegliendo tra un implementazione software (CPU) o in hardware (acceleratore).

Le linee guida nella progettazione dell’algoritmo di scheduling sono, naturalmen-

te, quelle di massimizzare il throughput del sistema e minimizzare il tempo di

elaborazione complessivo.

Sul modello di riferimento sono quindi state effettuate delle simulazioni per

valutare e misurare gli effetti dello scheduling dei pacchetti tra CPU ed accelerato-

re. I risultati ottenuti dimostrano che il partizionamento del processo di crittaggio

tra hardware e software, se adeguatamente gestito in funzione delle dimensioni

dei dati e dello stato del sistema, è una soluzione necessaria per evitare, da un

lato, che l’acceleratore si saturi e, dall’altro, compensare il vincolo imposto dalla

limitata banda del bus PCI. Il bus rappresenta, infatti, una risorsa condivisa da me-

moria ed acceleratore, e risulta particolarmente sovraccaricato, oltre che dai dati,

anche dalle numerose istruzioni di gestione e controllo dell’acceleratore stesso.

I miglioramenti introdotti all’algoritmo di scheduling dei pacchetti, sono sta-

ti pensati con l’intenzione di ridurre il numero di interazioni CPU-acceleratore,

numero di richieste sul bus, e, possibilmente, accresce la località dei dati per un

rapido accesso e riduzione della tempistica.

18

1. Introduzione

Un secondo aspetto innovativo estraibile da questo lavoro di tesi è dato dal-

l’idea di usare unasliding windowper pre-analizzare il flusso di dati in funzione

dell’appartenenza di un pacchetto ad unasecurity association (SA). I pacchetti

aventi la stessa SA sono gestiti come fossero un unico dato e cifrati nei proces-

sori in un unico step. In questo modo si risparmia sui tempi di inizializzazione

del dispositivo e si compensano le inefficienze riscontrate nel processamento di

pacchetti di dimensioni ridotte. Lasliding windowha il pregio di essere tecno-

logicamente facile da implementare; si interfaccia immediatamente con qualsiasi

algoritmo di scheduling pre-esistente; è altamente parametrizzabile ed adattabile

al flusso di dati; produce risultati confortanti in termini di performance, pagando

un lieve dazio sulla latenza del sistema; riduce l’uso della CPU nel processo di

crittaggio dei pacchetti favorendo invece l’acceleratore, che risulta essere, in que-

sto modo, sfruttato a dovere.

Di seguito viene fornito un indice ragionato circa i contenuti e gli argomenti

trattati in questa tesi. La struttura dei capitoli rispecchia il flusso di lavoro. In-

nanzi tutto viene data una breve introduzione su IPsec, il protocollo usato per la

creazione delle reti private virtuali (VPN). Si è partiti poi da uno studio dell’esi-

stente nel campo degli acceleratori hardware nelle reti VPN-IPsec per individuare

un’approccio metodologico al design dei dispositivo. Tale approccio metodologi-

co è servito per produrre le specifiche dell’acceleratore da usare nel modello del

sistema di riferimento preso in considerazione in questa tesi. Infine una serie di

simulazioni sono state svolte per testare il comportamento del modello.

• Capitolo 2: IPsec

Introduzione al protocollo di sicurezza IPsec, comunemente usato nella

creazione delle VPN. Si definiscono le linee guida per realizzare un im-

plementazione del protocollo secondo lo standard dell’IETF. Sono esposti:

il nucleo di IPsec costituito da ESP e AH nelle due modalità, trasporto e tun-

nel; i concetti chiave di SA epolicyed i database SAD e SPD; il protocollo

19

1. Introduzione

per lo scambio delle chiavi IKE; e sono forniti dettagli circa l’elaborazione

del traffico IPsec.

• Capitolo 3: Stato dell’arte.

Viene data una descrizione schematica e generale dell’architettura e delle

funzionalità degli acceleratori presenti sul mercato. Le informazioni rac-

colte provengono da un lavoro di ricerca svolto tra le maggiori aziende

produttrici di acceleratori crittografici hardware.

• Capitolo 4: Approccio metodologico al design degli acceleratori hardware.

Sono descritti gli acceleratori hardware attraverso differenti livelli di ana-

lisi per offrire una visione macroscopica del sistema acceleratore, che sia

il più possibile teorica e si distacchi da una specifica realizzazione in com-

mercio. Si sono individuati due approcci metodologici, uno da applicare al

design degli acceleratori e l’altro da usare per una valutazione generale dei

dispositivi.

• Capitolo 5: Acceleratore crittografico, sistema di riferimento e modello.

In questo capitolo si definiscono le specifiche dell’acceleratore crittografico

da usare nel sistema di riferimento. Si descrive il modello del sistema in

ogni suo componente. Sono dati i dettagli dell’algoritmo di scheduling e si

focalizzano i dettagli circa lo studio da effettuare sul modello.

• Capitolo 6: Simulazioni sul modello e sliding window.

In questo capitolo sono presentati i risultati delle simulazioni. Viene intro-

dotta l’idea della sliding window e mostrati gli effetti sul sistema. Infine

è fornito un esempio di scalabilità del nostro modello verso un’architettura

multi-acceleratore.

20

Capitolo 2

IPsec

2.1 Introduzione

La sicurezza delle comunicazioni è parte integrante della nuova versione del pro-

tocollo internet IPv6. La sicurezza viene interamente affidata ad una suite di pro-

tocolli accumunati sotto la sigla IPsec. Le reti attuali basate su IPv4 possono

comunque supportare IPsec come estensione.

IPsec è uno standard di IETF, la cui architettura di base è esposta in [1], e

fornisce, attraverso tecniche crittografiche, servizi di sicurezza al traffico IP. La

protezione prende la forma di autenticazione dell’origine dei dati, integrità senza

connessione, confidenzialità, controllo degli accessi e antireplay. Servizio sup-

plementare di IPsec, non strettamente connesso con la sicurezza, è IPcomp [2],

per la compressione dei pacchetti, motivata, in parte, dall’impossibilità dei livel-

li sottostanti di effettuare una compressione efficiente a causa dell’impiego della

cifratura. Poichè tali servizi vengono forniti a livello IP, livello di rete, posso-

no essere utilizzati, in maniera del tutto trasparente, da un qualunque protocollo

sovrastante.

IPsec protegge i dati tra singoli hosts, tra reti disecure gateway(p.e., router,

firewall, etc.), e tra host e secure gateway. L’utilizzo principale di IPsec è nella

creazione delle reti private virtuali (VPN) e in ambito del cosidettoroad warrior.

21

2. IPsec

Figura 2.1:IPsec Roadmap: protocolli e loro relazioni

L’architettura di IPsec è schematizzata in Figura2.1, e comprende anche le

relazioni tra i protocolli di cui è costituito. Dettagli circa i protocolli ed i servizi

saranno esposti nelle sessioni successive.

2.2 Architettura di IPsec

2.2.1 Overview

Documento di riferimento per l’architettura di IPsec è la RFC1 2401 [1], in cui si

definiscono le linee guida per realizzare un’implementazione del protocollo. Sono

esposti i servizi di sicurezza che IPsec deve provvedere, come e dove possono

essere usati, come sono costruiti i pacchetti e in che modo vengono processati, ed,

infine, le interazioni tra l’elaborazione IPsec e le politiche (policy).

Come si può osservare in Figura2.1, il “nucleo” di IPsec è costituito da

due protocolli:l’Authentication Header(AH) e l’Encapsulated Security payload

(ESP). Entrambi possono essere usati per proteggere l’intero datagramma IP op-

pure la sola parte del livello superiore inclusa nel payload di IP. Questa distinzio-

ne è gestita considerando due differenti “modi” di IPsec:tunnel modee transport

mode, rispettivamente.

1Request For Comment (RFC)

22

2. IPsec

IPsec necessita di protocolli ed elementi supplementari per permetterne un rea-

le utilizzo ed un’implementazione coerente con l’infrastruttura internet. A questo

scopo, IPsec richiede un protocollo per lo scambio delle chiavi; suggerimento di

IETF è IKE (Internet Key Exchange).

Elementi fondamentali collegati con IPsec sono leSecurity Association(SA)

e i parametri che definiscono lapolicy di sicurezza, dai quali hanno origine il

Security Policy Database(SPD) eSecurity Association Database(SAD). IPsec

distingue il flusso di pacchetti in entrata (inbound) o in uscita (outbound) per i

quali esistono differentipolicyeSA.

In Figura2.2 è mostrata una schematizzazione di IPsec tramite UML. Il mo-

dello tiene conto delle specifiche dello standard IETF.

2.2.2 Security Association (SA)

Per processare propriamente i pacchetti IPsec è necessario avere un modo per as-

sociare i servizi di sicurezza e una chiave crittografica al traffico che deve essere

protetto, ed aggiungere, inoltre, le informazioni circa il computer paritario remo-

to con il quale il traffico IPsec è scambiato. In altre parole, come proteggere il

traffico, quale traffico è protetto e con chi avviene lo scambio. Il problema viene

risolto tramite la creazione di unaSecurity Association(SA), la quale contiene le

informazioni necessarie per processare i pacchetti IP secondo le direttive di IPsec.

Una SA è unidirezionale, definisce i servizi di sicurezza associati al traffico per

singola direzione, in entranta ed in uscita; pertanto, se viene richiesta una relazio-

ne per uno scambio sicuro bidirezionale, sono necessarie almeno due SA. Inoltre,

IPSec permette di negoziare SA asimmetriche: un host può avere, in questo modo,

il traffico in uscita, p.e., cifrato con 3DES ed autenticato tramite SHA-1, mediante

l’impiego del protocollo ESP; mentre il traffico in ingresso, p.e., solo autenticato

tramite MD5 attraverso il protocollo AH.

Si intuisce che ogni SA può essere associata sia ad AH che ESP, ma non ad

entrambi. Nel caso si voglia proteggere il traffico, utilizzando congiuntamente

AH e ESP, serviranno, pertanto, due security association, una per ogni protocollo.

23

2. IPsec

Ru

les

Inbo

un

d_S

PD

Ou

tbo

un

d_S

PD

Po

licy_S

PD

IKE

Pro

tocol

SA

D

IKE

_S

A

Inbound_

SA

DO

utb

oun

d_S

AD

SA

IPS

ecP

roto

col

AH

Pro

toco

lE

SP

Pro

tocol

Tra

nspo

rtA

HT

un

ne

lAH

Tra

nspo

rtE

SP

Tu

nnelE

SP

New

IPH

eader

Tra

iler_

ES

P

Hea

der_

ES

P

IKE

_S

AD

SA

_D

BS

P_

DB

manag

es

-

-

-

- -

calls

-

use

s

-

--

-

-

Is c

om

po

sed

by

-

0..*

-

Is c

om

posed b

y

-

0..*

-

Is c

om

pose

d b

y-

0..

*

-

Is c

om

pose

d b

y

-

0..*

-

is c

om

po

sed b

y

-

0..*

-

que

ries

-

qu

erie

s

-

--

--

-

-

-

-

-

-

--

--

--

Figura 2.2:Modello UML di IPsec

24

2. IPsec

Per identificare una SA si utilizza una tripla di parametri così definiti:

• Securty Parameters Index (SPI):

Una stringa di bit assegnata a questa security association. Tale valore è

trasportato nell’intestazione di AH ed ESP e viene deciso dal destinatario

della security association.

• Indirizzo IP di destinazione:

Indica il punto terminale della security association, nel caso di modalità tun-

nel (esposta nella sezione2.2.3) si tratta dell’indirizzo presente nell’header

esterno.

• Protocollo di sicurezza:

Indica quale protocollo utilizzare (AH o ESP).

Le SA possono essere create manualmente o dinamicamente, e vengono memoriz-

zate all’interno delSecurity Association Database(per il quale si veda la sezione

2.2.5). Se creata manualmente una SA non ha un tempo di vita. Viceversa, se

creata dinamicamente, una security association possiede un tempo di vita che può

essere espresso sia in termini temporali che di traffico ricevuto (bytes), scaduto il

quale la SA deve essere dichiarata non più valida e rimossa dal SAD. Tale tempo

di vita viene generalmente negoziato in fase di scambio di chiavi tra i due hosts;

identifica l’ammontare di traffico protetto da una determinata chiave e pertanto

deve essere gestito con le dovute cautele per evitare di subire attacchi al sistema

per uso permanente della stessa chiave crittografica.

2.2.3 Modalità Trasporto e Tunnel

In [1] si descrivono due modalità per applicare la protezione IPsec a ogni pac-

chetto. In modalità trasporto (non utilizzata solitamente tra secure gateway) viene

aggiunto l’header ESP (si veda la Figura2.5) o AH (si veda la Figura2.7) tra

l’header IP e l’header del protocollo di trasporto. In modalità tunnel invece il

25

2. IPsec

� � � ��

� � � ��

ESP Tunnel AH Tunnel

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � ��

AH Trasporto

� � � � ��

ESP Tasporto

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

LOCAL AREALOCAL AREA

GATEWAY

SECURE

HOST

GATEWAYSECURE

HOST

INTERNET NETWORKNETWORK

LOCAL AREA LOCAL AREANETWORK NETWORKINTERNET

HOST

SECUREGATEWAY

HOST

SECURE

GATEWAY

LOCAL AREA LOCAL AREA

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

NETWORK NETWORKINTERNET

HOST

SECUREGATEWAY

HOST

SECURE

GATEWAY

LOCAL AREA LOCAL AREA

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��

NETWORK NETWORKINTERNET

HOST

SECUREGATEWAY

HOST

SECURE

GATEWAY

Figura 2.3:Modalità Tunnel e Trasporto per AH e ESP, combinazioni possibili.

26

2. IPsec

pacchetto originale viene incapsulato in un nuovo pacchetto IP e l’header AH o

ESP viene inserito tra i due header IP. Le SA, inoltre, possono essere combinate

tra loro, sia nel caso i punti terminali delle SA siano gli stessi, sia nel caso siano

diversi (SA nesting) : si potrebbe per esempio avere una coppia di SA in modalità

trasporto tra i due host ed una coppia di SA in modalità tunnel tra i gateway che

stanno tra i due host.

In Figura2.3 sono mostrati i livelli di combinazione ed associazione tra SA,

AH e ESP.

2.2.4 Security Policy Database (SPD)

Un sistema che implementa IPsec mantiene un SPD per ciascuna interfaccia sulla

quale IPsec è attivo. Tale SPD è suddiviso in due sezioni, una per il traffico in

ingresso (SPDinbound) e una per il traffico in uscita (SPDoutbound), e contiene

un elenco ordinato di politiche di sicurezza in base alle quali ogni pacchetto IP

viene elaborato. Ogni politica del SPD è suddivisa in due parti: una parte regola

e una parte azione.

La parte regola è codificata mediante uno o più selettori e individua il tipo

di traffico da trattare secondo le modalità indicate dalla parte azione. Per ogni

selettore, nel caso la regola indichi l’uso di IPsec, vi è inoltre un’indicazione del

valore che questo deve assumere all’interno del SAD (si veda la sezione2.2.5).

La parte azione specifica se il pacchetto che ha soddisfatto la parte regola deb-

ba essere scartato,lasciato passare in chiaro, o elaborato tramite IPsec. In questo

ultimo caso viene anche specificato in che modo il pacchetto debba essere ela-

borato, indicando i protocolli e gli algoritmi da utilizzare, e viene mantenuto un

puntatore alla lista di SA attive negoziate a partire da questa politica.

I selettori mediante i quali è possibile esprimere una regola del security po-

licy database includono campi dell’header IP e dei protocolli di livello superiore

assieme ad altri elementi. Segue una lista di selettori previsti da [1]:

• Indirizzo IP di destinazione:

27

2. IPsec

può trattarsi di un singolo indirizzo IP, di un intervallo, di indirizzi (estremi

inclusi), di un indirizzo IP e una maschera di sottorete o di un indirizzo

generico (wildcard). In caso di modalità tunnel tale indirizzo IP è quello

presente nell’header IP interno. I campi presenti nell’ header IP esterno non

fanno parte dei selettori.

• Indirizzo IP Sorgente:

Può trattarsi di un singolo indirizzo IP, di un intervallo di indirizzi (estre-

mi inclusi), di un indirizzo IP e una maschera di sottorete o di un indiriz-

zo generico (wildcard). Valgono le stesse considerazioni per il selettore

precedente nel caso di modalità tunnel.

• Nome:

UserID dell’ utente, nome del sistema espresso come FQDN (Fully Quali-

fied Domain Name), X.500 DN (Distinguished Name), X.500 GN (General

Name) o di un valore generico. Tale selettore può essere utilizzato soltanto

congiuntamente ad un protocollo di scambio delle chiavi, poichè non esiste

alcun modo per immettere tale valore all’interno di un header IP.

• Livello di sensibilità dei dati:

Viene utilizzato per i sistemi MLS (Multi Level Security). Può assumere i

valori: unclassified, confidential, secret, top secret o un valore generico.

• Protocollo di trasporto:

Ottenuto dal campo IPv4 protocol o IPv6 next header. Può essere un singolo

protocollo o una wildcard.

• Porta sorgente e destinazione:

Può essere una singola porta TCP o UDP o una wildcard.

28

2. IPsec

2.2.5 Security Association Database (SAD)

Un sistema che implementa IPsec mantiene un SAD per ogni interfaccia sulla

quale IPsec è attivo. Il SAD è diviso in due sezioni: una sezione contiene le SA

relative al traffico in uscita e una sezione quelle relative al traffico in ingresso.

Ogni SA presente nel SAD è suddivisa in tre parti:

• Chiave di identificazione:

Costituita dalla tripla <indirizzo IP di destinazione, SPI, protocollo>; viene

utilizzata per individuare univocamente la SA all’interno del SAD.

• Selettori:

Contiene una copia dei selettori della politica (presente nel SPD), che ha

portato a negoziare tale SA. Per ogni selettore espresso nel SPD, è possibile

includere il valore che questo assume nel SPD oppure quello che assume

nel pacchetto che ha portato alla negoziazione della SA.

• Materiale specifico SA:

Contiene le chiavi, gli algoritmi negoziati e tutto il materiale necessario per

l’elaborazione di questa SA (dimensione della finestra, anti-replay, tempo

di vita, etc.).

2.2.6 Il protocollo ESP

Il protocollo Encapsulating Security Payload fornisce i servizi di riservatezza, au-

tenticazione, integrità e protezione contro gli attacchi replay. E’ possibile uti-

lizzare solo il servizio di riservatezza oppure solo il servizio di autenticazione e

integrità (e il servizio anti-replay se selezionato), oppure è possibile utilizzare tutti

i servizi insieme.

ESP aggiunge sia un header che un trailer questo perchè incapsula tutti i dati

che protegge. L’autenticazione offerta da ESP, a differenza di quella di AH, non

copre l’header IP esterno.

29

2. IPsec

Figura 2.4:Header ESP.

Il formato di ESP è illustrato in Figura2.4, segue una breve descrizione dei

campi che lo compongono [3]:

• Security Parameters Index:

Contiene il security parameters index della SA utilizzata

• Sequence Number:

Contiene il numero di sequenza del pacchetto per una certa SA. Analogo ad

AH

• Payload Data:

Contiene il payload del pacchetto IP (se in modalità trasporto) o l’intero

pacchetto IP (in caso di modalità tunnel). Tale campo è cifrato se si utilizza

il servizio di riservatezza. Nel caso l’algoritmo di cifratura richieda un vet-

tore di inizializzazione (IV Initialization Vector) questo è inserito all’inizio

del payload.

• Padding:

Contiene il padding (variabile 0-255 byte). Può essere incluso nel pacchetto

30

2. IPsec

perchè l’algoritmo di cifratura richiede che il testo in chiaro sia un multiplo

di una certa dimensione oppure per allineare correttamente i campi succes-

sivi o ancora per limitare gli effetti di un’analisi del traffico basata sulla

dimensione dei pacchetti.

• Pad Length:

Contiene la lunghezza del padding.

• Next Header:

Contiene il codice indentificativo del protocollo che segue ESP, per esempio

TCP o UDP.

• Authentication Data:

Contiene il valore per il controllo dell’integrità (ICV Integrity Check Value)

calcolato sull’intero pacchetto ESP privo del campo Authentication Data. Il

campo è di lunghezza variabile e dipende dalla specifica funzione utilizzata

per calcolare tale valore. Nel caso il servizio di autenticazione e integrità

non sia attivo, questo campo viene omesso.

La posizione dell’header e del trailer di ESP, sia in modalità tunnel che trasporto

è mostrata in Figura2.5.

Figura 2.5:Header e Trailer EPS per crittografia ed autenticazione dei pacchettiIP

31

2. IPsec

Figura 2.6:Header AH.

2.2.7 Il protocollo AH

Il protocollo Authentication Header fornisce i servizi di autenticazione, integri-

tà e protezione contro gli attacchi replay. AH autentica, l’header AH stesso e

l’intero pacchetto IP, a eccezione dei campi variabili che, essendo modificabili

dai nodi intermedi, non possono essere autenticati. Per IPv4 vengono considera-

ti variabili i campi: type of service, flags, fragment offset, time to leave, header

checksum più alcune opzioni il cui elenco completo si trova in [4]. Per IPv6, in-

vece i campi variabili sono: class, flow label, hop limit e tutte le opzioni marcate

come modificabili dai nodi intermedi. Si osservi che, in caso di modalità tun-

nel, viene autenticato sia il pacchetto IP interno che l’header IP esterno utilizzato

per l’incapsulamento. La posizione dell’header AH all’interno del pacchetto IP è

mostrata in Figura2.7sia per la modalità trasporto che per quella tunnel.

L’header AH è illustrato in Figura2.6, segue una breve descrizione dei campi

che lo compongono:

• Next Header:

Contiene il codice indentificativo del protocollo che segue AH (per esempio

TCP o ESP)

• Payload Length:

Contiene la lunghezza del solo header AH, in parole di 32 bit, meno 2

32

2. IPsec

• Reserved:

Riservato per usi futuri (deve essere impostato a zero)

• Security Parameters Index:

Contiene il security parameters index della SA utilizzata

• Sequence Number:

Contiene il numero di sequenza del pacchetto per una certa SA, ed è utiliz-

zato per prevenire gli attacchi replay. Quando viene stabilita una SA ogni

punto terminale inizializza questo contatore a zero e prima di trasmettere un

pacchetto lo incrementa (il primo sequence number vale pertanto 1). Se il

servizio anti-replay è attivo il mittente non deve consentire che tale campo

superi il valore232 − 1 tornando a zero. Il ricevitore gestisce il servizio

anti-replay mediante un meccanismo a finestra

• Authentication Data:

Contiene il valore per il controllo dell’integrità (ICV, Integrity Check Va-

lue). Tale campo ha lunghezza variabile ma deve comunque essere un mul-

tiplo di 32 bit. Poichè l’header AH deve avere una lunghezza multipla di 32

bit per IPv4 e di 64 bit per IPv6 è possibile inserire un padding.

2.3 I protocolli IKE e ISAKMP

Per quanto riguarda la gestione delle chiavi lo standard è attualmente costituito

dall’Internet Key Exchange versione 1 (IKEv1,[5]). Altre proposte sono in fase di

studio come il Kerberized Internet Negoziation of Keys (KINK, [6]) che propone

una soluzione per sistemi centralizzati, l’Host Identity Protocol (HIP, [7]) una

proposta innovativa che tra le altre cose propone un protocollo di scambio delle

chiavi nel caso di comunicazione end-to-end, e l’Internet Key Exchange versione

2 (IKEv2, [8]) protocollo designato come successore dell’attuale standard. Per

quanto riguarda l’interfaccia tra il protocollo di scambio delle chiavi e il SAD

33

2. IPsec

Figura 2.7:Autenticazione del pacchetto IP tramite AH.

una proposta in tale ambito è costituita dalla PF_KEYv2 [9] che permette ad una

applicazione che si sia registrata di interagire con il SAD.

L’Internet Key Exchange è un protocollo basato sul framework Internet Se-

curity Association and Key Management Protocol (ISAKMP, [10]). ISAKMP

definisce il formato dei pacchetti e gli scambi per la gestione (creazione, modi-

fica, cancellazione) delle security association e la generazione delle chiavi indi-

pendentemente dalle tecniche crittografiche utilizzate (tipo di chiavi, algoritmi di

cifratura, algoritmi di autenticazione, etc.). Il preciso contenuto e il significato di

ciascun pacchetto ISAKMP dipendono dal dominio di interpretazione (Domain of

Interpretation - DOI) che in tal caso corrisponde al dominio IPsec [11].

L’Internet Key Exchange definisce due fasi: nellaphase_1i due nodi si au-

tenticano e negoziano una security association per proteggere la fase successiva.

Durante laphase_2, che avviene sotto la protezione della prima, possono essere

negoziate molteplici SA per altri protocolli (AH, ESP ed IPcomp). La SA stabili-

ta durante laphase_1, detta ISAKMP SA o IKE SA, è bidirezionale a differenza

delle IPsec SA e rappresenta parte dello stato del protocollo, pertanto non viene

inserita nel SAD.

34

2. IPsec

Oltre a definire due fasi, IKE definisce anche due modalità e due scambi ag-

giuntivi per la corretta gestione delle security association. Durante laphase_1IKE

utilizza l’identity protect exchangee l’aggressive exchangemessi a disposizione

da ISAKMP chiamandoli rispettivamenteMain Modee Aggressive Mode. Per lo

scambio diphase_2viene introdotto ilQuick Mode. Gli altri due scambi utilizzati

(non trattati in questa tesi) sonol’informational exchange (presente in ISAKMP)

utilizzato per comunicare condizioni di errore e informazioni sullo stato delle SA

e lo scambionew group modeche permette a due peer IKE di negoziare l’uso di

un nuovo gruppo Diffie-Hellman.

IKE utilizza UDP (User Datagram Protocol) per il trasporto dei propri messag-

gi. Lo IANA (Internet Assigned Number Authority) ha assegnato a tale protocollo

la porta UDP 500.

2.3.1 IKE phase_1

La composizione dei messaggi durante uno scambio diphase_1varia in base al

meccanismo di autenticazione utilizzato. Vengono messi a disposizione quattro

modalità di autenticazione dei peer IKE: tramite segreto condiviso, tramite una

coppia di chiavi pubbliche per la cifratura in due varianti e infine tramite una

coppia di chiavi pubbliche per la firma. A ognuna di queste modalità corrisponde

una variante del Main Mode e una dell’Aggressive Mode, si hanno, pertanto, otto

possibili combinazione di scambi diphase_1.

L’autenticazione durante laphase_1fa riferimento all’autenticazione dell’i-

dentità degli hosts e non è da confondere con l’autenticazione dell’origine dei dati

che invece viene offerta da AH e ESP.

Il Main Mode è costituito da sei messaggi. Nei primi due vengono negoziati i

parametri della IKE SA, nei due messaggi successivi viene effettuato lo scambio

Diffie-Hellman per la negoziazione delle chiavi crittografiche. Nel caso di auten-

ticazione tramite una coppia di chiavi per la cifratura (nelle due varianti) vengono

comunicate anche le due identità (cifrate), infine negli ultimi due messaggi si

trasmettono le identità e la prova di essere in possesso del segreto collegato all’i-

35

2. IPsec

dentità comunicata.

Per il Main Modenel caso di autenticazione mediante segreto condiviso (si

veda la Figura2.8). Nel primo messaggio l’iniziatore comunica il proprio cookie

nell’header ISAKMP (HDR) e la propria proposta per la IKE SA (payload SA),

il risponditore replica inserendo nell’header ISAKMP il proprio cookie e selezio-

nando una delle proposte fatte dall’iniziatore per la IKE SA (payload SA). Nel

terzo messaggio l’iniziatore invia il valore DH (payload KE) insieme ad un non-

ce (payload Ni) cioè un valore pseudocasuale utilizzato, tra le altre cose, per la

generazione del materiale crittografico. Il risponditore replica in maniera del tut-

to simmetrica con il proprio valore DH (payload KE) ed un nonce (payload Nr).

A questo punto i due interlocutori dispongono di tutte le informazioni necessarie

per la generazione del materiale crittografico relativo alla IKE SA, la negoziazio-

ne continua pertanto sotto la protezione di tale materiale. Nel quinto messaggio

l’iniziatore comunica la propria identità (payload IDii) e dimostra di essere a co-

noscenza del segreto condiviso relativo all’identità IDii (payload HASH I), il ri-

sponditore, in maniera analoga replica comunicando la propria identità (payload

IDir) e la prova di conoscere il segreto associato a tale identità (payload HASH

R). La coppia di cookie presente nell’header generico ISAKMP viene usato come

identificatore univoco di unaphase_1.

L’ Aggressive Modeutilizza invece tre messaggi per autenticare le parti, scam-

biare le chiavi e negoziare la IKE SA al costo di non proteggere le identità e di ga-

rantire una minor flessibilità (mostrati in Figura2.8). Mentre nel primo messaggio

del Main Mode, infatti, l’iniziatore può comunicare tutti i gruppi Diffie-Hellman

supportati in ordine di preferenza e il risponditore sceglierne uno; nell’Aggressi-

ve Mode l’iniziatore deve scegliere un unico gruppo Diffie-Hellman. Nel caso il

risponditore non supporti tale gruppo, l’handshake dovrà essere terminato e riav-

viato. Si osservi, inoltre, che poichè dopo l’invio del primo messaggio non è stata

ancora stabilita una chiave di sessione l’iniziatore non può essere sicuro che il ri-

36

2. IPsec

Figura 2.8: IKE phase_1: Scambio messaggi in modalità Main Mode (sx) eAggressive Mode (dx) [12].

fiuto del gruppo DH arrivi dal risponditore legittimo (DoS). Durante l’Aggressive

Mode tutti i messaggi sono inviati in chiaro.

2.3.2 IKE phase_2

Sotto la protezione di una IKE SA i due interlocutori possono procedere con la

negoziazionedi una IPsec SA attraverso unQuick Mode. I punti terminali di tale

SA risultano essere gli stessi dellaphase_1. Non è possibile, attualmente, nego-

ziare IPsec SA i cui punti terminali differiscano da quelli della IKE SA sotto la

quale vengono negoziate.

Con riferimento alla Figura2.9, nel primo messaggio l’iniziatore invia le pro-

prie proposte per la IPsec SA (payload SA) e un nonce (payload Ni) inoltre può

includere anche i payload IDci e IDcr contenenti informazioni relative al traffico

37

2. IPsec

Figura 2.9:IKE phase_2: Scambio di messaggi in modalità Quick Mode [12].

che si intende proteggere ed il payload KE nel caso si desideri la Pefect Forward

Secrecy, l’intero messaggio viene autenticato dal payload HASH(1). Nel secon-

do messaggio il risponditore seleziona una proposta tra quelle fatte dall’iniziatore

(payload SA), invia il proprio nonce (payload Nr) e include i payload KE e IDcx

nel caso l’iniziatore li abbia inseriti. L’intero messaggio è autenticato mediante il

payload HASH(2). L’iniziatore risponde con un messaggio di conferma contenen-

te un paylaod HASH(3). Una tale negoziazione ha come effetto quella di stabilire

due SA, una per ogni direzione. In un singolo Quick Mode è anche possibile ne-

goziare più SA contemporaneamente inserendo payload SA multipli all’interno

del primo e del secondo messaggio. L’effetto finale di una negoziazione di SA

multiple è quello di generare2 ∗ n SA doven è il numero di payload SA inclusi

nel Quick Mode.

38

2. IPsec

2.4 Implementazioni di IPsec

IPsec può essere implementato in diversi modi:

• implementazione nativa oBump In The Code (BITC): richiede l’accesso al

codice di IP ed è applicabile sia al caso di singoli host che nel caso di secure

gateway.

• implementazioneBump In The Stack (BITS): in questo caso IPsec viene

implementato tra IP e i driver di rete. Poichè non richiede l’accesso al codice

di IP un tale approccio risulta particolarmente utile in caso di sistemi legacy.

Viene tipicamente utilizzato negli host.

• implementazioneBump In The Wire (BITW): in questo caso IPsec viene

implementato in un dispositivo esterno in genere dotato di un proprio indi-

rizzo IP. Viene solitamente utilizzato in sistemi militari e in alcuni sistemi

di tipo commerciale.

2.5 Gestione ed elaborazione del traffico IPsec

Come precedentemente accennato, IPsec distingue tra datagrammi in uscita dal si-

stema (ovvero diretti verso il livello data-link) e datagrammi in ingresso al sistema

(ovvero provenienti dal livello data-link). Per il trafficooutboundl’elaborazione

avviene immediatamente dopo aver effettuato il routing del pacchetto e quindi

aver selezionato l’interfaccia di uscita, mentre per il trafficoinbound il routing

avviene successivamente. In una visione a sottostrati del livello IP il sottolivello

di routing si trova sopra a quello IPsec.

2.5.1 Traffico Inbound

Per il traffico in ingresso al sistema bisogna innanzitutto ricomporre il datagram-

ma IP nel caso sia stato frammentato. L’interfaccia di provenienza del pacchet-

to seleziona quali database utilizzare per l’elaborazione. I campi <indirizzo IP

39

2. IPsec

Figura 2.10:Elaborazione pacchetti IPsec: Inbound [13]

di destinazione, SPI, protocollo> vengono utilizzati come chiave di ricerca della

SA all’interno del SAD. Se non viene identificata alcuna SA il pacchetto viene

scartato, in caso contrario elaborato.

Questa fase include anche il confronto dei selettori del pacchetto con quelli

presenti nella SA. Nel caso il datagramma sia autentico ma i selettori nel SAD

non vengano soddisfatti, il datagramma viene scartato. Si controlla infine di aver

applicato l’elaborazione necessaria. Tale controllo può essere effettuato o median-

te un puntatore dalla SA verso la politica del SPD che ha reso necessaria la sua

negoziazione (backpointer) o consultando il SPD e verificando che il puntatore

presente nella politica che viene soddisfatta punti proprio alla SA applicata.

Il realtivo diagramma di flusso è mostrato in Figura2.10.

40

2. IPsec

Figura 2.11:Elaborazione pacchetti IPsec: Outbound [13].

2.5.2 Traffico outbound

Per quanto riguarda il trafficooutbound, il routing seleziona l’interfaccia di uscita

del pacchetto e conseguentemente i database (SPD e SAD) da utilizzare durante

l’elaborazione (il diagramma di flusso è mostrato in Figura2.11). Il datagramma

viene confrontato contro l’SPD alla ricerca di una politica applicabile. Il database

viene percorso dalla primaregolafino all’ultima e non appena viene trovata una

politica la cui “parte regola” venga soddisfatta viene eseguita la corrispondente

“parte azione”. Nel caso non venga soddisfatta alcuna regola, il datagramma

41

2. IPsec

Figura 2.12:Elaborazione IPsec in dattaglio: sequenza di operazioni.

viene semplicemente scartato. Se si individua una politica adatta viene eseguita

la parte azione corrispondente (scartare, inviare in chiaro o applicare IPsec). Se

la politica richiede l’applicazione di IPsec viene consultato il puntatore associato

alla politica di sicurezza che può puntare a nessuna, una o più SA. Nel caso di

nessuna SA viene invocato il demone di scambio delle chiavi se presente, al fine

di negoziare la security association e tutto il materiale crittografico necessario. Se

tale entità non è attiva sul sistema il datagramma viene scartato, in caso contrario,

a negoziazione avvenuta, la SA viene posta nel SAD, collegata alla politica del

SPD e l’elaborazione applicata.

Quando la SA individuata è unica non vi sono ambiguità, l’elaborazione viene

eseguita e il pacchetto viene passato al livello inferiore, mentre nel caso le SA

siano multiple è necessario un modo per identificare quale utilizzare. A tal fine il

datagramma viene confrontato con i selettori che sono presenti nella SA (sezione

selettori). Individuata la security association il datagramma viene elaborato, in

caso opposto viene invocato il demone di scambio delle chiavi.

2.5.3 Elaborazione IPsec dei pacchetti

Si focalizza adesso l’attenzione sull’elaborazione dei pacchetti IPsec per il traffico

outbound, antecedente il loro invio allo strato data-link. L’interno del blocco “Ela-

borazione IPsec” in Figura2.11è decomponibile nella azioni espresse in Figura

2.12.

Una volta definita la corretta SA per il determinato pacchetto in analisi, si co-

nosce quale elaborazione è richiesta per proteggere i dati e come dovranno essere,

42

2. IPsec

Figura 2.13:Mappatura del datagramma IP all’interno del protocollo ESP [14].

pertanto, composti l’header ed il trailer, p.e. nel caso di ESP, da aggiungere al

pacchetto (si veda la Figura2.13).

Le operazioni richieste dal blocco “Context Management” di Figura2.12,

possono essere elecante di seguito:

1. Estrazione del SPI ed aggiornamento delSequenceNumbernell’header ESP;

controllo delsequence number rollover(si veda la Figura2.14).

2. Aggiornamento del contatore IPsec per la data SA (conteggio del numero di

pacchetti inviati da quando è stata stabilita una SA, numbero di bytes, time).

43

2. IPsec

3. Controllo se l’SA ha superato i limiti imposti dalSA LifeTime. In tal caso

intraprendere delle azioni per bloccare gli ulteriori pacchetti e provare a

ristabilire un nuovo insieme di chiavi per questa SA.

4. Se è usata la crittografia, si deve generare unInitialization Vector(IV) per

l’algoritmo crittografico (DES, 3DES, AES).

5. Se si usa la modalitàTunnel Mode, gestire i bits delType of service(TOS)

in funzione della politica associata alla data SA. In alcuni casi tali bits sono

copiati dall’header IP, in altri casi vengono rigenerati nuovamente.

6. Nel caso di modalitàTrasport Mode, il campo field nell’header IP deve

essere aggiornato indicando il nuovo protocollo, sia ESP o AH.

7. Dato che si deve aggiungere l’header ed il trailer bisogna aggiornare il cam-

po lengthdell’header IP. Inoltre, avendo modificato l’header IP originale,

bisogna ricalcolare ilchecksum.

8. Lo standard IPsec, richiede per ESP, che la lunghezza finale del pacchet-

to sia multipla di 32 bits, pertanto, bisogna calcolare ed inserire unextra

paddingnel trailer ESP. In alcuni casi, in aggiunta al precedente, un ulte-

riore padding è inserito per raccordarsi alla dimensione minima dei blocchi

richiesta dall’algoritmo crittografico (si veda la Figura2.15).

9. Infine IPsec permette l’aggiunta di un numero casuale di bits di padding per

nascondere la reale lunghezza del pacchetto e proteggerne ulteriormente il

contenuto.

A questo punto, se il pacchetto deve seguire il protocollo ESP, è pronto per

la crittografia e l’autenticazione. Viceversa, se il pacchetto segue le regole di

AH, è necessario “mascherare” qualsiasi campo variabile prima di autenticare il

pacchetto (per maggiori dettagli sui campi si rimanda alla sezione2.2.7). Dopo di

ciò, il pacchetto è pronto per essere crittato, autenticato o entrambi, dipende dal

modo d’uso. In ESP solo una porzione del pacchetto viene crittata, e una larga

44

2. IPsec

extractSPI calculateSequenceNumber

extractSequenceNumberFromSA

incrementSequenceNumber concatSN2HeaderESP

extractAntiReplay

rollCounter create_newSA

evSPIInserted:

evSeqNumExtracted:

[else]/overflow=true:

[seqNumber<boundSeqNum]:

evSNIncremented:

[else]:

[anti_replay]:

evSNadded2HeaderESP:

evCounterRolled: evNotFinished/ESPProtocol.gen(new evSequenceNumberOverflow());:

Figura 2.14:Diagramma UML degli Stati per la creazione dell’Header ESP.

fetta viene autenticata (dettagli alla sezione2.2.6). In AH, l’intero pacchetto è

autenticato (si veda sezione2.2.7).

Il processo esposto è schematizzato tramite un diagramma UML degli stati in

Figura2.16, in cui si è supposta una modalità Tunnel per IPsec con uso di ESP

per crittografia e autenticazione.

Al termine del processo, il pacchetto IP è cresciuto in dimensione dovuto al-

l’aggiunta dell’header ESP/AH e del trailer, pertanto, l’operazione susseguente

è la frammentazione. La frammentazione è un processo necessario dato che IP

impone una dimensione massima dei pacchetti che possono essere accettati lungo

ogni canale di comunicazione (MTU). In alternativa o in supporto alla frammen-

tazione si può operare un IPcomp del pacchetti [2] dato che i livelli sottostanti

(data-link) non sono in grado di effettuare un frazionamento adeguato degli IP a

causa della crittografia.

Si noti come alcune delle operazioni descritte e raffigurate in2.16, potrebbero

efficientemente essere eseguite in parallelo su dispositivi hardware dedicati.

2.6 IPSec in azione

2.6.1 Le reti private virtuali (VPN)

IPsec si presta per essere usato da molte applicazioni; fornisce, infatti, servizi a

livello di rete e pertanto è del tutto trasparente ai livelli superiori. Attualmente

45

2. IPsec

wait

putPadding

checkAlgorithmContent

applyDefaultPadding

extractPaddingFromAlgorithm countLengthOfUsefulData

extractMinSize

computePaddingBytesencryptionUsePadding

checkForAlignement

addPadding

notAddPadding

insertPadding

computePaddingLength

applyAlgorithmCoding applyDefaultCoding

applyRandomCoding applyZeroCoding

InsertPadLength

putNextHeader

evCodeAlgo:

evDefaultCoding:

evCodingSelected:

evCodingSelected:

evCountingDone:

evMinSizeExtracted:

[lenData<minSize]:

[else]/diff=0:

evDiffComputed:

startESPTrailer:

evDiffCountedEnc:

evDiffCountedAL:

[diff=0]:

[else]/startPadding=true:

[startPadding=false]:

evPadLenComputed:

[else]:

[defaultCoding]/i=1:

evAdded2Vector:

[else]/startPadding=false:

evAlgoCodingApplied:

[randomCoding]/i=1:

[ese] / i=1

evAdedd2Vector:

evAdded2VectorRan: [i<padLength]/i++:


evPaddingDone:

evPadLengthInserted:

[i<padLength]/i++:

[i<padLength]/i++:


Figura 2.15:Diagramma UML degli stati per la creazione del Trailer ESP.

IPsec costituisce uno dei più efficaci mezzi per costruire le reti private virtuali.

Le reti private virtuali (VPN,Virtual Private Networks), permettono di col-

legare tra loro delle reti locali tramite l’infrastruttura Internet, garantendo però

sicurezza (riservatezza, integrità. . . ) al traffico che viaggia sulla rete esterna.

Utilizzando IPsec questo è possibile: è sufficiente inserire nelle reti locali dei se-

cure gateway attraverso i quali far passare tutto il traffico diretto alle altre reti, e

creare dei tunnel IPsec tra i secure gateway. In questo modo il traffico diretto da

una rete all’altra viaggia su Internet ma è protetto dal tunnel IPsec, il tutto senza

che gli host, né tantomeno le applicazioni, debbano preoccuparsene. Si ha così,

virtualmente, un’unica rete privata che sfrutta l’infrastruttura della rete pubblica.

Un esempio di questa architettura è illustrato in Figura2.17.

Le VPN sono un caso tipico in cui si può avere la sovrapposizione di vari livel-

li di IPsec. Si supponga che il tunnel tra i secure gateway utilizzi ESP con cifratura

e integrità: allora tutto il traffico che fluisce tra di essi verrà cifrato e autenticato.

In qualche caso si potrebbe però volere anche sicurezza end-to-end, e impostare

IPsec tra due host appartenenti a reti diverse, per esempio utilizzando ancora ESP.

46

2. IPsec

putPayload

insertOriginalIPPacket

computeESPTrailer concatESPTrailerencryption

putHeaderESP

putIPHeader

concatNewIPHeader

computeNewIPHeader

concatAuthField authenticationESP

skipAuthentication

extractAuthAlgo

concatHeaderESP

evPayloadExtracted: evExtractPayload

evESPTrailerComputed: evESPTrailerInserted:

evEncryptionDone:

[itsNewIPHeader.evNewIPHeaderDone()]:

evNewIPHeaderInserted/packet_finished=tre;before_new_header=false;:

[before_new_header=true]:

evConcatDone/before_new_header=true;packet_finished=false;:

evAuthDone:

headerESPInserted:

evSkippingDone/before_new_header=true;packet_finished=false;:

[auth_algorithm="NULL"]:

[auth_algorithm!="NULL"]:

evHeaderESPcomputed:

payloadInserted:

evSkipDone:

evSequenceNumberOverflow:

Figura 2.16:Diagramma UML degli stati per l’elaborazione IPsec in modalitàTunnel.

Allora tutto il traffico tra questi due host verrebbe elaborato da IPsec sia sugli

host, dove verrebbe cifrato/decifrato una volta, sia sui gateway, dove sarebbe ci-

frato/decifrato un’altra volta. In questo caso si ha quindi una sovrapposizione di

SA, con end-point diversi.

Con riferimento alla Figura2.17, vediamo cosa succede quando un host vuole

comunicare con altro host appartenente ad una rete differente.

Un host sulla prima rete (ad esempio con lindirizzo 10.10.42.98) che vuole

comunicare con un host sulla seconda (ad esempio 10.20.85.31) si limiterà ad in-

viare il relativo pacchetto IP senza alcun particolare accorgimento. Tale pacchetto

arriverà al secure gateway della prima rete, che si accorgerà che è destinato alla

seconda: il gateway cifrerà quindi il pacchetto e lo incapsulerà in nuovo pacchet-

to IP, che avrà come mittente il suo indirizzo pubblico (x.y.z.w in figura) e come

destinazione l’indirizzo pubblico del secondo gateway (a.b.c.d). Tale pacchetto

viaggerà normalmente su Internet, ma chi lo intercettasse vedrebbe solamente che

è in corso una comunicazione IPsec tra i due gateway, mentre non conoscerebbe

né i contenuti della comunicazione, né il protocollo utilizzato (a livello trasporto

e applicazione), né il mittente e il destinatario reali della comunicazione (l’intero

pacchetto IP originale è inviato cifrato). Quando il pacchetto arriverà al secondo

gateway, questo ne controllerà l’autenticità e l’integrità e decifrerà la porzione ci-

frata ricostruendo così il pacchetto originale, che inoltrerà poi verso la destinazio-

47

2. IPsec

Figura 2.17:La rete privata virtuale con IPsec [13].

ne. L’host sulla seconda rete riceverà quindi il pacchetto così come è stato inviato

dal mittente originale: gli host sulle due reti possono dunque comunicare tra loro

senza conoscere alcun dettaglio riguardo al tunnel IPsec (di cui possono anche

ignorare l’esistenza). Si ha così, virtualmente, un’unica rete privata che sfrutta

l’infrastruttura della rete pubblica, dato che il tunnel IPsec appare alle macchine

sulle due reti locali come un unico link virtuale.

2.6.2 La rete Road Warrior

Il road warrior si può vedere come un caso degenere della VPN, in cui da una

parte si ha un singolo host anziché una rete: un esempio tipico è quello in cui una

persona vuole accedere alla rete aziendale trovandosi all’esterno, per esempio a

casa propria oppure in viaggio, tramite una connessione sicura, in modo da essere

autenticato e da proteggere le informazioni in transito. La particolarità del road

warrior rispetto alla VPN è che in questo caso in genere l’host esterno ha un

indirizzo IP dinamico e quindi non noto a priori, al contrario di quanto avviene

con i secure gateway che hanno di solito un indirizzo IP statico e noto in fase di

configurazione.

48

Capitolo 3

Stato dell’arte

3.1 Introduzione

Performance e sicurezza sono le caratteristiche sempre più richieste alla rete glo-

bale. Avere comunicazioni che siano al tempo stesso sicure e veloci richiede

security processor sempre più efficaci. Gli utenti, dall’altra parte, non voglio-

no solo sicurezza e velocità, chiedono anche convenienza in termini di rapporto

costo/efficienza. La combinazione di network processor e security processor dedi-

cati è la soluzione ad elevato rapporto costo-efficacia rispetto ad avere un singolo

(o, probabilmente, multipli) general-purpose processor.

Un semplice network processor (NP), in uno scenario in cui la velocità delle

rete sia piuttosto bassa, è in grado di sobbarcarsi il lavoro extra richiesto dalla

crittografia. Viceversa, ad elevate velocità, il processo di crittaggio non può essere

eseguito solo a livello software; un acceleratore hardware è, pertanto, richiesto.

Una soluzione è data da un security processor dedicato, da affiancare al NP o

direttamente alla CPU del sistema, in base allo scenario d’uso.

I security processor, o acceleratori crittografici hardware, non hanno tutti le

medesime caratteristiche. Numerose sono le alternative offerte dal mercato. Un’a-

nalisi comparativa non è così ovvia come ad esempio quella che si avrebbe con-

frontando i soli algoritmi crittografici.

49

3. Stato dell’arte

In questo capitolo vengono presentati gli acceleratori hardware. Una descri-

zione generale dell’architettura e delle funzionalità di tali dispositivi ottenuta at-

traverso un lavoro di ricerca condotto in ambito commerciale.

La rassegna presentata nelle sessioni successive, è stata necessariamente fil-

trata per concentrarsi sulle problematiche inerenti il lavoro di tesi. Tra tutti gli

acceleratori hardware in commercio, l’attenzione è posta su architetture che an-

dranno a costituire soluzioni di supporto, come schede PCI, o come processori

crittografici da installare in sistemi più complessi.

I dati raccolti sono stati tratti dai siti internet delle aziende, ragione per cui

in alcuni casi sono tecnicamente poco dettagliati. Tra la multitudine di aziende

si sono selezionate le maggiori produttrici nel settore, costantemente aggiornate e

considerate promotrici di innovazione.

3.2 Broadcom

I processori Broadcom [15] si basano su una architettura proprietaria e scalabile

per ottenere il massimo delle performance dagli algoritmi crittografici usati nelle

VPN, con una velocità di processamento compresa tra pochi Megabits al secondo

a multi-Gibabits al secondo.

Le tipoligie di processori per la sicurezza si suddividono in due macro ca-

tegorie, differenziati in base al tipo di protocollo che implementano. Si hanno

acceleratori per IPsec o per SSL. Per il tema trattato in questa tesi, rilevante è

la famiglia di prodotti per IPsec identificati dal codice: BCM58xx. Vediamo nei

dettagli.

La soluzione BCM5841 (la cui foto è in Figura3.1) è l’ultima proposta dalla

Broadcom. Parametri chiave della nuova versione riguardano elevata flessibli-

tà di throughput al fine di addattarsi ad ogni scenario di rete. E’ disponibile in

quattro versioni, 600 Mbps, 1.2 Gbps, 2.4 Gbps e 4.8 Gbps, rispettivamente. Le

caratteristiche principale dichiarate sono riassumubili in:

50


Figura 3.1:Processore Broadcom 5841

• Performance e modalità operativa:

– 4.8 Gbps di throughput

– modalità AES-CBC e AES-CTR

– supporto completo per AH e ESP

• Interfaccia di comunicazione veloce e flessibile

– POS-PHY livello 3

– interfaccia FIFO

• Supporto per un numero illimitato di SAs via in-band keying

• Bassi consumi di potenza, 0.18µm, con 1.8 V di livello operativo

51


Figura 3.2:Applicazioni VPN che usano il Broadcom 5841

Figura 3.3:Corrent CR7110, schema a blocchi

3.3 Corrent

Attualmente la corrent [16] produce una serie di chip per la sicurezza appartenenti

alla famiglia dei CR7xxx. Punta di diamante della famiglia, in ambito IPsec è il

processore CR7110 il cui schema a blocchi è mostrato in Figura3.3.

Caratteristiche tecniche del CR7110 sono riassumibili in:

• Processore IPsec ad elevate performance: 1 Gbps anche con dimensione dei

pacchetti piccola

• Full-duplex POS-phy 3 Streaming Interface a 104 MHz

52


• On-chip Modulo-Exponentiation

– 512, 768, 1024, 1536, 2048 dimensione dei blocchi di bit supportata

– RSA a 1024 bit (exponent, base, modulus) con oltre 625 chiavi al

secondo in modalità CRT

• Oltre 500 connessioni/sec IKE Main Mode

• Interfaccia di comunicazione 32/64-bit, 33/66 MHz PCI

• Interfaccia Dual 64-bit, 100 MHz ECC SDRAM (DDR) per immagazzina-

mento delle chiavi e Security Associations su memorie esterne

– Supporto per oltre 1M di Security Associations simultanee in modalità

tunnel.

• Algoritmi crittografici supportati: ARC4, DES, 3DES, and AES

• Algoritmi autenticazione supportati: HMAC-MD5 e SHA-1

• IPsec Packet Processing Engine (PPE) on-chip:

– Header parsing

– Security Associations lookup

– Header e trailer manipulation

– Back-channel ICMP source lookup

• Generatore di numeri casuali conforme allo standard FIPS-140-2: True

digital 3-grade non-deterministic.

Un esempio di uso del chip CR7110 all’interno di una scheda PCI è in Figura3.4.

Si noti la presenza del NP e del posizionamentoOff-linedel chip.

53


Figura 3.4:Esempio di uso del chip CR7110 all’interno di una scheda PCI

Figura 3.5:Hifn HIPP III 8350 Security Processor

3.4 Hifn

I processori crittografici offerti dalla Hifn [17] costituiscono la serie 8xxx. In

questa sede si esaminerà l’HIPP III 8350, gioiello della casa costruttrice con 4

Gbps di throughput.

L’8350 fornisce una soluzione completa, per l’elaborazionein-line, atta ad

ottimizzare le performance di IPsec e IKE, combinando elaborazione delle poli-

tiche inbound e outbound , SA loohup, SA context handling e manipolazione dei

pacchetti tutto in un singolo chip mostrato in Figura3.5.

Caratteristiche del modello 8350 sono:

54


Figura 3.6:Diagramma a blocchi del chip Hifn HIPP III 8350

• Single-core, soluzione a basso costo:

– 4 Gbps IPsec performance

– 1 Million Pachetti al second, back-to-back SA variation

– Scalabile con altri chip per per applicazioni che supportino porte ad 1

Gbps

• Elaborazione in-line (si veda la Figura3.7):

– Protocollo IPsec e algoritmi crittografici In-line col flusso di dati

– Ottimizzato per modalità site-to-site IPSec VPN

– Supporto On-chip per l’elaborazione richiesta da IKE

– Soluzione completa per IPsec e IKE che facilita l’implementazione di

sistemi basati su IPsec

55


Figura 3.7:Esempio di uso di Hifn HIPP III 8350 in una scheda PCI.

• Ottimizzato per modalità site-to-site con:

– 512 on-chip policy entries

– Supporto per oltre 200 SAs on-chip

– Oltre 256K SAs attraverso immagazzinamento off-chip in SDRAM

• Supporto completo per l’intero protocollo IPSec :

– Tunnel, transport modes, ESP eAH

– AES (CBC & CTR), DES/3DES, SHA-1, MD5, AES-XCBC

• Specifiche:

– .13µ process, 324 LBGA (19mm square)

– Consumo di potenza inferiore a 1.75W

56


Figura 3.8:IBM 4753 Cryptographic Coprocessor

3.5 IBM

La soluzione proposta da IBM [18] per accelerare i processi crittografici si ba-

sa principalmente su architetture PCI da includere all’interno dei server, fornen-

do, come valore aggiunto, anche una protezione fisica dell’acceleratore hardware

conforme allo standard FIPS PUB 140-1. L’acceleratore hardware dell’IBM è il

modello 4753. Il prodotto è mostrato in Figura3.8mentre il suo schema a blocchi,

ad alto livello, è in Figura3.10.

L’acceleratore hardware 4753 è costituito dal chip “IBM UltraCypher Engine”

il quale è in grado di eseguire gli algoritmi crittografici richiesti da IPsec (si veda

la Figura3.9).

Riassumendo le funzionalità del 4753 possiamo dire che:

• Il core del modulo è una CPU 486 con sistema operativo proprio real time.

• Throughput di 188Mbit/s con DES in modo CBC con blocchi di 4 Mb

• Supporto per DES, DES3, RSA (up to 2048-bit modulus), DSA, SHA-1,

MD5, MD2, SSL3

57


Figura 3.9:IBM 4753 Module

3.6 Motorola/FreeScale

La casa produttrice Motorola, ha istituito un’azienda, la FreeScale Semiconductor

[19], alla quale ha affidato la produzione dei chip per la sicurezza. La famiglia

dei processori per la sicurezza prende il nome di “S1 Family” il cui MPC190 è il

prodotto d’eccellenza.

Il processore MPC190 è ottimizzato per eseguire efficentemente tutti gli algo-

ritmi associati con IPsec, IKE, WTLS/WAP e SSL/TLS; è l’unico processore sul

mercato in grado di accelerare anche gli algoritmi matematici delle Elliptic Cur-

ve, i quali sono particolamente importanti per la sicurezza delle comunicazioni

58


Figura 3.10:Schema a blocchi dell’ IBM 4758 Cryptographic Coprocessor

wireless.

Tecnicamente il MPC190 ha le seguenti caratteristiche:

• 6 unità per l’esecuzione di chiavi publiche: RSA, ECC, Diffie-Hellman

• 3 unità per l’autenticazione ognuna in grado di eseguire: MD-4, MD-5,

SHA-1

• 3 unità DES e 3DES

• 1 unità ARC4

• 1 unità per il generatore di numeri casuali

• 32bit address/64 bit data, 66MHz, PCI 2.2 compliant External Bus Interfa-

ce, con logica Master/Slave l

• 9 Crypto-Channels, con supporto per “multicommand descriptor chains”

• 1.8v supply, 3.3v I/O, 252MAPBGA

• Performance con IKE:

59


Figura 3.11:Diagramma a blocchi del MPC190

– 1024 bit Diffie-Hellman - 520 connessioni al secondo

– 155 bit ECC - 1000 connessioni al secondo

• Performance Crittografia1:

– 3DES-HMAC-SHA-1 0.6 Gbps

– DES 1.13 Gbps

– 3DES .68 Gbps

– MD5 .97 Gbps

• Esegue crittografia/autenticazione in singolo passo

1Le stime sono state raccolte tenendo conto delle seguenti operazioni: lettura dalla memoriedei data/key/context; elaborazione interna in MPC190; scrittura dei data/context nella memoria.Lettura e scrittura avvengono tramite interfaccia PCI.

60


Figura 3.12:Sun Crypto Acceleretor 4000 board

3.7 Sun

Anche la Sun [20] contribuisce coi proprio prodotti al mercato degli acceleratori

hardware con il suo “Sun Crypto Accelerator 4000 board” (in Figura3.12) per le

reti Ethernet Gigabit, che supporta sia IPsec che SSL.

Tra le altre caratteristiche troviamo:

• Session establishment rate: oltre 4300 operazioni al secondo

• Bulk encryption rate: oltre 800 Mbps

• Compatibile con RSA a 2048-bit

• Velocizza di oltre 10 volte il processo di crittaggio 3DES

• Progettato per rispettare lo standard FIPS 140-2 Level 3

• Immagazzinamento delle chiavi private e loro gestione in memoria sicura

• Riconfigurazione dimanica sui server Sun

61


• Protocolli di sicurezza supportati:

– IPsec per IPv4 e IPv6, includo IKE

– SSLv2, SSLv3, TLSv1

• Algoritmi crittografici ottimizzati: ESP (DES, 3DES) crittografia; ESP (SHA1,

MD5) autenticazione; AH (SHA1, MD5) autenticazione

• Configurabile sia come in-line (esegue DES, 3DES, SHA1, MD5) che off-

line (esegue solo per DES e 3DES, il resto in software)

• Consumi di potenza stimati intorno a 6.25 W @ 5V e 12.75 W @ 3.3V

Infine, l’acceleratore crittografico della Sun è disponibile in due versioni, una per

le reti via cavo, e l’altra per le reti in fibra ottica.

62

Capitolo 4

Approccio metodologico

al design degli acceleratori hardware

4.1 Introduzione

Per comprendere la struttura e l’utilità degli acceleratori hardware è necessario

considerare diversi aspetti: come sono connessi con il sistema? Come sono fatti?

Quali sono i modi d’uso? Quanto lavoro svolgono e come?

Dalla ricerca condotta nel mercato degli acceleratori sono sorte differenti ar-

chitetture con svariate funzionalità, andando da semplici chip a complicati pro-

cessori comprensivi di memorie interne e chip ausiliari.

Di seguito vengono descritti gli acceleratori hardware attraverso differenti

livelli di analisi per offrire una visione macroscopica del sistema acceleratore,

che sia il più possibile teorica e si distacchi da una specifica realizzazione in

commercio.

L’approccio metodologico innovativo proposto per il design degli acceleratori

è condotto ad alto livello e comprende l’osservazione dell’acceleratore hardware

da tre punti di vista differenti:

• Panoramica esterna

63

4. Approccio metodologico al design degli acceleratori hardware

• Struttura interna

• Visione d’uso

Nei paragrafi successivi si forniscono maggiori dettagli circa l’analisi svolta a

partire dallo stato dell’arte. Per ogni sezione verrano presentati gli aspetti tec-

nici adottabili in fase di design di un acceleratore hardware, seguiti da relativi

commenti.

Infine, sono proposte delle metodologie di valutazione di un acceleratore crit-

tografico hardware. Si tratta di un criterio ad uso pratico suggerito da [21], e

dello standard ufficiale di certificazione FIPS PUB 140-1, della NIST (National

Institute of Standards and Technology [22]), di cui si darà solo dei brevi cenni.

4.2 Metodologia di design per l’acceleratore

4.2.1 Panoramica esterna

Si vuole mostrare l’acceleratore come visto dall’esterno. L’osservazione è posta

su due aspetti in particolare: il posizionamento dell’acceleratore sia riferito al

sistema utilizzatore che anche rispetto al flusso di dati; e su quale sia l’interfaccia

fisica di comunicazione tra acceleratore e sistema.

4.2.1.1 Design generale e posizionamento del modulo

Un acceleratore hardaware è un dispositivo dotato di porte di ingresso e di uscita

per i dati e le istruzioni di controllo. Alcuni acceleratori hanno canali dedicati per

ogni flusso, distinguendo quello funzionale da quello di controllo (si veda la Figu-

ra4.1). Inoltre, si può ancora suddividere il flusso dati in diversi input facenti capo

a pacchetti, chiavi crittografiche, security associations, etc.; analogamente le istru-

zioni di controllo possono dar vita a ingressi separati per istruzioni di inizializza-

zione, management, esecuzione, reset, etc.; invece, solitamente l’output è costitui-

to da un unica uscita dipendente da come è realizzato l’acceleratore hardware, e

64


(Dipende dall’implementazione)

Pacchetti dati

Chiavi crittografiche

Security Associations (SA) Inizializzazione

Management

Esecuzione

Reset

Acc

Control

Output

Pacchetto Criptato

Input

Figura 4.1:Il modulo Acceleratore (ACC)

quale ruolo svolge all’interno del processo di protezione dei dati.Una tipica uscita

dell’acceleratore hardware è il pacchetto crittato, comprensivo di header.

E’ immediato chiedersi dove si installa l’acceleratore hardware e come intera-

gisce con il sistema ospitante (host).

Il modulo è collegabile all’host in modi differenti. Le possibili connessioni

fanno riferimento alla presenza o meno di un NP nell’host, ed all’architettura

stessa dell’acceleratore hardware. In particolare, si distinguono due tipologie di

connessione con l’host che prendono il nome di:

• Fabric SideConnection (FSC)

• Network SideConnection (NSC)

rispettivamente, alla connessione diretta con l’host, o con il NP1.

Il posizionamento all’interno del sistema deve inoltre tenere conto di come

l’acceleratore hardware è distribuito rispetto al flusso dei dati, rappresentato tipi-

camente da pacchetti. Le definizioni che si danno in questo ambito contraddistin-

guono due tipologie di acceleratori hardware [21, 23].

1Per termine connessione si intende il posizionamento dell’acceleratore hardware all’internodel sistema, facendo riferimento a chi controlla e fornisce dati all’acceleratore hardware.

65


Shared Resource

Fabric Proc (FP)

PHY MAC ACC

Figura 4.2:Fabric Side Connection – Inline

• In-line al flusso di dati

• Off-lineal flusso di dati (o ancheLook-aside Mode)

Le alternative possibili per l’installazione di un acceleratore hardware sono mo-

strate nelle Figure4.2, 4.3, 4.4, 4.5. La linea tratteggiata, visibile in ogni archi-

tettura, delimita l’area in cui i dati vengono elaborati applicando il protocollo di

sicurezza. Il flusso di dati è inteso in ingresso dalla rete tramite l’interfaccia di

livello fisico PHY_MAC. Le porte di ingresso/uscita di ogni modulo, acceleratore

o processore, sono raffigurate tramite blocchi rettangolari per evidenziare la ne-

cessità di un opportuna interfaccia di interconnessione tra i moduli. Nel caso di

posizionamentoFabric Side, si osservi la presenza del blocco “Shared Resource”

il quale identifica le risorse di sistema condivise dai moduli, come, p.e., la memo-

ria del sistema host. L’uso delle risorse condivise è prerogativa dei sistemiFabric

Side in quanto, l’acceleratore hardware, in questi casi, è un chip supplementare da

aggiungere al sistema. NelleNetwork Side Connectionle risorse condivise sono

assenti in quanto tipicamente accluse all’interno del NP; in questi casi, l’accele-

ratore hardware è progettato insieme al NP e, solitamente, gli viene delegato un

compito specifico, p.e., la crittografia dei dati.

66


PHY MAC

ACC

Shared Resource

Fabric Proc (FP)

Figura 4.3:Fabric Side – Look-aside Mode (Off-line)

PHY MAC ACC NP

Fabric Side

Figura 4.4:Network Side Connection – In-line

4.2.1.2 Tipologie di posizionamento, pro e contro

Nello schemaIn-line tutti i pacchetti provenienti dall’esterno, p.e. da una porta

di rete, attraversano comunque l’acceleratore hardware, al quale spetta il compito

di individuare se devono essere processati al suo interno o lasciati passare oltre.

Nel secondo caso, modalitàOff-line, i pacchetti ricevuti sulla porta di rete, sono

ridiretti al dispositivo hardware solo se ne è richiesta la protezione dei dati.

Ovviamente adottare una soluzioneIn-line offre il vantaggio di poter pro-

cessare i pacchetti crifrati immediatamente al loro arrivo, evitando che passino

per un pre-processing dal NP e velocizzando di conseguenza il processo nel suo

67


NP

ACC

PHY MAC

Fabric Side

Figura 4.5:Network Side Connection – Look-aside Mode (Off-Line)

complesso.

Dall’altro lato, si intusce che una soluzioneIn-line richiede un design congiun-

to sia del NP che dell’ acceleratore hardware o, nel migliore dei casi, la possibilità

di introdurre sistemi ponte per l’interfacciamento dei due processori. Bridges che

inevitabilmente appesantiscono il data path con possibile degrado delle prestazioni

complessive.

L’acceleratore hardware, dal canto suo, per poter supportare l’intero proces-

samento dei pacchetti, dovrebbe poter disporre di parecchi moduli supplementari

che esplitino le farie funzioni richieste dal protocollo IPsec: analisi dell’header,

autenticazione, crittaggio, etc..

Si conclude che, sebbene l’In-line processingrappresenti la scelta consiglia-

bile, è anche quella che richiede ingenti risorse spese per la progettazione del

sistema, l’interconnessione, e la realizzazione di complessi chip.

L’ Off-line processinglascia aperta la possibilità di avere un acceleratore hard-

ware fisicamente situato su un altra scheda, o su chip facilmente installabile sull’e-

sistente struttura. Lo svantaggio di un architettura simile, in molti casi, è connesso

con il bus di comunicazione tra NP e acceleratore hardware, il quale risulta esse-

re un fattore limitante per le prestazioni. Per tale motivo, spesso si utilizza una

struttura con chipOff-line in sistemi tipicamenteFabric Side, delegando all’ac-

celeratore hardware il semplice compito di crittaggio/decrittaggio e lasciando la

68


restante parte di IPsec al FP. In questo modo si riduce il traffico transitante sul

bus ma si accresse quello per istruzioni di controllo e gestione da/per l’accelera-

tore hardware, inoltre, aumenta il carico di lavoro svolto dal FP nel protocollo di

sicurezza.

La flessibilità di installazione e gestione dell’acceleratore hardware, controlla-

to via software dal FP (tipicamente general-purpose), rappresenta un buon punto

di forza a vantaggio della soluzioneOff-line, anche se può essere considerata una

scelta di design di comodo, in cui non si decentra il processo di sicurezza dei dati,

ma lo si “migliora a pezzi”, con il FP sovraccaricato del lavoro restante.

Le considerazioni esposte sulla tipologia di posizionamento del’ accelerato-

re hardware rispetto al flusso di dati valgono, con i dovuti adattamenti, sia per

architetture NSC che FSC. Si può, infatti, osservare che l’architetturaFabric Si-

de, è simile allaNetwork Side, con la differenza che il sistema, in questo caso,

non possiede un NP, pertanto il compito di processare i pacchetti viene affidato

al general-purpose fabric processor (FP). L’acceleratore hardware, di conseguen-

za, è un modulo progettato, in toto, per installarsi all’interno del host, p.e., come

scheda PCI apposita.Network Side Connectionprevede, invece, che l’acceleratore

hardware sia inteso come chip supplementare all’interno del design del NP.

4.2.1.3 Interfaccia fisica di comunicazione

Per completare il quadro tecnico sulla panoramica esterna, vengono fornite in-

formazioni circa il tipo di interfaccia di comunicazione usata dall’acceleratore

hardware [24, 25, 26]. Le alternative in commercio coprono quasi tutto l’insieme

di tecnologie utilizzabili in pratica. Di seguito è stilato un elenco delle soluzioni

adottabili e comunemente in uso, distinte per tipologia di dato a cui fanno rife-

rimento (si veda la Tabella4.1). Per maggiori dettagli si rimanda alla letteratura

specifica [27].

L’importanza dell’interfaccia di comunicazione è fondamentale. L’accelerato-

re hardware necessita di un continuo flusso di dati ed istruzione da e per il pro-

cessore dell’host (NP o FP). Spesso il canale di comunicazione rappresenta un

69


DATA I/F CONTROL I/F

8xx or 82xx local busStreaming bus 10/100 Base T

PCI 32/64 bit 33/66 MhzPL3

ARM 32 bitPL4 PCI-X 64 bit 100 MHz

Hyper TransportGbE

Tabella 4.1:Interfacce di comunicazione per un generico acceleratore hardware

fattore limitante per le prestazioni del sistema. L’obiettivo nell’uso o nella proget-

tazione delle interfacce è quello sia di aumentarne la capacità, in termini di banda

di trasmissione, sia di ridurre il numero di interazioni tra acceleratore hardware e

host.

Solitamente, dispositivi progettati per ottenere elevate performance utilizzano,

tipicamente, due interfacce, una per il flusso di dati da crittare/decrittare, e l’altra

per scopi di puro controllo. L’architettura ad una singola interfaccia è tipicamente

usata in scenari in cui la gestione delle applicazioni e dei dati è comunque de-

centralizzata sull’host. Resta, comunque preferibile, separare fisicamente i due

flussi, dati ed istruzioni, al fine di evitare processi concorrenti sul canale di comu-

nicazione, anche dovuti, p.e., ad altre risorse di sistema che condividono il canale

stesso.

Per rendersi conto che il canale di comunicazione rappresenta un collo di bot-

toglia delle performance, si pensi al fatto che le interfacce tipicamente usate in

commercio prevedono l’uso del PCI e PCI-X. In teoria la banda disponibile per

un PCI (66MHz, 64 bit ) è di 4.2 Gbps, anche se, in pratica, si stima essere di circa

1.2 Gbps in entrata ed uscita dal chip. Se, inoltre, il bus è condiviso le prestazioni

non possono che peggiorare [21].

70


4.2.2 Struttura Interna

Una volta inquadrato il chip all’interno dell’host, si deve progettare il chip spe-

cificando i componenti del modulo e quali funzioni l’acceleratore hardware deve

essere in grado di svolgere. La domanda alla quale si tenterà di rispondere in

questa sezione è: “Come è fatto l’acceleratore hardware al suo interno?”.

La comprensione dell’architettura interna dell’acceleratore hardware è legata

ad IPsec, ovvero quanto lavoro richiesto dal protocollo è svolto dall’acceleratore

hardware e quanto invece rimane al processore dell’host. Il livello di implemen-

tazione, e la profondità dei dettagli, del protocollo IPsec determinano la comples-

sità dell’acceleratore hardware. Prima, quindi, di rispondere alla domanda sul

“Com’è?” ci si deve chiedere “Cosa deve svolgere?” l’acceleratore hardware del

protocollo IPsec.

4.2.2.1 Design dell’architettura, approccio multi-livello

Come descritto nel capitolo2 dedicato ad IPsec, il protocollo risulta essere com-

plesso e prevede parecchie fasi, fra loro, spesso, distinte nettamente (p.e., scambio

delle chiavi, autenticazione, crittografia). Questa modularità si riflette nelle scelte

di design della struttura interna di un acceleratore hardware.

Volendo schematizzare il problema del design, si conviene che i fattori da

tenere in considerazione sono:

• Livello di implementazione di IPsec (STACK)

• Livello di implementazione funzionalità applicative (APPLICATION)

• Livello di complessità del chip (CORE)

4.2.2.1.1 Il livello STACK Il primo livello, STACK, si riferisce al protocollo

IPsec nelle sue specifiche. Dallo STACK IPsec le operazioni che si possono estrar-

re, in ambito crittografico, e che generalmente offrono un buon partizionamento

hardware/software sono di seguito elencate:

71


• Algoritmi di scambio chiavi: RSA, etc.

• Algoritmi di autenticazione: HMAC-SHA-1, HMAC-MD5, etc.

• Algoritmo di compressione: IPComp

• Algoritmi crittografici: DES, 3DES, AES, etc.

Il processing dei pacchetti inteso come elaborazione degli header (e trailer, nel

caso ESP) non è stato incluso nell’elenco menzionato, in quanto non direttamente

connesso con operazioni crittografiche2.

Gli algoritmo sopra elencate trovano parecchie realizzazioni in pratica ed in

letteratura [28].

Inoltre le implementazioni di IPsec suggerite da [1] sono:

• IPsec nativo con IP

• “Bump-in-the-stack” (BITS)

• “Bump-in-the-wire” (BITW)

Per maggiori spiegazioni, si riveda il capitolo2 su IPsec.

4.2.2.1.2 Il livello APPLICATION Con il termine APPLICATION si vuole,

invece, identificare l’insieme di funzionalità svolte da un acceleratore hardware.

In [25] si fa riferimento a cinque strati. Ogni strato rappresenta un insieme di

funzioni adibite alla sicurezza. Lo strato ’0’ è il riferimento. Gli strati classificano

un acceleratore hardware in base a quanto lavoro/funzionalità, del protocollo di

sicurezza, esso svolge. Per intenderci, nello strato ’0’ troviamo un acceleratore

hardware “nullo”, ovvero, tutte le funzionalità per la sicurezza si trovano nell’host.

Si riporta l’elenco degli strati, con una breve descrizione delle funzionalità ad

essi connesse, per maggiori dettagli si veda [25]:

2Analogamente per l’interrogazione dei database SAD e SPD, considerata un operazione alivello application

72


• STRATO ’0’ : Zero

Tutte le funzionalità applicative si trovano nell’host. L’acceleratore può pe-

rò eseguire operazioni puntuali dello stack IPsec, come, p.e., la crittografia.

• STRATO ’1’: Private Key

L’acceleratore hardware implementa le funzioni di gestione delle chiavi

private.

• STRATO ’2’ : Session Key

Le funzioni inerenti le chiavi private/pubbliche e le gestione della sessione

sono spostate dall’host all’acceleratore hardware.

• STRATO ’3’ : Metadata

anche le funzionalità connesse con l’elaborazione crittografica sono passate

all’acceleratore hardware

• STRATO ’4’ : Command Verification

A questo strato, l’acceleratore hardware offre servizi supplementari alla si-

curezza come, p.e., la conferma, da parte dell’utente, e quindi la verifica dei

comandi inviati dall’host all’acceleratore hardware.

• STRATO ’5’ : App-level Functionality

L’acceleratore hardware possiede sistemi per l’input e output, e meccani-

smi per la memorizzazione dei dati. Lo strato ’5’ rappresenta l’estremo

superiore di un acceleratore hardware, in cui è praticamente simile ad un

general-purpose, anche se dedicato al solo protocollo di sicurezza.

4.2.2.1.3 Il livello CORE Infine, con CORE si classificano gli acceleratore

hardware in base all’architettura fisica che li compone. Un acceleratore hardware

può essere costituito da [29]:

• single core

• multi core

73


• multi core, standalone3

La prima soluzione è quella più semplice, e solitamente si riferisce ad ASIC

progettati col solo compito di svolgere, p.e., l’algoritmo crittografico AES.

Per la seconda e terza soluzione si parla di acceleratori hardware costituiti

da parecchi moduli interni ognuno specializzato in un processo ed interconnessi

tra loro per svolgere parecchie funzioni, p.e., come la gestione del protocollo di

scambio delle chiavi. Gli acceleratori hardware in commercio sono tipicamente

di questo tipo.

Ovviamente l’acceleratore hardware può avere al suo interno delle risorse au-

siliarie, come, ad esempio, memorie protette, oppure far riferimento alle risorse

dell’host stesso.

4.2.2.1.4 Rappresentazione graficaLa metodologia di approccio al design

interno di un acceleratore crittografico hardware, esposta precedentemente, è an-

che raffigurabile graficamente con un diagramma tridimensionale (mostrato in Fi-

gura4.6) in cui il livello di sicurezza, protezione e complessità di design del si-

stema cresce con gli assi. Nelle ordinate troviamo la classificazione in base agli

strati, quindi a livello applicazione (APPLICATION). Sulle ascisse è rappresenta-

to lo stack IPsec (STACK) attraverso le macro fasi in cui il protocollo si svolge,

ordinate in termini temporali di esecuzione, prendendo come riferimento il traffi-

co in entrata (per il traffico in uscita le operazioni sono le stesse ma eseguite con

diverso ordine, si veda il capitolo2 su IPsec). La terza dimensione (CORE) iden-

tifica la classe di appartenenza dell’acceleratore crittografico in base al numero

di “core” costituenti l’architettura. Per ragioni grafiche la terza dimensione è sta-

ta raffigurata come espansione di aree; nessun significato è da associare ai limiti

delle regioni. In questo modo lo spazio delle scelte per il design di un accelera-

tore è mappato in uno spazio tridimensionale che tenga conto dei livelli descritti

in precedenza. Procedere secondo la crescita degli assi equivale a realizzare ac-

3Standalone indica che il dispositivo è costituito da un modulo unico a se stante, separata dalresto del sistema ed incluso interamente all’interno di un box protettivo anti intrusione.

74


STACK

CO

RE

AP

PL

IC

AT

IO

N

App−level

Command Verification

Metadata

Session Key

Private KeyC

om

pre

ssion

e

Critto

gra

fia

Ch

iav

i

Au

ten

tica

zion

et

Strato

Stand

alon

e

Multip

le cor

e

sing

le cor

e

Figura 4.6:Spazio di design interno di un acceleratore hardware

celeratori hardware sempre più specializzati ed autosufficienti, con conseguente

crescita della complessità progettuale ed architetturale, nonchè delle dimensioni e

consumo di potenza del dispositivo.

4.2.2.2 Selezione di un design

Sorge spontaneo chiedersi come combinare i livelli di design in Figura4.6ai fini

della progettazione di un acceleratore hardware. Non esiste un modo univoco di

prendere una decisione progettuale; esiste, invece, qualche vincolo che costringe

ad intraprendere una strada piuttosto che un altra.

Per fare un esempio, si pensi di voler realizzare un modulo che implementi

solo l’algoritmo crittografico AES [28]; sembra opportuno quindi sviluppare l’ac-

celeratore hardware a singolo core, tipicamente un ASIC o FPGA; apparterrà allo

strato ’0’ ed elaborerà crittograficamente il pacchetto protetto da IPsec, nessun

75


altra operazione del protocollo sarà svolta dal dispositivo. In ambito militare, in-

vece, dove sono richiesti alti livelli di sicurezza, sembra opportuno selezionare

un acceleratore hardware che sia multicore e standalone, in modo da includere

una certa protezione anche fisica del dispositivo e permetterne il posizionamento

anche al di fuori dell’host stesso. Un acceleratore hardware di questo tipo deve

potere gestire autonomamente l’intero protocollo IPsec e pertanto dovrà essere

di tipo strato ’4’ e salire nello stack fino a comprenderlo interamente. Una tale

implementazione di IPsec è, solitamente, di tipo bump-in-the-wire (BITW).

Sviluppare un acceleratore hardware, quindi, significa selezionare un punto

nello spazio di design in Figura4.6 ed implementare il necessario in hardware.

Ogni scelta dovrà tenere in considerazione il contesto entro cui l’acceleratore

hardware dovrà compiere il suo dovere.

In generale i vantaggi di muoversi dallo strato ’0’ agli strati superiori, e rendere

l’acceleratore hardware, al tempo stesso, completo, accrescendone la capacità di

gestire lo stack IPsec, sono ovviamente legati alle prestazioni. Un acceleratore

hardware progettato in questo modo, è particolarmente efficiente poichè altamente

specializzato ed ottimizzato al solo scopo di ottenere il massimo dal protocollo di

sicurezza. Dalla parte opposta, ci si rende facilmente conto che realizzare un

acceleratore hardware complesso, richiede parecchi sforzi di design ed alti costi

di sviluppo.

Semplificare l’acceleratore hardware sembrerebbe la soluzione a miglior rap-

porto costi/benefici, ma si deve tenere in considerazione che il protocollo IPsec

risulta particolarmente complesso sia nella sua architettura che nelle regole. Di

conseguenza, un acceleratore hardware “semplice”, magari single core, sarà af-

fiancato ad un host al quale spetterà la fetta più grande di IPsec. In un sistema del

genere l’interfaccia di comunicazione tra host ed acceleratore hardware divente-

rebbe il vero problema a livello prestazionale a causa delle numerose interazioni

di controllo e gestione tra le due parti, allo scambio dei dati, al ritorno dei risultati,

etc.

La sfida consiste, quindi, nel partizionare ottimamente lo stack IPsec tra ac-

76


Figura 4.7: Partizionamento HW/SW dello stack IPsec in funzione delposizionamento: In-line, Off-line[30].

celeratore hardware ed host, ottimizzando il processo di comunicazione sia dal

punto di vista fisico, con interfacce più efficienti e a banda più ampia, sia facendo

attenzione alla politica di gestione di IPsec inteso come applicazione distribuita e

concorrente fra i processori dedicati e general-purpose. La tabella in Figura4.7

descrive un modo in cui potrebbe avvenire il partizionamento HW/SW dello stack

IPsec.

Se si vuole puntare all’ottimizzazione del protocollo IPsec, si deve anche te-

nere in considerazione lo scopo per il quale IPsec è stato progettato. IPsec è un

protocollo “statefulness” utilizzato in ambienti in cui sono richieste sessioni, di

lunga durata, in cui il volume di dati scambiati è enorme. Al contrario, lo scambio

delle chiavi, p.e., tra i gateway avviene solo in fase iniziale e in numero limitato

rispetto alla quantità di sessioni aperte tra gli hosts delle due reti (poche chiavi per

77


molte sessioni). Risulta, pertanto, che la distribuzione delle operazioni inerenti

lo stack IPsec vede poche generazioni di chiavi (fase iniziale, p.e.,tramite RSA) e

pesante crittaggio dei dati (lungo tutta la durata della sessione, p.e., tramite AES).

La progettazione di un acceleratore hardware deve tenere in considerazione questa

distribuzione di carichi di lavoro sullo stack.

4.2.3 Visione d’uso

Una volta selezionato e sviluppato l’hardware di un acceleratore, il passo succes-

sivo consiste nel determinare quale sia il software da eseguire al fine di gestirne

l’utilizzo: il firmware e l’interfaccia di comunicazione software.

Viene dato un cenno alle caratteristiche che devono possedere il firmware e

l’interfaccia software di un acceleratore.

4.2.3.1 Design del firmware e del software

L’aspetto legato al firmware è di fondamentale importanza per rendere efficiente il

funzionamento dell’acceleratore hardware. Esso rappresenta il mezzo attraverso

cui potersi interfacciare all’acceleratore hardware e poterlo gestire.

Il design del firmware prevede che esso possa offrire servizi quali:

• Gestione della memoria

• Servizi d’immagazzinamento permanente dei dati

• Comunicazione con l’host

• Gestione dei processi e dei thread

Per quanto riguarda il software di gestione si possono seguire parecchie strade

che si differenziano, principalmente, per il livello di astrazione delle istruzioni di

controllo dell’acceleratore hardware. Un soluzione “object-based” è per esempio

proposta in [31], un altra, invece, più a basso livello (bit-level) è in studio presso

ST Microelectronics in [32].

78


Per il firmware, non si può parlare di un partizionamento tra acceleratore/host

processor in quanto è da sviluppare unicamente all’interno dell’acceleratore stes-

so. La complessità del firmware cresce con la complessità del dispositivo. Per

soluzioni multicore con alto grado di stack IPsec, si può pensare di includere un

kernel apposito per offrire e gestire ad alto livello l’acceleratore hardware e per-

mettere anche una certa flessibilità e riprogrammabilità del dispositivo. Viceversa,

per soluzioni single core una definizione del firmware a mezzo di istruzioni sui bit

sulle porte di controllo dell’acceleratore hardware è preferibile.

Diversamente, per lo sviluppo dell’interfaccia software di comunicazione tra

host e acceleratore hardware, si deve pensare come suddividere il software di ge-

stione tra le due parti e quali messaggi si possono scambiare i due processori.

Tipicamente, il software è in esecuzione sull’host ed il livello di astrazione dei

messaggi è basso, con istruzioni simil-assembler, come INIT, ENCRYPT, etc. La

ragione è da riscontrare nel fatto che l’implementazione più diffusa di IPsec è la

“bump-in-the-stack” (BITS) quindi a livello di rete di IP, direttamente gestito dal

sistema operativo dell’host. Un’altenativa pensabile è quella di un acceleratore

hardware di alto livello con, appunto, un kernel interno ed un’implementazione

“bump-in-the-wire” (BITW) di IPsec.

4.3 Metodologie di valutazione per un acceleratore

Superato lo sviluppo del firmware e del software, il design è completo. A que-

sto punto una visione d’insieme non può precludere dall’identificare un qualche

criterio per valutare il design e l’acceleratore hardware in sè. Una tabella di uso

pratico è proposta nella sezione4.3 tratta da [21]. In ultima analisi, uno sguardo

è dato allo standard della NIST (National Institute of Standars and Technology

[22]) correntemente in uso per certificare la validità e qualità di un acceleratore

hardware; standard a cui le aziende fanno riferimento per lo sviluppo dei propri

prodotti [29].

79


4.3.1 Criterio ad uso pratico

Nelle precedenti sessioni si è cercato di esporre i parametri da tenere in conside-

razione nel design di un acceleratore hardware, cercando di vagliare le possibili

alternative con spirito critico seguendo un approccio top-down.

Sembra quindi utile avere anche un criterio con il quale poter valutare le scelte

effettuate ed inquadrare un acceleratore hardware dal punto di vista prestazionale.

Le difficoltà in questo caso sono da ricondurre al fatto che manca un metodo

scientifico di misura delle performace. Considerare il solo throughput dichiarato

dalla casa custruttrice senza comprendere in che classe di appartenenza si colloca

l’acceleratore hardware e, quindi, capirne il posizionamento nell’host, il grado di

implementazione dello stack IPsec, la flessibilità e riprogrammabilità, il livello

di specializzazione, l’interfaccia di comunicazione e quant’altro precedentemente

accennato, significa commettere un errore di superficialità.

Il criterio di [21], tipicamente ad uso pratico, si presenta come una tabella

in cui sono elencati le caratteristiche chiave da tenere in considerazione quando si

vuole “misurare” un acceleratore hardware. La prima colonna contiente una breve

descrizione dell’attributo, la seconda colonna definisce un metodo di misura per

il criterio. La terza colonna mostra un esempio di metrica delle performance.

4.3.2 La certificazione NIST, FIPS PUB 140-1

Esiste una certificazione stilata dal NIST per validare la qualità e testare la sicu-

rezza di un acceleratore hardware. Lo standard a cui si fa riferimento è il FIPS

PUB 140-1, di cui si drà un solo un breve cenno in questa tesi. Le case costruttrici

di acceleratori crittografici hardware richiedono tale certificato per i loro prodotti

i quali, pertanto, vengono progettati e realizzati tenendo conto delle specifiche e

requisiti richiesti da questo standard.

Lo standard indica quali siano i requisiti che devono essere soddisfatti da un

modulo crittografico utilizzato all’interno di un sistema di sicurezza per proteg-

gere i dati nei sistemi di telecomunicazioni. Lo standard descrive quattro livelli

80


CRITERIOSTANDARD DI

MISURAZIONE

ESEMPIO DI

MISURAZIONE

IPsecperformance

AES, 3DES 2.2 Gbps

Tunnels IKE alsecondo

Main mode phase 1 IKE(1024-bit RSA kyes, 180 bit

Diffie-Hellman keys)2300 operationi/sec.

RSAperformance

1024-bit, CRT 3400 operationi/sec.

Modulocrittografico

integrato sul chipSoluzione con uno o più chip

Soluzione On-chip =single core

Algoritmicrittograficisupportati

AES (128,192 & 256bit), RC4, 3DES

Packetprocessing

Nessuno, paziale, completo Completo

ImplementazioneCo-design acceleratore e line

card a risorse condivise; oIn-line con le line card

Qualsiasi

On-chip Memory

Nessuna (uso della memoriadel sistema); cache on-chip;memoria ad alta velocità ed

accesso diretto

DDR

I/O Bandwidth Ex: PCI, PL-3, Utopia... PL3/104 MhzInterfaccia di

controlloPCI

Supportosoftware

Drivers, librerie slow-path,codice per integrazione IPsec

nei NP, stack IKETutto compreso

Consumo dipotenza

Massima vs Nominale 4-5 W massimo

Massimadimensione delle

chiavi

Massima dimensioneesponenziale per crittografia

asimmetrica (w/CRT)

Dimensione chiavi di4096-bit (w/CRT)

Tabella 4.2:Criteri di valutazione di un acceleratore hardware [21]

81


qualitativi di sicurezza: Livello 1, Livello 2, Livello 3, Livello 4. Con questi li-

velli si intende coprire un ampio intervallo di potenziali applicazioni ed ambienti

nei quali i moduli crittografici possono essere impiegati. I requisiti di sicurezza

ricoprono un area relativa al design ed implementazione del modulo crittografi-

co. Quest’area include il design di base e la documentazione, l’interfaccia del

modulo, le regole di autorizzazione e servizi, la sicurezza a livello fisico del mo-

dulo, la sicurezza a livello software, la sicurezza a livello del sistema operativo,

lo scambio delle chiavi, gli algoritmi crittografici, le interferenze e compatibilità

elettromagnetica, ed, infine, il self-testing.

Viene fornita una breve descrizione dei livelli di sicurezza del FIPS 140-1 [29]:

• L IVELLO DI SICUREZZA 1: E’ il più basso livello di sicurezza. Non è

richiesto nessuna protezione fisica del modulo. Tra gli esempi di sistemi

classificabili al primo livello si trovano i circuiti integrati (IC), e i cosidetti

prodotti per la sicurezza add-on. Al livello 1 i software crittografici sono

eseguiti solitamente nei processori general-purpose.

• L IVELLO DI SICUREZZA 2: Il livello 2 include requisiti sulla protezione

fisica del dispositivo. Troviamo, p.e., strati protettivi e lucchetti per evitare

accessi fisici non autorizzati. Inoltre, il livello 2 indica le regole di base

per l’autenticazione, tramite le quali un modulo è in grado di autenticare

un operatore e verificarne l’autorizzazione ad assumere un ruolo specifico

ed eseguire un insieme di servizi. Infine, sono permessi, a questo livello, i

software crittografici per ambienti multi utente timeshared.

• L IVELLO DI SICUREZZA 3: A livello 3 ci sono requisiti di sicurezza fisica

elevati. Si garantisce che l’accesso alle risorse critiche del modulo, come,

p.e., alcuni parametri chiave per la sicurezza, da parte di un utente non au-

torizzato, comporta, inevitabilmente, il cosidetto “zeroized” dei parametri.

Vale l’autentificazione dell’identità dell’operatore, regole più stringente del

livello precedente. Il software crittografico può essere, eseguito in ambienti

multi utente timeshared ma con reti di computer a più alto tasso di sicurezza,

82


in cui computer autorizzati e non coabitano nella stessa stuttura. Infine, le

porte di ingresso ed uscita del modulo devono essere distinte e fisicamente

separate.

• L IVELLO DI SICUREZZA 4: E’ il più alto livello di sicurezza specialmente a

livello fisico. Il dispositivo deve essere protetto contro qualsiasi intrusione.

L’acceleratore deve tenere sotto controllo anche l’ambiente operativo, inteso

come voltaggio e temperatura di funzionamento. Sono presenti meccanismi

di “zeroized” dei parametri. Il software crittografico è inteso funzionare in

sistemi multi utente timeshared in cui anche i sistemi operativi sono tenu-

ti sottocontrollo per assicurare protezione ulteriore contro operazioni non

autorizzate.

83

Capitolo 5

Acceleratore crittografico,

sistema di riferimento e modello

Si è compresa l’importanza delle reti private virtuali (VPN) le quali rappresen-

tano un modo efficiente per creare sistemi di comunicazione sicuri facendo uso

dell’esistente infrastruttura pubblica di internet. IPsec è il protocollo maggior-

mente usato per la realizzazione delle VPN (presentato e discusso nel capitolo

2). Solitamente, in un contesto del genere si usano degli acceleratori crittografi-

ci hardware per compensare il grosso onere computazionale della crittografia.(si

veda il capitolo3).

Il sistema sopra menzionato è al centro dello studio di questa di tesi (schema

SECURE GATEWAY +

SECURE CHANNEL

INTERNET

+ ACCELERATORE CRITTOGRAFICO+ ACCELERATORE CRITTOGRAFICOSECURE GATEWAY +

Figura 5.1:Rete VPN fra secure gateway con canale sicuro protetto tramite ESP

84

5. Acceleratore crittografico, sistema di riferimento e modello

in Figura5.1). E’ opportuno, quindi, poter disporre di un modello software di

riferimento che emuli l’architettura del secure gateway costituita dal processore

dell’host e da un acceleratore hardware. Un modello che sia indipendente dalla

piattaforma tecnologica allo scopo di analizzare il comportamento aSystem-Level

e apportare delle migliorie.

Prendendo spunto dalla metodologia di design di un acceleratore crittografico

hardware, esposta nel capitolo4, si è scelto di considerare un dispositivo che

implementi la sola crittografia dei pacchetti, affidando l’intera gestione di IPsec

con protocollo ESP in modalità tunnel alla CPU del secure gateway.

La progettazione del modello è realizzata allo scopo di studiare l’effetto delle

dimensioni dei pacchetti sulle performance del sistema host-acceleratore in una

rete ad elevata velocità di trasmissione; individuare, di conseguenza, un algoritmo

di scheduling che scelga tra una cifratura dei dati in hardware (acceleratore) o in

software (CPU) facendo in modo di non peggiorare il throughput o accrescere la

latenza del sistema.

La prima parte di questo capitolo espone le ragioni che hanno portato a de-

terminate scelte progettuali inerenti il modello del sistema. La seconda parte si

occupa di descrivere l’architettura di tale modello fornendo informazioni su come

sono realizzati i moduli (si veda la sezione5.3). Particolarmente importante è la

sezione5.4 in cui si descrive l’algoritmo di scheduling, e la5.5 dove si esami-

na il dataflow dell’architettura. Le simulazioni effettuate sul modello verranno

presentate nel capitolo6.

5.1 Analisi del problema e scelte progettuali

Il processo crittografico dei dati è la causa principale possibile degrado delle pre-

stazioni di un sistema che implementi IPsec. Fino a qualche anno fa un’imple-

mentazione software di IPsec era adeguata per la maggior parte delle applicazioni

in reti WAN a velocità di trasmissione di T1 (1.5 Mb/s) o T3 (45 Mb/s). Un pro-

cessore standard era in grado di processare il traffico sulla rete e trasformare i

85


pacchetti cifrati tramite gli opportuni algoritmi crittografici. Tipiche velocità di

elaborazione sono riassunte nella tabella5.1.

Algoritmo crittografico Esempio di Performance

DES 108 Mb/sAES 254 Mb/s

HMAC-MD5 837 Mb/sSHA-1 407 Mb/s

Tabella 5.1: Performance degli algoritmi crittografici per un tipico general-purpose [14].

Se consideriamo che la velocità di trasmissione della rete è in crescita, fino

alle Gigabit Ethernet, possiamo affermare che le performance di IPsec andranno

anch’esse verso il multi-gigabit rate. Chiaramente la potenza software non è suffi-

ciente a raggiungere un tale traguardo, ecco quindi che gli acceleratori crittografici

hardware sono la scelta migliore per adattarsi all’enorme velocità della rete.

Nella sezione2.5, si è mostrato come avviene l’elaborazione del traffico IPsec

e di quante operazioni esso richieda per ogni pacchetto1. Quando si è parlato

della metodologia di design degli acceleratori si è fatto anche notare come sia

necessario individuare un buon punto di trade-off tra quanto sviluppare in hard-

ware all’interno dell’acceleratore e quanto mantenere in software nel processore

dell’host (si veda la sezione4.2). Verranno ora ripresi questi concetti ed applicati

al nostro modello. Il risultato darà origine alle specifiche del nostro acceleratore

hardware.

La linea seguita per comprendere quali siano i compiti assegnati al nostro

acceleratore fa riferimento al partizionamento suggerito da [14]. Esso può essere

considerato come una possibile realizzazione del nostro modelloSystem-Level.

Vediamolo in dettaglio con riferimento alle operazioni descritte in sezione2.5.

La policy lookuppuò essere realizzata efficientemente in hardware con una

Content-Addressable Memory(CAM) ad alta velocità d’accesso. L’overhead ri-

1Alcuni sostengono che IPsec sia troppo complesso e criticano la sua architettura [33].

86


chiesto per la gestione è minimo. Pertanto è una funzione che si potrebbe aggiun-

gere al processore senza rischi di un sovraccarico per lavoro extra.

La SA lookuppuò essere implementata in vari modi. Per un numero ridotto

di SA simultanee (nell’ordine delle centinaia) può essere progettata come una

semplice ricerca binaria ancora gestita tramite CAM. Per un numero elevato di

SA (migliaia) invece si deve puntare ad una ricerca binaria più efficiente oppure

all’hashing. In entrambi i casi, analogamente a quanto detto per lepolicy, si può

pensare di gestire il tutto direttamente tramite il processore (con migliaia di SA

l’overhead computazionale potrebbe diventare un problema).

Aggiungere l’IPsec header(e trailer) è qualcosa che il processore può svolge-

re senza troppe penalizzazioni visto anche il fatto che comunque tali funzioni so-

no presenti nella gestione del normale traffico IP. Tali funzionalità rappresentano

delle add-on a quanto già esistente.

Per l’SA context, le operazioni richieste sono gestibili dal processore. In questo

caso il problema reale è rappresentato dalla larghezza di banda della memoria e

non dal consumo di risorse computazionali.

La crittografia richiesta da IPsec, come ripetutamente dichiarato, per operare

ad elevate velocità della rete deve necessariamente essere implementata in hard-

ware. Chiaramente una soluzione data da ASIC o FPGA dedicati è preferibile alla

gestione in un processore generico.

Infine, per la frammentazione possiamo dire che essa è richiesta se il pacchetto

IPsec supera la dimensioni della MTU della rete. Tale limitazione diventa trascu-

rabile con le reti attuali. Pertanto un’implementazione all’interno del processore

non dovrebbe risultare computazionalmente onerosa.

Nel modello considereremo quindi un acceleratore hardware con il solo com-

pito di eseguire la crittografia dei dati.

5.1.1 Specifiche dell’acceleratore crittografico

Il modello di riferimento per il nostro acceleratore è quello di unlight-weigh

accelerator.

87


La traccia seguita nella definizione delle specifiche del chip è riassunta nel

seguito. Fondamentalmente come linea guida si richiede di avere un chip critto-

grafico che abbia:

• Design semplice.

Progettare un circuito ASIC (o anche FPGA) che implementi l’algoritmo

crittografico AES richiede uno sforzo significativamente minore rispetto

a realizzare un sistema multi-core che implementi l’intero protocollo IP-

sec. La semplicità del dispositivo lo rende anche altamente flessibile ed

adattabile.

• Bassi costi.

Analogamente a quanto esposto nel punto precedente, i costi di sviluppo,

realizzazione e time-to-market sono notevolmente ridotti rispetto ai sistemi

multi-core.

• Indipendenza dal protocollo.

Un chip che implementi un algoritmo crittografico è utilizzabile anche in

ambiti diversi dal solo protocollo IPsec. Lo stesso chip potrebbe essere

usato, per esempio, anche con il protocollo SSL.

• Versatilità e scalabilità.

La semplicità del chip comporta che le dimensioni dello stesso siano no-

tevolmente ridotte. Si intuisce che una soluzione del genere possa essere

anche facilmente scalabile, raddoppiando o triplicandone il numero di ac-

celeratori al fine di incrementare il parallelismo e quindi le performance

complessive del sistema.

Così facendo si tenta di eliminare il collo di bottiglia del peso computazioneale

della crittografia risolvendolo con un hardware dedicato. Ovviamente esiste il ro-

vescio della medaglia: la presenza di un chip così semplice richiede una continua

interazione col sistema che potrebbe essere controproducente per le performance,

allungando complessivamente la tempistica del protocollo IPsec.

88


Tenendo in mente questi obiettivi progettuali, si sono definite le specifiche per

il nostro acceleratore esposte nel seguito.

Adottando l’approccio metodologico del capitolo4 definiamo le specifiche

del nostro acceleratore crittografico tenendo presente anche il partizionamento

HW/SW esposto nella sezione .

• Design generale e posizionamento del modulo

– L’acceleratore hardware ha due ingressi, una per i pacchetti e l’altro

per le chiavi crittografiche. Le istruzioni di controllo e management

viaggeranno su un canale di comunicazione dedicato. L’output è co-

stituito dal pacchetto cifrato. Il posizionamento è di tipoFabric Si-

de Connection(FSC) in modalitàlook-asidecon condivisione della

memoria di sistema.

• Interfaccia fisica di comunicazione

– Il bus di comunicazione usato è di tipo PCI 32 bit 66 MHz.

• Design architettura

– L’implementazione di IPsec per l’uso congiunto con l’acceleratore è

di tipo bump-in-the-stack(BITS). L’acceleratore ha il compito di cri-

frare i dati attraverso opportuni algoritmi crittografici. Gli algoritmi

quali, p.e., generazione e scambio di chiavi, autenticazione, etc., sono

eseguiti dal processore di sistema.

– Secondo la classificazione di [25], l’acceleratore si colloca allo stra-

to ’0’, in cui tutte le funzionalità a livello applicazione sono gestite

tramite processore di sistema.

– L’acceleratore sarà costituito da un chip single-core adibito alla cifra-

tura dei dati con un throughput di circa 250Mbit/s.

89


• Design del firmware e dell’interfaccia software

– Il firmware del chip è costituito da circuiteria di controllo per la gestio-

ne interna del modulo e la comunicazione con il processore di sistema.

Nessuna gestione della memoria, o immagazzinamento protetto dei

dati sono implementati all’interno del chip pertanto nessun firmware è

richiesto per amministrare tale funzionalità.

– Per l’interfaccia software si adotta una soluzione a bit-level, con istru-

zioni simil-assembler. Il riferimento è [32].

Il design generale rispecchia perfettamente le politiche progettuali riassunte nella

sezione precedente. Adottare una soluzioneFabric Side, look-asidecon inter-

faccia PCI consente infatti di potere includere l’acceleratore in un qualsiasi si-

stema che supporti il canale PCI senza stravolgerne l’architettura. L’acceleratore

crittografico rappresenterebbe quindi una normale estensione del secure gateway,

con costo di adattamento pari a zero. Analogamente, l’implementazione di IPsec

di tipo bump-in-the-stackè realizzabile semplicemente come un’aggiornamento

del sistema operativo, ed il costo di sviluppo per il firmware ed dell’interfaccia

software sono anch’essi ridotti data la semplicità del chip crittografico.

5.2 Sistema di riferimento

A questo punto avendo le specifiche dell’acceleratore siamo in grado di definire in

dettaglio l’architettura del nostro sistema (schematizzato in Figura5.2) dal quale

sviluppare il modello con cui verranno effettuate le misurazioni .

Il sistema di riferimento preso in esame in questa tesi consta di una CPU e di

un acceleratore crittografico entrambi connesse alla memoria tramite bus. Ovvia-

mente il bus tra CPU e memoria e significativamente più veloce del bus PCI al

quale si appoggia l’acceleratore. Ilbridge in figura connette il bus PCI col bus

veloce a formare un unico sistema di comunicazione.

90


Shared Memory

PCI bus

Fast bus

Bridge

HardwareEncryption

SoftwareEncription

Scheduler

CPU

Accelerator

Figura 5.2:Modello di riferimento del sistema.

5.3 Architettura del modello

Il modello è tratto, con le dovute modifiche da [34]. Come già accennato, il mo-

dello del nostro sistema si colloca aSystem-Level-Design, pertanto la computa-

zione dei dati è stata rappresentata attraverso ritardi sul datapath del sistema. Per

esempio il bus PCI è stato modellizzato come un ritardo dato dalla trasmissione

dei pacchetti da e per la memoria. Sono stati trascurati i conflitti che potrebbero

incorrere nell’accesso alla RAM da parte dei due processori, così come sono stati

ignorati i messaggi necessari per l’intercomunicazione tra CPU ed acceleratore.

Tali messaggi sono stati emulati come ritardi nell’elaborazione dei dati ed inclusi

nel tempo di inizializzazione del dispositivo. Avere ignorato i conflitti sulla RAM

introduce un errore trascurabile in quanto l’accesso alla RAM è solitamente più

veloce che l’accesso al bus PCI.

Novità del modello rispetto alle architetture solite è l’uso parallelo di CPU

ed acceleratore per la crittografia dei dati. A tal fine si è scelto di implementare

l’algoritmo AES in entrambi i processori. In questo modo si ha un confronto omo-

geneo in termini di algoritmo crittografico. Inoltre AES si dimostra essere partico-

91


larmente efficiente nella sua implementazione software rispetto ad altri algoritmi

della stessa classe. Un’implementazione hardware di AES invece è presentata in

[28].

Tutti i moduli sono stati descritti facendo uso del linguaggioSystemC[35]. Il

SystemCè un insieme di librerie e framework sviluppate in C++ che offre costrutti

per la creazione di oggetti hardware-oriented. La potenzialità del framework pro-

prietario permette di simulare processi concorrenti e gestire lo scorrere del tempo

per emulare elaborazioni software. Tali caratteristiche si adattano ottimamente ai

nostri scopi.

5.3.1 I processori

Ai fini del nostro modello, la CPU e l’acceleratore crittografico possono essere

modellati in maniera analoga. Infatti, ciò che conta per la nostra analisi è il ritardo

che essi introducono nel datapath; ritardo dovuto al processo crittografico che è

funzione della dimensione del pacchetto. Si suppone che il tempo di elaborazio-

ne sia conosciuto a priori. Un affermazione del genere è valida per gli algoritmi

crittografici a chiave simmetrica (come l’AES nel nostro caso). Pertanto il tempo

di elaborazione è funzione del numero di blocchi costituenti il pacchetto in esa-

me. Inoltre, si assume che ogni pacchetto sia indipendente dagli altri, in perfetto

accordo con quanto descritto negli RFC di IPsec.

La prima assunzione fatta, sulla conoscenza a priori del tempo di elaborazio-

ne, non è però perfettamente valida per il processamento del pacchetto a mezzo

del software nella CPU. Il processore di sistema infatti alloca le risorse necessarie

per il processo crittografico in funzione del proprio carico di lavoro in quel deter-

minato istante. Questo aspetto è tenuto in considerazione nel nostro modello at-

traverso due costanti,Iratio edEratio che rappresentano rispettivamente il rapporto

tra i tempi di inizializzazione (Iratio) e crittaggio (Eratio) del processore rispetto

a quelli dell’acceleratore. Infatti ciò che conta per i nostri scopi è il rapporto re-

lativo tra le velocità (tempi) dei due processori in modo da poter studiare come

tale rapporto influenzi il livello di concorrenza del sistema e simuli, assegnando

92


staticamente valori diversi alle suddette costanti, la variabilità software dei tempi

di elaborazione della CPU.

Così facendo l’equazione per il calcolo del ritardo è la stessa per i due pro-

cessori; la differenza è data, appunto, dalle due variabiliIratio edEratio (presenti

nella CPU, e pari a “1’, invece, nell’acceleratore).

L’equazione per l’acceleratore è pertanto:

tenc,1 = tinit,1 +

⌈bdata

16

⌉∗ tblock,1 (5.1)

Analogamente per il processore di sistema si ha:

tenc,0 = (tinit,0 ∗ Iratio) +

⌈bdata

16

⌉∗ (tblock,0 ∗ Eratio) (5.2)

Il termine tencrappresenta il ritardo complessivo dovuto al processo di critto-

grafia ed è dato dalla somma del tempo di inizializzazione,tinit , e dal tempo per

cifrare un pacchetto di dimensioni pari abdata bytes considerando che il tempo

per cifrare un blocco di 16 bytes è pari atblock. Il pedice “0” e “1”, identificano il

processore: rispettivamente “0” per la CPU e “1” per l’acceleratore.

Come si può notare dalla Figura5.2, ogni processore ha una coda FIFO in cui

vengono memorizzati i pacchetti prima di essere processati. Le dimensioni della

coda, nel nostro modello, sono state fissate a 50 elementi.

5.3.2 Il bus

Il meccanismo di accesso al bus tiene conto delle contese che si potrebbero pre-

sentare. L’accesso al bus, se libero, viene dato al processore che ne richiede l’uso

nel momento stesso della richiesta. Nel caso di bus bloccato da un altra risorsa, il

processore è messo in attesa fino a quando il bus ritorna libero.

La trasmissione sul bus, tipicamente dal processore alla memoria (e viceversa),

è anch’essa modellizzata come ritardo sul datapath, in funzione della dimensione

del pacchetto trasmesso. L’equazione è la seguente:

93


tbus = tbus−cycle ∗(Caddress +

⌈bdata

Lbus

⌉)(5.3)

Dove tbus−cycle è il periodo del bus che nel nostro caso è pari a(

166∗ 106

);

inveceCaddressè il tempo necessario per settare l’indirizzo, che con bus PCI in

DMA è pari ad un ciclo di bus;bdata è la lunghezza in bytes dei dati da trasferire

sul bus mentreLbus è la lunghezza della parola del bus, pari a4per PCI 32bit.

5.3.3 La memoria

Nella memoria RAM sono memorizzati sia i pacchetti “normali” che i pacchetti

“protetti” i quali hanno subito il crittaggio da parte dell’acceleratore o della CPU.

Nessuna modellizzazione delle memoria RAM viene fornita in questa sede. Come

anticipato, l’accesso alla memoria RAM è solitamente più veloce rispetto all’ac-

cesso al bus PCI e pertanto, avere trascurato eventuali conflitti di memoria non

costituisce grave penalizzazione per il modello in esame.

L’accesso da e per la memoria è simulato come traffico sul bus.

5.3.4 Lo scheduler

Lo scheduler è un processo eseguito all’interno della CPU di sistema. E’ costituito

da una coda FIFO in cui vengono memorizzati i pacchetti in ingresso al sistema, i

quali devono poi essere smistati verso l’acceleratore o la CPU allo scopo di essere

crittati. Per operare la scelta del processore lo scheduler fa uso di un algorit-

mo opportunamente studiato per ottimizzare il parallelismo tra i due processori

ed ottenere migliori performance dal sistema. La descrizione dell’algoritmo di

scheduling è alla sezione5.4.

94


5.4 Algoritmo di scheduling

Il cuore della architettura è costituito dallo scheduler il quale distribuisce oculata-

mente i pacchetti che devono essere cifrati tra CPU ed acceleratore. Per funzionare

lo scheduler segue un determinato algoritmo. Data l’architettura innovativa pro-

posta in questa tesi, in cui si hanno due opportunità di crittografia dei pacchetti,

ovvero, sia totalmente a carico della CPU, oppure tramite l’ausilio dell’accelera-

tore crittografico, l’algoritmo di scheduling deve essere studiato ad hoc per otti-

mizzare il parallelismo tra i due processori ed amministrare a dovere il traffico che

necessita di essere cifrato.

Le fondamenta dell’algoritmo di scheduling si basano sulle assunzioni esposte

nella sezione inerenti i processori, ovvero: la conoscenza a priori del tempo di

elaborazione richiesto dall’algoritmo di crittaggio, funzione solo della lunghezza

del pacchetto dati; e la totale assenza di dipendenza tra un pacchetto ed un altro.

Il concetto chiave è semplice: distribuire il pacchetto al processore che im-

piegherà meno tempo per elaborarlo. Per mettere in atto tale concetto, si com-

prende come sia necessaria un’equazione, abbastanza accurata, attraverso la quale

si possa calcolare il tempo di completamento delle operazioni, per il determina-

to pacchetto, in quel particolare processore (indicato col terminetempo di fine).

L’equazione sviluppata per il calcolo deltempo di fineè la seguente:

fk = wk + pk , k = {0, 1} (5.4)

Il tempo di fine, fk, per ogni processorek, (con:k = 0 per la CPU;k = 1per

l’acceleratore), è definito come la somma deltempo di attesa,wk, e del tempo

di processamento, pk. Il terminepk = pk (bdata) è funzione delle dimensioni del

pacchetto in accordo con le equazioni5.1(perk = 1) e5.2(perk = 0). Il calcolo

del tempo di attesaper il processorek, invece, tiene conto di due fattori: il tempo

di computazione dei pacchetti memorizzati nella coda FIFO (tempo di attesa in

coda, qk) e deltempo residuodi computazione (rk) riferito al pacchetto in fase di

processamento in quel momento. Pertanto si ha che:

95


qk = qk (t) =N∑

n=1

ckn (5.5)

Il tempo di attesa in coda, nel processorek, è dalla sommatoria deitempi di

computazione, ckn, di ogni pacchetto della coda FIFO di dimensioniN . Il valore

del ckn è ottenuto applicando le equazioni5.1 e 5.2. Ovviamente il tempo di

computazione di una coda vuota è pari a zero. Si intuisce che iltempo di attesa in

coda, per come è stato definito, può essere facilmente aggiornato ad ogni aggiunta

o prelevamento di un nuovo pacchetto dalla coda, pertanto si presta ad una facile

implementazione software.

Il tempo residuoè calcolato come:

rk = rk (t) = cjk −

(t− tjk

)(5.6)

in cui cjk rappresenta il tempo di computazione del pacchettoj; j è il pac-

chetto che al tempot, tempo corrente della simulazione, è in fase di elaborazione

da parte del processorek; mentretjk è il tempo in cui ha avuto inizio l’elabora-

zione del pacchettoj all’interno del processore; pertanto(t− tjk

)è il tempo di

computazione finora trascorso.

In definitiva il tempo di attesa,wk, per il pacchetto correntemente in esame

può essere espresso come:

wk = wk (t) = qk (t) + rk (t) (5.7)

5.5 Funzionamento del sistema

Con riferimento alla Figura5.3, viene adesso descritto il funzionamento del siste-

ma a runtime. Il modello può essere considerato valido sia nel caso di cifratura

dei pacchetti che nel caso di de-cifratura. Infatti con ragionevole approssimazione

con l’algoritmo AES i due processi impiegano lo stesso tempo. Pertanto, in questo

esempio e nel seguito, considereremo solo il flusso di dati in uscita (outbound),

96


Main FIFO queue

Fast Bus

PCI bus

Scheduler

HardwareEncryption

Accelerator

SoftwareEncription

CPUCPU FIFO queue

Acc FIFO queue

Figura 5.3:Schema di funzionamento in realtime.

con pacchetti che necessitano di essere crittati. Il flusso di dati si articola nelle

seguenti operazioni:

1. I pacchetti in ingresso nel sistema vengono immagazzinati nella coda dello

scheduler (main queue).

2. Scheduler

(a) preleva il pacchettoj dalla coda FIFO.

(b) calcola iltempo di fine, fk, entro cui verrà elaborato il pacchettoj per

ognuno dei due processori

(c) alloca il pacchettoj al processore con il minoretempo di fine. Il

pacchettoj viene inserito nella coda del rispettivo processore.

3. Processore (CPU o acceleratore)

(a) Attende che ci siano elementi nella sua coda FIFO.

(b) C’è almeno un pacchetto in coda. Preleva il pacchettoj dalla coda.

i. Elabora il pacchettoj (crittaggio/decrittaggio)

ii. Invia il pacchetto cifratoj in memoria.

97


Le code dei processori rappresentano porzioni di memoria RAM riservata. Per-

tanto come si può notare dalla Figura5.3, il prelevamento di un pacchetto dalla

coda FIFO interessa il bus. Analogamente, i pacchetti cifrati, restituiti dai proces-

sori, vengono memorizzati in memoria RAM, quindi viene nuovamente usato il

bus per il loro trasferimento.

Si fa notare che l’intero sistema è temporizzato da un clock master, ma è anche

del tutto asincrono grazie alla presenza delle code. Lo scheduler ed i processori

lavorano in maniera indipendente l’uno dall’altro.

5.6 Analisi ed obiettivi del modello

La presenza di un acceleratore crittografico inevitabilmente porta all’insorgere di

altri fattori che potrebbero essere limitanti per le performance del sistema. Sebbe-

ne ottimizzato per i processi crittografici, esso è penalizzato, p.e., dall’elaborare

pacchetti con dimensioni ridotte. Come mostrato in Figura5.4, l’acceleratore

offre performance migliori al crescere delle dimensioni dei pacchetti; si noti l’an-

damento esponenziale in funzione della dimensione. Una delle cause di questa

perdita di efficienza è dovuta principalmente al fatto che il tempo per trasferire i

dati all’acceleratore ed il tempo di setup del dispositivo sono, con pacchetti di di-

mensioni piccole, complessivamente superiori al tempo di processamento dei dati

stessi.

Aggiungendo l’acceleratore crittografico al secure gateway rischiamo di avere

spostato, e non risolto, il collo di bottiglia costituito dal peso computazionale degli

algoritmi crittografici per il processore general-purpose. Il nuovo collo di bottiglia

risiede adesso nell’inefficienza che ha l’acceleratore nel processare i pacchetti IP

di dimensioni minime. Comunemente ci si riferisce a questa penalizzazione con

il termineIPsec tax.

Il problema non è del tutto trascurabile se si pensa che, secondo un’analisi

condotta dal CAIDA [37] (Cooperative Association for Internet Data Analysis),

la dimensione più probabile per il traffico su internet è pari a 40 bytes, come chia-

98


Figura 5.4:IPsec Throughput in funzione delle dimensioni dei pacchetti [36].

ramente mostrato in Figura5.5. In pratica, nel caso degli acceleratori crittografici,

il valore di riferimento per cui si considera un pacchetto piccolo è di 64 bytes.

La Figura5.6 mostra invece quali siano i valori della media e del mediano in un

arco di tempo di analisi del traffico pari a circa 11 mesi. Si può concludere che,

osservando il traffico su internet, la dimensione dei pacchetti ha una distribuzione

compresa in un insieme predominante di lunghezze costituito da 40/64 bytes, 576

bytes e 1500 bytes, con una media complessiva intorno ai 400 bytes.

Il modello sviluppato in questa tesi tiene conto dei problemi legati alle reti ad

alta velocità e allaIPsec taxpagata dall’acceleratore per i pacchetti piccoli. Si

vuole investigare sulla dipendenza tra performance e dimensione dei pacchetti in

modo da studiare soluzioni in grado di apportare miglioramenti al sistema. Il pun-

to d’intervento per ottimizzare il sistema, data la naturaSystem-Level del modello,

è costituito dall’algoritmo di scheduling dei pacchetti.

La necessità dello scheduler parte da un presupposto logico: si vuole evitare

99


Figura 5.5: Distribuzione cumulativa della lunghezza dei pacchetti su internet[37].

infatti di convogliare indiscriminatamente i pacchetti da cifrare verso l’accelerato-

re principalmente perchè si rischierebbe la saturazione del dispositivo in ambienti

ad elevato network rate; e secondo, perchè il peso dellaIPsec taxinfluenzerebbe

negativamente le performance. L’idea di base invece è quella di individuare un

algoritmo di scheduling che smisti i pacchetti tra un crittaggio in hardware, quindi

a mezzo dell’acceleratore, o in software tramite invece il processore di sistema. In

questo modo si dispone di due processori (CPU ed acceleratore) per la cifratura

dei dati aumentando il grado di parallelismo del sistema. L’uso congiunto della

CPU inoltre potrebbe sortire effetti positivi sullaIPsec tax, preferendo una cifra-

tura software dei pacchetti piccoli (naturalmente deve esistere un guadagno nel

fare ciò).

Si ponga attenzione al fatto che, a differenza di quanto avviene in ambito

commerciale, nel modello in esame la presenza dell’acceleratore non esclude che

100


Figura 5.6:Media e mediano, e rispettive varianze, dei pacchetti su internet in 11mesi di osservazioni. [37].

la CPU possa comunque espletare un algoritmo crittografico senza fare uso del-

l’hardware dedicato. E’ compito dello scheduler individuare la scelta migliore tra

CPU ed acceleratore in funzione dello stato del sistema in un determinato istante

di tempo.

Volendo riassumere gli obiettivi allo studio, possiamo fare riferimento alla

Figura5.7, in cui viene visualizzato il flusso di analisi del sistema. Punto d’origine

è dato dalla necessità di avere alte performance in ambienti VPN basati su IPsec

con elevate velocità di trasmissione della rete . Soluzione proposta è quella di

un acceleratore hardware, di cui abbiamo dato le specifiche nella sezione5.1.1,

sul quale aggravare il processo crittografico. Il dispositivo soffre della cosiddetta

IPsec tax, ovvero le performance decadono con le dimensioni dei pacchetti. Per

compensare tale effetto, si cerca di processare i pacchetti piccoli (64 bytes) nella

CPU stessa. Il modello è, quindi, costituito da due processori crittografici, uno

101


IPsec Tax

Scheduling

Ottimizzato

Algoritmo

Scheduling

Parallelismo

CPU

Acceleratore

Crittografia

Tramite CPU

Software

Acceleratore

Crittografico

Hardware

Rate

High Network

Algoritmo

Figura 5.7:Flusso di analisi e generazione obiettivi.

hardware (l’acceleratore) ed uno software (la CPU). A questo punto è necessario

un’adeguato algoritmo di scheduling dei pacchetti per smistare il crittaggio tra i

due processori. Su tale algoritmo di scheduling verranno effettuati i miglioramenti

al fine di ottenere risultati migliori in termini di performance e di latenza media

del sistema.

102

Capitolo 6

Simulazioni sul modello e sliding

window

6.1 Design space exploration

6.1.1 I pattern di traffico

Al fine di studiare l’effetto delle dimensioni dei pacchetti sul nostro modello si

è scelto di sottoporre il sistema ad un traffico generato “sinteticamente”. Le ti-

pologie di traffico (pattern) utilizzate nelle simulazioni si differenziano per due

parametri: dimensione del payload e security association (SA).

Per la dimensione del payload dei pacchetti si sono adottate quattro differenti

distribuzioni statistiche riassunte nella tabella6.1, ognuna con 50.000 campioni

(pacchetti). I dettagli statistici sul traffico generato, divisi per distribuzione, sono

esposti nella tabella6.2.

Per quanto riguarda la distribuzione costante sono state considerate 4 tipologie

di traffico con payload fisso, i cui valori utilizzati sono elencati in tabella, andando

da valore nullo a 1024 bytes.

Nel caso di distribuzione esponenziale e uniforme sono indicati, invece, i pa-

103

6. Simulazioni sul modello e sliding window

Distribuzione Statistica(# di pacchetti 50000)CostanteEsponenzialeUniformeReale

Tabella 6.1:Pattern di traffico usati nelle simulazioni. Distribuzione del payloaddei pacchetti.

rametri statistici di maggiore rilievo (media, deviazione standard, ...). Entrambe

sono state ottenute facendo uso del generatore di traffico D-ITG (Distributed Inter-

net Traffic Generator) [38]: un software capace riprodurre il traffico tra due punti

di una rete, secondo precisi processi stocastici, applicabili sia all’Inter Departure

Time(IDT) che alla dimensione dei pacchetti. In particolare, si è scelta una distri-

buzione esponenziale con media 500 bytes (il cui istogramma è mostrato in Figura

6.1) in accordo con le dimensioni medie del traffico internet (si veda la sezione

??). Analogamente, per la distribuzione uniforme si è ricoperto un range di valori

ampio che va da zero a 1960 bytes. In Figura6.2è visualizzato l’istogramma del-

la distribuzione uniforme. Si noti il picco in prossimità de 40 bytes in entrambe

le distribuzioni, esponenziale ed uniforme; esso rappresenta il traffico, non costi-

tuito da dati (payload), ma solo da pacchetti header TCP (tipo SYN/ACK/FIN).

Infine la distribuzione reale è ottenuta dagli archivi delInternet Traffic Archive

(ITA [ 39]) da cui è possibile scaricare deitracedi traffico internet raccolti trami-

te il tool tcpdump[40]. Nel nostro caso si è prelevato un trace ottenuto tra due

gateway in una rete a 2 Mbit/s contenente circa 3 milioni di pacchetti, di cui solo

50.000 di tali campioni sono stati considerati nelle simulazioni. Da tale trace sono

state prelevate le informazioni circa il payload dei pacchetti. L’istogramma del

trace usato è in Figura6.3; si osservino i due picchi in circa 40 bytes (traffico TCP

di tipo SYN/ACK/FIN) e in circa 512_bytes (traffico medio su internet).

104


0

500

1000

1500

2000

2500

3000

3500

4000

0 1000 2000 3000 4000 5000 6000

Num

ber

of s

ampl

es

Payload packets size [bytes]

Exponential Distribution with mean 500 bytes

Figura 6.1:Istogramma della distribuzione esponenziale.

400

500

600

700

800

900

1000

0 200 400 600 800 1000 1200 1400 1600 1800 2000

Num

ber

of s

ampl

es


Uniform Distribution between 0 and 1960 bytes

Figura 6.2:Istogramma della distribuzione uniforme.

105


COSTANTE

0 [bytes]64 [bytes]512 [bytes]1024 [bytes]

ESPONENZIALE

media: 500 [bytes]mediano: 345 [bytes]dev std: 502 [bytes]

min: 0 [bytes]max: 5123 [bytes]

UNIFORME

range [bytes]: [0,1960]media: 976 [bytes]dev std: 565 [bytes]

REALE

media: 256 [bytes]mediano: 162 [bytes]std dev: 259 [bytes]

min: 0 [bytes]max: 1460 [bytes]

Tabella 6.2:Dettagli sulle singole distribuzioni dei pattern di traffico.

Un altro parametro utile ai nostri scopi, inerente i pattern di traffico, è la carat-

terizzazione dei pacchetti in base alla security association (SA). Si sono generati

appositamente due tipologie di trace che modellizzano due differenti distribuzio-

ni di SA, ed identificate rispettivamente con i termini “equal” e “incremental”.

Entrambe le distribuzioni sono costituite da 4 diverse SA, ognuna con una speci-

EQUAL I NCREMENTAL

SA1 25% 40%SA2 25% 30%SA3 25% 20%SA4 25% 10%

Tabella 6.3:Caratterizzazione del traffico in base alla SA.

fica percentuale riferita al flusso totale di 50.000 pacchetti. In “Equal”, il flusso si

ripartisce equamente nelle 4 SA; mentre in “incremental” le probabilità assumono

via via valori crescenti a partire dal 10%, come mostrato in tabella6.3.

106


0

5000

10000

15000

20000

25000

30000

35000

40000

0 200 400 600 800 1000 1200 1400 1600

Num

ber

of s

ampl

es


Real Traffic Distribution

Figura 6.3:Istogramma del traffico reale.

A questo punto sono stati descritti i trace che andranno a stimolare il nostro

sistema. Ogni pacchetto viene inviato al sistema come se provenisse da una rete

ad 1 Gbit/s a velocità massima e senza pause tra un pacchetto ed un altro. Tale

situazione, ovviamente, è ideale e rappresenta il caso peggiore di funzionamen-

to del sistema ma ciò non influenza negativamente gli obiettivi prefissi, ovvero,

validare l’algoritmo di scheduling. Nella tabella6.4 sono riassunti i parametri

che caratterizzano i pattern di traffico ed il loro range di valori. Essi generano

(2 ∗ 7) = 14 combinazioni possibili, ovvero 14 pattern di traffico che andranno a

testare il nostro sistema.

6.1.2 Velocità di elaborazione relativa per i processori

Come descritto nella sezione5.3.1, i processori, CPU ed acceleratore, sono stati

modellizzati come processi che introducono un ritardo temporale sul datapath.

Resta da determinare quali siano i valori dei tempi nelle equazioni5.1e 5.2, con

107


Parametro Range di Valori

Network 1 Gbit/s (Ideale)Distribuzione SA 4 SA con [%]:

{10, 20, 30, 40};{25, 25, 25, 25}

Distribuzione Payload {fixTo0, fixTo64, fixTo512, fixTo1024,exponential, uniform, real}

Tabella 6.4:Range dei parametri per i pattern di traffico usati nelle simulazioni.

particolare rilievo ai rapporti relativi di velocità espressi dalle costantiIratio ed

Eratio.

Iratio edEratio diversificano il comportamento della CPU per quanto riguarda

la sua capacità di elaborare i pacchetti. Valori alti diIratio ed Eratio accresco-

no i tempi di elaborazione rispettivamente per l’inizializzazione e la cifratura dei

blocchi.Iratio edEratio, in un certo senso, simulano in maniera statica il compor-

tamento non deterministico della CPU in fase di elaborazione dei dati, come se si

facesse una istantanea del sistema .

Parametro Range di valori

Iratio {1,3}Eratio {1,3,5,7}

Tabella 6.5:Range dei valori perIratio edEratio.

I valori presi in considerazione in questa tesi sono riassunti nella tabella6.5.

Un valore pari a ’3’ perIratio significa che la CPU ha un tempo d’inizializzazio-

ne 3 volte più alto rispetto a quello dell’acceleratore hardware; analogamente, se

Eratio = 5 la CPU è più lenta dell’acceleratore di ’5’ volte nel processo di ci-

fratura dei dati. I valori perIratio edEratio pari ad ’1’ rendono identiche le due

equazioni dei processori5.1 e 5.2, pertanto la CPU e l’acceleratore processano i

dati con gli stessi tempi.Iratio ed Eratio, pertanto, identificano(2 ∗ 4) = 8 dif-

ferenti rapporti di velocità tra CPU ed acceleratore; 8 stati di funzionamento del

108


Pattern Throughtput ACC

fixTo0 1.49e+05 Kbit/sfixTo64 1.81e+05 Kbit/s

real 2.08e+05 Kbit/sfixTo512 2.13e+05 Kbit/s

exponential 2.14e+05 Kbit/sfixTo1024 2.18e+05 Kbit/suniform 2.19e+05 Kbit/s

Tabella 6.6: Throughput dell’acceleratore senza algoritmo di scheduling infunzione dei pattern di input.

sistema, che risponderanno in altrettanti modi diversi ai pattern di traffico descritti

in precedenza.

6.2 Test preliminari e scheduling efficiente

Per prima cosa si osserva il sistema in assenza di scheduling dei pacchetti tra

CPU ed acceleratore. Tutti i pacchetti sono inviati unicamente ad uno dei due

processori. Ovviamente l’equazione5.1 dell’acceleratore non dipende dai valori

di Eratio, pertanto sono stati tabulati i valori del throughput in funzione solo dei

pattern di traffico in ingresso al sistema (si veda la tabella6.6). Al contrario, per la

CPU si vedano i grafici in Figura6.4, rispettivamente con unIratio = 1 e Iratio =

3. Sia la tabella che la figura sono stati ottenuti considerando la distribuzione di

SA “equal” (in questo contesto le informazioni sulle SA dei pacchetti non sono

rilevanti).

Dalla tabella si evince immediatamente l’effetto dellaIP taxsulle performance

dell’acceleratore: si prenda per confronto, p.e., il throughput da “fixTo512” a

“fixTo0”, il peggioramento è dell’ordine del 30%. L’acceleratore dimostra che

con pacchetti di dimensioni piccole, payload ’0’ e ’64’, il peso rilevante sulle

performance è dato dal tempo di inizializzazione del dispositivo.

109


a)

0

50000

100000

150000

200000

250000

300000

1 2 3 4 5 6 7

Sys

tem

Thr

ough

put [

kbit/

s]

Encoder Time Ratio

W=1, Ir=1, SA=4equal

fix0fix64

fix512fix1024

expuniform

real

b)

0

50000

100000

150000

200000

250000

300000

1 2 3 4 5 6 7

Sys

tem

Thr

ough

put [

kbit/

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.4:Throughtput della CPU senza algoritmo di scheduling in funzione diEratio, per diversi pattern di traffico. In (a)Iratio = 1, in (b) Iratio = 3.

110


Se consideriamo unEratio = 1 e Iratio = 1, Figura6.4e grafico (a), abbiamo,

quindi, una CPU in grado di elaborare i dati alla stessa velocità dell’accelerato-

re. Facendo una rapida comparazione con i dati sull’acceleratore in tabella6.6, si

verifica facilmente che, con questi parametri, la CPU ha un throughput maggiore

rispetto all’acceleratore, per qualsiasi pattern in ingresso. Il throughput della CPU,

infatti, si localizza nell’intorno tra 180 Mbit/s e 270 Mbit/s, mentre per l’accele-

ratore il range è tra circa 150 Mbit/s e 220 Mbit/s, valori inferiori ai precedenti.

La ragione è da riscontrare nel fatto che l’acceleratore richiede la lettura e scrittu-

ra dalla memoria attraverso il bus PCI e questo introduce un ulteriore ritardo nel

datapath complessivo.

Introduciamo, adesso, una differenza sui tempi di inizializzazione tra CPU ed

acceleratore, assegnando, p.e.,Iratio = 3, ed osserviamo i punti diEratio = 1.

L’incremento diIratio non è funzione delle dimensioni dei pacchetti, è un ritardo

additivo alla cifratura (si veda l’equazione5.2). Questo cambiamento, sebbene

non influenzato dalle dimensioni dei pacchetti, penalizza le performance della

CPU (si veda la Figura6.4, grafico (b)). La CPU continua ad essere globalmen-

te meglio del sistema col solo acceleratore tranne che in presenza dei pacchetti

piccoli (linea “fixTo0”), probabilmente perchè in questo caso il ritardo sul bus è

minore del tempo di inizializzazione della CPU.

In generale, invece, osservando come varia il throghput della CPU in funzione

di Eratio, in entrambi i grafici di Figura6.4, possiamo renderci conto come già con

una CPU tre volte più lenta nel crifrare i dati le performance degradano pesante-

mente inferiori ai 100 Mbit/s. Inoltre, anche la CPU risente dell’effetto del tempo

di inizializzazione sul throughput. Con pacchetti di dimensioni ridotte, il tempo

di inizializzazione, infatti, diventa comparabile al tempo di cifratura, rendendo,

così, il processo di crittaggio inefficiente.

Per il confronto sulla latenza media del sistema, con una CPU a stessa capa-

cità di elaborazione dell’acceleratore (Iratio = 1 e Eratio = 1) non ci sono grandi

differenze nei risultati ottenuti. Così come non si osservano cambiamenti signifi-

cativi quando si passa ad unIratio = 3. Ovviamente, ancora una volta, con CPU

111


0

2

4

6

8

10

12

1 2 3 4 5 6 7

Sys

tem

Avg

Pac

ket L

aten

cy [m

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.5:Latenza media del sistema con la sola CPU operativa.

via via sempre più lenta dell’acceleratore la latenza del sistema cresce con appros-

simazione lineare la cui pendenza è funzione delle dimensioni dei pacchetti, come

mostrato in Figura6.5.

Introducendo nel nostro sistema l’algoritmo di scheduling esposto in sezio-

ne5.4possiamo far funzionare contemporaneamente CPU ed acceleratore accre-

scendo il parallelismo del nostro sistema. Questo cambiamento dovrebbe portare

a migliorare ovviamente il throughput complessivo. Inoltre vogliamo verificare

come si comporta il sistema in funzione delle dimensioni dei pacchetti.

In Figura6.6 sono messi a confronto i throughput dei sistemi , con la sola

CPU e con CPU ed acceleratore insieme. Come si poteva prevedere l’uso paral-

lelo dei processori per cifrare i dati trasla verso l’alto le performance del sistema.

Se prendiamo il caso peggiore del grafico (b), ovvero, CPU sette volte più lenta

112


a)

0

50000

100000

150000

200000

250000

300000

1 2 3 4 5 6 7

Sys

tem

Thr

ough

put [

kbit/

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

b)

150000

200000

250000

300000

350000

400000

450000

500000

1 2 3 4 5 6 7

Sys

tem

Thr

ough

put [

kbit/

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.6: Confronto tra throughput del sistema: (a) solo CPU vs (b) CPU +acceleratore.

113


dell’acceleratore (Eratio = 7) e pattern “fixTo0”, si ha un throughput di circa 180

Mbit/s. Compariamo tale valore con le migliori performance sullo stesso pattern

“fixTo0” nel grafico (a), ovvero con una CPU alla stessa velocità dell’acceleratore

(Eratio = 1), in cui, stavolta, il throughput vale circa 130 Mbit/s. Il miglioramento

ottenuto è intorno al 38%. Si tenga presente che i grafici sono stati ottenuti con un

tempo di inizializzazione delle CPU tre volte maggiore di quello dell’acceleratore

(Iratio = 3), quindi il guadagno in performance è ottenuto con la configurazio-

ne peggiore ottenibile per la CPU, considerando ildesign space explorationdei

parametri delle simulazioni esposto in precedenza.

L’uso congiunto della CPU e dell’acceleratore crittografico, oltre ad incre-

mentare il throughput, ha effetti benefici soprattutto sulla latenza media dei pac-

chetti nel sistema, come mostrato in Figura6.7. Mentre in (a) la latenza cresce

linearmente con le dimensioni dei pacchetti, fino a raggiungere, nel caso peggiore

(pattern “fixTo1024) con CPU molto lenta (Eratio = 7), tempi di latenza di circa

10 ms; in (b), invece, lo scheduling dei pacchetti sfrutta efficientemente il paral-

lelismo tra CPU ed acceleratore, ottenendo come risultato l’appiattimento delle

curve di latenza media, con tempi nell’intorno di 2 ms per parametri agli estremi

(pattern “fixTo1024” eEratio = 7). Al di là di questo confronto prestazionale, ri-

salta soprattutto il fatto che, in generale, la latenza media in (b) non è influenzata

dalla variazione diEratio (come invece accadeva in (a) ). Ciò vuol dire che una

variazione della velocità della CPU, oltre un rapporto dei tempi di cifratura pari

a ’3’, non produce cambiamenti significativi nella latenza media dei pacchetti nel

sistema.

Con questa configurazione, in cui CPU ed acceleratore interagiscono assieme

per ottimizzare il processo di crittaggio dei dati, si deve soppesare quanto lavoro

svolge ogni processore. In Figura6.8 è riportata la percentuale di pacchetti, su

un totale di 50.000, elaborati dalla CPU, per ogni pattern di traffico in ingresso.

Il comportamento del sistema si differenzia in base alla tipologia di scenario di

traffico. La considerazione che si può trarre è che per pattern costanti, fixToxxx,

l’uso della CPU decade abbastanza velocemente, seguendo lo stesso andamen-

114


a)

0

2

4

6

8

10

12

1 2 3 4 5 6 7

Sys

tem

Avg

Pac

ket L

aten

cy [m

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

b)

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7

Sys

tem

Avg

Pac

ket L

aten

cy [m

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.7:Confronto sulla latenza media del sistema: (a) solo CPU vs (b) CPU+ acceleratore.

115


15

20

25

30

35

40

45

50

55

60

1 2 3 4 5 6 7

CP

U u

sage

[%]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.8:Percentuale di pacchetti processati dalla CPU.

to indipendentemente dalle dimensioni dei pacchetti costituenti il pattern stesso.

Sembrerebbe, quindi, che in uno scenario in cui il traffico è costituito da un di-

mensione fissa per i pacchetti, questi vengono indirizzati dallo scheduler preferi-

bilmente verso l’acceleratore alleviando il carico sulla CPU. Con pattern costituiti

da una distribuzione statistica del payload (“exp”, “uniform”) o tratti da trace di

traffico reale (“real”), invece, l’uso della CPU si assesta tra il 35% ed il 50%. Esa-

minando le curve di “exp”, “uniform” e “real” in Figura6.8, si riscontra che l’uso

della CPU decresce all’aumentare della lunghezza media del payload; infatti, nel-

l’ordine di maggiore uso della CPU abbiamo “real”, “exp” ed “uniform” le cui

medie sono rispettivamente di 256 bytes, di 500 bytes e di 976 bytes (si riveda la

tabella6.2). Analoghe considerazioni, anche se con meno rilevanza, valgono per

i pattern a lunghezza di payload costante.

Si potrebbe affermare, prematuramente, che lo scheduler preferisca lasciare

116


a)

0

200

400

600

800

1000

1200

1400

1 2 3 4 5 6 7

AC

C A

vg P

acke

ts L

engt

h [b

ytes

]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

b)

0

200

400

600

800

1000

1200

1 2 3 4 5 6 7

Avg

CP

U P

acke

ts L

engt

h [b

ytes

]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.9:Dimensione media dei pacchetti processati: (a) dall’acceleratore, (b)dalla CPU.

117


alla CPU l’elaborazione dei pacchetti “piccoli”, mentre sono lasciati all’accelera-

tore i pacchetti “grandi”. In supporto a questa affermazione si osservino le Figure

6.9e6.10. Nella prima sono riportate le lunghezze medie dei pacchetti processati

dall’acceleratore e dalla CPU, per ogni pattern di traffico. Si ponga l’attenzione

sull’andamento delle curve. Per l’acceleratore (grafico (a)) al crescere diEratio,

quindi con CPU più lente, la dimensione media dei pacchetti processati, in gene-

rale, cresce lievemente. La ragione è da riscontare nel fatto che lo scheduler invia

alla CPU pacchetti mediamente più piccoli, come si può notare dal grafico (b):

dove più lenta sarà la CPU più piccoli saranno i pacchetti che le verranno dati. I

pacchetti “tolti” alla CPU, all’aumentare della sua lentezza, sono comunque me-

diamente più piccoli di quelli “normalmente” processati dall’acceleratore, ecco

pertanto spiegato l’andamento appiattito del grafico (a). Ovviamente i pattern a

payload costante non sono da considerare in questa analisi sulle lunghezze medie.

Per maggiore dettagli sui pacchetti elaborati da ogni processore si veda la Fi-

gura 6.10, in cui è riportato l’istogramma dei pacchetti nel caso particolare di

pattern “real”. Tenendo presente l’istogramma completo del pattern “real” in Fi-

gura6.3si noti come in Figura6.10la suddivisione dei pacchetti sia visibilmente

marcata tra i due processori. All’acceleratore sono lasciati i pacchetti di dimen-

sioni maggiori, circa 512 bytes (grafico (a)), mentre alla CPU spetta il compito

di processare i pacchetti a lunghezza minore, intorno ai 40 bytes (grafico (b)).Il

comportamento è analogo con gli altri pattern di traffico.

Da un osservazione approssimativa dei grafici (a) e (b) si potrebbe supporre

che lo scheduler operi in base ad una soglia di dimensioni prestabilita: sotto la

soglia il pacchetto è inviato alla CPU, sopra la soglia all’acceleratore. Si ricor-

da, però, che lo scheduling dei pacchetti non avviene esclusivamente in base alle

dimensioni del pacchetto correntemente in esame; lo scheduler, infatti, esegue le

sue scelte calcolando iltempo di fine(si veda l’equazione5.4) e stabilendo, in

realtime, quale dei due processori garantisce il tempo di processamento minore.

La presenza dei picchi “minori” in (a) ed in (b) dimostra che i processori operano

su tutto lo spettro di dimensioni dei pacchetti.

118


a)

0

5000

10000

15000

20000

0 200 400 600 800 1000 1200 1400 1600 1800

Num

ber

of s

ampl

es

Packet size [bytes]

ACC packet histogram - pattern=’real’, Ir=3, Er=7

b)

0

5000

10000

15000

20000

0 200 400 600 800 1000 1200 1400 1600 1800

Num

ber

of s

ampl

es

Packet size [bytes]

CPU packet histogram - pattern=’real’, Ir=3, Er=7

Figura 6.10:Istogrammi dei pacchetti processati (a) dall’acceleratore e (b) dallaCPU.

119


6.3 Ulteriore ottimizzazione del sistema

Nella sezione precedente abbiamo analizzato il comportamento del sistema, con e

senza lo scheduler. E’ emerso che, sebbene lo scheduler migliori il funzionamen-

to del sistema, ottendo performance degne di nota, complessivamente il modello

risente ancora dellaIPsec taxdovuta al processamento dei pacchetti di dimensio-

ni ridotte. L’uso della CPU, infatti, è legato in qualche modo alle dimensioni del

payload del traffico in ingresso (si riveda la Figura6.8). Quando si è progettato

l’algoritmo di scheduling tra i nostri obiettivi c’era quello di ottenere come risul-

tato quello di compensare l’IPsec taxdell’acceleratore, evitando di inviargli pac-

chetti piccoli e sperare che questi potessero essere meglio processati in software

direttamente dalla CPU. Le misurazioni effettuate confermano tale assunzione (si

riveda la Figura6.10). Ma l’IPsec taxpenalizza anche la CPU; con riferimento

nuovamente alla Figura6.8, si è fatto notare come l’uso della CPU si manten-

ga ancora percentualmente alto per un traffico in ingresso a lunghezza media del

payload sui 200 bytes. Pertanto, se da un lato si è reso efficiente l’acceleratore,

dall’altro, invece, abbiamo ancora un livello di utilizzo della CPU potenzialmente

elevato. La CPU viene, invece, coinvolta di meno con pattern di traffico a payload

costante o a dimensione media piuttosto elevata.

Partendo dai risultati raccolti e dalle osservazioni sopra esposte, si è perfe-

zionato il nostro modello al fine di ottimizzare l’uso congiunto di CPU ed acce-

leratore. L’idea nasce da un concetto semplice che fa riferimento alle security

association (SA) di IPsec. Ci si è principalmente chiesti: perchè non inviare al

processore crittografico (CPU o acceleratore) tutti i pacchetti appartenenti alla

stessa SA in un unico multi-pacchetto (merged)? Dove permergeds’intende un

unico pacchetto costituito dall’accodamento di una serie di pacchetti con la stessa

SA.

I pacchetti vengono cifrati in base alle informazioni sulla chiave crittografi-

ca presenti nella SA, pertanto imergedhanno tutti la stessa chiave crittografica.

Di conseguenza l’acceleratore potrebbe risparmiare sul tempo di inizializzazione

processando con un’unica chiave ilmergedricevuto e questo, sicuramente avreb-

120


be effetti positivi sullaIPsec tax. Inoltre, processare un multi-pacchetto in un

unico step all’interno del processore porterebbe a risparmiare anche sul numero

di istruzioni di controllo tra CPU ed acceleratore. Si pensi, p.e., che esistano due

istruzioni di controllo e gestione del dispositivo identificate dai comandi RESET

ed ENCRYPT. Tali istruzioni sono inviate dallo scheduler (CPU) al dispositivo

ogni volta che si vuole processare un pacchetto. Se, per esempio, nel flusso in

ingresso troviamo 5 pacchetti con la stessa SA, lo scheduler dovrebbe inviare al-

trettanti comandi RESET ed ENCRYPT all’acceleratore per un totale quindi di 10

comandi. Al contrario, inviando direttamente un unico pacchettomergedil nu-

mero di comandi si ridurrebbe a 2, con un evidente risparmio, avendo, tra le altre

cose, trascurato eventuali segnali/istruzioni in senso opposto, cioè dall’accelerato-

re alla CPU, per i quali varrebbero le stesse considerazioni. Un’altra conseguenza

dell’uso dei pacchettimergedha a che fare con la diminuizione di richieste di ac-

cesso al bus PCI, la cui spiegazione è del tutto analoga a quanto raccontato con

un esempio a proposito delle istruzioni di controllo. Ulteriore vantaggio dato dai

mergedscaturirebbe dal fatto che, mantenendo la stessa SA per un certo numero

di pacchetti, si risparmia sul numero di operazioni diSA lookup.

Come tutte le soluzioni anche l’uso dei pacchettimergedha i suoi possibili

svantaggi. Tra i più evidenti c’è l’occupazione del bus per un tempo lungo dovu-

to, appunto, alla trasmissione di pacchetti costituiti da un elevato numero di bytes.

Analogamente, lo stesso processore (CPU o acceleratore) è impiegato intensiva-

mente per un ampio arco di tempo e questo potrebbe essere controproducente

specie nel caso in cui ad elaborare il pacchettomergedè la CPU. Infine, per crea-

re un pacchettomergedè necessario disporre di un certo numero di pacchetti i

quali devono essere prima ricevuti e poi fusi insieme. L’attesa dei pacchetti, p.e.

dalla rete, potrebbe accrescere la latenza media dei dati nel sistema, con ritardi

indesiderati sul path tra ingresso ed uscita.

121


6.3.1 La sliding window

Finora non si è ancora parlato di come si creino i pacchettimergede come sono

gestiti dallo scheduler, ovvero: qual è l’architettura usata per tenere traccia dei

pacchetti ricevuti? Quali sono le regole usate per unire più pacchetti assieme

in un unico multi-pacchetto? In base a quale principio lo scheduler assegna un

mergedalla CPU piuttosto che all’acceleratore?

Ci sono diverse possibilità per memorizzare i pacchetti ricevuti ed analizzare

la loro SA; in questa tesi si è pensato di usare un’accorgimento che agisca diretta-

mente sulla coda FIFO (main queue), dalla quale lo scheduler attinge i pacchetti.

L’idea per ottenere imergedè quella di usare una finestra di osservazione scor-

revole (sliding window) da disporre sui dati della FIFO allo scopo di esaminare

l’appartenenza dei pacchetti ad una data SA (si veda la Figura6.11). A livello

implementativo la sliding window è una modifica del comportamento della main

queue. Fondamentalmente la sliding window aggiunge due nuovi parametri alla

main queue: sono la dimensione della finestra (indicata conW) ed un tempo di

timeout (T). In questa sede, il timeout non è considerato in quanto si è supposto

che la rete invii i pacchetti alla velocità massima nominale, pertanto tra un arrivo

ed il successivo non ci sono attese.

Le regole per la lettura e scrittura dalla sliding window sono le seguenti:

• Si può scrivere sulla main queue se il numero di pacchetti è inferiore alle

dimensioni della finestra,W.

• Se la finestra è piena, si deve attendere che ci sia almeno una lettura di un

pacchetto per potere nuovamente scrivere sulla coda.

• Se la finestra è vuota la lettura è posticipata dopo una scrittura sulla coda.

• L’operazione di lettura è susseguente ad uno di questi eventi:

– riempimento della finestraW .

122


Scheduler

��

��

��

��

��

��

��

��

SA_2SA_1

Window

Sliding

Figura 6.11:La sliding window.

– scatto del timeoutT (se dopo il timeout la coda è vuota si deve atten-

dere un’operazione di scrittura).

– fine del flusso di pacchetti in ingresso.

• E’ possibile leggere il primo pacchetto o, contemporaneamente, tutti i pac-

chetti con la stessa SA inclusi nella sliding window.

• Ogni operazione di scrittura e lettura blocca la coda fino a quando non ha

terminato il suo processo.

Lo scopo della sliding window è quello di individuare e gestire i pacchetti con

la stessa SA. Un modo efficiente e semplice da implementare per adempiere a

questo compito , è quello di considerare l’analisi della SA in funzione del primo

pacchetto ricevuto, seguendo, quindi, la logica FIFO della main queue.

Consideriamo la Figura6.11e vediamo quello che succede in realtime nella

sliding window. Una volta ricevuto il primo pacchetto (pacchetto più a destra)

si esamina la sua SA. Tutti i pacchetti successivi al primo, in arrivo nella coda,

saranno confrontati, uno ad uno, con questa SA per determinare se fanno parte

123


della stessa connessione (ci si riferirà ai pacchetti con la stessa SA del primo con

il terminesimili). La sliding window memorizza quindi le informazioni rilevanti

sui pacchettisimili, ovvero, posizione nella coda e lunghezza in bytes. Fintanto

che la finestra non è piena, oppure non si verifica uno degli eventi descritti in pre-

cedenza a proposito delle regole delle main queue, nessuna operazione di lettura

può essere eseguita da parte dello scheduler. Al completamento della finestra, lo

scheduler è libero di leggere il primo o tutti i pacchettisimili, in base all’algorit-

mo presentato nella prossima sezione6.3.2. In seguito ad un’operazione di lettura

i pacchetti rimasti nella coda vengono slittati e risistemati mantenendo, però, il

loro ordine di arrivo. Per esempio, se lo scheduler legge solo il primo pacchetto, i

pacchetti rimanenti slittano in avanti come una normale FIFO; nel caso in cui ven-

gano letti contemporaneamente tutti i pacchettisimili (con la stessa SA), quindi

vengono tolti pacchetti in posizioni generiche all’interno della finestra, i pacchetti

rimanenti (sono quellinon-simili) sono slittati e ricompattati verso destra man-

tenendo la stessa configurazione temporale. Tutte le informazioni sulle SA sono

azzerate una volta letti dei dati dalla coda; il nuovo pacchetto di destra costituirà il

nuovo termine di paragone per determinare i nuovi suoisimili. Al termine dell’o-

perazione di slittamento dei dati nella finestra ed aggiornamento della nuova SA,

la coda è pronta per un’altra operazione di lettura/scrittura.

Il funzionamento descritto per la sliding window è particolarmente efficiente

poichè non deve tenere in memoria i dati di tutte le possibili SA nella finestra;

cosa che, con finestre ampie e centinaia di SA, diventerebbe qualcosa di oneroso

e particolarmente complicato da gestire. Basta, invece, tenere in considerazione

la SA del primo pacchetto (da destra), quello che in una normale FIFO sarebbe

letto dallo scheduler, e confrontare tale valore, in realtime, con le SA dei nuovi

pacchetti in arrivo. Un altro vantaggio di una tale implementazione consiste nel

basso tasso di rimescolamento dei dati, i quali mantengono, così, la loro sequenza

temporale. Il prezzo da pagare è, ovviamente, quello di attendere che la finestra

sia piena (non nel caso in cui si usi un timeout) e quindi mantenere in coda per un

dato lasso di tempo i pacchetti già ricevuti, con possibile aumento della latenza

124


dei dati nel sistema. Il tempo di latenza per la sliding window è legato principal-

mente alla velocità della rete e alla dimensione della finestra (e del timeout). Nel

nostro caso il traffico sulla rete viaggia alla velocità massima (per costruzione) e,

quindi, si garantisce che non ci siano attese tra un pacchetto ed il successivo; inve-

ce si è cercato di mantenere ridotte le dimensione della finestra in quanto ciò che

interessa è studiare il comportamento di massima del nostro modello in presenza

dei pacchettimerged. In tabella6.7è mostrato il range di valori usati nelle nostre

simulazioni per la sliding window.

Parametro Range di valori

Dimensione Finestra (W) {1,2,3,4,5}Timeout +∞

Tabella 6.7:Range di valori per i parametri della sliding window.

6.3.2 Il nuovo scheduling con la sliding window

Naturalmente l’introduzione della sliding window comporta inevitabilmente delle

modifiche al nostro modello. In realtà le modifiche interessano il solo scheduler, a

cui bisogna fornire le informazioni su come manipolare anche i pacchettimerged.

Lo scheduler deve, in questo caso, compiere una doppia scelta: selezionare prima

il migliore processore col minore tempo di fine, questo sia per i pacchettimerged

che per i pacchettisingle; successivamente scegliere il più conveniente tra i due

tipi di pacchetti ed inviarlo, appunto, al processore. Per rendere il confronto valido

non si può comparare il tempo di fine di un pacchettomergedcon il tempo di fine

nel caso si invii, p.e., il primo pacchetto della coda. ciò che lo scheduler confronta

con il tempo di fine di unmergedè il tempo di fine deisingle, ovvero, considera

tutti i pacchetti costituenti ilmerged(i pacchettisimili) e calcola il tempo di fine

come se fossero inviati, singolarmente, uno dopo l’altro .

L’aspetto interessante è dato dal fatto che lo scheduler, visto l’efficienza di-

mostrata nelle precedenti simulazioni, usa lo stesso algoritmo di scheduling per

125


Window

Best ?

Sliding

SingleTempo di fine

Merged

coda

proc

Tempo di fine

tempi di fineCalcolo dei

Invia al Proc

Figura 6.12:Schema di principio di funzionamento dello scheduler con slidingwindow.

il calcolo dei tempi di fine descritto in sezione5.4; Tale algoritmo è, quindi, riu-

tilizzato sia per i pacchettimergedche per isingle. Lo scheduler esegue una

comparazione tra il tempo di fine calcolato su un pacchetto unicomerged, somma

di tutti i bytes deisimili, ed il tempo di fine complessivo deisingle, calcolato come

somma dei tempi di fine parziali di ogni pacchetto nella lista deisimili.

In Figura6.12è mostrato il principio di funzionamento del nuovo scheduler.

Lo scheduler è costituito da tre attività principali:

1. Calcolo dei tempi di fine del pacchettoj, per:

(a) j =pacchettosingle

(b) j =pacchettomerged

2. Selezione del pacchettoj migliore, cioè a minore tempo di fine.

3. Invio al processore del pacchetto selezionato al punto 2.

126


Il nuovo scheduler deve però conoscere la composizione deisimili nella finestra

d’osservazione; tale informazione è direttamente prelevata dalla sliding window

(diagramma “sliding window” in Figura6.12). Analogamente l’algoritmo di sche-

duling, come precedentemente descritto, necessita di alcune informazioni sullo

stato corrente delle code dei processori (diagramma “coda” in figura), e sull’at-

tuale stato di elaborazione dei processori (diagramma “proc” in figura). I tempi

di fine per i pacchettimergede singleviene confrontato per determinare il mi-

nore (diagramma “best” in figura), il quale sarà inviato al dovuto processore per

l’elaborazione. A pari tempo di fine si predilige l’invio del pacchettomerged.

Nel caso dei pacchettimergedil calcolo del tempo di fine per ogni processore

è “esatto”, nel senso che il pacchetto è interpretato come fosse un unico pacchetto

di dimensioni maggiori al quale applicare una sola volta l’algoritmo di schedu-

ling, prelevando le informazioni esatte sullo stato delle code e del processore. Per

i pacchettisinglesi applica inveceN volte l’algoritmo di scheduling conN pa-

ri al numero di pacchettisimili nella sliding window. In questo caso il tempo

complessivo di processamento è dato dalla somma dei tempi di fine parziali degli

N pacchetti. C’è una inesattezza nel calcolo di tale tempo di fine, infatti, per i

pacchettisimili nella sliding window, successivi al primo, le informazioni sullo

stato delle code e del processore non sono aggiornate in tempo reale, in quanto

si sta calcolando il tempo di fine complessivo a priori all’interno scheduler senza

nessun effettivo invio di dati. Pertanto, il tempo di fine complessivo per isingle

è un’approssimazione per difetto sui pacchetti in esame; se si considerasse, per

assurdo, il cambiamento dello stato delle code e dei processori, il tempo di fine

complessivo deisinglesarebbe sicuramente maggiore rispetto a quello calcolato

con le modalità sopra descritte. La comparazione tra i tempi di fine deimergede

dei singlepertanto resta valida e lo scheduler può eseguire con efficienza la sua

scelta.

Un ulteriore precisazione va aggiunta sempre a proposito delle differenze tra

scheduling deimergede deisingle. Quando si applica l’algoritmo di scheduling

per imerged, abbiamo detto che lo si esegue una sola volta, pertanto si calcolano i

127


tempi di fine per ogni processore e si sceglie il minore, quindi, intrinsecamente si

sceglie anche il processore al quale inviare il pacchetto. Al contrario l’algoritmo

di scheduling deisingleviene applicato N volte, e gli N tempi di fine parziali per

ogni processore vengono poi sommati tra loro per costituire il tempo di fine com-

plessivo, mentre la scelta del processore avviene solo in fase di scheduling del pri-

mo pacchetto, poichè, se dovesse prevalere la scelta deisingle, allora s’invierebbe,

appunto, il primo pacchetto in coda.

6.4 Test post ottimizzazione

In questa sezione vengono riportate le simulazioni effettuate per testare l’effetto

della sliding window, e quindi anche del nuovo scheduler, sul sistema. Rispetto

alle simulazioni precedenti, entrano a fare parte del design space esploration anche

la dimensione della finestra (il cui range di variabilità è in tabella6.7) ed assumono

un ruolo rilevante la distribuzione delle SA nel flusso di dati (si veda la tabella6.3).

Esaminiamo, pertanto, i risultati ottenuti mettendoli a confronto coi precedenti.

Dimensione finestra 4-Equal [pacchetto] 4-Incremental [pacchetto]

1 1 12 1.25 1.33 1.55 1.634 1.87 1.985 2.22 2.33

Tabella 6.8: Numero medio di pacchetti con la stessa SA in funzione del-le dimensioni della finestra, per le due distribuzioni di traffico4-equal e4-incremental.

In tabella6.8 è mostrata la media di pacchetti con la stessa security asso-

ciation (SA) all’interno della sliding window, in funzione delle dimensioni della

finestra di osservazione, suddivisi secondo le due tipologie di traffico “4-equal” e

“4-incremental”.

128


a)

0

10

20

30

40

50

60

70

80

90

1 2 3 4 5 6 7

Mer

ged

Pac

kets

[%]

Encoder Time Ratio

Ir=3

W=1W=2W=3W=4W=5

b)

0

10

20

30

40

50

60

70

80

90

1 2 3 4 5 6 7

Mer

ged

Pac

kets

[%]

Encoder Time Ratio

Ir=3

W=1W=2W=3W=4W=5

Figura 6.13:Percentuale sul totale dei pacchetti merged, per diverse dimensionedella finestra, con distribuzione di SA (a) 4-equal, (b) 4-incremental.

Quello che succede al sistema quando lo scheduler può usare i pacchettimer-

gedè mostrato invece in Figura6.13, in cui sono riporate le percentuali di pacchet-

ti mergedsul totale. Il risultato che si osserva è che lo scheduler invia pacchetti

mergedindipendentemente dalla velocità di processamento della CPU (cioè da

Iratioe Eratio) e dalla tipologia di pattern usato per il traffico. Tra il grafico (a) e

(b) cambia solo la distribuzione di SA; in (b) le percentuali sono maggiori perchè

la distribuzione 4-incremental ha in media un valore più alto di SA identiche nella

sliding window (si riveda la tabella6.8). Ovviamente al crescere delle dimensioni

della finestra cresce il numero di pacchetti che possono formare unmergede per-

tanto cresce anche la percentuale sul totale. La ragione di questo comportamento

è presto spiegata. La differenza nei tempi di fine tra imergeded i singleè nel va-

lore e nel peso che ha il tempo di inizializzazione. Neimergedil dispositivo viene

inizializzato una sola volta quindi anche iltinit viene conteggiato una volta. Nei

singleil tinit è sommato N volte, con N numero di pacchettisimili. Si intuisce che

il tinit deisingleassuma un peso rilevante sul totale tempo di fine incrementadone

considerevolmente il valore.

Nel seguito si analizzerà il comportamento della sliding window con dimen-

sione pari al massimo presente nel range utilizzato nelle simulazioni, ovvero una

W = 5, con riferimento alla distribuzione 4-equal di SA.

129


Assoldato che lo scheduler invia principalmente pacchettimerged, chi tra CPU

ed acceleratore cifrerà questi dati? In Figura6.14sono messe a confronto le per-

centuali d’uso della CPU per cifrare i dati, per ogni pattern di traffico, inerenti

sia il sistema senza la sliding window (grafico (a), conW = 1) che con sliding

window (grafico (b), conW = 5). La stessa comparazione è mostrata in Figura

6.15, questa volta focalizzata solo sul pattern ’real’.

E’ evidente da questi risultati che la presenza della sliding window abbassa

notevolmente la percentuale d’uso della CPU. Con riferimento alla Figura6.14, si

noti come i pacchettimerged(grafico (b)) alleggeriscano il carico di lavoro della

CPU dove, invece, il sistema senza la sliding window non agiva efficientemente,

ovvero sui pattern di traffico con distribuzione statistica dei payload. Si prenda in

considerazione, per un rapido calcolo, la Figura6.15, in cui il pattern di traffico è

il “real”, si ha un risparmio dell’uso della CPU tra il 20% ed il 35%.

La causa dell’andamento decrescente in funzione del rapporto di cifratura

Eratio è identica a quanto già detto per il sistema senza sliding window. In questa

nuova situazione l’esistenza dei pacchettimergedcontribuisce ad accrescere il di-

vario tra le dimensioni dei pacchetti processati dalla CPU e quelli , invece, trattati

dall’acceleratore. Lo scheduler continua a rifornire la CPU di pacchetti “piccoli”

ma la possibilità creata daimergedaumenta la dimensione media dei pacchetti;

i pacchettimergeddi grandi dimensioni sono inviati, però, maggiormente verso

l’acceleratore. Per esempio, nel caso di pattern “real”,Iratio = 3 e Eratio = 7,

W = 5, la CPU processa un totale 8185 pacchetti pari a circa il 29% dei pacchetti

totali, di cui il 58% sono pacchettimerged; ma sul totale dei pacchettimergedletti

dallo scheduler la CPU ne processa soltanto il 27%, il resto sono elaborati dell’ac-

celeratore. Considerando nel caso in esame che l’87% dei pacchetti in ingresso

allo scheduler vengono inviati ai processori come pacchettimerged, si osservi la

Figura6.16 in cui è riportato il valore medio e la deviazione standard dei pac-

chetti processati nell’acceleratore e nella CPU, confrontati col valore medio dei

pacchettimerged. E’ immediato rendersi conto, anche visivamente, di come ven-

gano suddivisi i pacchetti (in questo caso, in maggioranzamerged) tra la CPU e

130


a)

15

20

25

30

35

40

45

50

55

60

1 2 3 4 5 6 7

CP

U u

sage

[%]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

b)

15

20

25

30

35

40

45

50

55

60

1 2 3 4 5 6 7

CP

U u

sage

[%]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.14: Percentuale di pacchetti processati dalla CPU per ogni pattern ditraffico. (a)W = 1 e (b)W = 5.

131


25

30

35

40

45

50

55

60

1 2 3 4 5 6 7

CP

U u

sage

[%]

Encoder Time Ratio

Ir=3, SA=4equal, Pattern=Real

W=1W=5

Figura 6.15:Percentuale di pacchetti processati dalla CPU. Confronto tra sistemacon sliding window (W = 5) e senza (W = 1) nel caso di pattern ’real’.

l’acceleratore. Si ricorda, altresì, che la media del pattern "real" è di 256 bytes,

che paragonata ai 904 bytes mediamente processati dall’acceleratore rende l’idea

sulle nuove proporzioni dei pacchettimerged. Ancora una volta, più la CPU è

lenta, più piccoli sono i pacchetti processati. Considerazioni analoghe valgono

con gli altri pattern, altre dimensioni della finestra e altri rapporti diIratioeEratio.

Un aspetto interessante della nuova configurazione con sliding window è che

il sovraccarico dei processori non subisce modifiche rispetto al sistema senza fi-

nestra di osservazione. I dati raccolti parlano di un carico di lavoro, calcolato

come rapporto tra il tempo di processamento complessivo del processore sul tem-

po totale, che aumenta percentualmente da 99% a 99.8% per la CPU, mentre per

l’acceleratore la percentuale varia tra 76% e 78.2%.

L’effetto della sliding window sulle performance del sistema sono mostrate

nelle Figure6.17 e 6.18, in cui sono riportati i grafici comparativi col sistema

senza finestra, rispettivamente per il throughput e la latenza media dei pacchetti.

Per quanto riguarda il throughput, in Figura6.17, sebbene l’andamento del-

132


Figura 6.16: Confronto tra le lunghezze medie dei pacchetti elaborati daiprocessori e la dimensione media di un pacchetto merged.

le curve di (a) e di (b) sia pressappoco identico, si noti come la sliding window

abbia introdotto un miglioramento generalizzato. L’incremento maggiore si ha

per pattern a dimensione media dei pacchetti piccola, in particolare per il pattern

“fixTo0”. Il risultato raggiunto testimonia l’efficienza dei pacchettimergednei

confronti dellaIPsec tax, e non solo, si osservi, infatti, come in (b) si sia ridotta

la distanza relativa tra le curve, potendo, pertanto, affermare, con ragionevole ap-

prossimazione, che il throughput ottenuto sia indifferente dalla tipologia di pattern

di traffico.

Dal punto di vista della latenza, invece, si evince dalla Figura6.18che il siste-

ma in generale non subisce, globalmente, un ulteriore ritardo dovuto alla latenza

dei pacchetti nella sliding window. Tale risultato può essere giustificato dall’in-

cremento delle performance guadagnate in termini di throughput che compensano

i tempi di attesa di una finestra piena ad ogni lettura. Una latenza maggiore si ha

per i pattern “fixTo512” e “fixTo1024”, probabilmente perchè, in questo caso, i

pacchetti hanno una dimensione considerabile abbastanza grande, ed il fatto che

133


a)

150000

200000

250000

300000

350000

400000

450000

500000

1 2 3 4 5 6 7

Sys

tem

Thr

ough

put [

kbit/

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

b)

200000

250000

300000

350000

400000

450000

500000

550000

1 2 3 4 5 6 7

Sys

tem

Thr

ough

put [

kbit/

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.17:Confronto tra i throughput del sistema (a) senza sliding window e (b)con sliding windowW = 5.

134


a)

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7

Sys

tem

Avg

Pac

ket L

aten

cy [m

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

b)

0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7

Sys

tem

Avg

Pac

ket L

aten

cy [m

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.18:Confronto dei tempi medi di latenza per il sistema (a) senza slidingwindow e (b) con sliding windowW = 5.

135


Figura 6.19:Variazione percentuale relativa del throughput calcolata rispetto alsistema senza sliding window, per dimensioni della finestra pari a “1” e “5”,diversificata per pattern di traffico.

il flusso sia costituito da pacchetti di dimensioni identiche comporta una cattiva

“digeribilità” da parte del sistema. I commenti a proposito della latenza devono

però essere presi col beneficio del dubbio in quanto il sistema simulato ha una rete

che trasmette i pacchetti a velocità massima e senza pause, quindi la latenza nella

sliding window è ridotta al minimo possibile. In un sistema reale, probabilmente,

si avrebbe una latenza maggiore e, soprattutto, dipendente dal tempo di timeout

per la lettura; timeout, in questo caso indispensabile per evitare lo stallo del siste-

ma. Infine il valore della finestra pari a ’5’ non è particolarmente elevato per cui

non si hanno lunghi tempi di attesa tali da modificare sostanzialmente la latenza

del sistema.

Nelle Figure6.19, 6.20e 6.21sono riassunti gli effetti della sliding window

rispettivamente sul throughput, la latenza media e l’uso della CPU per processare i

pacchetti. I diagrammi fanno riferimento ad una CPU con parametri pari aIratio =

3 eEratio = 3.

136


Figura 6.20:Variazione percentuale relativa della latenza media calcolata rispettoal sistema senza sliding window, per dimensioni della finestra pari a “1” e “5”,diversificata per pattern di traffico.

Figura 6.21:Variazione percentuale relativa dell’uso della CPU calcolata rispettoal sistema senza sliding window, per dimensioni della finestra pari a “1” e “5”,diversificata per pattern di traffico.

137


6.5 Esempio e test di scalabilità del modello

Il modello sviluppato si presta ad un’immediata scalabilità. A dimostrazione di

quanto detto sono state eseguite delle simulazioni aggiungendo un ulteriore ac-

celeratore sul bus PCI. Le modifiche da apportare al modello sono minime ed

interessano il solo scheduler. La presenza di un nuovo acceleratore richiede che

lo scheduler operi la sua scelta scegliendo questa volta il minore tra i 3 tempi di

fine calcolati applicando il solito algoritmo di scheduling, rispettivamente per la

CPU, l’acceleratore-1, e l’acceleratore-2. Nessuna altro cambiamento è neces-

sario, lo scheduler può continuare a sfruttare le proprietà sulle SA dei pacchetti

nella sliding window per smistaremergedverso i processori ed ottimizzare le per-

formance del sistema. In questa nuova situazione emerge però un problema di

condivisione del bus PCI da parte dei due acceleratore che potrebbe influenzare

negativamente le performance del sistema. Di seguito sono riportati i grafici di

maggiore interesse inerenti il nuovo sistema multi-acceleratore. I parametri con-

siderati sonoIratio = 3, W = 5, SAdistribution = 4equal, dato che per tutti gli

altri valori il comportamento del sistema multi-acceleratore è analogo al sistema

con singolo dispositivo.

In Figura6.22sono mostrate le curve di throughput del sistema con doppio

acceleratore crittografico. L’andamento segue quello dei precedenti sistemi (si

veda la Figura6.17), ma le performance del sistema sono notevolmente migliorate

con valori al di sopra dei 400Mbit/s.

Due acceleratore alleggeriscono il numero di pacchetti processati dalla CPU

come mostrato in Figura6.23, dove sono riportate le percentuali di utilizzo della

CPU e dell’acceleratore-1 (l’acceleratore-2 si ricava di conseguenza). In que-

sto caso, l’uso della CPU si colloca al si sotto del 30%, con valori decrescenti

all’aumentare diEratio.

La latenza media del sistema non subisce sostanziali miglioramenti, nonostan-

te l’uso congiunto dei due processori. Globalmente diminuisce restando nell’in-

torno dei valori del sistema a singolo acceleratore (in Figura6.18).

Infine, come accennato, vengono riportati in Figura6.24i grafici sui conflitti

138


350000

400000

450000

500000

550000

600000

650000

700000

750000

1 2 3 4 5 6 7

Sys

tem

Thr

ough

put [

kbit/

s]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.22:Throughput del sistema multi-acceleratore.

sul bus che inevitabilmente si originano dalla condivisione del canale da parte dei

due acceleratori. Si osservi come nel caso di sistema senza sliding window (gra-

fico (a)) i pattern di traffico a dimensione dei payload fissa non creino conflitti.

Si verifica una situazione in cui mentre un acceleratore processa i dati l’altro li

carica dal bus, senza quindi conflitti reciproci. Per giustificare un comportamen-

to del genere si deve pensare che i dati giungono ad un rate elevato e che il bus

ha una banda abbastanza ampia da permettere una trasmissione veloce anche con

pacchetti di dimensione 1024 bytes; inoltre nella fase iniziale quando lo scheduler

smista il primo pacchetto verso gli acceleratori crea uno sfasamento temporale di

processamento dei dati tra i due dispositivi. Nel grafico (b) invece si noti come

la presenza della sliding window e di conseguenza ilmergedei pacchetti aumen-

ti la percentuali di conflitti sul numero di richieste di accesso al bus. In questo

caso i pacchettimergedinviati dallo scheduler modificano la natura costante dei

pattern “fixToxxxx”, pertanto si perde quel tipo di pseudo- sincronizzazione tra i

processori discusso a proposito del grafico (a). Si faccia attenzione a come imer-

gedagiscano sui pattern a dimensione costante. In particolare si noti come, per i

139


a)

5

10

15

20

25

30

35

40

1 2 3 4 5 6 7

CP

U u

sage

[%]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

b)

30

32

34

36

38

40

42

44

46

1 2 3 4 5 6 7

AC

C1

usag

e [%

]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.23: Sistema multi-acceleratore: percentuale sul totale di pacchettiprocessati (a) nella CPU e (b) nell’acceleratore-1.

140


a)

0

2

4

6

8

10

12

14

16

18

1 2 3 4 5 6 7

AC

C1

bus

conf

licts

[%]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

b)

10

11

12

13

14

15

16

17

18

1 2 3 4 5 6 7

AC

C1

bus

conf

licts

[%]

Encoder Time Ratio


fix0fix64

fix512fix1024

expuniform

real

Figura 6.24:Percentuale di conflitti sul numero di richieste di accesso al bus perl’acceleratore-1 con (a)W = 1 e (b) conW = 5.

141


pattern “fixToxxx”, ad una minore dimensione di payload corrisponde una mag-

giore percentuale di conflitti. E’ naturale aspettarsi un risultato simile in quanto,

come commentato, imergedmigliorano le prestazioni soprattutto in presenza di

una dimensione media dei pacchetti piccola. Per i pattern a distribuzione statistica

del payload invece la presenza di una sliding window e dei pacchettimergednon

modifica significativamente il numero di conflitti sul bus. Il grafico in Figura6.24

raccoglie i dati per l’acceleratore-1 ma possiamo ritrovare risultati analoghi, data

la simmetria del sistema anche per l’acceleratore-2.

142

Capitolo 7

Conclusioni

Il lavoro di tesi svolto si è concentrato sulle problematiche connesse con gli acce-

leratori crittografici hardware usati nelle reti VPN basate su IPsec. Si sono curati

due aspetti in particolare: in primo luogo si sono esplorate le alternative di design

provenienti dagli acceleratori hardware in commercio; successivamente si è svi-

luppato un modello aSystem Levelattraverso il quale studiare il comportamento

del sistema CPU-acceleratore in funzione delle dimensioni dei pacchetti.

L’analisi condotta sugli acceleratori crittografici in ambito aziendale ha pro-

dotto come risultato un ampia varietà di dispositivi, ognuno con proprie caratteri-

stiche e performance, adattabili quindi a diversi contesti d’uso (si veda il capitolo

3). I dati raccolti, insieme con le proposte in letteratura [25], sono stati organizzati

e formalizzati per ottenere un approccio generale, di alto livello, al design degli

acceleratori crittografici, descritto nel capitolo4. In particolare il problema del

design interno è stato affrontato con un orientamento multilivello che tenga conto

dei fattori chiave per un’efficiente implementazione del dispositivo. La metodolo-

gia di design proposta ha il duplice vantaggio di poter essere usata sia come linea

guida nella progettazione degli acceleratori hardware che anche come sistema per

classificare i dispositivi.

Successivamente si è fatto uso di tale metodologia di design per identificare le

specifiche di un acceleratore da includere in un modello simulativo che compren-

143

7. Conclusioni

da l’uso di tale acceleratore in supporto alla CPU. Novità rispetto a quanto avviene

in ambito industriale è che, nel sistema considerato, la presenza dell’acceleratore

non esclude che la CPU possa comunque espletare, di per sè, l’algoritmo critto-

grafico senza fare uso dell’hardware dedicato (si veda il capitolo5). Per sfruttare

questo parallelismo tra i due processori è stato proposto un algoritmo di sche-

duling descritto in sezione5.4 che smisti efficientemente i pacchetti in funzione

della loro dimensione e dello stato del sistema. L’idea e la progettazione di una

sliding window, presentata in sezione6.3.1, rappresenta un ulteriore innovazione

introdotta nel sistema che, insieme con l’algoritmo di scheduling, ha prodotto no-

tevoli miglioramenti rispetto ad un modello che invii indiscriminatamente tutti i

pacchetti verso l’acceleratore (si veda il capitolo6).

Sono state effettuate una serie di simulazioni sul sistema in oggetto al fine di

misurare l’efficienza dello scheduling dei pacchetti e gli effetti della sliding win-

dow. I risultati ottenuti su questa architettura dimostrano che l’uso della CPU è

particolarmente utile per compensare l’inefficienza dell’acceleratore nel proces-

sare pacchetti di piccole dimensioni. Lo scheduler infatti predilige la CPU per il

processamento dei pacchetti piccoli sui 40/64 bytes. La possibilità di effettuare

dei mergedei pacchetti, tramite la sliding window, ha accresciuto le dimensione

media dei dati processati i quali vengono maggiormente “ingeriti” dall’accelerato-

re con incremento del throughput complessivo ed ovvio alleggerimento del carico

di lavoro svolto dalla CPU. In termini di latenza media lo scheduling appiattisce i

tempi del sistema CPU/acceleratore su valori del tutto accettabili; così come sono

accettabili i ritardi introdotti dall’uso della sliding window.

In ultima analisi si è data prova dell’efficiente scalabilità del modello pro-

posto presentando un sistema multi-acceleratore in cui due dispositivi hardware

cooperano con la CPU per il processamento dei dati. In tale situazione sorgono

inevitabili conflitti nell’accesso al bus PCI condiviso dai due acceleratori. I dati

raccolti dimostrano comunque che la percentuale di conflitti sul bus si mantiene

piuttosto bassa e non causa gravi perdite in termini di throughput del sistema.

144

7. Conclusioni

7.1 Sviluppi futuri

Il modello usato nelle simulazioni si presta ad una serie di sviluppi ulteriori, prin-

cipalmente diretti verso un più alto grado di dettaglio dei moduli e dell’architettu-

ra.

Innanzitutto è opportuno inserire un timestamp sui pacchetti e di conseguenza

gestire anche l’inter departure time(IDT) tra un pacchetto. In questo modo si sti-

mola il sistema con un traffico più simile al comportamento reale della rete invece

di considerare un traffico a velocità massima nominale. Una modifica impatta sul

modello del sistema in modo sostanziale. Si pensi a quali conseguenze si avreb-

bero sui dati delle simulazioni a causa delle pause tra un pacchetto ed un altro. Si

potrebbe infatti verificare la situazione in cui, a causa delle lunghe attese, l’accele-

ratore ha il tempo di processare tutti i dati inviati dallo scheduler prima che arrivi

un nuovo pacchetto. Un altra conseguenza dell’IDT potrebbe essere l’incremento

della latenza causato dai ritardi con i quali si avrebbero gli eventi “finestra_piena”

nella sliding window.

In un sistema in cui i pacchetti sono ricevuti secondo un IDT statistico, o

campionato su trace di traffico reale, è necessario che si setti un timeout per la

lettura dalla sliding window. Un modo efficiente è quello di impostare il timeout

dinamicamente attraverso lo scheduler. Una proposta per un valore da assegnare

al timeout è lo stesso tempo di fine calcolato per il pacchetto in fase di lettu-

ra. Sembra sensato infatti assumere che la prossima lettura avvenga in seguito

all’elaborazione dell’ultimo pacchetto letto dalla sliding window.

Un altra miglioria applicabile alla sliding window interessa direttamente la

dimensione della finestra di osservazione. Nelle simulazioni effettuate si è consi-

derato un valore diW pari al massimo a “5”. Tale lunghezza è sicuramente insuf-

ficiente e deve essere ulteriormente accresciuta in concomitanza con distribuzioni

di SA sparse. Nei sistemi reali infatti si hanno centinaia di SA e di conseguen-

za si potrebbero avere due pacchetti con SA identica solo dopo parecchi dati. Per

ovviare a questo inconveniente, anche per la dimensione della finestra si può adot-

tare un approccio dinamico. La sliding window può essere settata adattativamente

145

7. Conclusioni

col traffico in ingresso. In questo caso la sliding window dove memorizzare, in

realtime, le informazioni circa i pacchetti ricevuti mantenendo una storia dei dati

processati al fine di estrapolare una statistica sul traffico in ingresso, dalla quale

poi trarre le indicazione per adattare le proprie dimensioni.

Più a basso livello si può agire sull’architettura e simulare anche le istruzioni di

controllo ed i messaggi tra CPU ed acceleratore. In questo modo si ha un utilizzo

contemporaneo del bus sia per i dati che per le istruzioni di controllo con ovvi

impatti sulle performance del sistema. Una direzione di studio è proprio quella di

investigare quali siano gli effetti della concorrenza sul bus (si pensi anche ad una

architettura multi-acceleratore).

Sviluppo naturale del sistema è verso le architetture multi-acceleratore, per le

quali cresce ovviamente la complessità dello scheduling e la concorrenza sul bus.

Infine, si può introdurre unaquality of service(QoS) sui pacchetti, un servizio

questo, che nelle reti attuale assume un ruolo sempre più importante.

146

Appendice A

Cenni di crittografia

E’ possibile identificare due tipi di algoritmi crittografici, basati su chiave simme-

trica e su chiave pubblica. I primi sono più veloci e molto sicuri ma necessitano

di una chiave pre-condivisa. I secondi sono più lenti ma non per questo meno

sicuri, se si sceglie una adeguata dimensione della chiave, e soprattutto non ne-

cessitano di nessuna chiave pre-condivisa. Una breve descrizione delle due classi

di algoritmi e una presentazione del protocollo Diffie-Hellman vengono date di

seguito.

A.1 Algoritmi a chiave simmetrica

Questo tipo di algoritmo utilizza una chiave pre-condivisa; fondamentalmente si

utilizza tale chiave per applicare le dovute trasformazioni ai dati da codificare.

Diverse configurazioni operative esistono per questi algoritmi, basate sul tipo di

applicazione con i quali vengono utilizzati. Ad esempio, per applicazioni nelle

quali grandi blocchi di dati devono essere trasmessi, ilCBC modeè sicuramente

il più adatto (si veda [41] alla sezione 1.5).

L’algoritmo più usato è il triple-DES (Digital Encryption Standard), una va-

riazione del vecchio (1977) DES. Un nuovo algoritmo criptografico chiamato

AES (Advanced Encryption Standard) è stato proposto dalla NSA per rimpiaz-

147

A. Cenni di crittografia

zare il triple-DES. Nel prossimo futuro AES diventerà probabilmente il de-facto

standard, come attualmente è il triple-DES.

A.2 Algoritmi a chiave pubblica

Questo tipo di algoritmo risolve il problema di dover avere una chiave pre-condivisa

utilizzando tecniche crittografiche asimmetriche. Sono necessarie due chiavi per

ogni peer, una denominata privata e conosciuta solo dal possessore, un’altra deno-

minata pubblica e conosciuta a chiunque volesse comunicare con quel determinato

peer. Si instaura una comunicazione sicura utilizzando la chiave pubblica del peer

per effettuare le trasformazioni crittografiche sui dati. In questo modo si proteg-

ge la comunicazione diretta verso il peer rendendo i dati inacessibili a chiunque

non possedesse la chiave privata. La trasformazione inversa infatti non può essere

effettuata conoscendo solamente la chiave pubblica (si veda [41] alla sezione 1.8).

Attualmente il più usato algoritmo di questa classe è RSA, ma nuovi algoritmi,

come ad esempio l’ECC (Elliptic Curve Cryptography), sono stati sviluppati e

diverranno probabilmente nel breve periodo i più diffusi.

A.3 Il protocollo Diffie-Hellman

Diffie-Hellman fornisce una soluzione al problema dello scambio delle chiavi per-

mettendo a due parti, mai incontratesi precedentemente o senza essersi mai scam-

biate delle chiavi, di stabilire una chiave condivisa scambiandosi messaggi su un

canale aperto. La chiave è scambiata nel modo seguente:

Il primo peer (A) sceglie una chiave segreta casuale denominatax, esegue

alcune operazioni su di essa ed invia il risultato (h) a B;

Il secondo peer (B) sceglie una chiave segreta casuale chiamatay, effettua

alcune operazioni su di essa ed invia il risultato (k) ad A;

B riceve h da A e calcola la chiave utilizzando h e y;

A riceve k da B e calcola la chiave utilizzando k e x;

148

A. Cenni di crittografia

La protezione della chiave segreta è data dal fatto che le operazioni effettuate

sux ey per ottenereh ek non sono facilmente invertibili, nel senso che è richiesto

un tempo computazionale molto elevato. Pertanto se un’eventuale terza parte fos-

se capace di scoprire il valore dih ek non sarebbe comunque in grado di scoprire

la chiave segreta in un tempo ragionevole.

Le operazioni applicate adx e y per ottenereh e k si basano sia su curve

ellittiche che sugli esponenziale nel dominio discreto. Il primo caso fa riferimento

allo stesso principio dell’ECC, mentre il secondo è basato sull’RSA.

Vedi [41] alla sezione 12.6 e [42] per maggiori informazioni su Diffie-Hellman

e le procedure di scambio delle chiavi.

A.4 Algoritmi di identificazione

Questo tipo di algoritmi sono utilizzati per certificare la provenienza dell’informa-

zione in modo da prevenire modifiche da parte di terzi. Questo può essere effet-

tuato calcolando una funzione hash dei dati al quale applicare successivamente un

algoritmo crittografico, a chiave pubblica o simmetrica (si veda [41] alla sezione

1.7). Una funzione di hash possiede la proprietà che, quando applicata a qualche

dato, fornisce un differentebrief codeper ogni blocco, o almeno la probabilità di

ottenere lo stesso codice per dati differenti è soddisfacentemente bassa (si veda

[41] alla sezione 1.9).

149

Bibliografia

[1] S. Kent and R. Atkinson, Security Architecture for the Internet

Protocol, IETF, November 1998, RFC2041. [Online]. Available:http:

//www.ietf.org/rfc.html

[2] A. Shacham, B. Monsour, R. Pereira, and M. Thomas,IP Payload

Compression Protocol (IPComp), IETF, September 2002, RFC3173.

[Online]. Available:http://www.ietf.org/rfc.html

[3] S. Kent and R. Artkinson,IP Encapsulating Security Payload (ESP), IETF,

November 1998, RFC2406. [Online]. Available:http://www.ietf.org/rfc.

html

[4] ——, IP Authentication Header, IETF, November 1998, RFC2402.

[Online]. Available:http://www.ietf.org/rfc.html

[5] D. Harkins and D. Carrell,The Internet Key Exchange (IKE), IEEE,

RFC2409. [Online]. Available:http://www.ietf.org/rfc.html

[6] M. Thomas and J. Vilhuber,Kerberized Internet Negotiation of Keys (KINK),

IETF, January 2003, Expired.

[7] R. Moskowitz, P. Nikander, P. Jokela, and T. R. Henderson,Host Identity

Protocol, IETF, October 2003, Work in progress.

[8] I. K. E. I. Protocol,Host Identity Protocol, IETF, October 2003, Work in

progress.

150

http://www.ietf.org/rfc.html







BIBLIOGRAFIA

[9] D. L. McDonald, C. Metz, and B. G. Phan,PF KEY Key Management API,

Version 2, IETF, August 1996, RFC1994.

[10] D. Maughan, M. Schertler, M. Schneider, and J. Turner,Internet Security As-

sociation and Key Management Protocol (ISAKMP), IETF, Novemebr 1998,

RFC2408.

[11] D. Piper,The Internet IP Securiy Domain of Interpretation for ISAKMP,

IETF, 1998, RFC2407. [Online]. Available:http://www.ietf.org/rfc.html

[12] A. Forzieri, “IPsec e Mobile VPN,” Tesi, Politecnico di Milano, 2002.

[13] D. Cerri, “IPSec e TLS a confronto: funzionin prestazioni ed estensioni,”

Tesi, Politecnico di Milano, Ottobre 2001.

[14] R. Savarda, “Next Generation Network Security Processors, Optimal

Design ad Integration with Network Processors,” inThe Communication

Design Conference, I. NectOctave, Ed., 2001. [Online]. Available:

http://netoctave.com

[15] Broadcom, web site. [Online]. Available:http://www.broadcom.com

[16] Corrent, web site. [Online]. Available:http://www.corrent.com

[17] Hifn, web site. [Online]. Available:http://www.hifn.com

[18] IBM, web site. [Online]. Available:http://www.ibm.com

[19] FreeScale, web site. [Online]. Available:http://www.freescale.com

[20] Sun, web site. [Online]. Available:http://www.sun.com

[21] J. Davis, “Which security processor is faster ?” Corrent, Tech. Rep., 2003,

White Paper.

[22] NIST, web site. [Online]. Available:http://www.nist.gov

151


http://netoctave.com

http://www.broadcom.com

http://www.corrent.com

http://www.hifn.com

http://www.ibm.com

http://www.freescale.com

http://www.sun.com

http://www.nist.gov

BIBLIOGRAFIA

[23] A. systems, “Hardware Security Modules: Where Companies Put Their

Trust,” AEP Systems, Tech. Rep., 2003, White Paper.

[24] N. Gammage, “Security application note,” December 2001, Technical

Marketing.

[25] P. Gutmann, “An Open-Source cryptographic coprocessor,” inIn Proc. of

the 9th Usenix Security Symposium, August 2000, pp. 97–112. [Online].

Available: citeseer.ist.psu.edu/gutmann00opensource.html

[26] S. Smith and S. Weingart, “Building a high-performance, programmable

secure coprocesor,” IBM Research Report RC 21102, Tech. Rep., Febrary

1998. [Online]. Available:http://citeseer.ist.psu.edu/smith98building.html

[27] G. Bucci,Architettura dei Calcolatori Elettronici. Mcgraw Hill, 2000.

[28] E. Hong, J.-H. Chung, and C. H. Lim, “Hardware design and performan-

ce estimation of the 128-bit block cipher crypton,” inFirst International

Workshop, Worcester, Ma, Usa, August 1999, pp. 49–61.

[29] N. I. of Standards and Technology,Security Requirements For Cryptogra-

phic Modules, U.S. Department of Commerce, January 1994.

[30] R. Friend, “Making the Gigabit IPsec VPN Architecture Secure,”IEEE

Computer, vol. 37, no. 6, pp. 54–60, June 2004.

[31] P. Gutmann, “The Design of a Cryptographic Security Architecture,” inThe

8th Usenix Security Symposium, August 1999.

[32] J. Owen, “Crypto channel controller,” ST Microelectronics, Tech. Rep. NS-

AS-F01, March 2003, Confidential Report.

[33] N. Ferguson and B. Schneier, “A Cryptographic Evaluation of IPsec,”

Counterpane Internet Security, Inc., Tech. Rep., 1999. [Online]. Available:

http://www.counterpane.com

152

citeseer.ist.psu.edu/gutmann00opensource.html

http://citeseer.ist.psu.edu/smith98building.html

http://www.counterpane.com

BIBLIOGRAFIA

[34] A. Ferrante, “Scheduling algorithm for a multi-accelerator-based IPSec

system,” Febrary 2004, ALaRI Internal Article.

[35] S. Group, “System C Library and Documentation.” [Online]. Available:

http://www.systemc.org

[36] S. Miltchev, S. Ioannidis, and A. D. Keromytis, “A study of the relative costs

of network security protocols,” inProceedings of the FREENIX Track: 2002

USENIX Annual Technical Conference. USENIX Association, 2002, pp.

41–48.

[37] S. McCreary, “Packet Length Distributions at NASA Ames Internet

Exchange (AIX),” Internet Analisys of the Cooperative Association for

Internet Data Analysis (CAIDA). [Online]. Available:http://www.caida.org

[38] S. Avallone, D. Emma, A. Pescapè, and S. Guadagno, “D-ITG -

Distributed Internet Traffic Generator,” Aprile 2004. [Online]. Available:

http://www.grid.unina.it/software/ITG/index.php

[39] ITA, “Internet Traffic Archive,” 2000. [Online]. Available: http:

//www.ita.ee.lbl.gov

[40] T. Group, “TCPDUMP public repository.” [Online]. Available:http:

//www.tcpdump.org

[41] A. Menezes and S. V. P. van Oorschot,Handbook of Applied Cryptography.

CRC Press, October 1996.

[42] R. Schroeppel, H. Orman, and S. O. Malley, “Fast key exchange with

elliptic curve systems,” 1995. [Online]. Available:http://citeseer.nj.nec.

com/schroeppel95fast.html

[43] R. Yuan and W. Strayer,Virtual Private Networks, Technologies and

Solution. Addinson-Wesley, 2001.

153

http://www.systemc.org

http://www.caida.org

http://www.grid.unina.it/software/ITG/index.php

http://www.ita.ee.lbl.gov

http://www.ita.ee.lbl.gov

http://www.tcpdump.org

http://www.tcpdump.org

http://citeseer.nj.nec.com/schroeppel95fast.html

http://citeseer.nj.nec.com/schroeppel95fast.html

BIBLIOGRAFIA

[44] L. Lamport,Latex User’s Guide and Reference Manual. Addinson-Wesley,

2000.

[45] N. Doraswamy and D. Harkins,IPSec: The New Security Standard for the

Internet, Intranets, and Virtual Private Networks. Pearson Education, 2003.

[46] Y. Hoskote, S. Vangal, V. Erraguntla, and N. Borkar, “A High-speed, Multi-

threaded TCP offload Engine for 10Gbps Ethernet,” inIEEE Conference,

2003, pp. 125–135.

[47] S. Makinemi and R. Iyer, “Architectural Characterization of TCP/IP Pac-

ket Processing on the Pentium M microprocessor,” inTenth International

Symposium on High-Performance Computer Architecture. IEEE, Febrary

2004.

[48] S. Ariga, K. Nagasachi, M. Minami, H. Esaki, and J. Murai, “Performan-

ce Evaluation of Data Trasmission Using IPSec over IPv6 Networks,” inin

INET. Yokohama, Japan: ISOC, July 2000.

[49] A. Ferrante and J. Owen, “IPSec Hardware Resource Requirements

Evaluation,” University of Milan and ST Microelectronics work.

[50] E. P. Markatos, “Speeding up TCP/IP: Faster Processors are not Enough,” in

IEEE Conference, Febrary 2002, pp. 341–345.

[51] C. Paar and L. Breveglieri, “Introduction to cryptography: Theory, software

and hardware,” ALari, Lugano, 2004, Lectures Notes.

[52] D. Cerri, “Sicurezza a livello IP: IPSec e le reti private virtuali,” Articolo

divulgativo.

[53] ——, “Sicurezza a livello IP: IPSec e FreeS/WAN,” 2001, Pluto-

Meeting,Slides.

[54] N. Cravotta, “Accelerating high-speed encryption: one bottleneck after

another,” Technical Report, August 2001.

154

Studio degli acceleratori crittograﬁci per IPsec: alternative di...

Documents

Transcript of Studio degli acceleratori crittograﬁci per IPsec: alternative di...