UNIVERSITÀ CÀ FOSCARI DI VENEZIA

Transcript

1 UNIVERSITÀ CÀ FOSCARI DI VENEZIA Dipartimento di Informatica Docente: Prof. Francesco Dalla Libera Anno Accademico Seminario di Protocolli di Reti Carlo Zacchello matr Antonio De Faveri matr

2

3 Carlo Zacchello Antonio De Faveri Pagina 1 Sommario 1 Introduzione Caratteristiche Informazioni trasmesse Assegnamento indirizzi Automatico Dinamico Manuale Vantaggi e svantaggi Funzionamento di DHCP V Funzionamento di DHCP V Messaggi Messaggi DHCP V Messaggi DHCP v Equivalenze tra Messaggi DHCP e DHCP v Stateless vs stateful DHCP v DHCP v6 Stateless DHCP v6 Stateful Scambio dei messaggi Riallocazione/Rinnovo Indirizzo IP Riallocazione Riallocazione: passo Riallocazione: passo Riallocazione: passo Riallocazione: passo Rinnovo Rinnovo: passo Rinnovo: passo Rinnovo: passo Configurazione apparecchiature Configurazione Client Configurazione Server Apparecchiature escluse Assegnazione inappropriata degli indirizzi Sicurezza Riferimenti...25

4 Carlo Zacchello Antonio De Faveri Pagina 2 Indice delle Figure Figura 2.1: Architettura Cliente - Servente DHCP...5 Figura 6.1: Formato messaggio DHCP...9 Figura 6.2: Formato messaggio DHCP v Figura 6.3: Formato opzioni DHCP v Figura 6.4: Automa a stati finiti del client...17 Figura 10.1: Formato opzione autenticazione DHCP...23 Indice delle tabelle Tabella 6.1: Descrizione campi messaggi DHCP...10

5 Pagina 3 1 Introduzione DHCP è un protocollo di rete che permette ai nodi di una rete di essere configurati ed identificati in maniera automatica da un apparato centrale. La sua nascita fu dettata dalle esigenze di semplificare le operazioni di assegnazione degli indirizzi di rete, in modo di ridurre gli interventi manuali sulla configurazione dei sistemi, e di ottimizzare l'accesso alla rete da parte di utenti saltuari, permettendo di allocare un numero di indirizzi inferiore all'utenza reale (nell'ipotesi che non sia mai tutta connessa). Storicamente rappresenta un'evoluzione di BOOTP, con il quale è (opzionalmente) retrocompatibile. Si possono trovare svariati esempi di utilizzo di dhcp, dagli ISP di connettività dial-up ai router domestici.

6 Pagina 4 2 Caratteristiche DHCP è strutturato secondo un modello client-server basato su due componenti: un meccanismo di allocazione degli indirizzi ed un protocollo per la trasmissione dei parametri di configurazione. Gli attori del protocollo DHCP sono 3 [fig 2]: DHCP server, che distribuisce gli indirizzi di rete, tiene traccia delle assegnazione, e che rialloca gli indirizzi con il lease time scaduto, DHCP client, l'host che si collega alla rete, DHCP relay agent, che inoltra le richieste fatte da un DHCP client verso il DHCP server, che si trova in un'altra rete (v. figura 2.2, la sequenza dei colori è rosso, che viene fermato dal router, celeste, verde, grigio e i passi si possono trovare al capitolo 4.3), e le risposte del server al client. Per funzionare deve conoscere l'indirizzo IP del DHCP server. Quando un client contatta un server DHCP per la prima volta, tra i due viene concordato un tempo di validità (lease time) per la configurazione assegnata; all'interno di questo periodo l'indirizzo rimane invariato ed, in caso di riavvio del client, il server cerca di riassegnare lo stesso ip alla macchina. L'accreditamento per l'accesso alla rete avviene secondo il seguente schema: - Il client manda un messaggio in broadcast a tutta la rete (poiché, ovviamente, non conosce l'indirizzo del DHCP server), chiedendo un indirizzo ed una configurazione. - I server (supponendo che nella rete ve ne sia più di uno) rispondono con un messaggio indirizzato al client (rintracciabile grazie al suo mac address) contenente una proposta di configurazione.

7 Pagina 5 - Il client utilizza un indirizzo ricevuto (generalmente il primo) ed invia un messaggio broadcast per informare la rete della configurazione che ha accettato. - Il server che ha offerto l'indirizzo selezionato invierà una conferma al client avvisandolo che l'indirizzo che gli ha assegnato ha una scadenza (lease time); gli altri server invece ritireranno la loro offerta rendendola disponibile in caso di richieste future. A questo punto il client è configurato per l'utilizzo della rete. Figura 2.1: Architettura Cliente - Servente DHCP Per maggiori informazioni vedere la RFC 2131[1] (versione precedente RFC 1541) e successive.

