Source Routing

Stiamo implementando un modulo del kernel per implementare il source routing come da standard IP.

Source Routing?

Il source routing (da non confondere con il policy routing di iproute2 ! ) è un routing che anziche' essere deciso hop-by-hop da ogni router vedendo la destinazione del pacchetto e consultando la propria tabella di routing, è deciso a priori dalla sorgente che genera il pacchetto.

In altre parole una sorgente può obbligare un pacchetto a transitare almeno attraverso alcuni router dati, oppure a transitare solo ed esclusivamente per i router che ha indicato. Nel primo caso si parla di loose source routing, nel secondo caso di strict source routing.

Alla base di tutto ci sono le opzioni di loose e strict source routing del protocollo IP. Per maggiori informazioni:

• http://www.networksorcery.com/enp/protocol/ip/option003.htm

• http://www.networksorcery.com/enp/default0904.htm

Normalmente le opzioni IP non vengono usate perche' la maggior parte dei router di Internet non le supporta. Linux e i dispositivi embedded basati su linux le supportano nativamente ma spesso non di default. Per abilitare il source routing basta dare il comando:

echo "1" > /proc/sys/net/ipv4/conf/all/accept_source_route 

Che c'entra col Wireless?

Supponiamo di avere una rete mesh con quattro nodi A-B-C-D fatta cosi':

      D--->Internet
     /
A---B
     \
      C--->Internet

in cui il nodo A si collega attraverso il nodo B connesso a sua volta a due nodi C e D che sono anche internet gateway ovvero due nodi connessi ad internet tipicamente attraverso un NAT. Quando A genera traffico verso internet, il nodo B smisterà i pacchetti di A verso C o D a seconda della propria tabella di routing, tuttavia se si utilizza OLSR questa tabella sarà calcolata dinamicamente e potrà variare nel tempo. Quando il nodo A genera traffico verso un sito internet e lo stato dei link B-C e B-D varia, il povero nodo A potrebbe assistere al fenomeno del cosiddetto route flapping ovvero all'interno della stessa connessione (supponiamo una connessione TCP) , una parte dei pacchetti arriverano al sito provenienti dal NAT del nodo D (quindi con IP sorgente del NAT del nodo D) e una parte provenienti da C (quindi con IP sorgente quello del NAT di C). Cio' non è buono perche' molti protocolli (tra cui pure TCP) hanno uno stato che è legato all'IP sorgente del pacchetto. Ad esempio TCP effettua un 3 way handshake iniziale verso un host. Se gli arriva un pacchetto proveniente da un altro IP, lo butta. UDP non mantiene lo stato ma protocolli che usano UDP, ad esempio SIP, si.

L'effetto macroscopico è che povero utente A "cadrà" frequentemente da Messenger, avrà difficoltà a fare download consistenti...insomma il fatto di avere ben due gateway internet gli creerebbe un disastro!

Le soluzioni per questo problema sono diverse:

• Non usare un protocollo di routing dinamico ed impostare le rotte statiche !!
• Dotare tutti i nodi di un IP pubblico e fare BGP
• Creare un tunnel verso l'internet gateway che di fatto vuol dire limitare la riconfigurabilita' automatica della rete ed equivale in pratica ad assegnare una rotta statica.

La quarta soluzione consiste nell'utilizzare il loose source routing assieme ad un modulo del kernel chiamato connection tracking che serve per capire quali pacchetti appartengono a quali connessioni (sessioni) ed è usato in praticamente tutti i NAT. Il connection tracking identifica la connessione e il loose source routing fa in modo che tutti i pacchetti di quella connessione transitino per lo stesso internet gateway. Dovesse andare giù il link associato a quell'internet gateway, le nuove connessioni saranno "tracciate" e fatte passare per l'altro internet gateway. Non solo. Piu si carica un gateway, e peggio va quel link. Questo sistema permetterebbe di fare load balancing tra i gateway inviando parte dei dati attraverso uno e parte attraverso l'altro

Implementazione

Per la precisione quello che stiamo implementando è un target di xtables (netfilter / iptables http://www.netfilter.org ) che aggiunge l'opzione loose and strict source routing ai pacchetti che matchano una determinata regola. Lo stiamo implementando in kernel space per ovvi motivi prestazionali in modo da poterlo poi far girare sui router con scarse capacità di calcolo: questo comporta una parte in userspace (una libreria condivisa ".so") e una parte in kernelspace (del codice da includere nel proprio kernel in maniera statica o caricandolo come modulo). L'obiettivo per ora e' almeno quello di aggiungerlo a xtables-addons che una collezione dei moduli di xtables aggiuntivi, facilmente installabili sulla propria macchina grazie a un sistema di patch automatico del kernel (ex Patch-O-Matic). Per scaricare il sorgente è sufficiente prenderlo dall'svn attraverso il comando

 svn co https://svn.ninux.org/svn/ninuxdeveloping/xtables-addons xtables-addons 

il modulo si chiama "SR".

• Basic Idea & SysAdm: ZioProto

• Kernel Hackers: Si_Mo OrazioPirataDelloSpazio lito