Dimostrazione di HIP nel SO Linux - Facoltà di Ingegneria · Introduzione Nel corso degli ultimi...

Facoltà di Ingegneria

Corso di Studi in Ingegneria Informatica

Elaborato finale in Protocolli per Reti Mobili

Dimostrazione di HIP nel SO Linux

Anno Accademico 2011/2012

Candidato:

RAFFAELE OLIVIERO

matr. N46000460

Indice

Introduzione 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1 Host Idendity Protocol 51.1 Funzionamento standard . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Host Identity Protocol for Linux 82.1 Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Endpoint Resolution . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 HIPL Application Programming Interface . . . . . . . . . . . 9

Legacy HIPL API . . . . . . . . . . . . . . . . . . . . . . . . . 10Native HIPL API . . . . . . . . . . . . . . . . . . . . . . . . . 10Endpoint Resolution nelle API natvie . . . . . . . . . . . . . . 11

2.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.1 Kernel Based Version . . . . . . . . . . . . . . . . . . . . . . . 11

HIP Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Hooks in the Linux Networking Stack . . . . . . . . . . . . . . 12Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14HIP Socket Handler . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2 User Space Version . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 Installazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.2 Primo Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.3 Secondo Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Conclusioni 27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

II

Introduzione

Nel corso degli ultimi venti anni, Internet ha subito una rapida e straordinariaevoluzione, diventando parte integrante della vita di milioni di persone. Eppure neltempo sono emersi alcune carenze nella tecnologia TCP/IP come:

• la gestione di terminali mobili e multi-homed;

• l’impossibilità di contrastare attacchi Denial-of-Service (DoS);

• l’impossibilità di garantire l’autenticità e confidenzialità dei messaggi;

• interoperabilità tra IPv4 e IPv6;

Nonostante molti di questi problemi siano ormai riconosciuti da tempo mancaancora un’adeguata e completa soluzione. Inoltre la maggior parte degli approccisono mirati alla risoluzione di un singolo problema escludendo di fatto le integrazionicon altre soluzioni e rendendo quindi impossible la costruzione di una base stabiledalla quale partire.

Host Identity Protocol (HIP) si propone come soluzione a tali problemi fornendoun approccio integrato che bene si adatta all’architettura TCP/IP esistente.

In questo elaborato di tesi, oltre a dare una breve panoramica sul protocolloHIP, si vogliono valutare le funzionalità di una particolare implementazione di HIPper sistemi Linux-based: HIP for Linux (HIPL) [1]. In particolare si articolerannodiverse fasi di test ognuna improntata su un particolare servizio fornito.

4

Capitolo 1

Host Idendity Protocol

1.1 Funzionamento standardL’idea di HIP viene introdotta nell’amito dell’ Internet Engineering Task Force(IETF) già nel 1999 ma la creazione di un Working Group e di un Research Groupavvengono solo nel 2004. Infine viene standardizzato nella RFC 4423 del 2006 [2].

Pur riconoscendo l’importanza dei due namespaces fondamentalii di Internet,l’Internet Protocol (IP) addres e il Domain Name Service (DNS), nel documento sisottolinea la necessità di colmare il gap che separa i due namespaces introducendoneuno nuvo: l’Host Identifiers (HIs). L’idea fondamentale su cui si basa HIP è infattiquella di separare l’identità di un host dalla sua posizione topologica nella rete. Ognihost può avere una o più HI a partire dalla quale, a valle di un processo crittograficosi perviene alla creazione di una coppia di chiavi: una pubblica ed una privata.

Figura 1.1: Infrastruttura HIP

In particolare la chiave pubblicaprende il nome di Host Identity Tag(HIT) anche se, al fine di mantenerela compatibilità con socket basate suIPv4, esiste anche un’altra rappresenta-zione dell’HI: Local Scope Identity (LSI).Ovviamente anche se rappresentano unnodo questi indirizzi non possono essereusati per raggiungere un host. PertantoHIP prevede di interporre tra il livellorete e quello trasporto un nuovo sotto-livello capace di effettuare la traduzioneda HIT/LSI a indirizzo IP.

Per garantire la sicurezza nelle tra-smissioni, di default tutti i pacchetti in HIP vengono trasportati utilizzando IPsecEncapsulated Security Payload (ESP). I pacchetti vengono smistati utilizzando il Se-curity Parameter Index (SPI) che identifica univocamente una Security Association(SA) instaurata tra due hosts utilizzando i rispettivi HIT. Questo fornisce non soloun grande supporto alla mobilità ma non rende necessario la trasmissione dell’HITnel pacchetto, riducendone la grandezza.

Per stabilire una SA i due host utilizzano HIP Base Exchange. In questa fasevengono scambiati quattro messaggi tra l’host che manda il primo pacchetto (Initia-

5

Facoltà di Ingegneria - Corso di Studi in Ingegneria Informatica Dimostrazione di HIP nel SO Linux

tor) e quello che lo riceve (Responder). Tale procedura è stata progettata in mododa poter contrastare attacchi DoS, utilizzando un puzzle crittografato che l’Initiatordeve risolvere prima che il Responder crei una connessione, e replay attack, auten-ticando le due entità coinvolte mediante l’uso di una chiave condivisa attraverso ilprotocollo Diffie-Helman.