8 Pagina Informazioni trasmesse Tipicamente il messaggio di configurazione inviato dal server contiene [2]: Indirizzo IP Subnet Mask DNS WINS A queste possono essere affiancate delle informazioni ausiliarie necessarie per utilizzare alcuni servizi essenziali: Nome dell'host Nome del dominio Gateway predefinito Server Network Time Protocol Esistono due criteri in base a cui assegnare gli indirizzi ip: Indirizzo MAC: consiste nell'identificare l'indirizzo hardware univoco di ogni dispositivo collegato alla rete, così da fornire in modo continuato la stessa configurazione ogni volta che il client DHCP avanza una richiesta al server DHCP usando quel particolare dispositivo di rete; Spazio degli indirizzi: viene definito un insieme o un intervallo di indirizzi IP (a volte indicati come pool) da assegnare dinamicamente i client DHCP in base all'ordine di arrivo delle richieste (la prima che arriva è la prima servita, disciplina FIFO). Dopo un determinato periodo, se il client DHCP non è presente in rete, la configurazione scade e viene reinserita nello spazio di indirizzi per poter essere riutilizzata. 2.2 Assegnamento indirizzi Normalmente DHCP prevede tre meccanismi di allocazione degli indirizzi: automatico, dinamico e manuale. [2] Automatico Un client che si connette al server DHCP riceve un indirizzo disponibile che viene mantenuto a tempo indeterminato fino alla disconnessione del client o ad una richiesta di nuova assegnazione. Il server tiene memoria degli IP assegnati in passato per una riassociazione dello stesso indirizzo allo stesso host, nel caso questo si sia disconnesso per un breve periodo di tempo Dinamico Un client che si connette al server DHCP riceve un indirizzo disponibile e lo mantiene per un tempo assegnato: l'indirizzo viene preso in lease (affitto) per un tempo determinato dopo il quale il client deve richiedere una nuova assegnazione. Differisce dal meccanismo automatico in quanto non viene garantita la riassegnazione dello stesso indirizzo al client Manuale Un client che si connette al server DHCP riceve sempre lo stesso indirizzo, univocamente determinato (es. dall'indirizzo MAC della scheda di rete, nome DNS di un server di rete, indirizzo

9 Pagina 7 di una subnet, ecc...). Con questo tipo di allocazione il DHCP si comporta come un postino che recapita al client un pacchetto di configurazione prefissato dall'amministratore di rete. 3 Vantaggi e svantaggi Il primo vantaggio di utilizzare DHCP è che eventuali cambiamenti della topologia della rete, ad esempio la modifica dell'indirizzo del server DNS o l'aggiunta di una stampante, richiedono di essere apportati manualmente solo ai server dhcp mentre gli altri host della rete vengono riconfigurati automaticamente. Questo semplifica l'integrazione di nuovi dispositivi nella rete, sollevando l'amministratore dall'onere di verificare la disponibilità di un indirizzo IP e, contestualmente, riduce notevolmente i conflitti nell'allocazione degli indirizzi IP. Un altro vantaggio consiste nella possibilità di spostarsi attraverso varie reti senza dover riconfigurare manualmente i parametri di accesso ad ogni cambio di rete (un'esigenza molto sentita dagli utenti di dispositivi mobili). Inoltre non è necessario utilizzare esclusivamente dhcp ma si può continuare a usare una configurazione manuale per alcuni host che lo richiedano (es: server dns, macchine che eseguono qualche servizio particolare, ecc). Da non sottovalutare è la possibilità di implementare un server dhcp anche su hardware economico, ad esempio i router domestici su cui semplificano le operazioni di installazione della rete all'utenza inesperta. Di contro, in contesti più grandi, serve dell'hardware dedicato che deve essere settato in maniera opportuna e l'amministratore di rete deve essere in grado di effettuare modifiche e inserimenti. Deve venir pianificata una metodologia che permetta alla rete di funzionare nel caso il server DHCP abbia problemi e bisogna anche definire il range di indirizzi che può assegnare e quelli che devono essere riservati (es. l'indirizzo del server DHCP deve essere un indirizzo non assegnabile). Con DHCP non è possibile risalire con certezza ad un client visto che il suo indirizzo può essere cambiato ed il vecchio indirizzo riassegnato ad un'altra macchina; questo può essere problematico nel caso si voglia tracciare l'attività in rete dei client (ad esempio nel caso si voglia rintracciare il responsabile di azioni fraudolente) e comporta la necessità di usare dei sistemi di logging delle assegnazioni. [3]

