Test del funzionamento di un Rendez-vous Server mediante l implementazione InfraHIP

Transcript

1 Facoltá di Ingegneria Corso di Studi in Ingegneria Informatica Elaborato finale in Protocolli per Reti Mobili Test del funzionamento di un Rendez-vous Server mediante l implementazione InfraHIP Anno Accademico 2012/2013 Candidato: PAOLA VENUSO matr. N

2 Indice Introduzione Host Identity Protocol Basi del protocollo Sicurezza Multihoming Mobilitá Rendez-vous Server Presupposti al Rendez-vous Server Protocollo di registrazione Funzionamento Parametri Host Identity Protocol for Linux Progetto InfraHIP Implementazione di HIPL Host Identiers Endpoint Resolution HIPL Application Programming Interfaces Legacy HIP API Native HIP API Architettura di HIPL Kernel Based Version User Space Version Testing Procedura di installazione Requisiti e dipendenze Installazione Test di prova di un Base Exchange Test del Rendez-vous Server Congurazione del RVS Test Analisi dei pacchetti Registrazione Pacchetto I Pacchetto R i

3 INDICE Pacchetto I Pacchetto R Base Exchange Pacchetto I Pacchetto R Pacchetto I Pacchetto R HIP Update Primo pacchetto Secondo pacchetto Terzo pacchetto Conclusioni Bibliograa ii

4 Introduzione L'idea di creare un protocollo come Host Identity Protocol (HIP) nasce dalle diverse mancanze mostrate dal protocollo IP. Infatti analizzando l'incredibile evoluzione di Internet degli ultimi anni é possibile notare quanto IP sia vulnerabile o carente nel contrastare attacchi DoS, nella gestione di terminali mobili e multi-homed ed inne nel garantire autenticitá e condenzialitá dei messaggi. Nonostante nel tempo siano state proposte diverse soluzioni a tali problematiche, esse non sono mai risultate del tutto soddisfacenti mostrandosi adatte alla risoluzione di un solo problema per volta. Il protocollo HIP é stato proposto come soluzione integrata a tutti questi problemi. Nel presente elaborato si studierá InfraHIP, un' implementazione del protocollo HIP per i sistemi Linux, ed in particolar modo il funzionamento del Rendez-vous Server nel contesto del supporto alla mobilitá. 1

5 Capitolo 1 Host Identity Protocol 1.1 Basi del protocollo L'idea di creare il protocollo HIP [1] nacque per la prima volta in ambito IETF nel Fino al 2003 peró lo sviluppo di tale idea rimase ad uno stadio informale. Infatti solo nel 2004 ci fu la creazione di un Working Group e di un Research Group. La standardizzazione é avvenuta poi nella RFC 4423 del Il concetto principale su cui é basato HIP prevede la separazione tra ció che identica un nodo e ció che indica la sua posizione in Internet. L'identicatore di un nodo é detto locator e l'indicatore della posizione di un nodo in Internet viene chiamato identier. Nel protocollo IP queste due funzioni vengono entrambe svolte dall'indirizzo IP. Con l'avvento della mobilitá l'identicazione di un nodo con IP non é piú univoca, per questo motivo HIP divide le due funzioni assegnandole a due forme diverse di Host Identity: Host Identity Tag (HIT ) e Local Scope Identity (LSI ). HIT e LSI assomigliano rispettivamente ad indirizzi IPv6 e IPv4 in modo da mantenere la compatibilitá con applicazioni legacy. Nella pratica vengono utilizzati gli indirizzi HIT e LSI no al livello trasporto, mentre dal livello di rete in giú si utilizza l'indirizzo IP. Quindi tra livello di trasporto e livello di rete viene posto un nuovo livello HIP, come mostrato in Figura 1.1, che si occupa di tradurre gli indirizzi HIT e LSI negli indirizzi IP corrispondenti. In questo modo il livello IP non deve subire modiche e il livello applicazione e il livello trasporto vedono sempre lo stesso HIT anche se il nodo si muove. Nelle sezioni seguenti vedremo come HIP si occupa dei problemi relativi a sicurezza, multihoming e mobilitá. 2

