BGP is the de facto routing protocol for inter-domain routing, or in other words, the global internet. It’s used to exchange routing information among autonomous systems around the entire world. Therefore, it’s extremely important we do what we can to secure BGP communications, what we advertise, and the methods we use to create peering relationships. However, BGP is decentralized in nature and generally built on trust between BGP peers making it difficult to secure and a popular attack vector.
For this post, I’ll focus on two main threats to BGP security and several (but not all) methods we can use to mitigate BGP security incidents.
BGP hijacks
BGP hijacks, or more accurately, AS hijacks, are generally malicious in nature. A bad actor hijacks traffic or routing related to a particular AS usually for the purposes of misdirecting traffic for some nefarious purpose such as denial of service or performing some sort of interception.
Examples in the news are plentiful.
In January of 2024, Spain’s second largest mobile operator, Orange España, experienced a national outage spanning multiple hours caused by a compromised password in their routing system. An attacker logged into Orange España’s RIPE NCC portal using the password “ripeadmin” and altered their RPKI configuration rendering many of its BGP routes RPKI-invalid.
In 2018, attackers performed a BGP hijack to redirect traffic headed for Amazon’s DNS service. The attackers then answered the DNS queries for the web-based crypto wallet “myetherwallet.com” and redirected users to an imposter “myetherwallet.com” website. Unsuspecting people entered their credentials in the fake website and ultimately lost the contents of their crypto wallets.
BGP hijacks are generally accomplished by advertising prefixes owned by another AS thereby redirecting traffic. This can be done pretty simply by advertising someone else’s IP address range, or more often a more specific route than the legitimate AS. Here’s an example image from Cloudflare that shows a bad actor advertising a more specific route (red) than the legitimate AS (green):
In this case, the hijacking router in AS65666 is advertising into BGP that they are the destination for 10.0.0.0/24 and 10.0.1.0/24, both of which are subnets within 10.0.0.0/23 owned by AS65001.
Route leaks
Route leaks are generally unintentional and caused by a misconfguration or some sort of error in design. A route leak is simply advertising prefixes accidentally that shouldn’t be or weren’t intended to be advertised into BGP. A route leak can have a similar effect as a BGP hijack in that traffic can be misdirected, blackholed, and lead to suboptimal routing in general. Again, the main difference between route leaks and BGP hijacks is that route leaks are usually an accident.
In February 2008, the state telecom of Pakistan was ordered by the government to block YouTube due to a video it deemed anti-Islamic. PTCL announced more-specific routes of YouTube’s BGP prefixes to effectively null route YouTube traffic, but they forgot they had a redistribute static configuration that either directly or via their IGP redistributed it into their eBGP sessions.
Providers upstream from PTCL failed to filter their announcements and in turn announced this more specific (and incorrect) route it to their own transit customers. Eventually, this route leak propagated to the whole world.
In July 2022, Canadian telecom giant Rogers Communications experienced a catastrophic outage taking down nearly all its services for its 11 million customers. The outage was ultimately found to be caused by the accidental removal of a route filter in the telecom’s BGP configuration causing routes to be removed and therefore cease from being advertised. This cascaded to a total outage, the largest in Canadian history.
Mitigating BGP security risks
There are a variety of ways to secure BGP, including both technical and cultural. Take a look at this list – which is only a portion of all the options we have at our disposal.
- Prefix filtering/ACLs
- Control plane policing
- TCP Authentication Option (TCP-AO)
- Minimum Route Advertisement Interval (MRAI)
- Route flap damping (RFD)
- Next-hop tracking
- TTL security
- uRPF (Unicast Reverse Path Forwarding)
- BGP Security (BGPSEC)
- Resource Public Key Infrastructure (RPKI)
- Autonomous System Provider Authorization (ASPA)
- Mutually Agreed Norms and Standards (MANRS)
For the sake of brevity, I’ll be focusing on just a few of these methods which I consider to be the most valuable and/or the least discussed in the networking community. However, for a more exhaustive list, check RFC7454 from 2015.
Prefix filtering
BGP prefix filtering is a simple and easy way to whitelist and filter BGP announcements. Normally, a service provider keeps a list of IP prefixes it expects from its peer (usually one of its customers) in a BGP prefix-list. Providers can then scan the prefixes it’s learning and discard BGP announcements that aren’t on the prefix list. Providers also read Internet Routing Registry (IRR) databases to build their local whitelist which can be done on subnet mask length, specific subnets, or specific prefixes.
Here’s a very simple prefix-list I found on the internet, but keep in mind these can be very long and can be created programmatically:
uRPF (Unicast Reverse Path Forwarding)
uRPF is an easy way to protect against spoofed source IP addresses in BGP updates. Basically, uRPF checks the source IP address of an incoming BGP update against the routing table of the router, and if the source IP isn’t in the local routing table, the update packet is dropped. And we can also do this based on the interface as well.
TTL Security
TTL is another easy way to protect against attackers that would invariably be more than one hop away and not a directly connected peer. In this case, an attacker would spoof legitimate-looking packets toward a BGP router, usually at high volume, resulting in a DoS attack.
If we set our allowed TTL value to 1, we can help prevent these types of attacks from happening ensuring we accept messages only from directly connected peers. In practice, the way to do this is to set the TTL to 255, the maximum value, which ensures the originator of the BGP update is exactly one hop away.
RPKI (Resource Public Key Infrastructure)
Defined in RFC 6480 (An Infrastructure to Support Secure Internet Routing), RPKI is a system used to validate BGP routes announced by an Autonomous System by verifying the AS is authorized to originate the prefixes in an an announced route. This gives us better reliability of the information networks use when filtering routes by enabling them to identify/drop BGP routes when the announced prefixes aren’t part of the address space assigned to the AS making the announcement.
RPKI establishes a trust anchor and hierarchy of authorities rooted at the RIRs (regional Internet registries) which you can see in the chart to the right.
RPKI doesn’t modify BGP or require cryptography to be performed during routing.
Therefore RPKI is a preventative validation mechanism, doing for BGP effectively what DNSSEC does for DNS. In the image below from the RIPE Labs website, you can see an oversimplification of how this process works.
First, an organization/AS registers its IP address space, organization name, ASN, etc with the relevant RIR. The RIR confirms that information and creates an ROA, or Route Origin Authorization. The image below is an example of an ROA object.
This object, which now exists in the RIR database, can be used to validate prefixes when some other AS learns about those routes. In other words, it can perform a Route Origin Validation. In practice, the way this works is that as AS checks learned prefixes by looking up the ROA using a third party software (a validator) to establish an RPKI-to-Router session with routers. Examples of third party validation software are Routinator, Fort Validator, OctoRPKI, etc.
The AS then receives an RPKI-valid or RPKI-invalid message which is used to generate route filters and allow or deny those prefixes from being added to a local routing table. In this way, we’ve used RPKI to reject prefixes learned from an AS that isn’t allowed to advertise them thus preventing a BGP hijack.
BGPsec (BGP Security)
Introduced in RFC 8205 in September 2017, BGPsec is a cryptographic way to guarantee a BGP route has an authorized origin AS. Specifically, BGPsec signs the BGP UPDATE message including previous and next-hop AS. In this way, BGPsec can determine if the AS-Path represented in the route is the same as the path through which the NLRI traveled.
Therefore BGPsec differs from RPKI in that BGPsec offers a cryptographic method for path validation and not just origin validation. However, BGPsec hasn’t been adopted widely as a security mechanism and is debated as to its effectiveness.
Basically, the idea is that all ASes need to employ BGPsec for it to be effective. And because the entire path for UPDATE messages is encrypted, computational cost per device is high. This has been a major stumbling block for widespread adoption, although there are some who argue that BGPsec can still provide value if even just backbone providers agree to use the protocol among themselves.
BGPsec isn’t best practice yet, but it’s something I believe we should get familiar with.
Autonomous System Provider Authorization (ASPA)
ASPA is a method to state which ASNs are allowed to propagate (as opposed to announce) routes. Different from other security mechanism used to validate the origin of a route, ASPA is used to validate AS_PATH and enables other entities to reject a route when the AS_PATH contains a valley-free violation.
ASPA objects are created and distributed the same way as ROAs in RPKI. The image below from MANRS is an example of an ASPA object.
Using this method, an AS can ensure that there are no ASes in the path that aren’t allowed to be propagating this specific route. In the image below also from MANRS, the ASPA object was created by AS945 on 17 December 2022 and shows four providers are allowed to propagate its routes: AS1299, AS6939, AS32097, AS50058, and 61138.
Mutually Agreed Norms and Standards (MANRS)
MANRS is different than all the security measures we’ve looked at so far. Instead of a purely technical mechanism, MANRS is more a “culture, a philosophy, and a community.”
An initiative of the Internet Society, MANRS is made up of members who belong to a community of like-minded technologists. The goal is to help secure internet peering relationships and global routing by sharing information, develop standards, develop peer relationships for technical review, and so on.
Therefore, MANRS is not a technology, it’s not a formal regulatory body, and it’s not a new encryption method. It really is a community working together to secure the internet.
MANRS lists four “actions” on their website:
- Filtering – defining a clear routing policy and implementing a system to ensure that announcements to adjacent networks are correct.
- Anti-spoofing – enabling source address validation (SAV) and implementing anti-spoofing to prevent packets with incorrect source IP addresses from entering and leaving the network.
- Coordination – maintaining globally accessible up-to-date contact information to assist with incident response.
- Global validation – publishing data that enable other stakeholders to validate routing information worldwide.
Conclusion
Each section of this post could easily have been its own extensive blog post, and that includes all the mitigation methods I didn’t mention at all. Securing BGP isn’t just for service providers anymore, but for any enterprise organization with an internet presence managing BGP adjacencies.
Consider the several methods and mechanisms mentioned in this post, and consider joining MANRS to become part of the global community of engineers trying to keep the internet safe for everyone.
{networkphil} 
Leave a comment