Per un'Internet più sicura: l'architettura BGP RPKI - parte II (teoria)

PREMESSA: questo è il secondo di tre post scritti congiuntamente dal sottoscritto e da Flavio Luciani, Chief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog. Prima di leggere questo post è consigliabile leggere il primo, che trovate a qui. 

L'ARCHITETTURA BGP RPKI: SCHEMA A BLOCCHI

L’architettura BGP RPKI, il cui schema a blocchi è riportato nella figura seguente, è basata su dei database (RPKI repository), dove sono contenute le informazioni sui ROA, informazioni che possono essere immesse direttamente dai RIR o anche dai NIR/LIR/ISP (verificate comunque dai RIR) attraverso un particolare Publication Protocol. Di solito per questo i RIR mettono a disposizione delle interfacce web semplificate, che consentono di nascondere agli end user tutte le complessità legate ai Certificati Digitali, focalizzando l’attenzione sulla sola creazione e pubblicazione dei ROA.

Ciascun RPKI repository, oltre ai ROA, mantiene anche una lista di sub-RPKI repository (anche detti Trust Anchors) che vengono utilizzati per sincronizzare le informazioni sui ROA e quindi realizzare un unico RPKI repository virtuale a livello mondiale.

Sulla base dei ROA contenuti nei RPKI repository, un AS può validare la correttezza degli annunci ricevuti e scegliere in modo selettivo gli annunci che vuole accettare o meno.

Affinché tutto ciò sia efficace, è necessaria per un AS la certezza che le informazioni dei RPKI repository siano corrette e sincronizzate a livello mondiale. L’architettura RPKI prevede una gerarchia di RPKI repository e quindi di Certificali Digitali, che segue la stessa gerarchia prevista per l’assegnazione degli indirizzi IP, che può essere semplificata come segue: IANA→RIR→NIR/LIR. I 5 RIR mondiali hanno il compito di gestire ciascuno il RPKI repository dei ROA della propria area, e di mettere queste informazioni a disposizione degli altri RIR e degli ISP di tutto il mondo. 

Lato ISP, l’architettura prevede l’utilizzo di server denominati RPKI Validator, che a loro volta si interfacciano con i RPKI repository dei vari RIR per effettuare un download locale dei ROA. I router di Edge dell’ISP (ASBR), attraverso il protocollo standard RPKI-to-Router Protocol (RFC 6810 - The Resource Public Key Infrastructure (RPKI) to Router Protocol, Gennaio 2013), scaricano localmente i ROA presenti nel RPKI Validator, inserendoli in una RPKI Table. All’arrivo di un annuncio BGP, un router può così inferire sulla validità o meno degli annunci che riceve, confrontando il contenuto degli annunci con quello dei ROA presenti nella propria RPKI Table.

I RPKI Validator sono basati di solito su software Open Source. I più noti sono I seguenti:

• Routinator
• Ripe NCC Validator
• OctoRPKI
• Rcynic

RPKI E PREFIX HIJACKING

Le problematiche di Prefix Hijacking nell'Internet sono state illustrate nel post precedente a questo. Qui vogliamo mettere in evidenza come l'architettura può essere di aiuto ad evitare incidenti di questo tipo.

La figura seguente riporta un classico esempio di Prefix Hijacking che si ha in assenza di alcun controllo sull’origine dei prefissi annunciati (NOTA: nell'esempio sono utilizzati sia prefissi che numeri di AS privati, cosa non ammessa nell'Internet. I concetti comunque non cambiano).

Nella figura, l’AS 65201, senza alcuna autorizzazione, annuncia la subnet 10.1.5.0/24. Un AS dell’Internet, nella figura esemplificato dall’AS 65000, riceverà così due annunci, uno dell’intero prefisso 10.1.4.0/22, originato legittimamente dall’AS 65101, e uno della subnet più specifica 10.1.5.0/24, originato illegittimamente dall’AS 65201, che non è autorizzato ad annunciare né il prefisso 10.1.4.0/22 né alcuna sua subnet.

