Scenari Non Collaborativi in DSR

The route isn't important. It's the destination that matters. - Marianne Williamson

La fase di testing all'interno del SDLC è indubbiamente importante e ne abbiamo già parlato con le dovute considerazioni. Quando si tratta di protocolli di rete, però, la fase di testing in molti casi non può essere effettuata in scenari reali a causa di molteplici fattori - prima fra tutti la disponibilità delle risorse necessarie. Come si ovvia dunque a tale problema? Una possibile soluzione è fornita dalle simulazioni. Uno dei simulatori di rete più diffusi e completi è ns-3. In questo articolo voglio proporre un estratto del lavoro che ho svolto insieme ad un mio carissimo amico e collega - colgo l'occasione per ringraziare G.T. - nel quale presentiamo una modifica del modulo che implementa il protocollo di routing DSR presente nel simulatore ns-3. Con la nuova versione modificata del modulo, da noi battezzato DSR Bad, miriamo a studiare ed analizzare due esempi di scenari non collaborativi che ci permettano di osservare l’impatto subìto dal protocollo e la sua reazione a situazioni che non sono normalmente previste.

Prima di procedere è bene premettere alcuni importanti dettagli. Tutte le simulazioni sono state effettuate su macchina virtuale avente come sistema operativo Linux Mint 19.3 con installato il simulatore ns-3 versione 3.30.1. Il WiFi si trova in modalità ad-hoc con un rate di 2 Mb/s (802.11b) e come modello di propagazione viene impiegato il Friis Propagation Loss Model.

Il protocollo DSR

Il protocollo Dynamic Source Routing (DSR) rappresenta un esempio di protocollo di routing per reti MANET di tipo reattivo. Senza perderci nei dettagli del protocollo, ricordiamo semplicemente che i suoi vantaggi sono: basso overhead; i nodi che “ascoltano” apprendono nuove informazioni; scopre tutti i possibili cammini. D'altro canto i suoi svantaggi sono: all’inizio spreca molta energia (broadcast); intestazione di dimensione variabile; nessun incentivo alla collaborazione ma presuppone che tutti i nodi siano onesti. In particolare, poniamo maggiore enfasi su quest'ultimo svantaggio. Infatti, per poter funzionare in modo corretto, DSR presuppone che i nodi collaborino senza inibire, in alcun modo malevolo, le operazioni di routing.

Scenario Droppers

Il primo scenario che andremo a prendere in esame, chiamato Droppers, prevede che i nodi intermedi (cioè tutti i possibili nodi tra sorgente e destinazione) possano scartare con una certa probabilità i pacchetti ricevuti dagli altri nodi. Fra questi figurano anche i pacchetti di gestione Route Request (RREQ), Route Reply (RREP) e Route Error (RERR). In particolare, in questo contesto vogliamo osservare di quanto peggiorano le prestazioni del protocollo in funzione della percentuale di drop dei pacchetti da parte dei nodi, tenendo in considerazione anche il numero di pacchetti che i nodi ricevono durante la simulazione.

Scenario Liar

Più interessante risulta invece il secondo scenario, denominato Liar, il quale è caratterizzato da un'esecuzione con un nodo intermedio che mente sulla posizione della destinazione del pacchetto che deve inoltrare, fingendosi un suo vicino. Questo scenario potrebbe essere considerato più pericoloso rispetto al precedente: se un nodo riesce a mentire per molto tempo, questi potrà essere in grado di imporsi come una sorta di proxy per la destinazione e, di conseguenza, molta parte del traffico indirizzato alla destinazione passerà da lui, comportando eventuali rischi per la sicurezza - si vedano Man in the Middle Attack e Black Hole Attack. Anche qui vogliamo osservare eventuali variazioni di prestazioni del protocollo ponendo, però, maggiore enfasi sulla riuscita o meno dell'imbroglio e sulle eventuali capacità di recupero del protocollo.

Struttura

Regione

La regione della simulazione consiste in un'area rettangolare di dimensioni 1150x500 (m) che ospita un totale di 72 nodi distribuiti in 6 righe (12 nodi per riga). I nodi, una volta posizionati all'interno della regione, non alterano la propria posizione. Inoltre, la distanza fra una riga e l'altra è di 100 m e, all'interno della stessa riga, tra ogni nodo vi è una distanza ancora pari a 100 m. Questa disposizione - in aggiunta alla potenza di trasmissione fissata a 7.5 dBm - fa sì che quando un nodo trasmette, soltanto i sei nodi più vicini (cioè quelli che lo circondano) ricevano il segnale.

Continuando con la descrizione della struttura, particolare attenzione va data alla prima e all'ultima colonna di nodi. Infatti, la prima colonna contiene i nodi denominati sources che generano pacchetti destinati ai sink. L'ultima, invece, contiene dei nodi - detti appunto sinks - che stanno in ascolto di pacchetti a loro indirizzati.

