FACOLTÀ DI INGEGNERIA - infocom.uniroma1.itinfocom.uniroma1.it/~robby/Tesi/Alessandrelli 2006-07.pdf · Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni A.A. 2006/2007

FACOLTÀ DI INGEGNERIA Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni

Anno Accademico 2006‐2007

Identificazione e realizzazione di un modello di rappresentazione delle configurazioni di

tunneling in IPv6

Relatore: Candidato: Chiar.mo Prof. Roberto Cusani Sonia Alessandrelli

Matr. 796189 Correlatori: Ing. Simone Ferraresi Ing. Gianluca Maiolini

Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni A.A. 2006/2007

Identificazione e realizzazione di un modello di rappresentazione delle configurazioni di tunneling in IPv6

Pagina 2 di 189

INDICE

INTRODUZIONE......................................................................................................6 1 Sicurezza nelle reti ..............................................................................................9 1.1 La Norma ITU‐T X.800 .............................................................................10 1.2 Il Modello della Sicurezza........................................................................13 1.2.1 S‐VPN......................................................................................................15

1.3 Internet Key Exchange .............................................................................15 1.3.1 Scambio delle Chiavi ................................................................................16

1.4 IP Security ..................................................................................................18 1.4.1 Modalità di funzionamento......................................................................18 1.4.2 Security Association ................................................................................19 1.4.3 Authentication Header ............................................................................22 1.4.4 Encripted Security Payload .....................................................................26 1.4.5 Network Address Translation..................................................................29

2 IPV6......................................................................................................................32 2.1 Principali caratteristiche di IPv6 .............................................................33 2.2 Le Opzioni..................................................................................................38 2.3 Indirizzi IPv6 .............................................................................................40 2.3.1 Rappresentazione degli Indirizzi IPv6.....................................................40 2.3.2 Tipi di Indirizzi........................................................................................41 2.3.3 Indirizzi IPv6 con Indirizzi IPv4 Embedded ...........................................44

2.4 Autoconfigurazione..................................................................................44 2.4.1 Autoconfigurazione Stateless ..................................................................45 2.4.2 Autoconfigurazione Stateful....................................................................46

2.5 Gestione della QoS....................................................................................46 2.6 Sicurezza.....................................................................................................47 2.6.1 Authentication Header ............................................................................48 2.6.2 Encripted Security Payload .....................................................................49

2.7 Interoperabilità IPv6‐IPv4........................................................................49 2.7.1 Dual stack ................................................................................................50 2.7.2 Translation...............................................................................................51 2.7.3 Tunneling ................................................................................................55

3 Progettazione architettura di gestione per IPv6 ..........................................64 3.1 Il Progetto SAS‐Price ................................................................................65 3.1.1 SAS Manager...........................................................................................65



Pagina 3 di 189

3.1.2 SAS‐Price.................................................................................................66 3.2 Analisi ed Evoluzione del Progetto........................................................70 3.2.1 Progettazione concettuale ........................................................................71 3.2.2 Progettazione logica .................................................................................80 3.2.3 Progettazione fisica ..................................................................................91

4 Realizzazione dell’Aliger .................................................................................99 4.1 Strumenti di sviluppo...............................................................................99 4.1.1 Piattaforma .NET ....................................................................................99 4.1.2 C# ...........................................................................................................101 4.1.3 DataSet ..................................................................................................102

4.2 Security Framework ...............................................................................105 4.2.1 Modulo Popolatore.................................................................................105 4.2.2 Modulo Visualizzatore ...........................................................................108 4.2.3 Modulo Traduttore CSV........................................................................109 4.2.4 Moduli Split e Compose.........................................................................111

4.3 Implementazione dell’Aligner ..............................................................111 4.3.1 Connessione ai DataBase .......................................................................111 4.3.2 Evoluzione del progetto..........................................................................112 4.3.3 Compatibilità tra GSDB e SMDB .........................................................115 4.3.4 Elaborazione delle informazioni delle tabelle .........................................117

CONCLUSIONI .....................................................................................................127 APPENDICE A: Dizionario delle tabelle del GSDB .........................................130 APPENDICE B: Dizionario delle tabelle del DVDB ........................................139 APPENDICE C: Dizionario delle tabelle dell’SMDB .......................................157 APPENDICE D: Codice dell’Aligner ...................................................................170 BIBLIOGRAFIA .....................................................................................................188



Pagina 4 di 189

Indice delle Figure Figura 1.1: Modello della sicurezza degli accessi nella rete.........................................13 Figura 1.2: Modello di protezione dellʹinformazione nella rete...................................14 Figura 1.3: IKE – Fase 1: Main Mode e Aggressive Mode..........................................17 Figura 1.4: IKE – Fase 2: Quick Mode ........................................................................17 Figura 1.5: IPSec – Tunnel Mode e Transport Mode..................................................19 Figura 1.6: IPSec – Formato dellʹintestazioneʹAH .....................................................23 Figura 1.7: Formato del pacchetto con AH in Transport Mode ..................................24 Figura 1.8: Formato del pacchetto con AH in Tunnel Mode.......................................25 Figura 1.9: IPSec – Formato del datagramma ESP .....................................................27 Figura 1.10: Formato del pacchetto con ESP in Transport Mode ...............................29 Figura 1.11: Formato del pacchetto con ESP in Tunnel Mode ...................................29 Figura 1.12: Pacchetto ESP in Tunnel Mode con incapsulamento UDP ...................30 Figura 2.1: Intestazione di IPv6 ..................................................................................34 Figura 2.2: Intestazione di IPv4 ..................................................................................35 Figura 2.3: Datagramma IPv6....................................................................................38 Figura 2.4: Formato del pacchetto IPv6 con AH in Transport Mode .........................48 Figura 2.5: Formato del pacchetto IPv6 con AH in Tunnel Mode..............................49 Figura 2.6: Schema del Dual Stack v4/v6....................................................................50 Figura 2.7: Schema delle Transition v4/v6 BIS e BIA.................................................53 Figura 2.8: Translation IPv6 ‐ IPv4 con NAT‐PT......................................................55 Figura 2.9: Formato del pacchetto IPv6 in IPv4..........................................................56 Figura 2.10: Tunneling IPv6‐in‐IPv4 .........................................................................56 Figura 2.11: Tipi di Tunneling IPv6‐IPv4 ..................................................................57 Figura 2.12: Manual Tunnel IPv6‐in‐IPv4 ................................................................58 Figura 2.13: Compatible IPv4 Tunnel.........................................................................59 Figura 2.14: 6to4 Tunnel.............................................................................................63 Figura 3.1: Architettura del SAS Manager.................................................................65 Figura 3.2: Schema del progetto SAS‐Price ................................................................69 Figura 3.3: Rappresentazione grafica dei costrutti del modello Entità‐Relazione.......72 Figura 3.4: Schema concettuale del GSDB ..................................................................74 Figura 3.5: Schema concettuale del DVDB .................................................................78 Figura 3.6: Schermata Microsoft Visual Studio 2005 Express Edition ......................91 Figura 3.7: Schema Fisico del GSDB, Area Element...................................................93 Figura 3.8: Schema Fisico del GSDB, Area Device .....................................................94



Pagina 5 di 189

Figura 3.9: Schema Fisico del GSDB, Area Conns .....................................................95 Figura 3.10: Schema Fisico del GSDB, Area Device e Area SMNP ...........................96 Figura 3.11: Schema Fisico del GSDB, Area Rules Access List..................................97 Figura 3.12: Schema Fisico del GSDB, Area Firewall.................................................98 Figura 4.1: Schermata principale di Microsoft Visual Studio...................................100 Figura 4.2: Esempio di tabella del DataSet................................................................103 Figura 4.3: Security Framework, schermata principale ............................................105 Figura 4.4: Security Framework, Modulo Popolatore ...............................................106 Figura 4.5: Security Framework, Modulo Visualizzatore .........................................108 Figura 4.6: Funzioni allineamento GSDB – SMDB .................................................113 Figura 4.7: Diagramma E‐R dell’SMDB ..................................................................116 Figura 4.8: Compatibilità GSDB – SMDB ...............................................................117 Figura 4.9: Schema logico dell’Aligner......................................................................126

Indice delle Tabelle Tabella 1.1 – Minacce ad un sistema di comunicazione ..............................................12 Tabella 2.2 – Tipi di Extension Headers IPv6 .............................................................39 Tabella 2.3 – Classificazione degli indirizzi IPv6 in base ai bit più significativi ........41 Tabella 2.4 – Tipi di traffico e livelli di priorità IPv6 ..................................................47



Pagina 6 di 189

IINNTTRROODDUUZZIIOONNEE Una rete di telecomunicazioni è definibile come un insieme di nodi, canali trasmissivi e procedure mediante le quali due o più dispositivi possono scambiarsi delle informazioni. In particolare le entità comunicano utilizzando un protocollo, ovvero un insieme di regole che definiscono il formato, la sintassi e la semantica dei messaggi scambiati. La rete oggi più estesa e conosciuta è Internet, con quasi 400 milioni di nodi connessi, ed il protocollo su cui si basa è IP, Internet Protocol. Esistono diverse versioni di IP, aventi in comune le caratteristiche di base pur restando comunque protocolli distinti. In particolare la versione 4 di Internet Protocol è quella attualmente utilizzata su Internet e nella maggior parte delle reti locali mentre Internet Protocol versione 6, inizialmente sviluppato con il nome di IPng (IP next generation), è stato formalizzato negli anni ’90 e si sta affiancando progressivamente ad IPv4 con l’obiettivo di sostituirlo. Sicuramente IPv6 supera numerose limitazioni di IPv4 e molti suoi aspetti sono stati progettati alla luce delle problematiche emerse negli ultimi 20 anni di intenso utilizzo di IPv4. Purtroppo però IPv4 e IPv6 non sono compatibili e, pertanto, programmi e sistemi progettati per uno standard non possono comunicare direttamente con quelli pensati per l’altro. Inoltre la diffusione capillare e radicata dei sistemi basati su IPv4 non consente al giorno d’oggi di realizzare una transizione rapida dal vecchio al nuovo protocollo, rendendo di conseguenza necessaria l’implementazione di meccanismi e funzionalità in grado di permettere alle applicazioni di continuare a funzionare correttamente durante tutta la lunga fase di ‘aggiornamento’ della rete mondiale. Uno degli aspetti di IPv4 che si è cercato di migiorare in IPv6 è quello relativo alla sicurezza, rendendola integrata nello stesso protocollo. Infatti, la tutela della privacy e la sicurezza delle informazioni diventano requisiti di primaria importanza nella società odierna. Sono definiti diversi requisiti che individuano uno specifico livello di sicurezza. In particolare per la sicurezza in rete devono essere garantiti almeno l’autenticazione, l’integrità e la riservatezza. Questi requisiti sono offerti mediante dispositivi come un Security Gateway. La generazione delle regole di sicurezza e delle configurazioni di questi dispositivi spesso è fatta manualmente da un



Pagina 7 di 189

amministratore di rete nodo per nodo. La mancanza di un meccanismo di configurazione automatico dei dispositivi incrementa la potenziale esistenza di vulnerabilità o malfunzionamenti dovuti ad errori all’interno della configurazione. In questo senso è utile avere a disposizione uno strumento denominato NMS (Network Management System) con una funzionalità aggiuntiva di generazione automatica delle configurazioni dei dispositivi e risoluzione dei conflitti dovuti a errori nelle policy di sicurezza che possa aiutare l’amministratore di rete nel suo compito. Lo strumento di amministrazione di rete che è stato analizzato nel corso di questa tesi è l’NMS SAS‐Manager, un prodotto dei laboratori ElsagDatamat. Lo scopo di questa tesi è lo studio e l’integrazione all’interno del SAS‐Manager di nuove tecnologie come IPv6 nonché rendere possibile l’integrazione di queste tecnologie con funzionalità già implementate come gli strumenti di gestione avanzata della sicurezza nelle comunicazioni. In particolare in questo elaborato verranno esaminate le tecniche di traduzione degli indirizzi IP v6/v4 e verrà approfondito il concetto di tunneling come meccanismo che permette di incapsulare i dati in transito tra reti IPv6 su una rete IPv4. Il concetto di tunneling v4/v6 verrà confrontato coi sistemi di tunneling SVPN già integrati all’interno del sistema di NMS analizzato, al fine di rappresentare i dati in modo più uniforme e semplificato possibile all’interno dell’architettura di rete. Questo progetto si inserisce in un progetto più ampio, formato da più sottosistemi con un obiettivo comune: creare un unico sistema che permetta l’armonizzazione della rete, finalizzata ad una semplificazione della gestione della rete stessa in assenza di conflitti tra policy di sicurezza. Il lavoro è articolato in quattro capitoli. La tesi prevede in primo luogo la descrizione dei servizi di sicurezza che possono essere offerti in un contesto di rete, quali protezione della trasmissione dei dati mediante la realizzazione di SVPN IKE/IPSec. Nel secondo capitolo è fornita una descrizione del protocollo IPv6, degli aspetti di sicurezza implementati su tale protocollo e le tecniche di traduzione degli indirizzi v6/v4 e il concetto di tunneling. Nel terzo capitolo si introduce il progetto specifico del quale fa parte questo lavoro, il progetto SAS‐Price. Nell’ambito di tale progetto si evidenzia l’esigenza di implementare IPv6 all’interno dei database SQL su cui opera e verranno relazionate le funzionalità ad esso collegate con la struttura



Pagina 8 di 189

preesistente di gestione delle SVPN. Infine verrà implementato IPv6 all’interno di tali database scegliendo la soluzione di migliore utilizzo delle risorse. Nel quarto capitolo, infine, è descritta la fase di progettazione ed implementazione di un modulo software C# per realizzare la traduzione delle informazioni presenti nei database modificati tramite l’implementazione di IPv6 verso il database sul quale si basa il SAS‐Manager in modo da realizzare l’evoluzione teconologica di tale strumento.

Ringraziamenti Prima di ringraziare le persone che hanno collaborato alla realizzazione di questa tesi, vorrei ringraziare le persone della società ELSAGDATAMAT in cui lavoro da circa tre anni, perché hanno creduto in me e mi hanno supportato in tutto il difficoltoso cammino della laurea specialistica e del lavoro quotidiano che ho svolto con loro, in particolare rivolgo il mio più vorrei sentito ringraziamento al mio capo, il migliore che potessi sperare, Stefano Ponzuoli. Non ultimo in ordine di importanza sentitamente ringraziare mia madre Loretta Bolognini per avermi supportato in questi tre lunghi anni.



Pagina 9 di 189

11 SSiiccuurreezzzzaa nneellllee rreettii La protezione delle informazioni ha subito notevoli cambiamenti nel corso degli ultimi decenni, a partire dall’avvento di nuovi sistemi di immagazzinamento e trasferimento dei dati. In particolare, oltre agli aspetti di protezione di tipo fisico, che presuppongono l’accesso diretto all’elemento protetto per comprometterne la riservatezza, si è reso ultimamente necessario porre in primo piano l’aspetto della sicurezza logica, per proteggere le informazioni residenti in sistemi remoti o in transito tra essi. Con il termine “sicurezza” si intende l’insieme delle misure tese ad assicurare a ciascun utente autorizzato tutti e soli i servizi previsti per quell’utente, nei tempi e nelle modalità previste. Secondo la definizione ISO, la sicurezza è l’insieme delle misure atte a garantire la disponibilità, l’integrità e la riservatezza delle informazioni gestite:

Disponibilità: il sistema deve rendere disponibili a ciascun utente abilitato le informazioni alle quali ha diritto di accedere, nei tempi e nei modi previsti. Nei sistemi informatici, i requisiti di disponibilità sono legati a quelli di prestazione, di robustezza, di tolleranza ai guasti e di recupero dai guasti (garantire il rientro in funzione in tempo utile del sistema informatico, a seguito di eventi negativi anche gravi). La disponibilità di una informazione ad un utente, infatti, deve essere assicurata in modo ininterrotto durante tutto il periodo di tempo previsto (continuità del servizio);

Integrità: il sistema deve impedire l’alterazione diretta o indiretta delle informazioni, sia da parte di utenti e processi non autorizzati, che a seguito di eventi accidentali. Anche la perdita di dati (per esempio a seguito di cancellazione o danneggiamento), viene considerata come alterazione;

Riservatezza: il sistema deve impedire a chiunque di ottenere o dedurre, direttamente o indirettamente, informazioni che non è autorizzato a conoscere.

In un contesto di sistemi distribuiti, in cui la rete diventa un elemento fondamentale, si parla di sicurezza di rete ad indicare l’insieme di procedure, pratiche e tecnologie per proteggere le risorse, gli utenti e le organizzazioni che operano in rete.



Pagina 10 di 189

In questo capitolo sarà affrontato il problema della sicurezza nelle reti, partendo dal concetti generale di sicurezza per poi descrivere il modello di rete sicura S‐VPN. In particolare, con riferimento alle SVPN di descriveranno le caratteristiche dei security gateway preposti alla cifratura del traffico e la suite di protocolli IKE/IPSec utilizzati.

1.1 LA NORMA ITU-T X.800 La sicurezza delle reti in termini di attacchi, servizi di sicurezza atti a prevenirne il verificarsi e meccanismi di sicurezza che implementano tali servizi è stata oggetto di standardizzazione nella norma ITU‐T X.800 “Security Architecture for Open Systems Interconnection for CCITT Applications” [9]. La norma ITU‐T X.800 identifica tre componenti principali caratterizzanti un sistema di sicurezza:

- Evento indesiderato (attacco): rappresenta una qualunque azione indebita che miri a impedire il funzionamento di un servizio di sicurezza infrangendo uno o più meccanismi di sicurezza sfruttando le loro vulnerabilità o debolezze e guadagnando in tal modo l’accesso non autorizzato a dati protetti.

- Servizio: rappresenta una funzionalità che fornisce alcune garanzie di sicurezza al sistema di comunicazione, da cui l’utente può aspettarsi un determinato livello di protezione per l’informazione trasmessa.

- Meccanismo: rappresenta il mezzo con cui è implementato un servizio di sicurezza, ed è ogni soluzione progettata per scoprire, prevenire e recuperare un attacco

La norma ITU‐T X.800 definisce cinque categorie di servizi di sicurezza:

- Autenticazione: insieme di servizi che forniscono le prove dell’identità dell’utente nel corso di una comunicazione.

- Controllo dell’Accesso: insieme di servizi che permettono l’accesso di un certo utente ad un numero limitato di risorse, ovvero tutte e sole le risorse per le quali è autorizzato.

- Confidenzialità dei dati: insieme di servizi che proteggono i dati da letture, parziali o totali, non autorizzate.



Pagina 11 di 189

- Integrità dei dati: insieme di servizi che mirano a garantire che i dati ricevuti siano effettivamente tutti e soli quelli inviati, e che quindi l’informazione trasportata non sia stata alterata.

- Non Ripudio: insieme di servizi che impediscono di negare al mittente dell’informazione che egli l’abbia originata, ed al destinatario che egli l’abbia ricevuta.

Questi servizi sono realizzati tramite i seguenti meccanismi di sicurezza:

- Cifratura: trasformazione (reversibile da parte del legittimo destinatario) dei dati in modo da renderli inintelligibili a una terza parte non autorizzata.

- Firma Numerica: autenticazione dei dati tramite aggiunta di una firma ricavabile solo da chi è in possesso di una determinata informazione segreta che lo identifica univocamente.

- Controllo d’Accesso: verifica dell’identità (tramite autenticazione) di chi accede ad un dato sistema o ad una data risorsa di comunicazione.

- Integrità dei dati: aggiunta ai dati inviati di un codice univocamente ricavabile dai dati stessi che permette di verificare che non siano stati modificati durante il transito.

- Scambio di Autenticazione: mutua autenticazione fra le due entità partecipanti allo scambio dei dati.

- Traffico di riempimento (traffic padding): generazione di traffico che non contiene dati d’utente validi al fine di prevenire l’analisi del traffico.

- Controllo dell’instradamento: controllo del cammino seguito dai dati all’interno della rete che li trasporta alla destinazione.

- Certificazione mediante terze parti: autenticazione delle due entità partecipanti allo scambio dei dati da parte di una terza entità esterna ritenuta affidabile da entrambe.

La norma ITU‐T X.800 modella anche le minacce ad un sistema di comunicazione ed ai dati da esso trasportati:

- Distruzione: distruzione dell’informazione o delle risorse del sistema di comunicazione.

- Corruzione: modifica irreversibile e non autorizzata dell’informazione che la renda inutilizzabile.



Pagina 12 di 189

- Rimozione: furto o perdita dei dati o di altre risorse del sistema di comunicazione.

- Rivelazione: divulgazione non autorizzata di dati e informazioni. - Interruzione: indisponibilità dei dati o delle risorse necessarie alla loro

trasmissione. Tipo di Minaccia

Tipo di Attacco

Oggetto

Distruzione Disponibilità Distruzione di dati/informazioni o risorse di connettività

Corruzione Integrità Modifica non autorizzata di dati

Rimozione Disponibilità Furto o perdita di dati e altre risorse

Rivelazione Confidenzialità Divulgazione non autorizzata di dati e informazioni.

Interruzione

Disponibilità Rendere indisponibile le risorse di rete

Tabella 1.1 – Minacce ad un sistema di comunicazione

Per quanto riguarda gli attacchi alla sicurezza, la norma distingue fra attacchi passivi ed attacchi attivi. I primi non modificano le risorse o il funzionamento del sistema, ma compromettono la confidenzialità dei dati. Due esempi di attacchi passivi sono:

- Intercettazione del contenuto dei messaggi - Analisi del traffico

Gli attacchi attivi, invece, prevedono una modifica del flusso dei dati o la creazione di un falso flusso e possono essere suddivisi in quattro categorie:

- Mascheramento: assunzione da parte dell’entità attaccante di un’identità non propria;



Pagina 13 di 189

- Reply: replica di un messaggio (o di parte di lui) al fine di ottenere effetti non autorizzati ed imprevisti;

- Modifica: alterazione dell’informazione durante il transito; - Denial of Service: attacco alla disponibilità delle risorse necessarie alla

trasmissione dei dati;

1.2 IL MODELLO DELLA SICUREZZA L’attuale implementazione della struttura delle reti presenta numerosi problemi a livello di sicurezza. In particolare le informazioni presenti negli header dei pacchetti sono in genere ritenute corrette, e ciò permette agli hacker di attuare varie tipologie di attacco tramite la creazione di pacchetti falsi al fine di carpire informazioni o creare disservizio agli utenti. Inoltre, tutti i dati che si appoggiano su protocolli non crittografici, attraverso la rete pubblica sono esposti allʹosservazione di chiunque si trovi in rete. La sicurezza è necessaria qualora si debba proteggere le informazioni da chiunque possa rappresentare una minaccia ai requisiti richiesti di sicurezza dei dati, quali:

‐ Confidenzialità; ‐ Autenticità; ‐ Integrità.

Il modello di sicurezza degli accessi ad una rete privata ha come obiettivo limitare gli accessi a coloro che sono autorizzati e monitorare le attività della rete nel tentativo di rilevare la presenza di intrusi. La Figura 1.1 mostra un modello rappresentativo della nozione di sicurezza degli accessi alla rete.

Figura 1.1: Modello della sicurezza degli accessi nella rete



Pagina 14 di 189

La Figura 1.2 mostra un modello rappresentativo della nozione di sicurezza della rete in termini di protezione dell’informazione in fase di trasmissione. Un messaggio deve essere trasmesso da un’entità sorgente ad un’entità di destinazione e ciò richiede l’attraversamento di una rete (o di una serie di reti interconnesse).

Figura 1.2: Modello di protezione dellʹinformazione nella rete

Affinché lo scambio vada a buon fine è necessario stabilire un canale logico che permetta il trasferimento delle informazioni: ciò si realizza mediante l’instaurazione di un percorso all’interno della rete che collega le due entità e mediante l’uso cooperativo di protocolli di comunicazione da parte di tutti i nodi di questo percorso. In ogni caso un sistema crittografico di sicurezza si basa sulle due componenti: Una trasformazione di sicurezza delle informazioni trasmesse. La crittografia realizza una codifica del messaggio in modo che questo risulti illeggibile da parte di un estraneo. Un’informazione segreta nota ai due protagonisti dello scambio oppure solamente ad uno dei due. La chiave di crittografia viene utilizzata per codificare il messaggio prima della trasmissione e per decodificarlo dopo la ricezione. L’informazione segreta ed il messaggio da proteggere sono i due input della funzione di trasformazione di sicurezza, la quale a sua volta restituisce in output il messaggio protetto.



Pagina 15 di 189

1.2.1 S‐VPN La Virtual Private Network (VPN) è una rete privata virtuale che viene creata utilizzando un’infrastruttura di rete pubblica e condivisa (come Internet) per fornire un accesso e comunicazioni sicure tra utenti remoti. La VPN è utilizzata spesso per interconnettere gli uffici remoti di un’azienda in modo sicuro, ed è una soluzione meno onerosa rispetto all’utilizzo di una linea dedicata. Le due reti fisicamente distanti tra loro saranno quindi mutuamente raggiungibili mantenendo il loro piano di indirizzamento privato. La VPN costituisce un Tunnel in cui i pacchetti tra reti private viaggiano, opportunamente modificati, tra due gateway correttamente configurati. Una VPN opera in modo trasparente agli host e quindi anche agli utenti. Quando una VPN offre dei Servizi di Sicurezza prende il nome di Secure Virtual Private Network (S‐VPN). Una S‐VPN ha lo scopo di instaurare un canale di comunicazione (tunnel) che realizzi una connessione sicura tra due entità di pari livello quali host e/o Security Gateway, secondo un determinato protocollo. Il protocollo che rappresenta lo standard de facto attuale è IKE/IPSec (definito dall’IETF nelle RFC da 4301 a 4309) [21], [16]. Un Security Gateway è un dispositivo di rete che implementa il protocollo di sicurezza IPSec (come da RFC 4301) [21]. In termini più specifici un Security Gateway è un dispositivo in grado di processare traffico di S‐VPN secondo lo standard IPSec, garantendo quindi i tipici servizi di sicurezza già visti in precedenza. I Security Gateway IPSec gestiscono le associazioni con altri dispositivi dello stesso tipo. Tali associazioni sono definite Security Association (cfr. par. 1.4.2). In tal modo sono forniti servizi di tipo S‐VPN in maniera trasparente rispetto all’utente.

1.3 INTERNET KEY EXCHANGE Internet Key Exchange (IKE) è il protocollo usato per inizializzare una Security Association (SA) nella suite di protocolli IPsec. IKE definisce un meccanismo per condividere delle chiavi di cifratura, basandosi a sua volta sul meccanismo Internet Security Association and Key Management Protocol (ISAKMP).



Pagina 16 di 189

IKE è standardizzato nelle RFC 2409 “The Internet Key Exchange (IKE)” e definito anche nelle RFC 2407, RFC 2408 e RFC 4306 (IKEv2) [8], [23], [22], [19].

1.3.1 Scambio delle Chiavi IKE è un protocollo di livello applicazione e utilizza il protocollo UDP come protocollo di trasporto. La porta su cui viene stabilita la connessione è la 500. Lʹobiettivo di IKE è stabilre uno shared session secret, ossia una chiave condivisa corrispondente alla sessione da instaurare. Per inizializzare lo shared secret IKE utilizza lo standard di key exchange Diffie‐Hellman, da cui vengono derivate le chiavi crittografiche che verranno utilizzate per la successiva comunicazione. L’IKE, utilizzando ISAKMP come schema di scambi, si articola in due fasi: ‐ Fase 1: i due interlocutori concordano su come proteggere le loro

successive interazioni, costituendo una Security Association ISAKMP, che permetterà loro di inviare nella fase successiva pacchetti cifrati ed autenticati;

‐ Fase 2: vengono utilizzate le SA IKE, negoziate nella fase precedente, per instaurare una o più associazioni di sicurezza IPSec con lo scambio delle relative chiavi.

Nel corso della prima fase i due interlocutori negoziano gli algoritmi di cifratura (DES, 3DES, AES) ed hashing (MD5, SHA‐1) da utilizzare. Mediante l’algoritmo di Diffie‐Hellman è generato il segreto condiviso dal quale sono ricavate le chiavi per tali algoritmi. In tal modo il peer con il quale viene instaurata la comunicazione è autenticato in modo forte. L’autenticazione forte prevede l’utilizzo di informazioni non scambiate direttamente tra i due peer. Per realizzare l’autenticazione forte si può ricorrere ad esempio ad una preshared key, ovvero ad un segreto precondiviso, oppure a dei meccanismi di firma numerica. [22] La fase 1 può avvenire con due modalità: ‐ Main Mode: essendo già stabilito il segreto condiviso nei primi quattro

pacchetti scambiati, nel quinto e sesto pacchetto fornisce protezione di identità in quanto l’ informazione viaggia cifrata. La negoziazione richiede in totale lo scambio di sei pacchetti;



Pagina 17 di 189

‐ Aggressive Mode: utilizza solamente tre pacchetti ed in caso di autenticazione con crittografia a chiave pubblica fornisce la protezione d’identità.

Figura 1.3: IKE – Fase 1: Main Mode e Aggressive Mode

Durante questa fase avviene la negoziazione dei protocolli con relativi algoritmi e chiavi, da utilizzare per fornire i servizi di sicurezza richiesti dalla SA IPSec. Nella fase 2 lo scambio può avvenire in un’unica modalità: il Quick Mode.

Figura 1.4: IKE – Fase 2: Quick Mode



Pagina 18 di 189

Le chiavi e le informazioni negoziate vengono quindi date allo stack IPSec. Ad esempio, si può trattare di una chiave AES, e informazioni che identificano gli endpoints IP e le porte che devono essere protette, così come i tipi di tunnel IPsec che devono essere creati. Lo stack IPsec, a sua volta, intercetta i pacchetti IP ed effettua la cifratura/decifratura degli stessi.

1.4 IP SECURITY IP Security (IPSec) è un protocollo standard operante al livello 3 della pila OSI, utilizzato per creare connessioni sicure su reti IP. La sicurezza è ottenuta attraverso la cifratura e lʹautenticazione dei pacchetti IP ed è quindi fornita a livello di rete. La capacità di fornire protezione a livello di rete rende questo protocollo trasparente al livello delle applicazioni. IPsec è parte integrante di IPv6, mentre un’estensione opzionale del protocollo IPv4. Il protocollo è definito negli RFC 2401 e RFC 2412 [2].

1.4.1 Modalità di funzionamento IPsec è una suite di protocolli formata da protocolli che implementano lo scambio delle chiavi per realizzare il flusso crittografato (IKE) e protocolli che forniscono la cifratura del flusso di dati tra cui: ‐ Authentication Header (AH): garantisce lʹautenticazione e lʹintegrità

del messaggio ma non offre la confidenzialità (protocollo IP 51); ‐ Encapsulating Security Payload (ESP): fornisce autenticazione,

confidenzialità e controllo di integrità del messaggio (protocollo IP 50). IPsec supporta due modalità di funzionamento: ‐ Transport mode: usato per la connessione host‐to‐host dagli end‐point

(non dai gateway). Nel Transport mode viene cifrato solo il payload dei datagram IP, ma non lʹheader, per cui mittente e destinazione restano in chiaro. Ogni host che vuole comunicare deve implementare IPsec;

‐ Tunnel mode: usato per la connessione gateway‐to‐gateway ed è utilizzato per realizzare le SVPN. Nel Tunnel mode viene cifrato tutto il pacchetto IP originale. L’intero pacchetto IP originale viene incapsulato in un nuovo pacchetto con una nuova intestazione, che



Pagina 19 di 189

reca come mittente e destinatario i security gateway. Viene aggiunto lʹheader IPsec, inoltre il mittente e il destinatario sono cifrati per cui non risultano visibili. Ogni host che vuole comunicare non deve implementare IPsec, ma devono implementarlo solo i gateway agli estremi della comunicazione. Lo svantaggio è che in tal modo si inseriscono punti di centralizzazione che diventano single point of failure.

Figura 1.5: IPSec – Tunnel Mode e Transport Mode

IPsec può essere utilizzato anche per connessioni tra gateway e host nella modalità transport.

1.4.2 Security Association Un concetto fondamentale sia per AH che per ESP è quello di Security Association (SA). Una SA è una relazione, fra due entità in comunicazione, che identifica particolari condizioni di sicurezza. Un’associazione di sicurezza è una relazione one‐way (unidirezionale) tra il mittente ed il destinatario. Quindi, durante la creazione della connessione le entità coinvolte creano e gestiscono una SA per ognuno dei versi della comunicazione, quindi due SA individuano un canale full‐duplex per uno scambio bidirezionale sicuro.



Pagina 20 di 189

Il concetto di Security Association è alla base del funzionamento di IPsec. Una SA è un ʺcontrattoʺ fra le due entità coinvolte nella comunicazione in cui vengono stabiliti i meccanismi di protezione e le chiavi da utilizzare durante il successivo trasferimento dei dati. Le entità coinvolte nella comunicazione sono denominate peer e possono essere Security Gateway o Host che implementano il protocollo stesso. Ogni SA è identificata univocamente dalla combinazione dellʹindirizzo del destinatario e di un determinato Security Parameter Index (SPI). Lo SPI è negoziato nel corso dell’inizializzazione della comunicazione e in combinazione con l’indirizzo IP di destinazione ed il protocollo di sicurezza, identifica univocamente l’associazione di sicurezza per questo datagramma. L’insieme dei valori SPI nell’intervallo da 1 a 255 sono riservati dalla IANA per usi futuri. Lo SPI è definito dalla stazione sorgente e nel caso di multicast dovrà essere lo stesso per tutte le stazioni del gruppo. Ogni implementazione di AH e di ESP deve supportare il concetto di Security Association, sebbene possa supportare anche ulteriori parametri come componenti di una SA. Nellʹambito di IPsec, le security association possono essere impostarle manualmente, ma tale procedura è sconsigliata in quanto può introdurre errori che indeboliscono il tunnel. Per stabilire le security association in modo automatico in IPSec è utilizzato il protocollo IKE. In particolare della creazione, gestione e distruzione delle SA si occupa l’Internet Security Association and Key Management Protocol (ISAKMP). L’ISAKMP combina i concetti di autenticazione, gestione delle chiavi e associazione di sicurezza per fornire sicurezza alle comunicazioni su Internet. Tale protocollo non è limitato ad alcuno specifico algoritmo di cifratura, tecnica di generazione di chiavi o meccanismo di sicurezza. L’ISAKMP scambia informazioni fra le entità che stanno negoziando e infine stabilisce un’associazione di sicurezza tra queste parti sulla base di un protocollo stabilito (ESP o AH). Prima il protocollo di scambio iniziale IKE permette ad un insieme di attributi base di essere accettati e condivisi fra le parti. Tali attributi forniranno sicurezza per le successive comunicazioni dell’ISAKMP. Dopo che sono stati accettati questi attributi di base, autenticate le entità e generate le chiavi, l’associazione di sicurezza stabilita può essere utilizzata per comunicazioni successive dall’entità che ha invocato l’ISAKMP.



Pagina 21 di 189

Le tecniche più importanti e sicure per scambiare chiavi di sessione e segreti condivisi fra più utenti sono basate sulla crittografia a chiave pubblica. Da notare che le chiavi crittografiche possono proteggere informazioni per un lungo periodo di tempo, ma è bene distruggerle dopo ogni uso e rigenerarle successivamente. Al fine di semplificare la gestione delle SA, viene utilizzato un apposito database detto SAD (Security Association Database), dove viene tenuta traccia delle SA attive in un dato istante su un Security Gateway. Una SA contiene le informazioni necessarie per stabilire in che modo il traffico deve essere protetto. È infatti costituita dai seguenti parametri: Gli indirizzi IP dei peer coinvolti nella comunicazione; Il protocollo che verrà utilizzato per il tunnel (AH o ESP); Le tecniche di cifratura utilizzate e le relative chiavi; SPI, Security Parameter Index (numero intero a 32 bit). La Security Policy (SP) si occupa invece di definire quale traffico passante per il Security Gateway deve essere protetto. Una SP è una regola che stabilisce che tipo di traffico deve essere instradato nel tunnel e quindi essere coperto da IPsec. Questo avviene tramite il riconoscimento del flusso di traffico a cui il pacchetto IP appartiene. Tale riconoscimento avviene mediante il confronto dell’intestazione di ogni singolo pacchetto con un selettore: per ogni pacchetto viene quindi deciso se debba essere scartato, lasciato passare in chiaro oppure elaborato tramite IPSec. Quando un Security Gateway riceve un pacchetto che soddisfa i criteri di filtraggio per l’elaborazione in IpSec, stabilisce un appropriato tunnel di sicurezza se non già presente e invia il pacchetto ricevuto attraverso tale tunnel verso l’entità destinataria. In modo analogo alle SA, le SP attive in un dato istante su un Security Gateway sono contenute in un SPD (Security Policy Database). La security policy contiene: Indirizzo sorgente e indirizzo destinazione del pacchetto. Tale informazione è già contenuta nella SA, ma non è ridondante. Infatti, questa informazione è necessaria, quando viene utilizzato il Tunnel mode. Il protocollo e la relativa porta da instradare nel tunnel. Questa opzione dipende dallʹimplementazione del protocollo e non è sempre prevista. Nel caso non sia disponibile, tutto il traffico prodotto viene veicolato nel tunnel. Un identificativo della SA da utilizzare per processare i dati.



Pagina 22 di 189

Quindi nei due database SAD e SPD sono mantenuti rispettivamente i criteri di selezione del traffico e le modalità di protezione dello stesso. Una volta stabilita la Security Association e la Security Policy, può cominciare la comunicazione in base al protocollo AH o il protocollo ESP. A tali protocolli verrà passato il parametro SPI, che permetterà di risalire alle tecniche crittografiche da utilizzare per la trasmissione.

1.4.3 Authentication Header LʹAuthentication Header (AH), è un protocollo che fa parte della suite IPsec, le cui finalità sono di garantire:

‐ Integrità. AH fornisce un controllo di integrità sul pacchetto; ‐ Autenticazione. AH verifica dellʹautenticità del mittente.

Inoltre AH fornisce rotezione contro i replay‐attack. AH non garantisce in alcun modo la confidenzialità e la protezione dallʹanalisi del traffico del messaggio. Lʹautenticità è garantita tramite funzioni di hash a chiave simmetrica, ossia tramite il meccanismo delle pre‐shared keys. Infatti, per poter comunicare, due entità devono condividere la medesima chiave. Tale chiave viene combinata con il messaggio originale e quindi viene calcolata la checksum tramite una funzione di hash crittografico (MD5 o SHA). Il messaggio e la checksum vengono poi inviati al peer remoto. Il peer remoto può leggere il messaggio, dato che è in chiaro, e combinalo con la chiave di cui è a conoscenza per calcolare la checksum. Se la checksum corrisponde a quella inviata, il messaggio è autentico e viene accettato altrimenti viene scartato in quanto è stato modificato in un modo non consentito. Il protocollo utilizzato per implementare l’autenticazione è tuttavia ancora in fase di definizione. Lʹalgoritmo MD5, da solo non fornisce il non ripudio. Il non ripudio può essere fornito da alcuni algoritmi di autenticazione (algoritmi asimmetrici) usati con lʹAH, ma non è necessariamente supportato da tutti gli algoritmi che possono essere usati con AH. Lʹuso di AH aumenta i costi dellʹIP processing nei sistemi condivisi e aumenta la latenza delle comunicazioni. Ciò è dovuto principalmente al calcolo dellʹautenticazione dei dati da parte del mittente e al calcolo dellʹautenticazione e al confronto dei dati di ogni datagramma IP contenente AH, da parte di ogni ricevente. AH fornisce una sicurezza maggiore di quella



Pagina 23 di 189

che esiste attualmente in Internet, e non influenza la portabilità e non aumenta significativamente i costi implementativi [4].

Formato del Pacchetto AH L’autenticazione del pacchetto è realizzata utilizzando l’Authentication Header che permette di fornire lʹautenticazione e il controllo di integrità (ma senza riservatezza) dei pacchetti IP. Lʹintestazione di autenticazione ha il formato descritto in figura:

8 bit 8 bit 8 bit 8 bit

Next Header Lunghezza Riservato SPI (Security Parameter Index)

Numero di Sequenza

Dati di Autenticazione

Figura 1.6: IPSec – Formato dellʹintestazioneʹAH

La spiegazione del significato dei vari campi dell’intestazione è riportato di seguito:

- Next Header: (8 bit) indica lʹintestazione successiva, e contiene gli stessi valori del campo omonimo nellʹintestazione principale di IPv6;

- Lunghezza: (Length, 8 bit) lunghezza dellʹintestazione di autenticazione, espressa in multipli di 32 bit;

- Riservato: (16 bit) deve essere posto a zero; - SPI (Security Parameter Index): (32 bit) indice di sicurezza che è

stabilito nella associazione di sicurezza durante l’inizializzazione della comunicazione sicura;

- Numero di Sequenza: (32 bit) contiene un contatore crescente. È il valore che indica la sequenza di invio del pacchetto. Tale valore è assegnato dall’host sorgente al momento della creazione del datagramma ed è incrementato ad ogni pacchetto inviato. Il mittente deve sempre trasmettere questo campo mentre il ricevente non ha bisogno di effettuare particolari azioni su di esso. Il contatore del mittente e del ricevente devono essere inizializzati a zero al momento della creazione di un’associazione di sicurezza (il primo pacchetto



Pagina 24 di 189

trasmesso utilizzando una certa SA avrà il Sequence Number pari a 1). Previene da replay‐attack;

- Dati di Autenticazione: Authentication Data (campo di lunghezza variabile, dipendente dalla funzione di autenticazione selezionata) contiene un valore di controllo di integrità (ICV, Integrity Check Value), di dimensione pari a un multiplo intero di 32 bit che può contenere un padding per allineare lʹintestazione a 64 bit. Tutti gli algoritmi di autenticazione devono provvedere questa capacità. Tale campo è opzionale ed è incluso solo se è stato selezionato un servizio di autenticazione per la SA in questione.

Modalità di incapsulamento AH supporta nativamente sia il Transport mode che il Tunnel mode: Modalità Trasporto. Questa modalità è utilizzabile solo per comunicazioni tra host singoli che supportino lʹautenticazione. Nel Transport Mode lʹAH fornisce protezione al datagram proveniente dal livello superiore (TCP, UDP, etc …) Il formato del datagramma con AH in Transport Mode è mostrato nella figura seguente (in giallo è indicato il pacchetto originale):

IP Header

AH Header

TCP Header

DATI

Figura 1.7: Formato del pacchetto con AH in Transport Mode

Modalità Tunnel. In questa modalità lʹAH fornisce protezione allʹintero datagramma IP. Il pacchetto IP originale viene incapsulato in un nuovo pacchetto IP, dopo essere stato elaborato da AH. LʹHeader IP originale è incapsulato ed è posto un Header IP esterno, per consentire il trasporto del pacchetto. Infatti, poiché l’Header IP contiene l’indirizzo destinazione, eventuali direttive di routing ed informazioni sulle opzioni hop‐by‐hop, non è possibile trasmettere semplicemente il pacchetto IP cifrato preceduto dall’Header AH, quindi, è necessario incapsulare l’intero blocco (Header AH più lʹintero pacchetto IP cifrato) con un nuovo Header IP che conterrà informazioni sufficienti per il routing ma non per l’analisi del traffico. Questa modalità può essere utilizzata sia per comunicazioni tra host singoli che con un gateway di sicurezza. Infatti, mentre la modalità trasporto si adatta bene a proteggere connessioni tra host che supportano l’AH, la modalità tunnel è



Pagina 25 di 189

utile per le configurazioni che includono un firewall o gateway di sicurezza che proteggono una rete privata da reti esterne. In quest’ultimo caso, la cifratura è necessaria solo tra un host esterno ed il gateway di sicurezza, oppure fra due gateway di sicurezza. Questo alleggerisce gli host della rete interna dal carico di lavoro della cifratura e semplifica anche il processo di distribuzione delle chiavi riducendo il numero delle chiavi richieste. Il formato del datagramma con AH in Tunnel Mode è mostrato nella figura seguente (in giallo è indicato il pacchetto originale):

IP Header Esterno

AH Header

IP Header

TCP Header

Dati

Figura 1.8: Formato del pacchetto con AH in Tunnel Mode

Un’alterazione del payload del messaggio originale (che viaggia in chiaro) verrebbe subito rilevata dal destinatario in quanto il pacchetto interno non sarebbe più autenticato (i dati di autenticazione contengono un hash crittografico dell’intero pacchetto). Il protocollo AH è progettato per proteggere lʹintero pacchetto IP inviato. Infatti, dal punto di vista della protezione, in entrambi i casi, i pacchetti sono autenticati completamente, ad eccezione dei campi variabili dell’intestazione IP (Type Of Service, flags, fragment offset, Time To Live, header checksum ed alcune delle opzioni). Questi campi, essendo modificabili dai nodi intermedi, variano durante la trasmissione e perciò non possono essere autenticati. Queste modifiche devono essere necessariamente consentite per esigenze di instradamento del pacchetto. Quindi i dati per lʹautenticazione vengono calcolati escludendo i campi dellʹHeader IP che variano durante il tragitto. Tali campi vengono inizializzati a zero sia dalla sorgente che dalla destinazione prima di calcolare la funzione di hash, necessaria per la protezione del pacchetto. Lʹesclusione di questi campi comunque non influenza la sicurezza. Il protocollo AH è incompatibile con le varie tecniche di NAT, infatti, poiché, in entrambe le modalità, vengono alterati i campi indirizzo nellʹheader IP, in ricezione la checksum fallisce.



Pagina 26 di 189

1.4.4 Encripted Security Payload L’ESP, Encripted Security Payload è un protocollo che fa parte della suite IPsec ed è progettato per fornire:

‐ Integrità. ESP fornisce un controllo di integrità sul pacchetto; ‐ Autenticazione. ESP verifica dellʹautenticità del mittente; ‐ Confidenzialità. ESP fornisce protezione dallʹanalisi del traffico del

messaggio. Inoltre ESP fornisce rotezione contro i replay‐attack. LʹESP, diversamente da AH, non è costituito da un unico header che precede le informazioni da proteggere, ma è costituito da tre blocchi che delimitano i dati protetti. I campi dei tre blocchi, insieme ai dati protetti, costituiscono lʹHeader ESP. Contrariamente ad AH, lʹheader IP non viene coperto dai controlli. Infatti, in ESP l’autenticazione non riguarda il contenuto dell’intestazione IP del pacchetto che viene trasmesso tra Security Gateway, ma solo il datagramma originale con l’aggiunta dello stesso ESP header. Il controllo di integrità e autenticità viene eseguito tramite HMAC (funzioni di hash). Lʹhash viene calcolato tramite una funzione di hash (MD5 o SHA1), utilizzando una chiave condivisa. Lʹhash ottenuto viene allegato al messaggio e inviato. In ricezione viene controllata lʹintegrità del messaggio. I pacchetti in uscita vengono incapsulati per intero all’interno del campo payload del pacchetto ESP, utilizzando se necessario anche un campo padding. Il risultato viene crittografato utilizzando la chiave, l’algoritmo crittografico e la modalità di applicazione dell’algoritmo indicati dalla rispettiva SA. Gli algoritmi di cifratura usati possono essere: Data Encryption Standard (DES), 3DES, AES e Blowfish [3]. ESP supporta sia il Tunnel mode che il Transport mode come per AH.

Formato del Pacchetto ESP Un pacchetto cifrato ha una struttura del tipo di quella mostrata in figura (in rosso sono indicati i dati cifrati):



Pagina 27 di 189

8 bit 8 bit 8 bit 8 bit

SPI (Security Parameter Index) Numero di Sequenza

Vettore di Inizializzazione

Carico (Payload)

Padding

Padding Lunghezza Padding

Tipo di carico

Dati di Autenticazione

Figura 1.9: IPSec – Formato del datagramma ESP

La spiegazione del significato dei vari campi del datagramma è riportato di seguito:

- SPI (Security Parameter Index): (32 bit) indice di sicurezza che è stabilito nella associazione di sicurezza durante l’inizializzazione della comunicazione sicura (questo campo è uguale a quello presente nell’Authentication Header);

- Numero di Sequenza: (32 bit) contiene un contatore crescente. È il valore che indica la sequenza di invio del pacchetto, previene da replay‐attack;

- Vettore di Inizializzazione: Se l’algoritmo di cifratura utilizzato per cifrare i dati richiede l’utilizzo di un vettore di inizializzazione (IV), questo può essere inglobato nel campo Payload Data. L’algoritmo di cifratura deve specificare la lunghezza di tale informazione. Ci sono due modi per utilizzare l’IV all’interno del campo Payload Data:

- Il ricevente considera l’IV come la parte iniziale del testo cifrato utilizzandolo nell’algoritmo direttamente;

- Il ricevente legge l’IV separatamente dal testo cifrato. In questo caso le specifiche dell’algoritmo devono indicare come effettuare l’allineamento del testo cifrato.

- Carico (Payload): (campo di lunghezza variabile) contiene i dati del pacchetto protetti da cifratura. Tale campo è obbligatorio.



Pagina 28 di 189

- Padding: (campo di lunghezza variabile tra 0 e 255 byte), è un campo di riempimento. Il Padding è richiesto da alcuni fattori:

- Alcuni codici di cifratura lavorano su blocchi di lunghezza fissa. Serve a far crescere la dimensione dei dati fino a divenire multiplo del blocco che lʹalgoritmo in uso riesce a gestire;

- Alcuni algoritmi di decifratura richiedono che il messaggio cifrato sia seguito da zeri;

- Può essere necessario per ragioni di allineamento dei campi successivi;

- Può essere utilizzato per allungare arbitrariamente il pacchetto, per confondere lʹanalisi del traffico.

- Lunghezza Padding: (8 bit) Pad Length indica il numero di byte di padding (presenti nel campo precedente). L’intervallo dei valori validi è da 0 a 255, dove il valore 0 indica che non ci sono byte di padding. Il campo pad length è obbligatorio;

- Tipo di carico: (8 bit) identifica il tipo di dati contenuto nel campo Payload data;

- Dati di Autenticazione: Authentication Data (campo di lunghezza variabile) Contiene i dati usati per autenticare il pacchetto.

Tutti i campi sono in chiaro fino al vettore di inizializzazione, il resto è crittografato. Se è richiesta anche l’autenticazione, la trasformazione crittografica deve essere effettuata senza comprendere il campo Authentication Data, quindi solo i campi di Payload, (l’eventuale) Padding, Lunghezza Padding e Next Header saranno cifrati. In caso di frammentazione lʹESP è processato prima della frammentazione e dopo il riassemblaggio.

Modalità di incapsulamento Essendo un protocollo per il trasferimento dati della suite IPsec, ESP supporta sia il Tunnel mode che il Transport mode: Modalità Trasporto. LʹESP header in questa modalità, è inserito nel pacchetto IP immediatamente prima dellʹheader del protocollo di livello di trasporto. In questo modo si risparmia banda di trasmissione perchè non ci sono header o



Pagina 29 di 189

opzioni IP cifrate. richieste. Il formato del datagramma con ESP in Trasport Mode è mostrato nella figura seguente (in arancione è indicata la parte di pacchetto che viene sottoposta a controllo di autenticità e integrità; in rosso sono indicate le zone di pacchetto che vengono protette anche tramite algoritmi crittografici):

IP Header

ESP Header

TCP Header

Dati ESP Trailer

ESP Auth

Figura 1.10: Formato del pacchetto con ESP in Transport Mode

Modalità Tunnel. Il pacchetto IP è contenuto nella parte cifrata dellʹESP e lʹintero ESP è contenuto in un pacchetto avente headers IP in chiaro. Questi header sono usati per instradare il pacchetto dalla sorgente alla destinazione. richieste. Il formato del datagramma con ESP in Tunnel Mode è mostrato nella figura seguente (in arancione è indicata la parte di pacchetto che viene sottoposta a controllo di autenticità e integrità; in rosso sono indicate le zone di pacchetto che vengono protette anche tramite algoritmi crittografici):

IP Header esterno

ESP Header

IP Header

TCP Header

Dati ESP Trailer

ESP Auth

Figura 1.11: Formato del pacchetto con ESP in Tunnel Mode

Lʹindirizzo IP più esterno non viene coperto dal controllo di integrità. Tale opzioni rende il protocollo ESP adatto ad essere utilizzato in alcuni tipi di NAT, in particolare in quelli statici. Tuttavia esistono soluzioni ad‐hoc per il funzionamento congiunto di IPsec e NAT come il NAT Traversal.

1.4.5 Network Address Translation Il NAT Network Address Translation è una tecnica utilizzata per il riutilizzo degli indirizzi IP. Questo protocollo viene implementato dai router di frontiera, connessi sia con la rete privata che con quella pubblica. Tale router ha almeno due indirizzi, uno privato, con il quale è riconosciuto all’interno della rete privata, e uno pubblico con il quale può essere raggiunto dalla rete pubblica. Il NAT modifica i pacchetti che della rete privata devono accedere alla rete pubblica. Tale modifica consiste nell’inserimento l’indirizzo pubblico del



Pagina 30 di 189

router in luogo dell’indirizzo privato dell’host sorgente nel campo Source IP Address dell’intestazione del pacchetto. In questo modo i pacchetti che dalla rete pubblica sono diretti all’host privato saranno destinati al router stesso che, tenendo memoria delle precedenti richieste, inoltrerà all’host ricevente i pacchetti ricevuti in risposta al flusso uscente. Risulta evidente che questa soluzione non permette a due reti private geograficamente distanti, connesse alla rete pubblica, di comunicare tra loro. Questo problema può essere superato in parte grazie all’utilizzo delle Virtual Private Network (VPN). Tuttavia gli host dietro un router (o un firewall) che effettua operazioni di NAT non godono di connettività end‐to‐end. Il NAT modifica degli header del pacchetto e ciò è in contrasto con IPsec che ha tra le sue funzionalità il controllo dellʹintegrità del pacchetto. In particolare il NAT è incompatibile con AH sia in tunnel mode che in transport mode, in quanto AH verifica lʹintegrità di tutto il pacchetto IP. L’ESP in Tunnel mode o in Transport mode non copre invece lʹheader IP con controlli, per cui risulta adatto nel caso in cui il NAT eseguito sia di tipo SNAT. Quindi la modifica apportata dal router deve coinvolgere solamente lʹheader IP e non anche la porta del livello superiore. Il NAT ha problemi di compatibilità anche con IKE e soprattutto in main mode. Il main mode usato congiuntamente al metodo delle preshared‐keys richiede lʹautenticazione degli host coinvolti nella comunicazione e tale autenticazione prevede un controllo sugli indirizzi IP. Lʹalterazione dellʹindirizzo da parte di un dispositivo che effettua il NAT provoca quindi il fallimento dellʹautenticazione. In questi casi, viene utilizzato il NAT‐Traversal (NAT‐T). Di seguito viene indicato il formato del pacchetto ESP in Tunnel Mode che subisce la modifica tramite NAT‐T (in arancione è indicata la parte di pacchetto che viene sottoposta a controllo di autenticità e integrità; in rosso sono indicate le zone di pacchetto che vengono protette anche tramite algoritmi crittografici; in verde sono indicati i campi di NAT‐T):

IP Header esterno

ESP Header

IP Header

TCP Header

Dati ESP Trailer

ESP Auth

IP Header esterno

UDP Header

NAT‐T Header

ESP Header

IP Header

TCP Header

Dati ESP Trailer

ESP Auth

Figura 1.12: Pacchetto ESP in Tunnel Mode con incapsulamento UDP



Pagina 31 di 189

I campi segnati in verde sono quelli relativi al NAT‐T. Questi campi vengono inseriti subito dopo lʹheader IP esterno, che non viene alterato. Non vengono alterati neanche i campi successivi. In ricezione è effettuata lʹoperazione inversa. In genere, nei dispositivi preposti alla gestione dei tunnel IPsec e nei client VPN, il NAT‐T non è abilitato di default ma deve essere impostato a mano. L’utilizzo del NAT è opzionale, infatti, durante la creazione della Security Association, i peer determinano se uno dei due subisce operazioni di NAT e solo in questo caso viene usato il NAT‐T. Questa operazione è effettuata durante la prima fase della negoziazione IKE. Nella prima fase del protocollo IKE, per mezzo di un pacchetto con un campo Vendor‐ID, che contiene un valore hash noto, i peer verificano che entrambe le entità coinvolte nella comunicazione siano in grado di supportare il NAT‐T. Una volta stabilito che entrambi i peer supportano il NAT‐T, vengono inviate delle frame ʺNAT‐Discoveryʺ (NAT‐D), in modo da verificare chi dei due o se entrambi i peer subiscano il NAT. Una volta effettuate teli verifiche, la comunicazione si sposta su una nuova coppia di porte UDP e lʹentità ʺnattataʺ comincia a inviare delle frame keepalive; queste frame servono a mantenere fisse le porte di comunicazione sul router e ad impedirgli di riassegnarle ad una nuova comunicazione.



Pagina 32 di 189

22 IIPPVV66 L’IPv4, Internet Protocol versione 4 venne standardizzato nel 1981 dallʹRFC 719. IPv4 è nato per creare un’interfaccia di trasmissione dei dati indipendente dal sottostante strato di collegamento (data link layer), che può essere realizzato con diverse tecnologie (Ethernet, Token Ring, FDDI, etc.). IPv4 dispone di uno spazio di indirizzamento di 32 bit, tale che si hanno: 2 ^ 32 = circa 4 miliardi di indirizzi diversi possibili. All’inizio degli anni ʹ90 ci fu una crescita vertiginosa del numero di macchine connesse ad Internet e, considerando che in quel momento si aveva la prospettiva (rivelatasi erronea grazie all’introduzione del protocollo NAT, Network Address Translation) che ogni singolo apparecchio elettronico sarebbe stato inserito direttamente allʹinterno della rete, si cominciò a temere che lo spazio degli indirizzi disponibili fosse a breve destinato ad esaurirsi. La prospettiva di incorrere nella carenza del numero di indirizzi disponibili fu anche motivata dalle modalità di suddivisione dello spazio di indirizzo nei due livelli rete/host e di utilizzo delle classi di indirizzamento. Infatti, nella sua evoluzione storica, il dispiegamento delle reti e lʹallocazione degli indirizzi siano stati inefficienti. Per sostituire lo schema classfull secondo il quale tutti gli indirizzi IP appartengono ad una specifica classe (classe A, B o C) e quindi migliorare gestione degli indirizzi di rete, nel 1993 è stato introdotto il CIDR (Classless Inter‐Domain Routing). Il CIDR è uno schema di indirizzamento in cui viene utilizzata una notazione per esprimere indirizzi del tipo: A.B.C.D/X, dove X indica il numero di bit (contati partendo da sinistra) che compongono il prefisso (o maschera) dell’indirizzo di rete. I rimanenti (32‐X) indicano gli host. Il CIDR che ha permesso di migliorare le prestazioni dellʹinstradamento IP grazie ad una più efficiente organizzazione delle tabelle di routing, ma non di eliminare le inefficienze che si erano formate nella distribuzione degli indirizzi IP. Infatti il ridispiegamento degli indirizzi comporta cambiamenti complessi a tutti i livelli e la riassegnazione di tutti gli indirizzi dei computer di ogni sottorete. Per questo motivo si pensò di progettare una nuova versione del protocollo IPv4 per risolvere il problema della scarsità del numero di indirizzi e per ottenere una maggiore flessibilità, sufficiente per garantire una prospettiva di utilizzo a lungo termine.



Pagina 33 di 189

Le funzioni e il formato dei pacchetti IPv6 sono specificate nelle seguenti RFC: ‐ RFC 2460: Internet Protocol, Version 6 (IPv6) Specification; ‐ RFC 3513: IP version 6 Addressing Architecture; ‐ RFC 3587: IPv6 Global UnicastAddress Format; ‐ RFC 3177: IAB/IESG Recommendations on IPv6 Address Allocations to Sites;

‐ RFC 2461: NeighborDiscoveryforIP version6 (IPv6); ‐ RFC 2462: IPv6 statelessaddress autoconfiguration; ‐ RFC 2893: Transition mechanism forIPv6 hosts and routers [15]; ‐ RFC 3056: Connection of IPv6 domains via IPv4 clouds [7]; ‐ RFC 3315: Dynamic Host Configuration Protocol for IPv6 (DHCPv6).

2.1 PRINCIPALI CARATTERISTICHE DI IPV6 Il protocollo IPv6 nasce come evoluzione di IPv4 per soddisfare la necessità di un nuovo schema di indirizzamento che rispondesse alle seguenti necessità: Ampliare lo spazio di indirizzamento globale disponibile: indirizzi a 128 bit (invece che a 32 bit di IPv4); Organizzazione gerarchica più flessibile: indirizzamento gerarchico basato sul concetto di prefisso. IPv6 è in grado di supportare una gerarchia con più livelli e un numero di nodi indirizzabili molto maggiore; Configurazione automatica tramite un meccanismo integrato di autoconfigurazione delle interfacce di rete; Introduzione di un nuovo tipo di indirizzamento: lʹanycast, che si aggiunge agli usuali unicast e multicast; Semplificazione del formato dellʹintestazione dei pacchetti, in modo da contenere lʹaumento delle dimensioni dovuto ai nuovi indirizzi. Vengono eliminati o resi opzionali alcuni campi di IPv4: Semplificazione della struttura generale dell’header; Creazione di header di lunghezza fissa; Diversa modalità di codifica del campo “Options”; Eliminazione dei campi Checksum e dei campi dedicati alla frammentazione. Supporto per le opzioni migliorato. In tal modo è garantita una trasmissione più efficiente e la flessibilità necessaria per introdurne di nuove in futuro; Possibilità di identificazione dei flussi dei pacchetti tramite una Flowlabel. È quindi supportata la qualità di servizio (QoS) che permette di identificare



Pagina 34 di 189

gruppi di dati per i quali si può provvedere un trattamento preferenziale (ad esempio per applicazioni multimediali e “real‐time” che richiedono maggiore controllo sulla stabilità della banda di trasmissione, sui ritardi o il jitter del flusso di pacchetti); Integrazione con l’architettura IPSec. Lʹintestazione del pacchetto usata dal protocollo IPv6 è mostrata nella figura seguente: Versione Priorità Etichetta di flusso Lunghezza dati Prossimo Header TTL

Indirizzo Sorgente (128 bit)

Indirizzo Destinazione (128 bit)

Figura 2.1: Intestazione di IPv6


- Versione: (Version, 4 bit) versione del protocollo, è possibile la coesistenza di più versioni di IP;

- Priorità: (Traffic Class, 8 bit) stabilisce la classe di servizio e la priorità del pacchetto ed è compatibile con la specifica del campo DSCP dell’architettura Diffserv;

- Etichetta di flusso: (Flowlabel, 20 bit) identifica, insieme al campo Source Address, un particolare flusso di pacchetti, consente di instradare i datagrammi in hardware e l’applicazione delle procedure di reservation delle risorse per traffico con qualità di servizio garantita;

- Lunghezza dati: (Payload Length, 16 bit) lunghezza in byte del datagramma IP (escluso l’header), normalmente la lunghezza massima del payloadè 65.535 byte, ma se la lunghezza del pacchetto è maggiore di 64 K il suo valore è “0” e l’opzione “Jumbo Payload” indica la lunghezza effettiva;



Pagina 35 di 189

- Prossimo Header: (Next Header, 8 bit) contiene il codice che identifica l’header che segue nel pacchetto (ad esempio IP, TCP, UDP, ESP, AH …);

- TTL: (Hop Limit, 8 bit) numero massimo di tratte di rete che il pacchetto può attraversare, ogni router decrementa di una unità tale campo. Se il contatore si azzera prima che la destinazione sia raggiunta, il datagramma è scartato. Evita gli effetti di eventuali loop in rete e può essere utilizzato per effettuare delle ricerche di host in rete a distanza prefissata;

- Indirizzo Sorgente: (Source Address, 128 bit) indica l’indirizzo IP dell’host sorgente;

- Indirizzo Destinazione: (Destination Address, 128 bit) indica l’indirizzo IP dell’host di destinazione.

Per confronto di seguito è riportata anche la figura che mostra il formato dellʹintestazione del pacchetto usata dal protocollo IPv4:

Versione Lunghezza header Tipo di servizio Lunghezza totale (in Bytes)

Identificazione O D F M F Offset

TTL Protocollo Checksum Indirizzo Sorgente (32 bit)

Indirizzo Destinazione (32 bit) Opzioni (se presenti)

Figura 2.2: Intestazione di IPv4


- Versione: (Version, 4 bit) versione del protocollo; - Lunghezza header: (Header Length, 4 bit) lunghezza dellʹintestazione,

espressa in multipli di 32 bit; - Tipo di servizio: (Type Of Service, 8 bit). Consiste in:

- 3 bit di precedenza; - 1 bit non usato e posto a “0”; - 4 bit che identificano il tipo di servizio richiesto, uno solo dei

quali può essere posto a “1”.



Pagina 36 di 189

- Lunghezza totale: (Total Length, 16 bit) lunghezza totale, indica la dimensione del pacchetto IP in byte;

- Identificazione: (Identification, 16 bit) campo di identificazione del pacchetto. Il valore è assegnato alla creazione ed è aumentato di uno allʹorigine della trasmissione di ciascun pacchetto ma resta lo stesso per i pacchetti frammentati;

- Flag: (3 bit). Sono presenti 3 campi di 1 bit ciascuno che indicano la frammentazione: ‐ O: indica se un pacchetto è frammentato; ‐ D F: indica se ci sono ulteriori frammenti; ‐ M F: indica se il pacchetto non può essere frammentato.

- Offset (del frammento): (Fragmentation Offset, 13 bit) indica la posizione del frammento rispetto al pacchetto originale;

- TTL: (Time To Live, 16 bit) numero massimo di tratte di rete che il pacchetto può attraversare (ha lo stesso significato di Hop Limit);

- Protocollo: (Protocol, 8 bit) identifica il tipo di pacchetto che segue lʹintestazione di IPv4;

- Checksum: (Header Checksum, 16 bit) checksum dell’intestazione, che serve da controllo per eventuali errori presenti nell’header;

- Indirizzo Sorgente: (Source Address, 32 bit) indica l’indirizzo IP dell’host sorgente;

- Indirizzo Destinazione: (Destination Address, 32 bit) indica l’indirizzo IP dell’host di destinazione.

- Opzioni: altre opzioni eventualmente presenti. Lʹintestazione di IPv6 diventa di dimensione fissa, pari a 40 byte, invece per IPv4 si ha una dimensione (minima, in assenza di opzioni) di 20 byte. Quindi si ha un raddoppiamento della lunghezza complessiva dell’header, nonostante lo spazio destinato agli indirizzi sia invece quadruplicato. Ciò è dovuto ad una notevole semplificazione che ha ridotto il numero complessivo dei campi da 12 a 8. Uno dei criteri principali nella progettazione di IPv6 è stato quello di fare in modo di ridurre al minimo il tempo di processamento dei pacchetti da parte dei router. Rispetto ai campi dellʹintestazione di IPv4, IPv6 mostra le seguenti principali differenze:



Pagina 37 di 189

Il campo Header Length è stato eliminato. Infatti anche il campo relativo alle opzioni è stato eliminato dallʹintestazione che ha così dimensione fissa; Lʹintestazione è multipla di 64 bit e la somma dei campi degli indirizzi è di 64 bit, questo rende più veloce l’elaborazione da parte di computer con processori a 64 bit; I campi per gestire la frammentazione sono stati eliminati. Questo è dovuto al fatto che la frammentazione è unʹeccezione nel flusso regolare dei pacchetti che in ogni caso non deve rallentare il processamento dei pacchetti. Il campo Checksum è stato eliminato. Infatti tutti i protocolli di livello superiore (TCP, UDP, ICMPv6 …) hanno un loro campo di checksum che include anche i campi del livello inferiore. Inoltre il checksum esiste anche per gran parte protocolli di livello inferiore. In questo modo è stato ridotto il tempo di processamento, dato che i router non hanno più la necessità di ricalcolare il checksum ad ogni transito del pacchetto. Il campo Type Of Service è stato eliminato e una parte delle funzionalità ad esso delegate sono state implementate nel campo Priorità (contiene i bit di precedenza del campo Type Of Service). Il campo Flow Label è stato introdotto ex‐novo in IPv6 ed è usato insieme al campo Priority per implementare la gestione della QoS (Qualità del Servizio). Questo campo permette, infatti, di identificare i pacchetti appartenenti ad un determinato flusso per i quali si deve provvedere un trattamento preferenziale (ad esempio con banda garantita). Ulteriori caratteristiche che diversificano il comportamento di IPv4 da quello di IPv6 sono le seguenti: La frammentazione dei pacchetti da parte dei router lungo il percorso non può più essere attuata. La frammentazione dei pacchetti troppo grandi può essere gestita solo ai capi della comunicazione; IPv6 necessita del supporto per il path MTU discovery, ovvero il protocollo per la selezione della massima lunghezza del pacchetto. Tale protocollo è opzionale, ma senza di esso non è possibile inviare tramite IPv6 pacchetti più larghi della dimensione minima di 576 byte; Il broadcasting in IPv6 non è previsto, per cui le applicazioni che utilizzano tale modalità di instradamento dovono essere implementate usando il multicasting. Il multicast diventa quindi obbligatorio (invece che opzionale); È stato introdotto un nuovo tipo di indirizzi: gli Anycast.



Pagina 38 di 189

Come per IPv4 gli indirizzi identificano un singolo indirizzo (unicast) oppure un gruppo di indirizzi (multicast e anycast). Gli indirizzi unicast e multicast hanno le stesse caratteristiche che in IPv4. Gli indirizzi unicast identificano una singola interfaccia, gli indirizzi multicast identificano un gruppo di interfacce tale che un pacchetto mandato a uno di questi indirizzi viene inviato a tutte le interfacce del gruppo, mentre gli indirizzi anycast identificano un gruppo di interfacce tale che un pacchetto mandato a uno di questi indirizzi viene inviato alla più vicina (nel senso di distanza di routing) delle interfacce del gruppo.

2.2 LE OPZIONI IPv6 ha completamente cambiato il trattamento delle opzioni rispetto a IPv4. Infatti i campi relativi alle opzioni sono stati tolti dallʹintestazione del pacchetto e posti in apposito spazio denominato Extension Header (EH) posto tra l’header e lʹintestazione del protocollo di trasporto (payload del pacchetto IPv6). Il formato del datagramma IPv6 è mostrata nella figura seguente:

Header (40 bytes)

Extension Headers (Opzionale)

PayloadData (65.535 bytes massimo)

Figura 2.3: Datagramma IPv6

La spiegazione del contenuto dei campi è riportato di seguito: ‐ Header: contiene le informazioni comuni a tutti i datagrammi; ‐ Extension Headers: contengono le opzioni utilizzate dai router

intermedi e/o dall’host di destinazione; ‐ PayloadData: contiene i bit informativi elaborati dall’host di

destinazione. Per aumentare la velocità di processamento ciascuna estensione deve avere una lunghezza multipla di 8 byte per mantenere lʹallineamento a 64 bit.



Pagina 39 di 189

Poiché la maggior parte di queste estensioni non sono esaminate dai router durante lʹinstradamento e la trasmissione dei pacchetti, ma solo allʹarrivo alla destinazione, questa scelta ha consentito un miglioramento delle prestazioni rispetto a IPv4, dove invece la presenza di unʹopzione comportava lʹesame di tutte quante. Un secondo miglioramento rispetto a IPv4 è dato dal fatto che le opzioni possono essere di lunghezza arbitraria e non limitate a 40 byte. Questo, insieme alla modalità di trattamento delle stesse, consente di utilizzarle per scopi di sicurezza quali lʹautenticazione. Questo non sarebbe stato possibile da realizzare con la struttura del datagramma IPv4. Al momento sono definiti 6 tipi di Extension Headers, e sono i seguenti:

Next Header Extension Headers (EH) 0 Hop‐By‐Hop Options Header 43 Routing Header 44 Fragment Header 51 Authentication Header

50 Encapsulation Security Payload Header

60 Destination Options Header Tabella 2.2 – Tipi di Extension Headers IPv6

Il significato di ciascun tipo di Extension Header è riportato di seguito:

Hop‐By‐Hop Header: deve seguire immediatamente lʹintestazione principale. Indica le opzioni che devono essere processate ad ogni passaggio da un router, tra cui quella relativa al Jumbo Payload che segnala la presenza di un pacchetto di dati di dimensione superiore a 65535 byte;

Routing Header: definisce una Source Route (come l’opzione analoga in IPv4) ovvero una lista di indirizzi IP di nodi per i quali il pacchetto deve passare;

Fragment Header: è generato automaticamente, quando un host frammenta un pacchetto ed è processato alla destinazione nel momento del riassembaggio dei frammenti.

Authentication Header: gestisce lʹautenticazione e il controllo di integrità dei pacchetti (documentato dallʹRFC 1826);



Pagina 40 di 189

Encapsulation Security Payload Header: gestisce la cifratura del contenuto trasmesso (documentato dallʹRFC 1827);

Destination options Header: opzioni che devono essere esaminate al nodo di destinazione, ma nessuna di queste al momento è definita.

La presenza delle opzioni è rilevata dal valore del campo Next Header. Tale campo indica il tipo di header successivo a quello di IPv6 che, in assenza di opzioni, sarà quindi lʹintestazione di un protocollo di trasporto di livello superiore (ICMP, TCP, UDP ecc…). Perciò, se non ci sono opzioni negli Extension Headers, il campo Next Header dell’intestazione di IPv6 assume lo stesso valore del campo protocol dell’intestazione di IPv4, altrimenti assume il valore dellʹopzione presente. La presenza degli Extension Headers permette di avere di più opzioni in successione prima del pacchetto del protocollo di trasporto.

2.3 INDIRIZZI IPV6 Lʹallocazione degli indirizzi deve avere una struttura tale da permettere la costruzione di gerarchie che consentano un instradamento rapido ed efficiente dei pacchetti e tale da ottenere flessibilità nel dispiegamento delle reti. Questo comporta una riduzione drastica dei numeri utilizzabili, che non comporta però nuovamente il problema dell’insufficienza di indirizzi, infatti, è stato calcolato che anche nella peggiore delle ipotesi IPv6 dovrebbe essere in grado di fornire più di un migliaio di indirizzi per ogni metro quadro della superficie terrestre.

2.3.1 Rappresentazione degli Indirizzi IPv6 Poiché IPv6 ha un numero di bit quadruplicato non è più possibile usare la notazione coi numeri decimali di IPv4 per rappresentare un indirizzo IP, per questo gli indirizzi di IPv6 sono in genere scritti come sequenze di otto numeri esadecimali di 4 cifre usando i due punti come separatore (ad esempio: 5f1b:df00:ce3e:e200:0020:0800:2078:e3e3). Dato che la notazione resta comunque poco pratica esistono delle abbreviazioni. Se uno o più gruppi di 4 caratteri dell’indirizzo è pari a “0000”, tali zeri possono essere scritti come un unico zero oppure omessi e al loro



Pagina 41 di 189

posto inserito due colonne di caratteri due punti di separazione (::). Ad esempio, le righe seguenti rappresentano diversi modi di scivere lo stesso indirizzo IPv6: 2001:0db8:0000:0000:0000:0000:1428:57ab 2001:0db8:0000:0000:0000::1428:57ab 2001:0db8:0:0:0:0:1428:57ab 2001:0db8:0:0::1428:57ab 2001:0db8::1428:57ab 2001:db8::1428:57ab In IPv6, il concetto di maschera di rete è stato semplificato e nei documenti RFC si parla piuttosto di prefisso di un indirizzo. Il prefisso viene indicato tramite un numero aggiunto alla fine dell’indirizzo IPv6, separato da una barra obliqua (/). Tale valore indica, analogamente ad IPv4, il numero di bit più siginificativi dell’indirizzo IPv6 che costituiscono la lunghezza del prefisso. Nell’esempio seguente il prefisso si estende per i primi 60 bit dell’indirizzo, ovvero per le prime 15 cifre esadecimali (caratteri in blu sottolineati): 2001:0db8:0000:0000:0000:0000:1428:57ab/60

2.3.2 Tipi di Indirizzi Rispetto ad IPv4, in IPv6 non esiste più il concetto di classe. Il tipo di indirizzo è indicato dai bit più significativi che costituiscono il format prefix. Nella tabella seguente sono riportati i valori di tali bit e il tipo di indirizzo corrispondente mostra (molti prefissi restano tuttora non assegnati).

Tipo di indirizzo Prefisso Provider‐based 001 Geografic‐based 100 Riservato per NSAP 0000 001 Riservato 0000 0000 Multicast 1111 1111 Unicast link‐local 1111 1110 10 Unicast site‐local 1111 1110 11

Tabella 2.3 – Classificazione degli indirizzi IPv6 in base ai bit più significativi



Pagina 42 di 189

Come si nota dalla tabella, questa architettura supporta lʹallocazione di indirizzi per i provider, per uso locale e per il multicast. Gran parte dello spazio di indirizzamento (più del 70%) è riservato per usi futuri.

Indirizzi Provider‐Based Gli indirizzi provider‐based sono gli indirizzi usati per le comunicazioni globali, questi sono definiti nellʹRFC 2073 [24] e sono gli equivalenti degli indirizzi di classe dalla A alla C di IPv4. Lʹautorità che presiede allʹallocazione di questi indirizzi è la IANA. Per evitare i problemi di crescita delle tabelle di instradamento e una procedura efficiente di allocazione la struttura di questi indirizzi è organizzata in maniera gerarchica.

Indirizzi Unicast Gli indirizzi ad uso locale sono indirizzi unicast che sono instradabili solo localmente (allʹinterno di un sito o di una sottorete), e possono avere unicità locale o globale. Questi indirizzi sono pensati per lʹuso allʹinterno di un sito per una comunicazione locale immediata, o durante le fasi di autoconfigurazione prima di avere un indirizzo globale. Ci sono due tipi di indirizzi: ‐ Link‐local: è usato per un singolo link, in genere per la configurazione

automatica dellʹindirizzo al bootstrap e per la ricerca dei vicini. Un pacchetto che abbia tale indirizzo come sorgente o destinazione non è ritrasmesso dai router;

‐ Site‐local: è usato per lʹindirizzamento allʹinterno di un sito che non necessita di un prefisso globale. Questi indirizzi non sono ritrasmessi dai router allʹesterno del sito stesso. In sostanza sono gli equivalenti degli indirizzi riservati per reti private definiti in IPv4.

Indirizzi Multicast Gli indirizzi multicast sono usati per inviare un pacchetto a un gruppo di interfacce; lʹindirizzo identifica uno specifico gruppo di multicast e il pacchetto viene inviato a tutte le interfacce di detto gruppo. Unʹinterfaccia



Pagina 43 di 189

può appartenere ad un numero qualunque di gruppi di multicast. Il prefisso di formato per tutti gli indirizzi multicast è FF, ad esso seguono i due campi il cui significato è il seguente: Flag: è un campo di 4 bit. I primi tre sono riservati e posti a zero, lʹultimo è: Zero se lʹindirizzo è permanente (cioè un indirizzo noto, assegnato dalla IANA); Uno se lʹindirizzo è transitorio. Scop: è un numero di quattro bit che indica il raggio di validità dellʹindirizzo. Lʹultimo campo identifica il gruppo di multicast, sia permanente che transitorio, allʹinterno del raggio di validità del medesimo. Alcuni indirizzi multicast sono predefiniti e già riservati per il funzionamento della rete. Lʹutilizzo del campo di scope e di questi indirizzi predefiniti serve a recuperare le funzionalità del broadcasting.

Indirizzi Anycast Gli indirizzi anycast sono indirizzi assegnati ad un gruppo di interfacce. Un pacchetto spedito a questo tipo di indirizzi è inviato al componente del gruppo più “vicino” in base alla distanza di instradamento calcolata dai router. Tali indirizzi sono allocati nello stesso spazio degli indirizzi unicast, usando uno dei formati disponibili, quindi questi due tipi di indirizzi sono indistinguibili tra loro. Quando un indirizzo unicast viene assegnato a più interfacce (diventa un anycast) l’host su cui risiede tale interfaccia deve essere configurato in modo specifico. Gli indirizzi anycast consentono ad un nodo sorgente di inviare i pacchetti ad una destinazione su un gruppo di possibili interfacce selezionate. La sorgente dei messaggi non deve scegliere lʹinterfaccia più vicina, tale funzione è realizzata dal sistema di instradamento (la sorgente non ha nessun controllo sulla selezione dell’interfaccia più vicina). Questi indirizzi pertanto possono essere usati per raggiungere insiemi di router connessi a una particolare sottorete, o che forniscono lʹaccesso a un certo sotto‐dominio. Gli indirizzi anycast sono quindi spesso usati per raggiungere il fornitore di un servizio più vicino, rispetto all’host sorgente e con calcolo della distanza in base all’instradamento.



Pagina 44 di 189

Indirizzi Riservati Alcuni indirizzi sono riservati per scopi speciali, in particolare per scopi di compatibilità come gli indirizzi IPv4 mappati su IPv6. Tali indirizzi sono unicast e sono usati per consentire ad applicazioni IPv6 di comunicare con host che supportano solo IPv4 (ad esempio gli indirizzi generati da un DNS quando lʹhost è IPv4). È necessario che lʹhost di origine supporti sia IPv4 che IPv6.

2.3.3 Indirizzi IPv6 con Indirizzi IPv4 Embedded I meccanismi di transizione da IPv4 a IPv6 includono metodi per inserire dinamicamente in tunnel pacchetti IPv6 e instradarli attraverso l’infrastruttura IPv4 (cfr. par. 2.7.3). Ai nodi IPv6 che effettuano tali funzioni sono assegnati speciali indirizzi Unicast IPv6 che possiedono un indirizzo IPv4 nei 32 bits meno significativi. Questi indirizzi sono chiamati IPv4‐compatible. Un esempio di questo indirizzo è il seguente: ::130.192.252.27 Un altro tipo di indirizzi IPv6 con un indirizzo IPv4 embedded sono chiamati IPv4‐mapped. Questo secondo tipo di indirizzi è usato per rappresentare l’indirizzo di un nodo solo IPv4 nel dominio IPv6. Un esempio di questo indirizzo è il seguente: ::FFFF:130.192.252.27

2.4 AUTOCONFIGURAZIONE Una delle caratteristiche principali di IPv6 è lʹautoconfigurazione. Il protocollo, infatti, fornisce la possibilità ad un nodo di effettuare il discovery automatico del proprio indirizzo e dei parametri necessari per potersi connettere a internet. Lʹautoconfigurazione utilizza gli indirizzi link‐local. Se il nodo supporta gli standard IEEE 802.3 (Ethernet) tramite opportuna scheda di rete, è garantita la presenza di un indirizzo fisico MAC unico a 48 bit, per cui il nodo può



Pagina 45 di 189

assumere automaticamente e senza pericoli di collisione lʹindirizzo link‐local: FE80:xxxx:xxxx:xxxx, dove xxxx:xxxx:xxxx è lʹindirizzo MAC della scheda di rete. Nel caso in cui non sia presente una scheda che supporta lo standard IEEE 802.3 allora il nodo assumerà ugualmente un indirizzo link‐local, ma, invece di utilizzare del MAC address, il valore del campo a 48 bit verrà generato in modo casuale (con una probabilità di collisione di 1 su 300 milioni). Per prevenire il rischio di collisioni tra indirizzi duplicati, il nodo invia un messaggio ICMP Solicitation allʹindirizzo scelto in modo casuale e attende un intervallo di tempo predefinito. In caso di risposta lʹindirizzo è dunque duplicato (esiste un altro dispositivo in rete che possiede già tale IP address) e il procedimento dovrà essere ripetuto tentando un nuovo indirizzo. Una volta che sia stato ottenuto un indirizzo link‐local valido diventa possibile per il nodo comunicare con la rete locale a cui è connesso. Sono previste due modalità di autoconfigurazione: Stateless oppure Stateful, descritte nelle seguenti sezioni.

2.4.1 Autoconfigurazione Stateless L’autoconfigurazione Stateless è la forma più semplice tra i due tipi di autoconfigurazione e può essere realizzata quando è possibile ricavare lʹindirizzo globale dal link‐local address cambiando semplicemente il prefisso all’indirizzo assegnato dal provider. La procedura di configurazione è la seguente: i nodi IPv6 allʹavvio devono aggregarsi ad un gruppo multicast programmando le interfacce per ricevere i messaggi dallʹindirizzo multicast del gruppo di appartenenza. Successivamente i router devono inviare un messaggio ICMP Router Solicitation a tutti i router locali usando come sorgente il proprio indirizzo link‐local. Ogni router risponderà con un messaggio ICMP Router Advertisement che fornisce il prefisso e la validità nel tempo del medesimo. Questo tipo di messaggio può essere trasmesso anche a intervalli regolari e contiene anche lʹinformazione che autorizza un nodo a costruire in modo automatico il proprio indirizzo.



Pagina 46 di 189

2.4.2 Autoconfigurazione Stateful Lʹautoconfigurazione Stateless è semplice ma presenta alcuni problemi: Lʹuso degli indirizzi delle schede di rete è molto inefficiente. Infatti, nel caso in cui ci siano esigenze di creare una gerarchia strutturata su parecchi livelli, possono non restare disponibili 48 bit per identificare lʹindirizzo del singolo host; Il livello di sicurezza di questa procedura è basso. Infatti, basta introdurre nella rete un host che può configurarsi in modo automatico per ottenere un accesso legale anche se non autorizzato. Per questi motivi è stata introdotta la modalità di autoconfigurazione Stateful. Tale procedura si basa su un server che offre una versione IPv6 del DHCP. Un apposito gruppo di indirizzi multicast è stato riservato per questo tipo di server. Il nodo può quindi interrogare tale server utilizzando il proprio lʹindirizzo link‐local e ricevere un indirizzo unicast globale.

2.5 GESTIONE DELLA QOS Il campo Flow Label può essere usato allʹorigine della comunicazione per etichettare quei pacchetti per i quali si vuole un trattamento speciale da parte dei router, come la garanzia di banda minima o del tempo minimo di instradamento/trasmissione. I router che non supportano questa funzionalità devono porre a zero il valore del campo flow label per i pacchetti da loro originanti e lasciarlo invece invariato per i pacchetti in transito. Un flusso è univocamente identificato dagli indirizzi di origine e destinazione e dall’etichetta di flusso diversa da zero, mentre il traffico normale deve avere lʹetichetta di flusso impostata a zero. Lʹetichetta di flusso è assegnata dal nodo di origine che assegna i valori in modo (pseudo) casuale nel range tra 1 e FFFFFF. Il campo di priorità consente di indicare il livello di precedenza di alcuni pacchetti rispetto all’intero flusso proveniente dalla stessa sorgente. I valori di questo campo sono divisi in due intervalli: Da 0 a 7 sono valori usati per specificare la priorità del traffico per il quale la sorgente provvede un controllo di congestione; Da 8 a 15 sono valori usati per i pacchetti che non hanno il controllo di congestione, come ad esempio i pacchetti “real‐time” che vengono inviati a ritmo costante.



Pagina 47 di 189

Per il traffico con controllo di congestione sono raccomandati i seguenti valori di priorità a seconda del tipo di applicazione:

Valore Tipo di traffico 0 Traffico generico 1 Traffico di riempimento (es. news) 2 Trasferimento dati non interattivo (es. e‐mail) 3 Riservato 4 Trasferimento dati interattivo (es. FTP, HTTP, NFS) 5 Riservato

Tabella 2.4 – Tipi di traffico e livelli di priorità IPv6

Per il traffico senza controllo di congestione la priorità più bassa deve essere usata per i pacchetti meno importanti, in modo che siano i primi ad essere scartati in caso di congestione.

2.6 SICUREZZA Con IPv4 per realizzare un meccanismo di autenticazione e riservatezza è necessario ricorrere al protocollo IPSec. Con IPv6 la sicurezza è integrata nello stesso protocollo. Infatti, come già accennato nel par. 2.2 (“Le Opzioni”), sono previste delle apposite estensioni poste nel campo relativo all’Extension Header del datagramma che possono essere usate per indicare il tipo di sicurezza fornito: - AH (Authentication Header): intestazione di sicurezza che garantisce

lʹautenticità del mittente del pacchetto; - ESP (Encrypted Security Payload): intestazione che indica che il carico è

cifrato. In tal modo è assicurato che solo il legittimo ricevente può leggere il pacchetto.

IPv6 separa autenticazione e riservatezza perchè mentre la prima può essere implementata senza problemi, la seconda deve invece sottostare a stringenti norme anti‐esportazione (soprattutto riguardanti gli Stati Uniti). IPv6 definisce quindi due header diversi in modo tale che questi due servizi di sicurezza possano essere usati separatamente, congiuntamente, o non utilizzati, dipendentemente dalle esigenze. Sia AH che ESP possono essere utilizzati in due modalità:



Pagina 48 di 189

‐ Transport Mode. Viene fornita protezione solo ai dati contenuti nel payload;

‐ Tunnel Mode. Viene fornita protezione allʹintero datagramma IP. Perché il meccanismo funzioni, gli host sorgente e destinazione devono usare una stessa chiave crittografica e gli stessi algoritmi. Lʹinsieme degli passaggi effettuati per concordare le chiavi di crittografia e gli algoritmi usati per la cifratura del flusso informativo tra le due terminazioni della comunicazione sicura prende il nome di associazione di sicurezza SA (cfr. par. 1.4.2). In modo simile a come funzionano i Security Gateway IPSec in IPv4, IPv6 implementa delle Virtual Tunnel Interface (VTI) IPSec per realizzare protezione Site‐To‐Site del traffico. I VTI permettono di stablire tunnel IPSec [10].

2.6.1 Authentication Header L’autenticazione del pacchetto è realizzata, come per IPv4, utilizzando l’Authentication Header che permette di fornire lʹautenticazione e il controllo di integrità (ma senza riservatezza) dei pacchetti IP. Lʹintestazione di autenticazione può sempre essere impiegata nelle due diverse modalità: Modalità Trasporto. In questo caso lʹintestazione di autenticazione è inserita dopo tutte le altre intestazioni di estensione tranne per la Destination Option che può comparire sia prima che dopo. Nel Transport Mode lʹAH fornisce protezione al datagram proveniente dal livello superiore (TCP, UDP, etc …) ed ad alcuni campi dellʹHeader di base di IPv6. I dati per lʹautenticazione vengono calcolati escludendo alcuni campi dellʹHeader di IPv6 che devono subire cambiamenti durante il tragitto. Il calcolo dell’autenticazione viene effettuato prima della frammentazione al sito sorgente e dopo il riassemblaggio al sito destinazione, quindi, i campi interessati alla frammentazione possono essere inclusi nel calcolo. Il formato del datagramma con AH in Transport Mode è mostrato nella figura seguente (in arancione è indicata la copertura dell’autenticazione);

IPv6 Header

AH Header

Destination Option

TCP Header

DATI

Figura 2.4: Formato del pacchetto IPv6 con AH in Transport Mode



Pagina 49 di 189

Modalità Tunnel. In questa modalità lʹAH fornisce protezione allʹintero datagramma IP, incapsulando lʹHeader di IPv6 e ponendo un Header IP esterno, per consentire il trasporto del pacchetto. Il formato del datagramma con AH in Tunnel Mode è mostrato nella figura seguente (in arancione è indicata la copertura dell’autenticazione);

IPv6 Header Esterno

AH Header

IP Header Interno

Datagramma IP

Figura 2.5: Formato del pacchetto IPv6 con AH in Tunnel Mode

2.6.2 Encripted Security Payload L’ESP, come per IPv4, è progettato per fornire integrità, autenticazione e confidenzialità ai datagrammi IP. Può proteggere lʹintero datagramma IP o il datagram del protocollo dello strato superiore (TCP, UDP, ICMP…). L’ESP è realizzato usando un’opzione che è sempre lʹultima delle intestazioni di estensione. A questa segue il carico del pacchetto cifrato. LʹESP, diversamente da AH, non è costituito da un unico header che precede le informazioni da proteggere, ma è costituito da tre blocchi che delimitano i dati protetti. I campi dei tre blocchi, insieme ai dati protetti, costituiscono lʹHeader ESP. Ci sono due modalità per usare ESP: ‐ Modalità Trasporto. LʹESP header in questa modalità, è inserito nel

pacchetto IP immediatamente prima dellʹheader del protocollo di livello di trasporto. In questo modo si risparmia banda di trasmissione perchè non ci sono header o opzioni IP cifrate;

‐ Modalità Tunnel. Il pacchetto IP è contenuto nella parte cifrata dellʹESP e lʹintero ESP è contenuto in un pacchetto avente headers IP in chiaro. Questi header sono usati per instradare il pacchetto dalla sorgente alla destinazione.

2.7 INTEROPERABILITÀ IPV6-IPV4 Il protocollo IPv4 è ormai radicato a tal punto nelle reti pubbliche di trasporto dati, da rendere impossibile un passaggio rapido ad IPv6. Al momento sta avendo luogo una graduale transizione a IPv6 di Internet, dove i due protocolli convivono [20].



Pagina 50 di 189

A questo proposito il gruppo di lavoro ngtrans della Internet Engineering Task Force (IETF) ha proposto delle strategie di migrazione, essenzialmente riconducibili a tre principali tipologie: ‐ Dual stack; ‐ Translation; ‐ Tunneling.

2.7.1 Dual stack Nel meccanismo Dual Stack i nodi di rete implementano due distinti stack che operano in parallelo, permettendo alle applicazioni IPv4 e IPv6 di utilizzare lo stack corrispondente. La discriminazione dei diversi flussi comunicativi in ingresso viene fatta sulla base del valore presente nei primi 4 bit del datagram IP (0100 per IPv4, 0110 per IPv6) mentre, per la spedizione, ci si basa sul formato dell’indirizzo di destinazione. Analogamente, la scelta dello stack appropriato per le risposte DNS ricevute viene fatta sulla base del tipo di record contenuto. Dual stack è una soluzione estremamente semplice e che non richiede alcuna modifica ai livelli applicativi ma che consente solamente ai due protocolli di convivere all’interno della stessa rete, senza però che questi possano interoperare tra loro. Infatti, host IPv4 possono cioè comunicare solo con altri host IPv4 e lo stesso vale anche per gli host IPv6.

Figura 2.6: Schema del Dual Stack v4/v6



Pagina 51 di 189

2.7.2 Translation Per consentire l’interoperabilità tra i diversi protocolli è necessario ricorrere ad un meccanismo di Translation, ovvero di conversione di un protocollo in un altro. Tale meccanismo opera attraverso la trasformazione dell’header e, eventualmente, del payload. La traduzione, che può avvenire a diversi livelli nello stack di rete (Network, Transport e anche Applicativo), molto spesso ha il difetto di introdurre perdite di informazioni. Infatti, in tutti quei casi in cui non esiste una corrispondenza biunivoca tra i campi dei due protocolli i valori possono essere persi o impostati a valori standard senza particolare significato. La traduzione di un datagram IPv6 in IPv4 comporta sicuramente la perdita, ad esempio, del valore di Flow_Label. In base al funzionamento, i meccanismi di traduzione possono essere distinti in stateless e stateful. ‐ Stateless: è un traduttore in grado di effettuare ogni singola conversione

indipendentemente dalle altre traduzioni precedentemente fatte; ‐ Stateful: è un traduttore che necessita di mantenere in memoria

informazioni sulle traduzioni effettuate in precedenza (ad esempio corrispondenze tra le due tipologie di indirizzi).

SIIT SIIT, acronimo di Stateless IP/ICMP Translation (RFC2765), è stato ideato per effettuare la conversione dei pacchetti IP e ICMP. L’algoritmo SIIT indica le modalità di traduzione bidirezionale delle testate IPv4 e IPv6 e dei messaggi ICMPv4 e ICMPv6. Questo meccanismo, su cui si basano diversi traduttori, ignora molte delle Extension Header di IPv6 e diverse opzioni di IPv4. Tuttavia, questo algoritmo, è stato progettato appositamente in modo da mantenere inalterato nel processo di traduzione il checksum di UDP e TCP calcolato utilizzando gli Pseudo‐Header.



Pagina 52 di 189

BIS/BIA Alcune tipologie di traduttori operano direttamente sugli end‐system, inserendosi sotto forma di modulo aggiuntivo all’interno dello stack TCP/IP. IETF ha proposto due diversi meccanismi, entrambi pensati per consentire ad applicazioni IPv4 di operare all’interno di reti IPv6. ‐ BIS, Bump‐in‐the‐Stack (RFC2767): è una soluzione che prevede un

modulo traduttore inserito tra il livello in grado di identificare i pacchetti di livello applicativo che attraversano lo stack TCP/IPv4 e di conseguenza tradurli prima di inoltrarli via IPv6;

‐ BIA, Bump‐in‐the‐API (RFC3338): permette alle applicazioni pensate per IPv4 di comunicare con host IPv6 ma, trovandosi ad un livello superiore rispetto a BIS, è in grado di intercettare direttamente le chiamate alle Socket API. Questo permette a BIA di evitare la traduzione di pacchetti IP e non è nemmeno necessaria la modifica del nucleo del sistema operativo.

Sia BIS che BIA utilizzano per il loro funzionamento due componenti comuni: un Name Resolver ed un Address Mapper. ‐ Name Resolver: ha il compito di effettuare richieste DNS per decidere se

il destinatario del datagram IP supporta solamente IPv6 (ovvero se la traduzione è effettivamente necessaria o meno);

‐ Address Mapper: il secondo si incarica invece di allocare temporaneamente un indirizzo IPv4 utilizzato dall’applicazione e associato all’interfaccia IPv6 destinataria.

Entrambi i meccanismi presentano tuttavia il grosso limite di non poter gestire (e quindi tradurre) eventuali indirizzi inseriti nei protocolli di livello applicativo.



Pagina 53 di 189

Figura 2.7: Schema delle Transition v4/v6 BIS e BIA

NAT‐PT Il NAT‐PT, Network Address Translation – Protocol Translation (RFC2766) è un traduttore IPv4/IPv6 stateful che basa il proprio funzionamento sull’algoritmo descritto da SIIT. Il NAT‐PT è un meccanismo di traduzione in grado di permettere ad uno o più nodi IPv6 di comunicare con host IPv4 in maniera analoga a quanto avviene in presenza di un Proxy, allocando temporaneamente per ciascuno di essi indirizzi IPv4 e tenendo traccia delle associazioni. Utilizzando inoltre appositi ALG (Application Level Gateway) NAT‐PT è in grado di effettuare la traduzione dei protocolli di livello applicativo (FTP, DNS etc..). Tuttavia, poiché questo meccanismo deve tenere traccia delle associazioni effettuate tra gli indirizzi (stateful), è necessario che tutti i datagram di una sessione vengano inoltrati attraverso il medesimo dispositivo NAT‐PT [11]. Ci sono le seguenti modalità di utilizzo del NAT‐PT (mutuamente esclusive):

Static NAT‐PT: utilizza regole di traduzione statiche per effettuare il mapping di un indirizzo IPv6 su un indirizzo IPv4. I nodi della rete IPv6 comunicano con quelli della rete IPv4 usando il mapping IPv6 degli indirizzi IPv4 configurati sul router che implementa il NAT‐PT. L’esempio di figura 2.8 (a) mostra un nodo IPv6‐only che comunica con un nodo IPv4‐only usando il NAT‐PT. Il dispositivo che realizza il NAT‐PT mappa l’indirizzo sorgente IPv6 del nodo di origine 2001:0db8:bbbb:1::1 nell’indirizzo IPv4 192.168.99.2. Il NAT‐PT realizza



Pagina 54 di 189

inoltre la mappatura dell’indirizzo IPv4 del nodo di destinazione 192.168.30.1 nell’indirizzo IPv6 2001:0db8::a. Quando i pacchetti con l’indirizzo IPv6 arrivano al router e devono raggiungere un indirizzo IPv4 vengono quindi tradotti tramite il NAT‐PT. Tale protocollo permette di effettuare anche la traduzione dell’indirizzo IPv4 in IPv6 in modo da garantire al nodo IPv4‐only di comunicare col nodo IPv6‐only. Si realizza quindi il canale di ritorno nell’esempio di figura 2.8 (a). Il NAT‐PT statico è utile quando applicazioni oppure server necessitano di avere accesso ad un indirizzo IPv4 stabile (come ad esempio nell’acceso ad un DNS Server IPv4 esterno).

Dynamic NAT‐PT: permette di effettuare mappature NAT‐PT multiple attraverso l’allocazione degli indirizzi a partire da un pool. Infatti il NAT‐PT è configurato con un pool di indirizzi IPv6 e/o IPv4. All’inizio della sessione NAT‐PT un indirizzo temporaneo è allocato dinamicamente da tale pool. Il numero di indirizzidisponibili nel pool determina il massimo numero di sessioni concorrenti instaurabili. Il dispositivo che realizza la funzionalità di NAT‐PT dinamico memorizza in una Dynamic State Table ogni mappatura realizzata tra indirizzi IPv4/IPv6. L’esempio di figura 2.8 (b) mostra come è realizzato il Dynamic NAT‐PT. Il nodo IPv6‐only comunica con un nodo IPv4‐only usando il NAT‐PT dinamico con un pool di indirizzi IPv4 che va dal 10.21.8.1 fino al 10.21.8.10. Il dispositivo che realizza il NAT‐PT è configurato con un’Access List (Prefix List, o Route Map) IPv6 per determinare quali pacchetti devono essere tradotti dal NAT‐PT. Il NAT‐PT dinamico richiede almeno una mappatura statica per realizzare la connessione verso il DNS Server IPv4. Dopo che la connessione IPv6‐IPv4 è stata stabilita, i pacchetti di reply dalla rete IPv4 alla rete IPv6 si avvantaggiano del mapping dinamico precedentemente stabilito per ri‐tradurre da IPv4 a IPv6 nel canale di ritorno.

Port Address Translation (PAT): è anche chiamato Overload. Permette ad un indirizzo IPv4 singolo di essere usato all’interno di sessioni multiple. L’indirizzo IPv4 è associato ad una serie di indirizzi IPv6 effettuando il multiplexing sul numero di porta. Il Port Address Translation può essere realizzato attraverso una specifica interfaccia o tramite un pool di indirizzi. L’esempio di figura 2.8 (c) mostra come è



Pagina 55 di 189

realizzato il PAT: indirizzi IPv6 multipli vengono associati ad una singola interfaccia IPv4.

Figura 2.8: Translation IPv6 ‐ IPv4 con NAT‐PT

2.7.3 Tunneling Il Tunneling come meccanismo di transizione è utilizzato per interconnettere tra loro host che risultano separati o che appartengono a reti tra loro incompatibili. Le techniche di Tunneling permettono l’uso di reti IPv4 per trasportare il traffico IPv6. I datagrammi IP sono quindi trasportati all’interno di altri



Pagina 56 di 189

datagrammi IP, in modo che il protocollo incapsulato veda quello incapsulante come un “link virtuale”. Di seguito è mostrato il formato del pacchetto IPv6 incapsulato all’interno di un pacchetto IPv4:

IPv4 Header IPv6 Header Payload

Figura 2.9: Formato del pacchetto IPv6 in IPv4

In base alle esigenze si possono utilizzare tunneling IPv4 in IPv6 o viceversa. Per poter costuire tunnel è necessario che Hosts e router supportino il Dual Stack, sebbene non sia vero il contrario [12]. Tali nodi IPv4/IPv6 possono usare i tunnel per instradare i pacchetti IPv6 attraverso reti IPv4, come mostrato nella figura seguente:

Figura 2.10: Tunneling IPv6‐in‐IPv4

Il tunneling può essere usato nelle seguenti modalità: ‐ Router‐to‐Router: consiste in dei router IPv6/IPv4 interconnessi da

un’infrastruttura IPv4 che possono immettere nel tunnel IPv6 pacchetti per comunicare tra loro (esempio di figura 2.11 a);

‐ Host‐to‐Router: consiste in degli host IPv6/IPv4 che possono immettere nel tunnel IPv6 pacchetti verso un router IPv6/IPv4 intermedio che può essere raggiunto attraverso un’infrastruttura IPv4 (esempio di figura 2.11 b);

‐ Host‐to‐Router: consiste in dei router IPv6/IPv4 che possono immettere nel tunnel IPv6 pacchetti verso un host IPv6/IPv4 che può essere raggiunto attraverso un’infrastruttura IPv4 (esempio di figura 2.11 c);



Pagina 57 di 189

‐ Host‐to‐host: consiste in degli host IPv6/IPv4 interconnessi da un’infrastruttura IPv4 che possono immettere nel tunnel IPv6 pacchetti per comunicare tra loro (esempio di figura 2.11 d).

Figura 2.11: Tipi di Tunneling IPv6‐IPv4

Ci sono diversi meccanismi di tunneling utilizzabili:

Manually configured: - Manual Tunnel (6in4) (RFC 2893) [15];

Semi‐automated: - Tunnel broker (RFC3053) [13].

Automatic: - Compatible IPv4 (RFC 2529): Deprecated [6]; - 6over4: Deprecated; - ISATAP (RFC4214) [25]; - Teredo (RFC4380) [18]; - 6to4 (RFC 3056, RFC3068) [7], [17].



Pagina 58 di 189

Manual Tunnel Il meccanismo di Manual Tunnel utilizza un incapsulamento di datagram IPv6 in IPv4 anche noto come 6in4 (RFC 2893) [15]. Un operatore configura una connessione punto‐punto virtuale IPv6 tra i due end‐point del tunnel. Tunnel configurati manualmente necessitano di: Dual stack end points: entrambi gli estremi del tunnel devono essere dotati di doppio stack); Entrambi gli indirizzi, IPv4 e IPv6 devono essere configurati agli estremi del tunnel. La figura 2.12 rappresenta un’architettura in cui è implementato il Manual Tunnel IPv6 in IPv4. Le configurazioni dei router sono prese come esempio da un famoso vendor di dispositivi di rete (Cisco Systems) [14].

Figura 2.12: Manual Tunnel IPv6‐in‐IPv4

Gli estremi del tunnel in questo caso sono intesi come dispositivi di routing (e.g. router, security gateway, switch ly3 …). I tunnel creati sono del tipo: Protocol 41. Tali tunnel permettono la connettività tramite l’incapsulamento del pacchetto IPv6 direttamente dentro il pacchetto IPv4 nel quale il Protocol Field è impostato al valore 41, ovvero IPv6. Il tunneling configurato manualmente è di solito più deterministico e la diagnosi di eventuali problemi risulta più semplice rispetto agli automatic tunnel.



Pagina 59 di 189

Tunnel Broker Un Tunnel Broker (RFC3053) [13] è un servizio automatizzato per l’attivazione di tunnel IPv6 nelle reti esistenti. Tale meccanismo fornisce network tunnels che permettono l’instradamento del pacchetto IPv6 nella rete, ed è simile ai Manual Tunnel. Anche in questo caso i tunnel creati sono del tipo Protocol 41.

Compatible IPv4 Il meccanismo di Compatibile IPv4 (RFC 2893) [15] utilizza indirizzi IPv6 compatibili con indirizzi IPv4 per la realizazione del tunnel in modo automatico (cfr. par 2.3.3 “Indirizzi IPv6 con Indirizzi IPv4 Embedded”). Tale modalità risulta attualmente deprecata, quindi la sua implementazione è sconsigliata.

Figura 2.13: Compatible IPv4 Tunnel

6over4 6over4 (RFC2529) [6] è un meccanismo di tunneling anche noto come Virtual Ethernet poiché in grado di mettere in comunicazione tra loro via tunneling più host IPv6 Dual Stack isolati connessi sulla stessa rete IPv4 multicast. Con 6over4 i nodi IPv6 risultano connessi ad unʹunica Ethernet virtuale, basata su IPv4 e identificata da un indirizzo IPv4 multicast. IPv6 si appoggia quindi su IPv4 per svolgere le sue funzioni utilizzando gli indirizzi del protocollo v4 sottostante in sostituzione dei MAC_Address. 6over4 definisce un metodo per la generazione degli indirizzi IPv6 link‐local a partire da un indirizzo IPv4 e per effettuare il Neighbor Discovery su IPv4. La generazione degli indirizzi IPv6 link‐local è effettuata come segue:



Pagina 60 di 189

L’indirizzo inizia con il prefisso: fe80:0000:0000:0000:0000:0000: I 32 bits di ordine più basso, possono essere quelli dell’indirizzo IPv4 dell’host. Ad esempio, l’host 192.0.2.142 avrà un indirizzo IPv6 link‐local: fe80:0000:0000:0000:0000:0000:c000:028e (192.0.2.142 corrisponde a c000028e nella notazione esadecimale) Per effettuare il Neighbor Discovery, è necessario utilizzare il multicast. Ogni pacchetto IPv6 multicast è incapsulato in un pacchetto IPv4 multicast con destinazione 239.192.x.y, dove x e y sono rispettivamente il penultimo e l’ultimo byte dell’indirizzo IPv6 multicast. Dato l’indirizzo link‐local e multicast, un host può usare ICMPv6 per scoprire i neighbor e router, ed effettuare la Stateless Autoconfiguration (cfr. par. 2.4.1). 6over4 si appoggia quindi al multicast IPv4, che attualmente non risulta ampiamente supportato dall’infrastruttura di rete IPv4. L’utilizzo di 6over4 risulta quindi limitato e attualmente deprecato. La sua implementazione è sconsigliata.

ISATAP ISATAP (RFC4214) [25] ovvero Intra‐Site Automatic Tunnel Addressing Protocol è un meccanismo di tunneling simile a 6over4 ma che non si appoggia quindi al multicast IPv4. Infatti, usa IPv4 come un Nonbroadcast Multiple Access Network ‐ Data Link Layer virtuale, ovvero si appoggia su IPv4 come fosse l’infrastruttura di livello 2 ad accesso multiplo dove i dati sono trasmessi direttamente tra gli host attraverso un circuito virtuale. La generazione degli indirizzi IPv6 link‐local è effettuata come segue: L’indirizzo inizia con il prefisso (che si distingue da quello di 6over4 con i caratteri in blu): fe80:0000:0000:0000:0000:5efe: I 32 bits di ordine più basso, possono essere quelli dell’indirizzo IPv4 dell’host. Ad esempio, l’host 192.0.2.142 avrà un indirizzo IPv6 link‐local: fe80:0000:0000:0000:0000:5efe:c000:028e (192.0.2.142 corrisponde a c000028e nella notazione esadecimale) Poiché ISATAP non utilizzare il multicast, effettuare il Neighbor Discovery è più complesso rispetto a 6over4. Gli host ISATAP vengono configurati con



Pagina 61 di 189

una Potential Routers List (PRL) ovvero una lista di Neighbor potenziali. Tali router vengono sondati dall’invio di un messaggio ICMPv6 Router Discovery, per determinare quale di questi è attivo. ISATAP è un meccanismo comlesso e il suo utilizzo di risulta attualmente limitato sebbene implementato in Microsoft Windows XP, Windows Mobile ed alcune versioni di Cisco IOS [14].

Teredo Teredo (RFC4380) [18] è un protocollo di tunneling designato per garantire connettività IPv6 ai nodi che sono locati dietro dispositivi NAT IPv6. Teredo definisce una modalità di incapsulamento dei pacchetti IPv6 all’interno di datagrammi UDP IPv4 che possono essere instradati attraverso dispositivi NAT e attraverso la rete IPv4. Teredo svolge le seguenti funzioni: Diagnosi della connettività UDP over IPv4 (UDPv4) e del tipo di NAT presente; Assegnamento di un indirizzo IPv6 unico globalmente ruotabile ad ogni host che lo usa. Ad ogni client Teredo è assegnato quindi un indirizzo pubblico IPv6 costruito come segue: Bit da 0 a 31 sono impostati col prefisso Teredo (2001:0000::/32); Bit da 32 a 63 incapsulano l’indirizzo primario IPv4 del Server Teredo che è usato; Bit da 64 a 79 possono essere usati per definire alcuni flag. Attualmente solo il bit più significativo è usato: Flag=1 se il client Teredo è locato dietro un dispositivo NAT; Flag=0 altrimenti. Per Microsoft Vista sono usati più bit. In tali implementazioni, il formato di questi 16 bit è: CRAAAAUG AAAAAAAA, dove: Il Bit C è il flag che resta usato come descritto sopra; Il 12 Bit A sono scelti in modo random dal client Teredo per introdurre protezione addizionale per il nodo Teredo contro attacchi basati su IPv6. Bit da 80 a 95 contengono il numero di porta UDP “offuscato” a valle del NAT. Questo numero di porta è mappato sul client Teredo con tutti i bit invertiti.



Pagina 62 di 189

Bit da 96 a 127 contengono l’indirizzo IPv4 “offuscato” a valle del NAT. Questo è l’indirizzo publicco IPv4 di NAT con tutti i bit invertiti. Incapsulamento dei pacchetti IPv6 all’interno di datagrammi UDPv4 per la transmissione attraverso una rete IPv4; Instradamento del traffico tra host Teredo e host IPv6 nativi (o comunque non‐Teredo). Come esempio l’indirizzo IPv6: 2001:0000:4136:e378:8000:63bf:3fff:fdd2 si riferisce ad un client Teredo: Con un indirizzo del Server Teredo: 65.54.227.120 (4136e378 in esadecimale); Locato dietro ad un dispositivo NAT, infatti il bit numero 64 (8) è impostato; Con la porta 40000 UDP mappata dal NAT (in esadecimale: 63bf XOR ffff equivale a 9c40, ovvero al numero decimale 40000); Con un indirizzo IPv4 pubblico di NAT 192.0.2.45 (3ffffdd2 XOR ffffffff equivale a c000022d, ovvero l’indirizzo 192.0.2.45). I limiti di Teredo sono che non risulta compatibile con tutti i tipi di NAT.

6to4 6to4 (RFC 3056, RFC3068) [7] [17] è la tecnica raccomandata per il tunneling automatico che utilizza l’incapsulamento di tipo Protocol 41. 6to4 è un meccanismo che permette a reti IPv6 di comunicare tra loro attraverso una dorsale IPv4 senza la necessità di alcuna configurazione esplicita. 6to4 svolge le seguenti funzioni: Assegna un blocco di indirizzi IPv6 ad ogni host o rete che ha un indirizzo IPv4 globale; Incapsula i pacchetti IPv6 dentro i pacchetti IPv4 per la transmissione nella rete IPv4; Instrada il traffico tra nodi 6to4 e le reti native IPv6. Ciascuna delle reti interessate viene indirizzata attraverso speciali prefissi globali IPv6 appositamente riservati, identificati da un prefisso di 48 bit ottenuto concatenando ‘2002’ con i 32 bit dell’indirizzo IPv4 del router di collegamento alla dorsale (es. per l’indirizzo 207.142.131.202 si ha



Pagina 63 di 189

l’indirizzo 6to4: 2002:CF8E:83CA::/48). Gli endpoint del tunnel sono quindi determinati usando tali indirizzi IPv4 anycast.

Figura 2.14: 6to4 Tunnel

Quando 6to4 è usato da un host singolo, questo deve avere connettività IPv4 e un indirizzo IPv4 globale. Tale host è responsabile dell’incapsulamento dei pacchetti IPv6 uscenti e del decapsulamento dei pacchetti 6to4 entranti. 6to4 incapsula un pacchetto IPv6 nel payload di un pacchetto IPv4 con Protocol Type pari a 41. L’indirizzo IPv4 di destinazione da inserire nell’header è derivato dall’indirizzo IPv6 di destinazione del pacchetto IPv6 interno, come specificato sopra. L’indirizzo IPv4 sorgente da inserire nell’header è l’indirizzo IPv4 del nodo che invia il pacchetto nella rete IPv4. il pacchetto IPv4 risultante è instradato verso l’indirizzo IPv4 di destinazione come ogni altro pacchetto IPv4.



Pagina 64 di 189

33 PPrrooggeettttaazziioonnee aarrcchhiitteettttuurraa ddii ggeessttiioonnee ppeerr IIPPvv66 Nel precedente capitolo è stato introdotto il concetto di sicurezza dell’informazione e presentato il modello ITU‐T X.800 che rappresenta oggi lo standard universalmente accettato a livello internazionale per la protezione sia nell’accesso che nel transito attraverso una rete di telecomunicazioni. Si è inoltre mostrato come, tramite diverse tipologie di apparati e la suite di protocolli IKE/IPSec sia possibile effettuare la protezione dell’informazione in transito attraverso la rete ed il controllo perimetrale della stessa attraverso l’implementazione di politiche di firewall. In architetture TCP/IP complesse la configurazione manuale di questi apparati di sicurezza presenta notevoli difficoltà: si tratta di un procedimento soggetto a possibili errori e la cui difficoltà incrementa col numero di dispositivi presenti nella rete che sia necessario configurare. Per questo motivo esistono diverse soluzioni di software Network Management System (NMS) per la configurazione e la gestione attraverso interfacce grafiche di architetture di rete anche molto complesse. L’NMS sviluppato dai laboratori AMTEC della ElsagDatamat S.p.A è il SAS Manager, in cui è stato integrato e da cui si è sviluppato il progetto di rilevamento e risoluzione dei conflitti Sas‐Price. Lo scopo di questa tesi è di integrare all’interno del progetto SAS‐Price i componenti e le relative funzioni che permettano di gestire il protocollo IPv6, oltre all’IPv4 attualmente implementato. L’integrazione di IPv6 all’interno di tale progetto prevederà l’implementazione delle funzionalità correlate a tale protocollo già presentate all’interno del Capitolo 2: Dual Stack, ovvero la gestione del doppio piano di indirizzamento v4 e v6 (cfr. par. 2.7.1) che consente ai due protocolli di convivere all’interno della stessa rete, senza che questi possano interoperare tra loro; NAT‐PT e Tunneling v4/v6. Nel caso di NAT‐PT (cfr. par. 2.7.2) viene implementato il meccanismo di conversione tra indirizzi v4/v6 tramite regole di traduzione statiche o dinamiche per effettuare il mapping di un indirizzo IPv6 su un indirizzo IPv4. Nel caso di Tunneling v4/v6 (cfr. par. 2.7.3) viene implementato il meccanismo di transizione usato per interconnettere tra loro host che appartengono a reti tra loro incompatibili tramite incapsulamento di pacchetti IPv6 in datagrammi IPv4; IKE/IPSec, ovvero la gestione della sicurezza a livello IPv6 (cfr. par. 2.6).



Pagina 65 di 189

Nei paragrafi seguenti saranno presentati gli NMS e i relativi DB su cui sono state operate le modifiche che hanno reso possibile l’integrazione di IPv6 oltre agli strumenti ed ai software utilizzati in tale progetto.

3.1 IL PROGETTO SAS-PRICE In questo paragrafo è presentato il SAS Manager, ovvero il NMS sviluppato da ElsagDatamat S.p.A presso i laboratori AMTEC ed il progetto di rilevamento e risoluzione dei conflitti SAS‐Price attualmente in ricerca e sviluppo presso la medesima azienda nel reparto Excite.

3.1.1 SAS Manager SAS Manager [1], [5] è un’applicazione client‐server ad architettura distribuita proprietaria AMTEC, che permette di configurare e gestire apparati di rete da remoto mediante interfaccia grafica. Questo programma ha una visione generale della composizione della rete e ciò permette di fornire la gestione sia di aspetti legati ai singoli apparati, quali ad esempio le interfacce di un dispositivo o la configurazione di un firewall, sia di concetti che coinvolgano contemporaneamente più dispositivi come una S‐VPN. Il SAS Manager è orientato alla gestione degli apparati delle serie SAS (Secure Access System) che integrano le funzionalità di Security Gateway IPSec e di Firewall e permette una gestione limitata anche di altri tipi di dispositivi.

Figura 3.1: Architettura del SAS Manager



Pagina 66 di 189

Il SAS Manager è composto da due applicazioni client ad interfaccia grafica e un modulo server che gestisce un insieme di dati (costituito da un database e da vari file di configurazione). In dettaglio i componenti costitutivi del NMS sono: Un’istanza del SAS Manager Engine, che costituisce la parte server dell’intero sistema di gestione: controlla, centralizzandoli e serializzandoli, gli accessi agli apparati ed ai dati da parte dei moduli client; Due moduli client ad interfaccia grafica: Il SAS Manager Console costituisce l’interfaccia principale dell’intera architettura, è un modulo orientato alla gestione e alla configurazione completa sia della rete che della S‐VPN IKE/IPSec realizzata tramite i SAS: permette di avere una rappresentazione grafico‐gerarchica della rete e di controllarne completamente gli apparati. Può essere eseguito in più istanze su diverse macchine e si collega all’Engine per poter accedere agli apparati ed ai dati; Il SAS Configuration Manager è attivato ed usato come accessorio all’interno della Console per configurare aspetti tipicamente di rete (ad esempio relativi al routing) dei singoli apparati. Gestisce inoltre la configurazione del Firewall integrato nei SAS.

3.1.2 SAS‐Price La gestione delle politiche di sicurezza è un tema di grande attualità nella ricerca accademica e parallelamente il mondo industriale dei produttori di apparati di rete è molto sensibile a questo tema, in particolare per l’azienda ElsagDatamat che si occupa di sicurezza in vari livelli ed ambiti applicativi. Tra i progetti di collaborazione tra Azienda e Università, tale progetto nasce nell’ambito della collaborazione tra la società ElsagDatamat ed il dipartimento INFOCOM dell’Università La Sapienza di Roma. SAS‐Price (Secure Access System ‐ Policy Retriever with Integrity and Consistency Engine) è un progetto la cui finalità è quella di modellizzare ad alto livello la gestione degli apparati di rete con funzionalità di sicurezza, centralizzando il processo di rivelazione e risoluzione dei conflitti, in modo da creare così un’architettura software chiamata Security Framework (cfr. par. 4.2) che



Pagina 67 di 189

raccolga ed implementi gli studi compiuti nei singoli campi relativi alle policy di apparati e alle loro gestioni e configurazioni. Tale progetto che ha integrato nella piattaforma di gestione SAS Manager nuove funzionalità attraverso la creazione di due nuovi Data Base e e di specifici moduli software per l’interazione tra di essi e con i dispositivi.

SMDB (Sas Manager DataBase) Il database del SAS Manager, l’SMDB [1], [5] ha una struttura strettamente legata al software proprietario che lo utilizza: non è un database relazionale e non riesce a rappresentare in maniera completa tutti gli aspetti della configurazione di una S‐VPN. Questo accade perchè i dati su cui lavora il SAS Manager sono distribuiti in strutture diverse (alcuni nel database, altri su file) ma solo l’unione di questi dati permette al software di avere una visione completa per gestire l’intera configurazione di rete. Per questi motivi, l’SMDB non può essere definito un database generale per la rappresentazione di S‐VPN.

GSDB (Global Smart DataBase) È quindi nata l’esigenza di definire un nuovo database, il GSDB che permette di avere una visione globale della rete. Questo database è stato pensato e progettato per rappresentare in modo completo ed universale tutti gli aspetti relativi ad una configurazione di rete, sia a livello di policy di sicurezza che a livello di configurazioni di una S‐VPN. Il GSDB ruota attorno al concetto di connessione tra due o più network, alla quale si associano eventualmente le policy IKE e IPSec ed i vari parametri di connessione. Una singola istanza di tale database rappresenta le caratteristiche dell’intera rete gestita. In questo modo, il GSDB, contiene anche le informazioni già presenti nel SMDB. Inoltre, per le sue caratteristiche, il GSDB è in grado di integrare ed eventualmente in futuro di sostituire il database del SAS Manager oppure essere alla base di un qualsiasi software per la gestione delle reti svincolandosi dall’implementazione del SAS Manager.

DVDB (Device DataBase) Il GSDB va ad affiancarsi al database, già presente nel progetto, per la risoluzione dei conflitti delle policy, il DVDB. Tale database rappresenta le



Pagina 68 di 189

informazioni in modo puntuale, ovvero una singola istanza del database rappresenta tutte le informazioni su un singolo device nella rete e sulle connessioni che esso effettua. Il DVDB costituisce la struttura dati su cui si basa il sistema di risoluzione dei conflitti. Infatti il DVDB viene popolato dal Modulo Popolatore che prende in input i file di configurazione dei singoli apparati in formato ASN.1. La coesistenza di due database svincolati, in questo progetto, è dovuta all’esigenza di gestire contemporaneamente due funzionalità differenti: Configurazione di reti complesse. Necessita di un database globale quale il Global Smart DB. L’amministratore di rete ha una visione a livello di connessioni e non di dispositivo. Il GSDB mette a disposizione tali informazioni, senza dover effettuare una preventiva elaborazione dei dati presenti nel database puntuale. Risoluzione dei conflitti tra policy. Necessita di un database puntuale quale il Device DB. Per rilevare i conflitti infatti, sia di tipo inter‐device che intra‐device, si deve procedere con un’analisi delle singole policy presenti nella Access list e/o verificando la tabella delle regole del firewall. Entrambe queste informazioni sono disponibili direttamente nel DVDB, senza fare nessuna elaborazione precedentemente. La gestione di S‐VPN coinvolge la configurazione di almeno due apparati; invece di lavorare soltanto con le configurazioni puntuali degli apparati che formano la S‐VPN, è utile avere una visione globale dell’intera rete, da cui poter ricavare le singole configurazioni. D’altra parte la risoluzione dei conflitti implica che si lavori su dati puntuali, in quanto il conflitto è studiato sulla singola regola di configurazione di ogni SAS. Nasce quindi l’esigenza di inserire dati puntuali nel DVDB a partire da dati globali (nel GSDB) e viceversa. In questo modo, quando si vogliono configurare le S‐VPN si popola direttamente il GSDB, quando invece si devono configurare i singoli dispositivi si popola il DVDB. La coesistenza di due database che rappresentano gli stessi dati in maniera diversa, necessita di algoritmi per l’allineamento tra i due DB che permettano di mantenere anche una coerenza e consistenza dei dati. Questi algoritmi devono essere in grado di leggere le informazioni rappresentate in un modo, elaborarle, dedurre le informazioni per la nuova rappresentazione e aggiornare quest’ultima.



Pagina 69 di 189

Di seguito sono elencati i moduli software che fanno parte del progetto e che realizzano le funzioni di allineamento tra i DB e con i dispositivi di rete (per il dettaglio dei moduli software si rimanda al Capitolo 4):

- Split e Compose: effettuano funzioni di allineamento del DVDB e del GSDB e di passaggio dall’uno all’alro DB (cfr. par. 4.2.4);

- Risolutore: si occupa del rilevamento e della risoluzione dei conflitti sia a livello di Firewall che di S‐VPN degli apparati coinvolti, tramite appositi software che si interfacciano al DVDB;

- Popolatore: si occupa del recupero diretto dagli apparati SAS delle configurazioni di rete e di sicurezza (in formato strutturato ASN.1 o txt, intelligibile al firmware GAIA dei SAS) e del popolamento del DVDB(cfr. par. 4.2.1);

- Traduttore: si occupa del recupero delle configurazioni corrette nel DVDB e della conversione in formato intelligibile dagli apparati SAS (strutturato ASN.1 o txt) (cfr. par. 4.2.3).

Figura 3.2: Schema del progetto SAS‐Price

Il progetto è formato da più sottosistemi che, compiendo ciascuno determinate operazioni, consentono di raggiungere un obiettivo comune:



Pagina 70 di 189

l’allineamento complessivo e corretto della rete, finalizzata ad una semplificazione della gestione della rete in assenza di conflitti tra policy di sicurezza. Infatti, partendo da configurazioni di dispositivi SAS in formato testo, è possibile popolare il DVDB tramite il modulo Popolatore. Dal DVDB è possibile verificare la correttezza delle configurazioni di partenza tramite il modulo Risolutore dei conflitti. Una volta ottenuto il DVDB correttamente popolato (senza errori di configurazione dei dispositivi) il modulo Compose è in grado di passare dal DVDB (rappresentazione puntuale della rete) al GSDB (rappresentazione globale della rete). A completamento di tale processo verrà implementato un altro modulo chiamato Aligner che verrà discusso in dettaglio nel successivo Capitolo 4 per permettere all’SMDB di essere allineato al GSDB corretto. In tal modo, una volta popolato l’SMDB, ovvero il database del SAS Manager sarà possibile visualizzare tramite l’apposita interfaccia grafica dell’NMS la struttura dell’intera rete e sarà possibilemodificarla e gestire i singoli dispositivi SAS che la compongono. L’insieme di tutti questi strumenti, opportunamente relazionati, permette di raggiungere con successo l’obiettivo prefissato.

3.2 ANALISI ED EVOLUZIONE DEL PROGETTO Il modello dell’architettura dei DB presenti nel progetto Sas‐Price è implementato come una base di dati relazionale. La metodologia di progettazione di una base di dati relazionale è articolata in tre fasi principali da effettuare in cascata:

1. Progettazione concettuale: questa fase prevede di rappresentare la realtà d’interesse mediante una descrizione formale e completa ma indipendente dai criteri di rappresentazione utilizzati nei sistemi di gestione di basi di dati. Da questa prima parte comincia il processo di verifica delle informazioni e dei campi che devono essere modificati ed aggiunti al fine di implementare IPv6. Questa fase culmina con la produzione di uno schema concettuale. Questo schema è stato realizzato mediante il più diffuso modello concettuale dei dati, il modello Entità‐Relazione.



Pagina 71 di 189

2. Progettazione logica: consiste nella traduzione dello schema concettuale, definito nella fase precedente, nel modello di rappresentazione dei dati adottato dal sistema di gestione di basi di dati a disposizione. Il prodotto di questa fase viene denominato schema logico e consente di descrivere i dati secondo una rappresentazione ancora indipendente dai dettagli fisici, ma concreta perché disponibile nei sistemi di gestione dei database. Questo schema è stato realizzato mediante la tecnica più utilizzata nel caso di modello relazionale dei dati, quella della normalizzazione. L’esistenza di questa descrizione completa della base di dati, indipendente dagli aspetti implementativi, è stata molto utile in questa fase di prima progettazione come riferimento per le operazioni di interrogazione ed aggiornamento necessarie all’analisi dei campi del DB che è stato necessario modificare.

3. Progettazione fisica: nella fase di progettazione fisica lo schema logico viene completato con la specifica dei parametri fisici di organizzazione dei dati. Il prodotto di questa fase viene denominato schema fisico e dipende dallo specifico sistema di gestione di basi di dati scelto e dai criteri di organizzazione del sistema. Per questa fase di progetto è stata utilizzata la piattaforma Microsoft SQL Server 2005 Express Edition.

3.2.1 Progettazione concettuale La progettazione concettuale costituisce la prima parte dell’identificazione di un modello di dati e consiste nel rappresentare la realtà di interesse in termini di un modello formale ad alto livello indipendente dalla particolare implementazione fisica. Produce in output lo schema concettuale, ovvero un’astrazione e rappresentazione degli aspetti rilevanti della realtà ai fini dell’applicazione. La progettazione concettuale deve inoltre garantire correttezza e completezza della rappresentazione. Da questa prima parte comincia il processo di verifica delle informazioni e dei campi che devono essere modificati ed aggiunti al fine di implementare IPv6 e produrrà in output uno schema concettuale che comprenderà i principali elementi che dovranno essere aggiunti allo schema precedente. Le scelte progettuali dovranno essere quanto più generali possibile per non cadere in particolarizzazioni legate ad una singola modalità di utilizzo ma per



Pagina 72 di 189

poter comprendere il maggior numero di possibili diverse implementazioni e, quindi, per non vincolare le scelte che successivamente saranno fatte dagli sviluppatori del firmware dei SAS Gaia. Il modello dei dati usato per la rappresentazione di questo progetto è quello Entità‐Relazione.

3.2.1.1 Il modello Entità‐Relazione Il modello Entità‐Relazione, a cui spesso si fa riferimento con il termine modello E‐R, è un modello concettuale dei dati che fornisce una serie di costrutti necessari a descrivere la realtà d’interesse. Questi costrutti vengono poi utilizzati per definire degli schemi che descrivono l’organizzazione e la struttura delle occorrenze dei dati. Permette di catturare due aspetti fondamentali:

- Struttura dei dati: classi di oggetti e associazioni logiche che intercorrono tra di essi.

Vincoli: regole a cui le classi e le associazioni devono sottostare per rappresentare la realtà in modo corretto. I costrutti principali del modello E‐R, sono rappresentati in figura:

Figura 3.3: Rappresentazione grafica dei costrutti del modello Entità‐Relazione

Tali costrutti sono di seguito elencati e descritti:

- Entità: è una classe di oggetti che sono di interesse per l’applicazione, che hanno esistenza autonoma e proprietà comuni. Ogni entità ha un nome che la identifica in modo univoco nello schema e viene



Pagina 73 di 189

rappresentata da un rettangolo con il suo nome nel diagramma che descrive lo schema concettuale.

- Relazione: (o associazione) si definisce su due o più entità, e rappresenta dei legami logici, significativi per il sistema di interesse, tra esse. Il numero di entità coinvolte in una relazione si dice grado della relazione. Ogni relazione ha un nome che la identifica in modo univoco nello schema ed è rappresentata nel diagramma che descrive lo schema da un rombo che collega le entità sulle quali è definita la relazione.

- Attributo: è una proprietà locale di un’entità, di interesse ai fini dell’applicazione, che associa ad ogni istanza di entità un valore appartenente ad un insieme detto dominio dell’attributo (tipicamente interi, caratteri, stringhe, ecc.). Possono essere semplici o composti, cioè definiti su un dominio a più dimensioni. Ogni attributo di entità ha un nome che lo identifica in modo univoco nell’ambito della entità, ed è rappresentato da un cerchio collegato alla entità a cui appartiene. Per gli attributi composti si usa una rappresentazione gerarchica.

- Cardinalità di relazione: descrive il numero minimo e massimo di occorrenze di relazione a cui un’occorrenza dell’entità può partecipare. Si esprime mediante una coppia di numeri (x,y):

- x è un intero ≥ 0 ed è la cardinalità minima - y è un intero ≥ x ed è la cardinalità massima

- Cardinalità degli attributi: descrive il numero minimo e massimo di valori dell’attributo associati ad ogni occorrenza di entità o di relazione. Cardinalità degli attributi di tipo (1,1) sono omesse.

- Identificatore dell’entità: è un insieme di proprietà (attributi o relazioni) che permettono di identificare univocamente le istanze di un’entità. Non possono esistere due istanze di una data entità che assumono lo stesso valore per tutte le proprietà che formano l’identificatore. Per rappresentare un identificatore si usa la seguente notazione:

- Se composto da un solo attributo, si annerisce il pallino; - Se composto da molti attributi, questi si tagliano con un arco che

termina con un pallino nero. - Generalizzazione: rappresenta i legami logici tra un’entità, detta padre,

ed una o più entità dette figlie, di cui l’entità padre è più generale, ovvero le comprende come caso particolare. Una generalizzazione è



Pagina 74 di 189

completa se l’unione delle istanze delle entità figlie è uguale all’insieme delle istanze dell’entità padre. Si rappresenta con un’unica freccia che raggiunge il padre e archi che partono dalle figlie. La freccia non è annerita se la generalizzazione non è completa, ovvero l’entità padre non corrisponde all’unione di tutte le figlie.

Schema concettuale del GSDB Nella figura seguente è rappresentato il diagramma Entità‐Relazione semplificato (omessi gli attributi e considerando solo le entità e i vincoli fra esse) del GSDB di partenza:

Figura 3.4: Schema concettuale del GSDB

Per semplicità sono rappresentati solo gli attributi più significativi delle entità che dovranno essere modificate. Il modello identificato si può suddividere in due aree logiche maggiori ed un’area di minore importanza:



Pagina 75 di 189

- Element: area che fa riferimento alla relazione Protects, che lega gli Elements e i Device che li proteggono;

- Device: area che fa riferimento all’entità Device_new e alle caratteristiche del dispositivo.

- Conns: area che fa riferimento alla relazione CONNs che collega due Elements tramite una Policy IPSec ed eventualmente IKE (IPSecPolicy e IKEPolicy);

L’entità Elements_new è compresa in tutte le aree e si pone dunque come centrale all’interno dello schema logico. Il modello proposto rappresenta la S‐VPN come un insieme di connessioni fra Elements (ovvero sottoreti) protetti da un insieme di Device (ovvero Security Gateway). Ogni Element è caratterizzato da un nome ed un indirizzo IP e deve (vincolo di cardinalità (1,1)) essere protetto da un Security Gateway (Device), o da un’area VRRP in cui coesistono più Security Gateway (VRRP_Area), o da un coppia di Security Gateway di cui uno Master e l’altro di Backup (BK_Area). L’interazione fra un Element e uno o più Device che lo proteggono è modellizzata tramite la relazione quaternaria Protects. Ad ogni Element può essere associato un certificato digitale rappresentato dall’elemento Certificate, a sua volta ogni certificato deve essere emesso da un’autorità di certificazione che viene rappresentata dall’elemento CA. Le relazioni Certifies e Emitted rappresentano i vincoli fra tali entità. Il tunnel IKE/IPSec che caratterizza la S‐VPN è identificato nella relazione ternaria CONNs a cui partecipano due elementi, una policy IPSec ed una o nessuna policy IKE (nel caso il tunnel sia manuale non necessita dello scambio IKE). Le policy IKE e IPSec stesse sono considerate entità a sé stanti, rispettivamente IKEPolicy e IPSecPolicy. Da questo schema si può notarte come la relazione CONNs sia adatta a rappresentare ogni tipo di connessione, tra cui anche le connessioni tra due elementi IPv6 ed eventualmente anche tenere traccia del Tunneling v4/v6 (cfr. par. 2.7.3) tra i due endpoint della comunicazione. Infatti, nel caso di Tunneling v4/v6 come nel caso di Tunnel IKE/IPSec viene effettuato l’incapsulamento di un pacchetto in un altro. Nel primo caso il pacchetto incapsulato è IPv6 all’interno di un pacchetto IPv4, mentre nel caso di SVPN il pacchetto incapsulato è IPv4 all’interno del pacchetto IPSec. In



Pagina 76 di 189

entrambe le connnessioni è necessario tenere traccia di quattro indirizzi fondamentali: - L’indirizzo originale dell’host sorgente; - L’indirizzo originale dell’host destinazione; - L’indirizzo del peer origine del tunnel (o l’indirizzo modificato tramite

NAT‐PT); - L’indirizzo del peer destinazione del tunnel (o l’indirizzo modificato

tramite NAT‐PT). I primi due indirizzi sono contenuti nei due Element che sono connessi tra loro dalla relazione CONNs. Gli altri indirizzi sono contenuti nella tabella CONNsParam_new nei campi:

Local_IP_A: indirizzo IP locale del peer A; Local_IP_B: indirizzo IP locale del peer B.

Gli indirizzi Local_IP_A e Local_IP_B contengono l’informazione relativa agli estremi del tunnel (che sono i security gateway tra i quali viene instaurata la SVPN IKE/IPSec) e possono essere utilizzati per contenere gli estremi anche di un tunnel v4/v6, e quindi i relativi indirizzi IPv4. Anche per quanto riguarda la traduzione di indirizzo effettuata tramite NAT‐PT (cfr. par. 2.7.2) i campi di indirizzo all’interno degli elementi sono sufficienti ad immagazzinare tutta l’informazione di cui si ha bisogno. Infatti il caso NAT‐PT essendo analogo al caso NAT può essere trattato nello stesso modo di quest’ultimo, la cui implementazione è presente all’interno della struttura del GSDB. Infatti la tabella CONNsParam_new contiene i campi:

Remote_IP_A: indirizzo IP di NAT del peer A; Remote_IP_B: indirizzo IP di NAT del peer B.

Gli indirizzi Remote_IP_A e Remote_IP_B contengono l’informazione relativa agli indirizzi nattati del tunnel e possono essere quindi utilizzati per contenere gli indirizzi IPv4 utilizzati nella trasformazione di indirizzo effettuata nel NAT‐PT. Inoltre, poiché ad ogni Device può corrispondere più di una interfaccia tramite la relazione Interface, può essere immagazzinato sia l’indirizzo IPv4 che IPv6 del device, realizzando la funzione essenziale di Dual Stack (cfr. par. 2.7.1). Come precedentemente descritto, tale funzione deve essere implementata dai dispositivi di rete che intendono far parte di una rete mista (v4/v6) o che fanno da interfaccia tra queste due reti. Infatti, tramite tale entità viene



Pagina 77 di 189

evidenziata la possibilità di convivenza dei due protocolli all’interno dello stesso dispositivo tramite due interfacce o due diversi indirizzi appartenenti alla stessa interfaccia. In questo caso quindi, l’entità interfaccia non mantiene il significato fisico originario, ma diventa invece un’entità collegata a livello superiore, il livello di rete. Ogni interfaccia risulta dunque collegata all’indirizzo IP a livello 3 della pila TCP/IP piuttosto che al livello 1 ovvero il fisico della stessa. Possono, infatti, coesistere diversi indirizzi IP sulla stessa interfaccia fisica. Dall’analisi finora effettuata del database si evince che il GSDB è strutturato in modo tale da poter contenere già tutta l’informazione che è necessario mantenere all’interno dello stesso anche per quanto riguarda l’implementazione di IPv6. La seconda considerazione che si può fare in base a questa analisi è che la struttura di un tunnel di livello 3, se realizzata in maniera oppurtuna e in modo generale (come in questo caso) riesce a rappresentare in modo completo un qualsiasi altro tunnel dello stesso livello di rete. Esempi che è possibile fare sono, oltre al tunnel IKE/IPSec e il tunnel v4/v6 anche il tunnel GRE (Generic Routing Encapsulation).

Schema concettuale del DVDB Nella figura seguente è rappresentato il diagramma Entità‐Relazione semplificato (omessi gli attributi e considerando solo le entità e i vincoli fra esse) del DVDB di partenza.



Pagina 78 di 189

Figura 3.5: Schema concettuale del DVDB

Per semplicità sono rappresentati solo gli attributi più significativi delle entità che dovranno essere modificate. Rispetto al GSDB nel DVDB non c’è più l’entità centrale Element, che in questo caso diventa invece Device. Infatti, il DVDB contiene le informazioni di dettaglio relative al singolo dispositivo della rete e contiene quindi anche numerose entità con informazioni aggiuntive rispetto al GSDB, come le informazioni sul Management SNMP e sul Firewall. In generale nel DVDB si possono individuare le seguenti aree:

Device: principali caratteristiche del dispositivo e delle interfacce; SNMP: informazioni sulla Community e sul management SMNP; Firewall: regole, selettore, servizi più specifici; Rules Access List: regole presenti nella Access List del dispositivo, che individuano l’azione da associare ai pacchetti; regole presenti nelle Map List, che definiscono come proteggere il traffico selezionato “process” nelle Access List, differenziandosi tra mappe manuali e mappe ISAKMP; policy IKE, IPSec e trasformate che utilizzano.



Pagina 79 di 189

Le informazioni analoghe a quelle che si trovano nel GSDB si trovano nelle entità che fanno parte dell’area Device e Rules Access List, mentre le entità collegate all’area Firewall e all’area SNMP non trovano corrispondenza nel GSDB. Le considerazioni che si possono fare relativamente all’implementazione di IPv6 nel DVDB sono del tutto simili a quelle già fatte nel GSDB, in quanto entrambi i database sono stati progettati per memorizzare le informazioni di tunneling IKE/IPSec in modo completo e quindi anche il DVDB è strutturato in maniera tale da poter contenere tutte le informazioni necessarie all’implementazione di IPv6. Inoltre, le informazioni del GSDB e del DVDB devono corrispondere nel passaggio dall’uno all’altro database in modo che non avvenga perdita di informazioni importanti alla ricostruzione della struttura della rete tramite il SAS Manager. Infatti, i due database nascono per rappresentare le stesse informazioni in modo differente (a livello globale e a livello puntuale). Per cui poiché il GSDB già contiene completamente le informazioni necessarie all’implementazione di IPv6, dovrà essere così necessariamente anche per il DVDB. Nel caso del DVDB tutte le informazioni di interesse alle connessioni effettuate sono contenute in un unico elemento, Rules Access List che contiene i campi:

SourceIpAddr_RAL: Indirizzo IP sorgente / Maschera IP sorgente DestinationIpAddr_RAL: Indirizzo IP destinazione / Maschera IP destinazione

Action_RAL: Tipo di azione del Security Gateway sul traffico proveniente da quella sorgente e verso quella destinazione definite nei campi sopra:

- Discard: scarta i pacchetti; - Bypass: fa passare i pacchetti senza fare alcuna azione; - Process: processa i pacchetti come traffico IPSec, quindi effettua

la cifratura. Per cui può essere aggiunta un’ulteriore opzione per determinare se il traffico debba invece essere elaborato per l’introduzione in un tunneling v4/v6.

Nel caso del NAT‐PT può essere utilizzato l’elemento NATAddressSet che elenca i pool di NAT utilizzati dalla funzionalità di NAT, e in modo analogo



Pagina 80 di 189

può tenere traccia del NAT‐PT utilizzato nel sistema, modificando semplicemente un flag all’interno dell’elemento per distinguere i due casi. Infatti questa tabella contiene i campi:

Name_NAS: Nome del set di indirizzi; Id_DEV: Riferimento alla tabella DEVice (indica il device a cui corrisponde questo pool di NAT);

Type_NAS: tipo di indirizzi per il NAT (pool/list). Campo che può essere usato per discriminare il NAT‐PT aggiungendo un valore specifico per questa opzione;

AddrSet_NAS: insieme di indirizzi identificato da indirizzo Ip/Maschera;

AddrRange_NAS: altro estremo dell’intervallo di indirizzi della rete identificata dalla maschera.

Per quanto riguarda la funzione di Dual Stack, vale lo stesso discorso già fatto per il GSDB, infatti, anche in questo caso ad ogni device può corrispondere più di una interfaccia tramite la relazione Interface, e allo stesso modo può essere immagazzinato sia l’indirizzo IPv4 che IPv6 del dispositivo. La struttura di entrambi i database è stata quindi realizzata in modo talmente generale da permettere l’implementazione di queste nuove funzionalità senza impattare in maniera eccessiva il design delle basi dati stesse. Questo è certamente un vantaggio in temini di realizzazione in quanto riduce la complessità del lavoro, i tempi di lavorazione (che per l’azienda comporta costi) e minimizza il numero di errori, riducendo anche le tempistiche correlate alla fase di testing su tali nuove funzionalità.

3.2.2 Progettazione logica La progettazione logica consiste nella traduzione dello schema concettuale, definito nella fase precedente nel modello di rappresentazione dei dati adottato dal sistema di gestione di basi di dati a disposizione. Il prodotto di questa fase viene denominato schema logico. Essenzialmente i punti principali affrontati in questa fase sono: Scelta delle entità a cui è necessario apportare delle modifiche: per ogni entità devono essere scelti ed inseriti gli attributi atti a rappresentare in maniera esauriente la nuova realtà di interesse; Inserimento delle modifiche opportune ai campi selezionati.



Pagina 81 di 189

È necessario modificare quelle entità che fanno riferimento ad uno specifico protocollo di rete, e quindi laddove fosse presente un indirizzo IP, evidenziare se il pacchetto è nel formato IPv4 oppure IPv6. Infatti, poiché cambia il formato del pacchetto (cfr. par. 2.1) nella sua lunghezza dell’header, nella riduzione dei campi, nel trattamento delle opzioni. Esiste notevole differenza nel processamento del pacchetto a seconda del protocollo di rete, quindi laddove necessario la differenza verrà indicata aggiungendo i campi opportuni. Relativamente alle S‐VPN dall’analisi relativa al formato dei pacchetti nel caso IPv4 o IPv6 è emerso che IKE/IPSec vengono implementate nello stesso modo per i due protocolli IP. Le differenze (cfr. par. 2.6) consistono nel fatto che in IPv6 la sicurezza è integrata nello stesso protocollo, e quindi sono previste le apposite estensioni che possono essere usate per indicare il tipo di sicurezza ESP e/o AH fornito. Inoltre IPv6 implementa come per IPv4 sia il tunne che il Transport mode sia per AH che ESP, e utilizza gli stessi algoritmi di cifratura. La stessa negoziazione IKE può essere effettuata in Main o Aggressive mode. Non si ritiene dunque necessario specificare, nelle entità che trattano nel dettaglio i protocolli implementati IKE/IPSec, se si tratti di pacchetto IPv4 o IPv6, in quanto la specifica viene già effettuata nelle entità che trattano gli indirizzi IP a livello di dispositivo, di entità o di servizi e funzionalità connesse al protocollo di rete, al fine di garantire un corretto processa mento del pacchetto. Di seguito sono elencate in dettaglio le entità di ognuno dei due database e le scelte fatte per ognuna di queste.

Schema logico del GSDB Relativamente alla scelta delle entità a cui è necessario apportare delle modifiche, vengono analizzate in dettaglio le singole unità che compongono lo schema. Il GSDB contiene le seguenti entità suddivise per aree:



Pagina 82 di 189

Area Device:

Device_new: Contiene informazioni relative a tutti gli apparati. Ci sono informazioni che interessano lo specifico protocollo di rete e per le quali è necessario specificare il protocollo di appartenenza come GestAddr ovvero l’indirizzo di gestione del device. Per specificare il formato di questo indirizzo viene introdotto un nuovo attributo Type_IP_v4 che segnala se l’indirizzo è IPv4 (in caso contrario sarà IPv6). Il campo Gest_Addr_NAT ovvero l’indirizzo di gestione nattato del device, se presente, è di certo IPv4, in quanto il NAT è implementato ed utilizzato attualmente solo per IPv4 per far fronte alla scarsità di indirizzi disponiblili. In IPv6 tale protocollo non ha utilità per cui non trova implementazione.

Interfaces_new: Contiene informazioni sulle interfacce fisiche dei device. Contiene il campo Addr che equivale all’indirizzo dell’interfaccia ed è quindi necessario specificare il protocollo di rete. Per specificare il formato di questo indirizzo viene introdotto l’attributo Type_IP_v4. È possibile associare ad una stessa interfaccia più indirizzi IP e quindi ad associazioni IPv6 che vengono rilevate dalla relativa entità.

SubInterfaces_new: Elenca tutti i possibili indirizzi IP che possono essere associati ad una singola interfaccia fisica. Contiene il campo Addr_SUBINT che equivale all’indirizzo della sottointerfaccia ed è quindi necessario specificare il protocollo di rete. Per specificare il formato di questo indirizzo viene introdotto l’attributo Type_IP_v4.

NATCer_new: Contiene informazioni sul NAT su base certificato. Elenca i pool di NAT utilizzati da tale funzionalità. Ci sono informazioni che interessano lo specifico protocollo di rete come gli indirizzi appartenenti al range di NAT, ma, in questo caso, non è necessario specificare il protocollo di appartenenza. Infatti, essendo il NAT unicamente applicabile in IPv4, gli indirizzi contenuti negli attributi di questa entità sono solo di tipo IPv4.

Area Element:

Elements_new: Contiene l’elenco di elementi di VPN che possono essere utilizzati all’interno delle S‐VPN e contiene il campo Addr che equivale



Pagina 83 di 189

all’indirizzo dell’interfaccia. Un elemento può supportare la modalità Dual Stack e quindi supportare sia un indirizzo IPv4 che uno IPv6. Per tener traccia di questa doppia modalità, poiché nella realizzazione attuale non si può specificare un altro indirizzo di rete per IPv6, viene introdotto l’attributo Addr_IPv6. Il campo Nat_MNG_Addr ovvero l’indirizzo nattato dell’elelemento in caso si tratti di un elmento di gestione, se presente, è di certo IPv4, in quanto il NAT è implementato ed utilizzato attualmente solo per IPv4.

Protects_new: Relazione che lega device alle aree VRRP, e di backupPeer e agli elementi. Si traduce in una tabella nel DB. Contiene gli identificativi delle aree che connette e altre informazioni su queste. Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

VRRPArea_new: Rappresenta un’area di VRRP in cui c’è un device master e uno slave. Contiene il campo VIP_Addr ovvero l’indirizzo VIP degli apparati in VRRP ed è quindi necessario specificare il protocollo di rete. Per specificare il formato di questo indirizzo viene introdotto l’attributo Type_IP_v4. Per individuare quali devices fanno parte della stessa area VRRP, basta individuare i devices con lo stesso VIP.

BKArea_new: Rappresenta un’area dei peer di backup. Contiene informazioni come il Master_Id che è l’Id del device master dell’area. Poiché quindi vi è solo un riferimento a un device e non l’indirizzo dello stesso, non è necessario specificare il protocollo di rete.

Area Conns:

CONNs_new: Relazione multipla (fulcro del diagramma ER) tra Elements_new, IKEArea_new, CONNSParam_new, IPSecPolicy_new, Services_new. Contiene informazioni sulle connessioni IKE/IPSec e contiene campi come ELEM_A_Id e ELEM_B_Id ovvero gli Id dei due elementi che instaurano le S‐VPN tra loro. Poiché quindi vi sono solo riferimenti a elementi e non l’indirizzo degli stessi, non è necessario specificare il protocollo di rete.

CONNsParam_new: Contiene le informazioni sui parametri IKE della connessione e sui local IP address dei Peer. Ci sono quindi informazioni



Pagina 84 di 189

che interessano lo specifico protocollo di rete e per le quali è necessario specificare il protocollo di appartenenza. Tali campi sono: - Local_IP_A: Indirizzo IP locale del Peer A; - Local_IP_B: Indirizzo IP locale del Peer B; - Remote_IP_A: Indirizzo IP remoto del Peer A; - Remote_IP_B: Indirizzo IP remoto del Peer B. Le connessioni saranno instaurate tra due elementi che si scambiano pacchetti utilizzando lo stesso tipo di protocollo IP (condizione base della comunicazione) e quindi anche le S‐VPN saranno instaurate secondo questa condizione. Per specificare il formato di questi indirizzi viene introdotto quindi un unico attributo Type_IP_v4 che indica se il formato di questi indirizzi è IPv4 (o altrimenti IPv6).

CONNsServ_new: Relazione fra le connessioni ed eventuali servizi ad esse associati. Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

CryptoSet_new: Contiene le informazioni sulle primitive crittografiche disponibili per le policy IKE e IPSec (nome e tipo della primitiva crittografica). Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

IKEArea_new: Contiene l’elenco di tutte le connessioni che hanno la stessa politica IKE e altre informazioni su tale policy (chiave preshared della transazione IKE, Modalità della negoziazione IKE: Main mode/Aggressive mode , ecc…). Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

IKEPolicy_new: Contiene tutti i campi necessari a definire una politica IKE (tipo di algoritmo utilizzato per effettuare la cifratura, tipo di algoritmo di hashing, gruppo Diffie Hellman utilizzato nella transazone IKE, ecc…). Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

IPSecPolicy_new: Contiene informazioni sulle policy IPSEC (tipo di algoritmo di hashing AH, tipo di algoritmo di hashing ESP, tipo di algoritmo utilizzato per effettuare la cifratura di ESP, ecc …). Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

CA_new: Contiene informazioni sulle autorità di certificazione (Common name della Certification Authority, Informazioni sui



Pagina 85 di 189

certificati, ecc…). Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

Certificate_new: Contiene informazioni sui certificati (Common name del certificato, OrganizationUnit, Country, ecc…). Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

Services_new: Contiene il riferimento ai servizi attivi dei singoli elements che fanno parte di una connessione e le porte di connessione. Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

L’elenco completo delle tabelle e degli attributi del GSDB si trova nell’Appendice A. Lo schema logico completo, risultato di questa fase di progettazione, è rappresentato nel seguente paragrafo unitamente allo schema fisico implementato con SQL Server.

3.2.2.1 Schema logico del DVDB Relativamente alla scelta delle entità a cui è necessario apportare delle modifiche, vengono analizzate in dettaglio le singole unità che compongono lo schema. Il DVDB contiene le seguenti entità suddivise per aree: Area Device:

DEVice (DEV): Contiene informazioni relative ad ogni singolo apparato. Ci sono informazioni che interessano lo specifico protocollo di rete e per le quali è necessario specificare il protocollo di appartenenza. Tali campi sono: - SecureAddr_ DEV: Indirizzo di default per tunnel IPSec; - GestAddr_DEV: Indirizzo di gestione del device; Poichè un dispositivo può avere due indirizzi IP che appartengono a due interfacce che si connettono a due reti distinte, potrebbe accadere che l’indirizzo di gestione e di sicurezza siano di protocolli IP diversi. Nasce quindi l’esigenza di creare due nuovi attributi: Type_IP_v4_Gest e Type_IP_v4_Secure per identificare il tipo di protocollo IP di ognuno dei due indirizzi di rete.



Pagina 86 di 189

PHysical Interface (PHI): Contiene informazioni sulle interfacce fisiche di ogni device. Contiene il campo IpAddr che equivale all’indirizzo dell’interfaccia ed è quindi necessario specificare il protocollo di rete. Per specificare il formato di questo indirizzo viene introdotto l’attributo Type_IP_v4. È possibile associare ad una stessa interfaccia più indirizzi IP e quindi ad associazioni IPv6 che vengono rilevate dalla relativa entità.

NatAddressSet (NAS): Contiene informazioni per nattare un set di indirizzi in cui il campo Type equivale a list se vi è un elenco indirizzi oppure equivale a pool se vi è invece un pool di indirizzi disponibili per effettuare il NAT. Questo elemento può essere utilizzato per contenere le informazioni di NAT‐PT ed è possibile specificare di quale caso si tratti utilizzando il campo Type_NAS che specifica il tipo di indirizzi per il NAT (pool/list). Per discriminare il NAT‐PT si può aggiungere un valore specifico per questa opzione come ad esempio poolNAT‐PT.

Area SNMP:

SNMPManager (SNM): Contiene informazioni che permettono al protocollo SNMP di gestire gli indirizzi IP dei manager a cui inviare le segnalazioni spontanee (Trap). Contiene l’attributo Address_SNM, ovvero l’indirizzo di gestione, è quindi necessario specificare il relativo protocollo di rete. Per specificare il formato di questo indirizzo viene introdotto l’attributo Type_IP_v4.

SNMPCommunity (SNC): Contiene informazioni sulle community SNMP come il nome della community SNMP, il tipo di accesso (RO = sola lettura; RW = lettura e scrittura). Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

Area Rules Access List:

Rules Access List (RAL): Contiene informazioni sulle access list che permettono il passaggio solo di determinati pacchetti IP. In caso di IPSec devono essere definite delle access list specifiche per il passaggio dei pacchetti IPSec. Ci sono informazioni che interessano lo specifico



Pagina 87 di 189

protocollo di rete e per i quali è necessario specificare il protocollo di appartenenza. Tali campi sono: - SourceIpAddr_RAL: Indirizzo IP sorgente / Maschera IP sorgente; - DestinationIpAddr_RAL: Indirizzo IP destinazione / Maschera IP

destinazione. Le connessioni saranno instaurate tra due elementi che si scambiano pacchetti utilizzando lo stesso tipo di protocollo IP e quindi anche le S‐VPN saranno instaurate secondo questa condizione. Per specificare il formato di questi indirizzi viene introdotto quindi un unico attributo Type_IP_v4 che indica se il formato di questi indirizzi è IPv4 (o altrimenti IPv6). Inoltre per è necessario distinguere il tipo di azione da intraprendere sul traffico IPv6, quindi nel campo Action_RAL oltre ai campi discard, bypass e process si aggiunge un’ulteriore opzione (Tunnel_v6) per determinare se il traffico debba invece essere elaborato per l’introduzione in un tunneling v4/v6.

MapISakmp (MIS): Contiene informazioni sulle mappe ISAKMP, ovvero sulle policy IPSec dinamiche negoziate tramite IKE e definite fra due peer. Ci sono informazioni che interessano lo specifico protocollo di rete e per i quali è necessario specificare il protocollo di appartenenza o comunque effettuare delle modifiche. Tali campi sono: - PeerIdType_MIS: Tipo di identificativo utilizzato per individuare i

Peer della transazione IKE, e i valori utilizzati sono IPv4_Address oppure DistinguishName. Risulta necessario aggiungere anche un altro valore “IPv6_Address”. Da questo valore dipendono anche i campi LocalIdValue_MIS e RemoteIdValue_MIS (Identificativo del Peer locale e remoto della transazione IKE) che quindi non necessitano di modifiche perché il loro valore è già specificato dal campo PeerIdType_MIS;

- LocalPeerAddr_MIS: Nuovo indirizzo usato per la transazione IKE (necessario specificare il protocollo di appartenenza);

- RemotePeerAddr_MIS: Indirizzo dell’end‐point del tunnel IPSec (necessario specificare il protocollo di appartenenza).

Poiché si segue la regola che le S‐VPN sono instaurate tra due elementi che utilizzano lo stesso tipo di protocollo IP per specificare il formato degli indirizzi LocalPeerAddr_MIS e RemotePeerAddr_MIS viene



Pagina 88 di 189

introdotto un unico attributo Type_IP_v4 che indica se il formato di questi indirizzi è IPv4 (o altrimenti IPv6).

IKePolicy (IKP): Contiene informazioni sulle policy IKE definite (Nome della politica IKE, Numero identificativo della priorità di utilizzo delle Policy IKE, Tipologia di autenticazione, Tipo di algoritmo di hashing, Tipo di algoritmo di cifratura usato nella transazione IKE, ecc….). Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

MapisakmpXIkepolicy (MXI): Contiene informazioni per legare le entità MapISakmp (MIS) e a IKePolicy (IKP) (esprime una relazione). I campi contenuti sono quindi i riferimenti a queste, per cui tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

MapisakmpXTransformset (MXT): Contiene informazioni per legare le entità MapISakmp (MIS) e a TRansform Set (TRS) (esprime una relazione). I campi contenuti sono quindi i riferimenti a queste, per cui tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

MapMAnual (MMA): Contiene informazioni sulle mappe IPSec manual clear (non ISAKMP). Il campo RemotePeerAddr_MMA indica l’indirizzo dell’end‐point del tunnel IPSec e interessa lo specifico protocollo di rete. Per tale attributo è necessario specificare il protocollo di appartenenza. Per specificare il formato di questo indirizzo viene introdotto l’attributo Type_IP_v4.

TRansform Set (TRS): Contiene informazioni sui transform set, che costituisce una combinazione accettabile di transform, ovvero di algoritmi, protocolli e altre impostazioni di sicurezza che devono essere applicate al traffico protetto tramite il protocollo IPSec. L’attributo Mode_TRS (tunnel/transport) deve tener traccia di IPv6 tramite l’aggiunta di ulteriori due opzioni di scelta: tunnel_v6/transport_v6.

CERtificate (CER): Contiene tutte le informazioni sui certificati. (Nome della Certification Authority, Nome del certificato, ecc...). Risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.



Pagina 89 di 189

Area Firewall:

Rules FireWall (RFW): Contiene tutte le regole del firewall. Ci sono informazioni che interessano lo specifico protocollo di rete e per i quali è necessario specificare il protocollo di appartenenza. Tali campi sono: - SourceIpAddr_RFW: Indirizzo IP sorgente/Maschera dell’indirizzo IP

sorgente; - DestinationIpAddr_RFW: Indirizzo IP destinazione/Maschera

dell’indirizzo IP destinazione; Le connessioni saranno instaurate tra due elementi che utilizzano lo stesso tipo di protocollo IP e quindi per specificare il formato di questi indirizzi viene introdotto un unico attributo Type_IP_v4 che indica se il formato di questi indirizzi è IPv4 (o altrimenti IPv6).

SasfwIpDb (SID): Contiene informazioni che permettono di inserire un IP database, vale a dire una struttura nella quale è contenuto un insieme di indirizzi IP. Tale database è necessario per realizzare le politiche dʹaccesso utilizzate dal firewall per la gestione del traffico. Ci sono quindi informazioni che interessano lo specifico protocollo di rete e per i quali è necessario specificarlo. Tali campi sono: - AddrSet_SID: Indirizzo IP di inizio range o Indirizzo IP di un

insieme; - AddrRange_SID: Indirizzo IP di fine range o maschera. Gli indirizzi presenti in questi campi fanno riferimento a insiemi di indirizzi dello stesso tipo e con lo stesso protocollo IP (infatti si tratta di indirizzo e maschera corrispondente oppure di indirizzo finale e iniziale di un range). Per specificare il formato di questi indirizzi viene introdotto quindi un unico attributo Type_IP_v4 che indica se il formato di questi indirizzi è IPv4 (o altrimenti IPv6).

SasfwNatDb (SND): Contiene informazioni che permettono di inserire un NAT database, necessario per realizzare le politiche dʹaccesso utilizzate dal firewall per la gestione del traffico. Per le motivazioni viste nel caso dell’entità NatAddressSet (NAS) si ritiene il NAT unicamente applicabile in IPv4 e quindi gli indirizzi contenuti negli attributi di questa entità sono solo di tipo IPv4.

SasfwServicesDb (SSD): Contiene le informazioni necessarie per permettere l’inserimento di un service database. Questo è necessario



Pagina 90 di 189

per realizzare le politiche dʹaccesso utilizzate dal firewall per la gestione del traffico. Tale database associato al selettore e quindi ad una policy fornisce la possibilità di discriminare il traffico tra i vari IP database configurati. Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

FwPolicy (FWP): Contiene le informazioni per creare una policy (). A tale rule viene associata la direzione del traffico, un selettore ed un permesso allow oppure deny. In questo modo tale policy regola il traffico descritto dal selettore a lei associato. Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

FwSelector (FWS): Contiene informazioni che permettono di inserire un selettore, necessario per realizzare le politiche dʹaccesso utilizzate dal firewall per la gestione del traffico e che può essere abbinato ad una rule permit/deny. Tale entità contiene attributi come SourceIpDb e DestIpDb ovvero indirizzo IP sorgente e destinazione. Tali attributi non sono però legati al protocollo di rete in quanto non sono veri e propri indirizzi, ma nomi associati ad uno specifico indirizzo, il cui valore è immagazzinato nell’entità SasFwIpDb. È invece opportuno apportare modifiche all’attributo Protocol ovvero il protocollo associato al selettore (TCP / UDP / ICMP / AH / ESP / GRE /ANY_PROT) in cui si dovrebbe inserire ulteriori criteri di selezione quali: TCPv6 / UDPv6/ ICMPv6.

FWSelfpolicy (FSP): Contiene informazioni che permettono di specificare una Self Policy. Le Self Policy regolano il traffico entrante destinato al SAS stesso. Anche in questo caso è opportuno apportare modifiche all’attributo Protocol ovvero il Protocollo associato alla Self Policy (TCP, UDP, ICMP, ESP, GRE, AH) inserendo ulteriori criteri di selezione quali: TCPv6 / UDPv6/ ICMPv6.

FWBoxAccess (FBA): Contiene informazioni per raffinare ulteriormente le politiche Self (traffico destinato al SAS), in particolare si può definire se accettare o meno a seconda della provenienza (EXTERNAL, DMZ o CORPORATE) pacchetti di Ping, Telnet e Login. Tale entità risulta indipendente dal protocollo di rete e quindi non necessita di modifiche.

L’elenco completo delle tabelle e degli attributi del DVDB si trova nell’Appendice B.



Pagina 91 di 189

Lo schema logico completo, risultato di questa fase di progettazione, è rappresentato nel seguente paragrafo unitamente allo schema fisico implementato con SQL Server.

3.2.3 Progettazione fisica La Progettazione fisica consiste nel completamento dello schema logico con la specifica dei parametri fisici di organizzazione dei dati. Il prodotto di questa fase viene denominato schema fisico e dipende dallo specifico sistema di gestione di basi di dati scelto e dai criteri di organizzazione del sistema.

SQL Server Per lo sviluppo del modello fisico dei dati, è stato utilizzato Microsoft SQL Server 2005 Express Edition. Questo sistema di gestione di basi di dati è del tutto adatto ad esigenze di studio e risulta completamente integrato nell’ambiente di sviluppo gratuito Microsoft Visual Studio 2005 Express Edition, già utilizzato come piattaforma di sviluppo dei moduli software e dei DB del progetto SAS‐Price. Visual Studio è il tool utilizzato per amministrare i database SQL.

Figura 3.6: Schermata Microsoft Visual Studio 2005 Express Edition



Pagina 92 di 189

SQL Server è un Database Client‐Server, tipicamente installato su una macchina server a cui possono accedere più macchine client contemporaneamente.

Schema fisico Il processo di passaggio dal modello logico a quello fisico è caratterizzato dalla scelta del dominio di ogni singolo attributo introdotto. In questa fase sono anche state scelte le convenzioni per i nomi delle tabelle e degli attributi delle stesse, che poi sono state riportate “all’indietro” anche nel modello logico. Per quanto riguarda il dominio degli attributi, è stato scelto in alcuni casi di rappresentare valori numerici degli indirizzi IPv6 mediante dei VARCHAR(50), ovvero delle stringhe di dimensione variabile, di massima lunghezza 50 caratteri. La scelta è stata fatta per mantenere lo stesso dominio rispetto agli indirizzi IPv4. Infatti, 50 caratteri sono sufficienti per esprimere l’indirizzo IPv6 che dispone di 4 caratteri per ogni campo e 8 campi (32 caratteri più 7 caratteri di separazione ‘:’). In totale si hanno 39 caratteri solo per l’indirizzo senza maschera. Rispetto a IPv4, in IPv6 il prefisso di indirizzo non si esprime in modo esteso, ma con la notazione barra e numero di bit corrispondenti alla lunghezza del prefisso. Questo permette di portare il numero di caratteri al massimo a 43 e quindi permette di utilizzare lo stesso dominio usato per il formato IPv4: VARCHAR(50). La scelta orientata a mantenere lo stesso dominio comporta una semplificazione della struttura delle tabelle e permette inoltre che un campo di indirizzo possa ospitare sia un indirizzo IPv4 che IPv6. Questa scelta ha portato ad un’altra scelta, quella del dominio dell’attributo aggiuntivo Type_IP_v4 che discrimina il formato dell’indirizzo IP. Infatti, poiché ogni campo di indirizzo può ospitare entrambi i formati IP, per discriminarli basta semplicemente aggiungere un bit di informazione (dominio bit). Il bit sarà impostato di default a 1 (per IPv4) e dovrà essere modificato se si tratta di un indirizzo IPv6. Tale attributo non ammette il valore nullo.



Pagina 93 di 189

Nelle figure seguenti sono illustrati gli schemi fisici del GSDB e del DVDB suddivisi per aree. In Appendice A (GSDB) e in Appendice B (DVDB) è riportato il dizionario completo delle tabelle e degli attributi. Le relazioni con i vincoli sulle chiavi delle varie tabelle che li esprimono sono evidenziati dalla presenza di una connessione tra le tabelle con una chiave che punta verso la tabella di cui si ha il riferimento (chiave esterna). Le chiavi primarie di ogni tabella sono identificate dalla presenza di una chiave alla sinistra del nome dell’attributo all’interno della tabella. Alla destra del nome di dominio sono espressi i vincoli not null ovvero obbligatori. Se il campo “Ammetti Null” è checked, vuol dire che è ammesso il valore nullo per quel campo. GSDB, Area Element:

Figura 3.7: Schema Fisico del GSDB, Area Element

In questa figura si può notare la presenza dell’attributo aggiuntivo Type_IP_v4 nelle tabelle Device_new e VRRPArea_new e dell’attributo Addr_v6 nella tabella Elements_new.



Pagina 94 di 189

GSDB, Area Device:

Figura 3.8: Schema Fisico del GSDB, Area Device

In questa figura si può notare la presenza dell’attributo aggiuntivo Type_IP_v4 nelle tabelle Device_new, Interfaces_new, SubInterfaces_new. GSDB, Area Conns:



Pagina 95 di 189

Figura 3.9: Schema Fisico del GSDB, Area Conns

In questa figura si può notare la presenza dell’attributo aggiuntivo Type_IP_v4 nelle tabelle ConnsParame_new e dell’attributo Addr_v6 nella tabella Elements_new. DVDB, Area Device e Area SMNP:



Pagina 96 di 189

Figura 3.10: Schema Fisico del GSDB, Area Device e Area SMNP

In questa figura si può notare la presenza degli attributi aggiuntivi Type_IP_v4_Secure e Type_IP_v4_Gest nella tabella Device e dell’attributo aggiuntivo Type_IP_v4 nelle tabelle PHysicalInterfaces e SMNPManager. DVDB, Area Rules Access List:



Pagina 97 di 189

Figura 3.11: Schema Fisico del GSDB, Area Rules Access List

In questa figura si può notare la presenza degli attributi aggiuntivi Type_IP_v4_Secure e Type_IP_v4_Gest nella tabella Device e dell’attributo aggiuntivo Type_IP_v4 nelle tabelle RulesAccessList, MapIsakmp e MapManual. DVDB, Area Firewall:



Pagina 98 di 189

Figura 3.12: Schema Fisico del GSDB, Area Firewall

In questa figura si può notare la presenza degli attributi aggiuntivi Type_IP_v4_Secure e Type_IP_v4_Gest nella tabella Device e dell’attributo aggiuntivo Type_IP_v4 nelle tabelle RulesFirewall e SasfwIpDb.



Pagina 99 di 189

44 RReeaalliizzzzaazziioonnee ddeellll’’AAlliiggeerr Nei paragrafi seguenti di questo Capitolo verrà presentato il progetto SAS‐Price e il Security Framework, ovvero il “contenitore” dei moduli software che realizzano il progetto oggetto di questa tesi. Saranno quindi presentati gli strumenti ed i software utilizzati in questa fase e verranno descritte le modifiche che sono state operate all’interno del Security Framework per rendere possibile, a seguito dell’integrazione di IPv6, il completamento del progetto SAS‐Price. In particolare è stato necessario implementare un modulo software ex‐novo per permettere l’allineamento tra il GSDB e l’SMDB ovvero tra il Global Smart Database di nuova progettazione e il database del SAS‐Manager (cfr. par. 3.1.2). Una volta effettuato l’allineamento tra questi due database il progetto sarà completo in quanto sarà possibile visualizzare i risultati del lavoro effettuato finora sui database direttamente tramite la GUI dell’NMS SAS‐Manager. Poiché il SAS‐Manager è un prodotto AMTEC che viene realizzato per semplificare il compito della gestione di una rete complessa da parte dell’amministratore di rete, a seguito del lavoro effettuato in questa tesi, è ora possibile vedere il risultato del lavoro di molte altre tesi che hanno portato alla realizzazione del GSDB, del DVDB e del Security Framework. Inoltre, è stato ottenuto un risultato che ha permesso di ottenere un’evoluzione del prodotto il SAS‐Manager che conferisce un valore aggiunto al prodotto stesso e risulta di notevole utilità per l’azienda.

4.1 STRUMENTI DI SVILUPPO

4.1.1 Piattaforma .NET Per la realizzazione del progetto esposto nel precedente capitolo è stata utilizzata la suite di prodotti .NET. .NET è un progetto relativamente recente (la prima release è del 2002, mentre la versione attuale, il .NET Framework 3.0, è stata rilasciata nel Novembre 2006) all’interno del quale Microsoft ha incluso una piattaforma completa per lo sviluppo di applicativi, caratterizzata da indipendenza dall’architettura hardware e software sottostante, trasparenza rispetto alla rete, estrema



Pagina 100 di 189

rapidità di sviluppo delle applicazioni tramite una serie di procedure guidate e modelli di applicazioni “standard” per diverse esigenze. L’interfaccia principale del Visual Studio mostrato nella figura seguente:

Figura 4.1: Schermata principale di Microsoft Visual Studio

Include molte funzionalità appositamente pensate per integrarsi senza sforzo nell’ambiente delle reti TCP/IP e garantire sicurezza ed integrità dei dati. Utilizza estensivamente il concetto di modularità del software (Component Oriented Programming), proponendosi così come evoluzione dellʹesistente modello COM (Component Object Model), la tecnologia di software a componenti su cui Microsoft ha puntato maggiormente in passato per lo sviluppo su larga scala di applicazioni: .NET è destinato a sostituire COM come modello architetturale di software a componenti. La CLI (Common Language Infrastructure) è una macchina virtuale (simile alla Java Virtual Machine per l’uso di un bytecode intermedio fra il software applicativo e la macchina che lo esegue) che, insieme alla classe di librerie di base denominata CLR (Common Language Runtime), è progettata per poter funzionare con



Pagina 101 di 189

qualsiasi sistema operativo ed hardware sottostante. La macchina virtuale esegue un codice assembly denominato CIL (Common Intermediate Language). È inoltre possibile:

- Accedere a componenti scritti in altri linguaggi; - Accedere ai servizi e alle API del sistema operativo sottostante (solo

per Microsoft Windows); - Accedere ai Servizi Web utilizzando il protocollo SOAP (Simple Object

Access Protocol). La CLI è compatibile con qualsiasi linguaggio di alto livello orientato agli oggetti e fornisce una vasta libreria di classi condivisibili. In particolare i linguaggi integrati nell’IDE (Integrated Development Environment) cioè nell’ambiente di sviluppo Visual Studio sono:

- C#: linguaggio ad oggetti simile al Java della Sun Microsystems; - Visual Basic .NET: un nuovo linguaggio orientato agli oggetti e multi‐

threaded basato sulla semplice sintassi del VisualBasic; - J#: variante di J++ (la versione Microsoft di Java); - Managed C++: una variante del C++ per la piattaforma .NET.

4.1.2 C# Fra i vari linguaggi disponibili all’interno dell’IDE, per lo sviluppo del progetto è stato utilizzato il C# che è un linguaggio di estrema semplicità e potenza espressiva. Il C#, in un certo senso, descrive meglio degli altri linguaggi di programmazione le linee guida sulle quali gira ogni programma .NET. Il C# è stato, infatti, creato da Microsoft per la programmazione nel Framework .NET. I suoi tipi di dati primitivi hanno una corrispondenza univoca con i tipi .NET e molte delle sue astrazioni, come classi, interfacce, delegati ed eccezioni, espongono esplicitamente caratteristiche proprie del .NET framework. La sintassi del C# prende spunto da quella del Delphi, del C++, da quella di Java ed a Visual Basic per gli strumenti di programmazione visuale e per la sua semplicità. In confronto a questi linguaggi, ha subito una serie di modifiche che lo rendono adatto a scrivere codice sicuro e in una certa misura protetto da tipiche vulnerabilità quali buffer overflow ed esecuzione e/o



Pagina 102 di 189

invocazione non controllata di particolari funzioni di sistema, causate principalmente da errori tipici della programmazione C e C++. In particolare:

- I puntatori possono essere utilizzati solo in particolari blocchi di codice marcati come ʺunsafeʺ;

- In molte operazioni aritmetiche vengono controllati eventuali ʺoverflowʺ;

- Gli oggetti dinamici non vengono deallocati esplicitamente; la loro rimozione viene gestita automaticamente (implicitamente) da un ʺgarbage‐collectorʺ quando non esistono più riferimenti a tali oggetti. Questa gestione evita i due problemi ben noti dei dangling pointer (puntatore che non punta ad un’area di memoria valida) e del memory leak (particolare tipo di consumo non voluto di memoria dovuto da un processo che non riesce a rilasciare la memoria dinamica non più necessaria);

- Le sole conversioni implicite che sono consentite sono quelle ʺsafeʺ, ovvero che non espongono al rischio di perdita di dati causata dalla diversa tipologia di dato;

Il C# è inoltre uno dei pochi linguaggi di programmazione approvato come standard ECMA (European Computer Manufacturers Association).

4.1.3 DataSet Dovendo scrivere ed ottenere dati da database implementati secondo lo standard SQL Server 2005: il DVDB, il GSDB e l’SMDB è stato necessario fare interagire il linguaggio C# con queste strutture contenenti tutte le informazioni di interesse per le applicazioni. A tale scopo è stata utilizzata una delle funzionalità messe e disposizione dall’IDE del Visual Studio: i DataSet. Un DataSet costituisce un contenitore di dati disconnesso, ovvero indipendente dalla particolare fonte di dati, per l’archiviazione e la manipolazione di informazioni. Questo include le tabelle in cui sono contenuti, ordinati e vincolati, i dati e le relazioni tra le tabelle secondo il medesimo modello a oggetti gerarchico di un database relazionale. È possibile creare, modificare e importare DataSet utilizzando in maniera semplice e diretta lo spazio dei nomi appartenenti al namespace principale



Pagina 103 di 189

System.Data all’interno del .NET Framework. Ciascuna tabella viene memorizzata nell’oggetto DataTable, referenziata dalla proprietà Tables, mentre ciascun record è rappresentato dall’oggetto DataRow, referenziato dalla proprietà Rows della DataTable. Si hanno quindi le seguenti classi: ‐ DataSet: in cui sono inclusi gli insiemi: ‐ Tables: (di tipo DataTable) insieme delle tabelle di dati; ‐ Relations: che rappresenta le relazioni fra le tabelle.

‐ DataTables: in cui sono compresi gli insiemi: ‐ Rows: insieme delle righe delle tabelle; ‐ Columns: insieme delle colonne delle tabelle.

Figura 4.2: Esempio di tabella del DataSet

Dalla figura sopra è possibile vedere facilmente l’organizzazione in righe e colonne di una tabella di un DataSet, del tutto simile a quella di un database relazionale. È possibile ad esempio accedere alla tabella miaTabella del DataSet mioDataSet semplicemente scrivendo:

mioDataSet.Tables[“miaTabella”] mentre una specifica riga con un particolare Id = mioId potrà essere referenziata come:

mioDataSet.Tables[“miaTabella”].Rows.Select(“Id=”, “mioId”).



Pagina 104 di 189

Il DataSet è stato finora descritto come un contenitore di dati senza fare cenno ai metodi usati per popolarlo da fonti esterne. Tale importazione avviene attraverso l’oggetto DataAdapter. Il DataAdapter è sostanzialmente l’oggetto che permette di far comunicare una fonte dati con un DataSet. In questo caso si ha l’oggetto SqlDataAdapter per database SQL Server, ma sono disponibili altri DataAdapter per l’importazione da tutti i sistemi di gestione dati più diffusi. Il codice che esegue l’import dei dati è semplice: public void Fill_GSDBdataSet() { SqlConnection ConnFill = new SqlConnection(connessioneGSDB); ConnFill.Open(); foreach (DataTable tabella in gSDBDataSet.Tables) { string nome = tabella.TableName; SqlDataAdapter adattatore = new SqlDataAdapter("SELECT * FROM " + nome, ConnFill); adattatore.Fill(gSDBDataSet, nome); } ConnFill.Close(); }

Le righe di codice di cui sopra popolano interamente il DataSet a partire dal GSDB. L’ultima importante funzionalità permessa dall’uso di questa struttura è la sua completa interoperabilità con XML. La struttura di un intero DataSet, infatti, incluse tabelle, colonne, relazioni e vincoli, può essere definita in uno schema XML. È inoltre possibile leggere o scrivere uno schema XML esterno tramite i metodi ReadXmlSchema() e WriteXmlSchema(), dando così modo di esportare od importare la struttura dati della propria applicazione in maniera universale ed estremamente efficiente; tramite il metodo InferXmlSchema() è anche possibile ricavare uno schema di dati da qualsiasi documento XML strutturato anche non contenente schemi espliciti. Si può leggere un documento XML ed importarlo interamente in un DataSet che ne ricalchi la struttura tramite il metodo ReadXml(), ed esportare l’intero DataSet in formato XML tramite WriteXml(). Essendo XML un formato standardizzato dal W3C (World Wide Web Consortium) è possibile di fatto caricare od esportare dati da o verso qualsiasi altra applicazione in grado di leggere/scrivere un file XML. Le potenzialità di questa funzione del DataSet possono portare ad una completa interoperabilità fra apparati e software di qualsiasi produttore.



Pagina 105 di 189

4.2 SECURITY FRAMEWORK Il Security Framework è un progetto scritto in C# che racchiude tutti i moduli software che sono stati realizzati all’interno del progetto SAS‐Price. Si compone di un’interfaccia grafica che permette di attivare le singole funzionalità. L’interfaccia è mostrata nella figura di seguito:

Figura 4.3: Security Framework, schermata principale

4.2.1 Modulo Popolatore Il modulo popolatore interpreta i comandi del sistema operativo GAIA degli apparati SAS prodotti da AMTEC e popola il Device Database con le configurazioni degli stessi apparati. I file di configurazione interpretati sono in formato bytecode ASN.1 (Abstract Syntax Notation One) ovvero una notazione usata per descrivere tipi astratti e valori. Ciascun elemento ASN.1 che descrive un comando GAIA ha la struttura divisa in tre parti:

Ottetto identificatore, che identifica la classe ed il tipo semplice ASN.1 usato;

Lunghezza degli ottetti, poiché per un metodo strutturato non si sa a priori quanto esso possa essere lungo;

Contenuto degli ottetti, che contiene il valore dellʹelemento. Il tipo OID (Object Identifier) è una sequenza di interi che identificano un oggetto come un algoritmo o un tipo di attributo. Il suo valore può avere un



Pagina 106 di 189

qualsiasi numero di componenti, i quali generalmente non hanno valore negativo. È stata definita una classe astratta Regola e per il riconoscimento di ogni comando è stata creata una classe che eredita da Regola che gestisce il comando inserendo i dati nel DataSet. Il principale attributo pubblico di Regola è OID, che è una Lista contenente tutti i codici ASN.1 cui fa riferimento la specifica regola. La classe Regola possiede il metodo pubblico astratto Insert(), che ha per parametri il comando e un intero per il DeviceId, con il quale si inserisce nella struttura dati il dato comando afferente al DeviceId ricevuto come parametro.

Figura 4.4: Security Framework, Modulo Popolatore

All’avvio dell’interfaccia grafica (vedi Figura 4.4) l’utente può scegliere un percorso per le configurazioni, indicando una cartella del sistema in cui sono presenti i file (testo o ASN.1) che si intendono acquisire. All’avvio del processo di acquisizione, attraverso il pulsante Avvia dell’interfaccia grafica, il modulo accede al path delle configurazioni indicato, e per i file in formato testo provvede a tradurle in formato ASN.1 attraverso l’interazione con il modulo Convertitore. Ogni file esaminato, secondo l’ordine con cui il modulo li ha acquisiti, costituisce un nuovo dispositivo.



Pagina 107 di 189

Ottenuti gli elenchi di configurazione in bytecode esadecimale, questi vengono analizzati (uno alla volta) riga per riga, leggendone l’OID e cercando tra le regole definite quelle che hanno l’OID della regola nel loro attributo OID. Il vantaggio di aver convertito in formato ASN.1 è che in questo modo i file hanno già subito il processo di Parse dei comandi, semplificandone il riconoscimento. Il modulo software, per ogni nuovo dispositivo di cui si sta acquisendo la configurazione, crea una nuova tupla della tabella Device, e manterrà il campo Id in memoria come variabile di DeviceId da passare alle varie classi di inserimento regole. Per ogni OID di configurazione riconosciuto da una regola, si chiama il metodo Insert() della relativa classe, che esegue le operazioni definite di inserimento nelle tabelle del DataSet (conoscendo il DeviceId da modificare) ed eventuali controlli di integrità. Attraverso i controlli che una regola implementa nel metodo Insert() è possibile avvisare l’utente, tramite messaggi di allarme, di eventuali incongruenze nel comando. Di seguito è riportata a titolo di esempio la classe Firewall_On, che implementa Regola e inserisce nel Device Database l’informazione che il Firewall di un apparato è attivo. class Firewall_On : Regola { protected override void Insert(Comando comando, int DeviceID) { DeviceDBDataSet.DEViceRow riga = (DeviceDBDataSet.DEViceRow)dataset.DEVice.Rows.Find(DeviceID); System.Diagnostics.Debug.Assert(riga != null, "Il device " + DeviceID + " non è presente"); if ((ASN1Tools.GetBytes(comando.OID))[2] == 1) {//Il comando è di inserimento riga.FirewallStatus_DEV = true; } else {//Il comando è di cancellazione riga.FirewallStatus_DEV = false; } } public Firewall_On() { OID.Add(ASN1Tools.GetUL(new Byte[] { 0x29, 44, 1 })); } }



Pagina 108 di 189

4.2.2 Modulo Visualizzatore Il modulo visualizzatore fornisce una interfaccia grafica semplice ed intuitiva per la consultazione dei DataSet durante l’esecuzione del Framework (vedi Figura 4.5).

Figura 4.5: Security Framework, Modulo Visualizzatore

Per il modulo visualizzatore è stato fatto ampio uso della classe DataGridView che fornisce una tabella personalizzabile per la visualizzazione dei dati e consente la personalizzazione di celle, righe, colonne e bordi; è possibile inoltre impostare le proprietà DataSource e DataMember per associare DataGridView a unʹorigine dati e inserire automaticamente i dati nel controllo. All’interno dell’interfaccia esistono due ComboBox, nella prima vengono inseriti i nomi dei DataSet disponibili nel SAS‐Price: foreach (DataSet data in ListaDataset) { comboBox1.Items.Add(data.DataSetName); }

Quando il DataSet selezionato nella prima ComboBox cambia, nella seconda sono visualizzate tutte le tabelle dello specifico DataSet indicato nella prima: private void comboBox1_SelectedIndexChanged(object sender, EventArgs e) { ComboBox Sender = sender as ComboBox; foreach (DataSet data in ListaDataset) {



Pagina 109 di 189

if (data.DataSetName.Equals((string)Sender.SelectedItem)) { currentDataSet = data; comboBox2.Items.Clear(); foreach (DataTable tabella in data.Tables) { comboBox2.Items.Add(tabella.TableName); } } } }

Infine un’ultima porzione di codice inserisce nel visualizzatore DataGridView i dati della tabella che è stata selezionata tramite il codice precedente: private void comboBox2_SelectedIndexChanged(object sender, EventArgs e) { ComboBox Sender = sender as ComboBox; foreach (DataTable tabella in currentDataSet.Tables) { if (tabella.TableName.Equals((string)Sender.SelectedItem)) { dataGridView.DataSource = currentDataSet; dataGridView.DataMember = tabella.TableName; dataGridView.Update(); } } }

4.2.3 Modulo Traduttore CSV Il traduttore CSV nasce dall’esigenza pratica di riuscire a inserire all’interno del NMS SAS Manager una grande quantità di apparati in modo veloce ed automatico. Il SAS Manager a questo fine dispone di una utility che permette di importare gli apparati ed un insieme minimo di dati che consenta la loro raggiungibilità in rete direttamente da un file in formato CSV (Comma Separated Values) con un formato specifico, in cui ogni riga deve contenere le seguenti informazioni:

Tipo: tipo del nodo (campo opzionale); Nome: nome da assegnare al nodo (campo obbligatorio); Indirizzo di Gestione: indirizzo IP da utilizzare per la gestione del nodo (campo obbligatorio);

Community GET: community da utilizzare per le operazioni di GET SNMP sul nodo (campo opzionale);

Community SET: community da utilizzare per le operazioni di SET SNMP sul nodo (campo opzionale);



Pagina 110 di 189

Interfaccia di Gestione: interfaccia associata all’indirizzo di gestione del nodo (campo opzionale);

Indirizzo di Sicurezza: indirizzo IP da utilizzare per la sicurezza sul nodo (campo opzionale);

Interfaccia di Sicurezza: interfaccia associata all’indirizzo di sicurezza del nodo (campo opzionale).

Il modulo Traduttore CSV interroga il Device Database che contiene le informazioni su ogni apparato e prepara un file CSV secondo il formato specificato comprensibile dal SAS Manager. Si riporta a titolo esemplificativo la porzione di codice che scrive le righe relative alle community SNMP: if (rigaDEV.SNMPStatus_DEV == true) // elaboro community SNMP se esistono { foreach (DeviceDbDataSet.SNMPCommunityRow rigaSNMP in (DeviceDbDataSet.SNMPCommunityRow[])deviceDbDataSet.SNMPCommunity.Select("Id_DEV =" + rigaDEV.Id_DEV, "Type_SNC DESC")) { switch (rigaSNMP.Type_SNC) { case "RW": { S = rigaSNMP.Name_SNC; richTextBox1.AppendText(S + ";" + S + ";"); // Scrivo entrambe le community get e set nel Text Box break; } case "RO": { S = rigaSNMP.Name_SNC; richTextBox1.AppendText(S + "; ;"); // Scrivo solo la community set nel Text Box break; } break; // esce dal foreach trovata la prima community SNMP } } else richTextBox1.AppendText("; ;"); // se SNMP non c'è scrivo due spazi vuoti S = ""; S1 = ""; S2 = ""; // "svuoto" tutte le stringhe di appoggio }

Quest’applicazione, sebbene di utilizzo e realizzazione estremamente semplice, ha permesso con piccole modifiche l’import di più di 2000 SAS contribuendo a rendere possibile l’infrastruttura di rete gestita tramite SAS Manager con il maggior numero di apparati mai realizzata.



Pagina 111 di 189

4.2.4 Moduli Split e Compose Le due funzioni di Split e Compose mantengono l’allineamento e la consistenza dei dati fra il Device Database e il Global Smart Database:

La funzione di Split prende in input il modello globale contenuto nel GSDB e restituisce in output quello locale del DVDB;

La funzione di Compose è in grado di ricostruire il modello globale di una S‐VPN nel GSDB partendo dalle informazioni locali del DVDB.

Entrambe le basi di dati rappresentano la medesima architettura da due punti di vista diversi, ovvero quello locale, visto apparato per apparato, e quello globale, visto del Network Management System. Contengono quindi dati relativi alla stessa S‐VPN ed è per questo fondamentale curarne la consistenza per non incorrere in disallineamenti fra le informazioni per l’architettura di gestione e quelle per la risoluzione dei conflitti. La Split permette di passare in maniera automatizzata (e quindi esente da errori) dal database globale dell’intera architettura GSDB al database puntuale DVDB per ricavare poi le configurazioni di tutti gli apparati di rete, traducendole in veri e propri file di configurazione tramite il modulo Traduttore del SAS‐Price. Al contrario la Compose permette di aggregare un qualsiasi numero di architetture formate da un insieme di apparati SAS, precedentemente importati nel DVDB dal modulo Popolatore, fornendone la visione di rete globale nel GSDB.

4.3 IMPLEMENTAZIONE DELL’ALIGNER In questo paragrafo sono illustrate le fasi di progettazione dell’Aligner per permettere l’allineamento tra il GSDB e l’SMDB. In particolare sono descritte le fasi di connessione ai Database, gli obiettivi di progetto, l’analisi di compatibilità tra i database e la realizzazione delle corrispondenze dei campi dei DB tramite il codice C#.

4.3.1 Connessione ai DataBase Il primo passo fondamentale necessario per effettuare il completamento del progetto finora realizzato, è stato quello di fare in modo che tutti i moduli



Pagina 112 di 189

software che compongono il Security Framework scrivano ed ottengano i dati dallo stesso gruppo di database implementati secondo lo standard SQL Server 2005, ovvero accedano allo stesso DVDB, GSDB ed SMDB modificati in modo che implementino IPv6 secondo quanto descritto nel Capitolo 3. Quindi è stato necessario modificare ogni modulo software presente nel Framework in modo che avesse le seguenti stringhe di connessione: string connessioneEDB = @"Data Source=(local)\SQLEXPRESS;Initial Catalog=EDB;Integrated Security=SSPI"; string connessioneDVDB = @"Data Source=(local)\SQLEXPRESS;Initial Catalog=DVDB;Integrated Security=SSPI"; string connessioneSMDB = @"Data Source=(local)\SQLEXPRESS;Initial Catalog=SMDB;Integrated Security=SSPI";

Tali stringhe di connessione permettono di accedere direttamente al database presente in SQ L Server. Infatti, il C# eseguirà un controllo all’interno di SQL e nel momento in cui troverà dei database nominati EDB (ovvero GSDB), DVDB e SMDB rimanderà la rispettiva stringa di connessione a tali database. In questo modo si potrà lavorare direttamente sui database modificati tramite SQL Server. Se in SQL non dovesse esserci alcun database nominato EDB, DVDB oppure SMDB durante la fase di collegamento il C# solleverà un errore.

4.3.2 Evoluzione del progetto Il progetto SAS Price che è stato finora realizzato è formato da più sottosistemi che, compiendo ciascuno determinate operazioni, consentono di raggiungere un obiettivo comune: l’allineamento complessivo e corretto della rete, finalizzata ad una semplificazione della gestione della rete gestendo i conflitti tra policy di sicurezza. Partendo da configurazioni di dispositivi SAS in formato testo, è possibile popolare il DVDB tramite il modulo Popolatore. Dal DVDB è possibile verificare la correttezza delle configurazioni di partenza tramite il modulo Risolutore dei conflitti. Una volta ottenuto il DVDB correttamente popolato (senza errori di configurazione dei dispositivi) il modulo Compose è in grado



Pagina 113 di 189

di passare dal DVDB (rappresentazione puntuale della rete) al GSDB (rappresentazione globale della rete). A completamento di tale progetto e oggetto di questo Capitolo è l’implementazione di un altro modulo chiamato Aligner. Tale modulo permettere all’SMDB di essere allineato al GSDB corretto. In tal modo, una volta popolato l’SMDB, ovvero il database del SAS Manager sarà possibile visualizzare tramite l’apposita interfaccia grafica dell’NMS la struttura dell’intera rete e sarà possibile modificarla e gestire i singoli dispositivi SAS che la compongono. [1], [5] Per realizzare l’interoperabilità dei moduli contenuti nel Security Framework e il SAS Manager è necessario che il GSDB sia allineato all’SMDB. Per questo è stato sviluppato un modulo per l’allineamento tra i due database: l’Aligner. Lo schema di principio di funzionamento dell’Aligner è rappresentato in figura.

Aligner

Aligner

Figura 4.6: Funzioni allineamento GSDB – SMDB

In questo scenario, il database del SAS Manager (SMDB) è diviso logicamente in tre parti:



Pagina 114 di 189

System: tabelle in cui sono presenti informazioni di sistema, ad esempio la versione del software, tabelle con associazione ai file in cui sono contenuti altri dati, informazioni sul layout grafico ecc...

Management: tabelle in cui sono presenti informazioni aggiuntive che non riguardano le S‐VPN e che fanno riferimento alla parte di gestione dei dispositivi.

Old S‐VPN: tabelle che contengono informazioni riguardanti le configurazioni di S‐VPN.

A queste tre aree logiche si affianca la nuova area: New S‐VPN tabelle che contengono tutte le informazioni riguardanti le S‐VPN organizzate in maniera ottimale, ovvero le tabelle del GSDB.

In questo modo si ottiene così una nuova entità logica chiamata EDB che raccoglie sia tutte le tabelle presenti nel SMDB divise nelle tre aree: System, Management, Old S‐VPN e anche tutte le tabelle presenti nel GSDB che appartengono all’uinca area New S‐VPN. L’utilizzo dell’EDB invece che il GSDB, permette quindi di avere in un unico database i dati caratteristici di entrambi i database GSDB e SMDB, con il vantaggio di rendere più semplice la futura migrazione dell’SMDB al GSDB. Infatti, utilizzando l’EDB che già contiene tutte le tabelle dell’SMDB su cui si appoggia il SAS‐Manager, il passaggio al nuovo database può essere fatto in modo pressochè immediato e senza impatti significativi nella riscrittura del codice software dell’NMS. Le funzioni di allineamento tra l’SMDB ed il GSDB sono rappresentate da un allineamento tra la parte Old S‐VPN e la parte New S‐VPN, lasciando inalterate le altre tabelle utili al software e native nell’nms (ad esempio la tabella DBVERSION contiene informazioni cablate relative alla versione del database). In questo modo il SAS Manager continua a far riferimento al SMDB ma i dati scritti in questo database sono presi dal GSDB e copiati grazie alle funzioni di allineamento realizzate dall’Aligner. Gli algoritmi di Split e Compose realizzano così un legame tra la visione globale del SAS Manager e quindi del GSDB, con la visione puntuale del DVDB sul quale si effettua la risoluzione dei conflitti, completando l’evoluzione e realizzando le finalità del progetto SAS‐Price.



Pagina 115 di 189

4.3.3 Compatibilità tra GSDB e SMDB Nella prima parte del lavoro di progettazione dell’Aligner si è cercato di confrontare il nuovo modello nel GSDB con il precedente sistema di gestione dati del SAS Manager presente nell’SMDB, essenzialmente al fine di valutare l’entità del lavoro da effettuare tramite questo modulo software. Il diagramma logico secondo il paradigma Entità‐Relazione del SMDB è visibile nella figura seguente ed in Appendice C ne è riportato un estratto significativo del dizionario dei dati.



Pagina 116 di 189

Figura 4.7: Diagramma E‐R dell’SMDB



Pagina 117 di 189

Dalla sua analisi è possibile verificare la presenza di molte entità non direttamente attinenti alla gestione della S‐VPN. I risultati dell’analisi della compatibilità tra l’SMDB e il GSDB sono stati formalizzati nel seguente grafico:

Figura 4.8: Compatibilità GSDB – SMDB

È risultato che tra i campi inclusi nel SMDB e utilizzati dal SAS Manager:

66% è gestito dal GSDB in maniera analoga o in modo assolutamente compatibile. Tali campi sono elaborati e copiati dal GSDB all’SMDB ad opera dell’Aliger;

5,8% è va incontro a modifiche significative del codice del SAS Manager e dovrà essere elaborato dagli specialisti di questo software del laboratorio AMTEC;

28,2% è giudicato non attinente alle informazioni di S‐VPN e quindi è fatto confluire invariato nella sezione logica delle tabelle di gestione. Ovvero sono dei campi che non subiranno elaborazione ad opera dell’Aligner ma verranno lasciati invariati nell’opera di allineamento da GSDB a SMDB in quanto saranno popolati da file CSV in modo indipendente al Security Framework.

4.3.4 Elaborazione delle informazioni delle tabelle Come è stato precedentemente osservato, il database del SAS Manager (SMDB) è diviso in tre aree logiche. Verranno ora analizzate le tabelle corrispondenti a ciascuna area. La trattazione dei campi di alcune delle tabelle principali tramite l’utilizzo del codice C# è riportato in Appendice D.



Pagina 118 di 189

Area MANAGEMENT Le tabelle contenute in quest’area non verranno prese in considerazione dal modulo Aligner perché riguardano informazioni di gestione dei dispositivi elaborate da parte dell’NMS. Tali tabelle sono:

ACTIONS: azioni associate a determinati eventi (allarmi, guasti, ecc.); CONF: elenco delle configurazioni disponibili per ogni apparato della rete;

CONFVPNC: riferimento ai files di configurazione dei client di VPN, ovvero singoli PC che partecipano alla S‐VPN tramite apposito software di cifratura (AMTEC CryptoIP).

NODEWARN: lista di gateway e nodi in stato di warning. SCHEDOP: Upload/Download delle configurazioni degli apparati programmati a tabella oraria (Scheduled Operations).

SOFT: riferimento ai files di firmware degli apparati, per upload/download.

Area SYSTEM Le tabelle contenute in quest’area non verranno prese in considerazione dal modulo Aligner perché riguardano informazioni di sistema. Tali tabelle sono:

BACKMAP: riferimento ai files di sfondi grafici delle mappe di reti e VPN.

DBVERSION: versione dello schema del database. GTW_LOG: riferimento ai files contenenti i messaggi di ʹsyslogʹ prodotti dagli apparati e ricevuti dal SAS‐Manager.

IDPROGR: tabella di servizio per mantenere i progressivi da usare come ID delle tabelle.

NETS: contiene informazioni per le rappresentazioni grafiche delle reti. USERS: utenti della Console SAS‐Manager. VPNSAS: posizionamento nel layout grafico degli elementi delle vpn.

Area S‐VPN Nell’analisi per la realizzazione del modulo Aligner sono state considereranno solo le tabelle dell’area S‐VPN, effettuando un confronto con il modello identificato ed implementato nel GSDB. Tali tabelle sono:



Pagina 119 di 189

SAS, SAS2: tabelle che contengono le informazioni relative ai SAS (Security Gateway). Queste tabelle contengono informazioni che sono scritte dal SAS‐Manager a partire da file CSV. Si è scelto di procedere con un database non completamente vuoto all’inizio del popolamento dell’SMDB a partire dal GSDB, perché la situazione più diffusa di un possibile utilizzo del Security Framework è quella in cui ci si trova di fronte all’SMDB popolato con le configurazioni di rete dei SAS prive della parte relativa alla sicurezza. Tale parte è quella che deve subire il controllo di correttezza da parte del modulo Risolutore dei conflitti all’interno del Security Framework, quindi è quella che andrà scritta infine nell’SMDB. Inoltre, la tabella SAS contiene alcuni campi cifrati (PSSW_R e PSSW_W ovvero le password di lettura e scrittura sul dispositivo). Tali campi possono essere scritti solo dal SAS‐Manager che utilizza un algoritmo proprietario di cifratura. Se l’NMS al momento dell’apertura dell’SMDB non riconosce tali campi cifrati dal proprio algoritmo solleva un errore e non permette l’apertura della stessa interfaccia grafica del software. Diventa impossibile, in questo caso, alcuna oprazione sui dispositivi e sul database. Tali campi cifrati devono perciò necessariamente essere scritti dal SAS‐Manager. La situazione di partenza è quella in cui il SAS‐Manager popola parzialmente le tabelle SAS e SAS2 con alcune informazioni relative ai nodi presenti nella rete (ID, tipo, nome, indirizzo, password del dispositivo …) e la scrittura dei campi di tali tabelle deve essere completata dall’Aligner. Le informazioni che devono essere scritte in questa tabella dall’Aligner sono distribuite fra le tabelle Devices_new, Interfaces_new, SubInterfaces_new. Per selezionare le righe in cui inserire le informazioni mancanti è stato effettuato un ciclo iniziale: foreach (SASDataSet.sasRow sasrows in sasDataSet.sas.Rows) che seleziona ad ogni ciclo una riga della tabella SAS dell’SMDB. Successivamente è stato usato il metodo GetTupla (per la definizione del metodo vedi Appendice D): public static System.Data.DataRow GetTupla(System.Data.DataSet dataset, string

nomeTabella, params object[] coppie) tale metodo prende in ingresso quattro variabili: il nome del dataset, il nome della tabella all’interno del dataset, e la coppia con il nome della colonna e il valore cercato relativo a quella colonna. Il metodo, in base a



Pagina 120 di 189

tali parametri, ritorna la riga corrispndente al dataset, alla tabella e alla coppia con il nome‐valore della colonna. La riga: EDBDataSet.Device_newRow devicenew = (EDBDataSet.Device_newRow)

CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Device_new.TableName, "Name_DEV",

sasrow.NAME); cerca all’interno dell’eDBDataSet (dataset relativo al GSDB) nella tabella Device_new e nella colonna che si chiama ʺName_DEVʺ il valore corrispondente alla colonna chiamata ʺNAMEʺ della tabella SAS dell’SMDB corrispondente alla riga del ciclo i‐esimo relativo al foreach di riferimento. In pratica viene usato il nome del dispositivo, che rimane inalterato nel processo di modifica delle informazioni attraverso i cicli del Security Framework, per assegnare le informazioni mancanti al dispositivo stesso nella tabella SAS e SAS2 dell’SMDB a partire dalla tabella Device_new del GSDB. Successivamente viene stato usato il metodo GetTupla per ricercare le informazioni mancanti anche nelle altre tabelle del GSDB (Interfaces_new, SubInterfaces_new, …).

CONNS: tabella relativa alle connessioni fra gli elementi delle VPN. Le informazioni della tabella CONNS sono distribuite nel GSDB fra diverse tabelle, ovvero CONNs_new, CONNsParam_new, IKEArea_new. Alcune informazioni sulla policy IKE precedentemente contenute in CONNS (ad esempio la preshared key) sono confluite naturalmente nelle tabelle IKEArea_New e IKEPolicy_new. La scelta di dividere le informazioni propriamente di connessione in due tabelle, CONNs_new e CONNsParam_new è dovuta alla volontà di non appesantire CONNs_new con un numero eccessivo di attributi, rappresentando quest’ultima una relazione di quinto grado già di per sé complessa. Per estrapolare le informazioni da inserire in questa tabella è stato effettuato un ciclo iniziale: foreach (EDBDataSet.CONNs_newRow connsnewrow in eDBDataSet.CONNs_new.Rows) che scrivesse una riga della tabella CONNs dell’SMDB per ognuna delle righe CONNS_new del GSDB. Successivamente è stato usato il metodo GetTupla per richiamare le informazioni corrispondenti ad esempio nella tabella CONNsParam_new: EDBDataSet.CONNsParam_newRow connsparam = (EDBDataSet.CONNsParam_newRow)

CoseUtili.GetTupla(eDBDataSet, eDBDataSet.CONNsParam_new.TableName, "CONPAR_Id"

, connsnewrow.CONPAR_Id);



Pagina 121 di 189

cerca all’interno dell’eDBDataSet nella tabella CONNsParam_new e nella colonna che si chiama ʺCONPAR_Idʺ il valore corrispondente alla colonna chiamata ʺCONPAR_Idʺ della tabella CONNs_new dell’SMDB corrispondente alla riga del ciclo i‐esimo relativo al foreach di riferimento. In pratica vengono sfruttate le relazioni esistenti tra le tabelle del GSDB (ʺCONPAR_Idʺ rappresenta un vincolo di chiave esterna della tabella CONNs_new e chiave primaria della tabella CONNsParam_new) per ricavare le informazioni di una tabella dell’SMDB che sono distribuite su più tabelle del GSDB. Successivamente viene stato usato il metodo GetTupla per ricercare le informazioni mancanti anche nelle altre tabelle del GSDB.

EXTRAVPN: tabella relativa ai flussi di traffico in chiaro consentiti. Le ExtraVPN sono flussi di traffico a cui è permesso di passare in chiaro senza elaborazione attraverso il Security Gateway. Nell’architettura del GSDB vengono gestite come una normale connessione fra elementi in cui uno dei due è protetto da un apparato virtuale appositamente definito, detto Nobody ed ha policy IKE e IPSec nulle. Il SAS Nobody rappresenta dunque tutte le connessioni in chiaro dell’architettura: in questa maniera si ottiene maggiore uniformità e compattezza nel trattamento dei dati, potendo riutilizzare tabelle già definite riadattandole per rappresentare concetti differenti. Quindi le informazioni da inserire in questa tabella verranno ricavate a partire dallo stesso ciclo foreach del punto precedente (tabella CONNs) in cui è effettuato un controllo relativo ai due device che fanno parte della connessione esaminata: string daName = devicea.Name_DEV.ToUpper();

string dbName = deviceb.Name_DEV.ToUpper();

if ((daName == "NOBODY") || (dbName == "NOBODY")) ovvero, vengono ricavati i device che fanno parte della connessione relativa al ciclo foreach i‐esimo. Si controlla se uno dei due device si chiama NOBODY (il metodo chiamato sul nome del device ToUpper permette di modificare il nome interamente in maiuscolo in modo da evitare errori dovuti al Case‐Sensitive). Nel caso in cui uno dei due device è il SAS Nobody allora il contenuto della riga relativa alla tabella CONNs_new del GSDB esaminata è scritto nella tabella EXTRAVPN



Pagina 122 di 189

dell’SMDB, altrimenti verrà scritto nella tabella CONNs già esaminata nel punto precedente.

MNGDATA, MNGNAT, MNGVPN: tabelle relative alle SVPN di gestione. In particolare: - MNGDATA: contiene informazioni per l’identificazione dei Security

Gateway; - MNGNAT: contiene informazioni per l’identificazione dei Security

Gateway in caso di NAT; - MNGVPN: contiene le informazioni per la definizione della SVPN

di gestione. Nel GSDB non esistono elementi dedicati alla definizione delle sole SVPN di gestione. Tale SVPN viene considerata come una particolare Area IKE (tabella IKEArea_new) riconoscibile dal campo Is_Mng che è impostato al valore TRUE. Le connessioni di gestione hanno come coppia di elements il SAS‐Manager, ovvero un elemento (Server di NMS) a maschera piena con il campo Is_Mng abilitato, e un Security Gateway e risulta protetto da se stesso nella relazione Protects_new. In tale architettura è stato adottato lo schema di massimo riutilizzo di concetti ed elementi già esistenti. Quindi le informazioni da inserire in questa tabella sono ancora una volta ricavate a partire dallo stesso ciclo foreach analizzato per la tabella CONNs in cui è effettuato un ulteriore controllo relativo ai due device che fanno parte della connessione esaminata: if ((elementa.Is_Mng == true) || (elementb.Is_Mng == true)) ovvero, vengono ricavati gli element che fanno parte della connessione relativa al ciclo foreach i‐esimo. Si controlla se uno dei due elementi è il SAS‐Manager (tramite check sul campo Is_Mng abilitato) e quindi se la SVPN relativa a tale connessione è la SVPN di gestione. Nel caso in cui uno dei due elements è il SAS‐Manager allora il contenuto della riga relativa alla tabella CONNs_new del GSDB esaminata è scritto nelle tabelle MNGDATA, MNGNAT e MNGVPN dell’SMDB, altrimenti verrà scritto nella tabella CONNs o EXTRAVPN già esaminate nei punti precedenti.

PEERMAP: tabella relativa alle informazioni sui peer della negoziazione IKE. Questi dati sono deducibili dall’analisi congiunta delle tabelle CONNs_new, Elements_new e Protects_new. I peer sono gli



Pagina 123 di 189

apparati che proteggono Elem_A e Elem_B di una connessione CONNs non manuale e che utilizzi IKE per la negoziazione delle chiavi. Aggiungere una tabella apposita per indicare tutti i peer IKE avrebbe comportato una ridondanza non giustificata da alcun vantaggio in termini di maggiore chiarezza o efficienza del modello, quindi nell’SMDB le informazioni di questa tabella sono contenute nella tabella Device_new. Poiché l’entità centrale di questo insieme di tabelle in cui sono distribiute le informazioni su PEERMAP è ancora una volta CONNs_new, le informazioni da inserire in questa tabella sono ancora ricavate a partire dallo stesso ciclo foreach analizzato per la tabella CONNs. Questa volta però in tale ciclo non è effettuato alcun controllo, ma vengono direttamente scritte le informazioni relative ai due device che fanno parte della connessione esaminata.

BKPEER: tabella relativa alla gestione del peer IKE di backup dei gateway. Tale funzionalità è stata completamente rivisitata nel GSDB. Mentre nell’SMDB ad un apparato poteva venire assegnato un singolo peer di backup, nel nuovo modello le tabelle VRRPArea_new e BKArea_new possono organizzare i device in diverse aree di VRRP o Backup. Attraverso la tabella di relazione Protects_new si specifica come ogni elemento possa essere protetto da una BKArea, una VRRPArea o un device singolo. La maggiore complessità della nuova struttura è in questo caso compensata da un aumento notevole della flessibilità e scalabilità nella rappresentazione di S‐VPN in alta affidabilità. Poiché la rappresentazione nell’SMDB è semplificata rispetto alla rappresentazione nel GSDB si ha necessariamente perdita di informazione nel passaggio dal GSDB all’SMDB. Si è qundi pensato di tradurre solamente una delle due tabelle del GSDB (BKArea) nelle informazioni contenute nellla tabella BKPEER dell’SMDB, lasciando l’implementazione del VRRP a futuri sviluppi dell’NMS.

GROUPS: tabella relativa agli elementi (sottoreti) all’interno delle S‐VPN. Tale tabella viene quasi interamente rappresentata nelle nuova tabella Elements_new. La parte relativa ai certificati digitali è stata per migliore leggibilità spostata nella tabella Certificate_new. Quindi i campi della tabella GROUPS sono copiati tramite un foreach sulle righe della tabella Elements_new dell’SMDB ed estraendo gli opportuni dati dalla tabella Certificate_new tramite l’utilizzo del metodo GetTupla.



Pagina 124 di 189

IPNODE: tabella relativa ai nodi generici IP che si possono inserire nel SAS Manager oltre ai Security Gateway. I nodi IP sono gestiti come apparati nella tabella Device_new, disabilitando i campi IPSEC_Status e IKE_Status ad indicare che non si è in presenza di un Security Gateway. I campi della tabella IPNODE sono copiati tramite un foreach sulle righe della tabella Device_new dell’SMDB effettuando un controllo sui campi IPSEC_Status e IKE_Status: if ((devicenew.IKE_Status == false) && (devicenew.IPSec_Status == false)).

IKEPOL: tabella relativa alla definizione delle politiche IKE. Tale tabella è gestita in maniera quasi identica alla tabella IKEPolicy_new del GSDB. I campi della tabella IKEPOL sono copiati tramite un foreach sulle righe della tabella IKEPolicy_new dell’GSDB. Il campo PSKEY che contiene la PresharedKey relativa alla negoziazione deve essere ricavato eseguendo delle query (tramite l’utilizzo del metodo GetTupla) sulla tabella. IKEArea_new del GSDB.

IPSECPOL: tabella relativa alla definizione delle politiche IPSEC. Tale tabella è gestita in maniera quasi identica alla tabella IPSecPolicy_new del GSDB. I campi della tabella IPSECPOL sono copiati tramite un foreach sulle righe della tabella IKEPolicy_new del GSDB. Alcuni campi devono essere ricavati eseguendo delle query (tramite l’utilizzo del metodo GetTupla) anche sulle tabelle CONNs_new e CONNsParam_new.

CA: tabella relativa all’autorità di certificazione. La tabella CA_new del GSDB gestisce le autorità di certificazione in maniera del tutto analoga alla tabella CA dell’SMDB, infatti i campi di tale tabella sono copiati in modo diretto tramite un foreach sulle righe della tabella CA_new del GSDB senza subire elaborazioni.

NATPOOL: tabella relativa al pool di NAT utilizzato dalla funzionalità di NAT su base certificato. Tale tabella è riprodotta ed utilizzata in maniera del tutto simile nella tabella NATCert_new del GSDB. Infatti i campi della tabella NATPOOL sono copiati in modo diretto tramite un foreach sulle righe della tabella NATCert_new del GSDB senza subire elaborazioni.

SERVICES: tabella relativa ai servizi abilitati nella SVPN. Tali servizi sono gestiti in maniera analoga nella tabella CONNsServ_new del GSDB. Infatti i campi della tabella SERVICES sono copiati in modo



Pagina 125 di 189

diretto tramite un foreach sulle righe della tabella CONNsServ_new del GSDB senza subire elaborazioni.

VPNS: tabella che contiene le informazioni riguardanti la policy IKE e IPSec adottata dalle S‐VPN. Tale tabella contiene l’associazione fra una politica IKE ed una IPSec di default per una determinata VPN, è stato integrato in IKEArea_new. Infatti i campi della tabella VPNS sono copiati in modo diretto tramite un foreach sulle righe della tabella IKEArea _new del GSDB senza subire elaborazioni.

CLSERV: tabella relativa ai selettori di traffico per servizi abilitati su particolari porte. Tale tabella è di relazione e non contiene dati da gestire. In particolare il GSDB non contiene informazioni da trasferire in tale tabella.

CONNSERV: tabella relativa all’associazione dei selettori di traffico alle connessioni di VPN. Tale tabella è di relazione e non contiene dati da gestire. In particolare il GSDB non contiene informazioni da trasferire in tale tabella.

TRANSFORMS: tabella che contiene le informazioni per la realizzazione dell’associazione tra politiche IPSec e transform set. Tale tabella gestisce le trasformate crittografiche, ovvero insiemi di primitive crittografiche che sono assegnate in blocco ad una politica IKE o IPSec. Nel GSDB si è scelto di abbandonare il concetto di trasformata che portava al ripetersi degli stessi algoritmi crittografici in diverse occorrenze della tabella e di assegnare la gestione diretta di tali algoritmi presi singolarmente alla tabella CryptoSet_new, a sua volta in relazione con IKEPolicy_new e IPSecPolicy_new tramite IKEAlgotithm ed IPSecAlgorithm. Il contenuto di questa tabella non può essere scritto tramite l’Aligner perché fa riferimento al file esterno (Varie.cpp).

VPNGROUP: tabella che contiene informazioni sulla relazione molti a molti tra GROUPS e VPNS. Il GSDB non contiene informazioni da trasferire in tale tabella.

Le parti più significative del codice C# dell’Aligner sono riportate in Appendice D. Lo schema seguente rappresenta i principali cicli concatenati all’interno dell’Aligner:



Pagina 126 di 189

Figura 4.9: Schema logico dell’Aligner



Pagina 127 di 189

CCOONNCCLLUUSSIIOONNII La trattazione presentata in questa tesi raccoglie i risultati di un lavoro di analisi, di progettazione e di sviluppo realizzato presso il reparto Ingegneria D’Offerta, in collaborazione col reparto Excite Security della Divisione Automazione, Sicurezza e Trasporti all’interno dell’azienda ElsagDatamat S.p.A, società del gruppo Finmeccanica, e inserito nell’ambito di un progetto di ricerca realizzato in collaborazione con il Dipartimento INFOCOM dell’Università Sapienza di Roma. La tematica discussa riguarda la gestione dei dispositivi di sicurezza in una rete basata sia sul protocollo IPv4 che IPv6 attraverso software di Network Management System, ed in particolare l’integrazione di IPv6 all’interno di un modello astratto di rappresentazione delle configurazioni di rete e delle politiche di sicurezza relative ad un’infrastruttura di S‐VPN IKE/IPSec. Le problematiche affrontate sono inserite all’interno di un progetto industriale di più ampio respiro, il SAS‐Price (Secure Access System ‐ Policy Retriever with Integrity and Consistency Engine) mirato allo sviluppo di un sistema centralizzato di gestione delle configurazioni di rete e delle politiche di sicurezza che rilevi e risolva in modo automatico i conflitti presenti nella infrastruttura gestita, sistema in cui la base di dati, implementata al termine del lavoro di analisi e sviluppo presentato, è ora integrata all’interno dell’NMS SAS‐Manager. L’integrazione di IPv6 all’interno di un modello astratto di rappresentazione dei dati si è articolata in diverse fasi: Una prima fase di studio dell’architettura all’interno della quale doveva essere implementato il nuovo protocollo e dell’interazione fra le funzionalità ad esso correlate e gli elementi e la struttura già presenti all’interno del modello. Successivamente è stata effettuata la fase di analisi della soluzione implementativa ottimale, volta ad individuare le specifiche di completezza, scalabilità, uniformità e facilità di interazione con gli altri componenti dell’architettura. Infine la fase realizzativa è stata caratterizzata dalla modifica dei database per l’implementazione del nuovo protocollo IPv6 tramite il software Microsoft SQL Server e di verifica del funzionamento dello stesso.



Pagina 128 di 189

Dal punto di vista dell’innovazione il principale risultato è stato ottenuto tramite lo studio sulle architetture dei diversi tipi di tunnel analizzati nel corso del lavoro di implementazione di IPv6 all’interno dei database. Dallo studio è emerso che gli engine di configurazione automatica dei tunnel IKE/IPSec basati su specifiche architetture di database prodotti all’interno del progetto SAS‐Price, hanno una struttura di base adeguata a contenere il totale delle informazioni necessarie a definire un qualsiasi tipo di tunnel. Infatti, in base all’analisi condotta all’interno dell’architettura delle SVPN IKE/IPSec dei database che fanno parte di questo progetto, si è riscontrato e comprovato da test di laboratorio, che con minime variazioni all’interno delle tabelle dei database si possono implementare generiche strutture di tunneling compreso l’icapsulamento per il trasporto di IPv6 su IPv4. Da questo emerge la conclusione che, in base all’analisi effettuata su questi sistemi, la struttura di un tunnel di livello 3, se realizzata in maniera oppurtuna e in modo generale riesce a rappresentare in modo completo un qualsiasi altro tunnel del medesimo livello di rete. Infatti, i parametri che è necessario rappresentare all’interno di queste strutture sono simili (indirizzo IP sorgente, indirizzo IP destinazione, tipo di processamento…) per cui i campi utilizzati in una struttura di tunneling possono essere localizzati nellʹaltra ed essere riutilizzati. L’adozione di campi preesistenti per la rappresentazione di diverse architetture da un lato evita la ridondanza di strutture e lo spreco di risorse di memoria dall’altro semplifica e rende uniforme l’intera rappresentazione generale delle connessioni di rete. Dal punto di vista industriale è stato formulato l’obiettivo, raggiunto con lo svolgimento di questa tesi, di implementare i database relazionali del progetto SAS‐Price modificati tramite l’implementazione di IPv6 all’interno dell’NMS SAS‐Manager. La realizzazione del modulo software Aligner all’interno del Security Framework del progetto SAS‐Price si è articolata in diverse fasi: Una prima fase di studio dei database di origine e destinazione delle informazioni da elaborare e di l’analisi della compatibilità tra i due database. La fase realizzativa è stata caratterizzata dalla scrittura del codice C# che realizzasse la corrispondenza tra i campi di ciascuna tabella dei due database e di verifica del funzionamento del software all’interno del SAS‐Manager. Una volta realizzato l’allineamento tra i due database tutto il progetto di cui fa parte questa tesi come altri precedenti lavori, è stato infine completato in



Pagina 129 di 189

quanto è ora possibile visualizzare i risultati del lavoro di risoluzione dei conflitti sulle policy di sicurezza direttamente tramite la GUI dell’NMS SAS‐Manager. Poiché il SAS‐Manager è un prodotto AMTEC che viene realizzato per semplificare il compito della gestione di una rete complessa da parte dell’amministratore di rete, è stata infine ottenuta un’evoluzione di tale prodotto che risulta di notevole utilità per l’azienda. L’intero progetto SAS‐Price si pone come ponte verso un nuovo modello di management di infrastrutture di rete sicura, che integri al suo interno, oltre alle classiche funzionalità di gestione di S‐VPN e a quelle di correzione automatica ed “intelligente” degli errori e dei conflitti che inevitabilmente tendono a generarsi in reti notevolmente complesse, anche il protocollo IPv6 nei suoi aspetti di configurazione dei tunnel e le funzionalità ad esso collegate, in un’ottica di semplificazione della struttura che lascia spazio ad altre possibili implementazioni nei futuri sviluppi del sistema. I possibili sviluppi industriali a breve termine di questo lavoro volgono nella direzione di poter integrare all’interno della medesima architettura di gestione delle S‐VPN apparati di diversi produttori, indipendentemente dallo specifico linguaggio usato per la loro configurazione. Il modello presentato, infatti, risponde sia a requisiti di astrazione tali da renderlo compatibile con qualsiasi tipo di apparato e software NMS per l’amministrazione di rete, sia contemporaneamente a requisiti di completezza tali da poter rappresentare efficientemente configurazioni di S‐VPN anche di notevole complessità.



Pagina 130 di 189

AAPPPPEENNDDIICCEE AA:: DDiizziioonnaarriioo ddeellllee ttaabbeellllee ddeell GGSSDDBB LEGENDA: Nome Tabella (ACRONIMO TABELLA ) attributo (possibili valori) ELENCO ABBREVIAZIONI: Address ‐> Addr Algorithm ‐>Alg Authentication ‐> Auth Encryption ‐> Encr BKArea_new Rappresenta un’area dei peer di backup BKArea_Id: intero, chiave primaria Name_BKArea: varchar(50), nome del pool di devices nella stessa area di backup Master_Id: intero, ID del devices master dell’area (vincolo FK con tabella Devices_new campo DEV_Id) CA_new Riferimento alle autorità di certificazione CA_Id: intero, chiave primaria Name_CA: varchar(255), common name della Certification Authority Certificate_new Informazioni sui certificati CER_Id: intero, chiave primaria CA_Id: intero, ID della CA (vincolo FK con tabella CA_new campo CA_Id)



Pagina 131 di 189

CN_CER: varchar(255), CommonName OU_CER: varchar(255), OrganizationUnit O_CER: varchar(255), Organization C_CER: varchar(5), Country CONNs_new Relazione multipla (fulcro del diagramma ER) tra Elements_new, IKEArea_new, CONNSParam_new, IPSecPolicy_new, Services_new CONN_Id: intero, chiave primaria IKEAREA_Id: intero, identifica l’area IKE di appartenenza (vincolo FK con tabella IKEArea_new campo IKEArea_Id) IPSec_Id: intero, ID della policy IPSEC impiegata (vincolo FK con tabella IPSecPolicy_new campo IPSec_Id) Enab_NAT: bit, indica che nella connessione è previsto l’utilizzo del nat su base certificato per uno dei due elementi se posto pari a 1, di default pari a 0 CONPAR_Id: Integer, informazioni su parametri IKE e local Ip address dei peer (vincolo FK con tabella CONNsParam_new campo CONPAR_Id) Is_Manual: bit, evidenzia se si sta usando una mappa manual o ISakmp ELEM_A_Id: intero, elemento A della connessione in cui è attivo il servizio, ID relativo alla tabella ELEMENTS (vincolo FK con tabella Elements_new campo ELEM_Id) ELEM_B_Id: intero, elemento B della connessione in cui è attivo il servizio, ID relativo alla tabella ELEMENTS (vincolo FK con tabella Elements_new campo ELEM_Id) CONNsParam_new Contiene le informazioni sui parametri IKE della connessione e sui local IP address dei peer; queste informazioni non sono state inserite direttamente nella tabella CONNs_new in quanto più connessioni possono avere la stessa suite di parametri IKE. CONPAR_Id: Integer, chiave primaria



Pagina 132 di 189

PSKEY_AH_In: varchar (100), preshared key in modalità AH quando si usa una mappa manual PSKEY_AH_Out: varchar (100), preshared key in modalità AH quando si usa una mappa manual PSKEY_ESP_In_Auth: varchar (100), preshared key in modalità ESP quando si usa una mappa manual PSKEY_ESP_Out_Auth: varchar (100), preshared key in modalità ESP quando si usa una mappa manual PSKEY_ESP_In_Encr: varchar (100), preshared key in modalità ESP quando si usa una mappa manual PSKEY_ESP_Out_Encr: varchar (100), preshared key in modalità ESP quando si usa una mappa manual Local_IP_A: varchar(50), local IP address peer A Local_IP_B: varchar(50), local IP address peer B Nat_Remote_IP_A: varchar(50), remote IP address peer A Nat_Remote_IP_B: varchar(50), remote IP address peer B ID_A: varchar(100), identificativo presente nella transazione IKE relativa al peer A ID_B: varchar(100), identificativo presente nella trandazione IKE relativa al peer B ID_Type_A: intero, tipo di identificazione usata tra quelle possibili dal protocollo IKE per A ID_Type_B: intero, tipo di identificazione usata tra quelle possibili dal protocollo IKE per B Ret_Num: intero, definisce il numero di retries durante la negoziazione IKE KP_Alive_A: intero, definisce il timeout del tunnel IPSec prima di dover rieffettuare la negoziazione IKE (in secondi) KP_Alive_B: intero, definisce il timeout del tunnel IPSec per l’elemento B prima di dover rieffettuare la negoziazione IKE (in secondi) TM_Out_IKE: intero, definisce il timeout durante la negoziazione IKE (in secondi) AntiReplay: bit, specifica se la protezione antireplay è abilitata SA_Init: intero, specifica come la SA deve essere creata Map_Num_A: intero, numero della mappa che definisce il traffico della connessione per A (6999)



Pagina 133 di 189

Map_Num_B: intero, numero della mappa che definisce il traffico della connessione per B (6999) DHCP_Serv_Addr: varchar(50), indirizzo del server DHCP Nat_Traversal_A: intero, indica la modalità di NAT Traversal per l’elemento A (0 = disabilitato, 1 = Initiator, 2 = Responder) Nat_Traversal_B: intero, indica la modalità di NAT Traversal per l’elemento B (0 = disabilitato, 1 = Initiator, 2 = Responder) CONNsServ_new Relazione fra le connessioni ed eventuali servizi ad esse associati CONNsServ_Id: int, chiave primaria CONN_Id: int, id della tabella CONNs_new Serv_Id: int, id della tabella Services_new CryptoSet_new Contiene le informazioni sulle primitive crittografiche disponibili per le policy IKE e IPSec. CRSET_Id: Integer, chiave primaria Name_CRSET: varchar(50), nome della primitiva crittografica Type_CRSET: integer, tipo di primitiva Device_new Contiene l’elenco e le informazioni di tutti i devices; DEV_Id: Integer, chiave primaria Name_DEV: varchar(50), nome del device Type_DEV: Integer, tipo di device Gest_Addr: varchar(50), indirizzo di gestione GET_Comm: varchar(50), community get SNMP SET_Comm: varchar(50), community set SNMP Exit_Map: intero, numero della mappa di uscita (mappa 4 di default)



Pagina 134 di 189

Enab_NAT: bit, indica se è abilitato il NAT Gest_Addr_NAT: varchar(50), indirizzo di gestione nattato del device IKE_Status: bit, indica se IKE è attivo o meno IPSec_Status: bit, indica se IPSec è attivo o meno SNMP_Status: bit, indica se SNMP è attivo o meno FW_Status: bit, indica se il firewall è attivo o meno Features: intero, indica se il device è Nobody, CryptoIp, ecc... (il Device Nobody serve per la gestione delle ExtraVPN che in questo modo rientrano nelle connessioni e nelle IKEArea in quanto una mappa in chiaro di tipo ExtraVPN è una mappa tra Sas normale e Sas Nobody; il device CryptoIP invece serve per gestire il CryptoIP come un device software, ovvero un Sas software che protegge se stesso) ‐‐‐> 0 = Nobody; 1 = CryptoIp Elements_new Contiene l’elenco di elementi di VPN che possono essere utilizzati all’interno delle S‐VPN ELEM_Id : intero, chiave che identifica univocamente un elemento di vpn Name_ELEM : varchar(50), nome dato ad un element Addr: varchar(50), se è un elemento c’è il suo indirizzo/maschera, oppure il primo indirizzo del range; se è un client puo esserci il suo indirizzo oppure niente se è stato settato con l’indirizzo dinamico CER_Id: integer, relativo alla tabella Certificate (vincolo FK con tabella Certificate_new campo CER_Id) Is_Mng: bit, indica se l’elemento è protetto da un SAS di gestione e quindi fa parte della VPN di gestione (contiene un Sas Manager engine) Nat_MNG_Addr: indirizzo nattato dell’elelemento in caso si tratti di un elmento di gestione Interfaces_new Rappresenta tutte le interfacce fisiche dei devices INT_Id: Integer, chiave primaria



Pagina 135 di 189

DEV_Id: integer, ID del relativo device (vincolo FK con tabella Device_new campo DEV_Id) Name_INT: varchar(50), nome interfaccia Addr_INT: varchar(50), indirizzo associato all’interfaccia VRRP_IFC: bit, indica se si tratta dell’interfaccia su cui attivare VRRP Gest_IFC: bit, indica se si tratta dell’interfaccia di gestione IKEArea_new Contiene l’elenco di tutte le connessioni che hanno la stessa politica IKE IKEArea_Id: Integer, chiave primaria Name_IKEArea: varchar (50), nome dell’area IKE IKEPOL_Id: intero, collegamento alla policy IKE (vincolo FK con tabella IKEPolicy_new campo IKEPOL_Id) PSKEY_IKE: varchar(100), chiave preshared della transazione IKE IKE_Mode: intero, indica Main mode o Aggressive mode della negoziazione IKE IS_Mng: bit, indica se è un’area IKE di management IKEPolicy_new Contiene tutti i campi necessari a definire una politica IKE IKEPOL_Id: Integer, chiave primaria Name_IKEPOL: varchar(50), nome dato alla policy IKE ENCR_Alg: Integer, tipo di algoritmo utilizzato per effettuare la cifratura (vincolo FK con tabella CryptoSets_new campo CRSET_Id) HASH_Alg: Integer, tipo di algoritmo di hashing usato nella transazone IKE (vincolo FK con tabella CryptoSets_new campo CRSET_Id) DH_Group: Integer, gruppo Diffie Hellman utilizzato AUTH_Mode: Integer, dipende dalla tipologia di autenticazione usata nella transazione IKE (certificated, signature or preshared) Priority: Integer, priorità inserita dall’utente LifeTimeSA_Sec: Integer, durata della Security Association IKE in secondi LifeTimeSA_KB: Integer, durata della Security Association IKE in kilobyte



Pagina 136 di 189

LifeTime_Rekey: Integer, tempo limite dopo il quale rinegoziare una nuova chiave IPSecPolicy_new Dati relative alle policy IPSEC. IPSec_Id: intero, chiave primaria Name_IPSec: varchar(50), nome della policy IPSec AH_Auth_Alg: intero, tipo di algoritmo di hashing AH (vincolo FK con tabella CryptoSet_new campo CRSET_Id) ESP_Auth_Alg: intero, tipo di algoritmo di hashing ESP per l’autenticazione (vincolo FK con tabella CryptoSet_new campo CRSET_Id) ESP_Encr_Alg: intero, tipo di algoritmo utilizzato per effettuare la cifratura di ESP (vincolo FK con tabella CryptoSet_new campo CRSET_Id) LifeTime_Sec: intero, tempo di vita della SA in secondi LifeTime_KB: intero, tempo di vita della SA in kilobyte NATCer_new Elenca i pool di NAT utilizzati dalla funzionalità di NAT su base certificato. NatCer_Id: intero, chiave primaria Name_pool_NAT: varchar(50), nome associato al pool di indirizzi Addr_from: varchar(50), primo indirizzo del pool Addr_to: varchar(50), ultimo indirizzo del pool DEV_Id: intero, ID del sas in questione (vincolo FK con tabella Device_new campo DEV_Id) Protects_new Relazione che lega device alle aree VRRP, e di backupPeer e agli elementi; si tradurrà in una tabella nel DB PROT_Id: intero, chiave primaria VRRP_Id: intero, (vincolo FK con tabella VRRPArea_new campo VRRP_Id)



Pagina 137 di 189

BKArea_Id: intero, (vincolo FK con tabella BKArea_new campo BKArea_Id) DEV_Id: intero, (vincolo FK con tabella Devices_new campo DEV_Id) ELEM_Id: intero, (vincolo FK con tabella Elements_new campo ELEM_Id) Enab_SA_Bk: bit, indica se sono attive o meno le SA di backup VRRP_Priority: intero, indica la priorità del devices nell’area VRRP BKArea_Priority: intero, indica la priorità del devices nell’area di backup Services_new Riferimento ai servizi attivi dei singoli elements che fanno parte di una connessione SERV_Id: intero, chiave primaria Name_SERV::varchar(50), nome del selettore Port_From: intero, SourcePort_RAL Port_To: intero, DestinationPort_RAL SubInterfaces_new Elenca tutti i possibili indirizzi IP che possono essere associati ad una singola interfaccia fisica SUBINT_Id: intero, chiave primaria INT_Id: intero, (vincolo FK con tabella Interfaces_new campo INT_Id) Name_SUBINT: varchar(50), nome della sottointerfaccia Addr_SUBINT: varchar(50), indirizzo IP associato alla sottointerfaccia VRRPArea_new Rappresenta un’area di VRRP in cui c’è un device master e n slave; per individuare quali devices fanno parte della stessa area VRRP, basta individuare i devices con lo stesso VIP. VRRP_Id: intero, chiave primaria Name_VRRP: varchar(50), nome del pool di devices nella stessa area VRRP Master_Id: intero, ID del devices master dell’area (vincolo FK con tabella Devices_new campo DEV_Id)



Pagina 138 di 189

VIP_Addr: varchar(50), indirizzo VIP degli apparati in VRRP



Pagina 139 di 189

AAPPPPEENNDDIICCEE BB:: DDiizziioonnaarriioo ddeellllee ttaabbeellllee ddeell DDVVDDBB LEGENDA: Nome Tabella (ACRONIMO TABELLA ) attributo (possibili valori) id utilizzati per l’identificazione delle singole tuple chiave primaria campo per informazioni proprietarie DOMINIO(n) (x,y) = Dominio di appartenenza dell’attributo (dimensione) (x = Cardinalità minima, y = Cardinalità massima) ELENCO ABBREVIAZIONI: Address ‐> Addr Algorithm ‐>Alg Authentication ‐> Auth Encryption ‐> Encr CERtificate (CER) Contiene tutte le informazioni sui certificati. Un certificato può essere abbinato ad un indirizzo IP singolo, ad un pool di indirizzi, ad una macchina con indirizzo variabile (DHCP) con i comandi: ‐ ADD SCERT <string> <alfastring> MAP <integer> [IP] [<address>]; ‐ ADD SCERT <string> <alfastring> MAP <integer> [POOL] [<string2>]; ‐ ADD SCERT <string> <alfastring> MAP <integer> [DHCP] ] [<ip address>];

<string>: Identifica il nome della Certification Authority (max 40 caratteri). <alfastring>: Identifica con uno o più parametri le caratteristiche del Certificato associate all’utente (max di 50 caratteri, contiene CN,O, OU,ecc.). Id_CER Primary Key CaName_CER Nome della Certification Authority VARCHAR(50) (1,1) CommonName_CER Nome del certificato VARCHAR(50) (1,1)



Pagina 140 di 189

Organization_CER Nome dell’organizzazione del certificato VARCHAR(50) (1,1) OrganizationUnit_CER Nome dell’unità di riferimento dell’organizzazione del certificato VARCHAR(50) (0,1) Country_CER Paese di riferimento del certificato VARCHAR(50) (1,1) Id_MIS Riferimento alla tabella MapISakmp (MIS) DEVice (DEV) Contiene informazioni relative ad ogni singolo apparato. Id_DEV Primary key Identifier_DEV Identificatore del dispositivo univoco all’interno della rete (nome del SAS) VARCHAR(50) (1,1) Type_DEV Default 1 Tipo del SAS INT (1,1) SecureAddr_ DEV Indirizzo di default per tunnel IPSec VARCHAR(50) (0,1) IpsecStatus_ DEV (on/off) Default off Stato di attivazione delle funzioni IPSec BIT (1,1) FirewallStatus_DEV (on/off) Default off Stato di attivazione del Firewall BIT (1,1) IkeStatus_DEV (on/off) Default off Stato di attivazione di IKE BIT (1,1) GestAddr_DEV Indirizzo di gestione del device VARCHAR(50) SNMPStatus_DEV Stato di attivazione di SNMP BIT SNMPTrapStatus_DEV Stato di attivazione delle trap SNMP BIT SNMPAuthTrapStatus_DEV



Pagina 141 di 189

Stato di attivazione delle trap SNMP autenticate BIT FWBoxAccess (FBA) Contiene informazioni per raffinare ulteriormente le politiche Self (traffico destinato al SAS) utilizzando i comandi relativi al Box Access: in particolare si può definire se accettare o meno a seconda della provenienza (EXTERNAL, DMZ o CORPORATE) pacchetti di Ping, Telnet e Login. Vengono popolati dai comandi Gaia: ‐ FIREWALL PING FROM <DMZ/CORPORATE/EXTERNAL> <ALLOW /DENY>;

‐ FIREWALL TELNET FROM <DMZ / CORPORATE / EXTERNAL> <ALLOW /DENY >;

‐ FIREWALL LOGIN FROM <DMZ / CORPORATE / EXTERNAL> <ALLOW /DENY >;

Id_FBA Primary key Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) AccessType_FBA Indica in che modo viene effettuato l’accesso (ping, telnet, login) NCHAR(10) Interface_FBA Indica la tipologia di rete associata all’interfaccia in esame (corporate, external, dmz) NCHAR(10) Action_FBA Indica il tipo di azione specificato (allow, deny) NCHAR(10) FwPolicy (FWP) Contiene le informazioni per creare una policy. A tale rule viene associata la direzione del traffico, un selettore ed un permesso allow oppure deny. In questo modo tale policy regola il traffico descritto dal selettore a lei associato. Inoltre è possibile legare alla policy un gruppo di utenti. In questo caso la rule sarà valida solo per lo user appartenente a tale gruppo e solo previo



Pagina 142 di 189

autenticazione attraverso lʹapposita interfaccia grafica. Discende direttamente dal comando Gaia: FIREWALL ADD POLICY <Integer: rule id> <CORPORATE_IN / CORPORATE_OUT / DMZ_IN / DMZ_OUT> <ALLOW / DENY> SELECTOR <Selector Name> <LOG_ENABLE/LOG_DISABLE> [GROUP] [<Group DataBase Record Name>] Id_FWP Primary Key Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) Priority_FWP Numero che indica la priorità della policy INT Interface_FWP Indica il tipo di interfaccia da usare (corporate o dmz) VARCHAR(50) Direction_FWP Direzione del traffico (in‐out) VARCHAR(50) Action_FWP Tipo di azione consentita (allow, deny) VARCHAR(50) Selector_FWP Nome del selettore VARCHAR(50) LogEnable_FWP Indica se è abilitato o meno il log BIT NatName_FWP Nome del gruppo a cui è legata la policy (group database record name) VARCHAR(50) FwSelector (FWS) Contiene informazioni che permettono di inserire un selettore, necessario per realizzare le politiche dʹaccesso utilizzate dal firewall per la gestione del traffico. Il selettore può essere poi abbinato ad una rule permit/deny. Tabella popolata dal parsing del comando Gaia: FIREWALL ADD SELECTOR <Selector Name> <TCP / UDP / ICMP / AH / ESP / GRE / ANY_PROT> SOURCE <IP DataBase Record Name> <SAFE_PORT/ANY_PORT/ <Port Number> > [[<port number>]] DEST <IP



Pagina 143 di 189

DataBase Record Name> <SAFE_PORT /ANY_PORT/ <Port Number> > [<port number>] Id_FWS Primary Key Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) Name_FWS Nome del selettore VARCHAR(50) Protocol_FWS Protocollo associato al selettore (TCP / UDP / ICMP / AH / ESP / GRE / ANY_PROT) VARCHAR(50) SourceIpDb_FWS Indirizzo IP sorgente VARCHAR(50) SourcePort_FWS Porta sorgente VARCHAR(50) DestIpDb_FWS Indirizzo IP destinazione VARCHAR(50) DestPort_FWS Porta destinazione VARCHAR(50) Service_FWS Nome del service, serve quando un service database è associato al selettore VARCHAR(50) FWSelfpolicy (FSP) Contiene informazioni che permettono di specificare una Self Policy: le Self Policy regolano il traffico entrante destinato al SAS. Comando Gaia: FIREWALL ADD SELFPOLICY <TCP/UDP/ICMP/AH/ESP/GRE> [<port number>] <ALLOW / DENY> Id_FSP Primary Key Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) Protocol_FSP



Pagina 144 di 189

Tipo di protocollo (TCP, UDP, ICMP, ESP, GRE, AH) NCHAR(10) Port_FSP Numero di porta INT Action_FSP Indica il tipo di azione specificato (allow, deny) NCHAR(10) IKePolicy (IKP) Contiene informazioni sulle policy IKE definite. Diversi comandi del Gaia vengono parsati dal popolatore per questa tabella: ‐ IKE ADD POLICY < Policy Name>; ‐ IKE POLICY < Policy Name > PRIORITY < Priority of Policy between 0‐255>;

‐ IKE POLICY < Policy Name > AUTHENTICATION <Authentication Algorithm: Pshkey/Rsasign>;

‐ IKE POLICY < Policy Name > HASH <Hashing Algorithm: Md5/Sha>; ‐ IKE POLICY < Policy Name> ENCRYPTION <Encryption Algorithm: Descbc| Tdescbc | AESCBC128 |AESCBC192 |AESCBC256>;

‐ IKE POLICY < Policy Name > DHGROUP <Diffie‐Hellman: 768M/1024M>; ‐ IKE POLICY < Policy Name > LIFETIME SECONDS <LifeTime of Policy in sec.>;

‐ IKE POLICY < Policy Name > LIFETIME TRAFFIC <LifeTime of Policy in KB>;

‐ IKE POLICY < Policy Name > LIFETIME REKEY <Max n. of key usage>; Id_IKP Primary Key Name_IKP Nome della politica IKE VARCHAR(50) (1,1) Priority_IKP Numero identificativo della priorità di utilizzo delle Policy Ike INT (1,1) AuthType_IKP (preshared key/certificate) Tipologia di autenticazione usata nella transazione IKE VARCHAR(50) (1,1) HashAlg_IKP_ Tipo di algoritmo di hashing usato nella transazione IKE VARCHAR(50) (1,1)



Pagina 145 di 189

EncrAlg_IKP Tipo di algoritmo di cifratura usato nella transazione IKE VARCHAR(50) (1,1) DhGroup_IKP Gruppo di Diffie Hellman utilizzato nella transazione IKE INT (1,1) LifetimeSaIkeSecond_IKP Durata della Security Association Ike in secondi trasmessi INT (0,1) LifetimeSaIkeKB_IKP Durata della Security Association Ike in KB trasmessi INT (0,1) LifetimeSaIkeRekey_IKP Durata della Security Association Ike in numero di processi di rekey INT (0,1) MapISakmp (MIS) Contiene informazioni sulle mappe ISAKMP, ovvero sulle policy IPSec dinamiche negoziate tramite IKE e definite fra due peer. Viene popolata a partire da diversi comandi Gaia : ‐ IPSEC MAP < Map label ‐between 2 and 10000 > SET PEER <Remote Ip Address>;

‐ IKE ADD PEER < Peer Name>; ‐ IPSEC ADD MAP < Map label ‐between 2 and 10000 > ISAKMP [DYNAMIC][PRIORITY] [<Map label ‐between 2 and 10000>];

‐ IKE PEER <Peer Name> MODE MAIN; ‐ IKE PEER <Peer Name> MODE AGGRESSIVE; ‐ IKE PEER < Peer Name > LOCAL_ID <ID type: any word for see options> [<ip address, range or subnet>] [<ip address, range or subnet>];

‐ IKE PEER < Peer Name > REMOTE_ID <ID type: any word for see options> [<ip address,range or subnet>] [<ip address, range or subnet>];

‐ IPSEC MAP <Map label ‐between 2 and 10000> SET ANTI_REPLAY ON IKE PEER <Peer Name> KEEPALIVE <keepalive interval (sec)> IKE PEER < Peer Name > TMO <Timeout for retransmission (sec)> RETRY <n. of attempt>

Id_MIS Primary Key RemotePeerAddr_MIS



Pagina 146 di 189

Indirizzo dell’end‐point del tunnel IPSec VARCHAR(50) (0,1) IkePeerName_MIS Nome del Peer che compie la transazione IKE VARCHAR(50) (1,1) Type_MIS (static/dynamic) Tipologia della transazione IKE in base alla controparte VARCHAR(50) (1,1) IkeMode_MIS (main/aggressive) Modo della transazione IKE VARCHAR(50) (1,1) PeerIdType_MIS (IPv4_Address, Distinguish Name) Tipo di identificativo utilizzato per individuare i Peer della transazione IKE VARCHAR(50) (1,1) LocalIdValue_MIS Identificativo del Peer locale della transazione IKE VARCHAR(50) (0,1) RemoteIdValue_MIS Identificativo del Peer remoto della transazione IKE VARCHAR(50) (0,1) LocalPeerAddr_MIS Nuovo indirizzo usato per la transazione IKE VARCHAR(50) (1,1) AuthValue_MIS (preshared key value/certificate id) Valore di tipologia differente in base al tipo di autenticazione utilizzato nella transazione IKE VARCHAR(50) (1,1) AntiReplay_MIS (on,off) Deault off Stato della funzione antireplay BIT (0,1) KeepAliveTime_MIS Intervallo di Keep Alive per il peer dell’IKE INT (0,1) TimeOut_MIS Intervallo di Time Out per il peer dell’IKE INT (0,1) RetryNumber_MIS Numero di Retry consentititi INT (0,1) MapisakmpXIkepolicy (MXI) Contiene informazioni per legare le tabelle MapIsakpm e IkePolicy (esprime una relazione). Id_MXI Primary Key Id_MIS



Pagina 147 di 189

Riferimento a MapISakmp (MIS) Id_IKP Riferimento a IKePolicy (IKP) MapisakmpXTransformset (MXT) Contiene informazioni per legare le tabelle MapIsakpm e TransformSet (esprime una relazione). Id_MXT Primary Key Id_MIS Riferimento a MapISakmp (MIS) Id_TRS Riferimento a TRansform Set (TRS) Priority_MXT Numero identificativo della priorità di utilizzo del Transform Set INT (1,1) MapMAnual (MMA) Contiene informazioni sulle mappe IPSec manual clear (non ISAKMP), derivate dai comandi Gaia: ‐ IPSEC ADD MAP <Map label ‐between 2 and 10000‐> MANUAL <Permitsec/Clear/Corporate> [PRIORITY] [<Map label ‐between 2 and 10000>];

‐ IPSEC MAP <Map label‐between 2 and 10000> SET KEY <inbound / outbound> AH <Spi Value> <key>;

‐ IPSEC MAP <Map label‐between 2 and 10000> SET KEY <inbound / outbound> ESP <Spi Value> [CIPHER] [<Cipher Key>] [AUTH] [<Authentication Key>]

Id_ MMA Primary Key RemotePeerAddr_MMA Indirizzo dell’end‐point del tunnel IPSec VARCHAR(50) (1,1) AhInboundKey_MMA



Pagina 148 di 189

Chiave utilizzata per il traffico AH entrante VARCHAR(50) (0,1) AhOutboundKey_MMA Chiave utilizzata per il traffico AH uscente VARCHAR(50) (0,1) AhInboundSpi_MMA Security Parameter Index del traffico AH entrante INT (0,1) AhOutboundSpi_MMA Security Parameter Index del traffico AH uscente INT (0,1) EspInboundAuthKey_MMA Chiave utilizzata per l’autenticazione del traffico ESP entrante VARCHAR(50) (0,1) EspOutboundAuthKey_MMA Chiave utilizzata per l’autenticazione del traffico ESP uscente VARCHAR(50) (0,1) EspInboundEncrKey_MMA Chiave utilizzata per la cifratura del traffico ESP entrante VARCHAR(50) (0,1) EspOutboundEncrKey_MMA Chiave utilizzata per la cifratura del traffico ESP uscente VARCHAR(50) (0,1) EspInboundSpi_MMA Security Parameter Index del traffico ESP entrante INT (0,1) EspOutboundSpi_MMA Security Parameter Index del traffico ESP uscente INT (0,1) Id_TRS Riferimento al Transform set usato (tabella TRansform Set (TRS)) NatAddressSet (NAS) Contiene informazioni per nattare un set di indirizzi (list = elenco indirizzi da nattare; pool = indirizzi da usare per nattare quelli in una list). Dai comandi Gaia: ‐ NAT ADD LIST <List Name> <IP Address 1> [<IP Address 2>] MASK <IP Mask>;

‐ NAT ADD POOL <Pool Name> <IP Addr1> [<IP Addr2>] MASK <IP Mask>



Pagina 149 di 189

Id_NAS Primary Key Name_NAS Nome del set di indirizzi VARCHAR (50) (1,1) Type_NAS (pool/list) Funzione degli insieme di indirizzi per il NAT VARCHAR (50) (1,1) AddrSet_NAS Insieme di indirizzi identificato da indirizzoIp/maschera VARCHAR (50) (1,1) AddrRange_NAS Altro estremo dell’intervallo di indirizzi della rete identificata dalla maschera. VARCHAR (50) (0,1) Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) PHysical Interface (PHI) Contiene informazioni sulle interfacce fisiche di ogni device. Dal comando Gaia: <Interface>[/<Integer>] IP ON <IP address> <IP mask> �<ADD>� Id_PHI Primary Key Name_PHI Nome dell’interfaccia (es. Ethernet1) VARCHAR(50) (1,1) IpAddr_PHI Indirizzo dell’interfaccia, è possibile associare ad una stessa interfaccia più indirizzi IP VARCHAR(50) (1,n) Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) SASLogicalInterface_PHI Etichetta proprietaria di mappaggio su interfaccia logica VARCHAR(50) (0,1) Rules Access List (RAL)



Pagina 150 di 189

Contiene informazioni sulle access list che permettono il passaggio solo di determinati pacchetti IP. In caso di IPSec devono essere definite delle access list specifiche per il passaggio dei pacchetti IPSec tramite i comandi Gaia: ‐ IPSEC ACCESS <List label ‐between 2 and 10000‐> [PERMIT] [<Ip Address Src>] [<Ip Mask Src>] [<Ip Address Dst>] [<Ip Mask Dst>] [<Protocol>] [<Source port range s1/s2>] [<Destination port range s1/s2>] [BIDIRECTIONAL];

‐ IPSEC ACCESS <List label ‐between 2 and 10000‐> [DENIED] [<Ip Address Src>] [<Ip Mask Src>] [<Ip Address Dst>] [<Ip Mask Dst>] [<Protocol>] [<Source port range s1/s2>] [<Destination port range s1/s2>] [BIDIRECTIONAL];

Id_RAL Primary Key Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) Priority_RAL Numero identificativo della priorità di matching delle regole INT (1,1) Id_MMA (0,1) Riferimento a MapMAnual (MMA) Id_MIS (0,1) Riferimento a MapISakmp (MIS) Action_RAL (bypass/discard/process) Tipo di azione del Security Gateway VARCHAR(50) (1,1) Protocol_RAL Tipo del protocollo VARCHAR(50) (0,1) SourceIpAddr_RAL Indirizzo IP sorgente / Maschera IP sorgente VARCHAR(50) (1,1) DestinationIpAddr_RAL Indirizzo IP destinazione / Maschera IP destinazione VARCHAR(50) (1,1) SourcePort_RAL Numero della porta sorgente con eventuale range INT (0,1) DestinationPort_RAL Numero della porta destinazione con eventuale range INT (0,1) SASPriorityType_RAL Etichetta proprietaria di riferimento per la priorità VARCHAR(50) (0,1)



Pagina 151 di 189

Rules FireWall (RFW) Contiene tutte le regole del firewall, tabella popolata a partire dei tre comandi Gaia ADD IPDB, ADD SELECTOR e ADD POLICY: ‐ FIREWALL ADD IPDB <DataBase Record Name> <IP_ADDR / IP_RANGE / P_SUBNET / IP_ANY> [<IP Address>] [<final range Ipaddress / subnet mask>];

‐ FIREWALL ADD SELECTOR <Selector Name> <TCP / UDP / ICMP / AH / ESP / GRE / ANY_PROT> SOURCE <IP DataBase Record Name> <SAFE_PORT/ANY_PORT/ <Port Number> > [[<port number>]] DEST <IP DataBase Record Name> <SAFE_PORT/ANY_PORT/<Port Number> > [<port number>];

‐ FIREWALL ADD POLICY <Integer: rule id> <CORPORATE_IN / CORPORATE_OUT / DMZ_IN / DMZ_OUT> <ALLOW / DENY> SELECTOR <Selector Name> <LOG_ENABLE / LOG_DISABLE> [GROUP] [<Group DataBase Record Name>];

Id_RFW Primary Key Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) Priority_RFW Numero identificativo della priorità di matching delle regole INT (1,1) Action_RFW (allow/deny) Tipo di azione del firewall VARCHAR(50) (1,1) Protocol_RFW Tipo del protocollo VARCHAR(50) (0,1) SourceIpAddr_RFW Indirizzo IP sorgente / maschera dell’indirizzo IP sorgente VARCHAR(50) (1,1) DestinationIpAddr_RFW Indirizzo IP destinazione / Maschera dell’indirizzo IP destinazione VARCHAR(50) (1,1) SourcePort_RFW Numero della porta sorgente INT (0,1)



Pagina 152 di 189

DestinationPort_RFW Numero della porta destinazione con eventuale range INT (0,1) SASLogicalInterface_IN_RFW Etichetta proprietaria dell’interfaccia logica di ingresso VARCHAR(50) (0,1) SASLogicalInterface_OUT_RFW Etichetta proprietaria dell’interfaccia logica di uscita VARCHAR(50) (0,1) Nat_RFW Nome dell’associazione NAT VARCHAR(50) Notes_RFW Campo per eventuali note VARCHAR(50) SasfwIpDb (SID) Contiene informazioni che permettono di inserire un IP database, vale a dire una struttura nella quale è contenuto un insieme di indirizzi ip. Tale database è necessario per realizzare le politiche dʹaccesso utilizzate dal firewall per la gestione del traffico. Comando Gaia corrispondente: FIREWALL ADD IPDB <DataBase Record Name> <IP_ADDR / IP_RANGE / IP_SUBNET / IP_ANY> [<IP Address>] [<final range Ipaddress / subnet mask>] Id_SI Primary Key Name_SID Nome del set di indirizzi varchar(50) (1,1) Type_SID (ip_addr/ip_range/ip_subnet/ip_any) Tipologia di set di indirizzi varchar(50) (1,1) AddrSet_SID Set di indirizzi Ip. varchar(50) (1,1) AddrRange_SID Indirizzo Ip di final range o maschera. varchar(50) (0,1) Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione). SasfwNatDb (SND)



Pagina 153 di 189

Contiene informazioni che permettono di inserire un Nat database, necessario per realizzare le politiche dʹaccesso utilizzate dal firewall per la gestione del traffico. Comandi Gaia parsati: ‐ FIREWALL ADD NATDB <DataBase Record Name> MANY_TO_ONE <IP Address>;

‐ FIREWALL ADD NATDB <DataBase Record Name> ONE_TO_ONE <NAT Internal LIST: IP DataBase Record Name> <NAT POOL: IP DataBase Record Name>;

Id_SN Primary Key Name_SND Nome dell’associazione Nat VARCHAR(50) (0,1) Type_SND (OneToOne/ManyToOne) Tipologia di NAT (ManyToOne – OneToOne) VARCHAR(50) (1,1) TranslatedAddr_SND Nome del Pool nel caso di NAT OneToOne o Indirizzo Ip nel caso di NAT ManyToOne VARCHAR(50) (1,1) InternalAddr_SND Nome della List nel caso di NAT OneToOne VARCHAR(50) (0,1) Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione). SasfwServicesDb (SSD) Contiene le informazioni necessarie per permettere l’inserimento di un service database; questo è necessario per realizzare le politiche dʹ accesso utilizzate dal firewall per la gestione del traffico. Un service database rappresenta un servizio definito sul destinatario. Tale database associato al selettore e quindi ad una policy fornisce la possibilità di discriminare il traffico tra i vari ip database configurati. FIREWALL ADD SERVICEDB <DataBase Record Name> <TCP / UDP> < port number> Id_SSD Primary Key



Pagina 154 di 189

Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) Name_SSD Nome del servizio VARCHAR(50) Protocol_SSD Protocollo di trasporto VARCHAR(50) Port_SSD Numero di porta INT SNMPCommunity (SNC) Contiene informazioni sulle community SNMP definite dal comando: ADD SNMP COMMUNITY <community name> [<access type>] Id_SNC Primary Key Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) Name_SNC Nome della community SNMP VARCHAR(50) Type_SNC Tipo di accesso (RO = sola lettura; RW = lettura e scrittura) VARCHAR(50) SNMPManager (SNM) Contiene informazioni che permettono al protocollo SNMP di gestire gli indirizzi IP dei manager a cui inviare le segnalazioni spontanee (trap). Notare che per generare le segnalazioni spontanee (trap) occorre abilitare sia il protocollo SNMP sia le TRAP. ADD SNMP MANAGER <IP address> [<community name>] [GT] [ST] [SECT] Id_SNM Primary Key Id_DEV Riferimento alla tabella DEVice (indica il SAS in questione) Address_SNM



Pagina 155 di 189

Indirizzo di gestione VARCHAR(50) Community_SNM Nome della community SNMP VARCHAR(50) GT_SNM Valore per l’abilitazione delle generic trap BIT ST_SNM Valore per l’abilitazione delle specific trap BIT SECT_SNM Valore per l’abilitazione delle security trap BIT TRansform Set (TRS) Contiene informazioni sui transform set, che costituisce una combinazione accettabile di transform, ovvero di algoritmi, protocolli e altre impostazioni di sicurezza che devono essere applicate al traffico protetto tramite il protocollo IPSec. IPSEC TRANSFORM <Set Name> <Type of Transform> [<Type of Transform>] [<Type of Transform>] [MODE] [<Tunnel/Transport>] LIFETIME [SECONDS] [<Sa Lifetime in Seconds>] [KILOBYTES] [<Sa Lifetime in KB>] Id_TRS Primary Key Name_TRS Nome del Trasform Set VARCHAR(50) (1,1) Mode_TRS (tunnel/transport) Modalità del protocollo IPSec VARCHAR(50) (1,1) AhAlg_TRS Tipo di algoritmo usato per l’autenticazione con AH nel processamento IPSec VARCHAR(50) (0,1) EspAuthAlg_TRS Tipo di algoritmo usato per l’autenticazione con ESP nel processamento IPSec VARCHAR(50) (0,1) EspEncrAlg_TRS Tipo di algoritmo usato per la cifratura con ESP nel processamento IPSec VARCHAR(50) (0,1) LifetimeSaIpsecSecond_TRS



Pagina 156 di 189

Durata della Security Association IPSec in secondi INT (0,1) LifetimeSaIpsecKB_TRS Durata della Security Association IPSec in KB trasmessi INT (0,1)



Pagina 157 di 189

AAPPPPEENNDDIICCEE CC:: DDiizziioonnaarriioo ddeellllee ttaabbeellllee ddeellll’’SSMMDDBB LEGENDA: Nome Tabella (ACRONIMO TABELLA ) ATTRIBUTO (possibili valori) campo per informazioni proprietarie dominio(n) (x,y) = Dominio di appartenenza dell’attributo (dimensione) (x = Cardinalità minima, y = Cardinalità massima) ELENCO ABBREVIAZIONI: Address ‐> Addr Algorithm ‐>Alg Authentication ‐> Auth Encryption ‐> Encr BKPEER Peer IKE di backup dei gateway (SAS). Modulo Console, Menu: Selected‐>Backup IKE Peer ID: int, chiave primaria SAS_ID: int, ID del SAS primario PEER_ID: int, ID del SAS di backup PRIORITY: int, priorà associata al SAS di backup ALT_ADDR: varchar(16), indirizzo alternativo del SAS di backup (utile per NAT ad esempio) ALT_ADDR_G: varchar(16), indirizzo alternativo del SAS primario (utile per NAT ad esempio) CA Riferimento alle autorità di certificazione. Sul modulo console, Menu Globals ‐> Certification Authorities. ID: int, chiave primaria



Pagina 158 di 189

NAME: varchar(255), common name della Certification Authority CLSERV Associazione dei selettori di traffico (Services su modulo Console, menu Globals‐>Services) in chiaro per ogni client di VPN (CryptoIP). Modulo Console, Selezionare elemento di VPN di tipo Client, accedere alla finestra delle proprietà, scheda Client, bottone Allowed IP Traffic. ID: int, chiave primaria GROUP_ID: int, ID del gruppo (in questo caso client) su cui abilitare il servizio in chiaro SERVICE_ID: int, ID del servizio in chiaro permesso CONNS Contiene dati sulle connessione fra gli elementi delle VPN. Genera una entry ogni volta che si collegano due gruppi o elementi. Modulo Console, Menu: Selected Connections. ID: int, chiave primaria VPN_ID: int, ID della VPN del collegamento GROUP_A_ID: int, ID del gruppo\elemento A GROUP_B_ID: int, ID del gruppo\elemento B IPSEC_ID: int, ID della policy IPSEC impiegata PSKEY: varchar(100), preshared key (se necessaria) ENAB_NAT: int, indica che nella connessione è previsto l’utilizzo del nat per uno dei due elementi se posto pari a 1, di default pari a 0 IDENT_A: varchar(16), indirizzo dell’elemento A nella connessione (se diverso da quello specificato nella tabella GROUPS, se NULL invece si usa quello specificato in GROUPS.ADDR) IDENT_B: varchar(16), indirizzo dell’elemento B (se diverso da quello specificato nella tabella GROUPS, se NULL invece si usa quello specificato in GROUPS.ADDR) GTW_ADDR_A: varchar(16), indirizzo del gateway che protegge l’elemento A (se diverso da quello specificato in GROUPS.SAS_ID SAS.ADDR)



Pagina 159 di 189

GTW_ADDR_B: varchar(16), indirizzo del gateway che protegge l’elemento B (se diverso da quello specificato in GROUPS.SAS_ID SAS.ADDR) EXC_MODE: int, specifica Main Mode (se pari a 0) o Aggressive Mode (se pari a 1) KP_ALIV_TM: int, definisce il timeout per l’elemento A prima di dover rieffettuare la negoziazione IKE (in secondi) RESP_TM: int, definisce il timeout durante la negoziazione IKE (in secondi) RESP_TM_RET: int, definisce il numero di retries durante la negoziazione IKE KP_ALIV_TMB: int, definisce il timeout per l’elemento B prima di dover rieffettuare la negoziazione IKE (in secondi) DHCP_SERV: varchar(16), indirizzo del server DHCP (selezionabile solo nel caso uno dei due elements sia un client CryptoIP) NATT_MODE: int, indica la modalità di NAT Traversal (solo per client CryptoIP: 0 = disabilitato, 1 = Initiator, 2 = Responder) EXTRAVPN Contiene l’elenco di tutti i flussi di traffico in chiaro consentiti. Si abilita da menu del Gateway (selezionare Gateway popup menu Modify Security: Extra VPN traffic spuntare “Enable”) e si configura da Console, menu: Selected‐> Extra VPN traffic ID: int, chiave primaria SAS_ID: int, id del sas su cui è stato abilitato traffico extravpn (gateway‐>modify‐>security‐>extraVPN traffic ENABLE) ADDR_FROM: varchar(16), indirizzo sorgente traffico EXTRAVPN MASK_FROM: varchar(16), relative maschera ADDR_TO: varchar(16), indirizzo destinazione traffico EXTRAVPN MASK_TO: varchar(16), relative maschera SERVICE_ID: int, se non vi è associato nessun servizio è 0, altrimenti c’è l’ID del relativo servizio presente nella tabella SERVICES GROUPS



Pagina 160 di 189

Contiene l’elenco di elementi di VPN che possono essere utilizzati all’interno delle S‐VPN. Menu: Selected ‐> Elements‐> Insert oppure Modify. In alternativa: Elements‐> popup menu‐> Insert‐>Element o Nodes‐> popup menu‐> Modify Element. Esistono due tipi di elementi di VPN: un gruppo (rappresentato da un SAS e da un insieme di indirizzi che devono essere protetti da tale apparato) e un client IPSec (applicativo crittografico della serie CryptoIP Amtec). Un client puo’ essere a sua volta statico o dinamico. ID : int, chiave che identifica univocamente un elemento di vpn NAME : varchar(30), nome dato ad un gruppo e/o client SAS_ID: int, id del relativo sas (preso dalla tabella sas) se è un elemento, 0=client ADDR: varchar(16), se è un elemento c’è il suo indirizzo, oppure il primo indirizzo del range; se è un client puo esserci il suo indirizzo oppure niente se è stato settato con l’indirizzo dinamico ADDR_MASK: int, maschera dell’indirizzo ADDR; oppure 0 nel caso di client ADDR_TO: varchar(16), specifico per range di indirizzi, è alternativo al campo ADDR_MASK I successivi 4 campi vengono settati se AuthType_IKP == “RSAsign” (solo per un gruppo); dato che piu’ ikePolicy possono essere associate ad una MapISakmp, occorre andare a vedere il comando “ADD SCERT nomeCA info MAP numeroMappa” e selezionare in RulesAccesslist l’ID_MIS relativa all’entry in cui SASPriorityType_RAL=numeroMappa, dopodiche’ su MapISakmp si seleziona quella mappa con ID_MIS come predefinita. ID_CN: varchar(255), è il CommonName nel caso in cui il tipo di autenticazione preveda l’uso di certificati; altrimenti e vuoto ID_OU: varchar(255), è l’OrganizationUnit nel caso in cui il tipo di autenticazione preveda l’uso di certificati; altrimenti e vuoto ID_O: varchar(255), è l’Organization nel caso in cui il tipo di autenticazione preveda l’uso di certificati; altrimenti e vuoto ID_C: varchar(3), è il campo Country nel caso in cui il tipo di autenticazione preveda l’uso di certificati; altrimenti e vuoto



Pagina 161 di 189

NET_ID: int, indica la rete di appartenenza di un elemento e deve essere impostato a 0 per i gruppi, mentre per un Client si puo’ settare se si vuole assegnare al “sas” una rete rappresentabile graficamente (verra riportato l’ID della tabella NETS) MODIFIED: int, indica se è cambiato qualche parametro a seguito dell’ultima operazione di build, in modo tale che nell’eventuale build successivo si selezionano solo i client con campo modified pari a 1; tale campo quindi serve solo per i client IPSec ed indica che deve essere aggiornata la configurazione. CA_ID: int, chiave esterna da associare alla tabella CA PBKEY_FILE: varchar(50), file contenente la chiave pubblica del client IPSec (quando il client ha la cifratura software) PRKEY_FILE: varchar(50), file contenente la chiave privata del client IPSec (quando il client ha la cifratura software) CACER_FILE: varchar(50), file contenenete il certificato della CA del client IPSec (quando il client ha la cifratura software) CRDEV_TYPE: int, tipo di dispositivo crittografico utilizzato dal client IPSec (Cryptocard, Smartcard, Software) ENAB_UNCFG: int, di default è pari a 0; abilita unconfigured IP traffic (solo per client CryptoIP) ACC_GTW: int, indica se il gruppo/client che si sta considerando può essere acceduto o meno dagli elementi appartenenti al proprio gruppo (0=false; 1=true); si setta dal sas manager COMPAT_REL: int, di default è pari a 0, rappresenta compatibility mode, specifica se usare una modalità di compatibilità specifica; 1= compatibilità con CryptoIP 3.1 ; 2= compatibilità con CryptoIP 3.3. IKEPOL Contiene tutti i campi necessari a definire una politica IKE. Modulo Console, Menu: Globals IKE Policies ID: int, chiave primaria NAME: varchar(30), nome dato alla policy IKE ENCR_ALG: int, tipo di algoritmo utilizzato per effettuare la cifratura (es.: 0 = DES; 1 = T‐DES; 2 = AESCBC128; 3 = AESCBC192; 4 = AESCBC256)



Pagina 162 di 189

HASH_ALG: int, tipo di algoritmo di hashing usato nella transazone IKE (es.: 0 = MD5; 1 = SHA1) DH_GROUP: int, gruppo Diffie Hellman utilizzato ( 0 = 768; 1 = 1024; 2 = 1536) AUTH_MODE: int, dipende dalla tipologia di autenticazione usata nella transazione IKE (0 = preshared; 1 = signature; 2 = signature + certificate) PRIORITY: int, priorità inserita dall’utente PSKEY: varchar(100), valore della preshared, se presente LIFE_SEC: int, durata della Security Association IKE in secondi LIFE_KB: int, durata della Security Association IKE in kilobyte REKEY: int, tempo limite dopo il quale rinegoziare una nuova chiave IPNODE Anagrafica dei nodi generici IP che si possono inserire nel SAS Manager oltre ai SAS Modulo Console: selezionare rete, popup menu‐>Insert‐>Generic Node ID: int, chiave primaria (prende ID consecutive a quello dei SAS!!!) NET_ID: int, id della rete di appartenenza DOMAIN_ID: int, non usato NAME: varchar(30), nome del nodo IP STATUS: int, status del nodo (1 = not responding (rosso), 3 = alive (verde, ecc.) ADDR: varchar(16), indirizzo IP POLL_PERIOD: int, polling period (‐1 = disabled; 0= server default; X= user defined) POLL_TYPE: int, vale sempre 0 per IPNODE (rappresenta tipo di polling, lifetest o status, ma status è disabilitato su IPNODE) B_FEATURES: int, (0 = nè SNMP, nè Firewall; 1 = has SNMP; 2 = is firewall; 3 = SNMP+firewall) GET_COMM: varchar(30), community SNMP get, vuoto se SNMP non è abilitato SET_COMM: varchar(30), community SNMP set, vuoto se SNMP non è abilitato



Pagina 163 di 189

SYS_OBJ_ID: varchar(40), SysObjectId del nodo, acquisito dalla MIB SNMP SYS_SERVICE: int, SysServices del nodo, acquisito dalla MIB SNMP IFC_STATUS: varchar(250), vettore degli stati delle interfacce del nodo POS_X: int, posizione nodo su asse x POS_Y: int, posizione nodo su asse y IPSECPOL Dati relative alle policy IPSEC. Modulo Console, Menu: Globals IPSec Policies ID: int, chiave primaria NAME: varchar(30), nome della policy IPSec LIFE_SEC: int, tempo di vita della SA in secondi (0 per lasciare default) LIFE_KB: int, tempo di vita della SA in kilobyte (0 per lasciare default) ANTIREPLAY: int, specifica se la protezione antireplay è abilitata (se settato a 1) SA_CONN: int, specifica come la SA deve essere creata (0 per lasciare default, 1 in accordo a source, 2 a destination, 3 source port, 4 destination port, 5 protocol) MNGDATA Identifica il gateway usato per le vpn di gestione. Modulo Console, Menu: Globals‐>Management VPNs ‐>Management Application IP Addresses. ID: int, chiave primaria SERV_ADDR: varchar(16), indirizzo dell’elemento che ospita il SAS Manager Engine ADDR_TO: varchar(16), maschera di sottorete / fine range dell’elemento che ospita il SAS Manager Engine



Pagina 164 di 189

MNGNAT Identifica il gateway usato per le vpn di gestione in caso di NAT. Modulo Console, Menu: Selected‐>Gateways ‐> Modify ‐> NAT ‐> Manager Side Translated Addresses. ID: int, chiave primaria MNG_ID: int, ID della vpn di gestione SAS_ID: int, ID del sas che deve essere raggiunto dal tunnel di gestione SERV_ADDR: varchar(16), indirizzi “nattati” che potrebbero essere assunti dall’elemento che ospita il SAS Manager Engine ADDR_TO: varchar(16), maschera di sottorete /fine range degli indirizzi “nattati” che potrebbero essere assunti dall’elemento che ospita il SAS Manager Engine MNGVPN Contiene le informazioni per definire la VPN di gestione, ovvero quella relativa alla connessione tra il gestore e gli altri Security gateway (su modulo Console, menu Globals‐>Management VPNs) ID: int, chiave primaria NAME: varchar(30), nome dell’apparato in cui risiede il software di gestione SAS_ID: int, id del sas di gestione (ovvero id del SAS che protegge l’elemento che contiene il SAS Manager e da cui partono quindi i tunnel di gestione); se pari a 0 vuol dire che non esiste un gateway di gestione e quindi la gestione dei sas avviene in chiaro IKE_ID: int, politica IKE predefinita IPSEC_ID: int, politica IPSEC predefinita SECUR_ON: int, indica se si intende applicare la cifratura nella gestione sempre e comunque, oppure solo in base alla configurazione dei singoli SAS IS_DEFAULT: int, vale 1 se è la vpn di management di default, altrimenti 0 NATPOOL



Pagina 165 di 189

Elenca i pool di NAT utilizzati dalla funzionalità di NAT su base certificato. Modulo Console, Menu: Selected‐> Nat Pools. ID: int, chiave primaria SAS_ID: int, ID del sas in questione NAME: varchar(30), nome associato al pool di indirizzi ADDR_FROM: varchar(16), primo indirizzo del pool ADDR_TO: varchar(16), ultimo indirizzo del pool ADDR_MASK: varchar(16), maschera di sottorete del pool di indirizzi PEERMAP Contiene tutte le informazioni sui peer. Modulo Console, Menu: Selected ‐> Peers List ID: int, chiave primaria SAS_ID: int, id del sas al quale è associato il peer PEER_ID: int, identificativo del peer; è un campo che si autoesclude con il successivo, quando è presente CLIENT_ID questo viene posto pari a 0 CLIENT_ID: int, analogo a PEER_ID MAP: int, numero della mappa utilizzata per comunicare con il peer NUM_CONN: int, riporta il numero complessivo di connessioni esistenti tra il SAS ed il peer nelle VPN NUM_CONNBK: int, indica il numero delle connessioni dirette come backup esistenti tra il sas ed il peer M_CLEAR: int, pari a 0 se la comunicazione tra sas e peer avviene in chiaro; pari a 1 se avviene in cifrato. SAS Contiene informazioni relative ai sas. Menu: Selected ‐> Gateways‐> Insert oppure Modify. In alternativa Nodes‐> popup menu‐> Insert‐>Gateway o Nodes‐> popup menu‐>Gateway ‐> Modify



Pagina 166 di 189

ID: int, chiave primaria NET_ID: int, ID della rete a cui appartiene il SAS NAME: varchar(30), nome dell’apparato TYPE: int, tipo del SAS (es. 0 = SAS‐860A, 1 = SAS‐860B, 10 = SAS‐860ENP, ecc.) STATUS: int, status del SAS (1 = not responding (rosso), 3 = alive (verde, ecc.) ADDR: varchar(16), indirizzo di gestione del SAS IFC: int, interfaccia di gestione del SAS(es. 1 = ETHERNET1, 2 = ETHERNET2, ecc.) ADDR_SEC: varchar(16), indirizzo di sicurezza (secure address) del SAS IFC_SEC: int, interfaccia di sicurezza del SAS (es. 1 = ETHERNET1, 2 = ETHERNET2, ecc.) GET_COMM: varchar(30), community SNMP get SET_COMM: varchar(30), community SNMP set PSSW_R: varchar(40), password di lettura (PASSWORD) PSSW_W: varchar(40), password di scrittura (PASSWORD1) DOMAIN_ID: int, non usato MODIFIED: int, codice che indica se i dati del gateway sono stati modificati (es.: 1 se è stata buildata la configurazione, 3 se è stata modificata la configurazione e non è stato eseguito un build successivo, ecc.) MASTER: int, vale 1 se il SAS è master nel VRRP o se il VRRP è disabilitato [BACKUP]: int, vale 0 se il VRRP è disabilitato, altrimenti contiene SAS.ID del VRRP peer POLL_PERIOD: int, periodo di polling del SAS in secondi (di default il polling automatico è disabilitato e il campo vale ‐1) ENAB_CLEAR: int, abilita il traffico EXTRAVPN se posto pari a 1. Di default è posto a 0 ENAB_NAT: int, abilita il NAT su base certificate se posto pari a 1, di default è pari a 0 MLEVEL: int, specifica quanti hop è lontano il SAS dall’apparato dove risiede il SAS Manager (serve per upload multiplo) NAT_ADDR: int, se pari a 1 indica che deve essere usato un indirizzo nattato per gestire il SAS (Gateway Side Translated Address abilitato) M_NAT_FROM: varchar(16), non più utilizzato, il NAT viene gestito nella tabella MNGNAT , lasciare vuoto



Pagina 167 di 189

M_NAT_TO: varchar(16), non più utilizzato, il NAT viene gestito nella tabella MNGNAT , lasciare vuoto M_NAT_GTW: varchar(16), indirizzo nattato del SAS di gestione ADDR_NAT: varchar(16), indirizzo di gestione nattato del SAS MNGVPN_ID: int, indica a quale VPN di gestione appartiene il SAS (quella di default è pari a 0) REDUN_IFC: int, interfaccia usata dal sas per il colloquio con il suo backup VRRP (ifc di gestione, di sicurezza o specifica) ENAB_SA_BK: int, specifica se deve essere abilitato il backup delle SA (1 = backup verso l’indirizzo di management, 2 = backup verso l’indirizzo di sicurezza, 3 = backup verso un indirizzo specificato nel campo SA_BK_ADDR) SA_BK_ADDR: varchar(16), indirizzo verso cui devono essere fatto il backup delle SA B_FEATURES: int, indica se sono abilitati firewall e SNMP; 0 = no SNMP no firewall, 1 = SNMP, 2 = firewall, 3 = SNMP + firewall SAS2 Contiene informazioni aggiuntive per la tabella SAS. Menu: Selected ‐> Gateways‐> Insert oppure Modify. In alternativa Nodes‐> popup menu‐> Insert‐>Gateway o Nodes‐> popup menu‐>Gateway ‐> Modify ID: int, chiave primaria (lo stesso della tabella SAS) LOG_REC: int, LOG_LOAD: int, MNG_PSKEY: varchar(100), contiene la chiave preshared specificata (diversa da quella precablata) ADDR_MSK: int, maschera relativa al campo ADDR nella tabella SAS ADDRSEC_MSK: int, maschera relativa al campo ADDRSEC nella tabella SAS POLL_TYPE :int, , rappresenta tipo di polling, 0 = lifetest; 1 =status ADDR_MOD: varchar(16), è l’indirizzo del SAS preso dalla tabella SAS ADDRMOD_MSK: int, relativa maschera



Pagina 168 di 189

REDUN_ADDR: varchar(16), eventuale indirizzo dellʹinterfaccia usata dal sas per il colloquio con il suo backup VRRP (serve solo quando sas.redun_ifc è unʹinterfaccia specifica) ROUTSEC_MAP: int, 0=indica che è presente la mappa 4; altrimenti indica il numero di mappa che sostituisce 4. COMPAT_REL: varchar(40), compatibility mode, specifica se usare una modalità di compatibilità specifica IFC_STATUS: varchar(250), vettore degli stati delle interfacce del sas (per ogni interfaccia si segnala se è alive, not responding, ecc.) POS_X : int, posizione sull’asse x POS_Y : int, posizione sull’asse y SERVICES Riferimento ai servizi abilitati nella network (su modulo Console, menu Globals‐>Services) ID: int, chiave primaria NAME: varchar(30), nome del selettore PROT: int, Protocol_RAL (ad ogni servizio corrisponde un determinato valore numerico fornito da Abbadia; in particolare 1 =TCP; 2 = UDP; 3 = ICMP; 4 = ALL; 6 = VRRP; 7 = OSPF; 8 = IGMP; 100X= valore X inserito dall’utente per un protocollo Specific) PORT_FROM: int, SourcePort_RAL (0 = all; se settiamo single, i valori possibili sono: 7 = echo; 13 = daytime; 20 = ftp(data); 21 = ftp; 23 = telnet; 25 = SMTP; 37 = time; 49 = TACACS; 53 = DNS; 69 = TFTP; 70 = gopher; 79 = finger; 80 = http; 88 = Kerberos; 109 = POP2; 110 = POP3; 115 = SFTP; 118 = SQLservices; 123 = NTP; 143 = IMAP; 161 = SNMP; 162 = SNMP(trap); 170 = NetworkPostScript; 213 = IPX; 280 =http_mgmt; 500 = isakmp; X = valore inserito dall’utente come FROM nel caso venga selezionato il campo RANGE) PORT_TO: int, DestinationPort_RAL (0 = all; se settiamo single assume gli stessi valori di PORT_FROM; X = valore inserito dall’utente come TO nel caso venga selezionato il campo RANGE) NOT_FLAG: int, porre uguale a zero (campo non utilizzato dal SM)



Pagina 169 di 189

TRANSFORMS Contiene le informazioni per la realizzazione dell’associazione tra politiche IPSEC e transform set. IPSEC_ID: int, id della policy Ipsec TRANSF_ID: int, fa riferimento al file esterno Varie.cpp VPNS Informazioni riguardanti la policy IKE e IPSec adottata dalle vpn. Modulo Console, Trees: VPNs‐> Modify VPN (sulla vpn selezionata). ID: int, chiave primaria NAME: varchar(30), nome della VPN NET_ID: int, (valore settato a 0 di default, non serve più) IKE_ID: int, ID che identifica la policy IKE adottata IPSEC_ID: int, ID che identifica la policy IPSec adottata BMP_ID: int, ID dell’immagine utilizzata (valore settato a 0 di default) BMP_SCALE: int, fattore di scala dell’immagine del layout MAP_WIDTH: int, larghezza del layout grafico della vpn MAP_HEIGHT: int, altezza del layout grafico della vpn BMP_FIT: int, adatta l’immagine selezionata per la vpn all’intero layout



Pagina 170 di 189

AAPPPPEENNDDIICCEE DD:: CCooddiiccee ddeellll’’AAlliiggnneerr In questa appendice vengono riportate le parti di codice più significative del modulo software Aligner. using System.Drawing; using System.Text; using System.Windows.Forms; using System.Data.OleDb; using System.Data.SqlClient; using System.Data.Common; using System.Collections; using System.Net; namespace Split_Compose { public partial class Aligner : Form { public Aligner() { InitializeComponent(); } string connessioneEDB = @"Data Source=(local)\SQLEXPRESS;Initial Catalog=EDB;Integrated Security=SSPI"; string connessioneSMDB = @"Data Source=(local)\SQLEXPRESS;Initial Catalog=SMDB;Integrated Security=SSPI"; private List<DataTable> ordinePopolamento = new List<DataTable>(); private List<DataTable> ordinePopolamEdb = new List<DataTable>(); //(parti di codice mancanti) public void Popolamento() { ordinePopolamento.Add(sasDataSet.sas); ordinePopolamento.Add(sasDataSet.connserv); ordinePopolamento.Add(sasDataSet.ipsecpol); ordinePopolamento.Add(sasDataSet.mudsessions); ordinePopolamento.Add(sasDataSet.bkpeer); ordinePopolamento.Add(sasDataSet.vpnsas); ordinePopolamento.Add(sasDataSet.conns); ordinePopolamento.Add(sasDataSet.actions); ordinePopolamento.Add(sasDataSet.vpngroup); ordinePopolamento.Add(sasDataSet.backmap); ordinePopolamento.Add(sasDataSet.mngdata); ordinePopolamento.Add(sasDataSet.vpns); ordinePopolamento.Add(sasDataSet.ipnode); ordinePopolamento.Add(sasDataSet.services); ordinePopolamento.Add(sasDataSet.extravpn); ordinePopolamento.Add(sasDataSet.confvpnc); ordinePopolamento.Add(sasDataSet.transforms); ordinePopolamento.Add(sasDataSet.ca); ordinePopolamento.Add(sasDataSet.groups); ordinePopolamento.Add(sasDataSet.mngvpn); ordinePopolamento.Add(sasDataSet.ikepol); ordinePopolamento.Add(sasDataSet.nodewarn); ordinePopolamento.Add(sasDataSet.soft);



Pagina 171 di 189

ordinePopolamento.Add(sasDataSet.gtw_log); ordinePopolamento.Add(sasDataSet.mngnat); ordinePopolamento.Add(sasDataSet.natpool); ordinePopolamento.Add(sasDataSet.peermap); ordinePopolamento.Add(sasDataSet.sas2); ordinePopolamento.Add(sasDataSet.clserv); ordinePopolamento.Add(sasDataSet.schedop); } public void PopolamentoEdb() { ordinePopolamEdb.Add(eDBDataSet.sas); ordinePopolamEdb.Add(eDBDataSet.connserv); ordinePopolamEdb.Add(eDBDataSet.ipsecpol); ordinePopolamEdb.Add(eDBDataSet.mudsessions); ordinePopolamEdb.Add(eDBDataSet.bkpeer); ordinePopolamEdb.Add(eDBDataSet.vpnsas); ordinePopolamEdb.Add(eDBDataSet.conns); ordinePopolamEdb.Add(eDBDataSet.actions); ordinePopolamEdb.Add(eDBDataSet.vpngroup); ordinePopolamEdb.Add(eDBDataSet.backmap); ordinePopolamEdb.Add(eDBDataSet.mngdata); ordinePopolamEdb.Add(eDBDataSet.vpns); ordinePopolamEdb.Add(eDBDataSet.ipnode); ordinePopolamEdb.Add(eDBDataSet.services); ordinePopolamEdb.Add(eDBDataSet.extravpn); ordinePopolamEdb.Add(eDBDataSet.confvpnc); ordinePopolamEdb.Add(eDBDataSet.transforms); ordinePopolamEdb.Add(eDBDataSet.ca); ordinePopolamEdb.Add(eDBDataSet.groups); ordinePopolamEdb.Add(eDBDataSet.mngvpn); ordinePopolamEdb.Add(eDBDataSet.ikepol); ordinePopolamEdb.Add(eDBDataSet.nodewarn); ordinePopolamEdb.Add(eDBDataSet.soft); ordinePopolamEdb.Add(eDBDataSet.gtw_log); ordinePopolamEdb.Add(eDBDataSet.mngnat); ordinePopolamEdb.Add(eDBDataSet.natpool); ordinePopolamEdb.Add(eDBDataSet.peermap); ordinePopolamEdb.Add(eDBDataSet.sas2); ordinePopolamEdb.Add(eDBDataSet.clserv); ordinePopolamEdb.Add(eDBDataSet.schedop); } private void cancel_Click(object sender, EventArgs e) { SqlConnection ConnSqlSM = new SqlConnection(connessioneSMDB); SqlConnection ConnSql = new SqlConnection(connessioneEDB); ConnSqlSM.Open(); ConnSql.Open(); foreach (DataTable tabella in ordinePopolamento) { string nome = tabella.TableName; SqlCommand del = new SqlCommand("DELETE FROM " + nome, ConnSqlSM); del.ExecuteNonQuery(); } foreach (DataTable tabellaEdb in ordinePopolamEdb) { string nome = tabellaEdb.TableName; SqlCommand del = new SqlCommand("DELETE FROM " + nome, ConnSql); del.ExecuteNonQuery(); } // è necessario ristabilire le condizioni inziali del DB (che non è vuoto)



Pagina 172 di 189

EDBDataSet.mngdataRow mngdatarow = eDBDataSet.mngdata.NewmngdataRow(); SASDataSet.mngdataRow mngdatarows = sasDataSet.mngdata.NewmngdataRow(); EDBDataSet.mngvpnRow mngvpnrow = eDBDataSet.mngvpn.NewmngvpnRow(); SASDataSet.mngvpnRow mngvpnrows = sasDataSet.mngvpn.NewmngvpnRow(); mngdatarow.ID = 1; mngdatarow.SERV_ADDR = "127.0.0.1"; mngdatarow.ADDR_TO = "255.255.255.255"; mngdatarows.ID = 1; mngdatarows.SERV_ADDR = "127.0.0.1"; mngdatarows.ADDR_TO = "255.255.255.255"; mngvpnrow.ID = 1; mngvpnrow.NAME = "def"; mngvpnrow.SAS_ID = 0; mngvpnrow.IKE_ID = 0; mngvpnrow.IPSEC_ID = 0; mngvpnrow.SECUR_ON = 0; mngvpnrow.IS_DEFAULT = 1; mngvpnrows.ID = 1; mngvpnrows.NAME = "def"; mngvpnrows.SAS_ID = 0; mngvpnrows.IKE_ID = 0; mngvpnrows.IPSEC_ID = 0; mngvpnrows.SECUR_ON = 0; mngvpnrows.IS_DEFAULT = 1; mngvpnrows.KEEP_ALIVE = 0; eDBDataSet.mngdata.AddmngdataRow(mngdatarow); sasDataSet.mngdata.AddmngdataRow(mngdatarows); eDBDataSet.mngvpn.AddmngvpnRow(mngvpnrow); sasDataSet.mngvpn.AddmngvpnRow(mngvpnrows); ConnSqlSM.Close(); ConnSql.Close(); SplitTextBox.AppendText("---------- SMDB successful deleted ----------" + "\n\n"); } private void align_Click(object sender, EventArgs e) { Fill_EDBdataSet(); // riempio il Dataset //--- SAS foreach (SASDataSet.sasRow sasrows in sasDataSet.sas.Rows) { EDBDataSet.Device_newRow devicenew = (EDBDataSet.Device_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Device_new.TableName, "Name_DEV", sasrow.NAME); EDBDataSet.sasRow sasrow = eDBDataSet.sas.NewsasRow(); sasrow.ID = sasrows.ID; sasrow.NAME = sasrows.NAME; sasrow.NET_ID = sasrows.NET_ID; sasrow.STATUS = sasrows.STATUS; sasrow.ADDR = sasrows.ADDR; sasrow.ADDR_SEC = sasrows.ADDR_SEC; sasrow.IFC = sasrows.IFC; sasrow.IFC_SEC = sasrows.IFC_SEC; sasrow.PSSW_R = sasrows.PSSW_R; sasrow.PSSW_W = sasrows.PSSW_W; if (!(devicenew.Type_DEV == -1)) { sasrow.TYPE = devicenew.Type_DEV;



Pagina 173 di 189

sasrows.TYPE = sasrow.TYPE; } if (!(ipgestnatrange[0] == -1)) { sasrow.ADDR_NAT = ipgestnatrange[0]; sasrows.ADDR_NAT = ipgestnatrange[0]; } if (!(devicenew.GET_Comm == -1)) { sasrow.GET_COMM = devicenew.GET_Comm; sasrows.GET_COMM = sasrow.GET_COMM; } if (!(devicenew.SET_Comm == -1)) { sasrow.SET_COMM = devicenew.SET_Comm; sasrows.SET_COMM = sasrow.SET_COMM; } try { if (devicenew.Enab_NAT==true) { sasrow.ENAB_NAT = 1; sasrows.ENAB_NAT = 1; } else { sasrow.ENAB_NAT = 0; sasrows.ENAB_NAT = 0; } } catch (Exception) {} if ((devicenew.FW_Status == false) && (devicenew.SNMP_Status == false)) { sasrow.B_FEATURES = 0; sasrows.B_FEATURES = 0; } else if ((devicenew.FW_Status == false) && (devicenew.SNMP_Status == true)) { sasrow.B_FEATURES = 1; sasrows.B_FEATURES = 1; } else if ((devicenew.FW_Status == true) && (devicenew.SNMP_Status == false)) { sasrow.B_FEATURES = 2; sasrows.B_FEATURES = 2; } else if ((devicenew.FW_Status == true) && (devicenew.SNMP_Status == true)) { sasrow.B_FEATURES = 3; sasrows.B_FEATURES = 3; }



Pagina 174 di 189

EDBDataSet.Protects_newRow protectsnew = (EDBDataSet.Protects_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Protects_new.TableName, "DEV_Id", devicenew.DEV_Id); EDBDataSet.Elements_newRow element1row = null; string redundantaddr = null; foreach (EDBDataSet.Interfaces_newRow ifcnews in (EDBDataSet.Interfaces_newRow[])eDBDataSet.Interfaces_new.Select("DEV_Id =" + devicenew.DEV_Id)) { if (ifcnews.Gest_Ifc==true) { string ifcname = ifcnews.Name_INT.ToUpper(); int ifcnum = Interfaces.GetIfc(ifcname); sasrow.IFC = ifcnum; sasrows.IFC = ifcnum; } try { if (ifcnews.VRRP_Ifc == true) { sasrow.REDUN_IFC = ifcnews.INT_Id; sasrows.REDUN_IFC = sasrow.REDUN_IFC; redundantaddr = ifcnews.Addr_INT; } } catch (Exception) { } } try { element1row = (EDBDataSet.Elements_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Elements_new.TableName, "ELEM_Id", protectsnew.ELEM_Id); } catch (Exception) { } EDBDataSet.CONNs_newRow connsnwrow = null; try { connsnwrow = (EDBDataSet.CONNs_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.CONNs_new.TableName, "ELEM_A_Id", element1row.ELEM_Id); } catch (Exception) { } EDBDataSet.Elements_newRow element2row = null; try { element2row = (EDBDataSet.Elements_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Elements_new.TableName, "ELEM_Id", connsnwrow.ELEM_B_Id); } catch (Exception) { } EDBDataSet.CONNsParam_newRow connsparam = null; try { connsparam = (EDBDataSet.CONNsParam_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.CONNsParam_new.TableName, "CONPAR_Id", connsnwrow.CONPAR_Id); } catch (Exception) { }



Pagina 175 di 189

EDBDataSet.VRRPArea_newRow vrrpnew = null; try { vrrpnew = (EDBDataSet.VRRPArea_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.VRRPArea_new.TableName, "VRRP_Id", protectsnew.VRRP_Id); sasrow.MASTER = vrrpnew.Master_Id; sasrows.MASTER = sasrow.MASTER; } catch (Exception) { } EDBDataSet.BKArea_newRow bkareanew = null; try { bkareanew = (EDBDataSet.BKArea_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.BKArea_new.TableName, "BKArea_Id", protectsnew.BKArea_Id); sasrow.BACKUP = bkareanew.Master_Id; sasrows.BACKUP = sasrow.BACKUP; } catch (Exception) { } try { if (protectsnew.Enab_SA_Backup == true) { sasrow.ENAB_SA_BK = 1; sasrows.ENAB_SA_BK = 1; sasrow.SA_BK_ADDR = redundantaddr; sasrows.SA_BK_ADDR = redundantaddr; } else { sasrow.ENAB_SA_BK = 0; sasrows.ENAB_SA_BK = 0; } } catch (Exception) { sasrow.ENAB_SA_BK = 0; sasrows.ENAB_SA_BK = 0; } try { if (((element1row.Is_Mng == true) || (element2row.Is_Mng == true)) && (connsnwrow.Enab_NAT == true)) { sasrow.NAT_ADDR = 1; sasrows.NAT_ADDR = 1; } } catch (Exception) {} if ((!(element1row == null)) && (element1row.Is_Mng == true)) { sasrow.M_NAT_GTW = connsparam.Remote_IP_A; sasrows.M_NAT_GTW = sasrow.M_NAT_GTW; } if ((!(element2row == null)) && (element2row.Is_Mng == true)) { sasrow.M_NAT_GTW = connsparam.Remote_IP_B; sasrows.M_NAT_GTW = sasrow.M_NAT_GTW; }



Pagina 176 di 189

eDBDataSet.sas.AddsasRow(sasrow); //---- SAS2 SASDataSet.sas2Row sas2rows = (SASDataSet.sas2Row)CoseUtili.GetTupla(sasDataSet, sasDataSet.sas2.TableName, "ID", sasrows.ID); EDBDataSet.sas2Row sas2row = eDBDataSet.sas2.Newsas2Row(); sas2row.ID = sas2rows.ID; sas2row.LOG_LOAD = sas2rows.LOG_LOAD; sas2row.LOG_REC = sas2rows.LOG_REC; sas2row.MNG_PSKEY = sas2rows.MNG_PSKEY; sas2row.ADDR_MSK = sas2rows.ADDR_MSK; sas2row.ADDRSEC_MSK = sas2rows.ADDRSEC_MSK; sas2row.ADDR_MOD = sas2rows.ADDR_MOD; sas2row.ADDRMOD_MSK = sas2rows.ADDRMOD_MSK; if (!(devicenew.Exit_Map == -1)) { sas2row.ROUTSEC_MAP = devicenew.Exit_Map; sas2rows.ROUTSEC_MAP = sas2row.ROUTSEC_MAP; } if (!(sasrow.IFC == sasrow.REDUN_IFC)) { sas2row.REDUN_ADDR = redundantaddr; sas2rows.REDUN_ADDR = redundantaddr; } eDBDataSet.sas2.Addsas2Row(sas2row); //sasDataSet.sas2.Addsas2Row(sas2rows); }

//--- BKPEER

foreach (EDBDataSet.BKArea_newRow bknewrow in eDBDataSet.BKArea_new.Rows) { EDBDataSet.bkpeerRow bkrow = eDBDataSet.bkpeer.NewbkpeerRow(); SASDataSet.bkpeerRow bkrows = sasDataSet.bkpeer.NewbkpeerRow(); bkrow.ID = bknewrow.BKArea_Id; bkrows.ID = bkrow.ID; EDBDataSet.Protects_newRow protectsnw = (EDBDataSet.Protects_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Protects_new.TableName, "BKArea_Id", bknewrow.BKArea_Id); EDBDataSet.Device_newRow devnw = (EDBDataSet.Device_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Device_new.TableName, "DEV_Id", protectsnw.DEV_Id); EDBDataSet.sasRow sasrw = (EDBDataSet.sasRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.sas.TableName, "NAME", devnw.Name_DEV); bkrow.SAS_ID = sasrw.ID; bkrows.SAS_ID = bkrow.SAS_ID; bkrow.PRIORITY = protectsnw.BKArea_Priority; bkrows.PRIORITY = bkrow.PRIORITY; } //---CA //La tabella CA_new gestisce le CA in maniera identica al SMDB foreach (EDBDataSet.CA_newRow canewrow in eDBDataSet.CA_new.Rows) { EDBDataSet.caRow carow = eDBDataSet.ca.NewcaRow(); SASDataSet.caRow carows = sasDataSet.ca.NewcaRow();



Pagina 177 di 189

carow.ID = canewrow.CA_Id; carows.ID = carow.ID; carow.NAME = canewrow.Name_CA; carows.NAME = carow.NAME; eDBDataSet.ca.AddcaRow(carow); sasDataSet.ca.AddcaRow(carows); } //--- CONNS //Le informazioni della tabella CONNS sono ora distribuite fra varie

tabelle foreach (EDBDataSet.CONNs_newRow connsnewrow in eDBDataSet.CONNs_new.Rows) { //@ i++; int j=0; EDBDataSet.connsRow connsrow = eDBDataSet.conns.NewconnsRow(); SASDataSet.connsRow connsrows = sasDataSet.conns.NewconnsRow(); EDBDataSet.extravpnRow extravpn = eDBDataSet.extravpn.NewextravpnRow(); SASDataSet.extravpnRow extravpns = sasDataSet.extravpn.NewextravpnRow(); EDBDataSet.CONNsParam_newRow connsparam = (EDBDataSet.CONNsParam_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.CONNsParam_new.TableName, "CONPAR_Id", connsnewrow.CONPAR_Id); EDBDataSet.CONNsServ_newRow connserv = (EDBDataSet.CONNsServ_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.CONNsServ_new.TableName, "CONN_Id", connsnewrow.CONN_Id); EDBDataSet.IKEArea_newRow ikeareanew = (EDBDataSet.IKEArea_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.IKEArea_new.TableName, "IKEArea_Id", connsnewrow.IKEAREA_Id); EDBDataSet.Elements_newRow elementa = (EDBDataSet.Elements_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Elements_new.TableName, "ELEM_Id", connsnewrow.ELEM_A_Id); EDBDataSet.Elements_newRow elementb = (EDBDataSet.Elements_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Elements_new.TableName, "ELEM_Id", connsnewrow.ELEM_B_Id); EDBDataSet.Protects_newRow protectsa = (EDBDataSet.Protects_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Protects_new.TableName, "ELEM_Id", elementa.ELEM_Id); EDBDataSet.Protects_newRow protectsb = (EDBDataSet.Protects_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Protects_new.TableName, "ELEM_Id", elementb.ELEM_Id); //---- MNGDATA & MNGNAT & MNGVPN if ((elementa.Is_Mng == true) || (elementb.Is_Mng == true)) { EDBDataSet.mngdataRow mngdatarow = eDBDataSet.mngdata.NewmngdataRow(); SASDataSet.mngdataRow mngdatarows = sasDataSet.mngdata.NewmngdataRow(); EDBDataSet.mngnatRow mngnatrow = eDBDataSet.mngnat.NewmngnatRow(); SASDataSet.mngnatRow mngnatrows = sasDataSet.mngnat.NewmngnatRow(); EDBDataSet.mngvpnRow mngvpnrow = eDBDataSet.mngvpn.NewmngvpnRow(); SASDataSet.mngvpnRow mngvpnrows = sasDataSet.mngvpn.NewmngvpnRow(); if (connsnewrow.CONN_Id==1) { mngdatarow.ID = 1000;



Pagina 178 di 189

mngdatarows.ID = 1000; mngvpnrow.ID = 1000; mngvpnrows.ID = 1000; } else { mngdatarow.ID = connsnewrow.CONN_Id; mngdatarows.ID = mngdatarow.ID; mngvpnrow.ID = connsnewrow.CONN_Id; mngvpnrows.ID = mngvpnrow.ID; } mngnatrow.ID = connsnewrow.CONN_Id; mngnatrows.ID = mngnatrow.ID; mngnatrow.MNG_ID = ikeareanew.IKEArea_Id; mngnatrows.MNG_ID = mngnatrow.MNG_ID; mngvpnrow.IKE_ID = ikeareanew.IKEPOL_Id; mngvpnrows.IKE_ID = mngvpnrow.IKE_ID; if (elementa.Is_Mng == true) //controllo se è il sas manager { // divido indirizzo da maschera string ipa = elementa.Addr; String[] ipfroma = ipa.Split('/'); mngdatarow.SERV_ADDR = ipfroma[0]; mngdatarows.SERV_ADDR = ipfroma[0]; mngdatarow.ADDR_TO = ipfroma[1]; mngdatarows.ADDR_TO = ipfroma[1]; mngnatrow.SERV_ADDR = ipfroma[0]; mngnatrows.SERV_ADDR = ipfroma[0]; mngnatrow.ADDR_TO = ipfroma[1]; mngnatrows.ADDR_TO = ipfroma[1]; mngnatrow.SAS_ID = protectsa.DEV_Id; mngnatrows.SAS_ID = mngnatrow.SAS_ID; mngvpnrow.SAS_ID = protectsa.DEV_Id; mngvpnrows.SAS_ID = mngvpnrow.SAS_ID; } else // allora è elementb il sas manager { string ipb = elementb.Addr; String[] ipfromb = ipb.Split('/'); mngdatarow.SERV_ADDR = ipfromb[0]; mngdatarows.SERV_ADDR = ipfromb[0]; mngdatarow.ADDR_TO = ipfromb[1]; mngdatarows.ADDR_TO = ipfromb[1]; mngnatrow.SERV_ADDR = ipfromb[0]; mngnatrows.SERV_ADDR = ipfromb[0]; mngnatrow.ADDR_TO = ipfromb[1]; mngnatrows.ADDR_TO = ipfromb[1]; mngnatrow.SAS_ID = protectsb.DEV_Id; mngnatrows.SAS_ID = mngnatrow.SAS_ID; mngvpnrow.SAS_ID = protectsb.DEV_Id; mngvpnrows.SAS_ID = mngvpnrow.SAS_ID; } eDBDataSet.mngdata.AddmngdataRow(mngdatarow); sasDataSet.mngdata.AddmngdataRow(mngdatarows); eDBDataSet.mngnat.AddmngnatRow(mngnatrow); sasDataSet.mngnat.AddmngnatRow(mngnatrows); eDBDataSet.mngvpn.AddmngvpnRow(mngvpnrow); sasDataSet.mngvpn.AddmngvpnRow(mngvpnrows); }



Pagina 179 di 189

else { foreach (EDBDataSet.Device_newRow devicea in (EDBDataSet.Device_newRow[])eDBDataSet.Device_new.Select("DEV_Id =" + protectsa.DEV_Id)) { foreach (EDBDataSet.Device_newRow deviceb in (EDBDataSet.Device_newRow[])eDBDataSet.Device_new.Select("DEV_Id =" + protectsb.DEV_Id)) { string daName = devicea.Name_DEV.ToUpper(); string dbName = deviceb.Name_DEV.ToUpper(); if ((daName == "NOBODY") || (dbName == "NOBODY")) { //--- EXTRAVPN extravpn.ID = connsnewrow.CONN_Id; extravpns.ID = extravpn.ID; extravpn.SAS_ID = (devicea.DEV_Id + deviceb.DEV_Id);

// l'id del sas nobody è zero extravpns.SAS_ID = extravpn.SAS_ID; // divido indirizzo da maschera string ipa = elementa.Addr; String[] ipfrom = ipa.Split('/'); extravpn.ADDR_FROM = ipfrom[0]; extravpns.ADDR_FROM = extravpn.ADDR_FROM; extravpn.MASK_FROM = ipfrom[1]; extravpns.MASK_FROM = extravpn.MASK_FROM; string ipb = elementb.Addr; String[] ipto = ipb.Split('/'); extravpn.ADDR_TO = ipto[0]; extravpns.ADDR_TO = extravpn.ADDR_TO; extravpn.MASK_TO = ipto[1]; extravpns.MASK_TO = extravpn.MASK_TO; EDBDataSet.CONNsServ_newRow connservnew = null; try { connservnew = (EDBDataSet.CONNsServ_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.CONNsServ_new.TableName, "CONN_Id", connsnewrow.CONN_Id); } catch (Exception) { } if (!(connservnew == null)) { extravpn.SERVICE_ID = connservnew.CONNsServ_Id; extravpns.SERVICE_ID = extravpn.SERVICE_ID; } eDBDataSet.extravpn.AddextravpnRow(extravpn); sasDataSet.extravpn.AddextravpnRow(extravpns); } else { connsrow.ID = connsnewrow.CONN_Id; connsrows.ID = connsrow.ID; connsrow.VPN_ID = ikeareanew.IKEArea_Id; connsrows.VPN_ID = connsrow.VPN_ID; connsrow.GROUP_A_ID = connsnewrow.ELEM_A_Id; connsrows.GROUP_A_ID = connsrow.GROUP_A_ID; connsrow.GROUP_B_ID = connsnewrow.ELEM_B_Id; connsrows.GROUP_B_ID = connsrow.GROUP_B_ID;



Pagina 180 di 189

connsrow.IPSEC_ID = connsnewrow.IPSec_Id; connsrows.IPSEC_ID = connsrow.IPSEC_ID; try { if (connsnewrow.Enab_NAT == true) { connsrow.ENAB_NAT = 1; connsrows.ENAB_NAT = 1; } else { connsrow.ENAB_NAT = 0; connsrows.ENAB_NAT = 0; } } catch (Exception) { } connsrow.PSKEY = ikeareanew.PSKEY_IKE; connsrows.PSKEY = connsrow.PSKEY; connsrow.IDENT_A = connsparam.ID_A; connsrows.IDENT_A = connsrow.IDENT_A; connsrow.IDENT_B = connsparam.ID_B; connsrows.IDENT_B = connsrow.IDENT_B; string ikeName = ikeareanew.IKE_Mode.ToUpper(); if (ikeName == "MAIN") { connsrow.EXC_MODE = 0; connsrows.EXC_MODE = 0; } else if (ikeName == "AGGRESSIVE") { connsrow.EXC_MODE = 1; connsrows.EXC_MODE = 1; } string iplocala = connsparam.Local_IP_A; string iplocalb = connsparam.Local_IP_B; String[] iplocalsa = iplocala.Split('/'); String[] iplocalsb = iplocalb.Split('/'); connsrow.GTW_ADDR_A = iplocalsa[0]; connsrows.GTW_ADDR_A = iplocalsa[0]; connsrow.GTW_ADDR_B = iplocalsb[0]; connsrows.GTW_ADDR_B = iplocalsb[0]; if (!(connsparam.KP_Alive_A == -1)) { connsrow.KP_ALIV_TM = connsparam.KP_Alive_A; connsrows.KP_ALIV_TM = connsrow.KP_ALIV_TM; } if (!(connsparam.KP_Alive_B == -1)) { connsrow.KP_ALIV_TMB = connsparam.KP_Alive_B; connsrows.KP_ALIV_TMB = connsrow.KP_ALIV_TMB; } if (!(connsparam.TM_Out_IKE == -1)) { connsrow.RESP_TM = connsparam.TM_Out_IKE; connsrows.RESP_TM = connsrow.RESP_TM; }



Pagina 181 di 189

if (!(connsparam.Ret_Num == -1)) { connsrow.RESP_TM_RET = connsparam.Ret_Num; connsrows.RESP_TM_RET = connsrow.RESP_TM_RET; } if (!(connsparam.NAT_Traversal_A == -1)) { connsrow.NATT_MODE = connsparam.NAT_Traversal_A; connsrows.NATT_MODE = connsrow.NATT_MODE; } connsrow.DHCP_SERV = connsparam.DHCP_Serv_Addr; connsrows.DHCP_SERV = connsrow.DHCP_SERV; eDBDataSet.conns.AddconnsRow(connsrow); sasDataSet.conns.AddconnsRow(connsrows); //--- PEERMAP EDBDataSet.peermapRow peerrowa = eDBDataSet.peermap.NewpeermapRow(); SASDataSet.peermapRow peerrowsa = sasDataSet.peermap.NewpeermapRow(); EDBDataSet.peermapRow peerrowb = eDBDataSet.peermap.NewpeermapRow(); SASDataSet.peermapRow peerrowsb = sasDataSet.peermap.NewpeermapRow(); peerrowa.ID = devicea.DEV_Id; peerrowsa.ID = peerrowa.ID; peerrowa.SAS_ID = devicea.DEV_Id; peerrowsa.SAS_ID = peerrowa.SAS_ID; peerrowa.PEER_ID = deviceb.DEV_Id; peerrowsa.PEER_ID = peerrowa.PEER_ID; if (!(connsparam.Map_Num_A == -1)) { peerrowa.MAP = connsparam.Map_Num_A; peerrowsa.MAP = peerrowa.MAP; } if (devicea.Features ==1) // controllo se è cryptoip { peerrowa.CLIENT_ID = devicea.DEV_Id; peerrowsa.CLIENT_ID = peerrowa.CLIENT_ID; } peerrowb.ID = deviceb.DEV_Id; peerrowsb.ID = peerrowb.ID; peerrowb.SAS_ID = deviceb.DEV_Id; peerrowsb.SAS_ID = peerrowb.SAS_ID; peerrowb.PEER_ID = devicea.DEV_Id; peerrowsb.PEER_ID = peerrowb.PEER_ID; if (!(connsparam.Map_Num_B == -1)) { peerrowb.MAP = connsparam.Map_Num_B; peerrowsb.MAP = peerrowb.MAP; } if (deviceb.Features == 1) //controllo se è cryptoip { peerrowb.CLIENT_ID = deviceb.DEV_Id; peerrowsb.CLIENT_ID = peerrowb.CLIENT_ID;



Pagina 182 di 189

} eDBDataSet.peermap.AddpeermapRow(peerrowa); sasDataSet.peermap.AddpeermapRow(peerrowsa); eDBDataSet.peermap.AddpeermapRow(peerrowb); sasDataSet.peermap.AddpeermapRow(peerrowsb); }// fine else per il traffico regolare (non extravpn) } // fine foreach sul deviceb } // fine foreach sul devicea } // fine else dopo l'if per la selezione del traffico di gestione } // fine foreach sulle connessioni //--- GROUPS foreach (EDBDataSet.Elements_newRow elementnew in eDBDataSet.Elements_new.Rows) { EDBDataSet.groupsRow grouprow = eDBDataSet.groups.NewgroupsRow(); SASDataSet.groupsRow grouprows = sasDataSet.groups.NewgroupsRow(); grouprow.ID = elementnew.ELEM_Id; grouprows.ID = grouprow.ID; grouprow.NAME = elementnew.Name_ELEM; grouprows.NAME = grouprow.NAME; string ip = elementnew.Addr; String[] ipaddr = ip.Split('/'); grouprow.ADDR = ipaddr[0]; grouprows.ADDR = grouprow.ADDR; if (ipaddr.Length>1) { if (ipaddr[1].Length < 4) { grouprow.ADDR_MASK = Convert.ToInt32(ipaddr[1]); } else { grouprow.ADDR_MASK = Mask.GetIpMask(ipaddr[1]); } } grouprows.ADDR_MASK = grouprow.ADDR_MASK; grouprow.ADDR_TO = ipaddr[0]; grouprows.ADDR_TO = grouprow.ADDR_TO; EDBDataSet.Certificate_newRow certificatenew = (EDBDataSet.Certificate_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Certificate_new.TableName, "CER_Id", elementnew.CER_Id); if (!(certificatenew==null)) { grouprow.ID_C = certificatenew.C_CER; grouprows.ID_C = grouprow.ID_C; grouprow.ID_CN = certificatenew.CN_CER; grouprows.ID_CN = grouprow.ID_CN; grouprow.ID_O = certificatenew.O_CER; grouprows.ID_O = grouprow.ID_O; grouprow.ID_OU = certificatenew.OU_CER; grouprows.ID_OU = grouprow.ID_OU; } EDBDataSet.CA_newRow canew = null; try { canew = (EDBDataSet.CA_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.CA_new.TableName, "CA_Id", certificatenew.CA_Id);



Pagina 183 di 189

} catch (Exception) { } EDBDataSet.Protects_newRow protectsnew = (EDBDataSet.Protects_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Protects_new.TableName, "ELEM_Id", elementnew.ELEM_Id); EDBDataSet.BKArea_newRow bkarea = (EDBDataSet.BKArea_newRow)CoseUtili.GetTupla (eDBDataSet, eDBDataSet.BKArea_new.TableName, "BKArea_Id", protectsnew.BKArea_Id); EDBDataSet.VRRPArea_newRow vrrparea = (EDBDataSet.VRRPArea_newRow)CoseUtili.GetTupla (eDBDataSet, eDBDataSet.VRRPArea_new.TableName, "VRRP_Id", protectsnew.VRRP_Id); EDBDataSet.Device_newRow devnew = (EDBDataSet.Device_newRow)CoseUtili.GetTupla(eDBDataSet, eDBDataSet.Device_new.TableName, "DEV_Id", protectsnew.DEV_Id); if (!(canew == null)) { grouprow.CA_ID = canew.CA_Id; grouprows.CA_ID = grouprow.CA_ID; } if (!(devnew == null)) { grouprow.SAS_ID = devnew.DEV_Id; grouprows.SAS_ID = grouprow.SAS_ID; } if (!(bkarea == null)) { grouprow.SAS_ID = bkarea.Master_Id; grouprows.SAS_ID = grouprow.SAS_ID; } if (!(vrrparea == null)) { grouprow.SAS_ID = vrrparea.Master_Id; grouprows.SAS_ID = grouprow.SAS_ID; } eDBDataSet.groups.AddgroupsRow(grouprow); sasDataSet.groups.AddgroupsRow(grouprows); } //(parti di codice mancanti) ScriviDB(); } private void exit_Click(object sender, EventArgs e) { this.Dispose(); } public void ScriviDB() // (ogni tabella nel DB in memoria viene aggiornata con la tabella del SasDataset) { SqlConnection SqlConnEDB = new SqlConnection(connessioneEDB); SqlConnEDB.Open(); SqlConnection SqlConnSMDB = new SqlConnection(connessioneSMDB); SqlConnSMDB.Open();



Pagina 184 di 189

SqlDataAdapter sqladapter; SqlDataAdapter sqladapterSM; foreach (DataTable tabella in ordinePopolamento) { string nometabella = tabella.TableName; // il builder serve ad aggiornare le tabelle del ds modificate sqladapterSM = new SqlDataAdapter("SELECT * FROM " + nometabella, SqlConnSMDB); new SqlCommandBuilder(sqladapterSM); sqladapterSM.Update(sasDataSet, nometabella); } foreach (DataTable tabella in ordinePopolamEdb) { string nometabella = tabella.TableName; sqladapter = new SqlDataAdapter("SELECT * FROM " + nometabella, SqlConnEDB); new SqlCommandBuilder(sqladapter); sqladapter.Update(eDBDataSet, nometabella); } SqlConnSMDB.Close(); SqlConnEDB.Close(); SplitTextBox.AppendText("---------- L'EDB è stato popolato----------" + "\n"); SplitTextBox.AppendText("---------- L'SMDB è stato popolato ----------" + "\n"); } public void Fill_EDBdataSet() //POPOLO IL DATASET EDB DAL DB // (ogni tabella nel dataset viene aggiornata con la tabella dell'EDB SQL) { SqlConnection ConnFill = new SqlConnection(connessioneEDB); ConnFill.Open(); foreach (DataTable tabella in eDBDataSet.Tables) { string nome = tabella.TableName; SqlDataAdapter adattatore = new SqlDataAdapter("SELECT * FROM " + nome, ConnFill); adattatore.Fill(eDBDataSet, nome); } ConnFill.Close(); SplitTextBox.AppendText("---------- Popolamento EDB Dataset ----------" + "\n"); } }

using System.Collections.Generic; using System; using System.Data; using System.Diagnostics; namespace Split_Compose { public class CoseUtili {



Pagina 185 di 189

public static System.Data.DataRow GetTupla(System.Data.DataSet dataset ,string nomeTabella, params object[] coppie) { //Devono essere coppie if ((coppie.Length % 2 != 0) || (coppie.Length == 0)) Debug.Fail("Parametri non corretti"); DataRow daRitornare = null; //Provo a cercare la tupla nel Dataset if (daRitornare == null) { string select = ""; for (int i = 0; i < coppie.Length; i += 2) { //Creo la stringa della select select += coppie[i] + "='" + coppie[i + 1] + "' AND "; } select = select.Remove(select.Length - 5, 5); //Cerco tutti i datarow compatibili con quella select DataRow[] rw = dataset.Tables[nomeTabella].Select(select); if (rw.Length == 1) daRitornare = rw[0]; } return daRitornare; } } }

using System; using System.Data; using System.IO; using System.Text; using System.Collections.Generic; using System.Text.RegularExpressions; using System.Diagnostics; using System.Security.Cryptography; using System.Runtime.InteropServices; namespace Split_Compose { //(parti di codice mancanti) static class Interfaces { /// <summary> /// Torna il codice (int) corrispondente al nome dell'interfaccia. /// </summary> public static int GetIfc(string Ifc) { // il matching è fatto dal file: C:\Programmi\Amtec\SAS Manager Console v3\devifc.ini if (Ifc == "ETHERNET1") { return 1; } else if (Ifc == "ETHERNET2") { return 2; }



Pagina 186 di 189

else if (Ifc == "ETHERNET3") { return 3; } else if (Ifc == "ETHERNET4") { return 4; } else if (Ifc == "ETHERNET5") { return 5; } else if (Ifc == "ETHERNET6") { return 6; } else if (Ifc == "SERIAL1") { return 7; } else if (Ifc == "SERIAL2") { return 8; } else if (Ifc == "SERIAL3") { return 9; } else if (Ifc == "SERIAL4") { return 10; } else if (Ifc == "ISDN1B") { return 11; } else if (Ifc == "COMPACT PCI") { return 12; } else if (Ifc == "SERIAL5") { return 13; } else if (Ifc == "SERIAL6") { return 14; } else if (Ifc == "LOOPBACK") { return 15; } else if (Ifc == "ISDN1PRI") { return 26; } else if (Ifc == "ADSL1") { return 30; } else if (Ifc == "IMA1") { return 31; }



Pagina 187 di 189

else if (Ifc == "TUNNEL") { return 32; } else if (Ifc == "SHDSL1") { return 33; } else if (Ifc == "ETHERNET7") { return 34; } else if (Ifc == "ISDNBUNDLE") { return 35; } else if (Ifc == "VOIP1") { return 36; } else if (Ifc == "VOIP2") { return 37; } else if (Ifc == "VOIP3") { return 38; } else if (Ifc == "VOIP4") { return 39; } else if (Ifc == "ISDN2B") { return 40; } else if (Ifc == "IMA2") { return 41; } else if (Ifc == "ADSL2") { return 42; } else if (Ifc == "SHDSL2") { return 43; } else if (Ifc == "ISDN3B") { return 44; } else if (Ifc == "ISDN4B") { return 45; } else return 0; } } }



Pagina 188 di 189

BBIIBBLLIIOOGGRRAAFFIIAA [1] AMTEC (2006) “SAS Manager 3.0 Manuale D’Uso”, Network Security Department, Aprile. [2] Atkinson R. e Kent S. (1998a) “Security Architecture for the Internet Protocol”, Standards Track RFC 2401, IETF. [3] Atkinson R. e Kent S. (1998c) “IP Encapsulating Security Payload (ESP)”. Standards Track RFC 2406, IETF, November 1998. [4] Atkinson R. e Kent S. (1998b) “IP Authentication Header (AH)” Standards Track RFC 2402, IETF. [5] Becherucci S. e Flamini R. (2006) “SAS Manager 3.0” Specifica Tecnica AMTEC, Network Security Department. [6] Carpenter B. e Jung C. (1999) “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels” Standards Track RFC 2529, IETF. [7] Carpenter B. e Moore K. (2001) “Connection of IPv6 Domains via IPv4 Clouds” Standards Track RFC 3056, IETF. [8] Carrel D. e Harkins D. (1998) “The Internet Key Exchange (IKE)”, Standards Track RFC 2409, IETF. [9] CCITT (1991) “Security Architecture for open systems interconnection for CCITT applications”, Recommendation X.800, ITU. [10] Cisco Systems Inc. “Implementing IPSec in IPv6” da “Cisco IOS IPv6 Configuration Library” < http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_configuration_guide_chapter09186a0080573b9c.html >, 2003, agg. 2005. [11] Cisco Systems Inc. “Implementing NAT Protocol Translation” da “Cisco IOS IPv6 Configuration Library” < http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_configuration_guide_chapter09186a00801d6600.html >, 2002, agg. 2005. [12] Cisco Systems Inc. “Implementing Tunneling for IPv6” da “Cisco IOS IPv6 Configuration Library” < http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_configuration_guide_chapter09186a00801d6604.html >, 2001, agg. 2006. [13] Durand A. et al. (2001) “IPv6 Tunnel Broker” Standards Track RFC 3053, IETF. [14] Gai S. (1998) “Internetworking IPv6 with Cisco Routers”, McGraw‐Hill Computer Communications Series.



Pagina 189 di 189

[15] Gilligan R. e Nordmark E. (2000) “Transition Mechanisms for IPv6 Hosts and Routers” Standards Track RFC 2893, IETF. [16] Housley R. (2005) “Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)” Standards Track RFC 4309, IETF. [17] Huitema C. (2001a) “An Anycast Prefix for 6to4 Relay Routers” Standards Track RFC 3068, IETF. [18] Huitema C. (2001b) “Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)” Standards Track RFC 4380, IETF. [19] Kaufman C. (2005) “Internet Key Exchange (IKEv2) Protocol” Standards Track RFC 4306, IETF. [20] Koutepas G. (2006) “IPv6 Transition Mechanisms, their Security and Management”, 6DISS Workshop. [21] Kent S. e Seo K. (2005) “Security Architecture for the Internet Protocol” Standards Track RFC 4301, IETF. [22] Maughan D. et al. (1998) “Internet Security Association and Key Management Protocol (ISAKMP)”, Standards Track RFC 2408, IETF. [23] Piper D. (1998) “The Internet IP Security Domain of Interpretation for ISAKMP” Standards Track RFC 2407, IETF. [24] Rekhter Y. et al. (1997) “An IPv6 Provider‐Based Unicast Address Forma” Standards Track RFC 2073, IETF. [25] Templin F. et al. (2005) “Intra‐Site Automatic Tunnel Addressing Protocol (ISATAP)” Standards Track RFC 4214, IETF.

Documents

FACOLTÀ DI INGEGNERIA - infocom.uniroma1.itinfocom.uniroma1.it/~robby/Tesi/Alessandrelli 2006-07.pdf · Corso di Laurea Specialistica in Ingegneria delle Telecomunicazioni A.A. 2006/2007