LDP session authentication (TCP MD5)

An LDP session runs over TCP port 646. To stop spoofed segments being injected into it, RFC 5036 specifies protection with the TCP MD5 Signature Option (RFC 2385). Only the session is protected: neither discovery nor the label bindings are authenticated. This article verifies that asymmetry, the confusing state you get when only one end is configured, and how getting the scope wrong takes down unrelated peers, on an IOS XR (XRd) lab. For the basics, see What is LDP.

What is protected, and what is not

RFC 2385, quoted by section 2.9.1 of RFC 5036, computes an MD5 digest from information known only to the two ends of the connection and attaches it to the TCP segment. The password itself never appears in the connection stream, so an attacker has to obtain it as well as guess the sequence numbers.

Section 2.9.2 defines how LDP uses it.

Item	What the RFC says
Unit of configuration	A password (shared secret) is configured for each peer
When validation fails	The segment is dropped with no response to the sender
A peer with no password configured	Its LDP Hellos are ignored

The limits are stated too. Per section 5.2, Privacy, LDP does not encrypt label distribution. Reading the label bindings on the path is not prevented; what is prevented is the injection of spoofed segments.

Hellos (UDP 646) are not authenticated. “Ignore the Hellos” in 2.9.2 applies to peers for which no password has been configured, so Hellos from a peer that is configured are not ignored. In other words, with a password on one end only, the adjacency stays visible while the session alone fails to come up.

Configuration on IOS XR

The commands sit directly under mpls ldp. A peer is given as an LDP identifier that includes the label space number, such as 3.3.3.3:0.

Scope	Command	Who it affects
Per peer	`neighbor <LDP-Id> password clear <password>`	That peer only
All peers	`neighbor password clear <password>`	Every LDP peer of that router
Disable the shared password for one peer	`neighbor <LDP-Id> password disable`	Returns that peer to no authentication

clear means “the plaintext follows”; what gets stored is encrypted.

The all-peer form drags unrelated peers down with it

The all-peer form applies to every other LDP session the router has. Add it meaning to protect one link and the sessions with peers that do not know the password go down at the same time. That is exactly what the name says, but reading it as “it will not affect peers I have not configured yet” gets it backwards.

To protect one link, use the per-peer form. Use the all-peer form only once the same password has been rolled out to every peer of that router.

Note that the per-peer password and password disable are the same configuration line: whichever is entered later replaces the other. Combining an all-peer password with a disable for one specific peer does work.

What happens with a password on one end only

The end with the password expects every incoming segment to carry a digest. The end without one sends none, validation fails, and the segment is dropped with no response. To the sender the peer simply looks silent, so it keeps retransmitting its TCP SYN.

Hellos keep flowing, so show mpls ldp discovery still shows the adjacency while show mpls ldp neighbor goes empty.

When the session drops, so does the label exchange. The IGP is unaffected, the IP routes stay, and IP reachability inside the core keeps working while only the VPN traffic carried over MPLS fails. The routing table looks healthy, which makes the cause hard to guess.

Changing a password behaves the same way. The moment one end has a different value the two disagree, so a change costs an outage just like the initial rollout.

Lab topology

A chain with no redundancy. The core (PE1 - P1 - P2 - PE2) runs OSPF and LDP, and CE1 and CE2 attach to the PEs in VRF CUST-A and reach each other over VPNv4. Authentication is added to the PE1 - P1 link only.

The MPLS-LDPAUTH lab
  CE1 ------ PE1 ------ P1 ------ P2 ------ PE2 ------ CE2
(AS 65101)    |          ^                   |   (AS 65102)
           vrf CUST-A    |                vrf CUST-A
              +------ iBGP vpnv4 (Lo0) ------+
                         authentication goes here

Router	Lo0	Role	Label range
CE1	1.1.1.1	AS 65101, 192.168.1.0/24	-
PE1	2.2.2.2	Ingress/egress LSR, vrf CUST-A	24000 - 24999
P1	3.3.3.3	Transit LSR. Has two peers: PE1 and P2	33000 - 33999
P2	4.4.4.4	Transit LSR	44000 - 44999
PE2	5.5.5.5	Ingress/egress LSR, vrf CUST-A	55000 - 55999
CE2	6.6.6.6	AS 65102, 192.168.2.0/24	-

