Flow Binding Support for Mobile IPv4

Transcript

1 UNIVERSITA DEGLI STUDI DI NAPOLI FEDERICO II FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA ELABORATO FINALE Flow Binding Support for Mobile IPv4 Candidato: Panariello Ciro N ANNO ACCADEMICO 2012/2013 1

2 INDICE Introduzione...3 Capitolo I - Agent Discovery....7 Capitolo II - Registrazione..9 Capitolo III - Tecniche per intercettare i pacchetti.12 Capitolo IV - Flow Binding Support for Mobile IPv IV.1Alternate-CoA Extension IV.2FlowIdentificationExtension.. 17 IV.3. Routing Considerations IV.4.Protocol Configuration Variables Bibliografia

3 Introduzione Il protocollo Mobile IP propone una soluzione per la mobilità delle stazioni dal punto di vista del livello rete e dal punto di vista della posizione fisica del dispositivo. Consideriamo il caso di una stazione che si muove all'interno dell'ess wlan1. Il cambiamento del "punto di attacco" alla rete è gestito a livello MAC: l'indirizzo IP della stazione non cambia e quindi Mobile IP non interviene. Mobile IP interviene invece quando un nodo si sposta in una diversa rete di accesso. Il protocollo Ipv4 assume che l'indirizzo IP di un nodo identifichi univocamente il suo punto di accesso ad Internet, ossia il nodo deve trovarsi nella rete corrispondente al proprio indirizzo IP per ricevere i pacchetti ad esso destinati. Spostandosi in una rete diversa il nodo riceve un nuovo indirizzo IP. Affinchè un'applicazione che stava inviando dati a quel nodo continui a farlo, deve essere informata di questo evento altrimenti continuerà ad inviare pacchetti al vecchio indirizzo. C'è da dire inoltre che il protocollo di livello trasporto TCP non consente di mantenere attiva una connessione se uno dei due end-point cambia il proprio IP. È possibile consentire ad un nodo che si sposta in un'altra rete di mantenere il proprio indirizzo IP senza modifiche utilizzando router della rete che sappiano instradare i pacchetti destinati al nodo mobile verso la sua nuova posizione. Quindi i router della rete devono scambiarsi delle informazioni in modo da avere sempre delle rotte valide verso il nodo mobile. Ciò significa che, invece di effettuare l'instradamento in base alla parte rete dell'indirizzo IP, i router dovrebbero instradare i pacchetti utilizzando indirizzi IP completi (parte rete, parte host). Questo tipo di approccio rende il passaggio da una rete all'altra trasparente ai nodi mobili, ma comporta un carico di lavoro insostenibile per i 3

4 router, dato che ognuno dovrebbe costruire tabelle con milioni di voci. Risolvere il problema della mobilità rendendo il tutto completamente trasparente ai nodi non ha una soluzione praticabile. Allora si cerca un compromesso tra carico dei router e trasparenza delle operazioni all'utente. Il Mobile IP definisce diverse entità: Mobile Node: un nodo che cambia il suo punto di accesso da una rete o sottorete ad un'altra senza cambiare indirizzo IP. Un tale nodo deve essere in grado di rilevare quando cambia punto di accesso alla rete e quando torna nella propria rete domestica; Home Agent: un router sulla rete domestica del nodo mobile che mantiene la posizione corrente del nodo mobile ed inoltra i datagrammi destinati al nodo mobile mediante la tecnica del tunneling; Foreign agent: un router sulla rete visitata dal nodo mobile che riceve ed inoltra al nodo mobile i pacchetti ad esso destinati e tipicamente agisce da router di default per il nodo mobile; Mobility agent: un Home Agent oppure un Foreign Agent; Correspondent Node: un nodo, mobile o stazionario, con cui il nodo mobile sta comunicando. Home Address: un indirizzo IP assegnato al nodo mobile per un periodo esteso di tempo; Home Network: una rete il cui prefisso corrisponde a quello dell'home Address; Foreign Network: una qualunque rete diversa dalla home network; Care-Of Address: il punto di terminazione del tunnel usato per inviare dati al nodo mobile quando non è nella home network. Esistono due approcci nella gestione della mobilità: instradamento indiretto: la comunicazione tra il corrispondente ed il nodo mobile avviene tramite l'agente domestico, che inoltra i messaggi ricevuti al nodo mobile; instradamento diretto: il corrispondente ottiene l'indirizzo presso la rete 4