Figura 1.2: HIP Base Exchange

Il supporto di HIP alla mobilità ed al multihoming viene descritto nella RFC 5206del 2008 [3]. Tale documento affronta solo gli scenari fondamentali della mobilità edel moultihoming, mentre i casi più avanzati sono stati lasciati ad uno studio futuro.Quando un nodo mobile si sposta in una nuova rete o sottorete mantiene il proprioHI ma cambia l’indirizzo IP. Questo significa che, poiché a livello TCP le entitàvedono gli HIT, le connessioni restano attive anche se poi effettivamente l’IP cambia.

Figura 1.3: Update singnaling

Ovviamente quando l’indirizzo IP cam-bia il nodo mobile deve notificarlo alcorrispondente, mediante un messaggiodi UPDATE, affinchè quest’ultimo pos-sa aggiornare la corrispondenza tra HITe nuovo indirizzo IP.

Ma se un host non conosce l’indiriz-zo IP attuale del nodo mobile non puòinstaurare alcuna connessione HIP conlo stesso. Tale problema viene risoltodal Randezvous server (RVS) [4] il cuiindirizzo IP è fisso o comunque otteni-bile con una semplice query DNS e checonosce sempre l’indirizzo IP aggiornatodel nodo mobile perchè quest’ultimo usaun protocollo di registrazione ogni qual

volta cambia IP per informare il RVS.

6


L’uso di HIP non elimina la necessità dell’utilizzo del DNS. In una prima imple-mentazione si era pensato di salvare gli HITs nei record AAAA solitamente desti-nati agli indirizzi IPv6. Successivamente, per supportare tutti gli altri parametri diHIP, nei server DNS fù introdotto un campo specifico per HIP: Resources Records(RR). Le estensioni del DNS sono descritte nella RFC 5205 del 2008 [5]. Infine, permantenere al compatibilità con le applicazioni legacy, si utilizza un DNS proxy cheintercetta le richieste di risoluzione ed elabora i risultati inviando all’applicazionesolo i risultati di cui ha effettivamente bisogno.

7

Capitolo 2

Host Identity Protocol for Linux

2.1 ImplementazioneHIP for Linux (HIPL) è un progetto software del Helsinki Institute of InformationTechnology (HIIT) e Helsinki University of Technology (TKK) nato con lo scopodi creare un implementazione di HIP per GNU/Linux OS. Fondamentalmente è unprogetto di ricerca ma rappresenta un’ottima referenza nel caso in cui, un giorno, sivorrà integrare HIP nel kernel ufficiale di Linux. Il progetto si divide in due ramifondamentali:

• Kernel Based Vesion, che può essere sia compilata staticamente nel kernel outilizzata come modulo e si occupa di intercettare e, se necessario, modificareil traffico IPv6 in entrata e in uscita.

• User Space Vesion, un demone che fornisce un supporto crittografico al ker-nel implementando funzioni fondamentali come la creazione di chiavi Diffie-Hellman e Digital Signature Algorithm (DSA). Dal momento che tali opera-zioni richiedono una grande quantità di tempo per essere completate e vistoche il kernel è non-preemptive, devono essere effettuate in user mode;

2.1.1 Endpoint ResolutionLe applicazioni di rete comunemente utilizzano il Fully Qualified Domain Name(FQDN) per stabilire una connessione tra due host. L’interfaccia che fornisce larisoluzione del nome viene comunemente conosciuta come resolver, nella quale è in-cluso un set di funzioni usate dalle applicazioni per effettuare la traduzione Indirizzodi rete/nome host e viceversa.

In HIPL la risoluzione dei nomi avviene come mostrato in Figura 3.1: l’applica-zione invoca una funzione del resolver passandogli come argomento il nome dell’host.Questo effettua una query DNS la cui risposta sarà la coppia HIT/indirizzo IPv6.Tale coppia viene successivamente inoltrata al modulo HIPL la cui risposta sarà unEndpoint Descriptor (ED) nel caso in cui viene utilizzata una API nativa di HIP oun HIT nel caso in cui viene utilizzata una API legacy.

8


Figura 2.1: Endpoint Resolution

2.1.2 HIPL Application Programming InterfaceLe APIs costituiscono un utile supporto per le applicazioni in quanto forniscono lefondamentali funzionalità di rete quali, ad esempio, la risoluzione dell’identità. Dalpunto di vista del protocollo HIPL esistono due tipi diversi di applicazioni: quelleHIP-aware e quelle legacy. Uno degli obiettivi più importanti in fase di progetazzionedelle API è stato quello di garantire l’uso di HIP anche alle applicazioni legacysenza che queste fossero suscettibili a cambiamenti del codice per usufruire dellefunzionalità offerte dal protocollo.

Figura 2.2: HIPL Layering Model

9


Legacy HIPL API