6 CAPITOLO 1 Figura 1.1: Livello HIP 1.2 Sicurezza Per garantire la sicurezza nelle trasmissioni tutti i messaggi dati HIP vengono cifrati con IPsec ESP [2]. Quindi i nodi che si scambiano questi messaggi devono prima stabilire una Security Association, identicata da un SPI e legata agli HIT. Per l'utilizzo della cifratura IPsec ESP é necessario, per i nodi interessati, conoscere una chiave condivisa. Avviene allora una fase di Base Exchange in cui l'initiator (il nodo che vuole instaurare la connessione) ed il Responder (il nodo destinatario della richiesta di connessione) si scambiano la sequenza di pacchetti I1, R1, I2, R2. Tramite questo scambio il Responder invia un Cryptographic Puzzle all'initiator, in modo tale da contrastare attacchi di tipo DoS. Inoltre é presente un parametro Opaque da ricopiare nelle risposte dell'initiator per prevenire replay attack. Alla ne dello scambio di pacchetti ogni nodo manterrá una HIP association con l'altro nodo, contenente: HIT (oppure LSI) locale e dell'altro nodo 3

7 CAPITOLO 1 Indirizzo IP locale e dell'altro nodo Porto UDP locale e dell'altro nodo (nel caso di NAT) Keying material IPsec prevede la modalitá Transport Mode e la modalitá Tunnel mode. Per evitare peró alcuni problemi di queste due modalitá ne é stata introdotta una terza, utile nell'utilizzo di HIP: Beet. Secondo questo meccanismo nella SA vengono memorizzate due coppie di indirizzi, una esterna per l'instradamento ed una interna vista dall'applicazione. Gli indirizzi vengono scambiati in trasmissione e in ricezione nell'header IP, cosí da evitare problemi di attraversamento del NAT e di controllo checksum presenti nelle due precedenti modalitá. 1.3 Multihoming La gestione di piú interfacce di rete di uno stesso dispositivo é un'altra caratteristica di HIP. In IP questo meccanismo non é facilmente realizzabile, mentre in HIP viene utilizzato anche per la stessa comunicazione in maniera parallela. Essenzialmente il livello HIP associa diversi indirizzi IP allo stesso HIT. Un problema che puó nascere é legato all'utilizzo di percorsi diversi, provocando l'arrivo dei pacchetti fuori della replay protection window con scarto conseguente dei pacchetti. Per risolvere l'inconveniente si usa una diversa SA per ogni indirizzo IP, mantenendo lo stesso HIT. 1.4 Mobilitá Quando un nodo mobile si sposta in un'altra rete il suo indirizzo IP cambia. Se c'é una connessione TCP in atto essa resta attiva poiché l'indirizzo HIT non cambia. Infatti le entitá TCP fanno riferimento agli HIT. Il nodo mobile peró deve comunicare la sua nuova posizione in modo da aggiornare l'associazione tra l'ip e l'hit. L'aggiornamento avviene tramite lo scambio di un messaggio di UPDATE in cui il parametro LOCATOR contiene il nuovo indirizzo IP. In realtá la procedura di update é costituita 4

8 CAPITOLO 1 dallo scambio di tre messaggi. Questo sistema é stato scelto per proteggere la comunicazione da replay attack. Quindi il primo messaggio é quello di update, il secondo verica che il nodo mobile sia disponibile al nuovo indirizzo, il terzo contiene la copia del parametro Opaque contenuto nel secondo come ulteriore misura di sicurezza. In questo modo un attaccante che ha ascoltato un terzo messaggio precedente dovrebbe inserire un nuovo valore Opaque e ricalcolare la checksum, per la quale peró serve la chiave segreta. 5

9 Capitolo 2 Rendez-vous Server 2.1 Presupposti al Rendez-vous Server Un nodo mobile che si sposta frequentemente da una rete all'altra cambia altrettanto frequentemente indirizzo IP. Con Mobile IP un nodo mobile é comunque raggiungibile al suo indirizzo IP permanente, anche quando si trova in una rete ospitante. Infatti l'home agent intercetta i pacchetti destinati al nodo mobile e li inoltra verso la rete ospitante in cui si trova il nodo in quell'istante. I nodi che implementano HIP non possono stabilire un'associazione HIP se non conoscono l'indirizzo IP corrente del nodo destinatario. Per questo motivo é stato introdotto il Rendez-vous Server [3], un nodo con la funzione di conoscere sempre l'indirizzo IP aggiornato del nodo mobile. Esso conosce sempre l'ip del nodo poiché quest'ultimo eettua un procedura di registrazione. Mentre un nodo che vuole contattare il Rendez-vous Server ottiene l'indirizzo di quest'ultimo da una semplice query DNS. Nei paragra che seguono analizzeremo nel dettaglio la procedura di registrazione e i parametri dei pacchetti nel base exchange con un RVS. 2.2 Protocollo di registrazione Il nodo mobile si registra presso il Rendez-vous Server seguendo un preciso protocollo [4], implementato come un HIP base exchange ma con dei parametri addizionali. In generale, il nodo presso cui ci si deve registrare ore una lista di servizi (tra cui quello di RVS), usando il parametro REG_INFO nel messaggio R1 o nel messaggio UPDATE. Il nodo richiedente include il parame- 6

