{"id":1102,"date":"2026-09-09T02:25:09","date_gmt":"2026-09-09T02:25:09","guid":{"rendered":"https:\/\/junglelabs.uk\/"},"modified":"2026-09-09T02:25:09","modified_gmt":"2026-09-09T02:25:09","slug":"what-is-a-roa-in-rpki","status":"publish","type":"post","link":"https:\/\/junglelabs.uk\/it\/what-is-a-roa-in-rpki\/","title":{"rendered":"Cos'\u00e8 un ROA nel contesto del RPKI? Come funziona l'Autorizzazione all'Origine delle Route"},"content":{"rendered":"

Un'autorizzazione di origine del percorso \u00e8 digitalmente firmata RPKI<\/a> Un record che identifica quale ASN \u00e8 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\u00f2 annunciare. Ad esempio, un'organizzazione pu\u00f2 controllare il prefisso IPv4 203.0.113.0\/24 e utilizzare AS64500 per annunciarlo. Una ROA corrispondente pu\u00f2 autorizzare AS64500 a originare tale \/24. In termini semplici, il record comunica la seguente istruzione all'ecosistema di routing: \u00abQuesto ASN \u00e8 autorizzato ad annunciare questo prefisso\u00bb. Le reti che eseguono la convalida RPKI possono quindi confrontare il record con quanto osservano in BGP. Una ROA non trasferisce la propriet\u00e0 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 \u00e8 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.<\/p>\n\n\n\n

Perch\u00e9 \u00e8 necessaria una ROA?<\/h2>\n\n\n\n

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\u00f2 essere ancora legittima, ma generalmente produrr\u00e0 un risultato \"Not Found\" durante la convalida RPKI, poich\u00e9 non esiste un'autorizzazione corrispondente. Un risultato \"Not Found\" non \u00e8 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\u00f9 forte che pu\u00f2 essere utilizzato per distinguere l'origine prevista da un'origine non autorizzata o mal configurata. Un ROA diventa particolarmente utile quando un prefisso \u00e8 di valore critico per il business o ampiamente annunciato. Un'impresa pu\u00f2 utilizzare il proprio spazio di indirizzi per servizi pubblici, una piattaforma cloud pu\u00f2 annunciare infrastrutture client o un provider di hosting pu\u00f2 pubblicare ampie gamme di indirizzi da pi\u00f9 localit\u00e0. In queste situazioni, un'origine errata pu\u00f2 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\u00f2 verificare lo stato RPKI e determinare rapidamente se l'annuncio \u00e8 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\u00f9 fornitori upstream, un ROA pu\u00f2 fornire un'autorizzazione coerente indipendentemente dal fornitore che trasporta la rotta. Il fornitore pu\u00f2 cambiare, ma l'ASN di origine pu\u00f2 rimanere lo stesso. In tal caso, il ROA di solito non deve essere modificato semplicemente perch\u00e9 il percorso di transito \u00e8 cambiato.<\/p>\n\n\n\n

Come funziona un ROA con BGP?<\/h2>\n\n\n\n

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 \u00e8 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\u00f2 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\u00f2 essere Valid (Valida), Invalid (Non valida) o Not Found (Non trovata). Un risultato Valid significa che l'annunciata \u00e8 coperta da una ROA e che l'ASN di origine \u00e8 autorizzato. Un risultato Invalid indica che esiste una ROA pertinente, ma l'annunciata \u00e8 in conflitto con essa. Un risultato Not Found significa che non \u00e8 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 \u00e8 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.<\/p>\n\n\n\n

Le tre parti principali di un ROA<\/h2>\n\n\n\n

La prima parte di un ROA \u00e8 il prefisso IP autorizzato, che identifica l'intervallo di indirizzi che l'ASN di origine pu\u00f2 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 \u00e8 autorizzata a gestire tramite il registro pertinente o il rapporto di sponsorizzazione. Il prefisso deve essere inserito accuratamente, poich\u00e9 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.<\/p>\n\n\n\n

La seconda parte \u00e8 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 \u00e8 importante perch\u00e9 un provider di transito pu\u00f2 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 \u00e8 solitamente il valore che deve essere autorizzato.<\/p>\n\n\n\n

La terza parte \u00e8 la lunghezza massima del prefisso, spesso indicata come maxLength, che definisce quanto specifico pu\u00f2 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\u00f2 annunciare il \/24 esatto, ma non ha l'autorizzazione ad annunciare sotto-prefissi pi\u00f9 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\u00e0, ma consente anche annunci pi\u00f9 specifici. La lunghezza massima dovrebbe quindi riflettere il piano di routing effettivo, poich\u00e9 impostarla troppo corta pu\u00f2 far s\u00ec che percorsi pi\u00f9 specifici legittimi diventino Invalidi, mentre impostarla troppo lunga potrebbe autorizzare annunci che l'organizzazione non ha mai inteso permettere.<\/p>\n\n\n\n

Perch\u00e9 maxLength \u00e8 importante?<\/h2>\n\n\n\n

La lunghezza massima del prefisso \u00e8 una delle impostazioni ROA pi\u00f9 importanti e pi\u00f9 frequentemente fraintese, poich\u00e9 controlla il livello di specificit\u00e0 che l'ASN autorizzato pu\u00f2 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\u00f9 specifici per l'ingegneria del traffico, la connettivit\u00e0 regionale o la separazione dei servizi. Se la ROA copre solo l'aggregato mentre la rete annuncia route pi\u00f9 specifiche, queste route potrebbero essere classificate come Non Valide (Invalid). L'annuncio BGP pu\u00f2 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\u00f9 specifica pu\u00f2 indebolire la precisione della policy, poich\u00e9 un \/20 autorizzato con una lunghezza massima estremamente ampia consente a un sotto-prefisso molto pi\u00f9 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.<\/p>\n\n\n\n

ROAs for IPv4 and IPv6<\/h2>\n\n\n\n

Le ROA possono essere create per reti sia IPv4 che IPv6, e il principio di sicurezza sottostante \u00e8 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\u00f9 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\u00e9 un annuncio IPv6 non autorizzato pu\u00f2 comunque causare problemi di raggiungibilit\u00e0, reindirizzamento del traffico o routing globale inconsistente. RPKI offre agli operatori IPv6 la stessa opportunit\u00e0 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\u00f9 specifici e quale ASN li originer\u00e0, evitando record troppo restrittivi o eccessivamente ampi.<\/p>\n\n\n\n

Quando dovresti creare un ROA?<\/strong><\/h2>\n\n\n\n

Un ROA dovrebbe essere creato prima dell\u2019annuncio 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\u2019ASN di origine o iniziano a utilizzare una nuova allocazione IPv6, poich\u00e9 questi eventi alterano la relazione tra il prefix e la rete di origine. Una migrazione del provider \u00e8 un altro trigger comune: se l\u2019organizzazione mantiene lo stesso ASN di origine e cambia solo il carrier upstream, il ROA pu\u00f2 rimanere valido; se la migrazione modifica l\u2019ASN di origine, il record deve essere aggiornato prima o contemporaneamente alla modifica dell\u2019instradamento. 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\u2019autorizzazione pubblica corrisponda alla realt\u00e0 operativa. Una revisione periodica \u00e8 utile anche quando non si verificano cambiamenti noti, poich\u00e9 la documentazione di rete diventa obsoleta, le responsabilit\u00e0 del personale cambiano e vecchie autorizzazioni possono rimanere attive molto dopo che il progetto di instradamento originale \u00e8 stato sostituito.<\/p>\n\n\n\n

Errori comuni nella configurazione di ROA<\/h2>\n\n\n\n

Uno degli errori pi\u00f9 comuni \u00e8 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 \u00e8 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\u00e0 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\u00f9 ROA sovrapposti senza documentarne lo scopo; sebbene validi in determinate architetture, possono produrre risultati imprevisti e complicare le attivit\u00e0 di troubleshooting. Il mancato rimozione dei record obsoleti consente a un ASN di originare un prefisso molto tempo dopo che il progetto di rete \u00e8 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.<\/p>\n\n\n\n

ROA and IPv4 Transfer Planning<\/h2>\n\n\n\n

I trasferimenti IPv4 richiedono particolare attenzione poich\u00e9 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\u00e0 pubblico aiuta a identificare l'ASN di origine corrente, lo stato RPKI, le informazioni del registro e la visibilit\u00e0 BGP di un prefisso per pre-controlli tecnici, sebbene non confermi la propriet\u00e0 legale n\u00e9 garantisca l'idoneit\u00e0 al trasferimento.<\/p>\n\n\n\n

Modifiche a ROA e ASN<\/h2>\n\n\n\n

Una modifica dell'ASN impatta direttamente sulla convalida RPKI. Se un prefisso precedentemente annunciato dall'AS64500 verr\u00e0 ora annunciato dall'AS64510, la ROA deve autorizzare il nuovo origin prima che l'annuncio BGP possa essere accettato come Valid. Questo \u00e8 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\u00f2 prevedere l'autorizzazione temporanea sia degli origin vecchi che nuovi per creare una finestra di migrazione controllata, purch\u00e9 ci\u00f2 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.<\/p>\n\n\n\n

Come si verifica se un ROA sta funzionando?<\/h2>\n\n\n\n

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\u00f2 quindi confermare lo stato pubblico, dove un annuncio correttamente configurato restituisce Valid. Se il risultato \u00e8 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\u00e9 repository, validatori e sistemi di instradamento si basano su intervalli di aggiornamento, rendendo normali brevi ritardi durante la propagazione. Il confronto tra pi\u00f9 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.<\/p>\n\n\n\n

Cosa succede quando un ROA \u00e8 invalido?<\/h2>\n\n\n\n

Quando un annuncio BGP \u00e8 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\u00e0 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\u00e0 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\u00e9 la maggior parte dei risultati Invalid deriva da errori comuni come migrazioni incomplete, record obsoleti, dettagli errati del provider o annunci accidentali di pi\u00f9 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.<\/p>\n\n\n\n

Come dovrebbero le organizzazioni gestire i ROA?<\/h2>\n\n\n\n

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\u00e0 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\u00e0 BGP. \u00c8 fondamentale che le organizzazioni evitino autorizzazioni troppo generiche: le ROA precise sono pi\u00f9 facili da comprendere, pi\u00f9 semplici da auditare e molto meno soggette a consentire annunci non intenzionali.<\/p>\n\n\n\n

Domande frequenti<\/h2>\n\n\n\n

Un ROA \u00e8 lo stesso documento di propriet\u00e0 IP?<\/strong> <\/p>\n\n\n\n

No. Un ROA \u00e8 un'autorizzazione di routing che indica quale ASN pu\u00f2 originare un prefisso in BGP. Non sostituisce i record dei registri, i contratti, i documenti di trasferimento o le prove di propriet\u00e0 legale.<\/p>\n\n\n\n

Un singolo prefisso pu\u00f2 avere pi\u00f9 di un ROA?<\/strong> <\/p>\n\n\n\n

S\u00ec. Pi\u00f9 ROA possono essere appropriate quando un prefisso \u00e8 intenzionalmente originato da pi\u00f9 di un ASN o quando una migrazione controllata richiede un'autorizzazione temporanea per pi\u00f9 origini, sebbene i record sovrapposti dovrebbero essere accuratamente documentati.<\/p>\n\n\n\n

Un annuncio ROA indica il mio prefisso in BGP?<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Un fornitore di transito deve essere elencato nell'ROA?<\/strong><\/p>\n\n\n\n

Di solito, il ROA dovrebbe identificare l'ASN che origina la rotta. Un provider che trasporta solo la rotta non \u00e8 necessariamente l'ASN di origine, e il valore corretto dipende dall'architettura di routing effettiva.<\/p>\n\n\n\n

Quanto tempo ci vuole perch\u00e9 un ROA diventi visibile?<\/strong> <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Ogni prefisso IPv4 e IPv6 dovrebbe avere una ROA?<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Un ROA pu\u00f2 proteggere da ogni attacco BGP?<\/strong> <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Un'autorizzazione di origine del percorso (Route Origin Authorization, ROA) \u00e8 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\u00f2 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\u00e0 legale n\u00e9 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 \u00e8 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\u00f2 mantiene i dati RPKI allineati con l'ambiente di routing reale e riduce la possibilit\u00e0 che una rotta legittima venga classificata come Invalid.<\/p>","protected":false},"excerpt":{"rendered":"

A Route Origin Authorization is a digitally signed RPKI record that identifies which ASN is allowed to originate an IP prefix in BGP. It is created by, or on behalf of, the organization that holds the relevant Internet number resource. A ROA normally contains three essential elements: the IP prefix, the authorized origin ASN, and […]<\/p>\n","protected":false},"author":1,"featured_media":1104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is a ROA in RPKI? How Route Origin Authorization Works","_seopress_titles_desc":"Learn what a ROA is in RPKI, how it authorizes an ASN to announce an IPv4 or IPv6 prefix, why maxLength matters, and how to avoid common routing errors.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-1102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article"],"_links":{"self":[{"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/comments?post=1102"}],"version-history":[{"count":2,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/posts\/1102\/revisions"}],"predecessor-version":[{"id":1105,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/posts\/1102\/revisions\/1105"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/media\/1104"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/media?parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/categories?post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/tags?post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}