10 Pagina 8 4 Funzionamento di DHCP V4 La negoziazione avviene per mezzo di messaggi User Datagram Protocol (UDP) sulle porte 67 (server) e 68 (client), che sono riservate a questo scopo. Il processo di allocazione degli indirizzi viene detto ROSA: Request, Offer, Send, Accept.[4] Quando si connette alla rete, un client DHCP invia una richiesta in broadcast (DHCPDISCOVER) con indirizzo IP sorgente e indirizzo di destinazione , nella speranza di trovare un server DHCP in ascolto. (fase di Request) I server DHCP presenti sulla rete possono rispondere (o meno) con un pacchetto DHCPOFFER, contenente una proposta di configurazione, e lo inviano all indirizzo MAC del computer che ha lanciato il DHCPDISCOVER. (fase di Offer) Il client aspetta per un certo tempo di ricevere una o più risposte, dopodiché ne seleziona una e invia un pacchetto DHCPREQUEST in broadcast indicando quale server ha scelto. (fase di Send) Il server prescelto risponde quindi con un pacchetto DHCPACK per confermare l assegnazione e concludere la transazione. (fase di Accept) Da notare che le proposte di configurazione contengano una durata del prestito dell'indirizzo. Questo significa che una volta accettata quella proposta, il client manterrà la configurazione data fino allo scadere del tempo prestabilito. Prima del termine di questo periodo, dovrà rinnovare la configurazione, possibilmente cercando di mantenere gli stessi parametri, pena la caduta temporanea della connessione e di tutte le attività legate alla rete che erano in corso. 5 Funzionamento di DHCP V6 Il meccanismo di funzionamento di DHCPv6 è lo stesso adottato da nella versione precedente; ovviamente i pacchetti hanno nomi diversi e dimensioni maggiori per poter trasportare indirizzi più lunghi di quelli di ipv4. Inoltre, al fine di evitare confusione, vengono usate porte diverse: i client ascoltano sulla porta 546 udp mentre i server ed i relay sulla 547 udp. 6 Messaggi 6.1 Messaggi DHCP V4 Il formato dei messaggi è standard per tutti i messaggi scambiabili tra server e client. Questo formato può venire usato anche per servire client che si appoggiano esclusivamente con BOOTP, il predecessore di DHCP, grazie al fatto che alcuni campi opzionali sono interpretabili da entrambi (ad esempio NomeFile, usato da bootp per fornire il percorso dell'immagine per il boot di rete).

11 Pagina 9 Operazione Tipo HW Lunghezza ind. fisico N salti ID transazione Secondi Flag IP Client IP Assegnato IP Server IP Relay agent Indirizzo HW Client Nome server Nome File Opzioni Figura 6.1: Formato messaggio DHCP

12 Pagina 10 Campo Operazione Descrizione Tipo di messaggio: 1 =BOOTREQUEST identifica i messaggi diretti dal client al server 2 =BOOTREPLY identifica i messaggi diretti dal server al client Tipo HW Tipo di indirizzo fisico della macchina. Per Ethernet il valore e' 1. Lung. Ind. Fisico Lunghezza in byte dell'indirizzo fisico (6 bytes per Ethernet) N salti Utilizzato in caso di Relay agent, se il client è nella subnet del server questo campo è a 0 ID transazione Secondi Flag IP Client IP Assegnato IP Server IP Relay agent Ind. HW Client Nome server Nome File Opzioni Un numero casuale scelto dal client per associare le richieste e le risposte Secondi trascorsi dall'inizio della configurazione Nel caso il client non accetti messaggi unicast prima di aver configurato l'indirizzo IP viene modificato questo campo di 16 bit in questo modo: B Bit impostati a zero B = flag di broadcast/unicast Inizialmente posto a , è usato di norma quando il client si trova a dover richiedere i parametri (es. nel caso di lease time in scadenza) Indirizzo offerto dal server al client Viene usato nel passo di inizializzazione successivo, nella spedizione dei messaggi DHCPOFFER e DHCPACK Se questo campo è vuoto il client è nella stessa subnet del server Indirizzo fisico del client (MAC address) Campo opzionale con la stringa identificante il nome del server DHCP Nel caso il messaggio DHCP debba essere usato in una rete con BOOTP viene utilizzato questo campo per inviare il nome del file immagine di boot, per macchine senza disco di avvio Campo di lunghezza variabile di almeno 312 ottetti. Questo implica che il client deve poter ricevere messaggi di almeno 576 ottetti Tabella 6.1: Descrizione campi messaggi DHCP I messaggi che si possono scambiare il client e il server (o il relay agent) DHCP sono riassunti qui sotto [1]: DHCPDISCOVER: Messaggio broadcast inviato dal client alla subnet per localizzare i server disponibili a mandargli una configurazione di rete. Quando viene ricevuto questo messaggio da un qualsiasi server, questo sceglie un indirizzo da dare al client. Se il server non ha indirizzi disponibili viene avvisato l'amministratore, che attuerà le proprie politiche. Se ha indirizzi disponibili da allocare può

