As seen in Image 2, The Validator Server downloads the ROAs distributed from the Internet Registries (IRR), and the router will connect to the Validator Server via TCP using the Router-to-Router RPKI (RTR) protocol in order to download the VRPs locally to perform OV.
How does this look in BGP? Origin Validation (OV)
Origin Validation is the process of using the information provided by the RPKI infrastructure and acting according to the states. Once we compare the information contained on the VRP versus the BGP table, there are three possibilities that could result from this comparison:
- VALID - This prefix state corresponds to a matching entry in the VRP database that indicates the attributes of the prefix in the BGP UPDATE match what is contained in the VRP.
- UNKNOWN - This prefix state indicates there is no record matching the prefix. IOS-XR flags these prefixes as Not-Found.
- INVALID - A discrepancy exists on the attributes of the VRP versus the BGP UPDATE.
Table 1 - What is the state of the prefix?
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nwPL)
- If the BGP advertisement 8.8.8.0/24 is coming from ASN 15169, the prefix lookup results as VALID
- If the route record for advertisement 8.8.8.0/24 does not exist, lookup results as Not-Found
- If the BGP advertisement 8.8.8.0/24 is coming ASN other than 15169, the prefix lookup results as INVALID
Note: Origin Validation checks are made between BGP prefixes and the VRP database known as the RPKI table in IOS-XR.
In Example 3, we can observe that at this time the Attacker #666 within AS 64666 tries to hijack prefix 192.0.2.0/24, but since ISP #2 and Customer #2 have Origin Validation enabled and AS 64666 is not authorized to originate the prefix based on the information these ASes have about 192.0.2.0/24, the prefix would be either ignored for best path selection or completely dropped.
Example 2 - Origin Validation in Action
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001ny79)
Configuring Origin Validation in IOS-XR
We have arrived! After understanding the concepts around RPKI and OV, we can now apply them in order to prevent hijacks and effectively protect our autonomous system from hijacks in a demonstration. We will use Topology 1 - RPKI Topology for our example. For the Validator Server, I will be using GoRTR as a Docker instance, which is a Validator Server our XR1-CUSTOMER will connect to and that you can use for free to test the power of OV!
Topology 1 - RPKI Topology
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001ny87)
Code Snippet 1 - Initial Configuration
# XR1-CUSTOMER
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyF8)
# XR2-ISP1
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyFI)
# XR3-ATTACKER
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyFN)
Prefix 8.8.8.0/24 is registered by Google, Inc., and should only be received from AS 15169. initially, XR2-ISP1 advertises this prefix originated from AS15169, we can craft the advertisement as per below.
Code Snippet 2 - Crafting and advertising BGP route
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyFS)
We verify XR1 and see the advertisement 8.8.8.0/24 coming from AS 64512 originated from AS 15169 as we expected below.
Code Snippet 3 - Verifying BGP prefix
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyFX)
We notice that the Origin-AS validity flag is set to 'not-found', which means the VRP does not exist in the database, we can confirm this by checking the VRP table since we have not configured our router to connect to the Validator Server, yet.
Code Snippet 4 - Verifying VRP table
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyFc)
At this point, if XR3-Attacker starts advertising the same prefix, it will be selected as the best by XR2-CUSTOMER since AS path length would be a length of 1 coming from XR3-Attacher versus a length of 2 coming from XR2-ISP1, therefore we have produced a hijack in place. We can observe that XR2-CUSTOMER is choosing the route towards the attacker AS 64666.
Code Snippet 5 - Crafting and advertising hijack route
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyFm)
XR1-CUSTOMER has effectively a Denial of Service situation in its AS.
Code Snippet 6 - Route table verification post hijack
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyFr)
We can use the best-compare command in order to see the reason why the best path towards a peer has been selected overall.
Code Snippet 8 - BGP best path state
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyFw)
Now let’s try to mitigate this by enabling OV in XR1-CUSTOMER, the first step is to configure our router to connect to the Validator Server.
Code Snippet 9 - Configuring RTR session
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyG1)
Once the RTR protocol establishes the TCP connection, we can see that the VRPs will be downloaded locally in the router. Now if we check the RPKI table, we will see the contents of the VRPs.
Code Snippet 10 - Verifying VRP records
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyG6)
For the specific prefix 8.8.8.0/24, we can see an entry exists that indicates we can only see this prefix coming from AS 15169.
Code Snippet 11 - VRP record for prefix verification
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyGB)
Checking if anything has changed in the BGP table, we can observe that the validity information flag has changed and is flagging the advertisement coming from each peer according to the VRP table.
Code Snippet 12 - RPKI INVALID prefix in BGP table
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyC4)
With this information, we can start preventing hijacks. If you are a good observer, you will see that besides the Origin-AS validity flag, routing has not changed and XR1-CUSTOMER is still selecting the INVALID path as best, this is less than ideal. The reason why this is the case is due to the fact that we need to tell the BGP process to use the VRP table for Origin Validation when running best path selection, the way we can do this is by using the knob bgp bestpath origin-as use validity within the BGP.
Code Snippet 13 - Enabling use of OV in BGP path selection
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyCx)
This results in the route not being a candidate for Best Path Selection due to being flag as INVALID as seen below.
Code Snippet 14 - Effects of enabling bestpath validity usage in BGP path selection
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyDH)
Notice that the prefix flagged as INVALID is still in the BGP table, but we simply do not use it. We could optimize things further and craft a manual policy that allows granularity in decision making, for example, we can tell the BGP process to drop any INVALID prefixes coming from the peers.
Code Snippet 15 - Crafting custom OV Policy
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyDg)
If we check the BGP table again we will see that the prefix previously accepted but flagged as INVALID is not in the BGP table anymore, and we are only accepting the prefix coming from XR2-ISP1.
Code Snippet 16 - BGP dropping RPKI INVALID prefix
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyEA)
If we debug the BGP UPDATE activity, we would see that the prefix is being dropped due to the OV-POLICY condition to drop any prefix which results in a validation-state of INVALID.
Code Snippet 17 - INVALID prefix policy reject debug
![](https://learningnetwork.cisco.com/servlet/rtaImage?eid=a0D3i000008KX3I&feoid=00N3i00000BnD8k&refid=0EM3i000001nyEP)
Bonus Section: Additional Security Measures
Besides RPKI, consider implementing traditional BGP hardening techniques in order to further protect BGP from different types of attacks and bogon advertisements coming from the internet. Common security measures include, but are not limited to:
Conclusion
Origin Validation is a powerful tool that allows BGP to mitigate hijacks of prefixes on the internet, operators are encouraged to use RPKI in order to protect the internet and make it a safer place.
Happy studies! ![](static/image/smiley/default/smile.gif)