Dopo tanti anni, c’è sempre più attività su IPv6. Ho l’impressione che presto sarà raggiunta la massa critica per un’effettiva transizione a IPv6. Transizione che dovrebbe avere almeno un grosso vantaggio: liberarci di quel terribile accrocchio che è il NAT. Devo dire che se l’unico motivo per passare a IPv6 fosse aumentare il numero di indirizzi disponibili, mi sembra che ci sarebbero state strade molto più semplici. Appena avrò tempo cercherò di rinfrescarmi le idee.
Comunque sia, deve essere affrontata la fase di transizione, e in particolare di un gran numero di sistemi che sono dietro a un firewall/router IPv4 che fa NAT, cosa che blocca buona parte dei protocolli pensati per la convivenza (temporanea) fra IPv6 e IPv4. In particolare blocca quelli pensati per far parlare reti che supportano IPv6 attraverso un’infrastruttura che supporta solo IPv4. Ci ha pensato Microsoft, con un protocollo che si chiama Teredo, che ha seguito le vie corrette (una volta tanto), diventando “Standards Track”, RFC 4380. Sostanzialmente Teredo prevede l’incapsulamento dei pacchetti IPv6 in paccetti UDP. L’utilizzo di UDP permette di sfruttare le funzionalità già presenti nei router/firewall con NAT stateful, che prevedono di mantenere, almeno per un certo tempo, le mappature del NAT per il protocollo UDP, permettendo quindi il traffico entrante. Il traffico IPv6 viene poi estratto da UDP sulla rete IPv6 da router che supportano entrambi gli stack (Teredo Relay), mentre le attività di contrattazione vengono gestite da altri sistemi specializzati (Teredo Server). Nel complesso il protocollo non sembra male. Tuttavia, incapsulare pacchetti IP generici in UDP per far attraversare, su UDP e su porte effimere, il router/firewall, ha buone probabilità di permettere di aggirare le politiche del firewall. Il tutto è discusso in un papero di James Hoagland, un ricercatore di Symantec, del quale sono venuto a conoscenza attraverso Heise., ma anche nelle Security Considerations dell’RFC 4380. Si tratta di un problema generale dei meccanismi di tunneling e incapsulamento: se un tunnel permette di superare un meccanismo di protezione, allora riuscire a infilare qualcosa nel tunnel garantisce di aggirare quelle protezioni. Infatti, alcuni problemi sono simili a quelli descritti nell’RFC 3489. Dato che Teredo non è pensato con per creare una VPN fra specifici sistemi autenticati, ma per interfacciare con l’intera Internet IPv6, i problemi possono essere parecchi. Inoltre, ci sono altri attacchi che si possono immaginare in situazioni simili: DoS, man-in-the-middle ecc. Non riesco a valutare quanto tutti gli attacchi descritti saranno praticabili nella realtà, ma alcuni, fra cui il superamento di firewall e il sovraccarico di alcuni nodi, mi sembrano molto realistici. Dato che Teredo è supportato da XP con SP2 e da Vista (su Vista è attivato di default) e quindi probabilmente avrà un peso notevole nella transizione a IPv6, è bene che i suoi problemi di sicurezza vengano analizzati con cura.