5 visitata e comunica direttamente con il nodo mobile. In entrambi i casi occorre una fase di registrazione al termine della quale l'agente ospitante conosce tutti i dati del nodo mobile e l'agente domestico conosce la posizione del nodo mobile e l'indirizzo COA utile per contattarlo. Consideriamo ora l'instradamento indiretto. Il corrispondente indirizza il datagramma da inviare all'indirizzo permanente del nodo. L'agente domestico, che conosce la posizione del nodo mobile, lo inoltra verso l'agente ospitante il quale, a sua volta, lo inoltrerà al dispositivo mobile. La risposta del nodo mobile viene invece indirizzata direttamente al corrispondente. Occorre comunque dire che mentre il nodo mobile si sposta dalla rete domestica a quella ospitante, nell'intervallo di tempo che passa dal momento in cui il nodo si disconnette dalla rete domestica a quello in cui si connette alla rete ospitante, il flusso di dati viene interrotto. Se l'utente mobile si sposta in un'altra rete effettua la registrazione presso il nuovo agente ospitante, il quale informerà l'agente domestico del nuovo CoA. Questo approccio è completamente trasparente al corrispondente e consente al nodo mobile di mantenere le connessioni negli spostamenti tra le reti. Ovviamente lo scambio di messaggi tra corrispondente e nodo mobile mediante l'agente domestico può essere molto inefficiente se i due si trovano entrambi nella stessa rete, triangle routing problem. L'instradamento diretto invece prevede che il corrispondente sia cosciente della mobilità del nodo che intende contattare. Quindi anzichè inviare i datagrammi all'indirizzo permanente richiede e riceve l'indirizzo CoA del nodo mobile. Quindi effettua l'inoltro presso l'agente ospitante, il quale inoltrerà il datagramma verso il dispositivo mobile. Questo approccio risolve il problema della 5

6 triangolazione, ma ne introduce altri. Infatti, se il nodo mobile si sposta in un'altra rete il corrispondente continua ad inviare i pacchetti al COA di cui è in possesso, senza possibilità di sapere se questo è ancora valido. Infatti, il corrispondente contatta l'agente domestico solo all'inizio. Mentre nell'indirizzamento indiretto bastava aggiornare il COA dell'agente domestico per consentire al corrispondente di poter contattare il nodo mobile anche quando questa effettuava diversi spostamenti,con l'indirizzamento diretto ciò non vale. SOLUZIONI: 1) una soluzione potrebbe essere quella di utilizzare un protocollo che avvisi il corrispondente del cambiamento del COA; 2) il corrispondente potrebbe lavorare con agenti di appoggio, un esempio di agente da appoggio è l agetne ospitante. Mobile IP è definito come un insieme di miglioramenti di protocollo che consentono trasparenza nell'instradamento di datagrammi IP verso nodi mobili in Internet. Inoltre prevede che i messaggi usati per aggiornare un nodo riguardo la sua posizione debbano essere autenticati, in modo da avere una protezione contro i redirection attacks. Nel Mobile IP esistono tre concetti chiave: l'agent Discovery, la Registrazione, Tunneling e Flow Binding Support for Mobile IPv4. 6

7 Capitolo I - Agent Discovery L'Agent Discovery è quella fase in cui un nodo mobile giunto in una nuova rete deve apprendere l'identità dell'agente di quella rete, in modo da comprendere se è giunto nella home network o in una nuova foreign network. Questo processo può avvenire tramite un avviso dell'agente da scoprire, che invia un messaggio di Agent Advertisement, oppure tramite una richiesta del nodo, che invia un messaggio di Agent Solicitation. Per l'invio di tali messaggi non è richiesta alcuna fase di autenticazione. Il messaggio di Agent Advertisement estende il messaggio ICMP Router Advertisement, usato per annunciare l'indirizzo di un router che può essere usato come default gateway, aggiungendo un Mobility Agent Advertisement Extension. Questo messaggio viene inviato periodicamente in broadcast a livello MAC, a meno che non sia una risposta alla sollecitazione di un nodo (in tal caso sarà un messaggio unicast), e l'indirizzo IP destinazione può essere (per indirizzarlo a tutti i nodi su quel link) oppure (per indirizzarlo a tutti i nodi della sottorete). Questo messaggio contiene l'indirizzo IP del router, in modo da permettere ai nodi mobili di conoscere l'indirizzo IP dell'agente. Nel Mobility Agent Advertisement Extension, è presente: - il campo Registration Lifetime, che rappresenta la durata massima di una registrazione che l'agente è disposto ad accettare; - il bit R (Registration required) indica che la registrazione è obbligatoria anche se il COA è ottenuto per altra via; - il bit B (busy) il foreign agent non accetta (temporaneamente) registrazioni; - il bit H (home agent) indica che si tratta dell'agente domestico per la rete nella quale risiede; - il bit F (foreign agent) indica che si tratta dell'agente ospitante per la rete nella quale risiede; 7