Codice

Prima di passare alle demo degli esperimenti è doveroso accennare alle modifiche principali fatte sul codice - per semplicità evitando di approfondire tale aspetto poichè non è lo scopo di questo articolo. Per quanto riguarda i sorgenti del progetto,  questi sono organizzati in due cartelle. La cartella dsr contiene il modulo DSR modificato - tra le varie modifiche citiamo la classe dsr-bad-nodes - per poter eseguire gli scenari non collaborativi introdotti precedentemente. Il file dsr-performance.cc contenuto nella cartella scratch avvia la simulazione prendendo in input alcuni parametri e registra i risultati. Tralasciando ulteriori dettagli, all'interno del file dsr-routing.cc per quanto concerne lo scenario Droppers, è stato scritto un metodo (BadDropEvent) utilizzato dai nodi intermedi durante la simulazione per scatenare l'evento di drop dei pacchetti. Questo metodo restituisce un valore booleano: se il valore restituito dal metodo sarà true il nodo scarterà il pacchetto, altrimenti lo inoltrerà normalmente. All'interno dello stesso file, ma riguardante lo scenario Liar, è anche stato scritto un metodo (CountLiarReferencesInRoutes) allo scopo di tener conto delle occorrenze che ogni nodo possiede del nodo malevolo nelle proprie route cache. Questa operazione viene eseguita periodicamente durante la simulazione (ogni 10 secondi) per considerare gli aggiornamenti delle route cache da parte dei nodi. Infine, il comportamento malevolo del nodo liar è implementato - di seguito un estratto significativo del codice - nel file dsr-options.cc e consiste nel costruire una falsa route cache nella quale esso stesso si pone come ultimo nodo prima della destinazione.

Demo

Una volta introdotto, seppur brevemente, il background per poter comprendere un minimo le demo ed i risultati da queste scaturiti, possiamo passare all'azione lanciando gli esperimenti. È bene ricordare che lo scenario Legit utilizza il protocollo DSR così come è stato sviluppato senza ulteriori modifiche e la sua esecuzione viene utilizzata come punto di riferimento per il confronto con gli altri scenari. Inoltre, negli scenari non collaborativi sono esclusi dal poter svolgere azioni malevole, per ovvie ragioni, i nodi source e sink.

Scenario Droppers

Nel primo scenario da analizzare si è preso in considerazione un tempo di simulazione di 350 secondi ed i seguenti valori di probabilità di drop: 1%, 5%, 10%. Per avere un punto di riferimento in modo tale da confrontare i vari risultati, è bene innanzitutto lanciare l'esecuzione dello scenario Legit:

$ scratch/dsr-performance --duration=350 --outFileNames=DSR