Nei sistemi operativi basati su UNIX si utilizza una libreria standard chiamata libcche fornisce i metodi per le operazioni più comuni come l’interfaccia del resolver. InHIPL si utilizza un’altra implementazione delle API, chiamata libnet6, basata sulprogetto USAGI [6]. In particolare le API legacy si riferiscono prorpio alle funzioniche si trovano in tale libreria garatendo un utilizzo semplice e trasparente del procolloHIPL a qualsiasi applicazione. A tale scopo, come descritto da Candolin in una suapubblicazione [7], nella pratica è stata modificata solo la funzione gettaddrinfo. LeAPI legacy possono essere abilitate utilizzando due diversi tipi di approcci:

• Transparent HIP mode, un’opzione che può essere abilitata a tempo di compila-zione e che fa restituire alla getaddrinfo sempre l’HIT prima dell’indirizzo IPv6.Con il suo utilizzo non sono necessari cambiamenti al codice dell’applicazione;

• utilizzo esplicito, che avviene quando si setta il flag AI_HIP nella getaddrin-fo che restituisce solo gli HITs. Con il suo utilizzo sono necessari piccolicambiamenti al codice dell’applicazione.

Native HIPL API

Le applicazioni HIP-aware utilizzano le API native di HIP come proposto in unabozza dell’IETF del 2005 [8]. Queste costituiscono una parte importante dell’im-plementazione di HIPL e per utilizzarle, un’applicazione deve passare alla funzionedella socket una particolare costante: PF_HIP.

L’ED rappresenta uno dei concetti fondamentali su cui si basa l’implementazionedelle API native. Esso costituisce un collegamento all’HI: in particolare non è cheun semplice puntatore alla corrispondente entry nel HI database di un host. La suainterfaccia è rappresentata dalla struct

struct sockaddr_ed{unsigned short int ed_family;in_port_t ed_port;sa_ed_t ed_val;

}

dove

• la variabile ed_family è sempre settata utilizzando la costante PF_HIP perindicare l’utilizzo di un’API nativa;

• la variabile ed_port rappresenta un numero di porto utile a livello trasporto;

• la variabile ed_val è un identificatore univoco di un ED e viene mantenuta dalmodulo HIPL e utilizzata nel kernel;

10


Endpoint Resolution nelle API natvie

Per effettuare l’operazione di risoluzione degli host names in struct ED le applicazioniutilizzano una particolare funzione delle API native

int getendpointinfo(const char *nodename ,const char *servname ,const struct endpointinfo *hints ,struct endpointinfo **res);

Il risultato della funzione viene posizionato nella variabile res che rappresentaun puntatore ad una lista linkata allocata dinamicamente; in particolare sarà zero incaso di successo o un valore diverso da zero per indicare una particolare condizioned’errore.

Come si può notare viene introdotta una nuova struct

struct endpointinfo{int ei_flags;int ei_family;int ei_socktype;int ei_protocol;size_t ei_endpoint_len;struct socaddr *ei_endpoint;char *ei_canonname;struct endopointinfo *ei_next;

}

la quale viene utilizzata sia come input che come output nella funzione stessa eche contiene un campo ei_endpoint che punta ad un struct utilizzata nelle chiamatealle API native.

2.2 ArchitetturaIn questa sezione verrà descritta l’architettura delle due implementazioni di HIPLa cui si faceva riferimento nel precedente paragrafo anche se l’attenzione sarà mag-giormente focalizzata sull’implementazione kernel based dal momento che questarappresenta la versione principale pensata in fase di progettazione.

2.2.1 Kernel Based VersionL’architettura generica di questa versione di HIPL viene proposta nella Figura 2.3:le applicazioni utilizzano il protocollo utilizzando la libreria libnet6 ; il resolver comu-nica direttamente con l’HIPL Kernel Module e le chiamate alle API native vengonoinoltrate nel modulo kernel dall’HIP socket handler; le applicazioni legacy, invece,utilizzano le classiche API IPv6 ma vengono utilizzati gli HITs in luogo degli indirizziIPv6.

11


Figura 2.3: HIPL Kernel Based version Architecture

HIP Module

Il modulo kernel rappresenta il cuore dell’implementazione di HIP; ad esempio gesti-sce il base exchange, mantiene le associazioni HIP e implementa alcune funzionalitàfondamentali per la gestione della mobilità quali i messaggi di UPDATE.

Sicuramente la parte più importante del modulo kernel è il KHIPD Kernel Th-read, che rimane in attesa fino a quando non rivece nuovi compiti da eseguire comead esempio l’elaborazione di tutti i pacchetti HIP provenienti dalla rete. Ovvia-mente la comunicazione tra User Space e Kernel Space avviente mediante l’uso diparticolari socket HIP e grazie all’aiuto del HIP Socket Handler. Le informazioniscambiate dai due livelli contengono lo stesso tipo di dati che sono inclusi in un co-mune pacchetto HIP, per cui viene sfruttato lo stesso formato dei messaggi utilizzatoin tale protocollo.

Hooks in the Linux Networking Stack

L’implementazione di HIPL utilizza delle particolari funzioni, Hooks, per deviare ilnormale percorso dei pacchtti di rete nello stack IPv6 e passarne il controllo all’HIPLKernel Module quando è necesarrio. Tali funzioni agiscono sia in input che in output

Output hooks Input hooks Other hooks

