# LDP Authentication

LDP authentication uses TCP MD5 (option 19) for authentication, which is the same mechanism that BGP authentication uses. This does not encrypt the packets on the wire. The protocol (BGP or LDP) relies on TCP to drop the packets if the MD5 hash in the options header is not correct.



When using TCP MD5 authentication with BGP, the peering session uses simply uses authentication or it does not. It is configured using the **neighbor password** command. For LDP on IOS-XE, there are a few more options that we will investigate.

#### &#x20;<a href="#dcedefd1-45e1-4e46-aded-bc6696907703" id="dcedefd1-45e1-4e46-aded-bc6696907703"></a>

### IOS-XR Configuration <a href="#dcedefd1-45e1-4e46-aded-bc6696907703" id="dcedefd1-45e1-4e46-aded-bc6696907703"></a>

First we’ll briefly look at LDP authentication on IOS-XR. It works very similar to BGP. You can either configure the password for all neighbors, or per neighbor RID.

<pre><code>RP/0/0/CPU0:R1(config-ldp)#neighbor ?
  A.B.C.D:    LDP Id of neighbor
  dual-stack  Configure dual stack ipv4/ipv6 neighbor parameters
  password    Configure password for MD5 authentication for all neighbors
  &#x3C;cr>        
RP/0/0/CPU0:R1(config-ldp)#<a data-footnote-ref href="#user-content-fn-1">neighbor password ?</a>
  clear      Specifies an UNENCRYPTED password will follow
  encrypted  Specifies an ENCRYPTED password will follow

RP/0/0/CPU0:R1(config-ldp)#<a data-footnote-ref href="#user-content-fn-2">neighbor 1.1.1.1:0 password ?</a>
  clear      Specifies an UNENCRYPTED password will follow
  disable    Disables the global password from this neighbor
  encrypted  Specifies an ENCRYPTED password will follow
</code></pre>

#### &#x20;<a href="#id-1596dcb7-2e3c-456a-90d2-1594cbe81b0f" id="id-1596dcb7-2e3c-456a-90d2-1594cbe81b0f"></a>

### IOS-XE Configuration <a href="#id-1596dcb7-2e3c-456a-90d2-1594cbe81b0f" id="id-1596dcb7-2e3c-456a-90d2-1594cbe81b0f"></a>

IOS-XE is different, in that the password is configured under the **mpls ldp** **password fallback** command for all neighbors, or per neighbor using **mpls ldp neighbor&#x20;**_**RID**_**&#x20;password.** There is also an optional knob, **mpls ldp password required** that you can use.

<pre><code>R2(config)#mpls ldp password ?
  fallback  Specifies a fallback password will follow
  option    LDP password options
  required  MD5 password is required for the peer
  rollover  LDP password rollover parameters

R2(config)#<a data-footnote-ref href="#user-content-fn-3">mpls ldp neighbor 1.1.1.1 password ?</a>
  0     Specifies an UNENCRYPTED password will follow
  7     Specifies a HIDDEN password will follow
  LINE  The UNENCRYPTED (cleartext) password
  
R2(config)#<a data-footnote-ref href="#user-content-fn-4">mpls ldp password fallback ?</a>
  0          Specifies an UNENCRYPTED password will follow
  7          Specifies a HIDDEN password will follow
  LINE       The UNENCRYPTED (cleartext) password
  key-chain  Specifies a key-chain name will follow

R2(config)#<a data-footnote-ref href="#user-content-fn-5">mpls ldp password required ?</a>
  for   IP access-list specifying control on LDP peers
  &#x3C;cr>  &#x3C;cr>
</code></pre>



You set the password for all neighbors under **mpls ldp password fallback&#x20;**_**password**_**.** What does **fallback** mean though? I believe Cisco intends for you to configure passwords on a per-neighbor basis, and only _fallback_ to the fallback password if there is no explicit password configured for the neighbor.



If LDP neighborship(s) are already established, and you configure an LDP authentication password with **mpls ldp password fallback**, then existing neighborships will stay up. Likewise if an existing session is established, and you configure a password for the peer with **mpls ldp neighbor&#x20;**_**RID**_**&#x20;password**, that session will stay up.



You can use the **mpls ldp password required** knob to prevent this behaviour, and tear down existing sessions upon configuring the password. Even if you don’t have **mpls ldp password required** set, when you configure **mpls ldp password fallback**, any _new_ neighbors must have the correct MD5 password set.



