RPKI BGP Route Origin Validation: ROV Deployment Guide

Route origin validation (ROV) with RPKI is the cheapest major improvement you can make to Internet routing security: it lets a router check that the AS number originating a prefix is actually authorized to do so, using signed Route Origin Authorizations. This guide explains how the RPKI-to-Router protocol feeds a validation database, shows a working cache-server session and import policy on both Junos and Cisco, and lists the operational habits - monitoring Invalid prefixes before dropping them - that keep ROV from becoming an outage generator.

What a ROA proves, and what it does not

A ROA is a triple: address prefix, maximum length and origin AS. If your prefix is 198.51.100.0/24 with max length 26 and origin AS 64500, then any route whose prefix falls inside 198.51.100.0/24 with a length between 24 and 26 is Valid when originated by AS 64500, and Invalid when originated by anyone else. Prefixes with no covering ROA are Unknown. ROV validates the origin only - it says nothing about path manipulation, so leaks that keep the correct origin still pass. Use it together with prefix filters and, ideally, ASPA or Peerlock-style policies.

Validation states and how they map to policy

The dangerous state is not Invalid, it is Unverified: if every cache session drops and your policy drops Invalid routes, all previously-Invalid routes become Unverified and are suddenly accepted. Track validation counts, not just session state.

Junos: cache session and import policy

set routing-options validation group RPKI-CACHE session 192.0.2.10
set routing-options validation group RPKI-CACHE session 192.0.2.11
set routing-options validation group RPKI-CACHE session 192.0.2.10 refresh-time 300
set routing-options validation group RPKI-CACHE session 192.0.2.10 hold-time 600
set policy-options policy-statement ROV-IMPORT term VALID from validation-database valid
set policy-options policy-statement ROV-IMPORT term VALID then validation-state valid
set policy-options policy-statement ROV-IMPORT term VALID then local-preference 110
set policy-options policy-statement ROV-IMPORT term VALID then accept
set policy-options policy-statement ROV-IMPORT term INVALID from validation-database invalid
set policy-options policy-statement ROV-IMPORT term INVALID then validation-state invalid
set policy-options policy-statement ROV-IMPORT term INVALID then reject
set protocols bgp group EBGP import ROV-IMPORT

show validation database
show validation session
show validation statistics
show route validation-state invalid
show route 198.51.100.0/24 detail

Add set protocols bgp group IBGP family inet unicast validation or a community to carry the validation state across iBGP so you validate at the edge and act at the border. Keep the RPKI cache reachable over a stable path - a loopback, a dedicated VRF, or two caches in different failure domains.

Cisco: origin validation on IOS XE and IOS XR

! IOS XE
Router(config)# router bgp 64500
Router(config-router)# bgp rpki server tcp 192.0.2.10 port 323 refresh 600
Router(config-router)# address-family ipv4 unicast
Router(config-router-af)# bgp rpki route-filter 192.0.2.10
Router(config-router-af)# bgp bestpath origin-as validate

! IOS XR origin validation
Router(config)# rpki cache 192.0.2.10
Router(config-rpki-cache)# transport tcp port 323
Router(config-rpki-cache)# refresh-time 600
Router(config)# route-policy ROV
Router(config-rpl)# if validation-state is invalid then
Router(config-rpl)#   pass
Router(config-rpl)# else
Router(config-rpl)#   set local-preference 150
Router(config-rpl)# endif
Router(config-rpl)# end-policy
Router(config)# bgp 64500
Router(config-bgp)# rpki server 192.0.2.10
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# route-policy ROV in

Verification

Router# show bgp ipv4 unicast rpki servers
Router# show bgp ipv4 unicast rpki table
Router# show bgp ipv4 unicast 198.51.100.0/24
! validation state appears next to the path entry
Router# show bgp ipv4 unicast rpki table invalid
Router# clear bgp ipv4 unicast * soft in        ! re-run policy after DB change

Run the cache session for at least a week in monitor-only mode and count how many of your own or your customers' prefixes show up Invalid - that list is a to-do list of missing or wrong ROAs. Only then flip the drop rule, ideally with a staged policy that rejects only prefixes whose origin is invalid and whose path length is short, so you limit blast radius.

Operational checklist

Publish ROAs for every prefix you advertise including its correct max length; monitor show route validation-state invalid as an alert, not a daily report; keep two cache servers; log changes of validation counts to your monitoring system; and document the rollback - a single policy statement change should restore pre-ROV behaviour in seconds. Related reading on this site: BGP best path selection, prefix-list and route-map filtering, BGP communities and BGP neighbor flapping.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bgp_origin_validation.html