10 CAPITOLO 2 tro REG_REQUEST nel messaggio I2 o nel messaggio UPDATE scegliendo il servizio desiderato. Dopo aver ricevuto quest'ultimo messaggio, il server puó autenticare ed autorizzare il richiedente, tramite la sua chiave pubblica. Se l'autenticazione é andata a buon ne viene creata una corrispondenza tra servizio e richiedente. Altrimenti nel messaggio di ritorno é presente il parametro REG_FAILED. Se il richiedente prova a registrarsi per piú servizi contemporaneamente ed alcuni falliscono, i messaggi R2 e UPDATE contengono entrambi i parametri REG_RESPONSE e REG_FAILED. Un esempio é visibile in Figura 2.1. Figura 2.1: Esempio di registrazione L'operazione di refresh é iniziata dal server con un messaggio di UPDATE e viene poi completata come un ri-registrazione, con due ulteriori messaggi di UPDATE. La registrazione puó essere cancellata inviando un messaggio REG_REQUEST o REG_RESPONSE con il valore lifetime posto a zero. 2.3 Funzionamento Una volta eettuata la registrazione presso il Rendez-vous Server, ogni volta che il suo indirizzo IP cambia il nodo mobile deve comunicarlo al RVS. Se é giá presente una associazione HIP tra due nodi allora quello che cambia indirizzo IP puó comunicarlo direttamente all'altro nodo. Infatti l'uso del RVS si limita al contatto iniziale tra due nodi, di cui uno mobile, che non hanno un'associazione HIP preesistente. 7

11 CAPITOLO 2 L'unico pacchetto che passa per il RVS é I1, gli altri vengono scambiati direttamente tra i due nodi. In Figura 2.2 é possibile vedere un esempio di HIP base exchange con un RVS. Figura 2.2: HIP base exchange con RVS Il RVS confronta l'hit destinazione del pacchetto I1 con il proprio, se non coincidono controlla se ci sono associazioni attive per quell'hit. Allora se esiste tale associazione, il RVS sostituisce l'indirizzo destinatario nell'header IP del pacchetto I1 con quello associato all'hit. Inoltre il RVS sostituisce l'indirizzo sorgente in I1 con il proprio, ricalcola la checksum e inoltra I1 all'ip associato all'hit destinatario. In questo meccanismo si puó notare un'importante dierenza con Mobile IP: il Rendez-vous Server é necessario solo per l'inoltro del primo pacchetto, a dierenza dell'home agent che deve inoltrare tutti i pacchetti al nodo mobile. Ció accade perché il Responder invia il pacchetto R1 direttamente all'initiator il quale a questo punto conoscerá l'ip del Responder e potrá comunicare con quest'ultimo direttamente. In ultimo, se il RVS riceve un pacchetto con valore NULL nel campo del Responder HIT, allora interpreta il pacchetto come richiesta di associazione HIP con se stesso Parametri Il nodo Responder deve conoscere l'indirizzo IP dell'initiator per poter rispondere con un messaggio R2. Abbiamo giá visto che il RVS sostituisce il proprio indirizzo a quello sorgente nel pacchetto I1, ma oltre a questo aggiunge un parametro chiamato 8

12 CAPITOLO 2 FROM contenente l'indirizzo del reale sorgente ed anche un parametro RVS HMAC. Risulta chiaro che il Responder conosce l'ip dell'initiator grazie al parametro FROM inserito dal RVS. Il Responder poi aggiunge al pacchetto R2 il parametro VIA che contiene l'indirizzo IP del RVS da cui ha ricevuto il pacchetto I1. Il parametro VIA é pensato proprio per accertare le operazioni di associazione HIP. Il parametro VIA puó contenere indirizzi IP di piú RVS. 9

