Latest

Home / BGP / BGP Route origin validation (ROV) / networking / Introduction to BGP Route origin validation (ROV)

Introduction to BGP Route origin validation (ROV)

March 22, 2024 , ,

Introduction to BGP Route origin validation (ROV)

Route origin validation (ROV) prevents routes from being advertised accidentally. Network administrators may accidentally advertise routes to networks they do not control. This security issue can be resolved by enabling route origin validation. 

Route origin validation is a way for authenticating route advertising as coming from an expected autonomous system (AS). Route origin validation authenticates specified BGP prefixes using one or more resource public key infrastructure (RPKI) cache servers. 

To authenticate a prefix, the router (BGP speaker) checks a database of registered prefix-to-AS mappings retrieved from the cache server, ensuring that the prefix came from the correct autonomous system (AS).

⭐Related : BGP Cheat Sheet for Network Engineers
⭐Related : 51 facts about BGP routing Protocol for Network Engineers 

ROV relies on the Resource Public Key Infrastructure (RPKI), which is a cryptographic framework that allows resource holders (such as IP address space holders) to cryptographically bind their resources to the corresponding AS numbers using digital certificates. Public Key Infrastructure (RPKI) has private key and public key.

Introduction to Route origin validation (ROV)
Fig 1.1- Introduction to Route origin validation (ROV)

For an example, On router R1 if the IP address prefix is 30.30.30.0/24, the AS 100 is authorized to advertise 30.30.30.0/24 but if the IP address prefix is 31.31.31.0/24 comes the AS 100 denied as we installed RPKI Validator (Caches server) to only authorize 30.30.30.0/24 from BGP peer.

Similarly, On router R2 if the IP address prefix is 20.20.20.0/24, the AS 100 is authorized to advertise 20.20.20.0/24 but if the IP address prefix is 21.21.21.0/24 comes the AS 100 denied as we installed RPKI Validator (Caches server) to only authorize 20.20.20.0/24 from BGP peer.

When a prefix is received from an external BGP (EBGP) peer, it is examined by an import policy and marked as Valid, Invalid, Unknown, or Unverified:

  • ⭐ Valid: Indicates that the prefix and AS pair are found in the database.
  • ⭐Invalid: Indicates that the prefix is found, but either the corresponding AS received from the EBGP peer is not the AS that appears in the database, or the prefix length in the BGP update message is longer than the maximum length permitted in the database.
  • ⭐Unknown: Indicates that the prefix is not among the prefixes or prefix ranges in the database.
  • ⭐Unverified: Indicates that the origin of the prefix is not verified against the database. This is because the database got populated and the validation is not called for in the BGP import policy, although origin validation is enabled, or the origin validation is not enabled for the BGP peers.

 Sample Configurations on Router R1 & R2

As we setup Route origin validation (ROV) between the BGP peers of Router R1 and Router R2, Lets see the sample configuration as below: 

Router R1 (Sample Configs)

!
route-map rpki-rov permit 10
match rpki invalid
set local-preference 90
!
route-map rpki-rov permit 20
match rpki valid
set local-preference 100
!
router bgp 100
bgp rpki server tcp 10.10.10.2 port 8282 refresh 5
neighbor 15.15.15.2 remote-as 200
neighbor 15.15.15.2 route-map rpki-rov in
!
Router R2 (Sample Configs)
Lets see the sample configuration on the router R2 as below

!
route-map rpki-rov permit 10
match rpki invalid
set local-preference 90
!
route-map rpki-rov permit 20
match rpki valid
set local-preference 100
!
router bgp 200
bgp rpki server tcp 10.10.10.2 port 8282 refresh 5
neighbor 15.15.15.1 remote-as 100
neighbor 15.15.15.1 route-map rpki-rov in
!

Check some of the prefixes
Prefix no 1 : 30.30.30.0/24 
Lets see the prefix 30.30.30.0/24 on router R1. It should show valid as we add that on RPKI Server.

R1#sh ip bgp 30.30.30.0/24
BGP routing table entry for 30.30.30.0/24, version 8995350 Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
200 3333 12654, (received & used)
Origin IGP, localpref 100, valid, external, best
path 51012284 RPKI State valid

Prefix no 2 : 31.31.31.0/24 
Lets see the prefix 31.31.31.0/24 on router R1. It should  show invalid as we add that on RPKI Server.

R1#sh ip bgp 31.31.31.0/24
BGP routing table entry for 31.31.31.0/24, version 8995351 Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
200 3333 12654, (received & used) 10.1.1.5 from 10.1.1.2 (10.1.1.2) Origin IGP, localpref 90, valid, external 
path 510122C8 RPKI State invalid

Hope it clarifies, we will come up with more details in a complex network in our next article related to Route origin validation (ROV).

Free Tools...