hip_get_addr() hip_handle_esp() hip_handle_ipv6_dad_completed()hip_get_saddr() hip_handle_inet6_addr_del()hip_handle_output()hip_get_default_spi_out()

Tabella 2.1: HIPL Hooks nell’ IPv6 Networking Stack

12


In particolare le funzioni hip_get_addr ed hip_handle_output sono utilizzateper convertire gli HITs sorgente e destinazioni in un indirizzo IPv6; hip_get_saddrdetermina l’HIT di provenienza per un pacchetto che presenta un HIT come inidirizzodi destinazione; hip_get_default_spi_out trova il valore SPI da utilizzare in unpacchetto ESP in uscita; infine hip_handle_esp sostituisce l’indirizzo IPv6 con unHIT nei pacchetti in entrata prima che essi siano inoltrati al modulo IPsec.

Figura 2.4: HIPL Hooks nel Linux Networking Stack

Database

Oltre al Local Host Identity Database (HI DB) e al Peer Host Identity Database (HIDB), le cui funzioni sono facilmente intuibili, sono presenti altri due database.

L’Host Association Database (HABD) è una struttura dati globale presente nel-l’HIPL Kernel Module. Viene usato per conservare particolari informazioni come leassociazioni HIP: esso contiene infatti le Host Association (HA). Una HA includegli HIT’s di entrambe le entità, gli indirizzi IPv6 dei peer, il valore SPI utilizzato daESP, informazioni circa lo stato di HIP e le chiavi segrete condivise.

In particolare l’HADB è una hash table e gli HIT’s dei peer vengono utilizzaticome chiave primaria. Inoltre sono presenti altre due hash tables che vengono uti-lizzate per mappare le coppie SPI/HITs e per cercare una HA a partire dall’SPI.

L’Endpoint Descriptor Database (ED DB) è invece utilizzato dall’HIP SocketHandler per salvare gli Endpoint Descriptors. Ogni entry del Database contiene unastruct sockaddr_ed, l’HIT corrispondente e alcuni dati che identificano il processoche ha creato tale entry.

13


Resolver

Il Resolver è una componente dell’User Space che si occupa dell’HIP EndopointResolution per le applicazioni ed inoltre fornisce il mapping tra HIs, gli HITs e gliindirizzi IP al HIPL Kernel Module.

Il file di configurazione /etc/hip/hosts contiene il mapping tra il nome dell’host eil rispettivo HIT. Le applicazioni legacy convertono il nome dell’host in una strutturasockaddr_in6 utilizzando la funzione modificata gettaddrinfo mentre la applicazioniHIP-aware utilizzano la funzione del resolver gettendpointinfo il cui risultato sarà lastruct sockaddr_ed.

Gli HITs sono mappati agli indirizzi IPv6 nei due file di configurazione /etc/hostsed /usr/local/etc/hip/hosts. Le varie coppie vengono comunicate al kernel comeeffetto della chiamata al resolver, e per questo motivo risulterebbe un problema perl’implementazione uno scenario in cui si tenta di stabilire una connessione senzal’utilizzo del resolver.

HIP Socket Handler

Le chiamate alle API vengono intercettate dall’HIP Socket Handler se queste fannoparte della famiglia PF_HIP, ovvero quando ci troviamo in presenza di un’appli-cazione HIP-aware. L’Handler supporta gli ED in modo che questi possano esseredirettamente utilizzati nelle chiamate alle API. Esso inoltre assume la funzione diun wrapper per le API IPv6: il suo compito principale è infatti quello di convertiregli EDs nei rispettivi HITs ed inoltrare le chiamate delle API native nel Linux Ipv6Module. Nel caso in cui venga utilizzata una API legacy l’Handler non interviene: inquesto caso l’HIT viene trattato come un indirizzo IPv6. Per questo motivo l’utilizzolegacy di HIPL non introduce alcun cambiamento nelle API IPv6.

2.2.2 User Space VersionIn questo paragrafo verrano brevemente discusse le principali differenze tra l’imple-mentazione kernel based e quella user space.

Come è possibile notare dalla Figura 2.4, oltre al KHIPD Kernel Thread, vieneintrodotto l’HIPL User Space Daemon che si occupa della gestione di molte dellefunzione di HIP, ragion per cui il modulo kernel si occupa essenzialmente dell’inoltrodei messaggi. Molti dati infatti viaggiano tra i due livelli: ad esempio quando vieneaggiunto una nuova HI viene prima inviato un messaggio dall’user space al kernelmodule e successivamente tale messaggio viene inoltrato all’HIPL daemon.

14


Figura 2.5: HIPL User Space version Architecture

Vengono apportate delle modifiche anche alla struttura dei dati nel kernel

• L’HADB viene spostato nell’ user space ed inoltre una entry ora contiene anchel’HI locale specifica dell’associazione e dei puntatori che indicano le funzioniche possono essere utilizzate in un’associazione HIP;

• Bound End-to-End Tunnel mode Database (BEETDB) utilizzato nel modulokernel per abilitare l’integrazione HIP-IPsec.

Nella versione Kernel Based tutte le funzioni venivano implementate nel kernel.Ora invece sono implementate nell’user space utilizzando la libreria OpenSSL [9]ragion per cui gli HI sono salvati nell’user space.