13 Capitolo 3 Host Identity Protocol for Linux 3.1 Progetto InfraHIP Il progetto InfraHIP [5] é stato creato da Helsinki University of Technology (TKK) e Helsinki Institute for Information Technology (HIIT). Nell'ambito di tale progetto é stato sviluppato HIP for Linux [6] e sono stati approfonditi gli aspetti di HIP relativi alle applicazioni, come ad esempio: API, Rendez-vous Server, sicurezza, end-point multipli in un singolo nodo. HIP for Linux verrá presentato nei paragra seguenti, illustrandone implementazione ed architettura [7]. 3.2 Implementazione di HIPL L'implementazione corrente di HIPL é basata sul kernel Linux standard versione Essa é essenzialmente composta da tre elementi: HIP kernel module; HIP socket handler; User space resolver library; Inoltre é presente hipconf, un semplice user space program, usato per la congurazione degli host. Esistono poi due versioni di HIPL, Kernel Based Version e User Space Version, che verranno in seguito analizzate e confrontate. Mentre nei due sotto-paragra che seguono illustreremo due importanti aspetti di HIPL: Host Identiers e Endpoint Resolution. 10

14 CAPITOLO Host Identiers Gli Host Identiers sono divisi in due categorie: quelli forniti dal sistema operativo e quelli forniti dalle applicazioni. Gli Host Identiers appartenenti alla prima categoria sono conservati sicamente nel le /etc/hip. Le chiavi asimmetriche vengono conservate in le formattati secondo Privacy Enhanced Mail (PEM ). In questo modo un HI locale viene comunicato prendendo la corrispondente chiave privata, codicata con PEM, dal le system. L'HI rappresenta proprio la chiave pubblica, la quale viene dedotta dalla chiave private presa dal kernel Endpoint Resolution Per stabilire una connessione con un nodo in genere le applicazioni di rete usano Fully Qualied Domain Name (FQDN ). Per trovare l'indirizzo IP viene eetutata una query DNS. L'interfaccia che gestisce la risoluzione dei nomi é detta Resolver. Tale interfaccia é composta da una serie di funzioni per permettere alle applicazioni di tradurre gli indirizzi di rete in nomi DNS e viceversa. Le connessioni stabilite con HIP usano gli HIT come endpoint identiers invece che usare gli indirizzi IP. Il kernel deve comunque essere a conoscenza dell'indirizzo IP corrispondente all'hit risolto, in modo tale da poter trasmettere i pacchetti alla giusta destinazione. Il mapping tra HIT e IP é infatti parte integrante del processo di risoluzione dei nomi. Le funzioni di cui sopra vengono chiamate dalle applicazioni fornendo come argomento il nome dell'host, mentre il Resolver effettua la query DNS che fornisce in risposta l'hit e l'ip corrispondente. In seguito, é lo stesso Resolver a passare queste informazioni all'hipl kernel module. L'ultimo passo compiuto dal Resolver é quello di restituire all'applicazione un Endpoint Descriptor oppure un HIT. Nella corrente implementazione di HIPL la risoluzione endpoint é congurata manualmente tramite il le /etc/host/hipl, come vedremo in seguito nella fase di congurazione precedente al testing. 11

15 CAPITOLO HIPL Application Programming Interfaces Le API [8] supportano le funzionalitá di rete di base necessarie alle applicazioni come ad esempio identity resolution e binding to sockets. Figura 3.1: Modello a livelli con API Dal punto di vista di HIP ci sono due tipologie di applicazioni di rete: quelle che usanpo il protocollo HIP in modo esplicito ricorrendo alle API Native e quelle che usano HIP attraverso le API Legacy. In Figura 3.1 si puó vedere il modello a livelli con le API Legacy HIP API I sistemi operativi basati su UNIX utilizzano libc, una libreria standardizzata del linguaggio C, la quale fornisce una interfaccia per le socket. Esiste peró un'altra implementazione chiamata libinet6 appartenente al progetto USAGI [9]. Proprio a questa implementazione si riferiscono le API Legacy le quali permettono alle applicazioni di utilizzare il protocollo HIP in maniera trasparente. In pratica solo la funzione getaddrinfo é stata modicata per permettere questa funzionalitá. Le applicazioni Legacy si servono di una interfaccia per le socket che non viene modicata. Sappiamo che gli indirizzi HIT sono compatibili con le IPv6 API per via del collegamento tra gli indirizzi HIT e quelli IPv6. Si deduce quindi che gli HIT possono essere usati con le socket IPv6. 12

