BGP Security: Mitigating BGP prefix hijacks with RPKI in IOS-XR-By Elvin Arias

admin

Overview

In this blog, we will explore how BGP route hijacks happen on the internet and how we can mitigate them using Resource Public Key Infrastructure (RPKI) and Origin Validation (OV) in IOS-XR.

How do BGP hijacks happen?

The Border Gateway Protocol (BGP) is the routing protocol that glues the Internet together. With it, routing domains are encoded as Autonomous Systems (AS) and customers advertise public IP prefixes in order to provide the means of IP reachability. These blocks of IP addresses are known as ‘public’ blocks and correspond to provider-independent ranges that ASes own and that are registered in the Internet Regional Registries (IRR) with the corresponding data of the entity owning the prefix (AS information, prefix, prefix length, entity name, etc).

Note: You can use the IRR query tool to know further information about the IP prefix in question.

These IP blocks are advertised with the AS value that corresponds to where the prefix is being originated from and transiting through, a simple but elegant mechanism that allows us to trace back the routing domains originating the IP prefixes.

As depicted in Image 1, Customer #1 is within AS 64512 and is advertising prefix 192.0.2.0/24, as the prefix is advertised through the different ASes, the AS number where the prefix is transiting through is appended.

Image 1 - BGP advertisement flow

Customer #2 knows that the prefix 192.0.2.0/24 originated from AS 64512 and that it needs to transit AS 64514 and 64513 respectively before reaching the final destination AS.

How BGP chooses the best route

A fundamental problem that exists without Origin Validation (OV) is that BGP does not have a mechanism to validate if the advertisement where the prefix is coming from is legitimate. Since we are on the internet, the prefix can arrive from multiple peers, and in order for a router to choose a path, it has to choose the prefix based on the best path selection algorithm. A common step in the best path selection is to choose the prefix with the shortest AS path length, which leads to a similar behavior with other Distance Vector protocols where the ‘nearest’ exit is the lowest hop count towards the destination. Note the following items for this case:

• BGP will select the best route based on how ‘near’ the prefix is to based on its own view
• The AS attribute is used for this, a prefix that is received with the shortest AS list is the closest to the router, therefore is selected as the best path
• As per regular routing rules, the prefix with the longest match (more specific), is always selected, which leads attackers to leverage this behavior to create attacks by advertising longer matches than the legitimate prefix
  

As depicted in Example 1, we can observe that Victim #1 is advertising prefix 192.0.2.0/24 which is being advertised to different ASes on the internet, the Attacker #666, later on, will also be advertising the same prefix (or longer mask), ISP #2 and Victim #2 will run BGP Best Path Selection resulting in a shorter path through 64666 which allows all traffic to be routed towards the attacker AS, therefore, your prefix has been hijacked!

Example 1 - Introducing attack

Now all traffic starts to route towards Attacker #666, effectively causing a Denial of Service situation redirecting high volumes of traffic to the wrong ASN. This is simply due to the fact that:

• BGP is a routing protocol, and as such, it tries to choose the most optimal path, and in this case, the attacker relies on this fact to cause this issue
• BGP does not have a mechanism to automatically validate which peers are allowed to originate which prefixes unless explicitly defined by policy (regular prefix-lists matching and allowed/denied lists)
  

Example 2 - Hijacked, traffic routed towards AS 64666

Mitigating BGP hijacks: Introducing RPKI and Origin Validation

What if we could introduce a mechanism to tell the BGP process to use a source of truth for the IP prefixes being received from peers on the internet to validate the origin of the prefix and allow it or reject them accordingly? This is where Resource Public Key Infrastructure (RPKI) comes into play.

RPKI is defined in RFC 6480 and provides the cryptographic means to protect BGP and allow Origin Validation (OV). By defining the set of components necessary to distribute certificates that contain the details of the organizations that are allowed to originate the prefixes, RPKI sets the ecosystem to authenticate and validate what parties are allowed to originate the internet prefixes and if not, act accordingly (reject them) in order to optimally mitigate prefix hijacks.

Different components of RPKI exist, among them:

• Route Origin Authorization (ROA) - Is the certificate that contains the attributes of the prefix cryptographically signed by the Trusted Anchor (TA) or certificate authority. Only the AS and prefix with prefix-length defined in the ROA are allowed to originate the prefix. This is registered using the local Internet Registry and distributed so that other parties can use it to validate BGP advertisements against the information contained in the ROA.
• Trusted Anchor (TA) - Is the certificate authority that emits the ROAs, these are currently the major Internet Routing Registries (LACNIC, APNIC, ARIN, APNIC, etc.)
• Router-to-Router RPKI Protocol (RTR) - Is the protocol that allows communication from the router to the external server that holds the data for validation also known as Validated ROA Payload (VRP).
• Validated ROA Payload (VRP) - Refers to a lightweight version of the ROA. Routers do not process the ROAs directly, but these will download a lightweight version of the ROA or VRP that contains the prefix, prefix length, and ASN to perform origin validation.
• Validator Server - A server that contains the VRPs and that the router establishes a session to in order to download the VRPs.
  

Image 2 - RPKI Infrastructure

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?



• 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

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

Code Snippet 1 - Initial Configuration

# XR1-CUSTOMER

# XR2-ISP1

# XR3-ATTACKER

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

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

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

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

XR1-CUSTOMER has effectively a Denial of Service situation in its AS.

Code Snippet 6 - Route table verification post hijack

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

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

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

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

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

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

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

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

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

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

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:

• Always use authentication with peers!
• Use Time-to-Live security checks to protect against IP TTL attacks
• Set prefix limit warning thresholds
• Always add ACLs on your external interfaces to only allow peer IP address
• Add policies against Bogon prefixes and ASNs respectively
• Always deny your own prefixes from other external peers
• Set maximum-limit for AS-path length in BGP advertisement
• Always drop RFC1918 from public peers
• Many other ways to protect you: See RFC 7454 (also known as Best Current Practice: 194) – always check BCP’s!
  

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!