draft-ietf-mpls-ldp-hello-crypto-auth-08.txt		draft-ietf-mpls-ldp-hello-crypto-auth-09.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: December 4, 2014 M. Bhatia		Expires: December 20, 2014 M. Bhatia
	Alcatel-Lucent		Ionos Networks
	June 2, 2014		June 18, 2014
	LDP Hello Cryptographic Authentication		LDP Hello Cryptographic Authentication
	draft-ietf-mpls-ldp-hello-crypto-auth-08.txt		draft-ietf-mpls-ldp-hello-crypto-auth-09.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 Hashed Message Authentication Code
	Technology (NIST) Secure Hash Standard family of algorithms.		(HMAC) with National Institute of Standards and Technology (NIST)
			Secure Hash Standard family of algorithms.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 43		skipping to change at page 1, line 44
	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 December 4, 2014.		This Internet-Draft will expire on December 20, 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 2, line 24		skipping to change at page 2, line 29
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4		2. Cryptographic Authentication TLV . . . . . . . . . . . . . . 4
	2.1. Optional Parameter for Hello Message . . . . . . . . . . 4		2.1. Optional Parameter for Hello Message . . . . . . . . . . 4
	2.2. LDP Security Association . . . . . . . . . . . . . . . . 4		2.2. LDP Security Association . . . . . . . . . . . . . . . . 4
	2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6		2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 6
	2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 8		2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . 8
	3. Cryptographic Authentication Procedure . . . . . . . . . . . 8		3. Cryptographic Authentication Procedure . . . . . . . . . . . 8
	4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . 8		4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . 9
	5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 8		5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 9
	5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9		5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 9
	5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 9		5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . 10
	5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10		5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Processing Hello Message Using Cryptographic Authentication . 10		6. Processing Hello Message Using Cryptographic Authentication . 10
	6.1. Transmission Using Cryptographic Authentication . . . . . 10		6.1. Transmission Using Cryptographic Authentication . . . . . 10
	6.2. Receipt Using Cryptographic Authentication . . . . . . . 10		6.2. Receipt Using Cryptographic Authentication . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Operational Considerations . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 13		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		11.2. Informative References . . . . . . . . . . . . . . . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	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
	Hello messages are also used to maintain the relationship between LDP		Hello messages are also used to maintain the relationship between LDP
	peers necessary to keep the LDP session active.		peers necessary to keep the LDP session active.
	Since the Hello messages are sent using UDP and not TCP, these		Since the Hello messages are sent using UDP and not TCP, these
	messages cannot use the security mechanisms defined for TCP		messages cannot use the security mechanisms defined for TCP
	[RFC5926]. While some configuration guidance is given in [RFC5036]		[RFC5926]. While some configuration guidance is given in [RFC5036]
	to help protect against false discovery messages, it does not provide		to help protect against false discovery messages, it does not provide
	an explicit security mechanism to protect the Hello messages.		an explicit security mechanism to protect the Hello messages.
	Spoofing a Hello packet for an existing adjacency can cause the valid		Spoofing a Hello message for an existing adjacency can cause the
	adjacency to time out and in turn can result in termination of the		valid adjacency to time out and in turn can result in termination of
	associated session. This can occur when the spoofed Hello specifies		the associated session. This can occur when the spoofed Hello
	a smaller Hold Time, causing the receiver to expect Hellos within		specifies a smaller Hold Time, causing the receiver to expect Hellos
	this smaller interval, while the true neighbor continues sending		within this smaller interval, while the true neighbor continues
	Hellos at the previously agreed lower frequency. Spoofing a Hello		sending Hellos at the previously agreed lower frequency. Spoofing a
	packet can also cause the LDP session to be terminated directly,		Hello message can also cause the LDP session to be terminated
	which can occur when the spoofed Hello specifies a different		directly, which can occur when the spoofed Hello specifies a
	Transport Address, other than the previously agreed one between		different Transport Address, other than the previously agreed one
	neighbors. Spoofed Hello messages have been observed and reported as		between neighbors. Spoofed Hello messages have been observed and
	a real problem in production networks [RFC6952].		reported as a real problem in production networks [RFC6952].
	For Link Hello, [RFC5036] states that the threat of spoofed Hellos		For Link Hello, [RFC5036] states that the threat of spoofed Hellos
	can be reduced by accepting Hellos only on interfaces to which LSRs		can be reduced by accepting Hellos only on interfaces to which LSRs
	that can be trusted are directly connected, and ignoring Hellos not		that can be trusted are directly connected, and ignoring Hellos not
	addressed to the "all routers on this subnet" multicast group. The		addressed to the "all routers on this subnet" multicast group. The
	Generalized TTL Security Mechanism (GTSM) provides a simple and		Generalized TTL Security Mechanism (GTSM) provides a simple and
	reasonably robust defense mechanism for Link Hello [RFC6720], but it		reasonably robust defense mechanism for Link Hello [RFC6720], but it
	does not secure against packet spoofing attack or replay		does not secure against packet spoofing attack or replay
	attack[RFC5082].		attack[RFC5082].
	skipping to change at page 3, line 44		skipping to change at page 3, line 48
	spoofed Targeted Hellos by filtering them and accepting only those		spoofed Targeted Hellos by filtering them and accepting only those
	originating at sources permitted by an access list. However,		originating at sources permitted by an access list. However,
	filtering using access lists requires LSR resource, and does not		filtering using access lists requires LSR resource, and does not
	prevent IP-address spoofing.		prevent IP-address spoofing.
	This document introduces a new Cryptographic Authentication TLV which		This document introduces a new Cryptographic Authentication TLV which
	is used in LDP Hello messages as an optional parameter. It enhances		is used in LDP Hello messages as an optional parameter. It enhances
	the authentication mechanism for LDP by securing the Hello message		the authentication mechanism for LDP by securing the Hello message
	against spoofing attack. It also introduces a cryptographic sequence		against spoofing attack. It also introduces a cryptographic sequence
	number carried in the Hello messages that can be used to protect		number carried in the Hello messages that can be used to protect
	against replay attacks. The LSRs could be configured to only accept		against replay attacks.
	Hello messages from specific peers when authentication is in use.
	Using this Cryptographic Authentication TLV, one or more secret keys		Using this Cryptographic Authentication TLV, one or more secret keys
	(with corresponding Security Association (SA) IDs) are configured in		(with corresponding Security Association (SA) IDs) are configured in
	each system. For each LDP Hello message, the key is used to generate		each system. For each LDP Hello message, the key is used to generate
	and verify a HMAC Hash that is stored in the LDP Hello message. For		and verify a HMAC Hash that is stored in the LDP Hello message. For
	cryptographic hash function, this document proposes to use SHA-1,		cryptographic hash function, this document proposes to use SHA-1,
	SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard		SHA-256, SHA-384, and SHA-512 defined in US NIST Secure Hash Standard
	(SHS) [FIPS-180-3]. The HMAC authentication mode defined in		(SHS) [FIPS-180-3]. The HMAC authentication mode defined in
	[RFC2104] is used. Of the above, implementations MUST include		[RFC2104] is used. Of the above, implementations MUST include
	support for at least HMAC-SHA-256 and SHOULD include support for		support for at least HMAC-SHA-256 and SHOULD include support for
	HMAC-SHA-1 and MAY include support for either of HMAC-SHA-384 or		HMAC-SHA-1 and MAY include support for HMAC-SHA-384 and HMAC-SHA-512.
	HMAC-SHA-512.
	2. Cryptographic Authentication TLV		2. Cryptographic Authentication TLV
	2.1. Optional Parameter for Hello Message		2.1. Optional Parameter for Hello Message
	[RFC5036] defines the encoding for the Hello message. Each Hello		[RFC5036] defines the encoding for the Hello message. Each Hello
	message contains zero or more Optional Parameters, each encoded as a		message contains zero or more Optional Parameters, each encoded as a
	TLV. Three Optional Parameters are defined by [RFC5036]. This		TLV. Three Optional Parameters are defined by [RFC5036]. This
	document defines a new Optional Parameter: the Cryptographic		document defines a new Optional Parameter: the Cryptographic
	Authentication parameter.		Authentication parameter.
	skipping to change at page 4, line 41		skipping to change at page 4, line 44
	An LDP Security Association (SA) contains a set of parameters shared		An LDP Security Association (SA) contains a set of parameters shared
	between any two legitimate LDP speakers.		between any two legitimate LDP speakers.
	Parameters associated with an LDP SA are as follows:		Parameters associated with an LDP SA are as follows:
	o Security Association Identifier (SA ID)		o Security Association Identifier (SA ID)
	This is a 32-bit unsigned integer used to uniquely identify an LDP		This is a 32-bit unsigned integer used to uniquely identify an LDP
	SA between two LDP peers, as manually configured by the network		SA between two LDP peers, as manually configured by the network
	operator (or, in the future, possibly by some key management		operator (or, possibly by some key management protocol specified
	protocol specified by the IETF) .		by the IETF in the future) .
	The receiver determines the active SA by looking at the SA ID		The receiver determines the active SA by looking at the SA ID
	field in the incoming Hello message.		field in the incoming Hello message.
	The sender, based on the active configuration, selects an SA to		The sender, based on the active configuration, selects an SA to
	use and puts the correct SA ID value associated with the SA in the		use and puts the correct SA ID value associated with the SA in the
	LDP Hello message. If multiple valid and active LDP SAs exist for		LDP Hello message. If multiple valid and active LDP SAs exist for
	a given interface, the sender may use any of those SAs to protect		a given interface, the sender may use any of those SAs to protect
	the packet.		the packet.
	skipping to change at page 6, line 30		skipping to change at page 6, line 33
	the KeyStopGenerate time of the old key. Any unspecified values are		the KeyStopGenerate time of the old key. Any unspecified values are
	encoded as Zero.		encoded as Zero.
	Key storage SHOULD persist across a system restart, warm or cold, to		Key storage SHOULD persist across a system restart, warm or cold, to
	avoid operational issues. In the event that the last key associated		avoid operational issues. In the event that the last key associated
	with an interface expires, it is unacceptable to revert to an		with an interface expires, it is unacceptable to revert to an
	unauthenticated condition, and not advisable to disrupt routing.		unauthenticated condition, and not advisable to disrupt routing.
	Therefore, the router SHOULD send a "last Authentication Key		Therefore, the router SHOULD send a "last Authentication Key
	expiration" notification to the network manager and treat the key as		expiration" notification to the network manager and treat the key as
	having an infinite lifetime until the lifetime is extended, the key		having an infinite lifetime until the lifetime is extended, the key
	is deleted by network management, or a new key is configured		is deleted by network management, or a new key is configured.
	2.3. Cryptographic Authentication TLV Encoding		2.3. Cryptographic Authentication TLV Encoding
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Auth (TBD1) | Length |		|0|0| Auth (TBD1) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Security Association ID |		| Security Association ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cryptographic Sequence Number (High Order 32 Bits) |		| Cryptographic Sequence Number (High Order 32 Bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cryptographic Sequence Number (Low Order 32 Bits) |		| Cryptographic Sequence Number (Low Order 32 Bits) |
	skipping to change at page 7, line 7		skipping to change at page 7, line 24
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Authentication Data (Variable) |		| Authentication Data (Variable) |
	~ ~		~ ~
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	- Type: TBD1, Cryptographic Authentication		- Type: TBD1, Cryptographic Authentication
	- Length: Specifying the length in octets of the value field.		- Length: Specifying the length in octets of the value field,
			including the Security Association ID and Cryptographic Sequence
			Number fields.
	- Security Association ID: 32 bit field that maps to the		- Security Association ID: 32 bit field that maps to the
	authentication algorithm and the secret key used to create the		authentication algorithm and the secret key used to create the
	message digest carried in LDP payload.		message digest carried in LDP payload.
	Though the SA ID implies the algorithm, the HMAC output size should		Though the SA ID implies the algorithm, the HMAC output size should
	not be used by implementers as an implicit hint, because additional		not be used by implementers as an implicit hint, because additional
	algorithms may be defined in the future that have the same output		algorithms may be defined in the future that have the same output
	size.		size.
	- Cryptographic Sequence Number: 64-bit strictly increasing sequence		- Cryptographic Sequence Number: 64-bit strictly increasing sequence
	number that is used to guard against replay attacks. The 64-bit		number that is used to guard against replay attacks. The 64-bit
	sequence number MUST be incremented for every LDP Hello packet sent		sequence number MUST be incremented for every LDP Hello message sent
	by the LDP router. Upon reception, the sequence number MUST be		by the LDP router. Upon reception, the sequence number MUST be
	greater than the sequence number in the last LDP Hello packet		greater than the sequence number in the last LDP Hello message
	accepted from the sending LDP neighbor. Otherwise, the LDP packet is		accepted from the sending LDP neighbor. Otherwise, the LDP message
	considered a replayed packet and dropped.		is considered a replayed packet and dropped. The Cryptographic
			Sequence Number is a single space per LDP router.
	LDP routers implementing this specification MUST use existing		LDP routers implementing this specification MUST use existing
	mechanisms to preserve the sequence number's strictly increasing		mechanisms to preserve the sequence number's strictly increasing
	property for the deployed life of the LDP router (including cold		property for the deployed life of the LDP router (including cold
	restarts). One mechanism for accomplishing this could be to use the		restarts). One mechanism for accomplishing this could be to use the
	high-order 32 bits of the sequence number as a boot count that is		high-order 32 bits of the sequence number as a boot count that is
	incremented anytime the LDP router loses its sequence number state.		incremented anytime the LDP router loses its sequence number state.
	Techniques such as sequence number space partitioning described above		Techniques such as sequence number space partitioning described above
	or non-volatile storage preservation can be used but are beyond the		or non-volatile storage preservation can be used but are beyond the
	scope of this specification. Sequence number wrap is described in		scope of this specification. Sequence number wrap is described in
	Section 2.4.		Section 2.4.
	- Authentication Data:		- Authentication Data:
	This field carries the digest computed by the Cryptographic		This field carries the digest computed by the Cryptographic
	Authentication algorithm in use. The length of the Authentication		Authentication algorithm in use. The length of the Authentication
	Data varies based on the cryptographic algorithm in use, which is		Data varies based on the cryptographic algorithm in use, which is
	skipping to change at page 8, line 8		skipping to change at page 8, line 27
	Auth type Length		Auth type Length
	--------------- ----------		--------------- ----------
	HMAC-SHA1 20 bytes		HMAC-SHA1 20 bytes
	HMAC-SHA-256 32 bytes		HMAC-SHA-256 32 bytes
	HMAC-SHA-384 48 bytes		HMAC-SHA-384 48 bytes
	HMAC-SHA-512 64 bytes		HMAC-SHA-512 64 bytes
	2.4. Sequence Number Wrap		2.4. Sequence Number Wrap
	When incrementing the sequence number for each transmitted LDP		When incrementing the sequence number for each transmitted LDP
	packet, the sequence number should be treated as an unsigned 64-bit		message, the sequence number should be treated as an unsigned 64-bit
	value. If the lower order 32-bit value wraps, the higher order		value. If the lower order 32-bit value wraps, the higher order
	32-bit value should be incremented and saved in non-volatile storage.		32-bit value should be incremented and saved in non-volatile storage.
	If the LDP router is deployed long enough that the 64-bit sequence		If the LDP router is deployed long enough that the 64-bit sequence
	number wraps, all keys, independent of key distribution mechanism		number wraps, all keys, independent of key distribution mechanism
	MUST be reset. This is done to avoid the possibility of replay		MUST be reset. This is done to avoid the possibility of replay
	attacks. Once the keys have been changed, the higher order sequence		attacks. Once the keys have been changed, the higher order sequence
	number can be reset to 0 and saved to non-volatile storage.		number can be reset to 0 and saved to non-volatile storage.
	3. Cryptographic Authentication Procedure		3. Cryptographic Authentication Procedure
	skipping to change at page 10, line 23		skipping to change at page 10, line 43
	being used.		being used.
	This also means that the use of hash functions with larger output		This also means that the use of hash functions with larger output
	sizes will also increase the size of the LDP message as transmitted		sizes will also increase the size of the LDP message as transmitted
	on the wire.		on the wire.
	6. Processing Hello Message Using Cryptographic Authentication		6. Processing Hello Message Using Cryptographic Authentication
	6.1. Transmission Using Cryptographic Authentication		6.1. Transmission Using Cryptographic Authentication
	Prior to transmitting the Hello message, the Length in the		Prior to transmitting the LDP Hello message, the Length in the
	Cryptographic Authentication TLV header is set as per the		Cryptographic Authentication TLV header is set as per the
	authentication algorithm that is being used. It is set to 24 for		authentication algorithm that is being used. It is set to 24 for
	HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384 and 68 for HMAC-		HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384 and 68 for HMAC-
	SHA-512.		SHA-512.
	The Security Association ID field is set to the ID of the current		The Security Association ID field is set to the ID of the current
	authentication key. The HMAC Hash is computed as explained in		authentication key. The HMAC Hash is computed as explained in
	Section 3. The resulting Hash is stored in the Authentication Data		Section 3. The resulting Hash is stored in the Authentication Data
	field prior to transmission. The authentication key MUST NOT be		field prior to transmission. The authentication key MUST NOT be
	carried in the packet.		carried in the packet.
	6.2. Receipt Using Cryptographic Authentication		6.2. Receipt Using Cryptographic Authentication
	The receiving LSR applies acceptability criteria for received Hellos		The receiving LSR applies acceptability criteria for received Hellos
	using cryptographic authentication. If the Cryptographic		using cryptographic authentication. If the Cryptographic
	Authentication TLV is unknown to the receiving LSR, the received		Authentication TLV is unknown to the receiving LSR, the received
	packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036].		packet MUST be discarded according to Section 3.5.1.2.2 of [RFC5036].
			The receiving router MUST determine whether to accept a Hello Message
			from a particular source IP address as follows. First, if the router
			has, for that source IP address, any LDP Hello authentication
			information, such as a stored cryptographic sequence number or that
			LDP Hello authentication is required, then the router MUST discard
			any unauthenticated Hello packets. As specified later in this
			section, a cryptographic sequence number is only stored for a source
			IP address as a result of receiving a valid authenticated Hello.
	The receiving LSR locates the LDP SA using the Security Association		The receiving LSR locates the LDP SA using the Security Association
	ID field carried in the message. If the SA is not found, or if the		ID field carried in the message. If the SA is not found, or if the
	SA is not valid for reception (i.e., current time < KeyStartAccept or		SA is not valid for reception (i.e., current time < KeyStartAccept or
	current time >= KeyStopAccept), LDP Hello message MUST be discarded,		current time >= KeyStopAccept), LDP Hello message MUST be discarded,
	and an error event SHOULD be logged.		and an error event SHOULD be logged.
	If the cryptographic sequence number in the LDP packet is less than		If the cryptographic sequence number in the LDP Hello message is less
	or equal to the last sequence number received from the same neighbor,		than or equal to the last sequence number received from the same
	the LDP message MUST be discarded, and an error event SHOULD be		neighbor, the LDP Hello message MUST be discarded, and an error event
	logged.		SHOULD be logged.
	Before the receiving LSR performs any processing, it needs to save		Before the receiving LSR performs any processing, it needs to save
	the values of the Authentication Data field. The receiving LSR then		the values of the Authentication Data field. The receiving LSR then
	replaces the contents of the Authentication Data field with AuthTag,		replaces the contents of the Authentication Data field with AuthTag,
	computes the Hash, using the authentication key specified by the		computes the Hash, using the authentication key specified by the
	received Security Association ID field, as explained in Section 3.		received Security Association ID field, as explained in Section 3.
	If the locally computed Hash is equal to the received value of the		If the locally computed Hash is equal to the received value of the
	Authentication Data field, the received packet is accepted for other		Authentication Data field, the received packet is accepted for other
	normal checks and processing as described in [RFC5036]. Otherwise,		normal checks and processing as described in [RFC5036]. Otherwise,
	if the locally computed Hash is not equal to the received value of		if the locally computed Hash is not equal to the received value of
	the Authentication Data field, the received packet MUST be discarded,		the Authentication Data field, the received LDP Hello message MUST be
	and an error event SHOULD be logged. The foresaid logging need to be		discarded, and an error event SHOULD be logged. The foresaid logging
	carefully rate limited, since while a LDP router is under attack of a		need to be carefully rate limited, since while a LDP router is under
	storm of spoofed hellos, the resource taking for logging could be		attack of a storm of spoofed hellos, the resource taking for logging
	overwelming.		could be overwelming.
	After the LDP Hello message has been successfully authenticated,		After the LDP Hello message has been successfully authenticated,
	implementations MUST store the 64-bit cryptographic sequence number		implementations MUST store the 64-bit cryptographic sequence number
	for the Hello message received from the neighbor. The saved		for the LDP Hello message received from the neighbor. The saved
	cryptographic sequence numbers will be used for replay checking for		cryptographic sequence numbers will be used for replay checking for
	subsequent packets received from the neighbor.		subsequent packets received from the neighbor.
	7. Security Considerations		7. Operational Considerations
			Careful consideration must be given to when and how to enable and
			disable authentication on LDP Hellos. On the one hand, it is
			critical that an attack cannot cause the authentication to be
			disabled. On the other hand, it is equally important that an
			operator can change the hardware and/or software associated with a
			neighbor's IP address and successfully bring up an LDP adjacency with
			the desired level of authentication, which may be with different or
			no authentication due to software restrictions.
			LDP Hello authentication information (e.g. whether authentication is
			enabled and what the last cryptographic sequence number is)
			associated with an IP address is learned via a set of interfaces. If
			an interface is administratively disabled, the LDP Hello
			authentication information learned via that interface MAY be
			forgotten. This enables an operator that is not specifically
			manipulating LDP Hello authentication configurations to easily bring
			up an LDP adjacency. An implementation of this standard SHOULD
			provide a configuration mechanism by which the LDP Hello
			authentication information associated with an IP address can be shown
			and can be forgotten; configuration mechanisms are assumed to be
			accessed via an authenticated channel.
			8. Security Considerations
	Section 1 of this document describes the security issues arising from		Section 1 of this document describes the security issues arising from
	the use of unauthenticated LDP Hello messages. In order to address		the use of unauthenticated LDP Hello messages. In order to address
	those issues, it is RECOMMENDED that all deployments use the		those issues, it is RECOMMENDED that all deployments use the
	Cryptographic Authentication TLV to authenticate the Hello messages.		Cryptographic Authentication TLV to authenticate the Hello messages.
	The quality of the security provided by the Cryptographic		The quality of the security provided by the Cryptographic
	Authentication TLV depends completely on the strength of the		Authentication TLV depends completely on the strength of the
	cryptographic algorithm in use, the strength of the key being used,		cryptographic algorithm in use, the strength of the key being used,
	and the correct implementation of the security mechanism in		and the correct implementation of the security mechanism in
	skipping to change at page 12, line 11		skipping to change at page 13, line 17
	on the key are not feasible in their environments. In support of		on the key are not feasible in their environments. In support of
	these recommendations, management systems SHOULD support hexadecimal		these recommendations, management systems SHOULD support hexadecimal
	input of Authentication Keys.		input of Authentication Keys.
	The mechanism described herein is not perfect . However, this		The mechanism described herein is not perfect . However, this
	mechanism introduces a significant increase in the effort required		mechanism introduces a significant increase in the effort required
	for an adversary to successfully attack the LDP Hello protocol while		for an adversary to successfully attack the LDP Hello protocol while
	not causing undue implementation, deployment, or operational		not causing undue implementation, deployment, or operational
	complexity.		complexity.
	8. IANA Considerations		9. IANA Considerations
	The IANA is requested to as assign a new TLV from the "Label		The IANA is requested to as assign a new TLV from the "Label
	Distribution Protocol (LDP) Parameters" registry, "TLV Type Name		Distribution Protocol (LDP) Parameters" registry, "TLV Type Name
	Space".		Space".
	Value Meaning Reference		Value Meaning Reference
	----- -------------------------------- ------------------------		----- -------------------------------- ------------------------
	TBD1 Cryptographic Authentication TLV this document (sect 2.3)		TBD1 Cryptographic Authentication TLV this document (sect 2.3)
	The IANA is also requested to as assign value from the		The IANA is also requested to as assign value from the
	skipping to change at page 12, line 35		skipping to change at page 13, line 41
	Value Description Reference		Value Description Reference
	----- -------------------------------- ----------------------		----- -------------------------------- ----------------------
	TBD2 LDP Cryptographic Protocol ID this document (sect 4)		TBD2 LDP Cryptographic Protocol ID this document (sect 4)
	Note to the RFC Editor and IANA (to be removed before publication):		Note to the RFC Editor and IANA (to be removed before publication):
	The new value should be assigned from the range 0x400 - 0x4ff using		The new value should be assigned from the range 0x400 - 0x4ff using
	the first free value.		the first free value.
	9. Acknowledgements		10. Acknowledgements
	We are indebted to Yaron Sheffer who helped us enormously in		We are indebted to Yaron Sheffer who helped us enormously in
	rewriting the draft to get rid of the redundant crypto mathematics		rewriting the draft to get rid of the redundant crypto mathematics
	that we had added here.		that we had added here.
	We would also like to thank Liu Xuehu for his work on background and		We would also like to thank Liu Xuehu for his work on background and
	motivation for LDP Hello authentication. And last but not the least,		motivation for LDP Hello authentication. And last but not the least,
	we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen		we would also thank Adrian Farrel, Eric Rosen, Sam Hartman, Stephen
	Farrell, Eric Gray, Kamran Raza and Acee Lindem for their valuable		Farrell, Eric Gray, Kamran Raza and Acee Lindem for their valuable
	comments.		comments.
	10. References		11. References
	10.1. Normative References
			11.1. Normative References
	[FIPS-180-3]		[FIPS-180-3]
	"Secure Hash Standard (SHS), FIPS PUB 180-3", October		"Secure Hash Standard (SHS), FIPS PUB 180-3", October
	2008.		2008.
	[FIPS-198]
	"The Keyed-Hash Message Authentication Code (HMAC), FIPS
	PUB 198", March 2002.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104, February		Hashing for Message Authentication", RFC 2104, February
	1997.		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.
			[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
			Specification", RFC 5036, October 2007.
			11.2. Informative References
	[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		[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
	Specification", RFC 5036, October 2007.		Pignataro, "The Generalized TTL Security Mechanism
			(GTSM)", RFC 5082, 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.
	[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
	Authentication Trailer for OSPFv3", RFC 7166, March 2014.
	10.2. Informative References
	[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
	Pignataro, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 5082, October 2007.
	[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.
	[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security		[RFC6720] Pignataro, C. and R. Asati, "The Generalized TTL Security
	Mechanism (GTSM) for the Label Distribution Protocol		Mechanism (GTSM) for the Label Distribution Protocol
	(LDP)", RFC 6720, August 2012.		(LDP)", RFC 6720, August 2012.
	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP, and MSDP Issues According to the Keying		BGP, LDP, PCEP, and MSDP Issues According to the Keying
	and Authentication for Routing Protocols (KARP) Design		and Authentication for Routing Protocols (KARP) Design
	Guide", RFC 6952, May 2013.		Guide", RFC 6952, May 2013.
			[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
			Authentication Trailer for OSPFv3", RFC 7166, March 2014.
	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
	China		China
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
	Manav Bhatia		Manav Bhatia
	Alcatel-Lucent		Ionos Networks
	India		India
	Email: manavbhatia@gmail.com		Email: manav@ionosnetworks.com
End of changes. 34 change blocks.
	75 lines changed or deleted		108 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/