13 Pagina 11 DHCPOFFER: DHCPREQUEST: DHCPACK: DHCPNAK: DHCPDECLINE: DHCPRELEASE: scegliere diverse soluzioni: allocare l'indirizzo che il client aveva in precedenza (se il client era già stato connesso alla rete e se l'indirizzo è ancora disponibile), accettare la configurazione che il client ha già (se è nel suo range di indirizzi), accettare l'indirizzo che segnala il client con l'opzione Requested IP Address, sempre se è un indirizzo valido e non allocato (questa è una delle opzioni inseribili nel messaggio DHCP), allocare un nuovo indirizzo tra quelli del suo pool, in base alla subnet del richiedente. Ogni server che risponde ad un DHCPDISCOVER crea questo tipo di messaggio, includendo: l'indirizzo IP offerto al client (se il server ha già dato un indirizzo a questo client tenta di riassegnare lo stesso IP), il periodo di lease, tutti parametri di configurazione che possono servire, che sono programmati nel server e che il client chiede, il suo nome (nome server) e assegna al messaggio lo stesso ID del messaggio DHCPDISCOVER ricevuto. Questo messaggio viene creato dal client dopo aver selezionato l'offerta per lui migliore che può essere la prima arrivata o in alternativa essere quella che più gli aggrada (es. tempo di lease più alto). Il client a questo punto invia questo messaggio con le seguenti informazioni: identificativo del server del quale ha accettato l'offerta, non dimentichiamoci che il client invia anche questo messaggio in broadcast così tutti i server che ascoltano sanno che la loro offerta è stata accettata o respinta, indirizzo IP che il server gli ha assegnato, questo serve come conferma all'offerta fatta, la richiesta di altri parametri che a lui servono. Il server, ricevuto il messaggio DHCPREQUEST con il suo indirizzo, se ha ancora disponibile l'indirizzo che era stato proposto, invia questo messaggio di conferma e fornendogli i parametri richiesti. Se l'indirizzo proposto è stato già assegnato a qualche altro client, oppure se è scaduto il tempo di lease, il server manda questo messaggio al client e il client invierà nuovamente il DHCPDISCOVER. Il client ha la possibilità di controllare che l'indirizzo che il server vuole assegnargli sia effettivamente univoco (lo fa tramite una richiesta ARP), se si accorge che l'indirizzo è già usato da qualcun altro invia questo tipo di messaggio al server ricomincia il ciclo per la richiesta dell'indirizzo. Questo messaggio viene mandato dal client al server in unicast per

14 Pagina 12 DHCPINFORM: terminare il lease e rilasciare l'indirizzo assegnatogli. Viene mandato dal client al server per chiedere nuovamente i parametri di configurazione, senza ripetere tutto l'iter come se avesse bisogno di un nuovo indirizzo. 6.2 Messaggi DHCP v6 Il formato messaggi DHCP v6 invece è: [5] Msg-Type dove Msg-Type sono: Solicit: Advertise: Request: Confirm: Renew: Rebind: Reply: Release: Decline: Reconfigure: Opzioni (Variabile) Id. Transazione Figura 6.2: Formato messaggio DHCP v6 Inviato da un client per trovare quali sono i servers. DHCP presenti in rete. Messaggio inviato dai server per segnalare la loro presenza in risposta ad un messaggio Solicit. Messaggio inviato dai server per offrire ai client dei parametri di configurazione. Messaggio inviato dai client per informare i server che l indirizzo IP offerto è ancora appropriato alle condizioni di rete in cui si trova. Messaggio inviato dai client per allungare il periodo di prestito dell indirizzo IP e degli altri parametri di configurazione. Come Renew, ma viene inviato quando non viene ricevuta nessuna risposta. Messaggi usati dai server per confermare o meno l assegnazione di un indirizzo IP a un client. Reply ha un accezione ancora più ampia, in quanto può contenere dei nuovi parametri di configurazione da offrire al client. Messaggio inviato da un client per informare i server che l indirizzo IP che stava usando è stato rilasciato e può essere reinserito nel pool degli indirizzi IP disponibili. Messaggio inviato dai client per informare i server che l indirizzo IP offerto è già in uso. Messaggio inviato da un server a un client per informarlo che possiede nuove informazioni di configurazione, e che dovrebbe iniziare un nuovo ciclo Renew/Reply oppure Information-Request/Reply per ricevere le informazioni aggiornate.