Il BGP considera questi due prefissi come diversi e quindi eleggerà due best path, che entrambi andranno nella tabella di routing IP dei router dell’AS 65000. Per la regola del Longest Match Prefix, una porzione del traffico diretto al prefisso 10.1.4.0/22, quello diretto verso la subnet 10.1.5.0/24, sarà deviata verso l’AS 65201, finendo in un black-hole, e ancora peggio, dando all’AS 65201 la possibilità di "spiare" il traffico.

Alla radice del problema, anche qui vi è il fatto che il BGP non esercita alcun controllo sull’identità di chi immette i prefissi nell’Internet. Come già citato nel primo post, l’unico strumento possibile è l’implementazione di filtri, che però non tutti utilizzano, e poi aumenterebbe di molto la complessità delle configurazioni e non risolverebbe il problema. Ad esempio, come fa un AS intermedio a sapere se un AS remoto è autorizzato o meno ad annunciare un prefisso?

La soluzione migliore per risolvere il problema, è quella di utilizzare l’architettura RPKI. La figura seguente fa riferimento all’esempio precedente, ma con la sostanziale differenza che l’AS 65000 controlla attraverso un suo RPKI Validator, la legittimità dell’annuncio ricevuto.

Poiché il RPKI Validator dichiara l’annuncio ricevuto non valido, il router dell’AS 65000 scarta l’annuncio, evitando così il problema del Prefix Hijacking (che ovviamente non ha impatto sull’AS 65000, ma sull’AS 65101). In realtà il tipo di decisione che l’AS 65000 prende potrebbe essere diverso, anche se lo scarto è la decisione più sensata.

ROUTE ORIGIN AUTHORIZATION (ROA)

I ROA sono l’elemento chiave dell’architettura BGP RPKI. Possono essere visti come degli oggetti che forniscono un mezzo per verificare se un AS è autorizzato ad annunciare un determinato prefisso IP. Ogni ROA ha 4 componenti:

• Un prefisso IPv4 o IPv6, con una determinata lunghezza della maschera. Tipicamente è un prefisso assegnato da un RIR a un NIR/LIR/ISP
• Una lunghezza massima della maschera, che specifica quali subnet IP del prefisso originato possono essere annunciate.
• Il numero dell’AS che origina il prefisso IP o una sua subnet ammessa, ossia con lunghezza della maschera inferiore o al più uguale a quella specificata nel punto precedente.
• Una firma digitale, basata sul sistema chiave pubblica/chiave privata.

Il formato dei ROA e il loro utilizzo è descritto nella RFC 6811 - BGP Prefix Origin Validation, del Gennaio 2013.

Per la creazione dei ROA, i RIR forniscono una soluzione hosted nascondendo tutti i dettagli relativi alla complessità crittografica. Un operatore deve focalizzare la propria attenzione solo sulla creazione e pubblicazione dei ROA per i prefissi annunciati.

La prima cosa da fare è accedere al portale del RIR di riferimento (in questa guida faremo riferimento al portale di RIPE NCC). Una volta autenticati, cliccare sul tab "My Resources".

Nella schermata successiva, cliccare nel menu a sinistra sulla voce "RPKI dashboard" e quindi sul tab "Route Origin Authorisations (ROAs)".

Da qui è possibile visualizzare l'elenco dei ROA creati, aggiungerne di nuovi oppure cancellarli. Nel momento in cui si crea un nuovo ROA è necessario specificare l'AS di origine, il prefisso e la massima lunghezza della maschera.

ROA CON AS ORIGINE = 0

Il numero di AS = 0 è indicato nei registri IANA come riservato (vedi questo link). La RFC 6491 - Resource Public Key Infrastructure (RPKI) Objects Issued by IANA, specifica che il valore AS = 0 in un ROA va utilizzato per identificare prefissi che non devono essere annunciati nell’Internet e quindi non utilizzabili per il routing dei pacchetti. Questo consente a chi detiene un determinato prefisso IP di indicare che il prefisso ed eventualmente tutte le sue subnet IP, non può essere utilizzato per il routing dei pacchetti IP. 