In summary, **mpls ldp password fallback** configures the password for _new_ neighbor sessions. Existing neighbor sessions stay up. The command **mpls ldp password required** enforces the password for existing sessions as well.



### IOS-XE Demonstration

Some examples will help. First we’ll bring up LDP between two routers with no password on either end. Then we’ll add the fallback password and see that the neighborship stays up.

<pre><code>! The session is already up, with no password configured
R2(config)#do sho mpls ldp nei br
Peer LDP id          Uptime     NSR   GR  Discovery    Address    Labels    
-----------          ------     ---   --  ---------    -------    ------    
1.1.1.1:0            00:00:45   N     N   1            2          3

! We add a password for all neighbors on IOS-XE but not add the password on the neighbor.
R2(config)#mpls ldp password fallback my_password

! The neighbor 1.1.1.1 does not have a password configured, but the session stays up
R2(config)#do sho mpls ldp nei br             
Peer LDP id          Uptime     NSR   GR  Discovery    Address    Labels    
-----------          ------     ---   --  ---------    -------    ------    
1.1.1.1:0            00:01:35   N     N   1            2          3

R2(config)#do sho mpls ldp neighbor detail | in Password
        <a data-footnote-ref href="#user-content-fn-6">Password: not required, fallback, stale</a>
</code></pre>



You can see above that session to the peer stayed up, even though the peer has no password configured. You could say that this peer was “grandfathered in.” The **stale** keyword in the output indicates that the session is not using the configured password.



If we clear the LDP neighborship, now when the session tries to start again, R2 will require that the LDP neighborship uses MD5 authentication. Remember the **mpls ldp password required** command is _not_ configured right now.

```
R2(config)#do clear mpls ldp neighbor *

*Jul 24 02:54:27.247: %TCP-6-BADAUTH: No MD5 digest from 1.1.1.1(646) to 2.2.2.2(19423) (RST) tableid - 0
```



Let’s configure the password on the peer, R1.

```
*Jul 24 03:25:52.013: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP
R2(config)#do sho mpls ldp neighbor detail | in Password
        Password: not required, fallback, in use
```



As we can see above, the session comes up now on R2. Interestingly, the password is reported as “not required” still, reflecting the fact that we never configured the **mpls ldp password required** command. We know that technically the password really _is_ required because this was a new session that attempted to form _after_ we configured the password. Instead of “stale” we see “in use” now as well.



Let’s remove the password on both routers, establish the LDP session, then configure the password again, but make it required this time.

```
! Password removed on both routers
R2(config)#no mpls ldp password fallback cisco123
R2(config)#
*Jul 24 03:11:08.284: %LDP-5-PWDCFG: Password configuration changed for 1.1.1.1:0
*Jul 24 03:11:15.617: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP

R2(config)#mpls ldp password fallback cisco123
R2(config)#mpls ldp password required 
R2(config)#
*Jul 24 03:12:07.734: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is DOWN (Session's MD5 password changed)
```



If we add the password on the neighbor the session comes up. We can see that the password is required on the neighborship this time, due to the command **mpls ldp password required**.

```
R2(config)#do sho mpls ldp neighbor detail | in Password
        Password: required, fallback, in use
```

### &#x20;<a href="#id-919ee192-211b-4506-bb83-08c6a7286ff3" id="id-919ee192-211b-4506-bb83-08c6a7286ff3"></a>

### IOS-XR Demonstration <a href="#id-919ee192-211b-4506-bb83-08c6a7286ff3" id="id-919ee192-211b-4506-bb83-08c6a7286ff3"></a>

Let’s double check that IOS-XR works the way we expect it to. When we have an existing session and then configure a password, it should bring the existing session down.

```
! The session with R2 is already established

RP/0/0/CPU0:R1#show mpls ldp nei br
Sun Jul 24 03:13:33.545 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels    
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6 
-----------------  --  ---  ----------  ----------  ----------  ------------
2.2.2.2:0          N   N    00:01:05    1     0     2     0     3      0


! When we apply a neighbor password, all existing sessions will be brought down.
mpls ldp
 neighbor password clear my_password
commit

RP/0/0/CPU0:R1(config-ldp)#RP/0/0/CPU0:Jul 24 03:14:10.233 : tcp[400]: %IP-TCP-3-BADAUTH : Invalid MD5 digest from 2.2.2.2:33197 to 1.1.1.1:646
```



