BGP Route Security

Whenever there is a new attack on the Internet that has anything to do with BGP (Border Gateway Protocol), you hear the commonly used phrase that goes something like “BGP is based on the inherent trust model with no inbuilt security”. While that is true (as we will see in this article), what technology of the early Internet days was built with security in mind?

Take EIGRP and OSPF for example. These routing protocols can form neighbor relationships and share routing information even without any static neighbor configuration (unlike BGP where you must configure a peer). However, the problem with BGP is aggravated because while these other technologies are usually used within an Autonomous System (AS, a group of devices under the same administrative domain), BGP is used between ASes. The risk of malicious intent between ASes is greater than within an AS.

Securing BGP can be divided into three major parts:

• Protecting the BGP speakers themselves (a device participating in BGP is known as a “BGP speaker”)
• Protecting the BGP sessions between BGP peers
• Protection of BGP routing information between BGP peers

In this article, we will focus on the third category – security issues in BGP routes and protection against such issues.

BGP Route Security Issues

Just so we are on the same page, let’s run quickly through the basics of BGP as it relates to the Internet. The Internet is based on a hierarchical model. At the top, you have IANA, which delegates IP address and AS number allocation to Regional Internet Registries (RIRs), and then these RIRs allocate these IP address and AS numbers to ISPs (different tiers), and finally, the ISPs assign numbers to the customers/end users.

To enable communication between these various networks on the Internet, we use BGP i.e. BGP is used to provide reachability within and between ASes. It may be slow and complex to understand (and configure), but it is very scalable.

For BGP to do its work, you configure peering relationships between routers.

For example, in the diagram above, if we configure BGP peering between R1 and R2 and they announce their local networks into BGP, the BGP table of the routers will be something like:

• On R1: I can reach y.y.y.y/y via R2 and the AS_PATH is “2”
• On R2: I can reach x.x.x.x/x via R1 and the AS_PATH is “1”

Note: BGP uses various attributes in its operation. AS_PATH is one of those attributes.

This is where the problem with the trust model starts to become evident. R1 accepts the y.y.y.y/y route from R2 and all things being equal (default BGP configuration), will forward all traffic destined for y.y.y.y/y to R2. How does R1 actually know that y.y.y.y/y belongs to R2? Remember that y.y.y.y/y is a public IP address block routable on the Internet so it is very important that the routing information is correct.

This issue is exactly what was exploited on April 24, 2018, when some IP address blocks belonging Amazon DNS were hijacked (someone else claimed they owned it) and traffic to a particular service (Myetherwallet.com) was re-routed to a malicious server. The attacker(s) ended up stealing about $150,000 in Ethereum.

This kind of attack is known as BGP Hijacking. It may be done maliciously or in most cases, due to misconfiguration. One of the reasons it works is that BGP, like other routing protocols, will use the most specific route instead of a generic route. To reduce the global routing table size, most ASes perform route aggregation, so instead of sending out four /24 routes, they will send out one /22 route. If an attacker is able to advertise a more specific /24 route (part of the /22 block) into the global routing table, traffic will be sent to the attacker. Even in cases where the attacker advertises the same route/prefix as the original route, traffic may still flow to the attacker based on the BGP Path Selection algorithm.

The other security issue against BGP routes is called BGP Route Leaking. In this case, traffic flows through an unintended route because a BGP peer somewhere advertised routes they were not supposed to.

This is what happened in November 2018 when some Google services were inaccessible to some users due to a configuration error by MainOne, an ISP in Nigeria. This ISP has a BGP peering relationship with Google and receives some of Google’s advertised IP prefixes. While they could (probably) advertise these prefixes to their downstream BGP peers (e.g. customers, smaller ISPs), they mistakenly advertised (leaked) those prefixes to one major upstream ISP – China Telecom. China Telecom then advertised those prefixes to another major ISP in Russia, and this cascaded all the way to cause a denial of service (many Google services are blocked in China so return traffic will have been dropped).

There are several ways to prevent or at least reduce these issues including prefix filtering, AS path filtering, and so on. However, before we look at those solutions, let’s use a lab to simulate how these attacks can occur in BGP.

Lab #1: BGP Route Leak

In the lab setup above, Google has a prefix 192.168.2.0/24. MainOne has a peering relationship with both Google and China Telecom. China has BGP peering with Russia which has another peering relationship with RANDOM. Google also peers with RANDOM. MainOne is configured to only advertise routes that originate within its own AS i.e. 192.168.1.0/24.
The configuration on the devices is as shown below:

