idnits 2.17.00 (12 Aug 2021) /tmp/idnits7384/draft-nslag-mpls-deprecate-md5-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3036], [RFC5036]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC5036, but the abstract doesn't seem to directly say this. It does mention RFC5036 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5036, updated by this document, for RFC5378 checks: 2004-10-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2018) is 1549 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 3036 (Obsoleted by RFC 5036) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Andersson 3 Internet-Draft Bronze Dragon Consulting 4 Updates: 5036 (if approved) S. Bryant 5 Intended status: Best Current Practice A. Malis 6 Expires: August 26, 2018 Huawei Technologies 7 N. Leymann 8 Deutshe Telekom 9 G. Swallow 10 Independent 11 February 22, 2018 13 Deprecating MD5 for LDP 14 draft-nslag-mpls-deprecate-md5-00.txt 16 Abstract 18 When the MPLS Label Distribution Protocol (LDP) was specified circa 19 1999, there were very strong requirements that LDP should use a 20 cryptographic hash function to sign LDP protocol messages. MD5 was 21 widely used at that time, and was the obvious choices. 23 However, even when this decision was being taken there were concerns 24 as to whether MD5 was a strong enough signing option. This 25 discussion was briefly reflected in section 5.1 of RFC 5036 [RFC5036] 26 (and also in RFC 3036 [RFC3036]). 28 Over time it has been shown that MD5 can be compromised. Thus, there 29 is a concern shared in the security community and the working groups 30 responsible for the development of the LDP protocol that LDP is no 31 longer adequately secured. 33 This document deprecates MD5 as the signing method for LDP messages. 34 The document also selects a future method to secure LDP messages - 35 the choice is TCP-AO. In addition, we specify that the TBD 36 cryptographic mechanism is to be the default TCP-AO security method. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on August 26, 2018. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 74 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2.1. LDP in RFC 5036 . . . . . . . . . . . . . . . . . . . . . 3 76 2.2. MD5 in BGP . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. Securing LDP . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 83 7.2. Informative References . . . . . . . . . . . . . . . . . 5 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 86 1. Introduction 88 RFC 3036 was published in January 2001 as a Proposed Standard, and it 89 was replaced by RFC 5035, which is a Draft Standard, in October 2007. 90 Two decades after LDP was originally specified there is a concern 91 shared by the security community and the IETF working groups that 92 develop the LDP protocol that LDP is no longer adequately secured. 94 LDP currently uses MD5 to cryptographically sign its messages for 95 security security purposes. However, MD5 is a hash function that is 96 no longer considered adequate to meet current security requirements. 98 1.1. Requirement Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. Background 108 2.1. LDP in RFC 5036 110 In Section 5.1 "Spoofing" of RFC 5036 [RFC5036], in list item 2 111 "Session communication carried by TCP" the following statements are 112 made: 114 LDP specifies use of the TCP MD5 Signature Option to provide for 115 the authenticity and integrity of session messages. 117 RFC 2385 [RFC2385] asserts that MD5 authentication is now 118 considered by some to be too weak for this application. It also 119 points out that a similar TCP option with a stronger hashing 120 algorithm (it cites SHA-1 as an example) could be deployed. To 121 our knowledge, no such TCP option has been defined and deployed. 122 However, we note that LDP can use whatever TCP message digest 123 techniques are available, and when one stronger than MD5 is 124 specified and implemented, upgrading LDP to use it would be 125 relatively straightforward. 127 2.2. MD5 in BGP 129 There has been a similar discussion among working groups developing 130 the BGP protocol. BGP has already replaced MD5 with TCP-AO. This 131 was specified in RFC 7454 [RFC7454]. 133 To secure LDP the same approach will be followed, TCP-AO will be used 134 for LDP also. 136 As far as we are able to ascertain, there is currently no 137 recommended, mandatory to implement, cryptographic function 138 specified. We are concerned that without such a mandatory function, 139 implementations will simply fall back to MD5 and nothing will really 140 be changed. The MPLS working group will need the expertise of the 141 security community to specify a viable security function that is 142 suitable for wide scale deployment on existing network platforms. 144 3. Securing LDP 146 Implementations conforming to this RFC MUST implement TCP-AO to 147 secure the TCP sessions carrying LDP in addition to the currently 148 required TCP MD5 Signature Option. 150 A TBD cryptographic mechanism must be implemented and provided to 151 TCP-AO to secure LDP messages. 153 The TBD mechanism is the preferred option, and MD5 SHOULD only to be 154 used when TBD is unavailable. 156 Note: The authors are not experts on this part of the stack, but it 157 seems that TCP security negotiation is still work in progress. If we 158 are wrong, then we need to include a requirement that such 159 negotiation is also required. In the absence of a negotiation 160 protocol, however, we need to leave this as a configuration process 161 until such time as the negotiation protocol work is complete. On 162 completion of a suitable negotiation protocol we need to issue a 163 further update requiring its use. 165 Cryptographic mechanisms do not have an indefinite lifetime, the IETF 166 hence anticipates updating default cryptographic mechanisms over 167 time. 169 The TBD default security function will need to be chosen such that it 170 can reasonably be implemented on a typical router route processor, 171 and which will provide adequate security without significantly 172 degrading the convergence time of a Label Switching Router (LSR). 174 Without a function that does not significantly impact router 175 convergence we simply close one vulnerability and open another. 177 Note: As experts on the LDP protocol, but not on security mechanisms, 178 we need to ask the security area for a review of our proposed 179 approach, and help correcting any misunderstanding of the security 180 issues or our misunderstanding of the existing security mechanisms. 181 We also need a recommendation on a suitable security function (TBD in 182 the above text). 184 4. Security Considerations 186 This document is entirely about LDP operational security. It 187 describes best practices that one should adopt to secure LDP messages 188 and the TCP based LDP sessions between LSRs. 190 This document does not aim to describe existing LDP implementations, 191 their potential vulnerabilities, or ways they handle errors. It does 192 not detail how protection could be enforced against attack techniques 193 using crafted packets. 195 5. IANA Considerations 197 There are no requests for IANA actions in this document. 199 Note to the RFC Editor - this section can be removed before 200 publication. 202 6. Acknowledgements 204 - 206 - 208 7. References 210 7.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, 214 DOI 10.17487/RFC2119, March 1997, 215 . 217 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 218 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 219 1998, . 221 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 222 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 223 October 2007, . 225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 227 May 2017, . 229 7.2. Informative References 231 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 232 B. Thomas, "LDP Specification", RFC 3036, 233 DOI 10.17487/RFC3036, January 2001, 234 . 236 [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations 237 and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, 238 February 2015, . 240 Authors' Addresses 242 Loa Andersson 243 Bronze Dragon Consulting 245 Email: loa@pi.nu 247 Stewart Bryant 248 Huawei Technologies 250 Email: stewart.bryant@gmail.com 252 Andrew G. Malis 253 Huawei Technologies 255 Email: stewart.bryant@gmail.com 257 Nicolai Leymanm 258 Deutshe Telekom 260 Email: N.Leymann@telekom.de 262 George Swallow 263 Independent 265 Email: swallow.ietf@gmail.com