If we configure the fallback password on R2, the neighborship should come back up

```
R2(config)#mpls ldp password fallback my_password

*Jul 24 03:17:30.415: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is UP
```



The behavior of IOS-XR is more straight forward. When the password is configured, it is required for any existing and new sessions. IOS-XE adds some complexity but gives you more flexibility if you want to implement passwords in your brownfield environment. You can keep existing sessions up while you add the LDP password on your routers one-by-one. On IOS-XR you would have to take an outage window and try to commit all routers at the same time!

### &#x20;<a href="#id-2d1b6dd3-7565-43a7-b094-76126f180f1a" id="id-2d1b6dd3-7565-43a7-b094-76126f180f1a"></a>

### IOS-XE Rollover <a href="#id-2d1b6dd3-7565-43a7-b094-76126f180f1a" id="id-2d1b6dd3-7565-43a7-b094-76126f180f1a"></a>

You may have noticed the **rollover** option in IOS-XE under **mpls ldp password**. This feature allows you to delay a configuration change to the LDP password. If you set rollover to 3 minutes, for example, when you change the **fallover** password, it won’t take effect for 3 minutes.



Let’s verify this is the case. We’ll establish an LDP session between R1 and R2 using MD5 authentication, change the password on R2, and see if the neighbor goes down.

```
RP/0/0/CPU0:R1#show run mpls ldp
Sun Jul 24 21:34:44.289 UTC
mpls ldp
 neighbor
  password encrypted 060B161E5C4F1A0A1218000F
 !
 interface GigabitEthernet0/0/0/0

R2#show run | sec mpls ldp
mpls ldp password required
mpls ldp password fallback my_password

R2#show mpls ldp nei br
Peer LDP id          Uptime     NSR   GR  Discovery    Address    Labels    
-----------          ------     ---   --  ---------    -------    ------    
1.1.1.1:0            18:09:02   N     N   1            2          3
```

```
#R2
mpls ldp password rollover duration 3
mpls ldp password fallback my_password_new

R2(config)#do sho clock
*Jul 24 21:35:53.214: %LDP-5-PWDCFG: Password configuration changed for 1.1.1.1:0k
*21:35:55.326 UTC Sun Jul 24 2022

*Jul 24 21:39:31.786: %TCP-6-BADAUTH: Invalid MD5 digest from 1.1.1.1(646) to 2.2.2.2(51181) tableid - 0

*Jul 24 21:39:56.502: %TCP-6-BADAUTH: Invalid MD5 digest from 1.1.1.1(646) to 2.2.2.2(51181) tableid - 0
R2(config)#do sho mpls ldp nei br
Peer LDP id          Uptime     NSR   GR  Discovery    Address    Labels    
-----------          ------     ---   --  ---------    -------    ------    
1.1.1.1:0            18:14:11   N     N   1            2          3         

*Jul 24 21:40:45.926: %TCP-6-BADAUTH: Invalid MD5 digest from 1.1.1.1(646) to 2.2.2.2(51181) tableid - 0

R2(config)#do sho mpls ldp nei br
*Jul 24 21:41:08.063: %TCP-6-BADAUTH: Invalid MD5 digest from 1.1.1.1(646) to 2.2.2.2(51181) tableid - 0
Peer LDP id          Uptime     NSR   GR  Discovery    Address    Labels    
-----------          ------     ---   --  ---------    -------    ------    
1.1.1.1:0            18:15:17   N     N   1            2          3

*Jul 24 21:42:07.381: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (1) is DOWN (Session KeepAlive Timer expired)
```

Interestingly, the session is not torn down immediately. The UDP Hellos keep functioning, but the TCP keepalive timer needs to expire. This appears to be around 3 minutes or so.

[^1]: When no neighbor is specified, this password applies to all neighbors

[^2]: When specifying a neighbor you must use X.X.X.X:0 format

[^3]: On IOS-XE the neighbor is specified without the :0 suffix

[^4]: You must use **fallback** to apply a password to all neighbors

[^5]: This knob requires a password for existing sessions. When this is not set, any existing sessions established before a password was set will stay up.

[^6]: This states that a password is not required because the session was up before we set a **fallback** password. The password for this neighbor is also stale. If the neighbor session bounces the password will then be required.
