Back in the late 1980s and the early 1990s when BGP was developed, security was still an afterthought for protocols used on the internet. Since that time, we’ve come to realize that there are two potential security issues with BGP: you may be talking to the wrong device, or the right device may be saying the wrong thing.
Talking BGP to the wrong device can be as dramatic as someone rerouting the cable towards your BGP neighbor towards a different router, and then having that router impersonate your BGP neighbor. The more mundane risk consists of TCP reset attacks. TCP sessions can remain active indefinitely, and can also be idle for long periods of time. So it’s far from inconceivable that when systems A and B have a TCP session and system A reboots, A receives TCP packets from B after the reboot. Obviously, A then no longer has an active TCP session. So it sends B a “TCP reset” packet, which prompts B to tear down the session.
As TCP has no strong security features, a third party can send a spoofed TCP reset to A that seems to come from B. A will then tear down its TCP session and thus the BGP session running over that TCP session, interrupting the traffic flow between A and B until a new session can be set up. The attacker needs to send a packet with the right IP addresses, port numbers and TCP sequence number. The IP addresses are usually not too hard to find out and one port number is 179 (the BGP port number). So the attacker simply sends packets with all possible remaining port and sequence numbers, and within a minute or so they’ll hit the right combination and you can say goodbye to that BGP session.
There are three security mechanisms that can protect against this: the BGP TCP MD5 password, IPsec and the Generalized TTL Security Mechanism (GTSM).
The BGP TCP MD5 password system is described in RFC 2385, published in 1998. At only six pages, it’s a very short RFC, so if you have never read an RFC before, 2385 is a good one to start with. What the mechanism does is compute an MD5 cryptographic hash over the TCP “pseudo header”, which includes the IP addresses used, the BGP packet carried in the TCP segment and a secret password. The resulting MD5 hash is then put in a TCP option in the TCP header and the packet is sent on its way. (The password isn’t transmitted.) The other side performs the same MD5 calculation, and checks the result against the MD5 hash in the TCP header. If the two MD5 hashes are the same, then we can be reasonably sure of two things:
So if an attacker sends spoofed TCP reset packets, the MD5 hash will be missing or incorrect, so the router simply ignores those packets and the BGP session is unaffected. The password is configured as follows (Cisco):
neighbor 192.0.2.60 password 0 MySecretPassword
neighbor 192.0.2.70 password MySecretPassword
neighbor 192.0.2.80 password 7 AC24A9BD20A
The first line shows the password in clear text in the router’s configuration. The second line enters the password in clear text, but the router will then apply a simple (and relatively easily reversed!) encryption so the password is hidden from “over-the-shoulder attacks” as shown in the third line. On Juniper:
neighbor 192.0.2.90 {
authentication-key “$8$5R8/DCy1EZwXQUhe.mP2”; ## SECRET-DATA
}
The MD5 password system works well enough, and it’s widely used in practice. However, it’s relatively weak. Not only is the MD5 hashing algorithm at the end of its useful life, but it’s also not used in the best way and the system has no provisions for changing the password. Last but not least, if someone simply generates lots of fake BGP packets with incorrect hashes, the router CPU will be drowned in MD5 calculations.
IPsec is a general-purpose security mechanism that addresses all these weaknesses (there is also an improved version of the MD5 password system). Unfortunately, the ability to protect BGP sessions with IPsec is not widely implemented, and where it is, it’s usually quite complex to set up. So in practice, IPsec is rarely used to protect BGP.
The third mechanism to protect BGP is GTSM, which takes a completely different approach. Normally, (external) BGP is spoken between routers that share an IP subnet. I.e., there may be switches between router A and router B, but no additional routers. BGP enforces this by checking the TTL (Time-To-Live) field in the IP header of BGP packets. For normal packets, the TTL is set to something like 60, and then every router that forwards the packets decrements the TTL by one. When the TTL reaches zero, the packet is dropped. This makes sure packets don’t keep circling around forever when routing loops occur. BGP, however, sets the TTL to 1 for EBGP (external BGP) sessions upon transmission. The receiving router then checks if the TTL is still 1. If not, something bad must have happened so the BGP session is torn down.
GTSM (RFC 5082) takes this check one step further. Rather than setting the TTL to 1, when using GTSM, a BGP router sets the TTL of BGP packets to 255. The receiving router then checks if the incoming packets have a TTL of 255 and drops the packets if they don’t. Because routers decrement the TTL when forwarding packets, and 255 is the maximum value, it’s impossible for an attacker several hops away to send packets that arrive with a TTL of 255. This system is also extensively used for IPv6 packets that are only intended for local use. It has the advantage that there’s no need to exchange passwords or perform complex calculations. GTSM isn’t as widely supported as the MD5 password, but most routing platforms support it. This is how to configure it on Cisco:
According to the current documentation, Juniper doesn’t support configuring GTSM directly, but it is possible to set up a firewall rule to accomplish the same thing (page 865 of this PDF file).
Unfortunately, GTSM isn’t widely used, because it’s not automatically negotiated: it must be explicitly enabled on both ends. If GTSM is only enabled on one end of the BGP session, the session never comes up.
The next three weeks, we’ll look at the situation where an autonomous system announces prefixes that don’t belong to that AS, and what mechanisms are currently available and under development to filter out those incorrect announcements.