15 Pagina 13 Information-Request:Messaggio inviato dai client per richiedere i parametri di configurazione senza il bisogno di ricevere un indirizzo IP, che possiede già Relay-Forward: Relay-Reply: Messaggi usati da eventuali relay agent presenti sulla rete, per permettere lo scambio delle configurazioni fra più reti che usano un solo DHCP server. Messaggi usati da eventuali relay agent presenti sulla rete, per permettere lo scambio delle configurazioni fra più reti che usano un solo DHCP server. Il formato delle opzioni presenti nel DHCP v6 è la seguente: Option-code Option-data Option-length Figura 6.3: Formato opzioni DHCP v6 Option-code Option-len Option-data E' un intero che identifica un specifico tipo di opzione contenuta in questa opzione. E' un intero che rappresenta la lunghezza del campo Option-data. I dati delle opzioni; il formato e il tipo di dati dipendono dal tipo di opzione definita. 6.3 Equivalenze tra Messaggi DHCP e DHCP v6. DHCPv6 Message Equivalente DHCP Message Solicit DHCPDISCOVER Advertise DHCPOFFER Request DHCPREQUEST Confirm DHCPREQUEST Renew DHCPREQUEST Rebind DHCPREQUEST Reply DHCPACK / DHCPNACK Release DHCPRELEASE Decline DHCPRELEASE Reconfigure -

16 Pagina 14 Information-Request DHCPINFORM Relay-Forward - Relay-Reply Stateless vs stateful DHCP v6 Ci sono principalmente due modalità di utilizzo del tipo di servizio richiesto al DHCP: Stateless[6] Stateful DHCP v6 Stateless Il servizio Stateless Dynamic Host Configuration Protocol per IPv6 (DHCPv6) viene utilizzato dai client per ottenere delle informazioni di configurazione, come gli indirizzi di DNS name servers, che non richiedono la gestione di alcun stato dinamico per dei clients. Un nodo che utilizza una configurazione stateless DHCP deve aver già ottenuto il proprio indirizzo IPv6 attraverso altri meccanismi, tipicamente una autoconfigurazione dell'indirizzo. Durante questo tipo di configurazione, vengono scambiati solo 2 messaggi: INF-REQUEST e REPLY Se si prova ad eseguire un tcp dump sulla rete, si leggeranno questi risultati 15:45: IP6 PC-G71V.546 > ff02::1:2.547: dhcp6 inf-req 15:45: IP6 AntonioDeFav-PC.547 > PC-G71V.546: dhcp6 reply DHCP v6 Stateful Si assume che gli indirizzi (e possibilmente anche altri parametri) vengano assegnati al client. Per eseguire questo tipo di configurazione si ha uno scambio di 4 messaggi: SOLICIT, ADVERTISE, REQUEST e REPLY. 15:30: IP6 PC-G71V.546 > ff02::1:2.547: dhcp6 solicit 15:30: IP6 AntonioDeFav-PC.547 > PC-G71V.546: dhcp6 advertise 15:30: IP6 PC-G71V.546 > ff02::1:2.547: dhcp6 request 15:30: IP6 AntonioDeFav-PC.547 > PC-G71V.546: dhcp6 reply 6.5 Scambio dei messaggi Il client appena connesso il suo dispositivo di rete alla rete stessa invia un DHCPDISCOVER (come detto il paragrafo precedente), quindi è nel suo stato INIT (v. figura 6.4). Non ha indirizzo e non

17 Pagina 15 conosce il server DHCP e nemmeno sa se esiste. Quindi invia questo tipo di messaggio su tutta la rete indicando il suo indirizzo MAC, un identificatore del messaggio (un numero random) utilizzato poi per gli altri messaggi e le eventuali richieste (assegnamento di un indirizzo specifico, impostare un lease time particolarmente lungo, dei parametri di configurazione specifici, ecc...). Il client ora passa quindi allo stato successivo: il SELECTING. I server DHCP nella subnet processano il messaggio ricevuto e verificano se l'indirizzo MAC lo avevano già nel loro database e se possono fare un offerta, poi determinano i termini del noleggio. Se il client ha richiesto un IP specifico, un tempo di lease particolare o altri parametri, il server tenterà di soddisfare le richieste. I server rispondono (tutti) al client, in unicast o in broadcast, con un DHCPOFFER includendo le seguenti informazioni: Indirizzo IP offerto, se il server aveva assegnato precedentemente un indirizzo a quello specifico MAC, tenta di riassegnarglielo, nel caso contrario usa l'indirizzo IP richiesto dal client, altrimenti assegna un nuovo indirizzo IP, Tempo di lease, Parametri di configurazione specifici richiesti dal client oppure programmati dall'amministratore, Qualsiasi altro parametro da mandare al client, Il proprio nome host, Stesso ID del messaggio ricevuto. I server hanno la possibilità di inviare un messaggio all'indirizzo che dovrebbero assegnare al client che sta facendo la richiesta, per verificare che quell'indirizzo non sia già in uso, nel caso di IP in uso, il server non lo offrirà al client e ne offrirà un altro. Al client ora è arrivato il messaggio DHCPOFFER e, in base all'implementazione che ha, può decidere di accettare il primo messaggio arrivato oppure può aspettare che tutti i server abbiano risposto e poi accettare l'offerta più conveniente a lui (es. stesso indirizzo IP dell'ultima volta, tempo di lease più lungo, ecc...). Se non viene ricevuto nessun messaggio DHCPOFFER il cliente ritornerà allo stato di INIT inviando nuovamente DHCPDISCOVER. Il client quindi crea il DHCPREQUEST per l'offerta che ha selezionato. Questo messaggio ha due scopi: informare il server del quale accetta l'offerta e informare i restanti server che non ha accettato la loro offerta. In questo messaggio il client include: l'identificativo del server selezionato, l'indirizzo IP che il server gli ha proposto, una richiesta di qualsiasi parametro di configurazione che gli serve. Spedito questo messaggio il client si mette nello stato di REQUESTING, nel quale aspetta una risposta dal server. I server ricevono il messaggio. Quelli che non hanno letto nel messaggio il proprio identificativo si

