Il DNS potrebbe risolvere i difetti di sicurezza del routing Internet? Nuove idee dall'IETF 126

L'Internet Engineering Task Force (IETF) si è riunita a Vienna a fine luglio 2026 per il suo 126° meeting, dove gli ingegneri di rete hanno affrontato sfide di lunga data su come il traffico internet trova la sua strada attraverso il globo. Al centro di queste discussioni c'era il Border Gateway Protocol (BGP), il sistema che le reti usano per annunciare quali indirizzi IP controllano e come raggiungerli. Sebbene spesso invisibile agli utenti comuni, le debolezze di sicurezza del BGP possono portare a dirottamenti del traffico, sorveglianza e interruzioni. Quest'anno è emersa una nuova idea: usare il Domain Name System (DNS) per portare fiducia negli annunci di routing.

Un argomento che ha attirato l'attenzione è stata la manipolazione inattesa dell'attributo ORIGIN del BGP. Quando un router ha più percorsi verso la stessa destinazione, utilizza un rigoroso processo decisionale in otto passaggi per scegliere il migliore. Dopo aver confrontato le preferenze locali e la lunghezza del percorso AS, guarda il codice ORIGIN, un'etichetta che doveva indicare come una rotta è entrata per la prima volta nel BGP. Le tre possibilità sono 'i' (appreso da un protocollo di routing interno), 'e' (dall'ormai obsoleto Exterior Gateway Protocol) e '?' (incompleto, tipicamente da rotte statiche). In teoria, questo codice non dovrebbe mai cambiare dopo essere stato impostato, ma i ricercatori della sessione IEPG hanno mostrato che alcune reti lo hanno riscritto. Modificando le rotte al valore 'e', costringono altri router a declassare determinati percorsi, sovrascrivendo il consueto confronto della lunghezza del percorso AS. Questa pratica è apparsa per la prima volta nel 2023 ed è cresciuta: le misurazioni ora vedono il valore di origine EGP in una percentuale notevole di annunci BGP. Un operatore ha apertamente ammesso di usare questo trucco per allontanare il traffico da router distanti, sfruttando la maggiore priorità di ORIGIN nell'algoritmo di selezione. Eppure, se ogni rete facesse lo stesso, il beneficio si annullerebbe, un classico caso di 'funziona solo se sono l'unico a farlo'.

Gli sforzi per aggiungere sicurezza crittografica al BGP sono in corso da oltre due decenni, ma i progressi sono stati lenti. L'attributo AS_PATH, che elenca la catena di sistemi autonomi (AS) attraverso cui passa una rotta, è particolarmente vulnerabile alla falsificazione. Soluzioni esistenti come BGPsec firmavano l'intero percorso ma faticavano con la distribuzione parziale: se un qualsiasi salto lungo il percorso non lo supportava, la catena di firme si rompeva. Un approccio più recente è l'Autonomous System Provider Authorization (ASPA), in cui ogni AS pubblica un elenco dei suoi provider a monte. Idealmente, ogni relazione tra AS diventa nota, rendendo possibile individuare percorsi improbabili, come una rete cliente che finge di essere un provider di transito. Tuttavia, in un mondo in cui solo poche migliaia di oggetti ASPA sono stati pubblicati nella Resource Public Key Infrastructure (RPKI), la distribuzione parziale crea ambiguità. Una relazione mancante è un peer, una rete Tier-1 senza provider, o semplicemente un AS che non ha pubblicato i suoi dati? Per aiutare, le reti possono elencare AS0 come provider per segnalare che sono senza transito, ma l'interpretazione rimane complessa. La bozza ASPA ha subito 27 revisioni in quasi dieci anni, ma i vendor di router sono stati lenti nell'implementarla, aspettando un RFC stabile prima di impegnare risorse.

In questo contesto, PAVA (PAth VAlidation) offre un modello drasticamente più semplice, e si basa fortemente sul DNS. L'idea centrale è suddividere un percorso AS in triplette sovrapposte (e coppie finali). Ad esempio, un percorso di quattro AS diventa tre triplette, ciascuna rappresentante un segmento di due o tre passi. Ogni AS pubblicherebbe poi le sue relazioni adiacenti nella propria zona DNS, usando DNSSEC per l'autenticità. I record DNS indicherebbero se ciascun collegamento è una relazione 'up' (cliente-fornitore), 'down' (fornitore-cliente) o 'summit' (peer-to-peer). Controllando questi record, i router BGP possono capire se un percorso contiene una sequenza non valida, come saltare da un provider all'altro senza una transizione up-down. Poiché le firme DNSSEC possono essere legate alle stesse chiavi crittografiche già memorizzate nell'ancora di fiducia di RPKI, la validazione diventa senza soluzione di continuità. Questo approccio non solo elimina la necessità di un protocollo di sincronizzazione separato e assetato di risorse (l'attuale tallone d'Achille di RPKI), ma consente anche una distribuzione incrementale: se un AS non pubblica i record PAVA, il percorso viene semplicemente trattato come non validato piuttosto che bloccato. La presentazione all'IETF 126 ha mostrato come il DNS, un'infrastruttura globale e robusta, possa farsi carico dell'onere di distribuire efficientemente i dati di sicurezza del routing.

Per gli utenti internet di tutti i giorni, questi dibattiti sulla sicurezza del routing contano più di quanto possano sembrare. Quando i percorsi BGP vengono dirottati, accidentalmente o maliziosamente, il traffico può essere reindirizzato attraverso punti di intercettazione o annullato del tutto (blackholed). Un sistema di validazione basato sul DNS come PAVA renderebbe tali attacchi molto più difficili da realizzare, specialmente se combinato con un'adozione diffusa di DNSSEC. Nel frattempo, gli individui possono adottare misure per ridurre la propria esposizione. Utilizzare un resolver DNS incentrato sulla privacy che supporti DNSSEC e trasporto crittografato (come DoH o DoT) garantisce che il primo passo di qualsiasi connessione, la risoluzione DNS, sia autenticato e protetto da intercettazioni. AEU DNS, ad esempio, fornisce DNS-over-HTTPS con blocco integrato di pubblicità e tracker, aiutando gli utenti a evitare domini dannosi che potrebbero essere usati in attacchi al routing. Mentre l'IETF continua a perfezionare queste proposte, un internet più affidabile inizia con scelte semplici da parte dell'utente che rafforzano la sicurezza end-to-end.