Il lento ma inesorabile passaggio a IPv6 ha visto gli esperti passare da grandi speranze a grandi preoccupazioni in merito alla sicurezza. Ma come spesso accade, la verità è nel mezzo.

Pensare a nuove vulnerabilità di sicurezza potrebbe suonare quasi offensivo in questi giorni quando i fortunati che hanno davvero più tempo a disposizione sono tentati di usarlo male anche sulla rete... La prima certezza che accompagna l’introduzione di IPv6 è però che il perimetro da proteggere nell’infrastruttura IT, hardware e software, si allarga. Qui una reazione salutare potrebbe essere quella di restringerlo accelerando la transizione verso IPv6 (che è lenta ma inevitabile: non ci sono ‘piani B’ per l’evoluzione di Internet) così che rimanga di nuovo una sola versione del protocollo e IPv4 si possa trattare come un residuo di siti e servizi- dinosauro in via di estinzione. Tuttavia, soprattutto in Italia, dove quasi tutti gli ISP paiono ancora ignorare IPv6 (GARR qui è ovviamente una eccezione esemplare!) e questa prospettiva sembra remota, i dinosauri paiono piuttosto altri.

Non ignorare IPv6 dovrebbe essere un dovere per tutti da anni, soprattutto per i responsabili della sicurezza: la grande maggioranza dei sistemi operativi e dei dispositivi di rete abilitano infatti automaticamente lo stack IPv6. In assenza di gestione, chiunque potrebbe inviare Router Advertisement (RA), causare la configurazione automatica di indirizzi IPv6 pubblici e dirottare facilmente il traffico IPv6. Dirottare quindi tutto il traffico da e verso quasi tutti i grandi fornitori di servizi e contenuti, il cui accesso IPv6 viene ora normalmente preferito a IPv4.

L’introduzione di IPv6 ha poi implicazioni sulla sicurezza che vanno oltre alla maggiore complessità di dover gestire un doppio protocollo di rete. Se le proprietà topologiche di una rete IP non cambiano, se non cambiano i protocolli di livello inferiore e superiore e quindi neanche i corrispondenti metodi di attacco, ci sono alcune caratteristiche specifiche di IPv6 (riassunte anche nella figura) che hanno impatto diretto sulla sicurezza.

Il cambiamento più rilevante può non essere ovvio a prima vista, dopo tutto la sostituzione di un protocollo di trasporto dovrebbe essere trasparente, o quasi. Una delle conseguenze dell’abbandono del meccanismo ARP (questa è una significativa miglioria nell’architettura di IPv6) è che ad ogni interfaccia accessibile sulla rete IPv6 pubblica, sono associati sempre almeno due indirizzi, uno valido sulla rete locale e uno globale. Questi si aggiungono agli indirizzi IPv4, se presenti. Quindi ogni dispositivo che stabilisce una connessione di rete deve ora sempre scegliere fra più indirizzi possibili, sia per l’origine che per la destinazione del traffico. Anche la scelta della versione del protocollo da usare (v6 o v4) può essere vista come un caso speciale di questa scelta. Molto spesso questa logica di selezione ha dovuto essere introdotta modificando o aggiungendo nuovo codice in regioni critiche. Nuovo codice, in aggiunta agli stack IPv6 dei vari apparati che vengono solitamente sviluppati ex-novo, che è sempre terreno vergine per chi è in cerca di vulnerabilità da sfruttare.

La novità più vistosa è senz’altro la delega al protocollo ICMP (v6) di tutte le funzioni di ricerca di servizi essenziali sulla rete locale: la ricerca degli host vicini, dei router, dei servizi di risoluzione dei nomi, ecc. Questo ha causato l’aumento dei tipi di messaggi e quindi la necessità di filtrare in modo opportuno quelli che potrebbero essere usati male. In questo ruolo allargato di ICMP spicca poi il fatto che vengono normalmente inviati in multicast, periodicamente e in modo asincrono messaggi che causano la configurazione delle rotte e anche la configurazione automatica degli indirizzi IPv6 pubblici o del server DNS. Questo richiede di considerare e trattare la possibilità che circolino messaggi di Router Advertisement (RA) malevoli, capaci, perché normalmente accettati ed applicati anche senza essere richiesti, di disabilitare velocemente un’intera rete.

Con il passare degli anni, l’obbligo di supporto di alcune funzioni (IPSec, Mobile IP, etc.) è stato fatto cadere per non introdurre complessità superflua. Rimane però il fatto che gli header IPv6 possono essere troppi per essere contenuti in un solo pacchetto. Per realizzare alcune funzioni di filtro e di firewall potrebbe quindi essere necessario raccogliere, ordinare e riassemblare più di un pacchetto, il che è intrinsecamente inefficiente. Viene almeno qui in aiuto il divieto di frammentare i pacchetti IPv6 in transito e il limite minimo alla dimensione massima trasmissibile (MTU) dei pacchetti, fissato in 1280 byte – sono queste le uniche novità che portano a una riduzione nelle vulnerabilità sfruttabili.

Le statistiche di contatto raccolte da Google sono impietose, specie nel confronto con gli altri paesi europei: Belgio (53%), Germania (48%), Francia (40%), UK (41%)

È sano che questa breve panoramica possa aver destato qualche preoccupazione, o la sensazione che per progettare IPv6 siano state usate troppe energie (e troppo tempo) nella speranza, forse vana, di evitare tutti gli errori del passato e prevedere quelli del futuro.

La conclusione però non può essere la tentazione di spegnere IPv6! Il suo uso su scala globale continua ad aumentare, il codice matura e in molti casi pratici l’assunzione implicita che il nuovo protocollo di rete funzioni almeno altrettanto bene del vecchio (da subito!) sta venendo soddisfatta. Ad esempio, l’accesso ai dati prodotti dall’acceleratore LHC al CERN, come è stato presentato alla conferenza CHEP 2019, avviene ora circa al 60% via IPv6, con crescita costante, e si cominciano a considerare seriamente scenari in cui IPv4 viene spento definitivamente, completando la transizione. È piuttosto il caso di continuare ad accompagnare e facilitare questo lungo processo con sano realismo e “risk management”.