The label ranges are split per router so that a label in show mpls forwarding can be traced back to whoever allocated it.

P1 has two peers, PE1 and P2, so when authentication goes on PE1 - P1 only, whether P1 - P2 stays intact can be checked on the same router.

Overview of the verification

STEP	Operation	What it checks
0	No authentication	The session is up and ping / traceroute work
1	`neighbor 3.3.3.3:0 password` on PE1 only	The session drops while the adjacency stays; IP works but the VPN fails; P1 - P2 is untouched
2	The same password on P1	It recovers and the TCP handshake carries the MD5 option
3	Change only PE1’s password	A change costs an outage too
4	P1 follows with the new value	It recovers
5	Replace both with the all-peer form	PE1 - P1 holds, but P1 - P2 drops
6	`neighbor 3.3.3.3:0 password disable` on PE1	That peer returns to no authentication and drops again
7	Remove the `disable` from PE1	PE1 - P1 recovers
8	Remove the password from both (final state)	Back to the same state as STEP 0

Reachability is measured in every STEP with ping 192.168.2.1 source 192.168.1.1 count 50 timeout 1 from CE1, and inside the core with ping 5.5.5.5 source 2.2.2.2 from PE1.

STEP 0: without authentication

The session between PE1 and P1 is up and carries seven labels.

STEP 0 PE1 show mpls ldp neighbor brief
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Sun Oct 11 23:04:12.772 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:21:00    1     0     3     0     7      0

STEP 1: a password on PE1 only

Only PE1 is configured. What was entered is password clear, but what is stored is already encrypted.

Configuration committed on PE1 in STEP 1
mpls ldp
 neighbor
  3.3.3.3:0 password encrypted 11253D3536273F2455
 !
!

The adjacency stays, only the session drops

show mpls ldp neighbor brief returns nothing at all.

STEP 1 PE1 show mpls ldp neighbor brief (nothing comes back)
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Sun Oct 11 23:12:09.977 UTC

Yet show mpls ldp discovery still shows a live adjacency. It is still xmit/recv, and the Established timestamp has not been interrupted by the configuration change.

STEP 1 PE1 show mpls ldp discovery
RP/0/RP0/CPU0:PE1#show mpls ldp discovery
Sun Oct 11 23:12:09.646 UTC

Local LDP Identifier: 2.2.2.2:0
Discovery Sources:
  Interfaces:
    GigabitEthernet0/0/0/1 : xmit/recv
      VRF: 'default' (0x60000000)
      LDP Id: 3.3.3.3:0, Transport address: 3.3.3.3
          Hold time: 15 sec (local:15 sec, peer:15 sec)
          Established: Oct 11 22:43:06.419 (00:29:03 ago)

Hellos are not authenticated, so the adjacency alone survives. Looking only at show mpls ldp neighbor suggests there is no peer, when in fact the peer is plainly visible.

Only the labels disappear

The forwarding table makes it obvious what was lost. In STEP 0 the entries carried outgoing labels. The outgoing labels 33001 to 33003 were allocated by P1: because the label ranges are split per router, you can tell who handed out a label.

STEP 0 PE1 show mpls forwarding
RP/0/RP0/CPU0:PE1#show mpls forwarding
Sun Oct 11 23:04:14.341 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Pop         3.3.3.3/32         Gi0/0/0/1    10.2.3.3        212
24001  Pop         10.3.4.0/24        Gi0/0/0/1    10.2.3.3        0
24002  33001       4.4.4.4/32         Gi0/0/0/1    10.2.3.3        5644
24003  33002       10.4.5.0/24        Gi0/0/0/1    10.2.3.3        0
24004  33003       5.5.5.5/32         Gi0/0/0/1    10.2.3.3        23751
24005  Unlabelled  192.168.1.0/24[V]  Gi0/0/0/0    10.1.2.1        12400

Once the session drops, every one of those entries becomes Unlabelled. The destination and the outgoing interface are unchanged; only the information needed to push a label is gone.