8 - i bit M e G sono usati per indicare la possibilità d'utilizzo di modalità di tunneling addizionali. Il messaggio Agent Solicitation è identico al messaggio ICMP Router Solicitation. Viene usato da un nodo mobile che vuole informazioni riguardo agli agenti senza voler ricevere una comunicazione dell'agente. In particolare, tale messaggio viene inviato in broadcast: l'agente che riceve questa richiesta invierà direttamente un Agent Advertisement di risposta. Un nodo mobile scopre di essere passato in un'altra rete grazie a due tecniche di Move Detection: 1) Lifetime-based : se il nodo mobile non riceve un nuovo Agent Advertisement da un agente prima della scadenza del campo Lifetime, assume che ha perso contatto con l'agente. In tal caso, il nodo mobile può inviare un messaggio di Agent Solicitation oppure può utilizzare un messaggio di Agent Advertisement ricevuto da un nuovo agente. 2) Network prefix-based: prevede che il nodo mobile utilizzi il prefisso di rete per stabilire se l'agent Advertisement è stato ricevuto sulla stessa sottorete del corrente COA o se appartiene ad una sottorete diversa (e quindi il nodo si è spostato). Ovviamente, un nodo mobile si accorge di essere tornato alla sua home network quando riceve un Agent Advertisement dal suo home agent. In tale caso dovrà operare una de-registrazione verso l'ultima rete ospitante. 8

9 Capitolo II - Registrazione L'operazione di Registrazione consente ad un nodo mobile di registrarsi presso un agente ospitante ed ottenere un indirizzo CoA, che dovrà essere comunicato all'agente domestico. Ciò può avvenire tramite l'agente ospite o direttamente dal nodo mobile. La registrazione crea quindi un mobility binding presso l'home agent che associa per una certa Lifetime l'home address del nodo mobile al care-of address corrente. La registrazione fa uso di due tipi di messaggi, Registration Request e Registration Reply. Ci sono due tipi di care-of address a cui corrispondo due modalità differenti di registrazione: - foreign agent care-of address è un indirizzo che il nodo mobile ha imparato dal messaggio Agent Advertisement inviato dal foreign agent. Vantaggio: i diversi nodi mobili possono condividere lo stesso CoA, diminuendo il numero di indirizzi IP richiesti presso la foreign network. - co-located care-of address è un indirizzo che il nodo mobile ha imparato usando altri mezzi. Vantaggio: il nodo mobile può funzionare anche in luoghi in cui non c è il foreign agent. Le due modalità di registrazione associate all'utilizzo di queste due tipologie di indirizzi sono le seguenti. La prima tipologia di registrazione è quella che avviene attraverso il foreign agent e viene utilizzata quando il nodo mobile utilizza per la registrazione un CoA preso dall'agent Advertisement. Il nodo mobile invia un messaggio di Registration Request al foreign agent il quale reinoltrerà tale richiesta all'agente domestico che risponderà con un messaggio di Registration Reply,che giunge fino al nodo mobile attraverso il foreign agent. Tale procedura dovrebbe essere usata anche quando il nodo mobile si registra con un co-located CoA, ma ha ricevuto un Agent Advertisement con il bit R settato. 9

10 L'altra tipologia di registrazione prevede la comunicazione diretta tra l'home agent e il nodo mobile. In questa modalità il nodo mobile invia la Registration Request direttamente all'home agent che risponderà con una Registration Reply. Questa modalità deve essere usata quando il nodo mobile registra un co-located CoA e non ha ricevuto un Agent Advertisement con il bit R settato. Ovviamente deve essere usata anche quando il nodo mobile si de-registra essendo tornato nella propria home network. Il formato di un messaggio Registration Request contiene: - il Care-of-Address; - l'indirizzo dell'agente domestico e se il nodo mobile non conosce tale indirizzo, indica l'indirizzo di broadcast della sottorete del proprio home address. Ogni agente che riceve il messaggio risponde con una Registration Reply che nega la registrazione, ma in questo modo il nodo mobile viene a conoscenza degli indirizzi degli agenti che potrà utilizzare nelle prossime registrazioni; - il campo Lifetime: è la richiesta di durata della registrazione ed è settato a 0 per indicare una de-registrazione; - Il campo Identification è un valore usato dal nodo mobile per associare una Registration Reply ad una Registration Request e funge da protezione contro i replay attack; - Home Address, ma se il nodo mobile è nella home network e ancora deve registrarsi, nella richiesta tale campo avrà il valore e l'agente fornirà nella Registration Reply l'indirizzo da utilizzare. 10