2.3 TestingIn questa fase si cercherà di attuare quello che è il fine ultimo di questo elaboratofornendo un riscontro pratico al preambolo teorico descritto nei precedenti paragrafi.In particolare si effettueranno due tipi di test:

• Il primo dimostra che una connessione su HIP resta attiva anche quando unhost cambia indirizzo IP. In particolare si stabilisce una connessione SSH trai due host e si verifica che pur cambiando l’indirizzo IP su uno di questi laconnessione resta attiva;

• Il secondo dimostra il funzionamento dell’RVS. Si utilizzano tre hosts in localeche agiranno rispettivamente da Rendezvous Server, Initiator e Responder;

Talvolta si utilizzerà Wireshark per poter analizzare nel dettaglio le connessioniutilizzando il log dei pacchetti scambiati. Tutti gli host utilizzati montano Ubuntu11.10 (Oneiric Ocelot).

15


2.3.1 InstallazioneIl bundle HIPL è formato dai seguenti componenti

• HIP Daemon (HIPD), le cui funzioni sono già state spiegate nei precedentiparagrafi;

• HIP Firewall Utility Daemon (HIPFW), che implementa il filtraggio dei pac-chetti HIP e fornisce il supporto ad IPsec anche agli hosts legacy che hannoun kernel inferiore alla versione 2.6.27;

• DNS Proxy for HIP, che effettua la risoluzione da DNS a HITs per le applica-zioni;

É importante precisare bisogna utilizzare un sistema Linux che supporti la mo-dalità BEET IPsec. I kernel a partire dalla versione 2.6.27 implementano di defaulttale funzionalità, mentre nel caso se ne utilizzi uno più vecchio è possibile comun-que utilizzare una patch reperibile dal sito dello sviluppatore. Inoltre è necessariorisolvere alcune dipendenze: per farlo è possibile utilizzare i comandi

sudo apt -get install autoconf automake libtool make gcc \libssl -dev iptables -dev libnet -ip-perl \libnet -dns -perl bzr

sudo apt -get install xmlto doxygen check libconfig8 -dev miredosudo apt -get install fakeroot dpkg -dev debhelper devscripts

Per installare HIPL bisogna creare un nuovo file etc/apt/sources.list.d/hipl.listcon il seguente contenuto

deb http :// packages.infrahip.net/ubuntu DISTRO_NAME main

e digitare da terminale

sudo apt -get updatesudo apt -get install hipl -all

In alternativa si può scaricare il codice sogernte ed effettuare l’installazione uti-lizzando i classici comandi make e make install. Nel caso in cui ci fossero probelmicon la compilazione è possibile digitare il comando

CFLAGS=-Wno -error ./ configure

e rieseguire la compilazione. Una volta completata l’installazione è possibileeseguire il demone HIP digitando da terminale

sudo hipd -b

Tale lancio comporta la creazione di due interfacce virtuali e l’assegnazione diun HIT e un LSI come mostrano le immagini seguenti.

16


Figura 2.6: Run ifconfig

Figura 2.7: Run hipconf daemon get hi default

17


2.3.2 Primo TestIn questo test vengono utilizzati due hosts le cui informazioni sono riportate nellaTabella 2.2

Initiator Responder

HIT 2001001e5cdc93eef8a3213a484745da 20010016b814aabd52e7b4f100904ffaLSI 10.0.0.1 10.0.0.1Indirizzo IPv4 10.0.0.11 10.0.0.12

Tabella 2.2: Hosts Informations

Prima di procedere alla creazione di una connesione tra i due peer è necessaria unafase preliminare di configurazione sull’Initiator. In particolare si vanno a modificarei file /etc/hosts ed /usr/local/etc/hosts come segue

• nel primo si specifica la coppia [RESPONDER_HIT]/[RESPONDER_NAME] ;

• nel secondo si specifica la coppia [RESPONDER_IP]/[RESPONDER_NAME] ;

dove il [RESPONDER_IP] può essere sia un indirizzo IPv4 che IPv6. Fattoquesto il mapping tra HIT e indirizzo IP avviene automanticamente ma è anchepossibile una configurazione manuale digitando da shell il comandohipconf daemon add map PEER_HIT PEER_IP

A questo punto si instaura la connessione tra i due hosts digitando dall’Inititoril comando ssh responder. Come è possibile vedere dall’analisi dei pacchetti conWireshark (Figura 2.8) inizia l’HIP Base Exchange tra i due hosts

Figura 2.8: HIP Base Exchange

18


Il primo pacchetto I1 è di dimensione fissa poichè contiene solo l’header senzaalcun parametro"No. Time Source Destination Protocol Length Info3 0.000303 10.0.0.11 10.0.0.12 HIP 86 HIP I1

(HIP Initiator Packet)Frame 3: 86 bytes on wire (688 bits),

86 bytes captured (688 bits)Ethernet II, Src: AsustekC_33:c6:89 (00:1f:c6:33:c6:89),

Dst: dc:0e:a1:5b:8b:88 (dc:0e:a1:5b:8b:88)Internet Protocol Version 4, Src: 10.0.0.11 (10.0.0.11) ,

