Service provider

Validazione dell'origine delle rotte RPKI su OcNOS: configurare il ROV al peering edge

La validazione dell'origine delle rotte è il controllo più economico che un operatore può aggiungere al bordo di internet, ed è passata da opzionale ad attesa. Questa guida mostra come funziona su OcNOS e come configurarla su un router di peering, con comandi verificati su OcNOS-SP.

Che cos'è la validazione dell'origine delle rotte RPKI?

La Resource Public Key Infrastructure (RPKI) associa un prefisso IP alla rete autorizzata ad annunciarlo tramite un record firmato crittograficamente chiamato Route Origin Authorization (ROA). La Route Origin Validation (ROV) è l'azione che un router esegue quando confronta una rotta BGP in ingresso con quelle ROA e la contrassegna come valid, invalid o not-found. Una rotta è valid quando l'AS di origine e la lunghezza del prefisso corrispondono a una ROA, invalid quando una ROA esiste ma l'origine o la lunghezza sono errate, e not-found quando nessuna ROA copre il prefisso. La ROV blocca in un solo passaggio l'incidente e l'attacco di routing più comuni: una rete che origina un prefisso che non possiede e che invia il traffico di altri operatori nella direzione sbagliata.

Perché RPKI è importante ora

La validazione dell'origine delle rotte non è più un optional. I grandi provider di transito rifiutano le rotte RPKI-invalid per impostazione predefinita, i regolatori nazionali fanno riferimento alla sicurezza del routing nelle loro linee guida e le azioni MANRS considerano la validazione dell'origine e il filtraggio dei prefissi come requisiti fondamentali per una rete seria. Per un operatore che porta l'intera tabella BGP di internet al peering edge, la ROV elimina un'intera categoria di origini errate con pochissimo sforzo. Inoltre si ottiene protezione immediata, perché si beneficia di ogni ROA già esistente senza attendere il resto di internet.

Come OcNOS valida le rotte

OcNOS non ospita il database RPKI sul router. Si connette a un validatore RPKI esterno, chiamato anche cache RPKI-to-Router (RTR), che recupera e verifica crittograficamente le ROA dai trust anchor e consegna al router un insieme pulito di record validati da prefisso a origine. OcNOS mantiene quella tabella validata in memoria, la aggiorna tramite un timer e marca le rotte man mano che le riceve. È possibile puntare il router su più di un validatore per ridondanza. Funziona qualsiasi validatore che parli il protocollo RTR, inclusi Routinator, rpki-client con StayRTR e i deployment Krill di NLnet Labs.

RPKI route origin validation on an OcNOS peering router: an RTR session to an RPKI validator supplies validated ROAs, a valid BGP route from the IXP is accepted, and an RPKI-invalid route is dropped at the peering edge before it reaches the core.
Un router di peering OcNOS mantiene una sessione RTR verso un validatore RPKI, accetta una rotta valid e scarta una rotta RPKI-invalid al bordo prima che raggiunga il core e i clienti.

Come configurare la validazione dell'origine delle rotte RPKI su OcNOS

La configurazione si compone di tre parti: collegare il router a un validatore, lasciare che la tabella validata si popoli e applicare una policy che agisce sul risultato. OcNOS è transazionale, quindi ogni fase viene applicata con commit.

1. Collegare il router ai validatori RPKI

All'interno dell'istanza BGP, puntate il router verso una o due cache RTR. L'indirizzo da solo è un comando completo, e port è facoltativo e il valore predefinito è 3323 per TCP.

configure terminal
router bgp 64500
 bgp rpki server 10.0.0.10 port 3323
 bgp rpki server 10.0.0.11 port 3323
 commit

2. Confrontare lo stato di validazione e scartare le rotte invalid

Usate una route-map per agire sullo stato RPKI. Questa nega le rotte invalid e consente tutto il resto, quindi le rotte valid e not-found vengono accettate mentre quelle invalid vengono scartate.

route-map RPKI-EDGE-IN deny 10
 match rpki invalid
!
route-map RPKI-EDGE-IN permit 20
 commit

3. Applicare la policy in ingresso sulla sessione di peering

Collegate la route-map al peer eBGP nella address family che deve proteggere. Ripetete in address-family ipv6 unicast per IPv6.

router bgp 64500
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map RPKI-EDGE-IN in
  exit
 commit

Come verifico che la validazione RPKI funzioni?

Verificate che la sessione del validatore sia attiva, che la tabella validata contenga voci e che le rotte vengano marcate. OcNOS fornisce tre comandi per questo.

OcNOS# show bgp rpki server
OcNOS# show bgp rpki table
OcNOS# show bgp rpki

show bgp rpki server riporta ciascun validatore e se la sua sessione è stabilita, show bgp rpki table elenca i record validati da prefisso a origine che il router ha scaricato, e show bgp rpki riassume lo stato RPKI. Una volta stabilita la sessione e popolata la tabella, le rotte che non superano la validazione portano lo stato invalid e vengono scartate dalla route-map al bordo.

RPKI al peering edge

Origin validation is one layer of a secure peering edge, not the whole of it. On a complete open peering router, RPKI invalid-route rejection sits alongside prefix filtering aligned with MANRS, BGP FlowSpec for DDoS mitigation, and remote-triggered black-holing, so the router enforces routing hygiene and attack response from the same place it carries the full table. See how the roles fit together on the router IP core e di peering aperto.

Condividi