11 Il messaggio di Registration Reply è formato da: - Un campo Code che indica l'esito della registrazione. In particolare, se Code = 0 indica che la registrazione è andata a buon fine; - Una serie di codici per indicare il motivo per cui la registrazione è stata negata dall'home agent o dal foreign agent. 11

12 Capitolo III - Tecniche per intercettare i pacchetti Una volta effettuata la registrazione, l'home agent conosce il CoA del nodo mobile, che è un indirizzo sulla sottorete nella quale si trova il nodo stesso e lo associa al corrispondente home address del nodo assieme ad un valore lifetime. Poichè il corrispondente conosce l'home address del nodo mobile, invia i pacchetti a tale indirizzo. L'home agent intercetta tali pacchetti, li incapsula inserendoli nel payload del pacchetto IP (di default viene utilizzata la tecnica di tunneling IP-in-IP) e li invia al foreign agent, che invece mantiene una visitor list per determinare l'indirizzo MAC del nodo mobile a cui indirizzare effettivamente il pacchetto. Quindi tutti pacchetti destinati ad un nodo mobile che si trova in un altra rete vengono intercettati dall home agent, se quest ultimo è implementato sul gateway della sottorete domestica del nodo mobile. Quando al gateway arriva un pacchetto destinato al nodo mobile, che si trova in una foreign network, viene inviata sulla home network una ARP Request. Poiché l'home agent è stato configurato in modo da agire da proxy ARP, ricevuta l'arp Request, esamina il target IP address e se questo coincide con l'home address di un nodo per cui esiste un mobility binding, risponde con una ARP Reply contenente il proprio indirizzo MAC, in modo che i prossimi pacchetti saranno indirizzati ad esso. Quando il nodo mobile ritorna nella propria home network sarà in grado di ricevere direttamente i pacchetti ad esso destinati. Allora, come prima operazione viene effettua la de-registrazione per eliminare il mobility binding dalla tabella dell'home agent; quindi invia un messaggio ARP gratuito per fare in modo che gli altri nodi associno il proprio home address al proprio MAC address. Mobile IP è abbastanza soggetto a problematiche di sicurezza. Se nella sottorete della vittima c'è un mobility agent, l'attaccante può registrarsi usando come home address quello della vittima. 12

13 L'home agent nella sottorete della vittima intercetterà i pacchetti destinati alla vittima (che può essere anche un nodo fisso) e l inoltrerà all'attaccante. Per questo occorre che i messaggi di registrazione debbano essere Autenticati. Quindi i messaggi di Registration Request/Reply contengono un'estensione per la verifica dell'autenticità del mittente. Viene quindi inserita una checksum, che nello specifico è un message digest calcolato sul messaggio di registrazione con un algoritmo, che fa uso di una chiave a 128 bit. Il calcolo corretto della checksum prova la conoscenza della chiave e quindi l'autenticità del mittente. Inoltre per fornire protezione contro i replay attack il campo Identification nei messaggi di registrazione contiene l'ora dell'invio del messaggio, in modo che ogni coppia di messaggi di registrazione abbia timestamp differenti. La conoscenza di una chiave comune tra home agent e nodo mobile è un meccanismo che può essere risolto. Invece, garantire che un nodo mobile conosca una chiave comune con un foreign agent, indipendentemente dalla particolare foreign network è qualcosa di più complesso. 13

14 Capitolo IV - Flow Binding Support for Mobile IPv4 Questo documento presenta l estensioni del protocollo Mobile IP definendo due nuove estensioni che permettono ad un nodo mobile di registrarsi con più CoA usando un Alternate-CoA extension e di associare diversi flussi con differenti CoA tramite Flow Identification extension. IV.1. Alternate-CoA Extension Una nuova estensione usata per richiedere all home agent di registrare un altro careof-address attraverso cui raggiungere il nodo mobile. Un nodo mobile può inviare un Alternate-CoA extension nel messaggio di Registration Request all HA, se il messaggio di Registration Reply inviato dall HA non include il corrispondente Alternate-CoA extension, il nodo mobile viene a conoscenza che l' HA non supporta questa specifica. Il nodo mobile deve mettere Alternate-CoA Extension prima del Mobile-Home Authentication Extension nei messaggi di registrazione, in modo che l estensione sia completamente protetta. L Alternate-CoA Extension è costituita dai seguenti campi: Length Indica la lunghezza (in byte) dell'estensione; BID (Binding ID) Il campo BID intero senza segno in 8-bit, che identifica il legame del Care-of-Address incluso in quest estensione; 14