Dst: 10.0.0.12 (10.0.0.12)User Datagram Protocol , Src Port: hip -nat -t (10500) ,

Dst Port: hip -nat -t (10500)Host Identity ProtocolPayload Protocol: 59Header Length: 4Fixed P-bit: 0 (Always zero)Packet Type: 1Version: 1, Reserved: 0Fixed S-bit: 1 (HIP)Checksum: 0x0000 (correct)HIP Controls: 0x0000.... .... ....0 = Anonymous (Sender ’s HI is anonymous ): FalseSender ’s HIT: 2001001 e5cdc93eef8a3213a484745daReceiver ’s HIT: 20010016 b814aabd52e7b4f100904ffa"

Il Responder replica inviando il pacchetto R1 nel quale si possono notare diversiparametri quali il Cryptographic Puzzle, Diffie-Hellman, HOST_ID ed HOST_SIG"No. Time Source Destination Protocol Length Info4 0.001115 10.0.0.12 10.0.0.11 HIP 694 HIP R1

(HIP Responder Packet)Frame 4: 694 bytes on wire (5552 bits),

694 bytes captured (5552 bits)Ethernet II, Src: dc:0e:a1:5b:8b:88 (dc:0e:a1:5b:8b:88),

Dst: AsustekC_33:c6:89 (00:1f:c6:33:c6:89)Internet Protocol Version 4, Src: 10.0.0.12 (10.0.0.12) ,


Dst Port: hip -nat -t (10500)Host Identity ProtocolPayload Protocol: 59Header Length: 80Fixed P-bit: 0 (Always zero)Packet Type: 2Version: 1, Reserved: 0Fixed S-bit: 1 (HIP)Checksum: 0x0000 (correct)HIP Controls: 0x0000

19


Sender ’s HIT: 20010016 b814aabd52e7b4f100904ffaReceiver ’s HIT: 2001001 e5cdc93eef8a3213a484745daHIP ParametersPUZZLE (type =257, length =12)DIFFIE_HELLMAN (type =513, length =246)HIP_TRANSFORM (type =577, length =6)HOST_ID (type =705, length =159)ESP_TRANSFORM (type =4095, length =8)HIP_SIGNATURE_2 (type =61633 , length =129)"

Il terzo messaggio I2 contiene i parametri: Solution, contenente la soluzioneal puzzle; Diffie-Hellman, contenente la chiave pubblica dell’Initiator; Host_ID,contenente la chiave pubblica parte dell’HI dell’Initiator; HIP_SIG, contenente lasignature del messaggio calcolata usando la chiave privata dell’Initiator; ESP_INFO,contenente l’SPI usato dall’Initiator per la SA che si sta stabilendo.

"Ethernet II , Src: AsustekC_33:c6:89 (00:1f:c6:33:c6:89),Dst: dc:0e:a1:5b:8b:88 (dc:0e:a1:5b:8b:88)

Internet Protocol Version 4, Src: 10.0.0.11 (10.0.0.11) ,Dst: 10.0.0.12 (10.0.0.12)

User Datagram Protocol , Src Port: hip -nat -t (10500) ,Dst Port: hip -nat -t (10500)

Host Identity ProtocolPayload Protocol: 59Header Length: 76Fixed P-bit: 0 (Always zero)Packet Type: 3Version: 1, Reserved: 0Fixed S-bit: 1 (HIP)Checksum: 0x0000 (correct)HIP Controls: 0x0000Sender ’s HIT: 2001001 e5cdc93eef8a3213a484745daReceiver ’s HIT: 20010016 b814aabd52e7b4f100904ffaHIP ParametersESP_INFO (type=65, length =12)SOLUTION (type =321, length =20)DIFFIE_HELLMAN (type =513, length =195)HIP_TRANSFORM (type =577, length =2)HOST_ID (type =705, length =149)ESP_TRANSFORM (type =4095, length =4)HMAC (type =61505 , length =20)HIP_SIGNATURE (type =61697 , length =129)"

L’ultimo messaggio R2, se la soluzione è corretta, conferma l’associazione all’I-nitiator. Questo messaggio contiene i parametri ESP_INFO (SPI che si aspetta diricevere nei prossimi messaggi il Responder) e HIP_SIG.

"No. Time Source Destination Protocol Length Info6 0.077108 10.0.0.12 10.0.0.11 HIP 262 HIP R2

20


(Second HIP Responder Packet)Frame 6: 262 bytes on wire (2096 bits),




Dst Port: hip -nat -t (10500)Host Identity ProtocolPayload Protocol: 59Header Length: 26Fixed P-bit: 0 (Always zero)Packet Type: 4Version: 1, Reserved: 0Fixed S-bit: 1 (HIP)Checksum: 0x0000 (correct)HIP Controls: 0x0000Sender ’s HIT: 20010016 b814aabd52e7b4f100904ffaReceiver ’s HIT: 2001001 e5cdc93eef8a3213a484745daHIP ParametersESP_INFO (type=65, length =12)HMAC_2 (type =61569 , length =20)HIP_SIGNATURE (type =61697 , length =129)"