Una volta terminata tale esecuzione, si può procedere a lanciare le altre simulazioni - per semplicità in ordine crescente - nello scenario Droppers aggiungendo i parametri badScenario (in questo caso il valore da impostare è 1) e dropRate (0.01, 0.05 e 0.1 nell'ordine).

Il formato dell'output è il seguente: tempo di simulazione, identificativo del nodo, evento - come si può osservare nell'immagine sopra.

Risultati

Terminate le simulazioni, i risultati ottenuti possono essere raggruppati e graficati. A tale proposito è possibile utilizzare i dati che vengono forniti in output sui file csv e darli in input ad un software - Gnuplot, Excel o equivalenti - adatto allo scopo. Il grafico - visibile di seguito - prodotto a partire dall'output delle simulazioni eseguite risalta il modo in cui le prestazioni del protocollo DSR vengono profondamente influenzate in maniera negativa dallo scenario Droppers, già con un drop rate dell'1%.

Si osserva infatti che nell'esecuzione DROP-0.01 il numero cumulativo di pacchetti ricevuti dai sink - in ordinate - risulta significativamente minore rispetto all'esecuzione lecita di DSR. Con un drop rate del 5% il valore si abbassa addirittura al di sotto della metà rispetto al valore lecito. Infine, un valore di drop rate del 10% contribuisce a diminuire di circa un settimo il valore delle ordinate, quasi inibendo di fatto il corretto funzionamento del protocollo.

Questi primi risultati confermano dunque la tesi che il protocollo DSR dipende fortemente dalla collaborazione dei nodi nella rete.

Scenario Liar

Nel secondo scenario risulta essere sufficiente una tempistica di esecuzione di 101 secondi, in quanto le simulazioni sono in questo contesto indipendenti dalla variabile tempo. A differenza del caso Droppers, qui si è interessati a scoprire la posizione del nodo che riesce a mentire di più - in termini di traffico pacchetti - sulla sua presunta vicinanza alla destinazione. Si procede quindi ad eseguire una simulazione con scenario Liar per ogni nodo intermedio in posizione centrale che, di volta in volta, farà le veci del nodo liar. Pertanto, analogamente a quanto fatto nell'esperimento precedente, è sufficiente lanciare in maniera sequenziale le simulazioni con i parametri che seguono:

$ ... --duration=101 --outFileNames=LIAR-28 --badScenario=2 --liar=28

$ ... --duration=101 --outFileNames=LIAR-29 --badScenario=2 --liar=29

. . .

$ ... --duration=101 --outFileNames=LIAR-43 --badScenario=2 --liar=43

Risultati

Terminate le simulazioni descritte sopra, si deve adesso valutare quale sia il nodo che influenza in maniera più significativa il corretto funzionamento del protocollo. A questo proposito si ha che i nodi che vedono più traffico sono quelli in posizione centrale ed essi rappresentano potenziali candidati a rendere maggiormente pericoloso lo scenario Liar. Si procede quindi confrontando i risultati ottenuti riguardanti gli otto nodi individuati. Nella tabella sottostante è possibile osservare i corrispondenti valori delle simulazioni Legit e Liar.

Il nodo che salta immediatamente all'occhio è quello avente id 42, in quanto fra i due scenari vi è uno scarto di ben 767 pacchetti in meno ricevuti. Questo fatto accade perchè gli altri nodi hanno meno riferimenti ad esso nelle proprie route cache, rispetto allo scenario lecito. Il numero di riferimenti al nodo 42 risulta essere 1455 nello scenario lecito e 920 nello scenario Liar. In quest'ultimo quindi, il numero cumulativo di riferimenti che i nodi hanno del 42 è inferiore di 535 pacchetti rispetto al valore che assume nel primo scenario. In ultima aggiunta, In ultima aggiunta, si può precisare inoltre che il nodo 42 si trova quasi esattamente al centro della regione. Si è individuato dunque il nodo che soddisfa le condizioni per poter essere scelto come nodo liar significativo e, di conseguenza, lo si può utilizzare per effettuare un confronto con lo scenario lecito. Da questo momento in poi ci si riferirà in generale al nodo liar (o malevolo) intendendo il nodo 42.

La diminuzione dei pacchetti ricevuti del nodo liar è molto sorprendente in quanto significa che esso viene sostanzialmente escluso dai percorsi degli altri nodi e, dunque, viene quasi totalmente ignorato durante il resto della simulazione. A questo punto si potrebbe però pensare che l'imbroglio non riesca. In realtà, l'intento malevolo del nodo liar ha successo nei primi secondi della simulazione ma, dopo un certo punto, il nodo malevolo viene cancellato dalle route cache dagli altri nodi - il che comporta di fatto una quasi totale negazione del traffico per esso. Pertanto si ha un peggioramento iniziale delle prestazioni del procollo che avrà ormai influenzato l'andamento delle ricezioni dei pacchetti. A questo punto, prima di passare alle conclusioni, è possibile dare un'occhiata al confronto delle prestazioni fra le due simulazioni DSR e LIAR-42:

Come preannunciato è evidente che le prestazioni del protocollo DSR vengono influenzate in maniera certamente più lieve rispetto allo scenario precedente, ma non trascurabile.

Conclusioni

I due scenari bad che abbiamo confrontato con la versione originale del protocollo DSR hanno fatto emergere per certi aspetti dei risultati attesi - come osservato lo scenario Droppers ha di fatto confermato un forte calo delle prestazioni già con il solo 1% di drop rate. D'altra parte invece, lo scenario Liar ha messo in risalto come la posizione centrale di un nodo in DSR risulta essere la più critica. Il nodo malevolo riesce a causare danni iniziali che influenzano le prestazioni del protocollo nonostante gli altri nodi riescano a riprendere in mano la situazione velocemente, isolandolo dai propri percorsi.

In ultima analisi, proponiamo un confronto circa le prestazioni del protocollo DSR fra i tre scenari trattati. In particolare, prendiamo in considerazione il valore di drop rate meno dannoso (1%) nello scenario Droppers e il nodo più pericoloso (id 42) per lo scenario Liar. Come illustra la figura sopra, il primo scenario risulta comunque più distruttivo rispetto al secondo. Pertanto, possiamo concludere con l'affermare che il protocollo DSR risulta più sensibile, in termini di prestazioni, ad attacchi nello scenario Droppers piuttosto che nello scenario Liar. Questo è sufficiente a confermare che il protocollo soffre in un ambiente non collaborativo.

References

• https://it.wikipedia.org/wiki/Dynamic_Source_Routing
• https://www.researchgate.net/publication/262291230 Dynamic Source Routing DSR Protocol Implementation in ns-3
• https://www.rapid7.com/fundamentals/man-in-the-middle-attacks/
• https://pure.coventry.ac.uk/ws/portalfiles/portal/21367156/Dynamic_Source_Routing_under_Attacks.pdf