16 CAPITOLO 3 Per abilitare le Legacy API esistono due diversi approcci: trasparente ed esplicito. Il primo viene usato con l'opzione transparent HIP mode ed in questo modo la funzione getaddrinfo restituisce l'hit prima degli indirizzi IPv6. Se il Resolver non riesce a trovare un collegamento tra l'hit e il nome dell'host la funzione restituisce al chiamante l'indirizzo IPv6. I vantaggi di questo approccio sono: la retrocompatibilitá con le applicazioni di rete legacy e il non dover modicare il codice delle applicazioni legacy (con la condizione che esse siano ben collegate con la libreria libinet6). Il secondo approccio invece prevede l'utilizzo di uno speciale ag, detto AI_HIP, il quale viene passato a getaddrinfo che restituisce solo gli HIT quando tale ag é settato. Questa soluzione implica peró la necessitá di introdurre alcune modiche al codice delle applicazioni Native HIP API Le applicazioni che utilizzano le API Native sono di tipo aware ovvero sono applicazioni che hanno un certo grado di controllo sul livello HIP e sugli Host Identiers (possono ad esempio specicare il proprio HI). In questo contesto é stata introdotta la famiglia PF_HIP per le socket API. Per poter usufruire delle API Native la costante PF_HIP deve essere passata come parametro alla funzione della socket. Un concetto molto importante per quanto riguarda queste API é l'endpoint Descriptor (ED) che funge da riferimento per gli HI. Le API Native perfezionano il modello dell'hip namespace. Inoltre il livello applicazione viene ridenito e per identicare le dierenti associazioni usa: ED sorgente, ED destinazione, porto sorgente, porto destinazione e tipo di protocollo di trasporto. L'interfaccia dell'ed é la sruttura sockaddr_ed: s t r u c t sockaddr_ed { unsigned s h o r t i n t ed_family ; in_port_t ed_port ; sa_ed_t ed_val ; } 13

17 CAPITOLO 3 Il campo ed_family é sempre settato a PF_HIP per indicare che la famiglia di socket é di tipo nativo. Mentre il campo ed_port contiene un numero di porto del livello di trasporto. Inne il campo ed_val é un identicatore unico dell'ed contenuto nell'hip kernel module e usato dal kernel per fare riferimento ad ED. L'impiego di questa struttura invece che sockaddr_in é l'unica dierenza introdotta rispetto alle funzioni delle comuni socket API. 3.4 Architettura di HIPL Come giá anticipato nei paragra precedenti, l'implementazione di HIPL prevede due versioni: Kernel Based Version e User Space Version. Nei due paragra che seguono analizzeremo queste due implementazioni e le confronteremo, con particolare attenzione alla Kernel Based Version Kernel Based Version In questa versione le applicazioni fanno uso della resolver library libinet6 giá citata in precedenza. Il Resolver comunica con l'hipl Kernel Module a cui sono inoltrate le chiamate alle socket native dall'hip socket handler. Le applicazioni Legacy si servono delle IPv6 socket API ma impiegano gli indirizzi HIT al posto di quelli IPv6. In Figura 3.2 é illustrata l'architettura di questa implementazione. La gura é divisa in user space e kernel space. Questa seconda sezione contiene il Kernel Module il quale implementa il protocollo HIP. Il Kernel Module si occuperá allora del base exchange, di mantenere le associazioni HIP e delle altre funzioni relative alla mobilitá come ad esempio i messaggi di update. La parte piú importante del Kernel Module é il khipd kernel thread. Questo thread resta in attesa di compiti da eseguire, i quali saranno generati e inoltrati allo stesso thread all'arrivo dei pacchetti HIP. Inoltre il Kernel Module ingloba anche l'hip socket handler. Un altro importante aspetto di questa architettura é la comunicazione tra il kernel space e lo user space che avviene tramite 14

18 CAPITOLO 3 Figura 3.2: Architettura Kernel Based Version speciche socket. In particolare lo user space comunica con l'hip kernel module attraverso la famiglia di socket PF_HIP. I dati scambiati tra user e kernel space sono praticamente dello stesso tipo di quelli racchiusi nei pacchetti HIP e quindi viene riutilizzato proprio lo stesso formato usato per i messaggi del protocollo HIP. Dal lato user space la comunicazione é portata avanti dalla resolver library e dallo strumento hipconf. Dal lato kernel space invece interviene l'hip socket handler. In generale comunque le applicazioni dello user space non comunicano direttamente con il kernel module ma sempre tramite le routines delle API Legacy o Native. HIPL si serve di particolari funzioni, dette hook, sia in input che in output, per bypassare il controllo dei pacchetti nello stack IPv6 ed eventualmente, se necessario, incaricare di tale controllo proprio il kernel module. Le hook functions sono: 1. hip_get_addr; 2. hip_handle_output; 3. hip_get_saddr; 4. hip_get_default_spi_out; 15

