Internet si basa su un sistema di instradamento globale che consente a reti, data center, piattaforme cloud, provider di servizi Internet e aziende di scambiare traffico. Uno dei protocolli pi\u00f9 importanti in questo sistema \u00e8 il Border Gateway Protocol, comunemente noto come BGP. BGP permette alle reti indipendenti di annunciare gli intervalli di indirizzi IP che possono raggiungere. Senza BGP, l'Internet moderno non sarebbe in grado di collegare milioni di reti attraverso diversi paesi e fornitori. Tuttavia, BGP \u00e8 stato originariamente progettato per lo scambio di informazioni di instradamento basato principalmente sulla fiducia. Quando una rete annuncia un prefisso IP, altre reti potrebbero accettare l'annuncio senza disporre di un forte metodo crittografico per confermare se quella rete sia effettivamente autorizzata a utilizzare il prefisso. Questo crea un problema di sicurezza. Un annuncio di percorso errato o malevolo pu\u00f2 reindirizzare il traffico, interrompere i servizi o esporre i dati a percorsi indesiderati.<\/p>\n\n\n\n
Il RPKI \u00e8 stato sviluppato per migliorare la sicurezza del routing su Internet. Il nome sta per Resource Public Key Infrastructure (Infrastruttura a chiave pubblica delle risorse). Fornisce un modo per collegare le risorse numeriche di Internet, come i prefissi IPv4 e IPv6, con il numero di sistema autonomo autorizzato a originarli. Gli operatori di rete possono quindi utilizzare queste informazioni per determinare se un annuncio BGP \u00e8 coerente con l'autorizzazione registrata.<\/p>\n\n\n\n
Per le aziende che gestiscono il proprio ASN, amministrano risorse IP, utilizzano pi\u00f9 provider upstream o prevedono di annunciare spazi IPv4 o IPv6, comprendere RPKI sta diventando sempre pi\u00f9 importante. RPKI non sostituisce BGP e non risolve ogni problema di routing. Fornisce invece un ulteriore livello di verifica che aiuta le reti a prendere decisioni di routing pi\u00f9 sicure.<\/p>\n\n\n\n
RPKI \u00e8 un framework di sicurezza che utilizza certificati digitali e registri crittografici per verificare la relazione tra un prefisso di indirizzi IP e un ASN di origine. Un prefisso IP \u00e8 un blocco di indirizzi, come un IPv4 L'idea di base \u00e8 semplice. Un'organizzazione autorizzata a utilizzare un prefisso IP pubblica una dichiarazione firmata che identifica quale ASN (Autonomous System Number) ha il permesso di originare tale prefisso in BGP. Le reti che ricevono annunci BGP possono confrontare l'annuncio con le informazioni pubblicate. Se l'annuncio corrisponde, pu\u00f2 essere considerato autorizzato. Se entra in conflitto con le informazioni, l'annuncio potrebbe essere considerato sospetto o non valido.<\/p>\n\n\n\n I record utilizzati per esprimere questa autorizzazione sono comunemente chiamati Autorizzazioni di origine del percorso, o ROA. Un ROA identifica un prefisso IP, un ASN di origine autorizzato e, quando applicabile, la lunghezza massima del prefisso che l'ASN \u00e8 autorizzato ad annunciare. Sebbene i ROA siano una parte importante di RPKI, questo articolo si concentra sullo scopo pi\u00f9 ampio di RPKI e su come migliora la sicurezza del routing.<\/p>\n\n\n\n Il RPKI \u00e8 generalmente gestito tramite i Registri Internet Regionali, tra cui RIPE NCC, ARIN, APNIC, LACNIC e AFRINIC. A seconda della regione e del tipo di risorsa, il titolare delle risorse o l\u2019organizzazione sponsor pu\u00f2 creare e gestire le relative autorizzazioni attraverso i sistemi del registro.<\/p>\n\n\n\n Il BGP \u00e8 stato creato in un periodo in cui Internet era pi\u00f9 piccolo e il numero di reti partecipanti era limitato. Il suo scopo principale era lo scambio di informazioni di raggiungibilit\u00e0 tra sistemi autonomi. Il BGP pu\u00f2 selezionare percorsi in base a criteri, lunghezza del percorso, preferenza locale e altri attributi, ma il protocollo stesso non verifica automaticamente se un ASN \u00e8 autorizzato ad originare un determinato prefisso IP.<\/p>\n\n\n\n Questo significa che un errore di configurazione pu\u00f2 talvolta apparire simile a un annuncio malevolo. Se una rete annuncia accidentalmente un prefisso appartenente ad un'altra organizzazione, le altre reti potrebbero inizialmente accettare la rotta. Il risultato pu\u00f2 essere il traffico diretto verso la destinazione sbagliata, la perdita di connettivit\u00e0 o un routing instabile.<\/p>\n\n\n\n Un esempio ben noto \u00e8 un'interruzione di rotta o un hijack di prefisso. In un hijack, un ASN annuncia un prefisso che non controlla o che non dovrebbe originare. L'annuncio pu\u00f2 essere pi\u00f9 specifico rispetto alla rotta legittima, oppure pu\u00f2 raggiungere abbastanza reti da influenzare il traffico. Anche quando l'incidente \u00e8 accidentale, l'impatto operativo pu\u00f2 essere significativo.<\/p>\n\n\n\n Il RPKI aiuta fornendo agli operatori di rete una fonte esterna di informazioni di autorizzazione. Invece di fare affidamento esclusivamente sul contenuto di un annuncio BGP, un router o un sistema di sicurezza del routing pu\u00f2 verificare se l'ASN di origine \u00e8 stato autorizzato dal titolare dello spazio degli indirizzi. Questo non previene ogni incidente di routing, ma rende pi\u00f9 facile identificare e filtrare una classe importante di errori di routing.<\/p>\n\n\n\n Il RPKI funziona attraverso una catena di fiducia. Le risorse numeriche Internet sono gestite dai Registri Internet Regionali, e questi registri forniscono la base per i certificati digitali pertinenti. Il titolare di una risorsa IP pu\u00f2 creare un record di autorizzazione che indica quale ASN pu\u00f2 originare il prefisso.<\/p>\n\n\n\n I record firmati vengono raccolti in repository accessibili tramite software di sicurezza di routing. Un operatore di rete esegue un validatore RPKI o utilizza un servizio che effettua la convalida per suo conto. Il validatore scarica i record disponibili, verifica le loro firme, controlla se sono aggiornati e produce un dataset convalidato.<\/p>\n\n\n\n Il dataset convalidato viene quindi collegato all'infrastruttura di instradamento della rete. Quando viene ricevuta una rotta BGP, il router o il sistema di policy di routing confronta il prefisso annunciato e l'ASN di origine con le informazioni RPKI convalidate. Il risultato viene normalmente classificato come Valido, Non valido o Non trovato.<\/p>\n\n\n\n Questo processo avviene separatamente dalla sessione BGP stessa. BGP continua a scambiare informazioni di routing, mentre RPKI fornisce dati di autorizzazione aggiuntivi che possono essere utilizzati nella politica di routing. Una rete pu\u00f2 decidere come gestire ciascun risultato della convalida. Ad esempio, pu\u00f2 rifiutare le route Invalid, assegnare loro una preferenza inferiore o generare avvisi per un'ulteriore revisione.<\/p>\n\n\n\n Il processo \u00e8 progettato per essere distribuito e scalabile. Le grandi reti possono convalidare migliaia di prefissi senza richiedere a ogni organizzazione di stabilire una relazione diretta con ogni altra rete. Questo \u00e8 importante perch\u00e9 Internet include un enorme numero di operatori indipendenti con politiche e ambienti tecnici diversi.<\/p>\n\n\n\n Un'autorizzazione di origine del percorso (Route Origin Authorization) \u00e8 un record firmato che indica quale ASN \u00e8 autorizzato a originare un determinato prefisso IP. \u00c8 una delle parti pi\u00f9 visibili e pratiche della distribuzione di RPKI.<\/p>\n\n\n\n Ad esempio, un'organizzazione pu\u00f2 controllare il prefisso IPv4 L'autorizzazione pu\u00f2 anche specificare una lunghezza massima del prefisso. Questo \u00e8 importante perch\u00e9 una rete potrebbe voler consentire all'ASN di origine di annunciare il prefisso aggregato esatto, ma non prefissi pi\u00f9 specifici e di dimensione inferiore. Una lunghezza massima selezionata con cura pu\u00f2 ridurre il rischio che un annuncio imprevisto venga considerato autorizzato.<\/p>\n\n\n\n La configurazione ROA richiede attenzione poich\u00e9 un record errato pu\u00f2 far apparire non valida una rotta legittima. Se un'organizzazione cambia il proprio fornitore di transito, sposta un prefisso a un ASN diverso, suddivide un annuncio in prefissi pi\u00f9 specifici o trasferisce le risorse a un altro titolare, i record di autorizzazione potrebbero dover essere aggiornati. Un record obsoleto pu\u00f2 causare un'interruzione del servizio anche quando la configurazione BGP \u00e8 corretta.<\/p>\n\n\n\n Un articolo futuro pu\u00f2 spiegare come creare un ROA, come scegliere una lunghezza massima e come aggiornare le autorizzazioni durante una migrazione di risorse ASN o IP.<\/p>\n\n\n\n Un risultato Valid indica che un annuncio BGP \u00e8 coperto da un'autorizzazione RPKI applicabile e che l'ASN di origine \u00e8 autorizzato ad annunciare il prefisso. In genere, ci\u00f2 significa che il prefisso annunciato, la lunghezza del prefisso e l'ASN di origine sono coerenti con l'autorizzazione pubblicata.<\/p>\n\n\n\n Un risultato non valido indica che esiste un'autorizzazione, ma l'annuncio BGP non \u00e8 conforme ad essa. Ci\u00f2 pu\u00f2 accadere perch\u00e9 l'ASN di origine non \u00e8 autorizzato, perch\u00e9 l'annuncio \u00e8 pi\u00f9 specifico della lunghezza massima consentita o perch\u00e9 il prefisso si sovrappone a un'autorizzazione per un'origine diversa. Le rotte non valide meritano attenzione immediata poich\u00e9 potrebbero rappresentare un hijack, una configurazione accidentale o una migrazione incompleta.<\/p>\n\n\n\n Un risultato \"Not Found\" indica che non \u00e8 stata trovata alcuna autorizzazione applicabile per l'annuncio. Non significa automaticamente che il percorso sia dannoso o errato. Significa semplicemente che RPKI non pu\u00f2 confermare l'origine utilizzando i record attualmente pubblicati. Molti percorsi legittimi rimangono \"Not Found\" perch\u00e9 il titolare delle risorse non ha creato un'autorizzazione.<\/p>\n\n\n\n La distinzione tra Invalid e Not Found \u00e8 importante. Invalid indica un conflitto con i dati di autorizzazione esistenti, mentre Not Found indica l'assenza di dati di autorizzazione. Gli operatori di rete spesso trattano le route Invalid pi\u00f9 seriamente, ma la loro esatta politica di instradamento dipende dalla loro tolleranza al rischio, dai requisiti del servizio e dalle procedure operative.<\/p>\n\n\n\n Lo spazio degli indirizzi IPv4 \u00e8 limitato e molti prefissi IPv4 sono attualmente utilizzati in complesse configurazioni che coinvolgono provider, data center, piattaforme cloud, societ\u00e0 di leasing e transazioni di trasferimento. Queste configurazioni rendono la precisione del routing particolarmente importante.<\/p>\n\n\n\n Quando un prefisso IPv4 viene trasferito o spostato tra organizzazioni, l'origine BGP pu\u00f2 anche cambiare. Se l'autorizzazione del precedente proprietario rimane attiva mentre il nuovo proprietario annuncia il prefisso da un ASN diverso, la rotta pu\u00f2 diventare RPKI Invalid. Questo \u00e8 uno dei motivi per cui la pianificazione RPKI dovrebbe essere inclusa nei lavori di trasferimento e migrazione IPv4.<\/p>\n\n\n\n Prima di accettare o annunciare un prefisso IPv4, un'organizzazione dovrebbe confermare quale entit\u00e0 controlla la risorsa, quale ASN \u00e8 previsto per l'origine e se i record di autorizzazione pertinenti riflettono il progetto di instradamento pianificato. Il record del registro pubblico, gli annunci BGP e le informazioni RPKI dovrebbero essere esaminati congiuntamente. RPKI \u00e8 particolarmente utile quando un'azienda utilizza pi\u00f9 fornitori di transito. Un'autorizzazione di origine coerente pu\u00f2 proteggere il prefisso indipendentemente dal fornitore upstream che trasporta la rotta. Tuttavia, l'organizzazione deve comunque assicurarsi che tutti i fornitori utilizzino l'ASN corretto e la lunghezza del prefisso appropriata.<\/p>\n\n\n\n Le aziende che valutano un blocco IPv4 possono anche utilizzare strumenti pubblici per esaminare i dati di registrazione attuali, le informazioni sull'ASN di origine, lo stato RPKI e la visibilit\u00e0 BGP. Questi controlli non sostituiscono la due diligence contrattuale o la valutazione della reputazione, ma possono rivelare evidenti incongruenze nel routing prima di una transazione o di un'implementazione.<\/p>\n\n\n\n Le reti IPv6 beneficiano degli stessi principi di convalida dell'origine delle reti IPv4. I prefissi IPv6 vengono annunciati tramite BGP e un'origine errata pu\u00f2 creare rischi simili, tra cui interruzioni del traffico, fughe di rotte e annunci non autorizzati.<\/p>\n\n\n\n Le implementazioni di IPv6 spesso coinvolgono blocchi di indirizzi pi\u00f9 ampi e piani di indirizzamento pi\u00f9 strutturati. Un'organizzazione pu\u00f2 ricevere un'allocazione ampia ed annunciare un aggregato, utilizzando al contempo sotto-reti interne pi\u00f9 piccole per siti, data center o servizi. L'autorizzazione RPKI dovrebbe corrispondere ai prefissi effettivamente destinati al routing pubblico.<\/p>\n\n\n\n Un errore comune \u00e8 assumere che il routing IPv6 sia automaticamente pi\u00f9 sicuro perch\u00e9 IPv6 dispone di uno spazio degli indirizzi molto pi\u00f9 ampio. La dimensione dello spazio degli indirizzi non elimina la necessit\u00e0 di verificare l'origine del percorso. Se un prefisso IPv6 viene annunciato da un ASN errato e non esiste alcuna autorizzazione, altre reti potrebbero avere capacit\u00e0 limitate di distinguere tale annuncio da una rotta legittima. Le organizzazioni che implementano IPv6 dovrebbero includere RPKI nella loro progettazione iniziale del routing anzich\u00e9 attendere fino a quando la rete non \u00e8 completamente operativa. Ci\u00f2 facilita il coordinamento del piano degli indirizzi, dell'utilizzo degli ASN, dei provider upstream e dei record di autorizzazione prima che il traffico in produzione dipenda dall'annuncio.<\/p>\n\n\n\n Il principale vantaggio del RPKI \u00e8 che fornisce un metodo ampiamente riconosciuto per convalidare l'origine di una rotta BGP. Ci\u00f2 offre agli operatori di rete una base pi\u00f9 solida per il filtraggio e il monitoraggio delle annunciazioni rispetto alle sole informazioni BGP.<\/p>\n\n\n\n Il RPKI pu\u00f2 ridurre il rischio di accettare route che sono chiaramente incoerenti con l'autorizzazione dichiarata dal titolare delle risorse. Pu\u00f2 anche aiutare a identificare errori operativi durante le migrazioni di rete, i cambiamenti di provider, le modifiche alla sponsorizzazione degli ASN e i trasferimenti di risorse IPv4 o IPv6.<\/p>\n\n\n\n Per i titolari di risorse IP, RPKI dimostra che l'organizzazione sta gestendo attivamente la sicurezza del routing del proprio spazio di indirizzi. Ci\u00f2 pu\u00f2 migliorare il coordinamento con i fornitori di transito e ridurre le confusioni quando pi\u00f9 parti sono coinvolte nell'annuncio dello stesso prefisso.<\/p>\n\n\n\n Per i fornitori di servizi di transito e le aziende di hosting, la convalida RPKI pu\u00f2 diventare parte di un programma pi\u00f9 ampio di sicurezza del routing. I fornitori possono utilizzare i risultati della convalida insieme ai filtri dei prefissi, ai dati dell'IRR, al monitoraggio BGP e alle politiche di routing interne. Nessuna singola fonte di dati \u00e8 perfetta, ma combinare diversi segnali offre una migliore visibilit\u00e0 operativa.<\/p>\n\n\n\n Anche il RPKI migliora la risposta agli incidenti. Quando appare un annuncio BGP inaspettato, il team di rete pu\u00f2 verificare rapidamente se l'origine \u00e8 autorizzata. Questo pu\u00f2 aiutare a distinguere un potenziale hijack da una modifica di routing legittima ma non documentata.<\/p>\n\n\n\n Il RPKI \u00e8 prezioso, ma non rappresenta una sostituzione completa per la sicurezza del routing. Convalida la relazione tra un prefisso e un ASN di origine. Non dimostra che ogni hop nel percorso BGP sia affidabile e non garantisce che il traffico segua il percorso fisico migliore o pi\u00f9 sicuro.<\/p>\n\n\n\n Il RPKI non crittografa il traffico delle applicazioni. Non protegge le sessioni web, le query DNS, l'email o i dati privati dall'intercettazione. Per questi scopi sono ancora necessarie tecnologie di crittografia come TLS, VPN e protocolli di applicazione sicuri.<\/p>\n\n\n\n Anche il RPKI non impedisce automaticamente ogni tipo di route leak. Una rotta pu\u00f2 essere originata dall'ASN corretto ma comunque propagata in luoghi in cui non dovrebbe apparire. La validazione dell'origine potrebbe classificare tale rotta come Valid poich\u00e9 l'origine \u00e8 autorizzata, anche se il percorso pi\u00f9 ampio \u00e8 operativamente errato.<\/p>\n\n\n\n Il RPKI non dimostra di per s\u00e9 la propriet\u00e0 legale. I registri del registry, i contratti, i documenti di trasferimento e l'autorizzazione organizzativa rimangono importanti. Un risultato Valid indica che il percorso corrisponde a un'autorizzazione pubblicata; ci\u00f2 non conferma che tutti i requisiti commerciali o legali siano stati soddisfatti.<\/p>\n\n\n\n Infine, il RPKI funziona in modo efficace solo quando i record vengono mantenuti. Un'organizzazione che crea autorizzazioni e poi dimentica di aggiornarle dopo un cambiamento del provider o dell'ASN pu\u00f2 causare un'interruzione del routing da sola.<\/p>\n\n\n\n Il primo passo consiste nel creare un inventario di tutti i prefissi IPv4 e IPv6 posseduti, in affitto, sponsorizzati o previsti per l'annuncio dall'organizzazione. Per ogni prefisso, registrare l'ASN di origine previsto, i provider che lo annunciano, la lunghezza del prefisso e se il prefisso \u00e8 attualmente visibile in BGP.<\/p>\n\n\n\n Il passo successivo consiste nel confermare i record del registro e delle risorse. L'organizzazione dovrebbe verificare che lo spazio degli indirizzi sia associato all'account, all'organizzazione, al LIR sponsor o al titolare delle risorse corretto. Se i dati di registrazione pubblici sono obsoleti, devono essere corretti prima di creare nuove autorizzazioni di instradamento. Dopo aver confermato l'inventario delle risorse, l'organizzazione pu\u00f2 creare le opportune registrazioni di autorizzazione tramite il proprio Registro Internet Regionale o il provider sponsor. Il ASN di origine e la lunghezza massima del prefisso dovrebbero riflettere il piano di instradamento effettivo. Se vengono utilizzati pi\u00f9 ASN in modo legittimo, il progetto dovrebbe essere documentato accuratamente invece di aggiungere autorizzazioni generiche senza una ragione chiara.<\/p>\n\n\n\n L'organizzazione dovrebbe quindi convalidare i record utilizzando un validatore RPKI o un servizio di monitoraggio consolidato. \u00c8 importante confermare che gli annunci previsti restituiscano un risultato Valid prima di applicare politiche di filtraggio rigorose al traffico dei clienti o di produzione.<\/p>\n\n\n\n Il deployment dovrebbe essere considerato un processo operativo, non una configurazione una tantum. Le modifiche ai fornitori upstream, allo sponsor dell'ASN, all'aggregazione dei prefissi, alle ubicazioni dei data center e agli accordi di trasferimento IPv4 possono tutti influenzare i record RPKI. Il monitoraggio e la gestione delle modifiche dovrebbero far parte del normale flusso di lavoro di rete.<\/p>\n\n\n\n Un errore comune \u00e8 creare un'autorizzazione per l'ASN di origine errato. Questo accade spesso durante una migrazione del provider, quando l'ASN precedente rimane nel record mentre la rete inizia ad annunciare da un nuovo ASN.<\/p>\n\n\n\n Un altro errore consiste nell'impostare erroneamente la lunghezza massima del prefisso. Se un'organizzazione autorizza solo un aggregato ma annuncia una rotta pi\u00f9 specifica, l'annuncio della rotta pi\u00f9 specifica pu\u00f2 diventare non valido. Se la lunghezza massima viene impostata troppo ampia, l'autorizzazione potrebbe consentire annunci che l'organizzazione non intendeva permettere.<\/p>\n\n\n\n I record obsoleti rappresentano anch'essi un problema significativo. Un'autorizzazione che era corretta diversi anni fa potrebbe non corrispondere pi\u00f9 al design attuale della rete dell'organizzazione. I controlli regolari sono particolarmente importanti dopo un trasferimento IPv4, una fusione, un cambiamento del LIR sponsor o una rinumerazione ASN.<\/p>\n\n\n\n Alcune organizzazioni assumono anche che un risultato \"Not Found\" significhi che un percorso debba essere rifiutato. Nella maggior parte dei casi, \"Not Found\" significa che non esiste alcuna autorizzazione. Dovrebbe essere gestito in base alla politica della rete e al modello di rischio, piuttosto che essere trattato come automaticamente dannoso.<\/p>\n\n\n\n Il RPKI \u00e8 una parte di un approccio pi\u00f9 ampio alla sicurezza del routing. I database IRR contengono oggetti di policy di routing che possono essere utilizzati dagli operatori di rete per generare filtri. Questi oggetti possono descrivere quale ASN dovrebbe originare un prefisso, ma utilizzano un modello di fiducia e validazione diverso da quello del RPKI.<\/p>\n\n\n\n Il monitoraggio BGP mostra ci\u00f2 che viene effettivamente annunciato e dove tale annuncio \u00e8 visibile. Pu\u00f2 rivelare cambiamenti di rotta, origini impreviste, variazioni del percorso e periodi di instabilit\u00e0. RPKI indica se l'origine \u00e8 autorizzata, ma non fornisce la cronologia operativa completa di una rotta.<\/p>\n\n\n\n Per questo motivo, RPKI, IRR e il monitoraggio BGP sono spesso utilizzati insieme. Una revisione robusta del routing pu\u00f2 confrontare il record del registro, l'ASN previsto, l'oggetto IRR, l'autorizzazione RPKI e le osservazioni BGP in tempo reale. Quando queste fonti concordano, la posizione di routing \u00e8 pi\u00f9 facile da comprendere. Quando non concordano, la discrepanza dovrebbe essere indagata prima che una migrazione o un trasferimento venga completato.<\/p>\n\n\n\n La manutenzione del RPKI dovrebbe essere collegata alla gestione dei cambiamenti di rete. Quando un'organizzazione prevede di modificare il proprio ASN di origine, il fornitore upstream, la lunghezza del prefisso o la posizione di annuncio, dovrebbe valutare l'effetto previsto sui record di autorizzazione prima che il cambiamento venga effettuato.<\/p>\n\n\n\n Il monitoraggio dovrebbe avvisare il team di rete quando un prefisso previsto diventa Invalid, quando viene rimossa un'autorizzazione o quando appare un'origine precedentemente non rilevata. Gli avvisi sono pi\u00f9 utili quando includono il prefisso interessato, l'ASN dell'origine, lo stato di convalida corrente e l'ora della modifica.<\/p>\n\n\n\n Le organizzazioni dovrebbero anche documentare chi \u00e8 responsabile della gestione del RPKI. In alcune aziende, il team di ingegneria di rete gestisce i record. In altre, lo LIR sponsorizzante, il fornitore di servizi gestiti o il team di sicurezza si occupa di essi. Una chiara definizione delle responsabilit\u00e0 aiuta a prevenire ritardi durante gli incidenti e le migrazioni dei provider.<\/p>\n\n\n\n Una revisione periodica pu\u00f2 essere programmata mensilmente, trimestralmente o ogni volta che si verifica un cambiamento significativo nel routing. La frequenza appropriata dipende dalle dimensioni e dalla complessit\u00e0 della rete. Il punto importante \u00e8 che RPKI dovrebbe essere considerato come una parte viva del sistema di routing.<\/p>\n\n\n\n No. Una rete pu\u00f2 utilizzare BGP senza pubblicare record di autorizzazione RPKI. Tuttavia, RPKI \u00e8 sempre pi\u00f9 consigliato perch\u00e9 fornisce ad altre reti un modo per convalidare l'origine delle route annunciate dall'organizzazione.<\/p>\n\n\n\n Il RPKI non impedisce fisicamente a un'altra rete di inviare un annuncio BGP non autorizzato. Consente alle reti riceventi di identificare gli annunci che non corrispondono alle autorizzazioni pubblicate. Le reti possono quindi rifiutare, de-preferire o monitorare tali route in base alle proprie politiche.<\/p>\n\n\n\n No. RPKI supports both IPv4 and IPv6 prefixes. The same basic origin validation concept applies to both address families.<\/p>\n\n\n\n Non necessariamente. \"Not Found\" significa che non \u00e8 stata trovata alcuna autorizzazione applicabile. Non dimostra che il percorso sia errato. Tuttavia, i gestori delle risorse dovrebbero considerare la pubblicazione di autorizzazioni accurate affinch\u00e9 altre reti possano convalidare le loro annunci.<\/p>\n\n\n\n No. RPKI e IRR hanno scopi diversi e spesso vengono utilizzati insieme. Alcuni provider utilizzano entrambi i sistemi durante la creazione di filtri di routing e la revisione delle annunciazioni.<\/p>\n\n\n\n Un record errato pu\u00f2 causare la classificazione di un annuncio BGP legittimo come non valido. L'organizzazione dovrebbe rivedere l'ASN di origine, la lunghezza del prefisso e la lunghezza massima, quindi aggiornare l'autorizzazione prima di applicare il filtro delle rotte in modo rigoroso.<\/p>\n\n\n\n RPKI is an important improvement to the security of Internet routing. It gives IP resource holders a way to publish cryptographic authorization for the ASNs that are allowed to originate their IPv4 and IPv6 prefixes. It also gives network operators a practical method for checking whether BGP announcements match that authorization.<\/p>\n\n\n\n Il concetto \u00e8 semplice: il titolare di un prefisso IP pubblica l'origine prevista, e le altre reti convalidano l'annuncio in base a tali informazioni. Il risultato pu\u00f2 aiutare a identificare le rotte autorizzate, le rotte in conflitto e le rotte per cui non \u00e8 stata pubblicata alcuna autorizzazione. RPKI non sostituisce una attenta ingegneria di rete, la gestione dei registri, i record IRR, il monitoraggio BGP o la dovuta diligenza contrattuale. Inoltre, non garantisce che ogni rotta sia sicura o che ogni incidente di routing venga prevenuto. Il suo valore deriva dall'aggiungere un segnale di autorizzazione affidabile al processo di instradamento.<\/p>\n\n\n\n Per le organizzazioni che gestiscono un ASN, uno spazio IPv4, uno spazio IPv6 o pi\u00f9 provider upstream, il RPKI dovrebbe essere integrato nel normale design di routing. Prima di annunciare un prefisso, cambiare provider, completare un trasferimento IPv4 o distribuire una nuova rete IPv6, \u00e8 necessario esaminare congiuntamente i dati del registro, l'ASN di origine, i record di autorizzazione e lo stato BGP in tempo reale. Questo semplice processo pu\u00f2 prevenire errori evitabili e migliorare l'affidabilit\u00e0 complessiva della connettivit\u00e0 Internet.<\/p>\n\n\n\n <\/p>","protected":false},"excerpt":{"rendered":" The Internet depends on a global routing system that allows networks, data centers, cloud platforms, Internet service providers, and enterprises to exchange traffic. One of the most important protocols in this system is the Border Gateway Protocol, commonly known as BGP. BGP allows independent networks to announce which IP address ranges they can reach. Without […]<\/p>\n","protected":false},"author":1,"featured_media":1088,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is RPKI? A Beginner\u2019s Guide to Secure BGP Routing","_seopress_titles_desc":"Learn what RPKI is, how it protects BGP routing, why it matters for IPv4 and IPv6 networks, and how businesses can start using route origin validation.","_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-1086","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\/1086","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=1086"}],"version-history":[{"count":3,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/posts\/1086\/revisions"}],"predecessor-version":[{"id":1091,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/posts\/1086\/revisions\/1091"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/media\/1088"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/media?parent=1086"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/categories?post=1086"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/it\/wp-json\/wp\/v2\/tags?post=1086"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\/24<\/code> or an IPv6 \/48<\/code>. Un ASN identifica una rete indipendente che partecipa al routing BGP.<\/p>\n\n\n\nPerch\u00e9 BGP ha bisogno di RPKI?<\/h2>\n\n\n\n
Come funziona RPKI?<\/h2>\n\n\n\n
Cos'\u00e8 un'autorizzazione di origine del percorso?<\/h2>\n\n\n\n
192.0.2.0\/24<\/code> e utilizza ASN AS64500<\/code> per annunciarlo. L'organizzazione pu\u00f2 creare un'autorizzazione che consenta AS64500<\/code> originare 192.0.2.0\/24<\/code>. Se un altro ASN annuncia successivamente lo stesso prefisso, le reti che eseguono la convalida RPKI possono rilevare che l'origine non corrisponde all'autorizzazione.<\/p>\n\n\n\nCosa significano Valido, Non valido e Non trovato?<\/h2>\n\n\n\n
Why RPKI Matters for IPv4 Networks<\/h2>\n\n\n\n
Why RPKI Matters for IPv6 Networks<\/h2>\n\n\n\n
Quali sono i principali vantaggi del RPKI?<\/h2>\n\n\n\n
Cosa non pu\u00f2 fare il RPKI<\/h2>\n\n\n\n
Come pu\u00f2 un'azienda iniziare a utilizzare RPKI?<\/h2>\n\n\n\n
Errori comuni nel deployment di RPKI<\/h2>\n\n\n\n
RPKI, IRR e monitoraggio BGP<\/h2>\n\n\n\n
Come dovrebbe essere mantenuto il RPKI?<\/h2>\n\n\n\n
Domande frequenti su RPKI<\/h2>\n\n\n\n
No, RPKI is not required to use BGP.<\/h3>\n\n\n\n
Il RPKI previene un hijack BGP?<\/h3>\n\n\n\n
Il RPKI \u00e8 solo per IPv4?<\/h3>\n\n\n\n
Un risultato RPKI \"Not Found\" \u00e8 pericoloso?<\/h3>\n\n\n\n
Il RPKI pu\u00f2 sostituire un oggetto route dell'IRR?<\/h3>\n\n\n\n
Cosa succede se un record RPKI \u00e8 errato?<\/h3>\n\n\n\n