Protect BGP sessions with the TCP MD5 option

Since BGP uses TCP as its transport protocol, it is is vulnerable to all weaknesses of the TCP protocol itself. For a determined attacker, it is possible to forcibly close a BGP session or even hijack it and insert mailicious routing information into the BGP data stream.

Running BGP over IPsec would protect it against attacks on the TCP stream, but in practice that configuration is not deployed widely. Instead, the TCP MD5 option described in RFC 2385 is used commonly, as support for this protocol option is available on most BGP implementations.
The idea behind this feature is that to every packet in a TCP session a field is added with the MD5 checksum of the packet contents and a secret key. This establishes a cryptographically secure signature of the packet. Without knowing the key, it is near impossible to construct a packet with a valid signature. Since BGP speakers will immediately discard packets without a signature or with an invalid signature, the types of attacks described above cannot be executed without knowing the key.
The TCP MD5 option is available in most BGP implementations. For Cisco routers, all that is needed is a "neighbor x.x.x.x password mysecret" statement applied to the neighbor or peer-group definition. Juniper JunOS provides the "authentication-key mysecret" statement which can be applied globally at the BGP level, at the group level, or or at the individual neighbor level.
Unfortunately, for the open source Zebra and Quagga routing suites, the situation is more complicated. Since the MD5 checksum is computed at the TCP protocol level, it is a function of the operating system. For example, Linux does not support it natively, although a third-party kernel patch used to be available along with a wrapper library to have Zebra set the appropriate socket options. This is far from trivial to implement, unlike the password and authentication-key options described above.
Another approach to protect the the TCP session used by BGP is the BGP TTL security hack, presented at a recent NANOG meeting by Dave Meyer. These methods only protect the TCP session against attacks but do not protect against hostile BGP information received from the peer. Several other proposed BGP enhancements, such as S-BGP and soBGP address these issues. Unlike the TCP MD5 option described in this article, none of these protocols are widely deployed.