Improving BGP Security: 6 Quick Tips
The routing protocol has well-known security issues. Here are some ways to mitigate the risk.
May 9, 2016
Border Gateway Protocol (BGP) is the glue of the Internet. Without BGP and domain name servers (DNS), the Internet as you know it would not exist.
However, BGP security remains a challenge. One of the drawbacks of the routing protocol is that anyone is allowed to advertise any prefix, whether they own it or not. The most famous incident is probably when Pakistan Telecom started advertising prefixes belonging to YouTube, which routed Internet traffic towards Pakistan instead of YouTube’s data centers.
There are different initiatives working on the problem of authenticating incoming BGP routes. The key technology is to use certificates, but doing so leads to a lot of implications, such as more route churn, larger BGP tables, and the need to learn how to exchange certificates and handle unsigned routes. Considering the difficulties we have today to get ISPs to implement even basic protection mechanisms, I don't expect authentication of BGP routes to reach widespread usage for a long time.
So what are some of the things we can do today to improve BGP security? Here are six tips.
Protecting the BGP speaker
The BGP speaker should be protected by implementing features such as control plane policing (CoPP), which does not allow for anyone not configured as a BGP neighbor to send packets to TCP 179 --the well-known port that BGP uses. The speaker should also be protected from ICMP floods or other attacks towards the control plane. Data plane filters can be implemented if there is no support for control plane filters, but they require much more configuration. Protecting the BGP speaker decreases the risk of an attack against your BGP speaker, which could be a method to get your prefixes offline and allow attackers to potentially start advertising them.
Protecting the BGP sessions
Interior gateway protocols (IGPs) such as Open Shortest Path First (OSPF) are relatively easy to establish adjacencies to if you are layer 2 adjacent because hello packets are sent to a multicast address that is accessible to anyone. BGP relies on explicitly configured neighbors, which makes it harder for someone to establish an adjacency. There are a few methods to make it even more difficult though, which I describe below.
TCP MD5
BGP can use TCP Message Digest 5 (MD5) to create a hash used to authenticate the BGP packets sent between two neighbors. Let’s be honest and say that MD5 is not a great algorithm to protect your packets with these days, due to weaknesses in the algorithm. It is however better than sending them in clear text.
BGP TTL security (GTSM)
The next method is called Generalized TTL Security Mechanism (GTSM), which checks the incoming time to live (TTL) of a BGP packet and prevents attackers from using forged packets. If you set the TTL to 255, you can make sure that only directly connected routers can establish a BGP session and not someone on the outside because their packets would never make it to you with a TTL of 255 in the IP packet. Layer 3 devices decrement the TTL before forwarding a packet, which makes it impossible for a packet to reach your router with a TTL of 255.
Prefix filters
Had the upstream ISPs of Pakistan Telecom implemented proper prefix filters, the leaking of YouTube’s prefixes would never have happened back in 2008. It’s the responsibility of ISPs to allow their customers to only advertise prefixes that actually belong to them. A lot of ISPs don’t implement filters, which means that a customer can advertise any prefix, creating the risk of either a malicious hijack or a fat finger that could wreak havoc as well. Many ISPs blame the lack of filters due to the overhead of implementing them and keeping them updated. This is a task that should be automated, based on getting data from the routing registries and regularly updated every night. There are ISPs doing this today and tools available to get started.
Keep your data updated
Because some ISPs are implementing prefix filtering based on what data is in the routing registries such as ARIN and RIPE, it's critical you update your data. If you did not put your routes and your routing policy into those databases, you may end up with your routes not being advertised. Keep your data updated and add any new prefixes that you plan to advertise to the Internet. Also make sure to remove any prefixes that no longer belong to you. Unfortunately there will always be ISPs and organizations that are not interested in building a better Internet, but you should still do you part.
To demonstrate how the data can look in one of these routing registries, I did a search for one IP used for cisco.com and queried the database at radb.net.
Dib-BGP security.png
By searching for the IP, we get some interesting data. There is a /24 route that belongs to a larger /18 route, but in BGP it is advertised as a /24 route. This is probably to minimize the risk of a hijack of the cisco.com website.
The origin is autonomous system (AS) 109, which belong to Cisco. We can also see when this information was last updated and that the routing registry is ARIN, not surprising given that Cisco is an American company.
There are initiatives to make BGP more secure, but don’t wait around for them to gain traction. There are already tools that can help with several of the issues of BGP and most of them require very little effort to implement. You can learn about BGP security in the IETF's RFC 7454, BGP Operations and Security.
About the Author
You May Also Like