Un'autorizzazione di origine del percorso è digitalmente firmata RPKI Un record che identifica quale ASN è autorizzato ad originare un prefisso IP in BGP. Viene creato dall'organizzazione titolare delle relative risorse numeriche Internet o per suo conto. Una ROA contiene normalmente tre elementi essenziali: il prefisso IP, l'ASN di origine autorizzato e la lunghezza massima del prefisso che l'ASN può annunciare. Ad esempio, un'organizzazione può controllare il prefisso IPv4 203.0.113.0/24 e utilizzare AS64500 per annunciarlo. Una ROA corrispondente può autorizzare AS64500 a originare tale /24. In termini semplici, il record comunica la seguente istruzione all'ecosistema di routing: «Questo ASN è autorizzato ad annunciare questo prefisso». Le reti che eseguono la convalida RPKI possono quindi confrontare il record con quanto osservano in BGP. Una ROA non trasferisce la proprietà di un blocco di indirizzi IP. Non sostituisce un contratto, una voce di registro, un record di allocazione o un accordo di trasferimento IPv4. Pubblica soltanto un'autorizzazione relativa all'origine di una rotta. Il controllo legale e l'autorizzazione al routing sono correlati, ma non sono la stessa cosa. Le ROA possono essere create sia per le risorse IPv4 che per quelle IPv6. Il formato è simile, sebbene le lunghezze dei prefissi e il design operativo possano differire. Le reti IPv4 spesso lavorano con prefissi come /24, mentre le reti IPv6 comunemente annunciano aggregati come /32, /36, /48 o un'altra lunghezza appropriata alla loro allocazione e piano di routing.
Perché è necessaria una ROA?
Senza un ROA, le altre reti non dispongono di un'autorizzazione basata su RPKI per confermare che un ASN di origine BGP sia autorizzato ad annunciare un prefisso. La rotta può essere ancora legittima, ma generalmente produrrà un risultato "Not Found" durante la convalida RPKI, poiché non esiste un'autorizzazione corrispondente. Un risultato "Not Found" non è automaticamente un problema di instradamento. Molte rotte valide su Internet non dispongono di ROA. Tuttavia, quando un'organizzazione pubblica un ROA accurato, fornisce alle altre reti un segnale più forte che può essere utilizzato per distinguere l'origine prevista da un'origine non autorizzata o mal configurata. Un ROA diventa particolarmente utile quando un prefisso è di valore critico per il business o ampiamente annunciato. Un'impresa può utilizzare il proprio spazio di indirizzi per servizi pubblici, una piattaforma cloud può annunciare infrastrutture client o un provider di hosting può pubblicare ampie gamme di indirizzi da più località. In queste situazioni, un'origine errata può influenzare molti utenti e servizi. I ROA aiutano anche durante la risposta agli incidenti. Se un prefisso appare improvvisamente da un ASN imprevisto, un operatore di rete può verificare lo stato RPKI e determinare rapidamente se l'annuncio è in conflitto con l'intento pubblicato dal titolare delle risorse. Questo non spiega ogni dettaglio dell'incidente, ma fornisce un punto di partenza importante per le indagini. Per le organizzazioni che utilizzano più fornitori upstream, un ROA può fornire un'autorizzazione coerente indipendentemente dal fornitore che trasporta la rotta. Il fornitore può cambiare, ma l'ASN di origine può rimanere lo stesso. In tal caso, il ROA di solito non deve essere modificato semplicemente perché il percorso di transito è cambiato.
Come funziona un ROA con BGP?
BGP distribuisce le annunciazioni di rotta tra sistemi autonomi. Un'annunciata di rotta include solitamente un prefisso IP e un ASN di origine, insieme ad altre informazioni sul percorso e sulla politica. L'ASN di origine è il sistema autonomo che si dichiara come fonte della rotta. La convalida RPKI opera in parallelo a BGP. Un validatore recupera i dati di autorizzazione firmati dal sistema RPKI e verifica che i record siano autentici e aggiornati. Successivamente, crea un dataset convalidato che può essere utilizzato dai router, dai server di rotta o dai sistemi di policy di routing. Quando una rete riceve un'annunciata di rotta BGP, confronta il prefisso annunciato e l'ASN di origine con le informazioni ROA convalidate. Ci sono tre esiti principali. L'annunciata può essere Valid (Valida), Invalid (Non valida) o Not Found (Non trovata). Un risultato Valid significa che l'annunciata è coperta da una ROA e che l'ASN di origine è autorizzato. Un risultato Invalid indica che esiste una ROA pertinente, ma l'annunciata è in conflitto con essa. Un risultato Not Found significa che non è stata trovata alcuna ROA applicabile. La rete ricevente decide cosa fare con questi risultati. Alcuni operatori rifiutano le rotte Invalid. Altri assegnano loro una preferenza inferiore, generano un avviso o applicano politiche diverse a seconda della fonte. Non esiste una politica universale unica per ogni rete, ma molti provider trattano le annunciata Invalid come un grave problema di sicurezza del routing. Il punto importante è che la ROA non controlla direttamente Internet globale. Pubblica informazioni di autorizzazione. L'effetto pratico dipende dal fatto che altre reti recuperino, convalidino e utilizzino tali informazioni nelle proprie decisioni di routing.
Le tre parti principali di un ROA
La prima parte di un ROA è il prefisso IP autorizzato, che identifica l'intervallo di indirizzi che l'ASN di origine può annunciare. Per IPv4, un prefisso potrebbe essere 198.51.100.0/24; per IPv6, potrebbe essere 2001:db8:1234::/48. Il prefisso deve corrispondere a una risorsa che l'organizzazione è autorizzata a gestire tramite il registro pertinente o il rapporto di sponsorizzazione. Il prefisso deve essere inserito accuratamente, poiché un errore di battitura, un confine di rete errato o una lunghezza di prefisso sbagliata possono rendere il ROA inefficace o autorizzare un intervallo diverso da quello previsto.
La seconda parte è l'ASN di origine autorizzato a originare il prefisso, che corrisponde all'ASN che appare come origine dell'annuncio BGP. Se un'azienda possiede un blocco di indirizzi ma lo annuncia tramite l'ASN di un provider di transito, l'origine corretta dipende dal progetto di routing effettivo. L'ASN nel ROA dovrebbe essere normalmente l'ASN che origina la rotta, non semplicemente l'ASN del carrier upstream. Questa distinzione è importante perché un provider di transito può trasportare una rotta senza esserne l'origine; se l'ASN del cliente origina il prefisso e il provider lo trasporta solo, l'ASN del cliente è solitamente il valore che deve essere autorizzato.
La terza parte è la lunghezza massima del prefisso, spesso indicata come maxLength, che definisce quanto specifico può essere un annuncio pur rimanendo coperto dal ROA. Supponiamo che un ROA autorizzi 198.51.100.0/24 con una lunghezza massima di /24: l'ASN autorizzato può annunciare il /24 esatto, ma non ha l'autorizzazione ad annunciare sotto-prefissi più piccoli, come /25 o /26. Se lo stesso prefisso viene autorizzato con una lunghezza massima di /26, gli annunci per /24, /25 e /26 possono essere considerati coperti a seconda del percorso esatto e delle regole di validazione. Questo offre flessibilità, ma consente anche annunci più specifici. La lunghezza massima dovrebbe quindi riflettere il piano di routing effettivo, poiché impostarla troppo corta può far sì che percorsi più specifici legittimi diventino Invalidi, mentre impostarla troppo lunga potrebbe autorizzare annunci che l'organizzazione non ha mai inteso permettere.
Perché maxLength è importante?
La lunghezza massima del prefisso è una delle impostazioni ROA più importanti e più frequentemente fraintese, poiché controlla il livello di specificità che l'ASN autorizzato può utilizzare quando annuncia la risorsa. Molti operatori di rete annunciano un prefisso aggregato per ridurre la crescita della tabella di routing; ad esempio, un'organizzazione potrebbe detenere un /20 ma annunciarlo come un singolo aggregato. In alcuni casi, l'organizzazione potrebbe anche dover annunciare prefissi più specifici per l'ingegneria del traffico, la connettività regionale o la separazione dei servizi. Se la ROA copre solo l'aggregato mentre la rete annuncia route più specifiche, queste route potrebbero essere classificate come Non Valide (Invalid). L'annuncio BGP può essere tecnicamente corretto dal punto di vista dell'organizzazione, ma non corrisponde all'autorizzazione pubblicata in RPKI. D'altra parte, autorizzare ogni possibile route più specifica può indebolire la precisione della policy, poiché un /20 autorizzato con una lunghezza massima estremamente ampia consente a un sotto-prefisso molto più piccolo di apparire autorizzato anche se al di fuori del progetto intenzionale. Un approccio pratico consiste nell'autorizzare solo le lunghezze di prefisso che la rete si aspetta genuinamente di annunciare in base al proprio piano di indirizzamento, ai requisiti dei provider, alla progettazione del failover e alla strategia di ingegneria del traffico. Le modifiche alla lunghezza massima dovrebbero essere testate attentamente, confermando che tutti gli annunci in produzione restituiscono il risultato di validazione previsto prima di applicare filtri rigorosi.
ROAs for IPv4 and IPv6
Le ROA possono essere create per reti sia IPv4 che IPv6, e il principio di sicurezza sottostante è lo stesso: collegare un prefisso con un ASN di origine autorizzato. La principale differenza operativa risiede nella struttura degli indirizzi. Le risorse IPv4 sono scarse e spesso vengono annunciate in prefissi relativamente piccoli, con /24 come dimensione minima comune di annuncio su Internet pubblico. Le reti IPv6 generalmente ricevono allocazioni più ampie e possono dividerle in segmenti di sito, servizio o geografici, annunciando un aggregato mentre utilizzano diversi prefissi interni. La ROA deve allinearsi ai prefissi annunciati pubblicamente. Gli operatori IPv6 non dovrebbero assumere che uno spazio indirizzi ampio elimini i rischi di routing, poiché un annuncio IPv6 non autorizzato può comunque causare problemi di raggiungibilità, reindirizzamento del traffico o routing globale inconsistente. RPKI offre agli operatori IPv6 la stessa opportunità di pubblicare l'autorizzazione di origine offerta agli operatori IPv4. Prima di creare ROA IPv6, il team di rete dovrebbe documentare quali prefissi aggregati verranno annunciati, se sono previsti annunci più specifici e quale ASN li originerà, evitando record troppo restrittivi o eccessivamente ampi.
Quando dovresti creare un ROA?
Un ROA dovrebbe essere creato prima dell’annuncio di un prefix in produzione ogni volta che il titolare delle risorse dispone di un piano di instradamento chiaro, consentendo alle reti di validazione di recuperare le informazioni prima che la rotta diventi ampiamente visibile. Le organizzazioni dovrebbero inoltre rivedere i ROA quando ricevono una nuova allocazione, acquisiscono un blocco IPv4, completano un trasferimento di indirizzi, modificano l’ASN di origine o iniziano a utilizzare una nuova allocazione IPv6, poiché questi eventi alterano la relazione tra il prefix e la rete di origine. Una migrazione del provider è un altro trigger comune: se l’organizzazione mantiene lo stesso ASN di origine e cambia solo il carrier upstream, il ROA può rimanere valido; se la migrazione modifica l’ASN di origine, il record deve essere aggiornato prima o contemporaneamente alla modifica dell’instradamento. I ROA dovrebbero essere rivisti in caso di fusioni, acquisizioni, spostamenti di data center, modifiche dello sponsor ASN e importanti ridisegni di rete, per garantire che l’autorizzazione pubblica corrisponda alla realtà operativa. Una revisione periodica è utile anche quando non si verificano cambiamenti noti, poiché la documentazione di rete diventa obsoleta, le responsabilità del personale cambiano e vecchie autorizzazioni possono rimanere attive molto dopo che il progetto di instradamento originale è stato sostituito.
Errori comuni nella configurazione di ROA
Uno degli errori più comuni è l'inserimento dell'ASN di origine errato, che si verifica quando gli ingegneri confondono l'ASN del cliente con quello del provider di transito o quando un ASN obsoleto rimane nella configurazione dopo una migrazione. Un altro errore frequente è dimenticare di aggiornare la ROA dopo un trasferimento IPv4: il nuovo titolare annuncia il prefisso dal proprio ASN mentre l'autorizzazione precedente punta ancora all'origine originale, causando l'invalidità della rotta. Una lunghezza massima errata genera problemi simili quando un'organizzazione autorizza solo un /24 ma successivamente annuncia un /25 per l'ingegneria del traffico. Alcune organizzazioni creano più ROA sovrapposti senza documentarne lo scopo; sebbene validi in determinate architetture, possono produrre risultati imprevisti e complicare le attività di troubleshooting. Il mancato rimozione dei record obsoleti consente a un ASN di originare un prefisso molto tempo dopo che il progetto di rete è cambiato. Infine, alcune organizzazioni abilitano il rifiuto rigoroso delle rotte Invalid senza aver prima testato i propri annunci; i prefissi di produzione, le lunghezze massime e gli ASN di origine devono essere sempre verificati prima di fare affidamento sul filtraggio automatizzato.
ROA and IPv4 Transfer Planning
I trasferimenti IPv4 richiedono particolare attenzione poiché il titolare amministrativo, l'accordo di sponsorizzazione e l'origine del routing possono cambiare in fasi diverse del processo. Prima del trasferimento, il titolare attuale dovrebbe documentare le ROA esistenti e confermare quale ASN origina attualmente il prefisso, mentre l'acquirente prepara le informazioni di origine previste e coordina con i provider di transito. Durante la transizione, entrambe le parti devono avere un piano chiaro per aggiornare o sostituire i record di autorizzazione: mantenere attiva troppo a lungo la precedente ROA autorizza l'origine vecchia dopo il trasferimento, mentre rimuoverla troppo presto causa la condizione Invalid della rotta esistente prima che la nuova rotta sia pronta. Il processo esatto dipende dal registro, dal tipo di risorsa, dall'accordo di trasferimento e dalla progettazione operativa, rendendo RPKI un elemento essenziale della checklist insieme alla verifica del registro, alla revisione contrattuale, agli annunci BGP, agli oggetti route, al DNS inverso e allo screening della reputazione. Un checker di disponibilità pubblico aiuta a identificare l'ASN di origine corrente, lo stato RPKI, le informazioni del registro e la visibilità BGP di un prefisso per pre-controlli tecnici, sebbene non confermi la proprietà legale né garantisca l'idoneità al trasferimento.
Modifiche a ROA e ASN
Una modifica dell'ASN impatta direttamente sulla convalida RPKI. Se un prefisso precedentemente annunciato dall'AS64500 verrà ora annunciato dall'AS64510, la ROA deve autorizzare il nuovo origin prima che l'annuncio BGP possa essere accettato come Valid. Questo è particolarmente importante quando un'organizzazione passa da un ASN gestito dal provider al proprio ASN o cambia il proprio accordo di sponsorizzazione LIR, richiedendo una revisione congiunta del rapporto con il registro e dell'autorizzazione al routing. Una transizione accuratamente pianificata può prevedere l'autorizzazione temporanea sia degli origin vecchi che nuovi per creare una finestra di migrazione controllata, purché ciò sia documentato e l'autorizzazione obsoleta venga rimossa una volta completata. Il team di rete dovrebbe testare l'ordine delle operazioni prima di apportare modifiche in produzione, assicurandosi che la nuova autorizzazione sia pubblicata e convalidata prima di annunciare la nuova rotta BGP.
Come si verifica se un ROA sta funzionando?
La prima verifica consiste nel confermare che l'ROA contenga il prefisso previsto, l'ASN di origine e la lunghezza massima del prefisso tramite il portale RIR pertinente, l'interfaccia LIR sponsor o il sistema di gestione RPKI. Successivamente, confrontare l'autorizzazione con l'effettiva annuncio BGP, verificando che la lunghezza del prefisso annunciato sia coperta e che l'ASN di origine corrisponda a quello dell'ROA. Un validatore RPKI esterno può quindi confermare lo stato pubblico, dove un annuncio correttamente configurato restituisce Valid. Se il risultato è Invalid, ispezionare innanzitutto l'ASN di origine e la lunghezza del prefisso; se Not Found, verificare che l'ROA sia stato pubblicato e che i validatori abbiano avuto tempo per recuperarlo. I risultati non si aggiornano istantaneamente perché repository, validatori e sistemi di instradamento si basano su intervalli di aggiornamento, rendendo normali brevi ritardi durante la propagazione. Il confronto tra più fonti pubbliche, inclusi dati di registro, risultati dei validatori e osservazioni BGP correnti, evita di fare affidamento su informazioni memorizzate nella cache e fornisce una visione completa.
Cosa succede quando un ROA è invalido?
Quando un annuncio BGP è in conflitto con una ROA esistente, i validatori RPKI lo classificano come Invalid. La rotta non viene rimossa automaticamente da Internet globale, ma le reti che applicano politiche basate su RPKI potrebbero rifiutarla o assegnarle una priorità inferiore. L'impatto operativo dipende dall'ampiezza dell'applicazione: alcune reti filtrano rigorosamente, mentre altre utilizzano lo stato per il monitoraggio, il che significa che una rotta Invalid potrebbe rimanere visibile in alcune parti di Internet mentre diventa irraggiungibile attraverso altre. Se una rotta legittima diventa Invalid, l'organizzazione dovrebbe considerarla un problema di configurazione urgente, dando priorità alla revisione dell'ASN di origine, della lunghezza del prefisso annunciato e della lunghezza massima della ROA. La rotta non deve essere considerata malevola, poiché la maggior parte dei risultati Invalid deriva da errori comuni come migrazioni incomplete, record obsoleti, dettagli errati del provider o annunci accidentali di più specifici. Una volta corretta, i sistemi necessitano di tempo per aggiornarsi e il team di rete dovrebbe monitorare la rotta fino a quando questa non si stabilizza in tutti i punti di osservazione.
Come dovrebbero le organizzazioni gestire i ROA?
La gestione delle ROA richiede un proprietario chiaro, che sia il team di ingegneria di rete, il team di sicurezza, l'LIR sponsor, il fornitore di servizi gestiti o un altro gruppo responsabile delle risorse numeriche Internet. L'organizzazione dovrebbe mantenere un inventario dettagliato di ogni prefisso, ASN di origine, lunghezza massima, località di annuncio e contatti responsabili per semplificare le revisioni delle modifiche e le risposte agli incidenti. Le modifiche alle ROA devono essere integrate nelle procedure standard di modifica della rete, trattando RPKI come un requisito esplicito durante le migrazioni ASN, i cambi di provider, i trasferimenti IPv4 o le implementazioni IPv6. Il monitoraggio e gli allarmi dovrebbero essere configurati per rilevare risultati Invalid, origini impreviste, autorizzazioni rimosse o variazioni nella visibilità BGP. È fondamentale che le organizzazioni evitino autorizzazioni troppo generiche: le ROA precise sono più facili da comprendere, più semplici da auditare e molto meno soggette a consentire annunci non intenzionali.
Domande frequenti
Un ROA è lo stesso documento di proprietà IP?
No. Un ROA è un'autorizzazione di routing che indica quale ASN può originare un prefisso in BGP. Non sostituisce i record dei registri, i contratti, i documenti di trasferimento o le prove di proprietà legale.
Un singolo prefisso può avere più di un ROA?
Sì. Più ROA possono essere appropriate quando un prefisso è intenzionalmente originato da più di un ASN o quando una migrazione controllata richiede un'autorizzazione temporanea per più origini, sebbene i record sovrapposti dovrebbero essere accuratamente documentati.
Un annuncio ROA indica il mio prefisso in BGP?
No. La creazione di un ROA non genera un annuncio BGP; la rete deve comunque configurare il BGP tramite i propri router e i provider upstream.
Un fornitore di transito deve essere elencato nell'ROA?
Di solito, il ROA dovrebbe identificare l'ASN che origina la rotta. Un provider che trasporta solo la rotta non è necessariamente l'ASN di origine, e il valore corretto dipende dall'architettura di routing effettiva.
Quanto tempo ci vuole perché un ROA diventi visibile?
La tempistica dipende dal sistema RIR, dal repository di pubblicazione, dagli intervalli di aggiornamento del validatore e dalla cache. Gli aggiornamenti sono spesso visibili relativamente rapidamente, ma le modifiche in produzione dovrebbero prevedere un tempo sufficiente per la convalida.
Ogni prefisso IPv4 e IPv6 dovrebbe avere una ROA?
Si consiglia vivamente di pubblicare ROA accurati per i prefix annunciati in BGP. L'organizzazione dovrebbe prima confermare il proprio design di routing in modo che l'autorizzazione non renda invalidi accidentalmente gli annunci legittimi.
Un ROA può proteggere da ogni attacco BGP?
No. Un ROA supporta principalmente la convalida dell'origine. Non convalida ogni parte del percorso BGP, non previene tutte le fughe di rotte, non crittografa il traffico e non garantisce che il traffico segua un percorso fisico sicuro.
Un'autorizzazione di origine del percorso (Route Origin Authorization, ROA) è un componente centrale del RPKI, che stabilisce una relazione crittograficamente firmata tra un prefisso IP e l'ASN autorizzato ad originare tale prefisso in BGP. Il record include normalmente il prefisso, l'ASN di origine e una lunghezza massima del prefisso: ciascuno di questi elementi svolge un ruolo decisivo nell'identificare la risorsa, nel consentire l'origine e nel definire quanto specifico può essere l'annuncio. Le ROA accurate aiutano le reti a identificare annunci non autorizzati o mal configurati, risultando vitali durante trasferimenti IPv4, modifiche ASN, migrazioni dei provider, implementazioni IPv6 e operazioni di rete multi-homed. Al contempo, una ROA non costituisce prova di proprietà legale né una soluzione autonoma per la sicurezza del routing; funziona al meglio insieme a registri accurati, configurazioni BGP disciplinate, dati IRR, monitoraggio delle rotte e processi documentati di modifica. Per qualsiasi organizzazione che annuncia spazio pubblico IPv4 o IPv6, la regola pratica è semplice: pubblicare solo le origini che si intende utilizzare, autorizzare solo le lunghezze di prefisso che si prevede effettivamente di annunciare e rivedere i record ogni volta che la rete subisce modifiche. Ciò mantiene i dati RPKI allineati con l'ambiente di routing reale e riduce la possibilità che una rotta legittima venga classificata come Invalid.