15 Care-Of Address (CoA) Il campo CoA è formato da 32-bit. Questo campo non può essere aggiunto se l estensione è inclusa nel Registration Request con il campo BID impostato al BID del CoA precedente e se tale estensione è inclusa nel messaggio di Registration Reply ; Interface Type Tipo di interfaccia attraverso la quale è collegato il nodo mobile; Reserved Questo campo è in disuso. Il valore deve essere inizializzato a 0 dal mittente e deve essere ignorato dal ricevente; Priority/Status Quando l Alternate-CoA Extension è nel messaggio di Registration Request specifica il campo Priority assegnato al care-of-address. Il campo Priority è un intero senza segno a 8 bit e il ricevitore può utilizzare questo campo per determinare quale CoA usare per distribuire i pacchetti. Più basso è il valore del campo Priority, maggiore è la priorità assegnata al Coa e se il valore di tale campo è 255, il CoA deve essere cancellato. Quando l Alternate-CoA Extension è nel messaggio di Registration Reply questa estensione indica lo stato del CoA. Il campo Status è un intero senza segno a 8 bit, dove i valori indicano un successo e i valori compresi tra 128 e 255 indicano un fallimento. I valori definiti per il campo Status sono: Status Valori Commenti Accepted 0 CoA registrato. BID Changed 1 Il BID associato con un esistente CoA è stato cambiato al nuovo valore. Reject 128 CoA rifiutato. Unknown BID 129 Il BID non è riconosciuto Ogni CoA può essere aggiornato individualmente, inviando un messaggio di Registration Request, con il nuovo CoA inserito nell Alternate-CoA extension. Un nodo mobile può sostituire il CoA associato ad una determinata BID, inviando un 15

16 Alternate-CoA extension con il campo BID impostato al BID del CoA che voglio modificare ed inserendo nuovi valori dei campi Priority e CoA, impostando il campo Status su un valore appropriato (ad es., indicando operazioni come: accepted, rejected ecc). Quando un messaggio di Registration Request include uno o più accepted Alternate- CoA extension l HA deve includere i CoA accettati nella mobility bindings table che lega, per un tempo esteso, gli home address con i CoA registrati insieme ai loro BID, priorità e lifetime. Il BID e la priorità di un CoA sono indicati nell Alternate- CoA extension, mentre la lifetime è ereditata dalla durata del messaggio di Registration Reply. Da notare che CoA può essere rimosso dalla mobility bindings table se il campo lifetime di un Alternate-CoA scade. Gli Alternate-CoA avranno stessa durata, se sono registrati con lo stesso messaggio di Registration Request, altrimenti avranno durata differente. Ogni CoA sarà classificato in base alla sua priorità, più basso è il valore del campo Priority tanto maggiore è la loro posizione in classifica. Quando un messaggio di Registration Request include uno o più rejected Alternate- CoA extension, allora l HA non deve includere CoA rifiutato nella mobility bindings table. 1. Inoltre, se un Alternate-CoA extension è ricevuto con un BID uguale a un BID esistente nella mobility bindings table, allora l HA deve controllare il campo Priority dell'estensione in questione Se il campo Priority è impostato a 255, il CoA deve essere rimosso dalla mobility bindings table; 1.2. Se il campo Priority è impostato a qualsiasi altro valore, l HA deve controllare il campo CoA dell estensione e si possono verificare i seguenti casi: Se il campo CoA non è incluso, deve essere aggiornata la priorità del CoA identificato dal BID nell'estensione,; Se il campo CoA è incluso, le possibili situazioni che si possono verificare sono: Il campo CoA corrisponde a quello indicato dal campo BID nella mobility bindings table, allora la priorità di tale CoA deve essere di nuovo aggiornata; 16