hostname MAINONE
!
interface FastEthernet0/0
ip address 10.1.12.1 255.255.255.0
no shutdown
!
interface FastEthernet0/1
ip address 10.1.13.1 255.255.255.0
no shutdown
!
interface FastEthernet1/0
ip address 192.168.1.1 255.255.255.0
no shutdown
!
router bgp 1
network 192.168.1.0
neighbor 10.1.12.2 remote-as 2
neighbor 10.1.12.2 filter-list 1 out
neighbor 10.1.13.3 remote-as 3
neighbor 10.1.13.3 filter-list 1 out
no auto-summary
!
ip as-path access-list 1 permit ^$
!

hostname GOOGLE
!
interface Loopback0
ip address 192.168.2.2 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.12.2 255.255.255.0
no shutdown
!
interface FastEthernet0/1
ip address 10.1.25.2 255.255.255.0
no shutdown
!
router bgp 2
network 192.168.2.0
neighbor 10.1.12.1 remote-as 1
neighbor 10.1.25.5 remote-as 5
no auto-summary
!

hostname CHINA
!
interface FastEthernet0/0
ip address 10.1.13.3 255.255.255.0
no shutdown
!
interface FastEthernet0/1
ip address 10.1.34.3 255.255.255.0
no shutdown
!
router bgp 3
neighbor 10.1.13.1 remote-as 1
neighbor 10.1.34.4 remote-as 4
no auto-summary
!

hostname RUSSIA
!
interface FastEthernet0/0
ip address 10.1.34.4 255.255.255.0
no shutdown
!
interface FastEthernet0/1
ip address 10.1.45.4 255.255.255.0
no shutdown
!
interface FastEthernet1/0
ip address 192.168.4.4 255.255.255.0
no shutdown
!
router bgp 4
network 192.168.4.0
neighbor 10.1.34.3 remote-as 3
neighbor 10.1.34.3 weight 100
neighbor 10.1.45.5 remote-as 5
no auto-summary
!

hostname RANDOM
!
interface FastEthernet0/0
ip address 10.1.45.5 255.255.255.0
no shutdown
!
interface FastEthernet0/1
ip address 10.1.25.5 255.255.255.0
no shutdown
!
router bgp 5
neighbor 10.1.25.2 remote-as 2
neighbor 10.1.45.4 remote-as 4
no auto-summary
!

Let’s look at the BGP table of MainOne:

Notice that even though it sees the Google prefix (192.168.2.0/24) from two paths (directly from Google and through China > Russia > Random), it is using the shortest AS path which is through Google.

On the other hand, China will only see the Google prefix from Russia because we have configured MainOne not to advertise that Google prefix to China.

Looking at Russia, the Google prefix is seen through RANDOM:

Based on this, traffic from VPCS-1 to 192.168.2.2 will flow through MainOne > Google:

On the other hand, traffic from VPCS-2 to 192.168.2.2 will flow through Russia > RANDOM > Google:

So far, things are working correctly. Now, what happens when there’s a configuration error on MainOne and the Google Prefix is leaked to China:

Looking at MainOne’s BGP table, things still look relatively okay:

However, if we look at China, things have changed – China now sees that route through MainOne:

Note: BGP is slow. It may take some time before the BGP table is updated after a change.

Because of the better weight (100) that Russia uses for China, Russia will now use China to reach the Google Prefix (even though the path through RANDOM is shorter):

This means VPCS-2 will now go through Russia > China > MainOne > Google:

Now, what if China is blocking Google services (like it currently does)? The configuration on China to achieve this will be:

ip route 192.168.2.0 255.255.255.0 null0

With this configuration, if VPCS-2 tries to ping 192.168.2.2, it will fail:

Lab #2: BGP Prefix Hijacking

Using the same lab, we can simulate BGP hijacking. Let’s restore the AS path filter on MainOne:

With this, Russia is back to using RANDOM:

Let’s assume China wants to hijack some of Google’s services. One thing it can do is to advertise a more specific route for the 192.168.2.0 network e.g. /25

With this configuration, even though Russia still sees 192.168.2.0/24 via RANDOM, it will also have 192.168.2.0/25 through China:

So if VPCS-2 ping 192.168.2.2, it will actually go to China and not Google:

Securing BGP Routes

As we have seen above, BGP hijacking and route leaks can be easily accomplished (purposely or mistakenly) and in fact, these types of issues occur quite frequently on the Internet every day! In this section, we are going to discuss some solutions to tackle these issues.

Filtering

Filtering can happen in several ways including prefix filtering (e.g. advertise only 192.168.2.0/24), AS path filtering (e.g. advertise only routes that originated in a specific AS), and community-based filtering (e.g. advertise only routes with specific communities).

Note: This article provides good examples of filtering for BGP.

If China Telecom had configured appropriate filtering such that they only accept certain routes from MainOne, the issue that happened with the Google prefixes may not have happened at all or have been as widespread.