19 CAPITOLO 3 5. hip_handle_esp; Le prime due sono impiegate per convertire gli HIT sorgente e destinazione negli IPv6 corrispondenti nel livello IP in output. La terza stabilisce l'hit sorgente di un pacchetto che ha un HIT come indirizzo di destinazione. La quarta funzione di hook trova il valore SPI per i pacchetti ESP in uscita e l'ultima funzione rimpiazza gli IPv6 con gli HIT dei pacchetti in ingresso prima che questi vengano inoltrati al modulo IPsec. In seguito alle operazioni eseguite da quest'ultima funzione hook, il modulo IPsec cerca la corrispondente Security Association e se non ne trova una per l'indirizzo dato come destinazione viene chiamata la seconda hook function che innesca l'hip base exchange. In questo modo si avranno due SA e un'associazione HIP. Le informazione relative all'associazione HIP sono memorizzate nella Host Association Database (HADB) che é una hash table formata da HA entry. Esiste anche un Endpoint Descriptor Database (ED DB) impiegato dall'hip socket handler per conservare gli endpoint descriptor. Ogni ED entry é formata da una struttura sockaddr_ed e dal corrispondente HIT. Altre due importanti componenti della Kernel Based Version sono il Resolver e l'hip socket handler. Il primo si occupa della risoluzione endpoint per applicazioni di rete e della comunicazione al kernel module del mapping degli HI, HIT ed IP. L'HIP socket handler invece si occupa delle chiamate alle API che gli vengono inoltrate quando queste appartengono alla famiglia PF_HIP. Tale componente supporta anche gli ED, ha il compito di convertire in HIT corrispondenti e poi si occupa di inoltrare le chiamate delle API Native al Linux IPv6 Module User Space Version A dierenza della versione appena vista che prevede solo un khipd kernel thread, nella User Space Version si aanca a tale thread uno user space daemon (o piú semplicemente demone). La maggior parte delle operazione relative al protocollo HIP é compiuta da questo demone mentre le funzioni del kernel module sono essenzialmente limitate all'inoltro dei messaggi. Questa implementazione é mostrata in Figura

20 CAPITOLO 3 Figura 3.3: Architettura User Space Version Ci sono delle signicative dierenze nelle strutture dati del kernel rispetto al caso precedente. Per esempio l'hadb é stato rilocato nello user space e quindi una host association entry contiene ora l'hi usato per quella specica associazione. É stato poi aggiunto nel kernel module un database ausiliario chiamato BEETDB usato per abilitare l'integrazione HIP - IPsec. Nella pratica esso replica alcune informazione dell'hadb. Nella versione Kernel Based tutte le funzioni crittograche sono implementate nel kernel ma nella versione User Space si fa riferimento alla libreria OpenSSL per funzioni di crittograa e quindi tutte le operazioni di crittograa in HIP sono eettuate nello user space. Con la User Space Version allora anche gli HI sono conservati nello user space. 17

21 Capitolo 4 Testing 4.1 Procedura di installazione In questo capitolo vedremo prima come installare HIPL, con tutti i requisiti necessari e le varie dipendenze da risolvere. In seguito eettueremo dei test per vericarne le funzionalitá ed in particolare per analizzare il funzionamento del Rendez-vous Server Requisiti e dipendenze La prima cosa da fare é controllare se la versione di Linux utilizzata supporta BEET IPsec [10]. BEET IPsec puó essere installato secondo uno dei seguenti metodi: 1. Installare la versione del kernel o superiore poiché contiene giá il supporto a BEET. La versione corrente del kernel puó essere controllata con il comando uname -a. 2. Modicare il le /etc/init.d/hipl-rewall in modo che contenga l'opzione -i (HIPFW_OP=-bklpFi). In alternativa, dal terminale si puó eseguire il comando hipfw con le stesse opzioni. Ora per risolvere alcune dipendenze bisogna necessariamente digitare da terminale i seguenti comandi: sudo apt get i n s t a l l autoconf automake l i b t o o l make gcc l i b s s l dev sudo apt get i n s t a l l i p t a b l e s dev l i b n e t ip p e r l l i b n e t dns p e r l bzr 18