STEP 1 PE1 show mpls forwarding
RP/0/RP0/CPU0:PE1#show mpls forwarding
Sun Oct 11 23:12:11.216 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Unlabelled  3.3.3.3/32         Gi0/0/0/1    10.2.3.3        0
24001  Unlabelled  10.3.4.0/24        Gi0/0/0/1    10.2.3.3        0
24002  Unlabelled  4.4.4.4/32         Gi0/0/0/1    10.2.3.3        5644
24003  Unlabelled  10.4.5.0/24        Gi0/0/0/1    10.2.3.3        0
24004  Unlabelled  5.5.5.5/32         Gi0/0/0/1    10.2.3.3        11701
24005  Unlabelled  192.168.1.0/24[V]  Gi0/0/0/0    10.1.2.1        5100

IP works, only the VPN fails

Reachability from CE1 to CE2 is a complete outage.

STEP 1 CE1 ping 192.168.2.1 (the VPN traffic)
RP/0/RP0/CPU0:CE1#ping 192.168.2.1 source 192.168.1.1 count 50 timeout 1
Sun Oct 11 23:09:25.544 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 192.168.2.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

In the same STEP, IP reachability from PE1 to PE2’s loopback is lossless.

STEP 1 PE1 ping 5.5.5.5 (IP reachability inside the core)
RP/0/RP0/CPU0:PE1#ping 5.5.5.5 source 2.2.2.2 count 50 timeout 1
Sun Oct 11 23:10:22.902 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 5.5.5.5 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (50/50), round-trip min/avg/max = 8/11/26 ms

OSPF keeps running, so the IP routes remain and only the transport LSP is gone. Nothing looks wrong in the routing table.

TCP gets no answer

P1 keeps sending SYNs to re-establish the session. Their TCP options are 8 bytes, just MSS and window scale, with no MD5 signature.

STEP 1 No.14 SYN (P1 to PE1), TCP options
    Options: (8 bytes), Maximum segment size, Window scale, End of Option List (EOL)
        TCP Option - Maximum segment size: 1240 bytes
            Kind: Maximum Segment Size (2)
            Length: 4
            MSS Value: 1240
        TCP Option - Window scale: 0 (multiply by 1)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 0
            [Multiplier: 1]
        TCP Option - End of Option List (EOL)
            Kind: End of Option List (0)

PE1 cannot validate them, so per RFC 2385 it drops them with no response.

Download the pcap of the packet in the tshark output above (No.14 SYN)

What to look at when troubleshooting

The syslog differs between the two ends. Only the end that was configured can tell why.

STEP 1 syslog on PE1 (the side with the password)
RP/0/RP0/CPU0:Oct 11 23:07:22.906 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-NBR_CHANGE : VRF 'default' (0x60000000), Neighbor 3.3.3.3:0 is DOWN (Session MD5 password changed)

STEP 1 syslog on P1 (the side without it)
RP/0/RP0/CPU0:Oct 11 23:07:22.912 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-NBR_CHANGE : VRF 'default' (0x60000000), Neighbor 2.2.2.2:0 is DOWN (TCP connection closed)

The other end only gets TCP connection closed. It cannot tell that the peer turned on authentication, so when only one end has changed, the end that does not know about the change cannot reach the cause. The things to check:

What to look at	With a password on one end only
`show mpls ldp neighbor`	Empty. Looks like there is no peer
`show mpls ldp discovery`	Hellos are arriving. The cause is at the session layer
`show mpls forwarding`	All `Unlabelled`. The routes are there, the labels are not
`show ospf neighbor` / `show route`	Normal. The IGP is unaffected
syslog (the configured end)	`DOWN (Session MD5 password changed)`
syslog (the other end)	`DOWN (TCP connection closed)`

STEP 2: the same password on both ends

Adding the same password to P1 brings it back, with seven labels again.

Configuration committed on P1 in STEP 2
mpls ldp
 neighbor
  2.2.2.2:0 password encrypted 00283736256E3F2E5E
 !
!

STEP 2 PE1 show mpls ldp neighbor brief
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Sun Oct 11 23:18:14.919 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:02:52    1     0     3     0     7      0

The handshake SYN now carries an MD5 signature (Kind 19), and the options have grown to 28 bytes.