The fact is that even though filtering is one of the most accessible methods of preventing route leaks and hijacking, it is usually not properly done or even done at all. Many ASes just accept any route that is advertised to them and also advertise these routes to their peers. To make matters worse, how is an AS supposed to know which prefixes its peer can advertise so that it can apply the correct filters? For example, how was China Telecom supposed to know that MainOne should not have advertised those Google prefixes?

There are a few ways around this issue:

• For an end customer, an ISP should only accept that end customer’s IP address block. Any other prefix advertised from that customer should be dropped.
• A BGP speaker may choose not to accept routes that are too specific (e.g. /25). This will vary widely depending on the RIR/ISP.
• For peer-to-peer configurations (e.g. ISP to ISP), the case is more complex. There needs to be a way for each BGP speaker to know what routes it can accept from its peer. This can be achieved by querying one of several Internet Routing Registries (IRRs). An IRR is basically a database that contains routing information such as prefixes, the AS that can announce it, email address to contact if necessary, and so on. An administrator can use these IRRs to manually or automatically configure filters for its BGP peers.

Several IRRs are available but the most complete one is probably RADb. There are also several tools available to make use of these IRRs including the normal whois (CLI and web), IRRToolSet, bgpq3, and so on.

Keep in mind that IRRs usually contain inaccurate, incomplete, or outdated information. Also, there is really no way to prove that an AS owns the prefix they claim to own (or can advertise). This brings us to the next possible solution – Resource Public Key Infrastructure (RPKI).

Resource Public Key Infrastructure (RPKI)

Like we have discussed in this article, one of the main issues with BGP is its blind trust. This is because BGP (by default) does not have a way to verify if a peer really owns the route it is advertising. RPKI aims to solve this problem by using cryptography.

Think of secure web browsing – a site/server will request for a digital certificate from a Certificate Authority (CA) to prove that it is really who it claims it is. When a user wants to access that website, the server will send its certificate to the user and the user will confirm with the trusted CA whether the certificate is valid or not. This is what RPKI does but with routing information.

With RPKI, IP prefixes along with the AS number that can originate them are contained in a digitally signed object known as Route Origin Authorization (ROA). Anyone that wants to verify the validity of an ROA can contact the Trust Anchors which are the equivalent of CAs in RPKI. At the top level, the five RIRs (AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC) are the trust anchors since they are the holders of accurate routing information.

Note: An ROA can contain multiple prefixes. Also, the same prefix can be contained in multiple ROAs e.g. if multiple peers are allowed to advertise that prefix.

To reduce the burden on already burdened routers, the bulk of the RPKI process is actually done on other devices/servers apart from routers. So when a router receives a routing information, it will make a request to a validator (usually a server) saying “I have received this prefix that originated from this AS number; please validate it”. The validator will contact the trust anchors and check if that routing information matches an ROA. The result can be one of three:

• Valid: The prefix is matched in an existing ROA and originated from the correct AS number
• Invalid: The prefix is matched in an existing ROA but either did not originate from the correct AS number or the prefix length is longer than the maximum prefix length specified in the ROA
• Not Found: The prefix is not matched by any existing ROA

Let’s use an example to drive home the point. Assume that ONLY the following ROA exists:

• AS number: 12345
• Prefix: 10.1.0.0/17
• Maximum prefix length: /20

Let’s consider some scenarios:

• If a router receives the prefix 10.1.0.0/17 from AS 12345, this will be valid
• If a router receives the prefix 10.1.0.0/24 from AS 12345, this will be invalid because the prefix length is greater than the maximum prefix length specified in the ROA
• If a router receives the prefix 10.1.0.0/17 from AS 54321, this will be invalid because the origin AS is wrong
• If a router receives the prefix 10.2.0.0/17 from AS 54321, this will be not found because the ROA doesn’t cover this prefix

Using this validation information, a BGP speaker can make informed decisions. For example, it may drop any routing information with “invalid” status and assign a lower preference to those with “not found”.

Notice that RPKI will prevent BGP hijacking but probably not route leaks because RPKI deals with the origin AS. This means that RPKI should be seen as a complementary solution to filtering discussed above.

Note: RPKI deals with Origin Validation. Another aspect is Path Validation which BGPsec deals with.

Future Solutions

Other solutions being considered (currently in draft state) include:

• BGP speakers agreeing on BGP Roles beforehand (e.g. Provider, Customer, Peer): https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-open-policy/?include_text=1
• Using a BGP community to provide route-leak protection (RLP) information: https://datatracker.ietf.org/doc/draft-ietf-idr-route-leak-detection-mitigation/?include_text=1

Conclusion

In this article, we have seen how the trust model of BGP can be exploited to cause routing issues such as BGP hijacking and route leaks. While this is usually due to misconfiguration, it can also be done with malicious intent. We then looked at some solutions that can address these route security issues in BGP including filtering, RPKI, and BGP roles.