17 Il campo CoA è non corrisponde a quello indicato dal campo BID nella mobility bindings table, allora l' HA dovrebbe aggiornare la sua tabella inserendo il nuovo CoA indicato dal BID con la sua priorità. 2. Se un Alternate-CoA extension è ricevuto con un BID che è diverso dal BID esistente nella mobility bindings table, allora l HA deve controllare il campo CoA dell'estensione, in quanto si possono presentare le seguenti situazioni: Se il campo CoA non è incluso, l HA dovrebbe includere un Alternate- CoA extension nella Registration Reply, con un BID copiato dalla corrispondente estensione nel messaggio di richiesta e il campo Status impostato su "Unknown BID"; Se il campo CoA è incluso, l HA deve memorizzare nella mobility bindings table: il BID, CoA e valori di priorità del nodo mobile; Se il campo CoA è incluso, ma corrisponde a una CoA che è già registrato con un BID diverso, l' HA può sostituire il vecchio BID con il nuovo BID e può indicare il valore "BID Changed" nel campo Status del corrispondente Alternate-CoA extension incluso nel messaggio di Registration Reply. IV.2. Flow Identification Extension Una nuova estensione, compresa nei messaggi di Registration Request e Registration Reply, può avere anche più istanze all interno del stesso messaggio. Quest estensione contiene informazioni che permettono all home agent d identificare un flusso di traffico. Se un Flow Identification extension è ricevuto da un HA in un messaggio di Registration Request, l HA dovrebbe includere il corrispondente Flow Identification extension nel messaggio di Registration Reply, altrimenti il nodo mobile viene a conoscenza che l HA non supporta la seguente specifica. Il nodo mobile deve mettere quest estensione prima del Mobile-Home Authentication Extension nei messaggi di registrazione, in modo che sia completamente protetta. Flow Identification Extension ha un formato flessibile, questo può provocare a una leggera complessità nell'implementazione; tuttavia, consente di minimizzare la lunghezza totale dell'estensione inviata, che risulta essere particolarmente importante quando vengono usati collegamenti wireless a banda-limitata. I campi del Flow 17

18 Identification Extension sono indicati nella seguente tabella: Length Indica la lunghezza (in byte) dell'estensione; FID È un identificatore per un dato IP flow, individuato univocamente dal source address, destination address, tipo di protocollo, suorce port e destination port. Priority/Status Quando quest estensione è in un messaggio di Registration Request, specifica la priorità assegnata alla filter rule. Più basso è il valore del campo Priority, maggiore è la priorità assegnata alla filter rule e se il valore di tale campo è 255, la filter rule dev essere cancellata; Quando quest estensione è in un messaggio di Registration Reply, indica lo stato della filter rule. Per il campo Status i valori indicano un successo e i valori compresi tra 128 e 255 indicano un fallimento. I possibili status codes sono elencati nella Tabella 3. Status Value Comments Accepted 0 Flow binding è stato accettato. Reject 128 Flow binding rifiutato per ragioni non specificate. Poorly Formed 129 Flow Identification extension è formato male. Admin Prohibited 130 Amministrativamente proibito. Unknown FID 131 Il FID non è riconosciuto. Unknown BID 132 Un BID incluso nell estensione non è riconosciuto Table 3: Valori del campo Status per il Flow Identification 18

19 Action Quando l estensione è nel messaggio di Registration Request, specifica l'azione che deve essere presa dal ricevitore. I possibili valori del campo Action sono: Action Value Comment Drop 0 Diminuisce i corrispondenti pacchetti. Una regola di filtraggio che indica la Drop action deve includere un solo BID byte, il cui valore può essere impostato a 255 dal mittente e ignorato dal ricevente. Forward 1 Inoltra i corrispondenti pacchetti nel 1st BID della lista dei BIDs a cui punta la filter rule. X-Cast 2 Inoltra una copia di ciascun pacchetto nella lista dei BIDs a cui punta la filter rule. Table 4: Values for the IPv4 and IPv6 Flow Descriptor Action field F-Type Il campo Filter Type (F-Type) identifica il tipo di Filter Descriptor incluso nell'estensione. Filter Descriptor Il campo Filter Descriptor definisce un filtro e indica, in ogni documento, sempre la propria lunghezza; BIDs Indica i BIDs a cui il Filter Rule Descriptor punta, in ordine di apparizione. Si noti che se una filter rule non punta a nessun BIDs valido, la filter rule stessa non è più valevole; Type Tipo di range ignorabile. Vengono assegnati due valori da IANA uno per IPv4 e IPv6: 1. Se il campo Type indica un IPv4 Flow, allora, il Filter Rule Descriptor è come di seguito specificato. 19

20 Figura 4: IPv4 Filter Rule Descriptor Flags (A-L) Ogni flag, se settato, indica che il campo corrispondente è presente nel messaggio; (B)Protocol Un intero senza segno a 8 bit, che rappresenta il valore del numero di protocollo di trasporto associato con i numeri di porta nei pacchetti dati; (C) Source Address Questo campo identifica il source address dei pacchetti dati, che è l'indirizzo IPv4 a 32 bit del nodo corrispondente; (D)Destination Address Identifica il destination address dei pacchetti dati. Quando questo campo è incluso, deve essere impostato su uno dei home address registrati del nodo mobile. Si tratta di un indirizzo IPv4 a 32 bit; (E)Source Prefix Length Questo campo indica la lunghezza del prefisso del source address. Esso può essere inserito solo se il source address è incluso; (F) Destination Prefix Length Questo campo include la lunghezza del prefisso del destination address. Esso può essere inserito solo se il destination address è incluso; (G)Source Port Low Questo campo identifica il più basso numero di source port all interno di un intervallo in cui sono indicati i numeri di porta che verranno utilizzati nei pacchetti dati; 20

