> For the complete documentation index, see [llms.txt](https://ccnp-sp.gitbook.io/studyguide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ccnp-sp.gitbook.io/studyguide/routing/bgp-security/bgp-md5-authentication.md).

# BGP MD5 Authentication

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.

### Lab <a href="#dba750cf-f095-47e0-af75-b94e60249ce1" id="dba750cf-f095-47e0-af75-b94e60249ce1"></a>

<figure><img src="/files/4xkoQ5IZWDdLBk4SI7NU" alt=""><figcaption></figcaption></figure>

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#
router bgp 65001
 neighbor 10.4.5.5 password s3cr3t
```

R4 lets us know that packets from XR5 are missing the MD5 hash.

```
*Jul 11 20:19:24.633: %TCP-6-BADAUTH: No MD5 digest from 10.4.5.5(62144) to 10.4.5.4(179) tableid - 0
```

Let’s configure XR5 now, but with the wrong password to see if the log message changes.

```
XR5#
router bgp 65002
 neighbor 10.4.5.4
  password s3cret
```

R4’s log message changes from “No MD5 digest” to “Invalid MD5 digest”

```
*Jul 11 20:20:46.610: %TCP-6-BADAUTH: Invalid MD5 digest from 10.4.5.5(62144) to 10.4.5.4(179) tableid - 0
```

If we correct the password on XR5, the session comes up

```
XR5#
router bgp 65002
 neighbor 10.4.5.4
  password s3cr3t

R4#
*Jul 11 20:21:47.834: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Up
```

Let’s take a look at the packets:

<figure><img src="/files/dMIh4al5Ecd1Jngym1Ei" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/BiQyZcQIfBEOTlR2DuKF" alt=""><figcaption></figcaption></figure>

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.

### Further Reading <a href="#id-3fc9b666-35dd-414b-9490-930c33c05b8b" id="id-3fc9b666-35dd-414b-9490-930c33c05b8b"></a>

<https://datatracker.ietf.org/doc/html/rfc2385>

\
<https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/112188-configure-md5-bgp-00.html>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://ccnp-sp.gitbook.io/studyguide/routing/bgp-security/bgp-md5-authentication.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