STEP 2 No.9 SYN (P1 to PE1), TCP options
    Options: (28 bytes), Maximum segment size, Window scale, No-Operation (NOP), TCP MD5 signature, End of Option List (EOL), End of Option List (EOL)
        TCP Option - Maximum segment size: 1216 bytes
            Kind: Maximum Segment Size (2)
            Length: 4
            MSS Value: 1216
        TCP Option - Window scale: 0 (multiply by 1)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 0
            [Multiplier: 1]
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - TCP MD5 signature
            Kind: MD5 Signature Option (19)
            Length: 18
            MD5 digest: 337cab19feb964100c6a8ddb7e312780
        TCP Option - End of Option List (EOL)
            Kind: End of Option List (0)
        TCP Option - End of Option List (EOL)
            Kind: End of Option List (0)

Download the pcap of the packet in the tshark output above (No.9 SYN)

The SYN/ACK that comes back carries one as well (the digest differs per direction).

STEP 2 No.10 SYN/ACK (PE1 to P1), TCP options
    Options: (28 bytes), Maximum segment size, Window scale, No-Operation (NOP), TCP MD5 signature, End of Option List (EOL), End of Option List (EOL)
        TCP Option - Maximum segment size: 1216 bytes
            Kind: Maximum Segment Size (2)
            Length: 4
            MSS Value: 1216
        TCP Option - Window scale: 0 (multiply by 1)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 0
            [Multiplier: 1]
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - TCP MD5 signature
            Kind: MD5 Signature Option (19)
            Length: 18
            MD5 digest: ac7599ea7de4490ef9eff0cedc3030fd
        TCP Option - End of Option List (EOL)
            Kind: End of Option List (0)
        TCP Option - End of Option List (EOL)
            Kind: End of Option List (0)

Download the pcap of the packet in the tshark output above (No.10 SYN/ACK)

The options grew from 8 to 28 bytes, that is by 20, while the advertised MSS fell from 1240 to 1216, that is by 24. The MD5 signature is an 18-byte option including kind and length, padded to 20. Because the drop in MSS does not match the growth in options, this capture does not show how XR decides the MSS it advertises (the interface IPv4 MTU is 1500, and neither value is derived directly from it).

STEP 3 and 4: changing the password also costs an outage

Only PE1’s password is changed to a different value.

Configuration committed on PE1 in STEP 3
mpls ldp
 neighbor
  3.3.3.3:0 password encrypted 153E2F3C251F1F0C7A
 !
!

The two disagree immediately, the session drops, and the syslog gives the same reason as in STEP 1.

STEP 3 syslog on PE1
RP/0/RP0/CPU0:Oct 11 23:21:26.608 UTC: mpls_ldp[1178]: %ROUTING-LDP-5-NBR_CHANGE : VRF 'default' (0x60000000), Neighbor 3.3.3.3:0 is DOWN (Session MD5 password changed)

Setting P1 to the same new value brings it back (STEP 4). Changing the value alone causes exactly the same outage as adding it.

STEP 5: the all-peer form takes an unrelated peer down

The per-peer configuration is replaced by the all-peer form. Both PE1 and P1 get it, so the PE1 - P1 session is preserved.

Configuration committed on P1 in STEP 5
mpls ldp
 neighbor
  password encrypted 013F22347A3E322773
  no 2.2.2.2:0 password encrypted 0527223F00797A214B
 !
!

P1 - P2 drops, however. Seen from P2, the only peer left is PE2.

STEP 5 P2 show mpls ldp neighbor brief
RP/0/RP0/CPU0:P2#show mpls ldp neighbor brief
Sun Oct 11 23:42:33.104 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
5.5.5.5:0          N   N    00:58:58    1     0     2     0     7      0

P1 now demands an MD5 digest from every peer, so it discards P2’s segments. P2 keeps sending SYNs and not one of them is answered.

STEP 5 SYNs on the P1 - P2 link, and the SYN/ACKs that came back
$ tshark -r - -Y 'tcp.flags.syn==1 && tcp.flags.ack==0 && ip.src==4.4.4.4' \
    < mpls-ldp-authentication-step5-p1p2.pcap | wc -l
52
$ tshark -r - -Y 'tcp.flags.syn==1 && tcp.flags.ack==1' \
    < mpls-ldp-authentication-step5-p1p2.pcap | wc -l
0

The options on those SYNs are the same 8 bytes that P1 was sending to PE1 back in STEP 1.

