LDP Authentication
Last updated
Last updated
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.
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.
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 RID password. There is also an optional knob, mpls ldp password required that you can use.
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.
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.
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.
Let’s configure the password on the peer, R1.
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.
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.
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.
If we configure the fallback password on R2, the neighborship should come back 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!
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.
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.