How to deploy RPKI
A practical guide to deploying RPKI: creating ROAs in the RIR portal, running ROV validation on routers, and safely dropping invalid BGP routes.
Last updated:
Deploying RPKI splits into two parallel jobs. On the origination side you create ROA objects for your own prefixes in the RIR portal. On the filtering side you run ROV validation on your routers and drop routes marked invalid. The first job protects your address blocks from hijacking, and the second protects the traffic your network forwards. Both rely on cryptographically signed records anchored in the RIR (RFC 6480, RFC 6482).
Step 1: create ROAs in the RIR portal
A ROA (Route Origin Authorization) is a signed record stating which AS may originate a given prefix and the maximum prefix length allowed (maxLength). In RIPE NCC you create ROAs in the LIR Portal under the RPKI section, using the hosted certification service tied to your resources. Each prefix and AS pairing is evaluated separately, so for AS202520 create a ROA for every IPv4 and IPv6 prefix you originate, with the correct origin AS number.
- Set maxLength sensibly. If you do not plan to deaggregate, set it equal to the prefix length (e.g. /24 for a /24 block) to block hijacks using more-specific prefixes.
- Create a separate ROA for every prefix you actually announce in BGP, including backup and failover routes.
- Check that you do not accidentally create an invalid state for your own announcements, for example by announcing a more-specific prefix than maxLength permits.
- After publication, records propagate to global RPKI repositories within a few to several minutes.
Step 2: run an ROV validator
ROV (Route Origin Validation) is the mechanism that compares an announced prefix and its origin AS against the set of ROAs and assigns a valid, invalid, or not found (unknown) state. Routers do not fetch ROAs directly. They rely on a dedicated validator that builds a verified dataset and serves it over the RTR protocol (RFC 8210). The rules for assigning these states to BGP routes are defined in RFC 6811. Run at least two validators for redundancy and connect them to your edge routers.
Common open-source implementations are Routinator (NLnet Labs), FORT Validator, and rpki-client (OpenBSD). On the router you configure an RTR session to the validator, and the software (Cisco IOS XR, Juniper Junos, Nokia SR OS, BIRD, FRR) automatically tags routes with validation states that you can then use in routing policy.
Step 3: drop invalid routes
The final step is the drop invalids policy. In a route map or import policy you reject every route marked invalid while accepting valid and not found (unknown). You do not reject not found, because a large share of the global address space still has no ROA and blocking it would cut off legitimate traffic. Roll the policy out gradually: first monitor the count of invalid routes, then enable rejection on peering and transit sessions.
Before enabling drop invalids, make sure your own ROAs are correct, otherwise you risk invalidating your own prefixes. Monitor certificate expiry and validator health, because an expired certificate or a validator outage can unexpectedly change validation states.
RPKI in the AS202520 SkyPass network
At AS202520 SkyPass, ROV validation and a drop-invalids policy run on the edge routers in our Warsaw and Wrocław PoPs and on peering sessions at the Polish exchanges (THINX, TPIX, WRIX, 1-IX). If you buy IP transit from us or run BGP peering, correct ROAs for your prefixes mean your routes validate as valid across the network and your traffic is protected against origin hijacks. We are happy to help verify your ROA configuration before turning up a session.
Frequently asked questions
Which RIR portal do I create ROAs in?
In your own RIR's portal. For the European region that is the RIPE NCC LIR Portal (RPKI section). Other RIRs such as ARIN, APNIC, LACNIC, and AFRINIC have their own hosted certification services.
Do I need to run my own validator?
Yes, for filtering you need a validator that builds a verified set of ROAs and serves it to routers over RTR. You can use open-source software such as Routinator, FORT, or rpki-client, ideally in at least two instances.
Should I also drop not found (unknown) routes?
No. Drop only invalid routes. The not-found state means no ROA exists, and it still covers a large share of the address space, so blocking it would cut off legitimate traffic.
How do I set maxLength without hurting myself?
If you do not deaggregate a prefix, set maxLength equal to its length. Too large a maxLength opens the door to hijacks via more-specific prefixes, while too small a value can invalidate your own more-specific announcements.