STEP 5 No.22 SYN (P2 to P1), TCP options
    Options: (8 bytes), Maximum segment size, Window scale, End of Option List (EOL)
        TCP Option - Maximum segment size: 1240 bytes
            Kind: Maximum Segment Size (2)
            Length: 4
            MSS Value: 1240
        TCP Option - Window scale: 0 (multiply by 1)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 0
            [Multiplier: 1]
        TCP Option - End of Option List (EOL)
            Kind: End of Option List (0)

Download the pcap of the packet in the tshark output above (No.22 SYN)

Exactly the failure of STEP 1 has appeared on a link nobody touched, because a change meant to protect one link applied to every session of that router.

STEP 6 and 7: disabling authentication for one peer

Keeping the shared password in place, PE1 turns authentication off for this one peer.

Configuration committed on PE1 in STEP 6
mpls ldp
 neighbor
  3.3.3.3:0 password disable
 !
!

PE1 stops attaching the digest, so the session with P1, which still demands one, drops again. Removing the disable (STEP 7) falls back to the shared password and it recovers.

STEP 8: remove everything and return to the start

With the password removed from both ends, the session is re-established with a handshake that has no MD5 option, and P1 - P2 comes back too.

Configuration committed on PE1 in STEP 8
mpls ldp
 neighbor
  no password encrypted 04772F362E1478665B
 !
!

STEP 8 PE1 show mpls ldp neighbor brief
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Mon Oct 12 00:03:10.500 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:03:24    1     0     3     0     7      0

The running-config of the final STEP is identical to STEP 0 on all six routers, compared down to the number of occurrences of each line in the collected data.

Which sessions were alive in each STEP; the numbers are the labels being received.

STEP	PE1 - P1	P1 - P2	P2 - PE2	CE1 to CE2 (VPN)	PE1 to PE2 (core IP)
0	7	7	7	100% (50/50)	100% (50/50)
1	down	7	7	0% (0/50)	100% (50/50)
2	7	7	7	100% (50/50)	100% (50/50)
3	down	7	7	0% (0/50)	100% (50/50)
4	7	7	7	100% (50/50)	100% (50/50)
5	7	down	7	0% (0/50)	100% (50/50)
6	down	down	7	0% (0/50)	100% (50/50)
7	7	down	7	0% (0/50)	100% (50/50)
8	7	7	7	100% (50/50)	100% (50/50)

Design notes

If both ends cannot be done at once, decide the order first. A one-sided state always means a session outage. Rolling this out on a live core needs a maintenance window per link
Scope it with the per-peer form. The all-peer form takes the router’s other sessions down at the same time. Use it only after the password has reached every peer
The other end is told nothing. When changing authentication at a boundary with another organisation (inter-AS), tell them beforehand or they cannot identify the cause
Changing a password also costs an outage. It drops with Session MD5 password changed and then re-establishes, so plan a change exactly like a rollout
Nothing is encrypted. If the label bindings themselves need to be hidden, this mechanism is not enough

Verification configs and show output

For every STEP, the following kinds of output were collected from all six routers, one file per router. The verification config is the ..._run.txt (the final state is the one from the last STEP).

File	Content
`..._clear.txt`	The record of the counters cleared in that STEP (`clear counters interface` and `clear mpls forwarding counters`)
`..._ping.txt`	The `ping` (50 packets, 1-second timeout) and `traceroute` of that STEP
`..._show.txt`	`show version`, `show interface description`, the OSPF, LDP and MPLS forwarding set, `show tcp brief`, `show running-config mpls ldp` and so on
`..._log.txt`	`show logging` narrowed to that STEP. A marker is written with `logmsg` at the start of each STEP and its timestamp is passed to `show logging start`
`..._run.txt`	`show running-config` at that point in time, that is the verification config of that STEP
`..._trace.txt`	`show mpls ldp trace peer` and `binding`, and `show mpls lsd trace` (four core routers only)
`..._commit.cfg`	Only the configuration actually committed in that STEP, for the routers that were changed

STEP 0: No authentication

Router	clear	ping	show	syslog	running-config	trace
CE1	clear	ping	show	log	run	—
PE1	clear	ping	show	log	run	trace
P1	clear	ping	show	log	run	trace
P2	clear	ping	show	log	run	trace
PE2	clear	ping	show	log	run	trace
CE2	clear	ping	show	log	run	—

STEP 1: neighbor 3.3.3.3:0 password on PE1 only

