What is route origin validation?

By Anirban Datta, MANRS ambassador, and Zobair Khan, MANRS fellow

In this post, we look at what route origin validation (ROV) is, and why it is important for creating a more secure Internet for all.

The Internet is an interconnection of autonomous systems (AS) which use Border Gateway Protocol (BGP) to exchange routing or reachability information. BGP relies on trust among network operators to secure their systems well and to send correct data since there is no built-in validation in this protocol.  

Fig-1: Border Gateway Protocol runs on trust to build the Internet.

The problems with trust

Relying on trust as the backbone of BGP is risky. Unwanted events, often malicious attacks such as prefix hijacking, prefix leaking, and address spoofing, can and do have long-lasting negative impacts on the Internet.

Fig-2: Border Gateway Protocol can run with RPKI to make the Internet safer.

What is Resource Public Key Infrastructure (RPKI)?

RPKI is a framework designed to secure routing infrastructure. It is a resource certification which provides evidence for the authority to use given IPv4, IPv6, and ASN resources and it can be validated cryptographically. It’s a chain of certification hierarchy – the higher tier can sign for its child and become a certificate authority (CA). This is how the chain is built. The end owner can also sign non-certified objects and become end-entity (EE) along certificate authority (CA) for its own resources.

Fig-3: RPKI as a chain of trust

Route origin authorizations (ROAs) are digitally-signed objects that fix an address to an AS, signed by the address holder which is based on X.509 PKI certificate standards. ROAs are a method for verifying that a prefix or IP address holder has authorized an AS to originate route objects in the inter-domain routing environment for that prefix.

When Regional Internet Registries (RIRs) allocate resources to an Internet service provider (ISP), they issue a public key/certificate that binds the allocated resources to the ISP’s public key, all signed by RIR’s private keys. This certificate proves that the holder of the private key (the ISP) is the legitimate owner of the number resources.

ISPs can now sign their own resources using the private key, which can be verified by any third party with a reference to trust anchors – RIRs’ root certificate authority.

Fig-4: How route origin validation works.

BGP route declarations have an origin AS and AS path formation. The most widely known application of resource public key infrastructure is route origin validation (ROV).

ROV is executed using ROA, which establishes the list of the prefixes that an AS is authorized to announce. ROA accordingly states which autonomous system number is approved to start certain prefixes. So, a third party software (a validator) is run to establish an RPKI-to-Router session with routers and do the verifications with respect to the data achieved from trust anchors. Once validated, a ROA can be used to generate route filters.

Once we complete running an application for ROV we’ll be able to:

  • Verify whether an AS is authorized to announce a specific IP prefix
  • Reduce most common routing errors
  • Prevent routing hijacks

There are several third-party software used for validating certificates. Today we will discuss one of them: Routinator.


Installation: Routinator is a free, open source RPKI Relying Party software written by NLnetLabs in the Rust programming language.

Routinator connects to the Trust Anchors of the five RIRs —APNIC, AFRINIC, ARIN, LACNIC and RIPE NCC —downloads all of the certificates and ROAs in the various repositories, verifies the signatures and makes the result available for use in the BGP workflow.

The validated cache can be fed directly into RPKI-capable routers via the RPKI to Router Protocol (RPKI-RTR), described in RFC 8210.

System Requirements

At this time, the size of the global RPKI data set is about 500MB. Cryptographic validation of it takes Routinator about 2 seconds on a quad-core i7.

When choosing a system to run Routinator on, make sure you have 1GB of available memory and 1GB of disk space. This will give you ample margin for the RPKI repositories to grow over time, as adoption increases.


The Rust compiler runs on, and compiles to, a great number of platforms, though not all of them are equally supported.

To install rustup and Rust

curl https://sh.rustup.rs -sSf| sh

The easiest way to get Routinator is to leave it to cargo

Sudo apt install cargo
source ~/.cargo/env
cargo install routinator
routinator init--accept-arin-rpa

Now that Routinator is initiated, it is time to establish the RTR session with router.

routinator server --rtr[SERVER IP]:3323 --http [SERVER IP]:9556 –d

To see if Routinator has been initialised correctly and your firewall allows the required connections, it is recommended to perform an initial test run. You can do this by having Routinator print a validated ROA payload (VRP) list with the vrps subcommand

routinator -v vrps

You need to allow the RTR session port (3323 in this case), HTTP port (9556 in this case) and port for Rsync (873) to allow in your firewall to make the software work.

Now you need to configure your router end to establish the RTR session. Below configuration example of Cisco IOS XR and Juniper is given.

Cisco IOS XR Configuration Example:

router bgp [ASN]
 rpki server [SERVER IP]
  transport tcp port 3323
  refresh-time 120

address-family ipv4 unicast
 bgp origin-as validation signal ibgp

address-family ipv6 unicast
 bgp origin-as validation signal ibgp

Juniper Configuration Example:

routing-options { 
autonomous-system [ASN]; 
validation { 
group rpki-validator { 
Session [Server IP] { 
refresh-time 120; 
Port 3323; 
local-address X.X.X.253; 

Now you can check if the session is running or not in the server.

ps ax| grep routinator
1369 ?        Sl   124:05 /home/[USER]/.cargo/bin/routinator server --rtr [SERVER IP]:3323 --http [SERVER IP]:9556 -d
7487 pts/0    S+     0:00 grep --color=auto routinator

You can also check in the router.

sh bgp rpki server summary
Sun Aug 23 12:21:15.973 UTC
Hostname/Address        Transport       State           Time            ROAs (IPv4/IPv6)
       [SERVER IP]           TCP:3323        ESTAB           4w3d           145647/24392

Routinator gives you monitoring data in prometheus format. So you can collect them and make wonderful graphs in graphana. You can see the data at [http://[server ip]:9556/metrics].

Fig-5: Graphana showing graphs from Routinator data for monitoring.

Authors’ acknowledgement: The post benefited from notes, diagrams, and configurations from MANRS, APNIC training materials, NLnet Labs, and Dr. Philip Smith.

Editor’s Note: This is a guest post by a MANRS ambassadors and a MANRS fellows. Ambassadors are representatives from MANRS participants who provide mentorship, guidance, and feedback to others in the routing security community; Fellows are emerging leaders who strongly believe that routing security is an essential component for the future well-being of the Internet and are ready to contribute to its improvement.

View 3 Comments