draft-ietf-mpls-ldp-hello-crypto-auth-03.txt		draft-ietf-mpls-ldp-hello-crypto-auth-04.txt
	Network Working Group L. Zheng		Network Working Group L. Zheng
	Internet-Draft M. Chen		Internet-Draft M. Chen
	Intended status: Standards Track Huawei Technologies		Intended status: Standards Track Huawei Technologies
	Expires: September 20, 2014 M. Bhatia		Expires: September 30, 2014 M. Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	March 19, 2014		March 29, 2014
	LDP Hello Cryptographic Authentication		LDP Hello Cryptographic Authentication
	draft-ietf-mpls-ldp-hello-crypto-auth-03.txt		draft-ietf-mpls-ldp-hello-crypto-auth-04.txt
	Abstract		Abstract
	This document introduces a new optional Cryptographic Authentication		This document introduces a new optional Cryptographic Authentication
	TLV that LDP can use to secure its Hello messages. It secures the		TLV that LDP can use to secure its Hello messages. It secures the
	Hello messages against spoofing attacks and some well known attacks		Hello messages against spoofing attacks and some well known attacks
	against the IP header. This document describes a mechanism to secure		against the IP header. This document describes a mechanism to secure
	the LDP Hello messages using National Institute of Standards and		the LDP Hello messages using National Institute of Standards and
	Technology (NIST) Secure Hash Standard family of algorithms.		Technology (NIST) Secure Hash Standard family of algorithms.
	skipping to change at page 2, line 26		skipping to change at page 2, line 26
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 September 20, 2014.		This Internet-Draft will expire on September 30, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 3, line 38		skipping to change at page 3, line 38
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 19		10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	10.2. Informative References . . . . . . . . . . . . . . . . . . 19		10.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions		The Label Distribution Protocol (LDP) [RFC5036] sets up LDP sessions
	that run between LDP peers. The peers could either be directly		that run between LDP peers. The peers could either be directly
	connected at the link level or could be multiple hops away. An LDP		connected at the link level or could be multiple hops away. An LDP
	Label Switching Router (LSR) could either be configured with the		Label Switching Router (LSR) could either be configured with the
	identity of its peers or could discover them using LDP Hello		identity of its peers or could discover them using LDP Hello
	messages. These messages are sent encapsulated in UDP addressed to		messages. These messages are sent encapsulated in UDP addressed to
	"all routers on this subnet" or to a specific IP address. Periodic		"all routers on this subnet" or to a specific IP address. Periodic
	skipping to change at page 4, line 33		skipping to change at page 4, line 33
	Spoofing a Hello packet for an existing adjacency can cause the valid		Spoofing a Hello packet for an existing adjacency can cause the valid
	adjacency to time out and in turn can result in termination of the		adjacency to time out and in turn can result in termination of the
	associated session. This can occur when the spoofed Hello specifies		associated session. This can occur when the spoofed Hello specifies
	a smaller Hold Time, causing the receiver to expect Hellos within		a smaller Hold Time, causing the receiver to expect Hellos within
	this smaller interval, while the true neighbor continues sending		this smaller interval, while the true neighbor continues sending
	Hellos at the previously agreed lower frequency. Spoofing a Hello		Hellos at the previously agreed lower frequency. Spoofing a Hello
	packet can also cause the LDP session to be terminated directly,		packet can also cause the LDP session to be terminated directly,
	which can occur when the spoofed Hello specifies a different		which can occur when the spoofed Hello specifies a different
	Transport Address, other than the previously agreed one between		Transport Address, other than the previously agreed one between
	neighbors. Spoofed Hello messages have been observed and reported as		neighbors. Spoofed Hello messages have been observed and reported as
	a real problem in production networks		a real problem in production networks [RFC6952].
	[I-D.ietf-karp-routing-tcp-analysis].
	[RFC5036] states that the threat of spoofed Hellos can be reduced by		[RFC5036] states that the threat of spoofed Hellos can be reduced by
	accepting Hellos only on interfaces to which LSRs that can be trusted		accepting Hellos only on interfaces to which LSRs that can be trusted
	are directly connected, and ignoring Hellos not addressed to the "all		are directly connected, and ignoring Hellos not addressed to the "all
	routers on this subnet" multicast group. Spoofing attacks via		routers on this subnet" multicast group. Spoofing attacks via
	Targeted Hellos are a potentially more serious threat. An LSR can		Targeted Hellos are a potentially more serious threat. An LSR can
	reduce the threat of spoofed Targeted Hellos by filtering them and		reduce the threat of spoofed Targeted Hellos by filtering them and
	accepting only those originating at sources permitted by an access		accepting only those originating at sources permitted by an access
	list. However, filtering using access lists requires LSR resource,		list. However, filtering using access lists requires LSR resource,
	and does not prevent IP-address spoofing.		and does not prevent IP-address spoofing.
	skipping to change at page 12, line 51		skipping to change at page 12, line 51
	(L-16)/4 times. This implies that hash output is always a length of		(L-16)/4 times. This implies that hash output is always a length of
	at least 16 octets.		at least 16 octets.
	5.1. Preparing the Cryptographic Key		5.1. Preparing the Cryptographic Key
	The LDP Cryptographic Protocol ID is appended to the Authentication		The LDP Cryptographic Protocol ID is appended to the Authentication
	Key (K) yielding a Protocol Specific Authentication Key (Ks). In		Key (K) yielding a Protocol Specific Authentication Key (Ks). In
	this application, Ko is always L octets long. While [RFC2104]		this application, Ko is always L octets long. While [RFC2104]
	supports a key that is up to B octets long, this application uses L		supports a key that is up to B octets long, this application uses L
	as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and		as the Ks length consistent with [RFC4822], [RFC5310], [RFC5709] and
	[RFC6506] [RFC7166]. According to [FIPS-180-3], Section 3, keys		[RFC7166]. According to [FIPS-180-3], Section 3, keys greater than L
	greater than L octets do not significantly increase the function		octets do not significantly increase the function strength. Ks is
	strength. Ks is computed as follows:		computed as follows:
	If the Protocol Specific Authentication Key (Ks) is L octets long,		If the Protocol Specific Authentication Key (Ks) is L octets long,
	then Ko is equal to Ks. If the Protocol Specific Authentication Key		then Ko is equal to Ks. If the Protocol Specific Authentication Key
	(Ks) is more than L octets long, then Ko is set to H(Ks). If the		(Ks) is more than L octets long, then Ko is set to H(Ks). If the
	Protocol Specific Authentication Key (Ks) is less than L octets long,		Protocol Specific Authentication Key (Ks) is less than L octets long,
	then Ko is set to the Protocol Specific Authentication Key (Ks) with		then Ko is set to the Protocol Specific Authentication Key (Ks) with
	zeros appended to the end of the Protocol Specific Authentication Key		zeros appended to the end of the Protocol Specific Authentication Key
	(Ks) such that Ko is L octets long.		(Ks) such that Ko is L octets long.
	5.2. Computing the Hash		5.2. Computing the Hash
	skipping to change at page 19, line 17		skipping to change at page 19, line 17
	10.1. Normative References		10.1. Normative References
	[FIPS-180-3]		[FIPS-180-3]
	"Secure Hash Standard (SHS), FIPS PUB 180-3",		"Secure Hash Standard (SHS), FIPS PUB 180-3",
	October 2008.		October 2008.
	[FIPS-198]		[FIPS-198]
	"The Keyed-Hash Message Authentication Code (HMAC), FIPS		"The Keyed-Hash Message Authentication Code (HMAC), FIPS
	PUB 198", March 2002.		PUB 198", March 2002.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,
	February 1997.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic		[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
	Authentication", RFC 4822, February 2007.		Authentication", RFC 4822, February 2007.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
	[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,		[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
	and M. Fanto, "IS-IS Generic Cryptographic		and M. Fanto, "IS-IS Generic Cryptographic
	Authentication", RFC 5310, February 2009.		Authentication", RFC 5310, February 2009.
	[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,		[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
	Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic		Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
	Authentication", RFC 5709, October 2009.		Authentication", RFC 5709, October 2009.
	[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
	Authentication Trailer for OSPFv3", RFC 6506,
	February 2012.
	[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting		[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
	Authentication Trailer for OSPFv3", RFC 7166, March 2014.		Authentication Trailer for OSPFv3", RFC 7166, March 2014.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-karp-routing-tcp-analysis]		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		Hashing for Message Authentication", RFC 2104,
	BGP, LDP, PCEP and MSDP Issues According to KARP Design		February 1997.
	Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
	progress), April 2013.
	[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms		[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
	for the TCP Authentication Option (TCP-AO)", RFC 5926,		for the TCP Authentication Option (TCP-AO)", RFC 5926,
	June 2010.		June 2010.
			[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, May 2013.
	Authors' Addresses		Authors' Addresses
	Lianshu Zheng		Lianshu Zheng
	Huawei Technologies		Huawei Technologies
	China		China
	Email: vero.zheng@huawei.com		Email: vero.zheng@huawei.com
	Mach(Guoyi) Chen		Mach(Guoyi) Chen
	Huawei Technologies		Huawei Technologies
End of changes. 11 change blocks.
	23 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/