Router	clear	ping	show	syslog	running-config	trace	config committed
CE1	clear	ping	show	log	run	—	—
PE1	clear	ping	show	log	run	trace	commit
P1	clear	ping	show	log	run	trace	—
P2	clear	ping	show	log	run	trace	—
PE2	clear	ping	show	log	run	trace	—
CE2	clear	ping	show	log	run	—	—

STEP 2: The same password on P1

Router	clear	ping	show	syslog	running-config	trace	config committed
CE1	clear	ping	show	log	run	—	—
PE1	clear	ping	show	log	run	trace	—
P1	clear	ping	show	log	run	trace	commit
P2	clear	ping	show	log	run	trace	—
PE2	clear	ping	show	log	run	trace	—
CE2	clear	ping	show	log	run	—	—

STEP 3: Change only PE1’s password to a different value

Router	clear	ping	show	syslog	running-config	trace	config committed
CE1	clear	ping	show	log	run	—	—
PE1	clear	ping	show	log	run	trace	commit
P1	clear	ping	show	log	run	trace	—
P2	clear	ping	show	log	run	trace	—
PE2	clear	ping	show	log	run	trace	—
CE2	clear	ping	show	log	run	—	—

STEP 4: P1 follows with the new value

Router	clear	ping	show	syslog	running-config	trace	config committed
CE1	clear	ping	show	log	run	—	—
PE1	clear	ping	show	log	run	trace	—
P1	clear	ping	show	log	run	trace	commit
P2	clear	ping	show	log	run	trace	—
PE2	clear	ping	show	log	run	trace	—
CE2	clear	ping	show	log	run	—	—

STEP 5: Replace both with the all-peer neighbor password

Router	clear	ping	show	syslog	running-config	trace	config committed
CE1	clear	ping	show	log	run	—	—
PE1	clear	ping	show	log	run	trace	commit
P1	clear	ping	show	log	run	trace	commit
P2	clear	ping	show	log	run	trace	—
PE2	clear	ping	show	log	run	trace	—
CE2	clear	ping	show	log	run	—	—

STEP 6: neighbor 3.3.3.3:0 password disable on PE1

Router	clear	ping	show	syslog	running-config	trace	config committed
CE1	clear	ping	show	log	run	—	—
PE1	clear	ping	show	log	run	trace	commit
P1	clear	ping	show	log	run	trace	—
P2	clear	ping	show	log	run	trace	—
PE2	clear	ping	show	log	run	trace	—
CE2	clear	ping	show	log	run	—	—

STEP 7: Remove the disable from PE1

Router	clear	ping	show	syslog	running-config	trace	config committed
CE1	clear	ping	show	log	run	—	—
PE1	clear	ping	show	log	run	trace	commit
P1	clear	ping	show	log	run	trace	—
P2	clear	ping	show	log	run	trace	—
PE2	clear	ping	show	log	run	trace	—
CE2	clear	ping	show	log	run	—	—

STEP 8: Remove the password from both (final state)

Router	clear	ping	show	syslog	running-config	trace	config committed
CE1	clear	ping	show	log	run	—	—
PE1	clear	ping	show	log	run	trace	commit
P1	clear	ping	show	log	run	trace	commit
P2	clear	ping	show	log	run	trace	—
PE2	clear	ping	show	log	run	trace	—
CE2	clear	ping	show	log	run	—	—

Packet captures were taken per STEP on two links.

STEP	PE1 - P1	P1 - P2
0	pcap	pcap
1	pcap	pcap
2	pcap	pcap
3	pcap	pcap
4	pcap	pcap
5	pcap	pcap
6	pcap	pcap
7	pcap	pcap
8	pcap	pcap

References

Source	What was referenced
RFC 5036 LDP Specification	Section 2.9.1 (TCP MD5 Signature Option), 2.9.2 (a password per peer, drop without response on failure, ignore Hellos from peers with no password), 5.2 (nothing is encrypted)
RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option	The MD5 signature TCP option (Kind 19); the option is 18 bytes and implementations pad it to 20
IOS XR MPLS Configuration Guide	Syntax of `neighbor password`, `neighbor <LDP-Id> password` and `password disable`

The verification was carried out on XRd 26.1.1 (Cisco Modeling Labs).