draft-ietf-mpls-ldp-hello-crypto-auth-09.txt		draft-ietf-mpls-ldp-hello-crypto-auth-10.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 20, 2014 M. Bhatia		Expires: December 21, 2014 M. Bhatia
	Ionos Networks		Ionos Networks
	June 18, 2014		June 19, 2014
	LDP Hello Cryptographic Authentication		LDP Hello Cryptographic Authentication
	draft-ietf-mpls-ldp-hello-crypto-auth-09.txt		draft-ietf-mpls-ldp-hello-crypto-auth-10.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 Hashed Message Authentication Code		the LDP Hello messages using Hashed Message Authentication Code
	(HMAC) with National Institute of Standards and Technology (NIST)		(HMAC) with National Institute of Standards and Technology (NIST)
	Secure Hash Standard family of algorithms.		Secure Hash Standard family of algorithms.
	skipping to change at page 1, line 44		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 20, 2014.		This Internet-Draft will expire on December 21, 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 11, line 16		skipping to change at page 11, line 16
	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		The receiving router MUST determine whether to accept a Hello Message
	from a particular source IP address as follows. First, if the router		from a particular source IP address as follows. First, if the router
	has, for that source IP address, any LDP Hello authentication		has, for that source IP address, a stored LDP Hello cryptographic
	information, such as a stored cryptographic sequence number or that		sequence number, or is configured to require LDP Hello
	LDP Hello authentication is required, then the router MUST discard		authentication, then the router MUST discard any unauthenticated
	any unauthenticated Hello packets. As specified later in this		Hello packets. As specified later in this section, a cryptographic
	section, a cryptographic sequence number is only stored for a source		sequence number is only stored for a source IP address as a result of
	IP address as a result of receiving a valid authenticated Hello.		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 Hello message is less		If the cryptographic sequence number in the LDP Hello message is less
	than or equal to the last sequence number received from the same		than or equal to the last sequence number received from the same
	neighbor, the LDP Hello message MUST be discarded, and an error event		neighbor, the LDP Hello message MUST be discarded, and an error event
	skipping to change at page 11, line 51		skipping to change at page 11, line 51
	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 LDP Hello message MUST be		the Authentication Data field, the received LDP Hello message MUST be
	discarded, and an error event SHOULD be logged. The foresaid logging		discarded, and an error event SHOULD be logged. The foresaid logging
	need to be carefully rate limited, since while a LDP router is under		need to be carefully rate limited, since while a LDP router is under
	attack of a storm of spoofed hellos, the resource taking for logging		attack of a storm of spoofed hellos, the resource taking for logging
	could be 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 LDP Hello message received from the neighbor. The saved		for the LDP Hello message received from the source IP address. The
	cryptographic sequence numbers will be used for replay checking for		saved cryptographic sequence numbers will be used for replay checking
	subsequent packets received from the neighbor.		for subsequent packets received from the source IP address.
	7. Operational Considerations		7. Operational Considerations
	Careful consideration must be given to when and how to enable and		Careful consideration must be given to when and how to enable and
	disable authentication on LDP Hellos. On the one hand, it is		disable authentication on LDP Hellos. On the one hand, it is
	critical that an attack cannot cause the authentication to be		critical that an attack cannot cause the authentication to be
	disabled. On the other hand, it is equally important that an		disabled. On the other hand, it is equally important that an
	operator can change the hardware and/or software associated with a		operator can change the hardware and/or software associated with a
	neighbor's IP address and successfully bring up an LDP adjacency with		neighbor's IP address and successfully bring up an LDP adjacency with
	the desired level of authentication, which may be with different or		the desired level of authentication, which may be with different or
End of changes. 6 change blocks.
	13 lines changed or deleted		13 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/