Skip to main content

Deprecating MD5 for LDP
draft-nslag-mpls-deprecate-md5-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Loa Andersson , Stewart Bryant , Nicolai Leymann , George Swallow
Last updated 2018-03-01
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-nslag-mpls-deprecate-md5-01
MPLS Working Group                                          L. Andersson
Internet-Draft                                  Bronze Dragon Consulting
Intended status: Informational                                 S. Bryant
Expires: September 2, 2018                                      A. Malis
                                                     Huawei Technologies
                                                              N. Leymann
                                                         Deutshe Telekom
                                                              G. Swallow
                                                             Independent
                                                           March 1, 2018

                        Deprecating MD5 for LDP
                 draft-nslag-mpls-deprecate-md5-01.txt

Abstract

   When the MPLS Label Distribution Protocol (LDP) was specified circa
   1999, there were very strong requirements that LDP should use a
   cryptographic hash function to sign LDP protocol messages.  MD5 was
   widely used at that time, and was the obvious choices.

   However, even when this decision was being taken there were concerns
   as to whether MD5 was a strong enough signing option.  This
   discussion was briefly reflected in section 5.1 of RFC 5036 [RFC5036]
   (and also in RFC 3036 [RFC3036]).

   Over time it has been shown that MD5 can be compromised.  Thus, there
   is a concern shared in the security community and the working groups
   responsible for the development of the LDP protocol that LDP is no
   longer adequately secured.

   This document deprecates MD5 as the signing method for LDP messages.
   The document also selects a future method to secure LDP messages -
   the choice is TCP-AO.  In addition, we specify that the TBD
   cryptographic mechanism is to be the default TCP-AO security method.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

Andersson, et al.       Expires September 2, 2018               [Page 1]
Internet-Draft           Deprecating MD5 for LDP              March 2018

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 2, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirement Language  . . . . . . . . . . . . . . . . . .   3
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  LDP in RFC 5036 . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  MD5 in BGP  . . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Prior Art . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Securing LDP  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   RFC 3036 was published in January 2001 as a Proposed Standard, and it
   was replaced by RFC 5035, which is a Draft Standard, in October 2007.
   Two decades after LDP was originally specified there is a concern
   shared by the security community and the IETF working groups that
   develop the LDP protocol that LDP is no longer adequately secured.

Andersson, et al.       Expires September 2, 2018               [Page 2]
Internet-Draft           Deprecating MD5 for LDP              March 2018

   LDP currently uses MD5 to cryptographically sign its messages for
   security security purposes.  However, MD5 is a hash function that is
   no longer considered adequate to meet current security requirements.

1.1.  Requirement Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Background

2.1.  LDP in RFC 5036

   In Section 5.1 "Spoofing" of RFC 5036 [RFC5036], in list item 2
   "Session communication carried by TCP" the following statements are
   made:

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

      RFC 2385 [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.

2.2.  MD5 in BGP

   There has been a similar discussion among working groups developing
   the BGP protocol.  BGP has already replaced MD5 with TCP-AO.  This
   was specified in RFC 7454 [RFC7454].

   To secure LDP the same approach will be followed, TCP-AO will be used
   for LDP also.

   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 nothing will really
   be changed.  The MPLS working group will need the expertise of the

Andersson, et al.       Expires September 2, 2018               [Page 3]
Internet-Draft           Deprecating MD5 for LDP              March 2018

   security community to specify a viable security function that is
   suitable for wide scale deployment on existing network platforms.

2.3.  Prior Art

   RFC 6952 [RFC6952] dicusses a set of routing protocols that all are
   using TCP for transport of protocol messages, according to guidelines
   set forth in Section 4.2 of "Keying and Authentication for Routing
   Protocols Design Guidelines", RFC 6518 [RFC6518].

   RFC 6952 takes a much broader approach than this document, it
   discusses several protcols and also securing the LDP session
   initialization.  This document has a narrower scope, securing LDP
   session messages only.  LDP in initialization mode is addressed in
   RFC 7349 [RFC7349].

   RFC 6952 and this document, basically suggest the same thing, move to
   TCP-AO and deploy a strong cryotoigraphic algorithm.

   All the protcols discuseed in RFC 6952 should adopt the approach to
   securing protocol messages over TCP.

3.  Securing LDP

   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.

   A TBD cryptographic mechanism must be implemented and provided to
   TCP-AO to secure LDP messages.

   The TBD mechanism is the preferred option, and MD5 SHOULD only to be
   used when TBD is unavailable.

   Note: The authors are not 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.

   Cryptographic mechanisms do not have an indefinite lifetime, the IETF
   hence anticipates updating default cryptographic mechanisms over
   time.

Andersson, et al.       Expires September 2, 2018               [Page 4]
Internet-Draft           Deprecating MD5 for LDP              March 2018

   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 a Label Switching Router (LSR).

   Without a function that does not significantly impact router
   convergence we simply close one vulnerability and open another.

   Note: 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 a recommendation on a suitable security function (TBD in
   the above text).

4.  Security Considerations

   This document is entirely about LDP operational security.  It
   describes best practices that one should adopt to secure LDP messages
   and the TCP based LDP sessions between LSRs.

   This document does not aim to describe existing LDP implementations,
   their potential vulnerabilities, or ways they handle errors.  It does
   not detail how protection could be enforced against attack techniques
   using crafted packets.

5.  IANA Considerations

   There are no requests for IANA actions in this document.

   Note to the RFC Editor - this section can be removed before
   publication.

6.  Acknowledgements

   -

   -

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Andersson, et al.       Expires September 2, 2018               [Page 5]
Internet-Draft           Deprecating MD5 for LDP              March 2018

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
              1998, <https://www.rfc-editor.org/info/rfc2385>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <https://www.rfc-editor.org/info/rfc5036>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
              B. Thomas, "LDP Specification", RFC 3036,
              DOI 10.17487/RFC3036, January 2001,
              <https://www.rfc-editor.org/info/rfc3036>.

   [RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines", RFC 6518,
              DOI 10.17487/RFC6518, February 2012,
              <https://www.rfc-editor.org/info/rfc6518>.

   [RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
              BGP, LDP, PCEP, and MSDP Issues According to the Keying
              and Authentication for Routing Protocols (KARP) Design
              Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
              <https://www.rfc-editor.org/info/rfc6952>.

   [RFC7349]  Zheng, L., Chen, M., and M. Bhatia, "LDP Hello
              Cryptographic Authentication", RFC 7349,
              DOI 10.17487/RFC7349, August 2014,
              <https://www.rfc-editor.org/info/rfc7349>.

   [RFC7454]  Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
              and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
              February 2015, <https://www.rfc-editor.org/info/rfc7454>.

Authors' Addresses

   Loa Andersson
   Bronze Dragon Consulting

   Email: loa@pi.nu

Andersson, et al.       Expires September 2, 2018               [Page 6]
Internet-Draft           Deprecating MD5 for LDP              March 2018

   Stewart Bryant
   Huawei Technologies

   Email: stewart.bryant@gmail.com

   Andrew G. Malis
   Huawei Technologies

   Email: stewart.bryant@gmail.com

   Nicolai Leymanm
   Deutshe Telekom

   Email: N.Leymann@telekom.de

   George Swallow
   Independent

   Email: swallow.ietf@gmail.com

Andersson, et al.       Expires September 2, 2018               [Page 7]