18 Pagina 16 mettono in uno stato di rifiutato (prima di riassegnare l'indirizzo che quel client ha rifiutato aspettano per qualche istante). In questo stato il server può ancora assegnare al client che aveva fatto la richiesta l'indirizzo che gli aveva proposto (es. transazione non completata con il server scelto; per caduta di collegamento del server) come seconda scelta (il client invierà un altro DHCPREQUEST con l'identificativo del nuovo server scelto). Il server selezionato, se non l'ha fatto prima, verifica che l'indirizzo sia ancora disponibile, se non lo è invierà al client un DHCPNAK, nel caso migliore invierà un DHCPACK che conferma il noleggio con i parametri opzionali richiesti dal client. Il client se ha ricevuto un DHCPNAK torna allo stato INIT e ripeterà l'iter, se invece riceve il DHCPACK controlla l'indirizzo e il tempo di lease. Se nessuno dei due messaggi viene ricevuto il client ritrasmetterà il DHCPREQUEST per un altra volta, se non riceve messaggi ricomincerà la trafila per ottenere un indirizzo IP. Il client a questo punto fa un suo controllo: tenterà di contattare l'indirizzo IP assegnatogli per verificare che sia solo lui ad averlo, se riceve una risposta invierà un DHCPDECLINE al server che glielo ha assegnato e ritornerà allo stato INIT. Il client, se tutto è andato a buon fine, entrerà nello stato di BOUND e setterà i suoi due timer di lease T1 e T2. A questo punto il client può colloquiare con al rete.

19 Pagina 17 Figura 6.4: Automa a stati finiti del client

20 Pagina 18 7 Riallocazione/Rinnovo Indirizzo IP Quando il client è nello stato BOUND il DHCP rimane in stato di attesa fino al tempo di lease. Non c'è bisogno, per effettuare il rinnovo o la riallocazione del lease, di ripetere lo scambio di messaggi che si effettua alla prima connessione. 7.1 Riallocazione La riallocazione dell'indirizzo si effettua per due motivi principali: Il tempo di lease è variabile a seconda delle policy della rete; questo serve nel caso che le postazioni vengano spente, ad esempio, la notte e riaccese la mattina, così da non dover fare ogni giorno richieste di allocazione di indirizzi, ma solo rinnovi di tempo di lease. Rinnovare il tempo di lease senza dover assegnare nuovamente gli indirizzi, ad esempio nel caso le macchine vengano spente la sera e riaccese al mattino. Nel caso di reboot di un client (es. installazione nuovo software), sarebbe dispendioso, per la rete allocare un indirizzo IP nuovo per un client che il minuto prima aveva un indirizzo già noto anche ad altri client/server. Evitare di dover riassegnare l'indirizzo ip in caso di interruzione momentanea della connessione alla rete, ad esempio nel caso di un reboot per installare un nuovo software. Il processo di riallocazione dell'indirizzo IP è più breve rispetto al quello di allocazione: il client richiede al server, con cui ha effettuato l'allocazione, se il lease è ancora valido e se può riprendere ad usare l'indirizzo precedentemente allocato Riallocazione: passo 1 Il client parte ora dallo stato REBOOT e invia un DHCPREQUEST in broadcast per trovare un server con l'informazione del suo noleggio (può anche non essere il server originario). In questo messaggio non ci sarà l'identificativo del server, ma ci sarà: il suo indirizzo hardware, l'indirizzo IP che ha al momento, un numero random per l'identificativo della transazione una richiesta di parametri vari Riallocazione: passo 2 Ogni server controlla se il client è nel suo database per trovare le informazioni che sono state richieste e poi decide la risposta da dare al client: Informazioni valide: il server ha delle valide informazioni e invia al client un DHCPACK per confermare l'indirizzo IP e tutte le informazioni di cui il client ha bisogno. Noleggio invalido: il server decide che il prestito non è più valido (es. quando un client si sposta in un altra rete e chiede conferma del prestito, oppure dopo che il tempo di lease è finito) e invia un DHCPNAK.

21 Pagina 19 Informazioni scarse: un server che non ha informazioni o non ha tutte le informazioni non risponde al client Riallocazione: passo 3 Il client riceve ora due possibili messaggio: DHCPACK o DHCPNAK. Aspetta per qualche istante, per aspettare le risposte da tutti i server, e poi, in base alle risposte pervenutegli (quelle del passo precedente), risponde: DHCPACK: questo conferma la validità del noleggio e il client utilizzerà nuovamente il suo indirizzo IP per dialogare in rete, DHCPNAK: il noleggio non è più valido e il client torna allo stato di INIT per richiedere un nuovo indirizzo IP, Nessuna risposta: il client rispedisce un altro messaggio DHCPREQUEST e, se dopo un periodo di tempo, non ha ancora risposte conclude che nessuno ha le informazioni riguardanti il suo noleggio e tornerà allo stato di INIT Riallocazione: passo 4 Il client, fa un controllo addizionale per verificare che l'indirizzo che gli è stato confermato non sia in uso da qualcun altro. Non sarebbe necessario questo controllo, in quanto a questo punto ci arriva per una conferma del suo lease, ma viene fatto ugualmente per sicurezza. Se qualcuno risponde manda un DHCPDECLINE al server e torna a INIT, se nessuno risponde va nello stato di BOUND. 7.2 Rinnovo Quando il client arriva al tempo di rinnovo, se vuole continuare a dialogare, deve fare in modo che il server prolunghi il suo tempo di lease (a meno di allocazione dinamica con tempo di lease infinito o allocazione automatica). In questa fase entrano in campo due timer: il timer di rinnovo (renewing) e il timer di riconnessione (rebinding). Alla scadenza del primo il client deve richiedere al server di prolungare il tempo concesso al prestito, la scadenza del secondo, comporta che non c'è stata risposta per il rinnovo e il client deve richiedere ad un qualsiasi server il rinnovo. Dalla definizione di questi due tempi si può capire che il tempo di riconnessione è più lungo di quello di rinnovo ed entrambi sono più brevi del tempo di durata del lease (durata lease > riconnessione > rinnovo) Rinnovo: passo 1 Quando il tempo di rinnovo, di default il 50% del tempo di lease, scade, il client passa dallo stato di BOUND a quello di RENEWING e invia un messaggio DHCPREQUEST, in unicast questa volta, con le informazioni su chi è e il suo tempo di lease che era stato contrattato alla prima connessione Rinnovo: passo 2 Qui abbiamo due casi: Il server è raggiungibile e riceve la richiesta di rinnovo. Il server può essere d'accordo o non esserlo. Nel primo caso invia un DHCPACK per

22 Pagina 20 confermare il rinnovo indicando il nuovo tempo di lease, nel secondo caso invia un DHCPNAK rifiutando di rinnovare il noleggio. Il server non è raggiungibile. Il client scaduto il tempo di riconnessione (87,5% del tempo di lease), avendo più volte spedito il messaggio DHCPREQUEST e non avendo mai ricevuto risposta, passa dallo stato RENEWING a quello REBINDING (fino a questa scadenza il client dialoga normalmente con la rete). Invia quindi un messaggio DHCPREQUEST in broadcast indicando l'indirizzo che ancora possiede. Tutti i server presenti e in funzione nella rete, se hanno informazioni riguardanti il client, rispondono con un DHCPACK, confermando il rinnovo, oppure rispondono con un DHCPNAK, rifiutando l'estensione del noleggio Rinnovo: passo 3 Il client riceve un messaggio di risposta: nel caso sia un DHCPACK setta i due timer (rinnovo e riconnessione) in base al tempo di lease che gli è stato concesso (se era nello stato REBINDING, memorizza il server che gli ha risposto) nel caso sia un DHCPNAK il client passa immediatamente allo stato INIT per ricominciare il processo di allocazione.

23 Pagina 21 8 Configurazione apparecchiature 8.1 Configurazione Client Il client per essere configurato richiede solo che il servizio sia attivato, tutti gli altri parametri riguardanti la rete a cui si è collegato gli vengono inviati dal server DHCP, nel caso gliene servano altri può inviare in unicast il messaggio DHCPINFORM. 8.2 Configurazione Server Il server per poter fornire il servizio DHCP deve conoscere dei parametri di base: il nome di dominio di default per i client, la lista dei server DNS che devono essere usati dai client, la maschera di rete per la subnet in cui opera, il tempo di lease di default da assegnare se il client non ne specifica uno diverso, il massimo tempo di lease, il range di indirizzi che può assegnare per ogni sottorete a cui fornisce il suo servizio, il default gateway, l'indirizzo MAC degli eventuali host che necessitano di indirizzo IP fisso (es. DNS). Oltre a questi possono essere aggiunti anche altri parametri che in base alla rete potrebbero essere più o meno importanti. 8.3 Apparecchiature escluse E' bene che alcune apparecchiature di rete non abbiano un indirizzo IP dinamico. Lo stesso server DHCP, WINS, DNS, SMTP, SQL, Proxy e anche i server WEB dovrebbero avere un indirizzo IP statico, se proprio il server DHCP avesse un indirizzo dinamico, i client che si appoggiavano a questo per il loro noleggio andrebbero spesso nello stato di REBINDING quando devono rinnovare il tempo di lease. Anche i server WEB è necessario abbiano indirizzi IP statici, altrimenti i server DNS dovrebbero modificare il loro database ogni volta che questo cambia indirizzo.

24 Pagina 22 9 Assegnazione inappropriata degli indirizzi Un primo problema che può verificarsi è il conflitto di indirizzi. Se abbiamo più server DHCP con range di indirizzi che si sovrappongono è possibile che un server dia un indirizzo ad un client e un altro server dia lo stesso indirizzo ad un altro client. Un'altra fonte di problemi può essere il servizio APIPA (Automatic Private IP Addressing) presente sui sistemi windows più recenti. Se il client non riesce a mettersi in contatto col server DHCP, il servizio APIPA assegna automaticamente un indirizzo della famiglia x.x, col risultato che la macchina non riesce a connettersi alla rete nel caso venga usato un altro range di indirizzi.

25 Pagina Sicurezza Alcuni amministratori di rete, per rendere la propria rete più sicura, possono fare in modo che ci sia un'autenticazione dei messaggi scambiati. Potrebbero voler limitare l'assegnazione di indirizzi ad host autorizzati al fine di evitare attacchi Denial of Service in ambienti ostili in cui la rete non è fisicamente protetta. La minaccia più grossa per DHCP è l'attacco interno, cioè, la possibilità di fare in modo di essere un finto server che da informazioni errate ad un client per accaparrarsi le risorse, e l'indirizzo IP, che dovrebbe avere quel client e compiere attacchi (es. Denial of Service) dando la colpa a quel client. Un altra possibile minaccia per il client DHCP è che il server invii messaggi con parametri di configurazione non volutamente errati. Una minaccia per il DHCP server, invece, è che ci sia un client non valido mascherato in maniera che sia valido (attacco interno). La RFC 3118 [7] espone un metodo per autenticare i messaggi che server e client DHCP si scambiano e introduce un opzione di autenticazione fatta in questo modo. Figura 10.1: Formato opzione autenticazione DHCP I campi di questa opzione sono: Code: questo campo identifica l'opzione, 90 è il codice dell'autenticazione, Length: contiene la lunghezza dei restanti campi in ottetti, Protocol: ha 2 possibili valori 0, per il token di autenticazione una protezione semplice senza autenticazione dei messaggi, o 1, per l'autenticazione ritardate, inserita nel messaggio DHCPOFFER inviato dal server al client, Algorithm: il tipo di algoritmo usato nel protocollo di autenticazione, RDM: Replay Detection Method, identifica il tipo di rilevamento usato nel campo Replay detection (es. un contatore), Replay detection: varia a seconda del RDM, Authentication Information: dipende dal tipo di protocollo usato Questo tipo di autenticazione è scarsamente utilizzata dato il fatto che dal 1993 al 2001 il DHCP è stato implementato in ogni stazione e che le stazioni sono aumentate in maniera pressoché esponenziale. Si sono quindi utilizzate altre forme di protezione, tipo il DHCP Snooping effettuato

26 Pagina 24 da alcuni switch (analizzano tutti i pacchetti DHCP che li attraversano creando una mappatura tra indirizzi IP e indirizzi MAC facendo in modo che solo il server DHCP possa rispondere con dei messaggi DHCP) e IP Source Guard in combinazione con il DHCP Snooping (prevede che tutto il traffico IP proveniente da una porta non affidabile sia bloccato ad eccezione dei messaggi DHCP, tramite il DHCP Snooping viene costruita una lista di accesso per la determinata porta; il traffico con IP diverso da quello definito nella mappatura del DHCP Snooping viene scartato)[8].

27 Pagina Riferimenti 1: Network Working Group, RFC Dynamic Host Configuration Protocol, : Network Working Group, RFC Dynamic Host Configuration Protocol, : Cisco IOS IP Configuration Guide, Release 12.2, 4: K. S. Siyan, T. Parker, TCP/IP, 2002, Apogeo 5: J.F.Kurose - K.W.Ross, Internet e reti di Calcolatori, 2003, McGraw-Hill 6: Network Working Group, RFC Dynamic Host Configuration Protocol for IPv6 (DHCPv6), 7: Network Working Group, RFC Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6, 8: Network Working Group, RFC Authentication for DHCP Messages, : J.Davidson - J.Peters - M.Bhatia - S.Kalindi - S.Mukherjee, Fondamenti di Voice Over IP. Un approccio sistematico alla comprensione dei fondamenti di Voice Over IP., 2008, Pearson Paravia Bruno Mondadori S.p.A.