A questo punto si attiva l’interfaccia wireless del Responder in modo da cambiareindirizzo IP. Come si può notare dall’analisi dei pacchetti (Figura 2.9) il nuovoindirizzo viene segnalato all’Initiator ma ancora tramite ethernet.

Figura 2.9: Update Messages

21


Solo successivamente avviene il vero e proprio scambio dei tre messaggi di UP-DATE. In particolare nel primo messaggio si può notare la presenza del parametroESP_Info, che può essere utilizzato per cambiare chiave, e il parametro SEQ perrichiedere un riscontro da parte del corrispondente

"No. Time Source Destination Protocol Length Info92 27.928260 10.0.0.11 10.0.0.10 HIP 286 HIP UPDATE

(HIP Update Packet)Frame 92: 286 bytes on wire (2288 bits),

286 bytes captured (2288 bits)Ethernet II, Src: AsustekC_33:c6:89 (00:1f:c6:33:c6:89),

Dst: dc:0e:a1:5b:8b:88 (dc:0e:a1:5b:8b:88)Internet Protocol Version 4, Src: 10.0.0.11 (10.0.0.11) ,


Dst Port: hip -nat -t (10500)Host Identity ProtocolPayload Protocol: 59Header Length: 29Fixed P-bit: 0 (Always zero)Packet Type: 16Version: 1, Reserved: 0Fixed S-bit: 1 (HIP)Checksum: 0x0000 (correct)HIP Controls: 0x0000Sender ’s HIT: 2001001 e5cdc93eef8a3213a484745daReceiver ’s HIT: 20010016 b814aabd52e7b4f100904ffaHIP ParametersESP_INFO (type=65, length =12)SEQ (type =385, length =4)ACK (type =449, length =4)ECHO_REQUEST_SIGNED (type =897, length =4)HMAC (type =61505 , length =20)HIP_SIGNATURE (type =61697 , length =129)"

Il secondo messaggio invece serve a verificare che il nodo mobile sia effettivamen-te disponibile al nuovo indirizzo. Inoltre si può notare la presenza del parametroECHO_RESPONSE_SIGNED utilizzato come contromisura per i replay attack.

"No. Time Source Destination Protocol Length Info93 27.934329 10.0.0.12 10.0.0.11 HIP 262 HIP UPDATE





22


Dst Port: hip -nat -t (10500)Host Identity ProtocolPayload Protocol: 59Header Length: 26Fixed P-bit: 0 (Always zero)Packet Type: 16Version: 1, Reserved: 0Fixed S-bit: 1 (HIP)Checksum: 0x0000 (correct)HIP Controls: 0x0000Sender ’s HIT: 20010016 b814aabd52e7b4f100904ffaReceiver ’s HIT: 2001001 e5cdc93eef8a3213a484745daHIP ParametersACK (type =449, length =4)ECHO_RESPONSE_SIGNED (type =961, length =4)HMAC (type =61505 , length =20)HIP_SIGNATURE (type =61697 , length =129)"

Il terzo messaggio di riposta, infine, serve a confermare la propria identità ri-copiando i dati presenti nel parametro ECHO_RESPONSE_SIGNED e inoltrarlinuovamente al mittente."No. Time Source Destination Protocol Length Info94 27.942522 10.0.0.10 10.0.0.11 HIP 262 HIP UPDATE





Dst Port: hip -nat -t (10500)Host Identity ProtocolPayload Protocol: 59Header Length: 26Fixed P-bit: 0 (Always zero)Packet Type: 16Version: 1, Reserved: 0Fixed S-bit: 1 (HIP)Checksum: 0x0000 (correct)HIP Controls: 0x0000Sender ’s HIT: 20010016 b814aabd52e7b4f100904ffaReceiver ’s HIT: 2001001 e5cdc93eef8a3213a484745daHIP ParametersACK (type =449, length =4)ECHO_RESPONSE_SIGNED (type =961, length =4)HMAC (type =61505 , length =20)HIP_SIGNATURE (type =61697 , length =129)"

23


Al termine dello scambio la connessione riprende regolarmente da dove si erainterrotta, questa volta però utilizzando il nuovo indirizzo IP.

2.3.3 Secondo TestUna delle funzionalità più importanti che HIPL fornisce è quella del RendezvousServer (RVS). In questo test ai due hosts precedenti se ne affianca un altro le cuiinformazioni sono riportate nella Tabella 2.3

RV S

HIT 2001 : 1e : 2fc : 30c9 : c153 : 74a9 : 5f23 : 52c4LSI 10.0.0.1Indirizzo IPv4 10.0.0.8

Tabella 2.3: RVS Informations

Anche qui abbiamo bisogno di una fase preliminare di configurazione che stavoltainclude anche il RVS. In particolare bisogna andare a modificare il file /etc/hip/re-lay.conf nel quale troviamo le seguenti opzioni

whitelist_enabled = "yes"whitelist = ""minimum_lifetime = "60"maximum_lifetime = "3600"

HIPL infatti supporta, dal lato server, un servizio di white listing. Questo si-gnifica che solo quei client il cui HIT è inserito nella lista sono abilitati a registrarsial RVS. In alternativa tale servizio può essere disabilitato andando a modificare ilcampo whitelist_enabled. Inoltre è possibile configurare a proprio piacimento i valorilimite per la sessione di registrazione. É importante precisare che tali valori vengonoutilizzati per calcolare il vero lifetime e per questo non lo rappresentano in quantotale. La formula utilizzata, come specificato nella RFC 5203 [10], è la seguente

