FEATUREDApplication Development & Modernization
RYAN HARRIS | Sr. Network Engineer
Border Gateway Protocol (BGP) serves as the routing protocol of the Internet, orchestrating the flow of data across diverse networks. It’s also used within enterprise networks for a variety of use cases, including EVPN, MPLS, SD-Access, SD-WAN, and more.
However, BGP was designed in 1989, and it wasn’t designed with the full scope that it would be used for in mind. The BGP protocol has been updated several times throughout the years to add features, but the core concepts are still there.
Unfortunately, BGP wasn’t designed with security in mind from the beginning. Route hijacking, route leaks, and BGP session hijacking pose persistent dangers to network security and stability on the global Internet. These vulnerabilities can lead to unauthorized interception of traffic, disruptions in service availability, and even widespread internet outages. Addressing these threats requires proactive measures to safeguard BGP integrity.
Here, we’re going to explore a handful of options for securing a BGP deployment in an enterprise. These are actionable items to reduce your company’s exposure to denial-of-service when advertising public IP space onto the Internet.
Here are the Best Practices for BGP Hardening and Security:
1. Resource Public Key Infrastructure (RPKI)
RPKI is a technology that is gaining a lot of steam lately for securing the global routing table from accidental and malicious route hijacking. The RFC was originally published about ten years ago and aims to fix one of the biggest flaws in the design of BGP: trust. In a nutshell, RPKI validates that a route advertisement originates from the autonomous system that it is registered to. In practice, owners of public IP space register a prefix to an AS with their respective RIR (ARIN, RIPE, APNIC, LACNIC, or AFRINIC), this is called a Router Origin Authorization (ROA). Transit service provider networks investigate each route as it passes into and through their networks to validate that the origin AS matches that which is registered with an RIR, this is called a Router Origin Validation (ROV). If a route does not pass the ROV, it is discarded.
The hurdle to implementation is twofold, network operators need to create these ROAs in the administrative portals of their RIR and service providers need to implement the ROV process. The good news is this: if you’re a network operator that owns IP space registered with an RIR and your own ASN, you can sign the authorization with no change to your existing BGP deployment.
2. BGP Filtering
It’s good security hygiene to filter all information coming in and out of a network. It protects against a denial-of-service attack, even if an accidental one can be easily accomplished by knowing which routes will be expected from a neighbor and creating a filter against that list. For example, most enterprise networks will only need a default route advertised to them from an ISP via BGP, adding a filter will prevent an accidental configuration that sends a partial or full table to a router that is ill-equipped to receive it.
3. Secure BGP Peering
By default, BGP peering’s does not require authentication. With no authentication, an attacker could craft a BGP packet to either inject a route or shut down a BGP neighborship, causing a denial of service. BGP has supported the MD5 authentication method since the adoption of RFC 2385 in 1998, however, MD5 has been known to be weak for some time now.
In 2010, RFC 5925 (The TCP Authentication Option) was introduced to extend the ability to authenticate BGP updates. TCP Authentication Option, or TCP-AO, introduced a method to allow for support of newer hashing algorithms that are stronger than MD5 as well as allow vendors to introduce these stronger algorithms without requiring an RFC to implement. Some of these stronger algorithms include, HMAC-SHA-256, AES-128-CMAC, and HMAC-SHA-1. The required algorithms (defined in a separate RFC, 5926) are AES-128-CMAC and HMAC-SHA-1.
In addition to stronger hashing algorithms, TCP-AO introduces the ability to use keychains to periodically roll over to a new key without the connection dropping.
Not all vendors support TCP-AO, but Cisco (IOS-XE, IOS-XR, NXOS), Juniper, Arista, and Fortinet support it.
4. TTL Security
One of the first things you learn about eBGP connections is that, by default, the neighbor must only be one hop away. If you try and source the connection from a loopback or some other interface, it will fail unless you enable eBGP multihop. By default, BGP packets are sourced with a TTL of 1 and eBGP multihop will increase this TTL by whatever increment you chose so that the packet will arrive at the neighbor.
The problem with this is that if a malicious actor on the Internet were to source a BGP packet with a sufficiently large TTL (and matching session information), they could trigger a TCP reset and cause the neighbor to go down. TTL security aims to solve this.
Instead of sourcing BGP packets with the exact number of hops required to get to the neighbor, what if we set the TTL to the maximum, 255, and then set a lower bound to what the router will accept. For example, if our neighbor was 3 hops away, we would set the lower bound to be 255-3=222 and only accept packets with a TTL higher than 222. In the event that a malicious actor tries to send an RST packet to our router, the highest TTL they can manage would be 255 (hop count to our router). All packets with a lower TTL than specified will be discarded.
Beyond these suggestions, consider ways that you as a network operator can proactively monitor the propagation of your IP space on the public Internet to identify if and when changes occur to those advertisements. Deploying BGP security measures necessitates a holistic approach that encompasses both technical implementations and operational diligence.
Additionally, consider heading over to the Mutually Agreed Norms for Routing Security (MANRS) website where they provide implementation guides for network operators that can help you implement some of these suggestions.
