< draft-nslag-mpls-deprecate-md5-00.txt		draft-nslag-mpls-deprecate-md5-01.txt >
	MPLS Working Group L. Andersson		MPLS Working Group L. Andersson
	Internet-Draft Bronze Dragon Consulting		Internet-Draft Bronze Dragon Consulting
	Updates: 5036 (if approved) S. Bryant		Intended status: Informational S. Bryant
	Intended status: Best Current Practice A. Malis		Expires: September 2, 2018 A. Malis
	Expires: August 26, 2018 Huawei Technologies		Huawei Technologies
	N. Leymann		N. Leymann
	Deutshe Telekom		Deutshe Telekom
	G. Swallow		G. Swallow
	Independent		Independent
	February 22, 2018		March 1, 2018
	Deprecating MD5 for LDP		Deprecating MD5 for LDP
	draft-nslag-mpls-deprecate-md5-00.txt		draft-nslag-mpls-deprecate-md5-01.txt
	Abstract		Abstract
	When the MPLS Label Distribution Protocol (LDP) was specified circa		When the MPLS Label Distribution Protocol (LDP) was specified circa
	1999, there were very strong requirements that LDP should use a		1999, there were very strong requirements that LDP should use a
	cryptographic hash function to sign LDP protocol messages. MD5 was		cryptographic hash function to sign LDP protocol messages. MD5 was
	widely used at that time, and was the obvious choices.		widely used at that time, and was the obvious choices.
	However, even when this decision was being taken there were concerns		However, even when this decision was being taken there were concerns
	as to whether MD5 was a strong enough signing option. This		as to whether MD5 was a strong enough signing option. This
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 26, 2018.		This Internet-Draft will expire on September 2, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. LDP in RFC 5036 . . . . . . . . . . . . . . . . . . . . . 3		2.1. LDP in RFC 5036 . . . . . . . . . . . . . . . . . . . . . 3
	2.2. MD5 in BGP . . . . . . . . . . . . . . . . . . . . . . . 3		2.2. MD5 in BGP . . . . . . . . . . . . . . . . . . . . . . . 3
			2.3. Prior Art . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Securing LDP . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Securing LDP . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 4		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Normative References . . . . . . . . . . . . . . . . . . 5		7.1. Normative References . . . . . . . . . . . . . . . . . . 5
	7.2. Informative References . . . . . . . . . . . . . . . . . 5		7.2. Informative References . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	RFC 3036 was published in January 2001 as a Proposed Standard, and it		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.		was replaced by RFC 5035, which is a Draft Standard, in October 2007.
	Two decades after LDP was originally specified there is a concern		Two decades after LDP was originally specified there is a concern
	shared by the security community and the IETF working groups that		shared by the security community and the IETF working groups that
	develop the LDP protocol that LDP is no longer adequately secured.		develop the LDP protocol that LDP is no longer adequately secured.
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	for LDP also.		for LDP also.
	As far as we are able to ascertain, there is currently no		As far as we are able to ascertain, there is currently no
	recommended, mandatory to implement, cryptographic function		recommended, mandatory to implement, cryptographic function
	specified. We are concerned that without such a mandatory function,		specified. We are concerned that without such a mandatory function,
	implementations will simply fall back to MD5 and nothing will really		implementations will simply fall back to MD5 and nothing will really
	be changed. The MPLS working group will need the expertise of the		be changed. The MPLS working group will need the expertise of the
	security community to specify a viable security function that is		security community to specify a viable security function that is
	suitable for wide scale deployment on existing network platforms.		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		3. Securing LDP
	Implementations conforming to this RFC MUST implement TCP-AO to		Implementations conforming to this RFC MUST implement TCP-AO to
	secure the TCP sessions carrying LDP in addition to the currently		secure the TCP sessions carrying LDP in addition to the currently
	required TCP MD5 Signature Option.		required TCP MD5 Signature Option.
	A TBD cryptographic mechanism must be implemented and provided to		A TBD cryptographic mechanism must be implemented and provided to
	TCP-AO to secure LDP messages.		TCP-AO to secure LDP messages.
	The TBD mechanism is the preferred option, and MD5 SHOULD only to be		The TBD mechanism is the preferred option, and MD5 SHOULD only to be
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 24 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
	[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and		[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
	B. Thomas, "LDP Specification", RFC 3036,		B. Thomas, "LDP Specification", RFC 3036,
	DOI 10.17487/RFC3036, January 2001,		DOI 10.17487/RFC3036, January 2001,
	<https://www.rfc-editor.org/info/rfc3036>.		<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		[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations
	and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,		and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454,
	February 2015, <https://www.rfc-editor.org/info/rfc7454>.		February 2015, <https://www.rfc-editor.org/info/rfc7454>.
	Authors' Addresses		Authors' Addresses
	Loa Andersson		Loa Andersson
	Bronze Dragon Consulting		Bronze Dragon Consulting
	Email: loa@pi.nu		Email: loa@pi.nu
End of changes. 9 change blocks.
	8 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/