RPKI e ROA: cosa devono fare davvero chi acquista e chi affitta

Perché non è più facoltativo

Per anni l’RPKI è stato qualcosa che gli operatori consideravano una buona idea senza mai arrivare a farla. Le cose sono cambiate quando le grandi reti hanno iniziato ad applicarlo davvero. I principali provider di transito, le grandi piattaforme cloud e diverse grandi reti di contenuti eseguono ora la Route Origin Validation e scartano le route che risultano invalid.

La conseguenza pratica è netta. Un prefisso con una ROA sbagliata non è solo non protetto: è irraggiungibile da una quota crescente di internet. E il guasto è parziale e confuso: alcuni utenti ti raggiungono, altri no, e i traceroute sembrano a posto da dovunque tu stia facendo i test.

Se acquisti o affitti spazio di indirizzi, è il dettaglio di configurazione che più facilmente ti costa una giornata.

Cos’è davvero una ROA

L’RPKI è un sistema di attestazioni crittografiche legato al registro degli indirizzi. L’oggetto che conta ogni giorno è la Route Origin Authorization, o ROA, e contiene esattamente tre cose:

• Il prefisso. Per esempio 192.0.2.0/24.
• L’AS di origine. Il numero di sistema autonomo autorizzato ad annunciarlo.
• Una lunghezza massima. Il prefisso più lungo che può essere annunciato all’interno di quel blocco.

Questo è tutto l’oggetto. È una dichiarazione firmata dal titolare degli indirizzi che dice “questo AS può originare questo spazio, fino a questa dimensione”. I router non la leggono direttamente. I validatori scaricano e verificano i dati RPKI e passano il risultato ai router, che classificano ogni route come valid, invalid o not-found.

Ogni route finisce in uno di tre stati. Valid: una ROA copre il prefisso e l’annuncio corrisponde. NotFound, che molti strumenti mostrano come Unknown: nessuna ROA copre il prefisso. Invalid: una ROA copre il prefisso, ma l’annuncio la contraddice, perché arriva dall’AS sbagliato o con un prefisso più lungo di quanto la lunghezza massima consenta.

L’ordine di questi stati conta più di quanto si pensi. Una route senza ROA viene comunque accettata quasi ovunque: non è protetta, ma passa. Una route che risulta Invalid viene scartata da ogni rete che applica la validazione. Nessuna ROA è meglio di una ROA sbagliata. L’obiettivo è una ROA corretta, ma se il giorno dell’annuncio i dettagli non sono definiti, annunciare senza ROA e aggiungerla quando lo sono è molto più sicuro che pubblicarne una che contraddice ciò che invii.

Chi la crea dipende da come hai ottenuto lo spazio

Qui si inciampa di continuo, quindi vale la pena essere espliciti.

Se hai acquistato il blocco, è registrato a tuo nome e la ROA la crei tu nel portale del tuo registro, o chiedi di crearla al tuo LIR sponsor se è lui a tenere per te il rapporto con il registro. Fallo dopo che il trasferimento è completato, non prima, perché l’oggetto deve essere creato sotto il nuovo titolare. Lo spazio legacy acquistato nella regione del RIPE NCC ha bisogno di un contratto con il RIPE NCC o con un LIR sponsor prima di poter avere una ROA (il RIPE NCC).

Se affitti, il blocco non è registrato a tuo nome e non puoi creare la ROA. La crea il titolare, per il tuo ASN. Questo significa che devi dirgli due cose fin dall’inizio: l’ASN da cui annuncerai, e se intendi annunciare qualcosa di più specifico dell’intero blocco. Un affitto in cui la ROA non è stata creata per il tuo ASN risulterà invalid nel momento in cui lo annunci.

Se annunci tramite un cloud provider con il BYOIP, la ROA di solito deve indicare l’ASN del provider e non il tuo, perché è la sua rete a originare la route: AS16509 e AS14618 su AWS, AS8075 su Azure, AS396982 su Google Cloud nel suo Premium tier. Alcuni provider ti permettono invece di originare dal tuo ASN, con una tua sessione BGP (Vultr, Cherry Servers) o come opzione “bring your own ASN” in aggiunta al BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). In quel caso una ROA indica il tuo ASN, e AWS e Oracle Cloud ne vogliono anche una che indichi il loro. La maggior parte dei provider documenta l’ASN che la ROA deve indicare, e alcuni, tra cui Gcore, lo danno solo su richiesta, quindi verifica prima di creare qualsiasi cosa; le nostre guide per provider li elencano.