21 (H)Source Port High Questo campo identifica il più alto numero di source port all'interno di un intervallo in cui sono indicati i numeri di porta che saranno utilizzati nei pacchetti dati; (I)Destination Port Low Questo campo identifica il più basso numero di destination port all'interno di un intervallo di numeri di porta che verranno utilizzati nei pacchetti dati; (K)Destination Port - High Questo campo identifica il più alto numero di destination port all'interno di un intervallo di numeri di porta che verranno utilizzati nei pacchetti dati. 2. Se il campo Type indica la presenza di un IPv6 Flow, allora la Filter Rule Descriptor è come specificato di seguito: Flags (A-M) Ogni flag, se settato, indica se il campo corrispondente è presente nel messaggio; 21

22 (B)Protocol Un intero senza segno a 8 bit, che rappresenta valore del numero di protocollo di trasporto associato con i numeri di porta nei pacchetti dati; (C)Source Address Questo campo indica il source address dei pacchetti dati, cioè l'indirizzo del nodo corrispondente ed è a 128-bit per indirizzi IPv6; (D)Destination Address Questo campo identifica il destination address del pacchetto dati. Quando è incluso questo campo deve essere impostato su uno dei home address registrati del nodo mobile ed è a 128-bit per indirizzi IPv6; (E)Source Prefix Length Questo campo include il prefisso per il source address. Esso può essere inserito solo se il Sourece Address è incluso ; (F)Destination Prefix Length Questo campo include il prefisso per il destination address. Se il campo Destination Address è incluso, allora si riferisce a quel campo, altrimenti si riferisce al campo home address del messaggio Registration Request; (G)Source Port Low Questo campo identifica il più basso numero di source port all'interno di un intervallo di numeri di porta che verrà utilizzata nei pacchetti dati; (H)Source Port High Questo campo identifica il più alto numero di source port all'interno di un intervallo di numeri di porta che sarà utilizzato nei pacchetti dati; (I)Destination Port Low Questo campo identifica il più basso numero di destination port all'interno di un intervallo di numeri di porta che verrà utilizzata nei pacchetti dati; (K)Destination Port High Questo campo identifica il più alto numero di destination port all'interno di un intervallo di numeri di porta che sarà utilizzato nei pacchetti dati. Se il nodo mobile vuole cambiare la priorità di un filter rule può inviare un Flow Identification extension, includendo nell estensione il FID della filter rule che vuole modificare e impostando il campo Priority al nuovo valore (o 255 per la 22

23 cancellazione), senza includere eventuali BIDs. Le Filter rule non hanno bisogno di essere aggiornate esplicitamente e risultano valide fino a quando puntano a BIDs validi. Qualsiasi filter rule nella tabella classificatrice può essere sostituita da una nuova filter rule, inviando una Flow Identification extension con il campo FID impostato al FID del filter rule da sostituire e il resto dell'estensione definisce la nuova filter rule, la priorità ed i BIDs a cui punta. Ogni Flow Identification extension è classificato secondo il suo campo Priority, in cui si ha che minore è il valore del campo maggiore è la sua priorità. Come nella maggior parte delle classificazioni, le filter rule con la stessa priorità dovrebbero essere non sovrapposte, altrimenti il risultato è indefinito. I dispositivi mobile dovrebbe definire una filter rule di default per il traffico, che può essere definita da un Filter Identification extension impostando un elevato valore di priorità (in modo che sia selezionato all ultimo), il campo Filter Descriptor con flag impostati a 0 e il campo Action impostato a un opportuno valore. Si noti che l'elenco dei BIDs nel Flow Identification extension è ordinato e il loro significato dipende dall'azione indicata dal campo Action della stessa estensione. Quando un valido messaggio di Registration Request include una o più accepted Filter Identification extension, l HA deve includere le filter rule accettate nella tabella classificatrice del nodo mobile, per poi associare ogni filter rule con BIDs specifici. Se una filter rule è rifiutata, non deve essere inclusa nella classificazione del nodo mobile. Ciascuna filter rule nella classificazione del nodo mobile è valida fintanto che indica un BIDs valevole, altrimenti l HA deve rimuoverla. Se l HA riceve un Flow Identification extension, occorrerebbe innanzitutto verificare il campo FID di quell estensione distinguendo i due casi: 1. Se il valore del campo FID corrisponde a uno dei FID nella tabella classificatrice del nodo mobile specifico, l HA dovrebbe controllare il campo Priority del Flow Identification extension. In base al valore indicato nel campo Priority avremo: Se il campo Priority è impostato a 255, allora la filter rule associata al FID nel Flow Identification extension deve essere rimossa dalla tabella di classificazione del nodo mobile specifico; Se il campo Priority, è impostato su un valore diverso da 255, l HA dovrebbe controllare il campo Filter Description del Flow Identification 23

