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.
IOS-XR Configuration
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.
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
<cr>
RP/0/0/CPU0:R1(config-ldp)#
clear Specifies an UNENCRYPTED password will follow
encrypted Specifies an ENCRYPTED password will follow
RP/0/0/CPU0:R1(config-ldp)#
clear Specifies an UNENCRYPTED password will follow
disable Disables the global password from this neighbor
encrypted Specifies an ENCRYPTED password will follow
IOS-XE Configuration
IOS-XE is different, in that the password is configured under the mpls ldppassword fallback command for all neighbors, or per neighbor using mpls ldp neighbor RID password. There is also an optional knob, mpls ldp password required that you can use.
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)#
0 Specifies an UNENCRYPTED password will follow
7 Specifies a HIDDEN password will follow
LINE The UNENCRYPTED (cleartext) password
R2(config)#
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)#
for IP access-list specifying control on LDP peers
<cr> <cr>
You set the password for all neighbors under mpls ldp password fallback 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 RID 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.
! 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
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
IOS-XR Demonstration
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!
IOS-XE Rollover
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.
