[mpls] LDP Security

[Stewart Bryant <[e-mail]>]

To the SEC and RTG ADs,

I am sending the following message on behalf of the MPLS and the
PALS WG Chairs.

There is a concern shared among the security community and the working 
groups that develop the LDP protocol that LDP is no longer adequately 
secured. LDP currently relies on MD5 for cryptographic security of its 
messages, but MD5 is a hash function that is no longer considered to 
meet current security requirements.

In RFC5036 (published 2007) Section 5.1 (Spoofing) , List element 2. 
Session communication carried by TCP the following statements is made:

"LDP specifies use of the TCP MD5 Signature Option to provide for the 
authenticity and integrity of session messages.

"[RFC2385] asserts that MD5 authentication is now considered by some to 
be too weak for this application.  It also points out that a similar TCP 
option with a stronger hashing algorithm (it cites SHA-1 as an example) 
could be deployed.  To our knowledge, no such TCP option has been 
defined and deployed.  However, we note that LDP can use whatever TCP 
message digest techniques are available, and when one stronger than MD5 
is specified and implemented, upgrading LDP to use it would be 
relatively straightforward."

We note that BGP has already been through this process, and replaced MD5 
with TCP-AO in RFC 7454. I would be logical to follow the same approach 
to secure LDP. However, as far as we are able to ascertain, there is 
currently no recommended, mandatory to implement, cryptographic function 
specified. We are concerned that without such a mandatory function, 
implementations will simply fall back to MD5 and we will be no further 
forward

We think that the best way forward is to publish a draft similar to RFC 
7454 that contains the following requirement:

"Implementations conforming to this RFC MUST implement TCP-AO to secure 
the TCP sessions carrying LDP in addition to the currently required TCP 
MD5 Signature Option. Furthermore, the TBD cryptographic mechanism must 
be implemented and provided to TCP-AO to secure LDP messages. The TBD 
mechanism is the preferred option, and MD5 is only to be used when TBD 
is unavailable."

We are not an experts on this part of the stack, but it seems that TCP 
security negotiation is still work in progress. If we are wrong, then we 
need to include a requirement that such negotiation is also required. In 
the absence of a negotiation protocol, however, we need to leave this as 
a configuration process until such time as the negotiation protocol work 
is complete. On completion of a suitable negotiation protocol we need to 
issue a further update requiring its use.

Additionally we should note that no cryptographic mechanism has an 
indefinite lifetime, and that implementation should note the IETF 
anticipates updating the default cryptographic mechanism over time.

The TBD default security function will need to be chosen such that it 
can reasonably be implemented on a typical router route processor, and 
which will provide adequate security without significantly degrading the 
convergence time of an LSR. Without a function that does not 
significantly impact router convergence we simply close one 
vulnerability and open another.

As experts on the LDP protocol, but not on security mechanisms, we  need 
to ask the security area for a review of our proposed approach, and help 
correcting any misunderstanding of the security issues or our 
misunderstanding of the existing security mechanisms. We also need the 
recommendations of a suitable security function (TBD in the above text).

Best regards

The MPLS WG Chairs
The PALS WG Chairs