24 extension. Le possibili situazioni sono: Se la Filter Description non è inclusa nell estensione e il campo BID viene impostato a 0, l HA deve regolare la classifica della filter rule corrispondente al FID specifico, secondo il campo Priority nel Flow Identification extension; 2. Se la Filter Description è inclusa nell estensione, allora l' HA deve sostituire la corrispondente filter rule nella tabella di classificazione del nodo mobile con la filter rule inserita nel Flow Identification extension. Se il valore del campo FID non corrisponde a nessuno dei FID classificati dal nodo mobile, l HA dovrebbe includere la nuova filter rule nella tabella di classificazione del nodo mobile e dovrebbe essere classificata secondo il campo Priority indicato nel Flow Identification extension. In base ai BIDs dell estensione distinguiamo: Se uno o più BIDs sono inclusi nell estensione, allora la filter rule deve indicare la lista dei BIDs nell'ordine in cui appaiono; Se uno qualsiasi dei BIDs inclusi nell estensione non corrisponde a uno dei BID registrati nella mobile bindings table, l HA deve ignorare il Flow Identification extension e deve restituire un messaggio di risposta con il Flow Identification extension che include il FID dell estensione ricevuta e il campo Status impostato su un valore appropriato ( per esempio, " Unknown BID "); Se è incluso un BID con valore 0, l' HA deve restituire un messaggio di risposta con un Flow Identification extension, che include il FID della corrispondente estensione e il campo Status impostato su un valore appropriato. In entrambi i casi se alcuni BIDs sono inclusi anche nella Flow Identification extension, allora la lista dei BIDs, associati a una specifica filter rule, deve essere sostituita dalla lista fornita dal Flow Identification extension. 24

25 IV.3. Routing Considerations Questo documento permette all entità mobili di scambiare opzionalmente politiche di flusso. La maggior parte dei dispositivi IP supportano due schemi di traffico alternativi, Perflow load balancing e Per-packet load balancing. Questi schemi di bilanciamento di carico consentono al seguente dispositivo di distribuire uniformemente il traffico in base ai criteri di per- packet o per-flow, in tutti equal-cost links disponibili. Il comportamento predefinito di Per-flow load balancing trasmesso, garantirà che un determinato flusso assumi sempre lo stesso percorso ed eliminerà eventuali problemi di riordinamento dei pacchetti, che rappresenta la causa fondamentale del rallentamento del traffico. Un ulteriore schema di bilanciamento di carico è il Perdestination load balancing, che sfrutta tutti i percorsi, ma presenta un importante problema dovuto al riordinamento dei pacchetti sul lato ricevitore. IV.4. Protocol Configuration Variables Le seguenti variabili di configurazione del protocollo sono necessarie per la gestione del sistema e queste variabili devono essere configurabili su tutte le entità mobili. Un possibile flag da utilizzare è : Enable Multiple Tunnel Support. Questo flag indica se o non l'entità mobile, su cui questa variabile di protocollo è configurata, deve abilitare funzioni Multiple Tunnel Support. Questa variabile di protocollo è applicabile sull home agent, sul foreign agent e sul nodo mobile. Se questo flag è impostato a 0, indica che è disabilitato, mentre se risulta impostato a 1, dovrebbe essere abilitato. Nel momento in cui questo falg è abilitato il nodo mobile può stabilire multiple tunnel con l home agent, registrando una care-of-address per ognuno delle sue interfacce di roaming attive. I messaggi di Mobile IP exstension, definiti in questo documento devono essere trasportati in messaggi Mobili IP Registration, autenticati e interamente protetti senza indebolire il protocollo Mobile IP. 25

26 Bibliografia Draft IETF Mobility for IPv4 Multiple Tunnel Support; IETF Request for Comments (RFCs); 3344, 3024, 3519 J. Kurose, K. Ross, Reti di Calcolatori e Internet, Pearson; M. Gast, Wireless Networks: The Definitive Guide, O'Reilly; A.Gurtov, Host Identity Protocol (HIP), Wiley; J. Andrews, A. Ghosh, R. Muhamed, Fundamentals of WiMAX, Prentice Hall. 26