IPv6 nell'INFN
esperienze nelle sezioni

Francesco Prelz

INFN, sezione di Milano

(per conto del gruppo d'interesse per IPv6)

Sommario

• Sezioni pilota: come, dove, quando
• Cose che tutte le sezioni non dovrebbero ignorare
  • Ad esempio il World IPv6 day.
• Cosa vogliamo fare con IPv6 ?
• Cambiamo domanda: cosa vogliamo fare con...
• Transizione: quando ?
• Transizione: come ?
• Tunnel IPv6: non ce ne facciamo nulla
• Opzioni per la gestione dello spazio di indirizzamento
• Opzioni per l'autorizzazione degli accessi
• Evoluzione dei tool di monitoring
• Conclusioni

Sezioni pilota: come, dove, quando

• Sezioni con peering IPv6 attivo (in ordine di tempo):

  1. Catania (2006 - EuChinaGrid)	2. Roma 3 (2006 - EuChinaGrid)
  3. Milano (2008) - MX su IPv6 dal 2010	4. Milano Bicocca (2011) - MX su IPv6

• La lista potrebbe essere incompleta: solo il GARR possiede 'authoritatively' queste informazioni.
• Il piano di indirizzamento per l'INFN è finalizzato, e risiede tutto nel prefisso 2001:760:4200::/40.
• Attendiamo con ansia il CNAF!
• E' da poco iniziata ufficialmente l'attività di un gruppo IPv6 in HEPix. La prima conferenza telefonica settimanale (sigh) sarà il prossimo 26 Maggio.
  • Uno degli obiettivi è identificare i tempi di una possibile transizione (Es: LHC shutdown nel 2013? Pare presto.).
  • Un altro obiettivo è stabilire un testbed pan-europeo.

Cose da non dimenticare (1)!

• IPv6 viene già parlato sulle nostre reti. Provate a pingare l'indirizzo multicast 'all-nodes' (ping6 -I ethXX ff02::1). Quante risposte contate ?
  Ecco la statistica di Neighbour Discovery in una sezione piccola (Milano Bicocca) nelle scorse settimane (courtesy L. Carbone):
  

Cose da non dimenticare (2)!

• Ci sono alcune raccomandazioni presentate a CCR già a partire da Settembre 2008, da seguire per evitare la creazione di tunnel indesiderati.
• Specialmente in vista del prossimo 8 Giugno, World IPv6 day, è pure utile avere acceso su tutti i segmenti di rete un servizio per annullare i 'Rogue Router Advertisements', come ramond .
  ramond non annulla le rotte create secondo RFC4191, ma stiamo provando una patch che corregge questo, e abbiamo preparato anche alcune note di configurazione.
  Un'alternativa è 6MON del CNR di Pisa ("altamente sperimentale").

Perché tutto questo ?

Cosa vogliamo fare con IPv6 ?

• La domanda non è mai scontata.
• La tendenza nella formulazione di IPv6 è stata quella di incorporare nel protocollo varie applicazioni che con IPv4 vengono con varia fortuna realizzate sopra o attorno il livello di trasporto:
  • Neighbor discovery (addio ARP)
  • Authentication
  • Encryption
  • Host and network mobility
• Ne risulta una certa irriducibile complessità strutturale del protocollo. Ci torna qualcosa in tasca da questo, oltre alle possibili vulnerabilità?

O meglio, cosa vogliamo fare con:

• Deployment di IPsec:
  Quando e perché è utile implementare autenticazione e crittazione al livello 3 ? Sappiamo che abbiamo applicazioni (e relative 'trust root') utili al livello 2 ed ai livelli >= 4.
  • Forse non è solo un sintomo della proliferazione di specifiche e RFC dell'IETF variamente sponsorizzate e mai implementate.
• Applicazioni di mobilità INFN- o GARR-wide ?
• Ci interessano ?
• Se si, verranno fatte anche queste a livello 3 oppure con IEEE 802.16?
• Applicazioni di indirizzi anycast ?
• Protezione del riconoscimento esterno degli host (ping o port sweep).
• Protezione della risoluzione locale degli indirizzi sulle nostre reti.
• Cosa facciamo oggi per tutelarci da ARP poisoning o DHCP spoof ?
• Quanto temiamo normalmente oggi il nemico all'interno ?

Transizione: quando ?.

Attivazione del peering con il GARR e abilitazione del DNS sono attività semplici, che chiunque può fare anche ora, volendo. E' necessario iniziare dai servizi: l'abilitazione in dual-stack dei server SMTP registrati come MX per la sezione è altrettanto semplice, e quasi priva di effetti collaterali. Ma quando si può raccomandare una attivazione generalizzata? L'applicazione 'killer' che funziona solo con IPv6 probabilmente non comparirà mai: Ma una volta attivato IPv6, anche in dual-stack, tutte le applicazioni utili servite via IPv6 devono funzionare efficientemente. Le scadenze tassative (Es: DOE) aiutano ?

% connessioni SMTP via IPv6 Crescita al I ordine: 0.06 % al mese Simile alle statistiche IPv6 di Google.

Scenario di transizione: dual stack ovunque.

Scenario di transizione: host solo IPv6 ? (1)

Scenario di transizione: host solo IPv6 ? (2)

Tunnel IPv6: non ce ne facciamo nulla.

• Esistono tecnologie inventate per facilitare la transizione a IPv6 in assenza di accesso nativo. Ad esempio:
  • 6to4 consente di accedere alla rete IPv6 globale stabilendo un tunnel verso l'indirizzo anycast IPv4 192.88.99.1. Banale da utilizzare su molti sistemi, Windows incluso.
  • Teredo Permette di accedere alla rete IPv6 globale anche dietro un NAT, inviando il traffico via UDP a server noti (normalmente sulla porta 3544, ma una infrastruttura simile ma non ufficiale ne potrebbe usare altre).
  • Tunnel brokering su www.sixxs.net, che promuove attivamente la transizione a IPv6 offrendo indirizzi pubblici a chiunque lo richieda.
• Sono tecnologie intrinsecamente vulnerabili a denial-of-service, spoof, redirect.
• Non ci servono: chi ha bisogno di IPv6 può semplicemente richiedere l'attivazione al GARR. Dunque è essenziale filtrare questo traffico sui nostri router di frontiera.

Gestione degli indirizzi IPv6

• Esistono meccanismi per rendere la configurazione del livello di trasporto semplice, automatica ed indolore (?):
  • Autoconfigurazione stateless o SLAAC (sostanzialmente: gli host aggiungono il loro MAC address ad un prefisso inviato in multicast dal router)
  • Autoconfigurazione stateful o DHCPv6 (i clienti vengono identificati da due numeri generati a runtime: DUID che identifica l'host e IAID che identifica l'interfaccia)
• Questi meccanismi non consentono di implementare (neanche in IPv4...) i criteri di legittimazione ed autorizzazione dell'accesso a cui dobbiamo soddisfare.
• Richiedono comunque di prevenire efficacemente che vari dispositivi ottengano accesso IPv6 non autorizzato al mondo.
• Non vietano di continuare ad utilizzare la configurazione manuale degli indirizzi...

Autorizzazione dell'accesso

• Trasposizione del modello odierno:
  • Configurazione manuale del DNS, assegnazione manuale di un indirizzo IPv6.
  • Aggiornamento manuale di ACL che permettono il traffico dei soli indirizzi IPv6 assegnati.
• Altre opzioni:
  • IEEE 802.1x imposto ovunque ?
  • IPSEC ovunque (ma potrebbe non bastare o non essere l'approccio giusto per sicurizzare la neighbor discovery, vedi ad esempio RFC3971) ?
  • Con quali trust anchor ? AAI ?
• Se tutto fosse sicurizzato ci fideremmo anche dei protocolli di aggiornamento automatico del DNS ?

Nuovi tool di monitoring

• Si pone il problema di aggiornare gli strumenti di monitoring di rete che operano a livello 3.
• Aggiornamento lento, dettato dal mercato (o dalla sua perdurante assenza)...
• L'attuale sostituto morale di ARPwatch, NDPmon ha iniziato ad essere sviluppato nel 2006, e ora immagazzina le associazioni in un file XML e manda rapporti via syslog ed e-mail.
• Il successore di Nessus, OpenVAS ha aggiunto il supporto iniziale a IPv6 a Dicembre 2009 nella versione 3.0.0.
• Di ramond oppure 6MON, abbiamo già parlato.
• E' difficile pensare ad una messa in produzione di IPv6 senza installare ed integrare prima strumenti aggiornati di questo tipo. Stiamo iniziando ora a farne timidamente esperienza.

Conclusioni

• Ci sono alcune azioni che tutti dovrebbero aver fatto o fare, idealmente entro il prossimo 8 Giugno (World IPv6 day).
  1. Proteggersi contro la creazione di Tunnel IPv6 indesiderati.
  2. Attivare un servizio come ramond oppure 6MON perlomeno sui segmenti di rete dove compaiono macchine degli utenti.
• Chiunque lo desideri può attivare il peering IPv6, configurare alcuni servizi di base (DNS, E-mail, web), e quindi unirsi agli entusiasti early-adopters.
• Ma per giungere ad una raccomandazione di adozione generalizzata bisogna risolvere ancora varie questioni aperte (allocazione degli indirizzi, strumenti di monitoring, tecnica di transizione).
• Non si possono sottovalutare gli aspetti di sicurezza, anche senza arrivare a visioni troppo pessimistiche: The coming IPv6 security disaster

Bibliografia

• Sean Convery, Darrin Miller (Cisco), "IPv6 and IPv4 Threat Comparison and Best-Practice Evaluation", Marzo 2004
• Scott Hogg, Eric Vyncke, "IPv6 Security", Cisco Press, December 2008, ISBN 1-58705-594-5
• US-CERT, "Malware Tunneling in IPv6", Maggio 2005: riprende il precedente.
• Microsoft, "IPv6 Security Considerations and Recommendations ", aggiornato a Febbraio 2008
• Tim Chown, Stig Venaas, Rogue IPv6 Router Advertisement Problem Statement, IETF Draft, Marzo 2009.
• RFC: 2373, 2375, 2460, 2463, 2765, 2766, 3041, 3315, 3971, 4862, 4966.