draft-ietf-mpls-ldp-hello-crypto-auth-02.txt		draft-ietf-mpls-ldp-hello-crypto-auth-03.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: March 2, 2014 M. Bhatia		Expires: September 20, 2014 M. Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	August 29, 2013		March 19, 2014
	LDP Hello Cryptographic Authentication		LDP Hello Cryptographic Authentication
	draft-ietf-mpls-ldp-hello-crypto-auth-02.txt		draft-ietf-mpls-ldp-hello-crypto-auth-03.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 March 2, 2014.		This Internet-Draft will expire on September 20, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Cryptographic Authentication TLV . . . . . . . . . . . . . . . 6		2. Cryptographic Authentication TLV . . . . . . . . . . . . . . . 6
	2.1. Optional Parameter for Hello Message . . . . . . . . . . . 6		2.1. Optional Parameter for Hello Message . . . . . . . . . . . 6
	2.2. Cryptographic Authentication TLV Encoding . . . . . . . . 6		2.2. LDP Security Association . . . . . . . . . . . . . . . . . 6
	2.3. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 7		2.3. Cryptographic Authentication TLV Encoding . . . . . . . . 8
			2.4. Sequence Number Wrap . . . . . . . . . . . . . . . . . . . 9
	3. Cryptographic Authentication Procedure . . . . . . . . . . . . 8		3. Cryptographic Authentication Procedure . . . . . . . . . . . . 10
	4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . . 9		4. Cross Protocol Attack Mitigation . . . . . . . . . . . . . . . 11
	5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 10		5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . . . 12
	5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 10		5.1. Preparing the Cryptographic Key . . . . . . . . . . . . . 12
	5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . . 11		5.2. Computing the Hash . . . . . . . . . . . . . . . . . . . . 13
	5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.3. Result . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Processing Hello Message Using Cryptographic Authentication . 12		6. Processing Hello Message Using Cryptographic Authentication . 14
	6.1. Transmission Using Cryptographic Authentication . . . . . 12		6.1. Transmission Using Cryptographic Authentication . . . . . 14
	6.2. Receipt Using Cryptographic Authentication . . . . . . . . 12		6.2. Receipt Using Cryptographic Authentication . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	10.2. Informative References . . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	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 runs 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.
	Unlike other LDP messages, the Hello messages are sent using UDP and		Since the Hello messages are sent using UDP and not TCP, these
	not TCP. This implies that these messages cannot use the security		messages cannot use the security mechanisms defined for TCP
	mechanisms defined for TCP [RFC5926]. Besides a note that some		[RFC5926]. While some configuration guidance is given in [RFC5036]
	configuration may help protect against bogus discovery messages,		to help protect against false discovery messages, it does not provide
	[RFC5036] does not really provide any security mechanism to protect		an explicit security mechanism to protect the Hello messages
	the Hello messages.
	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
	[I-D.ietf-karp-routing-tcp-analysis].		[I-D.ietf-karp-routing-tcp-analysis].
	[RFC5036] describes that the threat of spoofed Basic Hellos can be		[RFC5036] states that the threat of spoofed Hellos can be reduced by
	reduced by accepting Basic Hellos only on interfaces to which LSRs		accepting Hellos only on interfaces to which LSRs that can be trusted
	that can be trusted are directly connected, and ignoring Basic Hellos		are directly connected, and ignoring Hellos not addressed to the "all
	not addressed to the "all routers on this subnet" multicast group.		routers on this subnet" multicast group. Spoofing attacks via
	Spoofing attacks via Extended Hellos are a potentially more serious		Targeted Hellos are a potentially more serious threat. An LSR can
	threat. An LSR can reduce the threat of spoofed Extended Hellos by		reduce the threat of spoofed Targeted Hellos by filtering them and
	filtering them and accepting only those originating at sources		accepting only those originating at sources permitted by an access
	permitted by an access list. However, filtering using access lists		list. However, filtering using access lists requires LSR resource,
	requires LSR resource, and does not prevent IP-address spoofing.		and does not 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 message 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. The LSRs could be configured to only accept
	Hello messages from specific peers when authentication is in use.		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 key IDs) are configured in each system. For each		(with corresponding key IDs) are configured in each system. For each
	LDP Hello packet, the key is used to generate and verify a HMAC Hash		LDP Hello message, the key is used to generate and verify a HMAC Hash
	that is stored in the LDP Hello packet. For cryptographic hash		that is stored in the LDP Hello message. For cryptographic hash
	function, this document proposes to use SHA-1, SHA-256, SHA-384, and		function, this document proposes to use SHA-1, SHA-256, SHA-384, and
	SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-3].		SHA-512 defined in US NIST Secure Hash Standard (SHS) [FIPS-180-3].
	The HMAC authentication mode defined in NIST FIPS 198 is used		The HMAC authentication mode defined in NIST FIPS 198 is used
	[FIPS-198]. Of the above, implementations MUST include support for		[FIPS-198]. Of the above, implementations MUST include support for
	at least HMAC-SHA-256 and SHOULD include support for HMAC-SHA-1 and		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-512.		MAY include support for either of HMAC-SHA-384 or 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
	skipping to change at page 6, line 25		skipping to change at page 6, line 25
	Optional Parameter Type		Optional Parameter Type
	------------------------------- --------		------------------------------- --------
	IPv4 Transport Address 0x0401 (RFC5036)		IPv4 Transport Address 0x0401 (RFC5036)
	Configuration Sequence Number 0x0402 (RFC5036)		Configuration Sequence Number 0x0402 (RFC5036)
	IPv6 Transport Address 0x0403 (RFC5036)		IPv6 Transport Address 0x0403 (RFC5036)
	Cryptographic Authentication 0x0404 (this document, TBD by IANA)		Cryptographic Authentication 0x0404 (this document, TBD by IANA)
	The Cryptographic Authentication TLV Encoding is described in section		The Cryptographic Authentication TLV Encoding is described in section
	2.2.		2.2.
	2.2. Cryptographic Authentication TLV Encoding		2.2. LDP Security Association
	0 1 2 3		An LDP Security Association (SA) contains a set of parameters shared
	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		between any two legitimate LDP speakers.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0|0| Auth (TBD) | Length |		Parameters associated with an LDP SA are as follows:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Authentication Key ID |		o Security Association Identifier (SA ID)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cryptographic Sequence Number (High Order 32 Bits) |		This is a 32-bit unsigned integer used to uniquely identify an LDP
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		SA, as manually configured by the network operator.
	| Cryptographic Sequence Number (Low Order 32 Bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		The receiver determines the active SA by looking at the SA ID
	| |		field in the incoming Hello message.
	| Authentication Data (Variable) |
	~ ~		The sender, based on the active configuration, selects an SA to
	| |		use and puts the correct Key ID value associated with the SA in
	| |		the 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 the packet.
			Using SA IDs makes changing keys while maintaining protocol
			operation convenient. Each SA ID specifies two independent parts,
			the authentication algorithm and the authentication key, as
			explained below.
			Normally, an implementation would allow the network operator to
			configure a set of keys in a key chain, with each key in the chain
			having fixed lifetime. The actual operation of these mechanisms
			is outside the scope of this document.
			Note that each SA ID can indicate a key with a different
			authentication algorithm. This allows the introduction of new
			authentication mechanisms without disrupting existing LDP
			sessions.
			o Authentication Algorithm
			This signifies the authentication algorithm to be used with the
			LDP SA. This information is never sent in clear text over the
			wire. Because this information is not sent on the wire, the
			implementer chooses an implementation specific representation for
			this information.
			Currently, the following algorithms are supported:
			HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512.
			o Authentication Key
			This value denotes the cryptographic authentication key associated
			with the LDP SA. The length of this key is variable and depends
			upon the authentication algorithm specified by the LDP SA.
			o KeyStartAccept
			The time that this OSPFv3 router will accept packets that have
			been created with this OSPFv3 Security Association.
			o KeyStartGenerate
			The time that this LDP router will begin using this LDP Security
			Association for LDP Hello message generation.
			o KeyStopGenerate
			The time that this LDP router will stop using this LDP Security
			Association for LDP Hello message generation.
			o KeyStopAccept
			The time that this LDP router will stop accepting packets
			generated with this LDP Security Association.
			In order to achieve smooth key transition, KeyStartAccept SHOULD be
			less than KeyStartGenerate and KeyStopGenerate SHOULD be less than
			KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left
			unspecified, the time will default to 0 and the key will be used
			immediately. If KeyStopGenerate or KeyStopAccept are left
			unspecified, the time will default to infinity and the key's lifetime
			will be infinite. When a new key replaces an old, the
			KeyStartGenerate time for the new key MUST be less than or equal to
			the KeyStopGenerate time of the old key.
			Key storage SHOULD persist across a system restart, warm or cold, to
			avoid operational issues. In the event that the last key associated
			with an interface expires, it is unacceptable to revert to an
			unauthenticated condition, and not advisable to disrupt routing.
			Therefore, the router SHOULD send a "last Authentication Key
			expiration" notification to the network manager and treat the key as
			having an infinite lifetime until the lifetime is extended, the key
			is deleted by network management, or a new key is configured
			2.3. Cryptographic Authentication TLV Encoding
			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|0| Auth (TBD) | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Security Association ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Cryptographic Sequence Number (High Order 32 Bits) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Cryptographic Sequence Number (Low Order 32 Bits) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			| Authentication Data (Variable) |
			~ ~
			| |
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	- Type: TBD, Cryptographic Authentication		- Type: TBD, Cryptographic Authentication
	- Length: Specifying the length in octets of the value field.		- Length: Specifying the length in octets of the value field.
	- Auth Key ID: 32 bit field that identifies the algorithm and the		- Security Association ID: 32 bit field that maps to the
	secret key used to create the message digest carried in LDP payload.		authentication algorithm and the secret key used to create the
			message digest carried in LDP payload.
			Though the SA ID implies the algorithm, the HMAC output size should
			not be used by implementers as an implicit hint, because additional
			algorithms may be defined in the future that have the same output
			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 packet 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 packet
	accepted from the sending LDP neighbor. Otherwise, the LDP packet is		accepted from the sending LDP neighbor. Otherwise, the LDP packet is
	considered a replayed packet and dropped.		considered a replayed packet and dropped.
	LDP routers implementing this specification MUST use available		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 wrap/boot count that		high-order 32 bits of the sequence number as a boot count that is
	is incremented anytime the LDP router loses its sequence number		incremented anytime the LDP router loses its sequence number state.
	state. Techniques such as sequence number space partitioning		Techniques such as sequence number space partitioning described above
	described above or non-volatile storage preservation can be used but		or non-volatile storage preservation can be used but are beyond the
	are really beyond the scope of this specification. Sequence number		scope of this specification. Sequence number wrap is described in
	wrap is described in Section 2.3.		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
	shown as below:		shown as below:
	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.3. 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		packet, the sequence number should be treated as an unsigned 64-bit
	value. If the lower order 32-bit value wraps, the higher order 32-		value. If the lower order 32-bit value wraps, the higher order 32-
	bit value should be incremented and saved in non-volatile storage.		bit value should be incremented and saved in non-volatile storage.
	If by some chance the LDP router is deployed long enough that there		If the LDP router is deployed long enough that the 64-bit sequence
	is a possibility that the 64-bit sequence number may wrap, all keys,		number wraps, all keys, independent of key distribution mechanism
	independent of key distribution mechanism, MUST be reset to avoid the		MUST be reset. This is done to avoid the possibility of replay
	possibility of replay attacks. Once the keys have been changed, the		attacks. Once the keys have been changed, the higher order sequence
	higher order sequence number can be reset to 0 and saved to non-		number can be reset to 0 and saved to non-volatile storage.
	volatile storage.
	3. Cryptographic Authentication Procedure		3. Cryptographic Authentication Procedure
	As noted earlier, the Auth Key ID maps to the authentication		As noted earlier, the Security Association ID maps to the
	algorithm and the secret key used to generate and verify the message		authentication algorithm and the secret key used to generate and
	digest. This specification discusses the computation of LDP		verify the message digest. This specification discusses the
	Cryptographic Authentication data when any of the NIST SHS family of		computation of LDP Cryptographic Authentication data when any of the
	algorithms is used in the Hashed Message Authentication Code (HMAC)		NIST SHS family of algorithms is used in the Hashed Message
	mode.		Authentication Code (HMAC) mode.
	The currently valid algorithms (including mode) for LDP Cryptographic		The currently valid algorithms (including mode) for LDP Cryptographic
	Authentication include:		Authentication include:
	HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512		HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512
	Of the above, implementations of this specification MUST include		Of the above, implementations of this specification 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 also include support for HMAC-SHA-384 and HMAC-		HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and HMAC-
	SHA-512.		SHA-512.
	skipping to change at page 10, 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]. According to [FIPS-180-3], Section 3, keys greater than L		[RFC6506] [RFC7166]. According to [FIPS-180-3], Section 3, keys
	octets do not significantly increase the function strength. Ks is		greater than L octets do not significantly increase the function
	computed as follows:		strength. Ks is 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
	First, the Authentication Data field in the Cryptographic		First, the Authentication Data field in the Cryptographic
	Authentication TLV is filled with the value Apad. Then, to compute		Authentication TLV is filled with the value Apad. Then, to compute
	HMAC over the Hello packet it performs:		HMAC over the Hello message it performs:
	H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Packet)))		H(Ko XOR Opad || H(Ko XOR Ipad || (Hello Message)))
	Hello Packet refers to the LDP Hello packet excluding the IP header.		Hello Message refers to the LDP Hello message excluding the IP
			header.
	When XORing Ko and Ipad, or XORing Ko and Opad, Ko must be padded		When XORing Ko and Ipad, or XORing Ko and Opad, Ko must be padded
	with zeros to the length of Ipad and the Opad.		with zeros to the length of Ipad and the Opad.
	5.3. Result		5.3. Result
	The resultant Hash becomes the Authentication Data that is sent in		The resultant Hash becomes the Authentication Data that is sent in
	the Authentication Data field of the Cryptographic Authentication		the Authentication Data field of the Cryptographic Authentication
	TLV. The length of the Authentication Data field is always identical		TLV. The length of the Authentication Data field is always identical
	to the message digest size of the specific hash function H that is		to the message digest size of the specific hash function H that is
	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 packet as transmitted on		sizes will also increase the size of the LDP message as transmitted
	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 Hello message, the Length in the Cryptographic		Prior to transmitting the Hello message, the Length in the
	Authentication TLV header is set as per the authentication algorithm		Cryptographic Authentication TLV header is set as per the
	that is being used. It is set to 24 for HMAC-SHA-1, 36 for HMAC-SHA-		authentication algorithm that is being used. It is set to 24 for
	256, 52 for HMAC-SHA-384 and 68 for HMAC-SHA-512.		HMAC-SHA-1, 36 for HMAC-SHA-256, 52 for HMAC-SHA-384 and 68 for HMAC-
			SHA-512.
	The Auth Key ID field is set to the ID of the current authentication		The Security Association ID field is set to the ID of the current
	key. The HMAC Hash is computed as explained in Section 3. The		authentication key. The HMAC Hash is computed as explained in
	resulting Hash is stored in the Authentication Data field prior to		Section 3. The resulting Hash is stored in the Authentication Data
	transmission. The authentication key MUST NOT be carried in the		field prior to transmission. The authentication key MUST NOT be
	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].
	If the Auth Key ID field does not match the ID of a configured		The receiving LSR locates the LDP SA using the Security Association
	authentication key, the received packet MUST be discarded.		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
			current time >= KeyStopAccept), LDP Hello message MUST be discarded.
	If the cryptographic sequence number in the LDP packet is less than		If the cryptographic sequence number in the LDP packet is less than
	or equal to the last sequence number received from the same neighbor,		or equal to the last sequence number received from the same neighbor,
	the LDP packet MUST be discarded.		the LDP message MUST be discarded, and an error event 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 Apad,		replaces the contents of the Authentication Data field with Apad,
	computes the Hash, using the authentication key specified by the		computes the Hash, using the authentication key specified by the
	received Auth Key ID field, as explained in Section 3. If the		received Security Association ID field, as explained in Section 3.
	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 packet MUST be discarded,
			and an error event SHOULD be logged.
			After the LDP Hello message has been successfully authenticated,
			implementations MUST store the 64-bit cryptographic sequence number
			for the Hello message received from the neighbor. The saved
			cryptographic sequence numbers will be used for replay checking for
			subsequent packets received from the neighbor.
	7. Security Considerations		7. 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
	skipping to change at page 15, line 12		skipping to change at page 18, line 12
	----- -------------------------------- ---------		----- -------------------------------- ---------
	TBD LDP Cryptographic Protocol ID this document (sect 4)		TBD LDP Cryptographic Protocol ID this document (sect 4)
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Liu Xuehu for his work on background		The authors would like to thank Liu Xuehu for his work on background
	and motivation for LDP Hello authentication. The authors also would		and motivation for LDP Hello authentication. The authors also would
	like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray,		like to thank Adrian Farrel, Eric Rosen, Sam Hartman, Eric Gray,
	Kamran Raza and Acee Lindem for their valuable comments.		Kamran Raza and Acee Lindem for their valuable comments.
	We would also like to thank the authors of RFC 5709 and RFC 6506 from		We would also like to thank the authors of RFC 5709 and RFC 7166 from
	where we have taken most of the cryptographic computation procedures		where we have taken most of the cryptographic computation procedures
	from.		from.
	10. References		10. References
	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.
	skipping to change at page 16, line 42		skipping to change at page 19, line 42
	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		[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
	Authentication Trailer for OSPFv3", RFC 6506,		Authentication Trailer for OSPFv3", RFC 6506,
	February 2012.		February 2012.
			[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
			Authentication Trailer for OSPFv3", RFC 7166, March 2014.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-karp-routing-tcp-analysis]		[I-D.ietf-karp-routing-tcp-analysis]
	Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP and MSDP Issues According to KARP Design		BGP, LDP, PCEP and MSDP Issues According to KARP Design
	Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in		Guide", draft-ietf-karp-routing-tcp-analysis-07 (work in
	progress), April 2013.		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,
End of changes. 41 change blocks.
	106 lines changed or deleted		219 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/