BGP MD5 Authentication
Last updated
Last updated
BGP MD5 Authentication allows you to authenticate BGP peers using an MD5 signature, which is an option built into TCP. RFC 2385 defines this feature. The MD5 signature is added to the TCP header of every packet.
You can use this with both iBGP peers and eBGP peers. As a reminder, TTL Security is only configurable on eBGP sessions.
MD5 Authentication does not encrypt the BGP packets. The packets themselves are still in clear text. You can sniff the session and see BGP Updates, etc. What MD5 Authentication does though, is it allows the router to process only the TCP header and decide whether the packet came from its peer. If the MD5 Authentication is bad or is missing, the router discards the packet without processing the BGP information inside the packet.
An attacker cannot do things such as reset the TCP session remotely, because with a missing MD5 signature, or bad MD5 signature, the router will simply not process the TCP packet.
To re-iterate, the MD5 signature is not part of the BGP protocol. BGP takes advantage of the TCP option, in the same way that it relies on TCP for reliable connectivity, packet sequencing, etc. The MD5 signature is not seen in the BGP Open message for example. It is strictly a function of TCP.
So you might be wondering, if the packets are still in clear text, what prevents someone from sniffing the packets and copying the MD5 signature in one of the packets? The reason this doesn’t work is because the MD5 hash is applied to the TCP header (src/dst IP, segment length, etc), the TCP data, and the password. This prevents someone from just re-using the signature they sniffed in a single captured packet.
We’ll re-use our existing lab from the last article, and configure MD5 Authentication on the session between R4 and XR5.
First let’s see what log messages we see if the password does not match. Let’s configure only R4.
R4 lets us know that packets from XR5 are missing the MD5 hash.
Let’s configure XR5 now, but with the wrong password to see if the log message changes.
R4’s log message changes from “No MD5 digest” to “Invalid MD5 digest”
If we correct the password on XR5, the session comes up
Let’s take a look at the packets:
As you can see, the packets are in clear text. Otherwise, wireshark would not be able to know that the data contains an OPEN message and KEEPALIVE message.
The MD5 digest is a TCP option. If we look at another packet, such as the OPEN from R4, we can see that every single BGP TCP packet contains an MD5 signature.
Keep in mind that I still have ttl-security configured from the last session. So ttl-security and MD5 authentication can work together to secure the BGP session.
