MORGAN (MPLS Overlay Routing Gives Anonymous Networking

MORGAN (MPLS Overlay Routing Gives
Anonymous Networking) Architecture
Donato Battaglino, Simone Teofili
25 settembre 2007
Introduzione
In questo documento sono descritte le nuove scelte architetturali della rete di
anonimizzazione MORGAN (MPLS Overlay Routing Gives Anonymous Networking): in esso vi sono le possibili ipotesi per la realizzazione del sistema
con i pro ed i contro che esse portano nell’architettura. Le nuove caratteristiche dell’architettura della rete di anonimizzazione sono dovute al problema
che occorre prevedere l’ingresso e il rientro di un socket all’interno della rete
di anonimizzazione: a tale scopo è stato introdotto il concetto di indirizzo
overlay (esplicito o implicito) che sarà descritto più avanti nel documento.
Le ipotesi fatte per l’ingresso di uno stream di dati nella rete di anonimizzazione prevedono l’uso di un proxy SOCKS che rilancia le connessioni TCP (in
caso di proxy SOCKS5 anche datagrammi UDP) attraverso la rete oppure
la configurazione di gateway che si affacciano direttamente sulla rete overlay. Altre caratteristiche documentate sono: scenari applicativi della rete di
anonimizzazione, formato del pacchetto con la presenza di indirizzi overlay e
multiplazione di più flussi in un path overlay.
1
Capitolo 1
Scenari applicativi
Gli scenari applicativi della rete di anonimizzazione MORGAN sono due, di
cui il secondo è l’estensione del primo. Il primo scenario operativo è di tipo
TOR-like [1] mentre il secondo comprende nella rete overlay anche i nodi
iniziale e finale della comunicazione (architettura all-in-MORGAN).
A
R1
R4
R3
R2
B
RETE OVERLAY MORGAN
Fig.1: Architettura TOR-like
A
R1
R4
R3
R2
B
RETE OVERLAY MORGAN
Fig.2:Architettura all-in-MORGAN
1.1
Architettura TOR-like
In questo scenario la rete overlay non comprende il nodo mittente e il nodo destinatario della comunicazione: occorre prevedere quindi un punto d’ingresso
e un punto d’uscita a/da la rete MORGAN. La maggior parte dei problemi
2
implementativi che riguardano questo scenario sono concentrati proprio sul
punto di ingresso di uscita dalla rete overlay. In Fig.1 possiamo vedere che gli
estremi della comunicazione sono il nodo A (client) e il nodo B (application
server): il nodo A vuole comunicare in modo anonimo con B utilizzando la
rete overlay MORGAN. Il primo processo che deve scatenare il nodo A è la
creazione del path (sempre in modo anonimizzato) per arrivare a B passando
per i nodi overlay (MORGAN nodes) R1,R2,R3 ed R4: il protocollo di segnalazione per la creazione del path non è specificato in questo documento, ma
si suppone che A (o un’altra entità sollecitata da A, come ad esempio il nodo
d’ingresso R1) possa invocare tale protocollo ogniqualvolta voglia istituire un
path attraverso la rete di anonimizzazione. Il nodo overlay R1 è l’ingresso
che A vede sulla rete MORGAN: le due scelte implementative possibili per
l’ingresso nella rete overlay sono di considerare R1 come proxy che inoltra le
richieste nella rete di anonimizzazione oppure come gateway (verso B) che si
affaccia sulla rete MORGAN.
1.2
Architettura all-in-MORGAN
In Fig.2 è possibile vedere la configurazione dell’architettura all-in-MORGAN:
in essa, come detto in precedenza, la rete overlay comprende tutti i nodi comunicanti: ciò significa che sia il mittente (client) sia la destinazione (server)
devono avere nel loro stack protocollare lo stato MPLS-over-IP per poter
inoltrare direttamente i pacchetti nella rete overlay. Quest’architettura comprende la configurazione TOR-like descritta in precedenza. Il vantaggio di
quest’architettura è che, considerando i meccanismi di Traffic Flow Confidentiality sottostanti allo strato MPLS-over-IP, un eventuale attaccante che
osserva i capi della rete (subito dopo A e prima di B) non riesce a portare
avanti un attacco di traffic analisys per correlare il traffico da A diretto verso
B.
3
Capitolo 2
Architettura TOR-like:
strategie d’ingresso
2.1
Proxy d’ingresso
Considerando l’architettura della rete di anonimizzazione TOR[1], si potrebbe utilizzare un proxy sul primo nodo del path overlay, che inoltra le richieste
TCP (e UDP) in modo anonimo attraverso la rete di anonimizzazione.
La soluzione migliore, affinché siano supportate la maggior parte delle applicazioni TCP-based senza modifiche, è quella di usare un’interfaccia proxy
basata su SOCKS[2]: SOCKS è un protocollo che convoglia delle sessioni
TCP per permettere alle applicazioni un accesso trasparente attraverso il firewall. Poiché SOCKS è indipendente dalle applicazioni, può essere usato da
più protocolli di strato applicativo.
Il protocollo SOCKS fornisce una generica interfaccia per i proxy TCP. Il
client si connette ad un SOCKS server con una connessione TCP, e richiede una connessione TCP su un altro socket verso un application server. Il
SOCKS server stabilisce la connessione, e comunica il successo o il fallimento
al client. Dopo che la connessione è stata stabilita, l’applicazione del client
comunica con server attraverso socket stabilito con il proxy.
2.1.1
SOCKS client
L’utente che vuole comunicare in modo anonimo, deve avere un client SOCKS
che permette di inviare le richieste SOCKS verso il nodo d’accesso alla rete di
anonimizzazione. Una buona soluzione (in caso di traffico HTTP, utilizzata
anche in TOR) è l’utilizzo di Privoxy [3]: Privoxy è un web proxy che ha
capacità di filtraggio per la protezione della privacy. Privoxy viene installato
4
sul client e quando viene usato ne intercetta le richieste HTTP, rilanciandole
attraverso il protocollo SOCKS verso un punto d’ingresso della rete overlay.
2.1.2
SOCKS proxy, nodo d’ingresso nella rete overlay
Come detto in precedenza, il SOCKS proxy è situato nei punti d’ingresso
della rete di anonimizzazione. Supponendo che il path sia già stato costruito
attraverso i nodi overlay (in seguito verranno fatte delle considerazioni sulle
funzionalità richieste al protocollo di segnalazione per il path setup), il proxy,
al giungere di nuove connessioni TCP da diversi client deve:
1. contattare attraverso la rete di anonimizzazione l’application server per
l’apertura di un nuovo socket;
2. comunicare al client il socket su cui comunicare oppure il fallimento
della richiesta;
3. effettuare un mapping consistente dei flussi informativi provenienti dagli utenti in distinti flussi informativi verso il server e mappare questi
ultimi in corrispondenti circuiti (o stream, vedi quarto capitolo) nella
rete si anonimizzazione, apponendo tag MPLS diverse ai vari flussi dati
e viceversa.
L’ultima operazione è fondamentale per l’ingresso nella rete di anonimizzazione del flusso TCP: il mapping dovrebbe essere effettuato tra source port
del pacchetto TCP e tra TAG MPLS che identifica il flusso tra i nodi overlay.
In seguito verrà descritto un possibile modo per multiplare più connessioni
TCP all’interno di un unico path.
2.1.3
Note sul path setup e sul protocollo di segnalazione
Fin’ora è stato ipotizzato che quando il client vuole effettuare una connessione in modo anonimo attraverso la rete overlay, esso trovi già un path formato
attraverso di essa; il protocollo di path setup che ha il compito di istituire i
circuiti cirtuali nella rete di anonimizzazione dovrebbe essere scatenato preventivamente, istituendo cosı̀ dei path prima che qualsiasi flusso sia inoltrato
in modo anonimo (situazione possibile nei casi di flussi diretti verso server più
trafficati con più richiesta di connessioni anonime), oppure al momento delle
richieste di connessione di un client verso un SOCKS proxy, nel caso in cui
un path verso la destinazione desiderata non sia disponibile: in quest’ultimo
caso il path setup ha origine nel primo nodo della rete overlay e inizia dopo
5
la richiesta di un socket da parte del client (CONNECT request) e prima del
rilascio da parte del SOCKS proxy del socket al client (CONNECT reply).
2.2
Gateway d’ingresso
In questo scenario un nodo d’ingresso nella rete overlay è un gateway per il
client verso l’application server. Se il nodo d’ingresso è situato nella stessa
sottorete IP di A non ci sono problemi, se invece è localizzato in un qualsiasi
punto di internet, esso può essere raggiunto tramite una VPN e impostato
come gateway dal client verso il server. Questa soluzione risulta più facile da implementare all’interno del kernel del sistema operativo rispetto la
precedente, ma anche meno flessibile per un utente finale, che dovrebbe modificare la tabella di routing per forzare il transito dei pacchetti diretti verso
una certa destinazione attraverso la rete di anonimizzazione.
GATEWAY
R1
A
Rete Overlay
Tunnel cifrato
Fig.3: Gateway verso la rete overlay
6
Capitolo 3
Uscita dalla rete MORGAN:
overlay addresses
L’introduzione di uno strato protocollare tra TCP/UDP e IP introduce dei
problemi nel transito dei pacchetti IP di risposta dal server verso il client, in
particolare è critico l’hop in cui i pacchetti IP rientrano nel circuito overlay
al’exit node della rete di anonimizzazione: quando una risposta giunge da
un application server all’exit node del path su cui è giunto il pacchetto proveniente dal client, lo strato MPLS non ha elementi sufficienti per apporre
al pacchetto la tag MPLS che identifica il circuito di ritorno da attraversare
nella rete di anonimizzazione. Infatti, anche se l’application server all’esterno
della rete overlay risponde a richieste di più client,(che possono provenire da
diversi path all’interno della rete di anonimizzazione), gli indirizzi IP su cui
il server apre il socket sono sempre quelli del server stesso e dell’exit node.
Per risolvere questo problema è stato introdotto il concetto di overlay address: un indirizzo IP overlay non è coinvolto per il normale instradamento
dei pacchetti a livello di rete, ma viene utilizzato solo per aprire un socket
sull’application server. Gli indirizzi overlay possono essere espliciti, ossia
viaggiano con il pacchetto all’interno della rete MORGAN e scelti dal client
o negoziati tramite un protocollo di segnalazione, o impliciti, cioè memorizzati in un database all’interno dell’ultimo nodo (exit node) nella rete overlay,
e gestiti unicamente da quest’ultimo. L’utilizzo e il trasporto degli indirizzi
overlay verranno esaminati successivamente in questo capitolo.
3.1
Problema delle risposte
In uno scenario in cui si ha lo strato MPLS direttamente sopra IP (con TAG
apposta tra l’header IPsec/ESP, e TCP/UDP), senza ulteriori accorgimenti
7
(ossia senza considerare l’uso di indirizzi overlay), nell’ultimo nodo del path
della rete di anonimizzazione (Rn ) avvengono le seguenti operazioni:
• nel caso di architettura TOR-like:
1. arriva una pacchetto facente parte di un certo path overlay con
IPsource=(Rn−1 ), IPdest=(Rn ) e label=X;
2. il nodo (Rn ), consultando il database di ILM (Incoming Label
Map) vede che è un pacchetto MPLS valido e quindi, per prendere
decisioni sull’inoltro del pacchetto, consulta la NHLFE associata
(Next Hop Label Forwarding Entry) e vede che il pacchetto deve
uscire dalla rete di anonimizzazione ed è diretto verso B;
3. il pacchetto viene inoltrato verso B con IPsource=(Rn ) e IPdest=B;
4. B, dovendo inoltrare una risposta al pacchetto ricevuto in precedenza attraverso la rete di anonimizzazione, manda un pacchetto
verso (Rn ) con IPsource=B e IPdest=(Rn ); (Rn ) però non riesce
a inoltrare la risposta nella rete overlay se più path terminano in
esso e sono diretti verso B;
• nel caso di architettura all-in-MORGAN:
1. il nodo (Rn ), consultando il database di ILM (Incoming Label
Map) vede che è un pacchetto MPLS valido e quindi, per prendere
decisioni sull’inoltro del pacchetto, consulta la NHLFE associata
(Next Hop Label Forwarding Entry) e vede che il pacchetto deve
uscire dalla rete di anonimizzazione ed è diretto verso B;
2. il pacchetto viene inoltrato verso B con IPsource=(Rn ), IPdest=B
e label=Y;
3. in un’architettura all-in-MORGAN nel nodo B gli strati applicativi aprono un socket con la coppia di indirizzi IP di (Rn ) e di B:
quando devono rispondere inoltrano un pacchetto verso gli strati
protocollari inferiori con tali indirizzi inconsapevoli della presenza
dello strato MPLS; giunto ad MPLS, non si potrebbe prendere una
decisione per l’inoltro di tale pacchetto nel caso più path terminino
nel nodo B.
8
ULTIMO NODO OVERLAY Rn
NODO FINALE B
APPLIC.
MPLS
IP/IPsec
TCP/UDP
IP
Richieste anonimizzate verso B da due path diversi
IP
Uscita dalla rete di anonim.
Rn
Rn-1
X
Payload 1
B
Rn
Payload 1
Rn
Rn-2
W
Payload 2
B
Rn
Payload 2
PROBLEMA:
come inviare sui due
path diversi le risposte?
Risposte di B
Rn
B
Risposta 1
Rn
B
Risposta 2
B
Risposta 1
Fig.4:Risposte nel caso TOR-like
ULTIMO NODO OVERLAY B
APPLIC.
TCP/UDP
B
Rn
B
Payload 1
Rm
Payload 2
Rn
Rm
MPLS
IP/IPsec
PROBLEMA:
come inviare sui due
path diversi le risposte?
Richieste anonimizzate verso B da due path diversi
B
Rn
X
Payload 1
B
Rm
W
Payload 2
Fig.5:Risposte nel caso tutti che i nodi siano nella rete di anonimizzazione
9
B
Risposta 2
3.2
Soluzione: indirizzi overlay
Il problema nell’ultimo nodo è quindi il non riuscire a discriminare le risposte
nei path di ritorno della rete di anonimizzazione. Se nel nodo di destinazione
gli strati applicativi riuscissero ad aprire dei socket con coppie di indirizzi diversi a seconda del path e del mittente nella rete di anonimizzazione,
il problema delle risposte nell’ultimo nodo sarebbe risolto. La soluzione sta
nell’utilizzare degli indirizzi nell’apertura dei socket, non coinvolti nel routing
a livello IP, ossia degli indirizzi overlay (indirizzi IP utilizzati al di sopra dello
strato di rete). Tali indirizzi sono unicamente coinvolti nell’ultimo nodo, in
quanto servono solo per poter inoltrare correttamente le risposte all’interno
della rete MORGAN, e possono essere espliciti, ossia trasportati lungo tutta
la rete all’interno dei pacchetti che viaggiano in modo anonimizzato, o impliciti, memorizzati solamente all’interno di database contenuti nei router overlay. In seguito verranno esaminate le precedenti modalità di indirizzamento
overlay ed il trasporto, nel caso si usi la modalità esplicita, degli indirizzi
overlay all’interno delle unità informative nella rete di anonimizzazione.
3.2.1
Indirizzamento overlay esplicito
In questa modalità di indirizzamento overlay il primo nodo della rete di anonimizzazione, oltre a taggare il pacchetto con una specifica label MPLS, ne
appone all’interno uno specifico indirizzo IP overlay (o una coppia di indirizzi) che rimarrà (o rimarranno) inalterati all’interno della rete fino all’ultimo
nodo overlay (potrà anche viaggiare cifrato in caso si abbiano dei nodi overlay non fidati). Il numero di indirizzi overlay necessari affinché le risposte
possano rientrare correttamente all’interno della rete di anonimizzazione è
uno, ma se ne può prevedere una coppia in caso di utilizzi e sviluppi futuri
(ad esempio particolari funzionalità di routing in cui si vuole rendere noto
all’ultimo nodo uno specifico percorso da far eseguire al pacchetto nella fase di ritorno). Con almeno un indirizzo overlay esplicito si riesce ad aprire
un socket nell’ultimo nodo della comunicazione tra la coppia di indirizzi IPdest=B e IPsource=OverlaySourceAddress, dove quest’ultimo viene apposto
ai pacchetti di un certo flusso dal primo nodo della rete overlay. Per avere indirizzi overlay univoci nel nodo di destinazione, essi vengono assegnati
con il protocollo di segnalazione e path setup all’inizio della comunicazione
all’interno della rete di anonimizzazione. Nel path di ritorno, l’apposizione
della tag MPLS con la specifica label che identifica il percorso, dipenderà dal
particolare indirizzo overlay assegnato ai pacchetti di un certo flusso.
Nei seguenti esempi verrà esaminato l’uso dell’indirizzamento overlay esplicito, senza tenere in considerazione di come l’indirizzo (o gli indirizzi) overlay
10
è (sono) contenuto nel pacchetto.
Nel caso di un singolo indirizzo overlay, abbiamo che tale indirizzo viene
inserito nel pacchetto dopo la label MPLS dal primo dei nodi overlay della
rete di anonimizzazione. Nel punto di uscita della rete di anonimizzazione,
nel caso TOR-like, può o no sostituire l’indirizzo IPsource del pacchetto: la
prima possibilità si può considerare solo nella situazione in cui il nodo di destinazione B si trovi nella stessa sottorete dell’ultimo nodo Rn; ciò è dovuto
al fatto che nel ritorno se B risponde all’IPsource=OverlaySourceAddress, il
routing IP fino al nodo overlay Rn fallirebbe.
La soluzione migliore è nell’eseguire un’operazione di source NATting sull’ultimo nodo overlay verso la destinazione B (MASQUERADING): in questo
caso, all’interno del nodo Rn prima viene fatta la sostituzione dell’indirizzo
IP sorgente del pacchetto con l’indirizzo overlay, poi viene NATtato con il
MASQUERADING, sostituendo l’indirizzo IP sorgente (rappresentato dall’indirizzo overlay) con l’indirizzo IP dell’interfaccia di rete verso B (sfruttando poi in numero di porta TCP per discriminare le risposte provenienti da
B); un procedimento molto simile viene utilizzato nell’indirizzamento overlay
implicito.
In uno scenario in cui tutti i nodi comunicanti sono compresi nella rete di
anonimizzazione, si può ipotizzare che una coppia di indirizzi overlay viaggi
all’interno del pacchetto anonimizzato: il nodo finale B aprirà un socket verso il primo nodo su questa coppia di indirizzi e la label che verrà apposta nel
pacchetto di ritorno dipenderà da tali indirizzi (gli indirizzi IP del pacchetto
di risposta anonimizzato saranno ovviamente quelli di B e del primo router
overlay che si incontra nel path di ritorno).
ULTIMO NODO OVERLAY Rn
B
MPLS
IP/IPsec
Rn
Rn-1
X
O
O
IP
Payload
Payload
MASQUERADING
B
Rn
Payload
VERSO IL NODO B
O: Indirizzo overlay
Fig.6:Indirizzamento overlay esplicito nello scenario TOR-like
11
ULTIMO NODO OVERLAY B
APPLIC.
TCP/UDP
Od
Os
MPLS
Payload
Os
Od
Rn
B
Risposta
IP/IPsec
Da Rn
B
Rn
X
Od
Os
Payload
Y
Os
Od
Risposta
Verso Rn
Fig.7:Indirizzamento overlay esplicito nello scenario All-in-MORGAN
3.2.2
Indirizzamento overlay implicito
L’indirizzamento overlay implicito è una modalità di indirizzamento a livello
overlay possibile in uno scenario del tipo TOR-like: l’indirizzo overlay non
esce mai dall’ultimo nodo della rete di anonimizzazione ed è legato al gruppo
di label del path overlay usato dal pacchetto per giungere al Rn: si ha infatti un database con le corrispondenze Label-SourceOverlayAddress. Viene
sfruttato anche in questo caso il NAT, in particolare in MASQUERADING,
verso l’indirizzo di destinazione. I passi applicati all’ultimo router overlay
alla ricezione di un pacchetto taggato MPLS sono i seguenti:
• confronto con le ILM memorizzate nel nodo e accettazione del pacchetto;
• lettura della NHLFE collegata alla ILM corrispondente al pacchetto
ricevuto;
• sostituzione dell’indirizzo IP destinazione del pacchetto con quello di
B e dell’indirizzo IP sorgente con l’indirizzo IP overlay presente nella
NHLFE corrispondente alla label del pacchetto ricevuto;
• invio del pacchetto sull’interfaccia di uscita;
• NATting dell’indirizzo overlay con l’indirizzo IP dell’interfaccia di uscita verso B (MASQUERADING)
12
3.2.3
Posizionamento degli indirizzi overlay all’interno
del pacchetto
Il posizionamento degli indirizzi IP overlay all’interno di un pacchetto che
viaggia attraverso la rete di anonimizzazione può essere effettuato secondo
due modalità:
• formato proprietario del pacchetto: l’indirizzo (o la coppia di indirizzi)
overlay segue (o seguono) la TAG MPLS successiva all’header IPsec
(ESP). Questa è la soluzione che permette il maggior risparmio possibile
di bit all’interno di un pacchetto, ma in contropartita occorre introdurre
un formato non standard dei protocolli contenuti nel pacchetto;
• incapsulamento IP-in-IP: gli indirizzi overlay sono contenuti in un header IP che segue la tag MPLS. Il vantaggio potrebbe essere rappresentato dal fatto che un’header IP completo che segue la tag MPLS potrebbe
essere sfruttato in sviluppi futuri del routing overlay in MORGAN; si
ha una maggiore ridondanza all’interno di un pacchetto. Quest’ultimo
problema potrebbe essere risolto da un algoritmo di compressione del
solo header IP (overlay).
3.3
Ritorno della connessione verso il client
Se viene adottato il NAT (MASQUERADING) nell’exit node della rete overlay, quando i pacchetti di risposta giungono dall’application server, l’indirizzo
dell’interfaccia verso il server che ha mascherato l’indirizzo overlay, viene risostituito da quest’ultimo.
Per la ri-immissione su un path di ritorno attraverso la rete, occorre che la
policy per il tagging del pacchetto abbia come parametri l’indirizzo overlay
del client e l’indirizzo IP dell’application server: la label che identifica il circuito di ritorno e gli indirizzi IP da apporre al pacchetto saranno in relazione
biunivoca con i parametri detti.
Il path di ritorno, indipendente da quello di andata, dovrà necessariamente
terminare sul nodo di ingresso della rete dove è localizzato il SOCKS proxy
che si affaccia verso il client.
13
Capitolo 4
Multiplazione di più flussi
all’interno di un path overlay
Rispetto a quanto descritto nell’architettura di TOR [1], anche all’interno
dell’architettura di MORGAN dovrebbe essere possibile multiplare all’interno di un unico path più flussi dati (connessioni TCP o flussi di datagrammi
UDP), appartenenti ad uno o più client che si connettono ai proxy SOCKS
sul perimetro della rete di anonimizzazione.
Per fare ciò, si può sfruttare la definizione di label stack all’interno dell’architettura protocollare di MPLS [4]: “It is useful to have a more general
model in which a labeled packet carries a number of labels, organized as a
last-in, first-out stack. We refer to this as a label stack.”. Si può adattare
la definizione di MPLS-label-stack per multiplare più flussi TCP all’interno
di un unico path nella rete di anonimizzazione: il nodo d’ingresso del path,
che si interfaccia con i client attraverso il proxy SOCKS, esegue il tagging
del pacchetto con un label stack composto da due label MPLS, la più esterna
che rappresenta il circuito nel quale il flusso deve viaggiare nella rete overlay,
e la più interna che rappresenta il flusso che può essere multiplato all’interno
di un path.
La label più interna deve essere in relazione uno ad uno con il flusso in uscita
dal proxy SOCKS ed in essa viene mappato tale flusso; tale label deve essere letta solo dall’exit node della rete overlay e deve essere in relazione con
l’indirizzo overlay che deve essere poi nattato in uscita dal nodo. Il valore
della label interna può essere deciso unicamente dal nodo di ingresso oppure
contrattato dal nodo di ingresso e l’exit node: lo svantaggio nel primo caso
è che si rischia la collisione nell’exit con uno stesso valore assegnato da un
altro nodo d’ingresso mentre nel secondo caso con una contrattazione si può
compromettere la sicurezza del sistema.
Il vantaggio principale derivante da questa soluzione è che i path all’inter14
no della rete di anonimizzazione sono indipendenti dai flussi di dati che li
attraversano, ossia che:
• i valori delle label che identificano i circuiti overlay non dipendono dai
flussi dati che li attraversano;
• l’indirizzo overlay assegnato per uscire dalla rete di anonimizzazione
dipende solo dal flusso uscente, quindi è solo in relazione con la label
più interna e non con tutte le label che identificano il circuito;
• i path tra i nodi overlay possono anche essere costruiti preventivamente.
15
Capitolo 5
Working in progress
Questa è una lista di idee che si vogliono sviluppare e inserire all’interno
dell’architettura di MORGAN:
• utilizzo di più punti d’ingresso e di uscita nella rete overlay per un
unico flusso dati: con l’attuale architettura è possibile che un flusso
informativo all’interno della rete overlay segua percorsi completamente
differenti in andata e ritorno dal client, compresi però, sempre tra un
nodo d’ingresso e un nodo di uscita. Si vuole sviluppare un’architettura
che permetta il ritorno di un flusso all’interno la rete overlay tramite
un nodo che non coincida necessariamente con l’exit node dal quale
è uscito il flusso in andata e l’uscita del flusso di ritorno da un nodo
che non coincida necessariamente con il punto d’ingresso del flusso in
andata;
• sviluppo dell’architettura “leaky pipe” [1]: tramite l’uso di uno stack di
label MPLS, fare in modo che gli strem dati multiplati in un path nella
rete overlay possano avere a disposizione più uscite dalla rete lungo tale
path;
• definire le specifiche del protocollo di segnalazione e di path setup.
16
Bibliografia
[1] Roger Dingledine, Nick Mathewson, Paul Syverson. “Tor: The SecondGeneration Onion Router ”, In the Proceedings of the 13th USENIX
Security Symposium, August 2004
[2] NEC, SOCKS: A protocol for TCP proxy across firewalls
[3] www.privoxy.org
[4] IETF, RFC 3031 “Multiprotocol Label Switching Architecture”,
www.ietf.org
17