Nella definizione di un ROA con AS = 0, è buona pratica definire la lunghezza massima della maschera uguale alla lunghezza della maschera del prefisso, anche se qualcuno preferisce definire come lunghezza massima della maschera il valore 32 per IPv4 e 128 per IPv6. Ma il risultato finale non cambia. 

L’utilizzo dell’AS = 0 è stato specificato nella RFC 7607 - Codification of AS 0 Processing, Agosto 2015. 

VALIDAZIONE DI UN ANNUNCIO

Il processo di validazione di un annuncio BGP dell’address-family IPv4 o IPv6 unicast, si basa su un confronto tra le informazioni contenute nell’annuncio, e i ROA presenti nel database del router stesso, scaricati dal RPKI Validator.

I possibili risultati del processo di validazione, come descritto nella RFC 6811, sono tre: Valid, Invalid e NotFound. Per vederne il significato, supponiamo di voler validare un annuncio BGP delle address-family IPv4 o IPv6 unicast, che contiene le seguenti informazioni:

• NLRI = Pfx/Mask 
• AS Origine = AS-X 

I possibili risultati del processo di validazione sono i seguenti

• Valid: nel RPKI Validator esiste un ROA = <Pfx-ROA/Mask-ROA; Max-Maschera; AS-ROA> con AS-X = AS-ROA, Pfx/Mask è un prefisso più specifico di Pfx-ROA/Mask-ROA  e Mask ≤ Max-Maschera.
• Invalid: nel RPKI Validator esiste un ROA = <Pfx-ROA/Mask-ROA; Max-Maschera; AS-ROA>, con Pfx/Mask che è un prefisso più specifico di Pfx-ROA/Mask-ROA, ma o AS-X ≠ AS-ROA e/o  Mask > Max-Maschera.
• NotFound: nel RPKI Validator non esiste alcun ROA = <Pfx-ROA/Mask-ROA; Max-Maschera; AS-ROA> per cui Pfx/Mask è un prefisso più specifico di Pfx-ROA/Mask-ROA.

La figura seguente riporta un esempio che aiuta a capire meglio gli stati di validazione RPKI di un annuncio BGP. 

Gli annunci vengono confrontati con un ROA caratterizzato da:

• Pfx-ROA/Mask-ROA = 79.140.80.0/20
• Max-Maschera = 24
• AS-ROA = 6762

Rispetto a questo ROA, i primi due annunci hanno stato di validazione Valid poiché entrambi originati dall’AS 6762, ed entrambi contengono un prefisso IPv4 che è subnet del prefisso 79.140.80.0/20 e hanno lunghezza della maschera, rispettivamente pari a 21 e 22, inferiore al valore di Max-Maschera del ROA, pari a 20.

Il terzo annuncio, del prefisso 79.140.84.0/22 originato dall’AS 2914, ha stato di validazione Invalid poiché è si una subnet del prefisso 79.140.80.0/20 con lunghezza della maschera inferiore al valore di Max-Maschera del ROA, ma è originato da un AS (= 2914) diverso da quello presente nel ROA (AS-ROA = 6762).

Il quarto annuncio, del prefisso 79.140.91.0/25 originato dall’AS 6762, ha stato di validazione Invalid poiché è si una subnet del prefisso 79.140.80.0/20 originata dallo stesso AS presente nel ROA (AS-ROA = 6762), ma con lunghezza della maschera (= 25) superiore al valore di Max-Maschera del ROA.

Infine, l’ultimo annuncio, del prefisso 79.140.0.0/16 originato dall’AS 1299, ha stato di validazione NotFound poiché non è una subnet del prefisso 79.140.80.0/20. Avrebbe avuto stato di validazione NotFound anche se a originare l’annuncio fosse stato l’AS 6762.

NOTA: nel caso di ROA con AS-ROA = 0, il risultato del processo di validazione è sempre Invalid.

E qui finisce la poesia (la teoria!), e quindi è ora di passare alla prosa (l'implementazione pratica!), Ma per questo dovete attendere il terzo post...