22 CAPITOLO 4 Tramite i seguenti comandi si acquisiscono altri requisiti e si risolvono altre dipendenze: sudo apt get i n s t a l l xmlto doxygen check l i b c o n f i g 8 dev miredo sudo apt get i n s t a l l f a k e r o o t dpkg dev sudo apt get i n s t a l l netcat6 debhelper d e v s c r i p t s Per quanto riguarda i requisiti di rete, bisogna vericare che il traco relativo ad HIP ed ESP non venga bloccato. Si puó controllare ció usando da terminale il comando iptables -L. Per permettere il passaggio del traco HIP attraverso il rewall bisogna aggiungere le seguenti regole (da terminale, in modalitá root): i p t a b l e s A INPUT p 139 j ACCEPT i p t a b l e s A OUTPUT p139 j ACCEPT i p t a b l e s A INPUT p udp s p o r t j ACCEPT i p t a b l e s A OUTPUT p udp dport j ACCEPT i p t a b l e s A INPUT p 50 j ACCEPT i p t a b l e s A OUTPUT p 50 j ACCEPT i p t a b l e s A INPUT p 58 j ACCEPT i p t a b l e s A OUTPUT p 58 j ACCEPT i p t a b l e s A INPUT s / 8 d / 8 j ACCEPT i p t a b l e s A OUTPUT s / 8 d / 8 j ACCEPT i p 6 t a b l e s A INPUT s : : : / 2 8 d : : : / 2 8 j ACCEPT i p 6 t a b l e s A OUTPUT s : : : / 2 8 d : : : / 2 8 j ACCEPT Installazione Ci sono due diverse modalitá di installazione: 1. Creare un nuovo le etc/apt/sources.list.d/hipl.list. Il le deve contenere la seguente stringa: deb DISTRONAME main e bisogna poi sostituire al valore DISTRONAME il nome della distribuzione in uso (in questo caso verrá usata precise). Basta poi digitare da terminale i seguenti comandi: 19

23 CAPITOLO 4 sudo apt g e t update sudo apt get i n s t a l l h i p l a l l 2. Si scarica dal sito il codice sorgente e si installa eseguendo da terminale: a u t o r e c o n f i n s t a l l. / c o n f i g u r e make make i n s t a l l Una volta completata la procedura avremo installato: HIP Daemon (HIPD) HIP Firewall Utility Daemon (HIPFW) DNS Proxy for HIP Ora possiamo eseguire l'hipd scrivendo da terminale sudo hipd. Figura 4.1: Comando hipconf daemon get hi default Come possiamo vedere nella Figura 4.1, con il comando hipconf daemon get hi default si leggono gli indirizzi HIT ed LSI assegnati durante l'esecuzione del demone. Inoltre si puó vericare che tutto sia andato a buon ne collegandosi all'indirizzo Il messaggio del sito in caso di connessione con HIP é mostrato in Figura

24 CAPITOLO 4 Figura 4.2: Rilevazione di una connessione con HIP Test di prova di un Base Exchange In questo paragrafo vedremo un semplice test in cui due host instaurano un Base Exchange. In Tabella 4.1 sono indicati gli indirizzi IPv4, IPv6 e HIT dei due host utilizzati. Nome Host IPv4 IPv6 HIT Initiator e::1 2001:0013:e87a:b8e4:68c8:258b:0fb4:68b8 Responder e::2 2001:0018:66b5:52d3:e479:7810:8446:133b Tabella 4.1: Indirizzi degli host Initiator e Responder Prima di instaurare la connessione tra i due host é necessario effettuare alcune operazioni. Le operazioni da eseguire da terminale al Responder sono le seguenti: 1. sudo ifcong NOME_INTERFACCIA inet6 add 3e::2/64 2. sudo hipd -b 3. nc6 -l -p 5000 Il primo comando aggiunge all'interfaccia usata dall'host un indirizzo di tipo 3e::xx/64, mentre l'ultimo comando permette all'host di attendere una connessione sulla porta scelta. Le operazioni da eseguire all'initiator sono le seguenti: 1. sudo ifcong NOME_INTERFACCIA inet6 add 3e::1/64 2. modicare il le /etc/hosts aggiungendo : 21