IPv6: l'altro 3% di Internet

Francesco Prelz

INFN, sezione di Milano

(per conto del disperso gruppo d'interesse per IPv6)

Sommario

1. Il mondo dopo il lancio globale di IPv6.
2. Principali differenze semantiche di IPv6.
   • Non permettono veramente alle applicazioni di essere agnostiche rispetto al livello di trasporto!
   • Anche una volta che venga trattata correttamente la differenza sintattica della diversa lunghezza dell'indirizzo.
3. Differenze del protocollo IPv6 rilevanti per la sicurezza.
4. Meccanismi di transizione: che fare da noi?
5. Conclusioni.

Il mondo dopo il lancio globale di IPv6 (1)

• 6 Giugno 2012: World IPv6 launch:

  Non si vede veramente un gradino... Ma è stata superata la soglia psicologica del (whopping) 3%. Statistiche da http://www.google.com/ipv6

Il mondo dopo il lancio globale di IPv6 (2)

• Fra i nostri contatti di rete le cose non vanno molto diversamente. Dal 2010 misuriamo la frazione di e-mail scambiati su IPv6 dai mailer della sezione di Milano:
  
  

Il mondo dopo il lancio globale di IPv6 (3)

Il mondo dopo il lancio globale di IPv6 (4)

• La situazione di RIPE probabilmente ispira la particolare situazione in Europa, con due paesi oltre il 10% di adozione a livello end-user:

  Statistiche da http://www. google.com/ipv6 Aggregate anche in http://6lab.cisco. com/stats/

Principali differenze semantiche di IPv6 (1)

• Perlomeno l'indirizzo link-local oltre agli eventuali altri a scope globale.
• ⇒ Per ogni comunicazione di rete deve essere scelto un indirizzo di origine ed un indirizzo di destinazione.
• Queste preferenze sono nuovi parametri di configurazione dei sistemi (in Linux: /etc/gai.conf e ip -6 addrlabel list).
• Un testo da non leggere prima di andare a dormire: RFC6724.
• Sparisce la nozione di indirizzo 'principale' associato ad una interfaccia di rete (salvo che nel caso di Mobile IP, per il quale viene preferito lo Home Address).
• La questione se preferire IPv4 o IPv6 è un caso particolare di questo problema.
  • Mantenere in modo indolore la preferenza per IPv6 è cruciale per non far deragliare il treno della transizione. La transizione a RHEL6 e derivati ha già mostrato un caso (socket in listen con PF_UNSPEC) in cui la preferenza per IPv6 viene meno, e con essa il funzionamento in dual stack.
  • La situazione è figlia diretta di due RFC: 4291 e 6724, ma a meno di non fare a meno degli stack di rete ibridi e/o correggere molte applicazioni non ha soluzione diversa dall'amendment di RFC6724.

Principali differenze semantiche di IPv6 (2)

• Può avvenire soltanto staticamente o via Router Advertisement, e questi ultimi sono messaggi multicast sulla rete.
  • Modello opposto a quello di DHCP, push vs. pull.
• I Router Advertisement, che devono provenire da una sorgente legittima sulla rete (in caso contrario si aprono gli scenari descritti in RFC6104), inducono tutti gli host collegati ad un segmento di rete:
  • Ad abilitare o meno l'autoconfigurazione dell'indirizzo di rete (bit autonomous nell'annuncio dei prefissi).
  • A cercare altre informazioni attraverso una query a DHCPv6 (bit managed e other nei Router Advertisement).
  • Ad aggiungere alla loro tabella di routing un numero arbitrario di rotte, fra cui quella di default.
• La rotta di default non può essere assegnata via DHCPv6.
  Sono ormai state bocciate cinque draft IETF (1, 2, 3, 4, 5) che proponevano di ripristinare questa funzione. Pare una battaglia persa.

Principali differenze semantiche di IPv6 (3)

• Oltre all'assegnazione manuale, sempre possibile, 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). Ma RFC6106, che permetterebbe di configurare i DNS via Router Advertisement, non pare essere ampiamente supportata.
  • 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). Come visto poco fa questo metodo non esenta dalla distribuzione dei Router Advertisement e quindi dalla protezione contro i rogue RA.
• Due esigenze fondamentali:
  1. Aggiornamento del DNS con la risoluzione inversa.
  2. Necessità di associare il traffico di rete ad un utente legittimo ed autorizzato (last-hop traceback).
     Art. 6 AUP GARR: "Tutti gli utenti a cui vengono forniti accessi alla Rete GARR devono essere riconosciuti ed identificabili".
• Ne riparliamo fra poco a proposito delle possibili strategie di transizione.

Differenze di IPv6 rilevanti per la sicurezza (1)

• RFC 4942 classifica tre ordini di caratteristiche (ma poi si concentra sul primo, visto che scrive agli estensori degli stack):
  1. Issues due to IPv6 protocol
  2. Issues due to Transition Mechanisms
  3. Issues due to IPv6 Deployment

Il protocollo richiede alle implementazioni di trattare extension header del protocollo per funzioni che in precedenza erano opzionali (IPsec, QOS, supporto per mobile IP) e reimplementa varie funzioni (DHCP, neighbor discovery, anycast, multicast). La comparsa di codice nuovo negli stack di rete è meravigliosa per chi è in cerca di vulnerabilità da sfruttare. Solo con l'avanzare dell'adozione e del tempo scopriremo quante ce ne sono.

Lo spazio di indirizzamento è più grande (128 bit - 340 undecilioni, 2120 indirizzi unicast teorici, 2112 indirizzi pubblici nella classe 2001:: già allocabili). Uno scan brute force è più laborioso, potrebbe essere saggio assegnare indirizzi non contigui, ma ci sono altri sistemi per trovare possibili target sulla rete locale. La collisione con indirizzi già allocati perde ogni efficacia (se mai ne ha avuta) nell'evidenziare accessi non autorizzati.

Differenze di IPv6 rilevanti per la sicurezza (2)

Molte funzioni utili al protocollo (Neighbor Discovery, MTU discovery, Mobility) vengono assorbite a livello 3 in ICMPv6. Dunque la comunicazione a livello 3 deve funzionare automaticamente almeno per macchine sullo stesso link. Molti tipi di messaggi nuovi in ICMPv6, ed una RFC (4890) dedicata solo a specificare regole di firewall minimali per gli accessi IPv6. L'operazione di Neighbor Discovery richiede un multicast locale. Ma ICMPv6 proibisce esplicitamente di rispondere a/amplificare richieste inviate a indirizzi multicast (es: FF02::1, all-link-local-nodes, FF05::2, all-routers, vedi RFC2373).

I dispositivi intermedi non possono frammentare i pacchetti. La MTU minima è di 1280 byte. Nessuno però impedisce alle implementazione degli stack di creare autolesionisticamente frammenti più piccoli.

Differenze di IPv6 rilevanti per la sicurezza (3)

	Ma... La grande quantità di header opzionali del protocollo potrebbe significare che il payload di livello superiore (con numeri di porta, ed altre informazioni utili per filtri e firewall) non si trova nel primo frammento e richiede di riassemblare i pacchetti.
	A conclusione e parziale giustificazione di questo (preoccupante?) elenco di differenze, ricordiamo le tensioni in gioco nella progettazione di IPv6: Recuperare la trasparenza interna del livello di trasporto (soppressione di qualunque elemento intermedio stateful: NAT, Firewall). Facilitare la configurazione automatica del livello di trasporto. Consentire applicazioni di IP mobile.

Della transizione: princìpi-guida.

1. I servizi su IPv6 devono funzionare da subito tanto bene quanto i loro equivalenti su IPv4:
   • ⇒ "IPv6 days" in cui si ha il permesso di rompere qualcosa.
   • ¬⇒ che l'indirizzo dell ambìto web server ec.europa.eu cominci ad essere risolto su IPv6 senza essere raggiungibile via IPv6, come avvenuto lo scorso 6 Maggio!
2. Occorre mantenere ovunque la preferenza per IPv6.
   • Ogni eccezione è un sassolino che rallenta il treno della migrazione.
3. Non bisogna avere fretta, ma agire proattivamente.
   • Gli strumenti di gestione della rete e di monitoring devono essere aggiornati.
   • Uno dei principali scenari problematici per la sicurezza è che le applicazioni vengano rappezzate in fretta e senza adeguata sperimentazione.
4. Occorre resistere allo scoraggiamento, la transizione sta avvenendo.
   • "At Google we believe IPv6 is essential to the continued health and growth of the Internet".
   • "Replacing the Internet's plumbing will take some time, but the transition has begun".

Meccanismi di transizione: che fare da noi? (1)

• Non esistono meccanismi di transizione IPv4/IPv6 che non richiedano di assegnare un indirizzo IPv4 pubblico (magari con NAT) alle macchine.
  A questo punto si può anche continuare a far passare il traffico IPv4.

Meccanismi di transizione: che fare da noi? (2)

• La curva di utilizzo su scala mondiale ha iniziato a salire più che linearmente, per la prima volta forse si può raccomandare alle sezioni INFN di pensare seriamente all'attivazione di IPv6.
  • Le informazioni per l'attivazione dell'accesso sono disponibili da anni su http://www.mi.infn.it/ipv6.
  • Nel prossimo talk sentiremo l'esperienza dei più audaci fra noi.
• Il problema principale da affrontare è, come visto, quello dell'assegnazione degli indirizzi IPv6, sia nel periodo di transizione che a regime, e della loro risoluzione nel DNS. Stanno venendo sperimentati due approcci complementari:
  • Milano-Bicocca: assegnazione stateless (SLAAC), monitoring del traffico di neighbour discovery con bigearpV6 e successivo aggiornamento del DNS e delle access-list.
  • Milano: assegnazione stateful pilotata dal DNS per le macchine dual-stack. Un plugin sperimentale a ISC-DHCP utilizza il MAC address estratto dal DUID delle richieste DHCPv6 (quando possibile).
    Viene quindi risolto il nome associato all'indirizzo IP nella risposta di ARP più recente per quel MAC e offerto via DHCPv6 l'indirizzo IPv6 (AAAA) eventualmente associato a quel nome.
• L'uso di IEEE 802.1x anche per le connessioni wired alla rete semplificherebbe lo spazio dei problemi (specialmente nella prevenzione di dispositivi rogue). Ce lo possiamo permettere?

Conclusioni

• Il treno della transizione a IPv6 è in moto, lento (ordine di un decennio?) ma inesorabile.
• L'adozione di IPv6 da parte degli utenti finali sta cominciando a crescere in modo più che lineare, siamo al 3% su scala globale.
• IPv6 ci richiede di aggiornare misure di sicurezza e e gli strumenti di monitoring, e di farlo senza fretta: che sia il momento di cominciare?
• Non esistono per ora meccanismi di traduzione di protocollo approvati che consentano di non avere un indirizzo IPv4 allocato per ogni host che deve fare traffico IPv4 (NAT-PT è stato deprecato in RFC4966), dunque il doppio stack rimane l'unico metodo di transizione ragionevole.
• Non abbiamo ancora nessuna soluzione magica del problema dell'assegnazione degli indirizzi per macchine dual stack, ma varie possibilità con pro e contro.
• Mettiamoci una mano sulla coscienza e saltiamo su questo treno in corsa: se non ci facciamo troppo male l'ovest ci attende.

Bibliografia

• Knowledge base del gruppo di lavoro IPv6 di HEPix: http://hepix-ipv6.web.cern.ch/knowledge-base.
• Scott Hogg, Eric Vyncke, "IPv6 Security", Cisco Press, Gennaio 2009.
• Microsoft, "IPv6 Security Considerations and Recommendations ", aggiornato ad Agosto 2011
• RFC: 2373, 2375, 2460, 2461, 2463, 2766, 3041, 3315, 3484, 3971, 4191, 4291, 4860, 4861, 4862, 4890, 4942, 4966, 6104. 6106. 6724.