Il ruolo di RPKI nel rafforzare la sicurezza del routing globale

Le prove condivise vengono verificate dalle singole reti. Il loro effetto dipende dai dati che queste ricevono e dalle politiche che applicano.

Un errore di routing in una rete può colpire persone molto lontane. Quando si propaga un’origine errata, un sito funzionante può diventare irraggiungibile oppure il traffico può finire dove non dovrebbe. RPKI offre alle reti riceventi un modo per verificare un aspetto di un annuncio prima di farvi affidamento.

Il suo valore nasce da una catena di azioni: un titolare pubblica un’autorizzazione utilizzabile, il software la verifica e un operatore applica una politica di routing. Comprendere questa catena chiarisce sia la protezione sia i punti in cui può venir meno.

Che cosa viene verificato?

Le reti si scambiano informazioni sulla raggiungibilità attraverso BGP. Un prefisso è un blocco di indirizzi IP; un ASN identifica un sistema autonomo. Un’autorizzazione dell’origine di una rotta, o ROA, indica quale ASN il titolare autorizza a originare rotte per determinati prefissi.

Il software di validazione verifica i record firmati e i certificati, quindi fornisce dati di autorizzazione validati. Un router confronta l’origine e la lunghezza del prefisso di una rotta con quei dati. L’operatore decide come agire in base al risultato. Questa ripartizione mantiene distinte la pubblicazione dei record, la validazione delle prove e le decisioni di routing.

Tre risultati, con significati diversi

• Valid: almeno un’autorizzazione che copre il prefisso consente l’origine e la lunghezza del prefisso annunciate.
• Invalid: esistono dati di autorizzazione che coprono il prefisso, ma nessun record consente quella combinazione.
• NotFound: nei dati utilizzati non esiste un’autorizzazione che copra la rotta.

Queste regole derivano da RFC 6811. In particolare, l’assenza di una ROA che copra il prefisso non equivale a una rotta Invalid. Né Valid significa che l’intero percorso annunciato sia stato autenticato.

Dove la protezione produce effetti

Se una rete ricevente rifiuta gli annunci Invalid, un’origine in conflitto con le autorizzazioni può essere fermata lì, senza che venga propagata attraverso quella rete. L’effetto dipende dalle autorizzazioni, dai dati disponibili e dalla politica effettivamente applicata. Pubblicare più ROA e avere più reti che usano la validazione dell’origine sono forme di adozione collegate, ma diverse.

RFC 8481 chiarisce il ruolo dell’operatore: assegnare uno stato di validazione è distinto dall’agire in base a quello stato. Non esiste un unico interruttore globale che faccia adottare contemporaneamente la stessa politica a tutte le reti.

Una rotta propagata impropriamente può mantenere un’origine autorizzata. Anche un percorso falsificato può conservare quel valore di origine. La validazione dell’origine lascia quindi aperti rischi di routing importanti; agli operatori servono ancora altri controlli e visibilità su come si propagano le rotte.

Anche il sistema delle prove richiede cura

Un’autorizzazione che indica l’ASN sbagliato o esclude una lunghezza di prefisso prevista può far classificare come Invalid un annuncio legittimo. Anche problemi ai repository, ai certificati o ai validatori possono modificare i dati disponibili ai router. Cache e tempi di aggiornamento diversi fanno sì che reti diverse non arrivino necessariamente alla stessa visione nello stesso momento.

Prepararsi sul piano operativo significa avere autorizzazioni precise, modifiche al routing collaudate, validatori monitorati e una procedura documentata per rispondere a dati obsoleti o mancanti. Un secondo validatore è utile solo nella misura in cui riduce i guasti ai quali si vuole resistere. Non elimina tutte le dipendenze condivise. RFC 7115 tratta gli aspetti operativi; RFC 8211 esamina le azioni dannose nel sistema di pubblicazione e certificazione RPKI.

La protezione non deve diventare dipendenza permanente

È anche una questione di progettazione istituzionale. Un organismo che controlla prove essenziali può influenzare reti che non gestisce e che non rappresenta politicamente. Nella Nota 28, Lu Heng sostiene che la funzione del registro debba rimanere un’amministrazione accurata, anziché diventare uno strumento di coercizione.

La sua Nota 64 pone un obiettivo progettuale più ambizioso: le regole comuni devono essere minime e verificabili localmente, i record devono essere portabili e i cambiamenti futuri devono dipendere dall’adozione volontaria dei partecipanti. La sicurezza e la possibilità di sostituire un coordinatore che non svolge più adeguatamente il proprio compito vanno progettate insieme.

L’urgenza è concreta. Quando gli utenti hanno già perso l’accesso, scoprire chi controlla un record necessario diventa un’emergenza. Ricostruisci queste dipendenze mentre le reti funzionano. Prosegui poi con come una modifica a un record può portare al rifiuto di una rotta.