I due errori che causano disservizi

Quasi tutti i guasti RPKI reali si riducono alla lunghezza massima.

Impostarla troppo permissiva. Una ROA per 192.0.2.0/24 con lunghezza massima /32 significa che qualsiasi annuncio di qualsiasi dimensione dentro quel blocco risulta valid. Questo vanifica buona parte dello scopo: un dirottatore che annuncia una route più specifica dal tuo numero AS risulta comunque valid, e in BGP vincono le route più specifiche. L’impostazione sicura predefinita è una lunghezza massima uguale alla lunghezza del prefisso, a meno che tu non abbia un motivo concreto per fare altrimenti.

Impostarla troppo rigida. Se annunci un /24 coperto da una ROA e poi devi deaggregarlo in due /25 per il traffic engineering, quei /25 diventano subito invalid e spariscono da gran parte di internet. Se prevedi di annunciare prefissi più specifici, la ROA deve consentirlo prima che inizi.

La regola che evita entrambi: fai in modo che la ROA descriva esattamente ciò che annunci davvero, e aggiornala nella stessa finestra di modifica di qualsiasi cambio di routing, non dopo.

ASPA: il livello successivo

Una ROA protegge il primo anello di una route: chi può originarla. Non dice nulla del percorso successivo, che è dove avvengono i route leak, quando una rete ripassa route che avrebbe dovuto tenere per sé. ASPA, Autonomous System Provider Authorization, copre una parte di questo vuoto.

Un oggetto ASPA è firmato dal titolare di un numero AS ed elenca gli AS che sono i suoi upstream. Le reti che lo validano possono rifiutare un percorso in cui il tuo AS sembra raggiungere internet tramite qualcuno che non è il tuo provider. È uno standard IETF emergente. Il RIPE NCC lo descrive come pronto per l’uso nella firma, e anche l’ARIN e l’APNIC permettono ai titolari di firmare ASPA (i registri a confronto).

• Se hai un tuo ASN, pubblica un ASPA che elenchi ogni upstream che porta le tue route verso internet. Lascia fuori i peer e i tuoi clienti.
• Tienilo aggiornato. Un provider che manca dall’oggetto può far rifiutare le tue route tramite quel provider dalle reti che applicano ASPA, quindi aggiungi un nuovo transito prima di attivarlo e rimuovi un vecchio transito dopo averlo disattivato.
• Porti il tuo ASN in un cloud? AWS raccomanda un ASPA che elenchi AS16509 e AS14618 come provider del tuo ASN; senza di essi, le route che riannuncia per te non superano la validazione ASPA.
• Affitti? L’ASPA appartiene al tuo ASN, non al prefisso, quindi lo pubblichi tu, non noi.

La checklist

Prima che lo spazio porti traffico di produzione:

• La ROA esiste per il prefisso corretto e l’AS di origine corretto.
• La lunghezza massima corrisponde al tuo piano di annunci reale.
• Ci sono anche i route object IRR. L’RPKI non li ha sostituiti. Molti upstream costruiscono ancora i filtri di prefissi dai dati IRR, quindi una ROA valida senza un route object corrispondente ti fa comunque filtrare.
• L’ASPA elenca ogni upstream, se ne pubblichi uno, e nessun peer o cliente.
• Valida dall’esterno. Controlla da un looking glass esterno o da un validatore RPKI, non dalla tua rete, che accetterà volentieri le tue route.
• Fai pulizia quando esci. Quando un affitto termina o smetti di annunciare un blocco, la ROA va ritirata o aggiornata. Una ROA obsoleta che punta a un ASN che non annuncia più lo spazio è un problema per chi lo riceve dopo.

Dove entra RTM Networks

Creiamo e manteniamo le ROA come parte sia dell’affitto sia della sponsorizzazione, non come extra (affitto IPv4, sponsorizzazione PI e ASN). Per un affitto, dicci l’ASN da cui annuncerai, o il cloud provider a cui porti lo spazio, e se ti servono prefissi più specifici, e la ROA è configurata prima della consegna. Per le risorse sponsorizzate gestiamo la configurazione RPKI insieme agli altri oggetti di registro.

Se prendi in carico spazio da altrove, chi configura l’RPKI dipende dalla strada: chi acquista lo fa per il blocco stesso, e in un affitto lo fa chi affitta. Possiamo verificare se per il blocco esiste una ROA e, se esiste, se è valida.