RPKI e ROA: come si mette in sicurezza il routing BGP

Il BGP, il protocollo che tiene insieme Internet, nasce senza alcun meccanismo di sicurezza: un AS puo' annunciare qualsiasi prefisso, anche uno che non gli appartiene. Da qui nascono i route hijack, volontari o accidentali, che dirottano il traffico verso reti sbagliate. RPKI e' la risposta a questo problema strutturale.

Cos'e' RPKI

RPKI (Resource Public Key Infrastructure) e' un'infrastruttura a chiave pubblica che lega in modo crittograficamente verificabile un blocco di indirizzi IP all'AS autorizzato ad annunciarlo. I Regional Internet Registry (per l'Europa, RIPE NCC) fanno da trust anchor: emettono certificati che attestano "questo prefisso e' assegnato a questo titolare".

Su questa catena di fiducia si appoggiano due operazioni distinte:

• Firma dei propri prefissi tramite ROA, in modo che gli altri possano validarli.
• Filtraggio dei prefissi ricevuti, scartando quelli che risultano invalidi.

Le due cose sono indipendenti: si puo' firmare senza filtrare e viceversa, ma la protezione reale arriva solo quando entrambe sono attive nell'ecosistema.

Cosa sono le ROA

Una ROA (Route Origin Authorization) e' un oggetto firmato che dichiara tre cose:

• il prefisso (es. 81.29.157.0/24)
• l'AS di origine autorizzato ad annunciarlo
• la maxLength, cioe' la lunghezza massima del prefisso annunciabile

La maxLength e' il dettaglio piu' frainteso. Se per un /24 si imposta maxLength /24, sono validi solo annunci di quel /24 esatto. Se si imposta /32, diventa valido qualsiasi spezzettamento fino al singolo indirizzo. Una maxLength troppo permissiva apre la porta proprio a quegli hijack che si vuole evitare: l'attaccante annuncia un /25 piu' specifico (vince sul /24 per longest-prefix-match) e l'annuncio risulta comunque RPKI-valid. Regola pratica: impostare maxLength uguale alla lunghezza del prefisso che si annuncia davvero.

I tre stati di validazione

Quando un router con validazione attiva riceve un annuncio, lo classifica in uno dei tre stati:

• Valid: esiste una ROA che copre prefisso e origine, e la lunghezza rientra nella maxLength.
• Invalid: esiste almeno una ROA per quel prefisso, ma l'origine o la lunghezza non corrispondono. E' il caso sospetto.
• NotFound (o Unknown): nessuna ROA copre quel prefisso. Non e' protetto, ma non c'e' violazione.

La policy standard e' semplice: scartare gli Invalid, accettare Valid e NotFound. Non si scartano i NotFound perche' una larga fetta di Internet non e' ancora firmata e farlo isolerebbe la rete.

Come si implementa

Il flusso operativo per un ISP si articola in due fronti.

Lato firma, dal portale del RIR (per Velix, il LIR Portal di RIPE NCC) si crea una ROA per ciascun prefisso assegnato, indicando AS di origine e maxLength corretta. La propagazione nei repository RPKI richiede in genere qualche ora.

Lato validazione, serve un RPKI validator (relying party software come Routinator, rpki-client o FORT) che scarica e verifica le ROA, costruisce una tabella di prefissi validati (VRP) e la espone ai router via protocollo RTR. I router (MikroTik RouterOS supporta RTR, cosi' come Cisco, Juniper, BIRD) si collegano al validator e applicano la policy nei route-map di import.

Schema tipico:

• 1 o 2 validator interni, ridondati
• sessione RTR dai border router al validator
• route policy che marca o scarta gli Invalid in ingresso da peer e transit

Perche' conviene anche al singolo AS

Firmare i propri prefissi con una ROA corretta riduce drasticamente il rischio che qualcuno dirotti il proprio traffico: gli AS che filtrano (e sono sempre di piu', inclusi i grandi transit) rifiuteranno l'annuncio fraudolento perche' Invalid. E' protezione che si ottiene una volta sola e lavora in automatico.

Filtrare gli Invalid in ingresso, dall'altro lato, protegge i propri clienti dal raggiungere destinazioni dirottate. Per un ISP che vende connettivita' come servizio, questo e' un elemento di qualita' e affidabilita' del routing, non un dettaglio tecnico opzionale.

Errori comuni da evitare

• maxLength troppo larga: vanifica la ROA. Tenerla aderente al prefisso reale.
• ROA dimenticate dopo un cambio di routing: se si sposta un prefisso su un altro AS o lo si disaggrega, la ROA va aggiornata prima, altrimenti i propri annunci legittimi diventano Invalid e spariscono da Internet.
• Validazione senza ridondanza: se l'unico validator cade, il router perde la VRP. Con la maggior parte delle implementazioni questo significa trattare tutto come NotFound (fail-open), ma va comunque progettato e monitorato.
• Affidarsi solo a RPKI: RPKI valida l'origine, non l'intero AS-path. Resta utile abbinare filtri IRR e prefix-list sui clienti.

RPKI non risolve ogni attacco al routing, ma elimina la classe piu' comune e dannosa di incidenti BGP con un costo di implementazione modesto. Per un operatore che gestisce un proprio AS e prefissi pubblici, oggi e' parte dello standard minimo di igiene di rete.