La validazione RPKI \u00e8 ora un elemento importante della sicurezza del routing BGP moderno. Aiuta gli operatori di rete a determinare se un numero di sistema autonomo \u00e8 autorizzato a originare un prefisso IPv4 o IPv6 specifico. Quando un router riceve un annuncio di percorso, pu\u00f2 confrontare l'annuncio con l'autorizzazione RPKI pubblicata per quell'intervallo di indirizzi.<\/p>\n\n\n\n
Il risultato viene normalmente visualizzato come Valido, Non valido o Non trovato. Questi tre etichette sono semplici, ma spesso vengono mal compresi. Un risultato Valido non significa che ogni parte del percorso sia perfetta. Un risultato Non valido non significa sempre che qualcuno stia attaccando la rete. Un risultato Non trovato non significa automaticamente che l'annuncio non sia sicuro.<\/p>\n\n\n\n
Le etichette descrivono solo la relazione tra un annuncio BGP e i dati di Autorizzazione all'Origine del Percorso disponibili. Per comprendere correttamente il risultato, \u00e8 necessario confrontare tre dettagli: il prefisso IP annunciato, l'ASN di origine e la lunghezza massima del prefisso consentita dall'autorizzazione.<\/p>\n\n\n\n
Questo articolo spiega ogni stato RPKI in termini pratici, mostra perch\u00e9 le rotte legittime possono diventare Invalid, e fornisce un processo di risoluzione dei problemi per gli operatori di rete che gestiscono il proprio ASN, risorse IPv4, assegnazioni IPv6 o routing in upstream. Se sei nuovo sul tema, inizia con il nostro guida a Cos'\u00e8 RPKI?<\/a> e poi leggi Cosa \u00e8 un ROA in RPKI?<\/a> per una spiegazione dettagliata del record di autorizzazione stesso.<\/p>\n\n\n\n RPKI sta per Resource Public Key Infrastructure. Collega le risorse numeriche Internet con record di autorizzazione firmati in modo crittografico. Il titolare o il gestore autorizzato di un prefisso IP pu\u00f2 pubblicare un ROA che indica che un certo ASN \u00e8 autorizzato a originare quel prefisso in BGP.<\/p>\n\n\n\n Un validatore raccoglie questi record firmati, ne verifica l'autenticit\u00e0 e crea un insieme di dati validati per gli operatori di rete. Quando viene ricevuto un percorso BGP, il sistema di instradamento dell'operatore confronta il percorso con questo insieme di dati. Il confronto pone tre domande base: La prefisso annunciato \u00e8 coperto da un'autorizzazione? L'ASN di origine \u00e8 quello indicato in quella autorizzazione? La lunghezza della prefisso annunciata \u00e8 entro la lunghezza massima consentita?<\/p>\n\n\n\n La risposta a quelle domande determina lo stato RPKI. Lo stato si applica all'autorizzazione all'origine del percorso, non a ogni attributo del percorso BGP. RPKI non dimostra che tutte le reti intermedie siano corrette, che il traffico segua il percorso migliore o che la risorsa dell'indirizzo sia legalmente disponibile per la vendita. \u00c8 un segnale di sicurezza mirato che aumenta la fiducia nell'origine di un percorso.<\/p>\n\n\n\n Un percorso \u00e8 Validit\u00e0 RPKI<\/strong> quando l'annuncio BGP \u00e8 coperto da almeno una ROA applicabile, l'ASN di origine corrisponde all'ASN autorizzato e la lunghezza del prefisso annunciato \u00e8 permessa dalla lunghezza massima della ROA. In termini pratici, la rotta \u00e8 coerente con l'autorizzazione alla routing pubblicata dal titolare delle risorse.<\/p>\n\n\n\n Ad esempio, supponiamo che un'azienda controlli Un risultato valido \u00e8 un segnale positivo, ma non deve essere interpretato come una garanzia completa. La rotta potrebbe ancora avere un percorso errato, una cattiva reputazione aziendale, una descrizione del registro obsoleta o un problema operativo al di fuori dell'autorizzazione di origine. Di solito, gli operatori di rete combinano RPKI con il monitoraggio BGP, il filtraggio dei prefissi, i controlli del registro e le procedure di risposta agli incidenti.<\/p>\n\n\n\n Uno stato valido pu\u00f2 cambiare anche quando la rete cambia. Se un'azienda sposta un prefisso a un altro ASN, inizia a annunciare un percorso pi\u00f9 specifico, o modifica il piano degli indirizzi, il ROA esistente potrebbe non corrispondere pi\u00f9 all'annuncio nuovo. RPKI riflette i dati di autorizzazione correnti, quindi deve essere mantenuto come parte delle operazioni normali della rete.<\/p>\n\n\n\n Un percorso \u00e8 RPKI non valido<\/strong> quando esiste un'autorizzazione applicabile, ma l'annuncio BGP \u00e8 in conflitto con essa. Il conflitto coinvolge di solito uno dei due aspetti: l'ASN di origine non \u00e8 autorizzato, oppure il prefisso annunciato \u00e8 pi\u00f9 specifico della lunghezza massima consentita dal ROA.<\/p>\n\n\n\n Ad esempio, un ROA pu\u00f2 autorizzare Non valido non significa necessariamente che stia avvenendo un attacco malizioso. Molte rotte non valide sono causate da errori operativi ordinari. Un ingegnere potrebbe dimenticarsi di aggiornare una ROA dopo una migrazione ASN, un provider potrebbe annunciare un prefisso cliente con l'origine errata, o la rete potrebbe iniziare a utilizzare prefissi pi\u00f9 specifici senza modificare la lunghezza massima.<\/p>\n\n\n\n Contemporaneamente, un risultato non valido non deve essere ignorato. Pu\u00f2 indicare un annuncio non autorizzato, una perdita di percorso con un origine inaspettata o un errore di configurazione che potrebbe rendere il prefisso irraggiungibile attraverso reti che utilizzano filtri RPKI rigorosi. La risposta corretta \u00e8 indagare rapidamente sul risultato e confrontarlo con il progetto di instradamento previsto.<\/p>\n\n\n\n Un percorso \u00e8 RPKI non trovato<\/strong> quando il validator non riesce a trovare un ROA applicabile per il prefisso annunciato. Non \u00e8 presente un'autorizzazione pubblicata che possa confermare o negare l'ASN di origine per quel percorso.<\/p>\n\n\n\n Non Trovato \u00e8 a volte chiamato \"non noto\", perch\u00e9 il sistema di convalida non dispone di informazioni sufficienti per autorizzazione per arrivare a una conclusione. Non significa che la route sia invalida, e non dimostra che l'origine non sia autorizzata. Molti prefissi legittimi su Internet non hanno ancora un ROA, o perch\u00e9 il titolare delle risorse non ha creato uno o perch\u00e9 l'autorizzazione non \u00e8 ancora visibile al validatore.<\/p>\n\n\n\n La mancanza di un ROA riduce la quantit\u00e0 di informazioni disponibili per le reti che desiderano validare il percorso. Se un ASN non autorizzato annuncia lo stesso prefisso, una rete che vede entrambe le annunce potrebbe avere difficolt\u00e0 a distinguere il percorso legittimo da quello falso utilizzando esclusivamente RPKI.<\/p>\n\n\n\n I detentori delle risorse dovrebbero normalmente pubblicare ROA accurate per i prefissi che annunciano pubblicamente, specialmente quando i prefissi supportano servizi importanti. Tuttavia, gli operatori dovrebbero evitare di creare un'autorizzazione frettolosa o troppo ampia solo per modificare Non trovato in Valido. Un ROA male configurato pu\u00f2 rendere una rotta legittima non valida, il che pu\u00f2 avere un impatto operativo pi\u00f9 immediato.<\/p>\n\n\n\n La distinzione pi\u00f9 importante \u00e8 che Invalido \u00e8 un conflitto<\/strong>, mentre Non trovato \u00e8 l'assenza dei dati di autorizzazione<\/strong>. Non valido indica che il validatore ha trovato un ROA rilevante ma la rotta non \u00e8 conforme ad esso. Non trovato indica che non \u00e8 stato trovato alcun ROA applicabile.<\/p>\n\n\n\n Considera due esempi. Nel primo, un'azienda pubblica un ROA autorizzante Questa differenza \u00e8 importante quando si crea una politica di instradamento. Molti network danno un trattamento speciale alle route non valide, poich\u00e9 un'autorizzazione esistente indica che il titolare delle risorse ha espresso un'aspettativa specifica. Le route Non Trovate potrebbero essere monitorate, date una preferenza inferiore o accettate in base alla politica locale. Ogni rete decide come applicare il risultato.<\/p>\n\n\n\n Gli operatori di rete dovrebbero ricordare che i risultati della convalida possono variare temporaneamente mentre i repository e i validatori vengono aggiornati. Se un ROA \u00e8 stato creato o modificato solo pochi minuti fa, diversi strumenti potrebbero mostrare stati diversi fino a quando l'aggiornamento non si \u00e8 propagato nel sistema di convalida.<\/p>\n\n\n\n La causa pi\u00f9 comune \u00e8 un cambiamento di ASN. Un'azienda potrebbe inizialmente annunciare un prefisso da un ASN fornito da un'organizzazione di upstream o sponsor e successivamente spostare il prefisso al proprio ASN. Se la ROA autorizza ancora l'origine vecchia, l'annuncio nuovo diventa non valido.<\/p>\n\n\n\n Un secondo motivo \u00e8 una lunghezza massima del prefisso errata. Un'organizzazione pu\u00f2 detenere un I trasferimenti IPv4 possono creare problemi simili. Durante un trasferimento, il titolare amministrativo e l'origine del routing possono cambiare in momenti diversi. Se l'autorizzazione del precedente titolare rimane attiva mentre il nuovo titolare annuncia il prefisso da un ASN diverso, la transizione pu\u00f2 produrre uno stato non valido.<\/p>\n\n\n\n Record obsoleti, confini di rete errati e malintesi sul ruolo del provider di trasporto sono altri fattori frequenti. Un provider pu\u00f2 trasportare un percorso del cliente senza essere l'ASN di origine. La ROA ha normalmente bisogno di autorizzare l'ASN che appare come origine del percorso, non semplicemente il carrier che trasporta il traffico.<\/p>\n\n\n\n Inizia registrando il prefisso esatto e l'ASN di origine mostrati nell'annuncio BGP. Non fare affidamento su un display abbreviato o su un documento di configurazione precedente. Conferma la famiglia di indirizzi, la lunghezza del prefisso e l'origine osservata da almeno un monitor di routing affidabile.<\/p>\n\n\n\n Inoltre, ispeziona gli ROA attivi per quel prefisso. Verifica l'ASN autorizzato e la lunghezza massima del prefisso. Se l'ASN di origine non corrisponde, determina se la rotta o l'autorizzazione \u00e8 errata. Se l'ASN \u00e8 corretto, controlla se il prefisso annunciato \u00e8 pi\u00f9 specifico della lunghezza massima consentita.<\/p>\n\n\n\n Verifica le modifiche recenti. Cerca una migrazione ASN, cambio del provider upstream, trasferimento IPv4, implementazione IPv6, spostamento del data center, cambiamento nell'aggregazione delle route o aggiornamento delle politiche BGP. La maggior parte dei risultati non validi legittimi possono essere collegati a un cambiamento recente non riflettuto nella gestione RPKI.<\/p>\n\n\n\n Se la ROA \u00e8 errata, aggiornala attraverso il relativo Regional Internet Registry, LIR sponsorizzatore o sistema di gestione RPKI. Se l'annuncio BGP \u00e8 errato, correggi invece la politica del percorso. Non risolvere un errore di instradamento pubblicando una ROA non necessariamente ampia, perch\u00e9 potrebbe autorizzare annunci che non erano mai stati intesi.<\/p>\n\n\n\n Dopo aver apportato la correzione, attendere che il repository e il validatore si aggiornino. Verificare nuovamente i risultati utilizzando un servizio di validazione esterna e una fonte di monitoraggio BGP. La route dovrebbe tornare a Valid quando l'origine e la lunghezza del prefisso corrispondono all'autorizzazione pubblicata.<\/p>\n\n\n\n La validazione RPKI non ritira automaticamente un percorso dalla rete Internet. La rete ricevente decide come utilizzare i risultati nella sua politica di instradamento. Alcuni operatori rifiutano i percorsi non validi, mentre altri li contrassegnano con una preferenza inferiore, generano avvisi o continuano a accettarli in base a determinate condizioni.<\/p>\n\n\n\n Una rotta valida pu\u00f2 ricevere un trattamento normale, ma comunque compete con altre rotte in base alla preferenza locale, alla lunghezza del percorso, alle regole di ingegneria del traffico e alla politica del provider. Una rotta Non trovata pu\u00f2 essere accettata da una rete e trattata con maggiore cautela da un'altra. Una rotta non valida pu\u00f2 rimanere visibile attraverso alcuni provider mentre diventa irraggiungibile attraverso reti che applicano filtri rigorosi.<\/p>\n\n\n\n Questa differenza spiega perch\u00e9 un annuncio non valido pu\u00f2 causare una connettivit\u00e0 parziale. Un servizio potrebbe funzionare in una regione ma fallire in un'altra, poich\u00e9 reti diverse applicano politiche diverse. Quando si diagnostica un'interruzione, \u00e8 quindi utile confrontare lo stato di convalida con la visibilit\u00e0 BGP da pi\u00f9 posizioni.<\/p>\n\n\n\n RPKI deve essere considerato come un input per la politica di instradamento, piuttosto che una sostituzione universale per i filtri di prefisso o il monitoraggio degli instradamenti. I migliori risultati operativi derivano solitamente dall'unione di dati RPKI accurati con registri e record di instradamento ben mantenuti.<\/p>\n\n\n\n Le stesse tre condizioni si applicano sia per IPv4 che per IPv6. In ogni famiglia di indirizzi, il validatore confronta il prefisso annunciato, l'ASN di origine e la lunghezza del prefisso consentita con le ROAs disponibili.<\/p>\n\n\n\n Le operazioni IPv4 comportano spesso prefissi relativamente piccoli, trasferimenti, accordi di leasing e pi\u00f9 provider. Un cambiamento nell'ASN originale o l'utilizzo di annunce pi\u00f9 specifiche pu\u00f2 influenzare rapidamente il risultato della validazione. I detentori delle risorse IPv4 dovrebbero rivedere RPKI ogni volta che un blocco viene trasferito, in affitto, spostato tra i provider o annunciato da una nuova posizione.<\/p>\n\n\n\n Le reti IPv6 ricevono spesso allocazioni pi\u00f9 grandi e potrebbero annunciare un insieme mentre utilizzano sottoreti interne pi\u00f9 piccole. La ROA pubblica deve corrispondere ai prefissi effettivamente annunciati a Internet. Se un operatore IPv6 autorizza solo un insieme ma successivamente annuncia route pi\u00f9 specifiche, queste potrebbero diventare non valide a meno che la lunghezza massima non le permetta.<\/p>\n\n\n\n A larger IPv6 address space does not remove the need for origin validation. IPv6 route hijacks and configuration mistakes can still interrupt services. Publishing precise ROAs during the initial IPv6 deployment makes future troubleshooting easier and gives upstream networks a clear authorization signal.<\/p>\n\n\n\n Prima di modificare un ASN, un provider a monte, un piano di aggregazione del percorso o un titolare delle risorse di indirizzo, registrare lo stato attuale di RPKI. Confermare quale ASN origina attualmente il prefisso e se l'annuncio \u00e8 Valido, Non Validato o Non Trovato.<\/p>\n\n\n\n Dopo aver preparato il nuovo progetto di instradamento, confronta le lunghezze dell'origine e del prefisso previste con quelle pianificate nei ROA. Se l'origine cambier\u00e0, pubblica o aggiorna l'autorizzazione prima di annunciare la nuova rotta, quando le condizioni operative lo permettono. Durante una migrazione controllata, potrebbe essere opportuno un'autorizzazione temporanea per entrambe le origini, ma l'accordo deve essere documentato e l'autorizzazione precedente rimossa quando la transizione sar\u00e0 completata.<\/p>\n\n\n\nCosa \u00e8 la Validazione RPKI?<\/h2>\n\n\n\n
Cosa Significa RPKI Valid?<\/h2>\n\n\n\n
203.0.113.0\/24<\/code> e pubblica un ROA che autorizza AS64500<\/code> origine che \/24<\/code>. Se l'azienda annuncia 203.0.113.0\/24<\/code> da AS64500<\/code>, l'annuncio dovrebbe restituire Valido. Lo stesso vale per un esempio IPv6 come 2001:db8:1200::\/48<\/code> quando vengono utilizzati il corretto ASN e la lunghezza del prefisso consentita.<\/p>\n\n\n\nCosa significa RPKI non valido?<\/h2>\n\n\n\n
AS64500<\/code> originare 198.51.100.0\/24<\/code>. Se AS64510<\/code> annuncia che lo stesso prefisso, l'ASN di origine non corrisponde e il percorso diventa non valido. Il risultato pu\u00f2 verificarsi anche quando AS64500<\/code> \u00e8 autorizzato per il \/24<\/code> ma annuncia 198.51.100.0\/25<\/code> mentre la ROA non consente prefissi che specifici.<\/p>\n\n\n\nCosa significa RPKI Non Trovato?<\/h2>\n\n\n\n
La differenza tra Invalid e Not Found<\/h2>\n\n\n\n
AS64500<\/code> per 192.0.2.0\/24<\/code>, ma AS64510<\/code> annuncia il prefisso. La rotta \u00e8 non valida perch\u00e9 l'origine entra in conflitto con l'autorizzazione. Nel secondo caso, l'azienda non ha pubblicato alcun ROA, e AS64500<\/code> annuncia il prefisso. La rotta non \u00e8 stata trovata perch\u00e9 non c'\u00e8 l'autorizzazione per valutarla.<\/p>\n\n\n\nPerch\u00e9 un percorso legittimo pu\u00f2 diventare non valido?<\/h2>\n\n\n\n
\/20<\/code>, pubblica un ROA con una lunghezza massima di \/20<\/code>e successivamente annunciare due \/21<\/code> percorsi per l'ingegneria del traffico. Queste notifiche pi\u00f9 specifiche potrebbero non essere coperte dall'autorizzazione originale. La configurazione BGP pu\u00f2 essere intenzionale, ma la politica RPKI \u00e8 troppo restrittiva per il nuovo design.<\/p>\n\n\n\nCome risolvere un risultato RPKI non valido<\/h2>\n\n\n\n
Come i risultati RPKI influenzano il routing BGP<\/h2>\n\n\n\n
RPKI Validation for IPv4 and IPv6<\/h2>\n\n\n\n
Come verificare lo stato RPKI prima di un cambiamento di rete<\/h2>\n\n\n\n