seconds = 2lifetime−64

8 (2.1)

da cui si ha

lifetime = 8log(seconds)

log(2)+ 64 (2.2)

Il Rendezvous Server è per alcuni aspetti simile all’Home Agent in Mobile IP.Esso infatti inoltra il primo messaggio del Base Exchange al nodo mobile ma i suc-cessivi pacchetti vengono scambiati direttamente tra le due entità coinvolte (Figura2.10)

24


Figura 2.10: Base exchange via RVS

A questo punto si può passare alla configurazione dell’Initiator modificando i file/etc/hosts ed /usr/local/etc/hosts come segue

• nel primo si specifica la coppia [RVS_IP]/[RESPONDER_NAME] ;

• nel secondo si specifica la coppia [RESPONDER_HIT]/[RESPONDER_NAME] ;

Rispetto al caso precedente si può notare che il Responder viene mappato conl’indirizzo IP del RVS mentre il secondo file rimane invariato. Gli stessi file invecenon devono essere modificati sul RVS e sul Responder: questo perchè si assume cheil RVS non abbia alcuna informazione sui suoi clients prima che questi lo contattinoe che il Reponder conosca già l’indirizzo IP e l’HIT del RVS. Fatto ciò si può eseguireil test vero e prorpio. Supposto che il demone HIP sia attivo su ogni host bisognaabilitare il servizio di randezvous sul RVS utilizzando il comandohipconf daemon add service rvs

25


Figura 2.11: Run hipconf daemon add service rvs

e successivamente registrare il Responder digitando

hipconf daemon add server rvs [RVS_HIT] <RVS_IP or hostname > \<LIFETIME_IN_SECONDS >

Figura 2.12: Run hipconf daemon add server rvs ...

Questo farà partire un base exchange tra i due host tra i quali si stabilirà una SA.Ora è possibile contattare il Responder tramite l’Initator ad esempio stabilendo unaconnessione SSH oppure una sessione Netcat. In ogni caso il Base Exchange avveràcome descritto in precedenza. Tutti i comandi disponibili per gestire il serviziorendezvous sono disponibili digitando hipconf

26

Conclusioni

Host Identity Protcol costituisce senza alcun dubbio un nuovo promettente approccioper facilitare la risoluzione di problemi quali la mobilità e multihoming. Tuttavia lespecifiche di HIP non sono state tutte sviluppate in maniera stabile e questo richiedeancora un lungo periodo di attività di ricerca, ma una delle migliori implementazionidisponibili rimane senza dubbio HIPL.

Le strutture interne di tale implementazione sono state modificate in modo dasupportare diversi identifiers contemporaneamente, la cui risoluzione viene fornitamodificando la libreria del resolver. In particolare tali identifiers possono esseresia forniti dal sistema che specificati dalle applicazioni, ed è stato implementato unmeccanismo di accesso, in particolar modo per gli ultimi, introducendo gli ED.

Ad ogni modo tale implementazione propone degli spunti interessanti su possibi-li idee di sviluppo future quali, ad esempio, la modifica della gestione dei messaggiinterni o della sintassi delle HIP API, per sopperire alla mancanza di alcune fun-zionalità. Una naturale evoluzione di HIPL potrebbe essere quella di sfruttare lefunzionalità offerte in software reali o anche in sistemi operativi. Uno di questi,abbastanza noto nel panorama open-source, potrebbe essere un buon canditato.

27

Bibliografia

[1] InfraHip Project - HIP for Linux. http://infrahip.hiit.fi

[2] IETF - Host Identity Protocol (HIP) Architecture - RFC 4423.http://www.ietf.org/rfc/rfc4423

[3] IETF - End-Host Mobility and Multihoming with the Host IdentityProtocol - RCF 5206. http://tools.ietf.org/html/rfc5206

[4] IETF - Host Identity Protocol (HIP) Rendezvous Extension - RFC5204. http://tools.ietf.org/html/rfc5204

[5] IETF - Host Identity Protocol (HIP) Domain Name System (DNS)Extension - RCF 5205. http://tools.ietf.org/html/rfc5205

[6] USAGI Project - Linux IPv6 Development Project. http://www.linux-ipv6.org

[7] Catharina Candolin - An Implementation of HIP for Linux

[8] IETF -Native Application Programming Interfaces for the Host Iden-tity Protocol - Internet Draft. http://tools.ietf.org/html/draft-mkomu-hip-native-api-00

[9] OpenSSL Project - Cryptography and SSL/TLS Toolkit.http://www.openssl.org

[10] IETF - Host Identity Protocol (HIP) Registration Extension - RFC5203. http://tools.ietf.org/html/rfc5203

28

Dimostrazione di HIP nel SO Linux - Facoltà di Ingegneria · Introduzione Nel corso degli ultimi...

Documents

Transcript of Dimostrazione di HIP nel SO Linux - Facoltà di Ingegneria · Introduzione Nel corso degli ultimi...