draft-ietf-csi-proxy-send-03.txt		draft-ietf-csi-proxy-send-04.txt
	CGA & SEND maintenance Working S. Krishnan		CGA & SEND maintenance Working S. Krishnan
	Group Ericsson		Group Ericsson
	Internet-Draft J. Laganier		Internet-Draft J. Laganier
	Intended status: Standards Track QUALCOMM Inc.		Intended status: Experimental QUALCOMM Inc.
	Expires: September 23, 2010 M. Bonola		Expires: December 2, 2010 M. Bonola
	Rome Tor Vergata University		Rome Tor Vergata University
	A. Garcia-Martinez		A. Garcia-Martinez
	UC3M		UC3M
	March 22, 2010		May 31, 2010
	Secure Proxy ND Support for SEND		Secure Proxy ND Support for SEND
	draft-ietf-csi-proxy-send-03		draft-ietf-csi-proxy-send-04
	Abstract		Abstract
	Secure Neighbor Discovery (SEND) specifies a method for securing		Secure Neighbor Discovery (SEND) specifies a method for securing
	Neighbor Discovery (ND) signaling against specific threats. As		Neighbor Discovery (ND) signaling against specific threats. As
	defined today, SEND assumes that the node sending a ND message is the		defined today, SEND assumes that the node sending a ND message is the
	owner of the address from which the message is sent, so that it is in		owner of the address from which the message is sent, so that it is in
	possession of the private key used to generate the digital signature		possession of the private key used to generate the digital signature
	on the message. This means that the Proxy ND signaling performed by		on the message. This means that the Proxy ND signaling performed by
	nodes that do not possess knowledge of the address owner's private		nodes that do not possess knowledge of the address owner's private
	key cannot be secured using SEND. This document extends the current		key cannot be secured using SEND. This document extends the current
	SEND specification in order to secure Proxy ND operation.		SEND specification in order to secure Proxy ND operation.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on December 2, 2010.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 23, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 6		4. Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . . 6
	5. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 8		5. Secure Proxy ND Specification . . . . . . . . . . . . . . . . 8
	5.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 8		5.1. Proxy Signature Option . . . . . . . . . . . . . . . . . . 8
	5.2. Modified SEND processing rules . . . . . . . . . . . . . . 10		5.2. Modified SEND processing rules . . . . . . . . . . . . . . 10
	5.2.1. Processing rules for senders . . . . . . . . . . . . . 10		5.2.1. Processing rules for senders . . . . . . . . . . . . . 10
	5.2.2. Processing rules for receivers . . . . . . . . . . . . 11		5.2.2. Processing rules for receivers . . . . . . . . . . . . 11
	5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 12		5.3. Proxying Link-Local Addresses . . . . . . . . . . . . . . 12
	6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 13		6. Application Scenarios . . . . . . . . . . . . . . . . . . . . 13
	6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 13		6.1. Scenario 1: Mobile IPv6 . . . . . . . . . . . . . . . . . 13
	6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 14		6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 14
	6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 16		6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 17
	7. Backward Compatibility with RFC3971 nodes and non-SEND		7. Backward Compatibility with RFC3971 nodes and non-SEND
	nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 19		7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 19
	7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 19		7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 22		8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 24		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	10.2. Informative References . . . . . . . . . . . . . . . . . . 24		11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		11.2. Informative References . . . . . . . . . . . . . . . . . . 25
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Requirements notation		1. Requirements notation
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for		Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for
	securing Neighbor Discovery (ND) signaling [RFC4861] against specific		securing Neighbor Discovery (ND) signaling [RFC4861] against specific
	threats. As defined today, SEND assumes that the node sending a ND		threats [RFC3756]. As defined today, SEND assumes that the node
	message is the owner of the address from which the message is sent,		sending a ND message is the owner of the address from which the
	so that it is in possession of the private key used to generate the		message is sent, so that it is in possession of the private key used
	digital signature on the message. This means that the Proxy ND		to generate the digital signature on the message. This means that
	signaling performed by nodes that do not possess knowledge of the		the Proxy ND signaling performed by nodes that do not possess
	address owner's private key cannot be secured using SEND.		knowledge of the address owner's private key cannot be secured using
			SEND.
	This document extends the current SEND specification with support for		This document extends the current SEND specification with support for
	Proxy ND. From this point on we refer to such extension as "Secure		Proxy ND. From this point on we refer to such extension as "Secure
	Proxy ND Support for SEND".		Proxy ND Support for SEND".
	3. Terminology		3. Terminology
	Secure Proxy ND		Secure ND Proxy
	A node authorized to either modify or generate a SEND message		A node authorized to either modify or generate a SEND message
	without knowing the private key related to the source address of		without knowing the private key related to the source address of
	the ICMPv6 ND message.		the ICMPv6 ND message.
	Proxied IPv6 address		Proxied IPv6 address
	An IPv6 address that does not belong to the Secure Proxy ND and		An IPv6 address that does not belong to the Secure ND Proxy and
	for which the Secure Proxy ND is performing advertisements.		for which the Secure ND Proxy is performing advertisements.
	Non-SEND node		Non-SEND node
	An IPv6 node that does not implement the SEND [RFC3971]		An IPv6 node that does not implement the SEND [RFC3971]
	specification but uses only the ND protocol defined in [RFC4861]		specification but uses only the ND protocol defined in [RFC4861]
	and [RFC4862], without security.		and [RFC4862], without security.
	RFC3971 node		RFC3971 node
	An IPv6 node that does not implement the specification defined in		An IPv6 node that does not implement the specification defined in
	this document for Secure Proxy ND support, but uses only the SEND		this document for Secure Proxy ND support, but uses only the SEND
	specification as defined in [RFC3971].		specification as defined in [RFC3971].
	SPND node		SPND node
	An IPv6 node that implements the specification defined in this		An IPv6 node that receives and validates messages according to the
	document for Secure Proxy ND support.		specification defined in this document for Secure Proxy ND
			support.
	4. Secure Proxy ND Overview		4. Secure Proxy ND Overview
	The original SEND specification [RFC3971] has implicitly assumed that		The original SEND specification [RFC3971] has implicitly assumed that
	only the node sending a ND message is the owner of the address from		only the node sending a ND message is the owner of the address from
	which the message is sent. This assumption does not allow proxying		which the message is sent. This assumption does not allow proxying
	of ND messages since the advertiser is required to generate a valid		of ND messages since the advertiser is required to generate a valid
	RSA Signature option, which in turns requires possession of the		RSA Signature option, which in turns requires possession of the
	public-private key pair that was used to generate a CGA, or that was		public-private key pair that was used to generate a CGA, or that was
	associated to a router certificate.		associated to a router certificate.
	skipping to change at page 6, line 30		skipping to change at page 6, line 30
	which the purpose for which the certificate is issued has been		which the purpose for which the certificate is issued has been
	specified explicitly as described in a companion document		specified explicitly as described in a companion document
	[I-D.ietf-csi-send-cert]. Briefly, a KeyPurposeId value is		[I-D.ietf-csi-send-cert]. Briefly, a KeyPurposeId value is
	defined for authorizing proxies. The inclusion of the proxy		defined for authorizing proxies. The inclusion of the proxy
	authorization value allows the certificate owner to perform		authorization value allows the certificate owner to perform
	proxying of SEND messages for a range of addresses indicated in		proxying of SEND messages for a range of addresses indicated in
	the same certificate. This certificate can be exchanged through		the same certificate. This certificate can be exchanged through
	the Authorization Delegation Discovery process defined in		the Authorization Delegation Discovery process defined in
	[RFC3971].		[RFC3971].
	o A new Neighbor Discovery option called Proxy Signature option		o A new Neighbor Discovery option called Proxy Signature (PS)
	(PSO). This option contains the hash value of the public key of		option. This option contains the hash value of the public key of
	the proxy, and the digital signature of the SEND message computed		the proxy, and the digital signature of the SEND message computed
	with the private key of the proxy. The hash of the public key of		with the private key of the proxy. The hash of the public key of
	the proxy is computed over the public key contained in the Secure		the proxy is computed over the public key contained in the Secure
	Proxy ND's certificate. When a ND message contains a PSO, it MUST		Proxy ND's certificate. When a ND message contains a PS option,
	NOT contain CGA and RSA Signature options. This option can be		it MUST NOT contain CGA and RSA Signature options. This option
	appended to any ND message: NA, NS, RS, RA and Redirect.		can be appended to any ND message: NA, NS, RS, RA and Redirect.
	o A modification of the SEND processing rules for all ND messages:		o A modification of the SEND processing rules for all ND messages:
	NA, NS, RS, RA, and Redirect. When any of these messages		NA, NS, RS, RA, and Redirect. When any of these messages
	containing a valid Proxy Signature option is validated, it is		containing a valid Proxy Signature option is validated, it is
	considered as secure.		considered as secure.
	These extensions are applied in the following way:		These extensions are applied in the following way:
	o A Secure Proxy ND which proxies ND messages on behalf of a node		o A Secure ND Proxy which proxies ND messages on behalf of a node
	can use the PSO option to protect the proxied messages. This		can use the PS option to protect the proxied messages. This
	Secure Proxy ND becomes part of the trusted infrastructure just		Secure ND Proxy becomes part of the trusted infrastructure just
	like a SEND router.		like a SEND router.
	o In order to allow nodes to successfully validate secured proxied		o In order to allow nodes to successfully validate secured proxied
	messages, the nodes must be aware of the Secure Proxy ND		messages, the nodes must be aware of the Secure Proxy ND
	certificate (in the format described in [I-D.ietf-csi-send-cert])		certificate (in the format described in [I-D.ietf-csi-send-cert])
	and must apply the modified processing rules specified in this		and must apply the modified processing rules specified in this
	document. We call these nodes 'SPND nodes'. Note that the rules		document. We call these nodes 'SPND nodes'. Note that the rules
	for generating ND messages in SPND nodes do not change, so these		for generating ND messages in SPND nodes do not change, so these
	nodes behave as defined in [RFC3971] for sending ND messages.		nodes behave as defined in [RFC3971] for sending ND messages.
	o To allow SPND nodes to know the certificate path required to		o To allow SPND nodes to know the certificate path required to
	validate the public key of the proxy, devices responding to CPS		validate the public key of the proxy, devices responding to CPS
	(Certification Path Solicitation) messages with CPA (Certification		(Certification Path Solicitation) messages with CPA (Certification
	Path Advertisements) as defined in Section 6 of SEND specification		Path Advertisements) as defined in Section 6 of SEND specification
	[RFC3971] must handle the certificate format specified in		[RFC3971] are extended to support the certificate format specified
	[I-D.ietf-csi-send-cert], and must be configured with the		in [I-D.ietf-csi-send-cert], and are configured with the
	appropriate certification path.		appropriate certification path.
	The proposed approach resolves the incompatibilities between the
	current SEND specification and the application scenarios described in
	Section 6.
	5. Secure Proxy ND Specification		5. Secure Proxy ND Specification
	A Secure Proxy ND performs all the operations described in the SEND		A Secure ND Proxy performs all the operations described in the SEND
	specification [RFC3971] with the addition of new processing rules to		specification [RFC3971] with the addition of new processing rules to
	ensure that the receiving node can differentiate between an		ensure that the receiving node can differentiate between an
	authorized proxy generating or forwarding a SEND message for a		authorized proxy generating or forwarding a SEND message for a
	proxied address, and a malicious node doing the same.		proxied address, and a malicious node doing the same.
	This is accomplished by signing the message with the public key of		This is accomplished by signing the message with the public key of
	the authorized Secure Proxy ND. The signature of the ND Proxy is		the authorized Secure ND Proxy. The signature of the ND Proxy is
	included in a new option called Proxy Signature option (PSO). The		included in a new option called Proxy Signature (PS) option. The
	signature is performed over all the NDP options present in the		signature is performed over all the NDP options present in the
	message and the PSO is appended as the last option in the message.		message and the PS option is appended as the last option in the
			message.
	5.1. Proxy Signature Option		5.1. Proxy Signature Option
	The Proxy Signature option allows public key-based signatures to be		The Proxy Signature option allows public key-based signatures to be
	attached to NDP messages. The format of the PSO is described in the		attached to NDP messages. The format of the PS option is described
	following diagram:		in the following diagram:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Key Hash |		| Key Hash |
	| |		| |
	| |		| |
	skipping to change at page 8, line 48		skipping to change at page 8, line 49
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .		. .
	. Padding .		. Padding .
	. .		. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: PSO layout		Figure 1: PS option layout
	Type		Type
	TBA		TBA
	Length		Length
	The length of the option (including the Type, Length, Reserved,		The length of the option (including the Type, Length, Reserved,
	Key Hash, Digital Signature, and Padding fields) in units of 8		Key Hash, Digital Signature, and Padding fields) in units of 8
	octets.		octets.
	skipping to change at page 10, line 23		skipping to change at page 10, line 23
	Padding		Padding
	This variable-length field contains padding. The length of the		This variable-length field contains padding. The length of the
	padding field is determined by the length of the Proxy Signature		padding field is determined by the length of the Proxy Signature
	Option minus the length of the other fields.		Option minus the length of the other fields.
	5.2. Modified SEND processing rules		5.2. Modified SEND processing rules
	The modifications described in the following section applies when a		The modifications described in the following section applies when a
	SEND message contains the Proxy Signature option (PSO), i.e. the		SEND message contains the PS option, i.e. the message was sent by a
	message was sent by a Secure Proxy ND.		Secure ND Proxy.
	This specification modifies the sender and receiver processing rules		This specification modifies the sender and receiver processing rules
	for the CGA and RSA options defined in the SEND specification		defined in the SEND specification [RFC3971].
	[RFC3971].
	5.2.1. Processing rules for senders		5.2.1. Processing rules for senders
	A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST		A ICMPv6 message sent by a Secure ND Proxy for a proxied address MUST
	contain a Proxy Signature option (PSO) and MUST NOT contain CGA and		contain a PS option and MUST NOT contain either CGA or RSA Signature
	RSA Signature options.		options.
	A Secure Proxy ND sending a SEND message with the PSO Signature		A Secure ND Proxy sending a SEND message with the PS option MUST
	option MUST construct the message as follows:		construct the message as follows:
	1. The SEND message is constructed without the PSO as follows:		1. The SEND message is constructed without the PS option as follows:
	A. If the Secure Proxy ND is locally generating the SEND message		A. If the Secure ND Proxy is locally generating the SEND message
	for a proxied address, the message MUST be constructed as		for a proxied address, the message MUST be constructed as
	described in Neighbor Discovery for IP version 6		described in Neighbor Discovery for IP version 6
	specification [RFC4861].		specification [RFC4861].
	B. If the Secure Proxy ND is forwarding a SEND message, first		B. If the Secure ND Proxy is forwarding a SEND message, first
	the authenticity of the intercepted message MUST be verified		the authenticity of the intercepted message MUST be verified
	as specified in SEND specification [RFC3971], Section 5. If		as specified in SEND specification [RFC3971], Section 5. If
	the SEND message is valid, any CGA or RSA option MUST be		the SEND message is valid, any CGA or RSA option MUST be
	removed from the message. The intercepted message is finally		removed from the message. The intercepted message is finally
	modified as described in Section 4 of the ND Proxy		modified as described in Section 4 of the ND Proxy
	specification [RFC4389].		specification [RFC4389].
	C. If the Secure Proxy ND is forwarding a SEND message already		C. If the Secure ND Proxy is forwarding a SEND message already
	containing a PSO, first the authenticity of the intercepted		containing a PS option, first the authenticity of the
	message is verified as specified in Section 5.2.2 of this		intercepted message is verified as specified in Section 5.2.2
	specification. If the SEND message is valid, the original		of this specification. If the SEND message is valid, the
	PSO MUST be removed from the message. The intercepted		original PS option MUST be removed from the message. The
	message is finally modified as described in Section 4 of the		intercepted message is finally modified as described in
	ND Proxy specification [RFC4389].		Section 4 of the ND Proxy specification [RFC4389].
	2. Timestamp and Nonce options MUST be included according to the		2. Timestamp and Nonce options MUST be included according to the
	rules specified in SEND [RFC3971]. The value in the Timestamp		rules specified in SEND [RFC3971]. The value in the Timestamp
	option MUST be generated by the Proxy. If the proxy is		option MUST be generated by the proxy. If the proxy is
	forwarding a message, the Nonce value in the proxied message MUST		forwarding a message, the Nonce value in the proxied message MUST
	be the same as in the forwarded message.		be the same as in the forwarded message, otherwise it is
			generated by the proxy.
	3. The Proxy Signature option MUST be added as the last option in		3. The Proxy Signature option MUST be added as the last option in
	the message.		the message.
	4. The data MUST be signed as explained in Section 5.1.		4. The data MUST be signed as explained in Section 5.1.
	5.2.2. Processing rules for receivers		5.2.2. Processing rules for receivers
	Any SEND message without a Proxy Signature option MUST be treated as		Any SEND message without a Proxy Signature option MUST be treated as
	specified in the SEND specification [RFC3971].		specified in the SEND specification [RFC3971].
	A SEND message including a Proxy Signature option MUST be processed		A SEND message including a Proxy Signature option MUST be processed
	as specified below:		as specified below:
	1. The receiver MUST ignore any RSA and CGA options, as well as any		1. The receiver MUST ignore any RSA and CGA options, as well as any
	options that might come after the first PSO. The options are		options that might come after the first PS option. The options
	ignored for both signature verification and NDP processing		are ignored for both signature verification and NDP processing
	purposes.		purposes.
	2. The Key Hash field MUST indicate the use of a known public key.		2. The Key Hash field MUST indicate the use of a known public key.
	A valid certification path (see [RFC3971] Section 6.3) between		A valid certification path (see [RFC3971] Section 6.3) between
	the receiver's trust anchor and the sender's public key MUST be		the receiver's trust anchor and the sender's public key MUST be
	known. The Secure Proxy ND's X509v3 certificate MUST contain a		known. The Secure Proxy ND's X509v3 certificate MUST contain a
	extended key usage extension including the KeyPurposeId value for		extended key usage extension including the KeyPurposeId value for
	the proxy authorization.		the proxy authorization.
	3. The Digital Signature field MUST have correct encoding.		3. The Digital Signature field MUST have correct encoding.
	4. The Digital Signature verification MUST show that the signature		4. The Digital Signature verification MUST show that the signature
	has been calculated as specified in Section 5.1.		has been calculated as specified in Section 5.1.
	5. Timestamp and Nonce options MUST be processed as specified in		5. The Nonce option MUST be processed as specified in [RFC3971]
	[RFC3971] Section 5.3.4, except for replacing 'RSA Signature		Section 5.3.4, except for replacing 'RSA Signature option' by 'PS
	option' by 'PSO option'.		option'.
	6. Messages with the Override bit [RFC4861] set MUST override an		6. The Timestamp option MUST be processed as specified in [RFC3971]
			Section 5.3.4, except for replacing 'RSA Signature option' by 'PS
			option'. The receiver SHOULD store the peer-related timing
			information specified in [RFC3971] Section 5.3.4.1 and 5.3.4.2
			(RDlast, TSlast) separately for each different proxy (which can
			be identified by the different Key Hash values of the proxied
			message) and separately from the timing information associated to
			the IP of node for which the message is proxied. In this way, a
			message received for the first time from a proxy (i.e. for which
			there is no information stored in the cache) for which the
			Timestamp option is checked, SHOULD be checked as messages
			received from new peers (as in [RFC3971] section 5.3.4.2).
			7. Messages with the Override bit [RFC4861] set MUST override an
	existing cache entry regardless if it was created as a result of		existing cache entry regardless if it was created as a result of
	a RSA Signature option or a PSO option validation. When the		a RSA Signature option or a PS option validation. When the
	Override bit is not set, the advertisement MUST NOT update a		Override bit is not set, the advertisement MUST NOT update a
	cached link-layer address created securily by means of RSA		cached link-layer address created securily by means of RSA
	Signature option or PSO option validation.		Signature option or PS option validation.
	Messages that do not pass all the above tests MUST be silently		Messages that do not pass all the above tests MUST be silently
	discarded if the host has been configured to accept only secured ND		discarded if the host has been configured to accept only secured ND
	messages.		messages.
	5.3. Proxying Link-Local Addresses		5.3. Proxying Link-Local Addresses
	Secure Neighbor Discovery [RFC3971] relies on certificates to prove		Secure Neighbor Discovery [RFC3971] relies on certificates to prove
	that routers are authorized to announce a certain prefix. However,		that routers are authorized to announce a certain prefix. However,
	Neighbor Discovery [RFC4861] states that router does not announce the		Neighbor Discovery [RFC4861] states that router does not announce the
	Link-Local prefix (fe80::/64). Hence, it is not required for a SEND		Link-Local prefix (fe80::/64). Hence, it is not required for a SEND
	certificate to hold a X.509 extension for IP addresses that		certificate to hold a X.509 extension for IP addresses that
	authorizes the fe80::/64 prefix. However, some scenarios ([RFC4389],		authorizes the fe80::/64 prefix. However, some Secure Proxy ND
	[RFC5213]) impose that the Secure ND proxy provides proxying function		scenarios ([RFC4389], [RFC5213]) impose providing the proxying
	for the Link-Local address of a node. When Secure ND proxy		function for the Link-Local address of a node. When Secure ND proxy
	functionality for a Link-Local address is required, either a list of		functionality for a Link-Local address is required, either a list of
	link-local addresses, or the fe80::/64 prefix MUST be explicitly		link-local addresses, or the fe80::/64 prefix MUST be explicitly
	authorized to be proxied in the corresponding certificate.		authorized to be proxied in the corresponding certificate.
	6. Application Scenarios		6. Application Scenarios
	In this section we describe three different application scenarios for		In this section we describe three different application scenarios for
	which Secure Proxy ND Support for SEND can be applied. Note that the		which Secure Proxy ND support for SEND can be applied. Note that the
	particular way in which Secure Proxy ND support is applied (which ND		particular way in which Secure Proxy ND support is applied (which ND
	messages are proxied, in which directions, how the interaction with		messages are proxied, in which directions, how the interaction with
	non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on		non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on
	the particular scenario considered. In the first two scenarios		the particular scenario considered. In the first two scenarios
	presented below, ND messages are synthesized on behalf of off-link		presented below, ND messages are synthesized on behalf of off-link
	nodes. In the third one, ND message generation is trigged by the		nodes. In the third one, ND message generation is trigged by the
	reception of ND messages in other interfaces of the proxy.		reception of ND messages in other interfaces of the proxy.
	6.1. Scenario 1: Mobile IPv6		6.1. Scenario 1: Mobile IPv6
	skipping to change at page 13, line 37		skipping to change at page 13, line 37
	intercepted by the Home Agent (HA) on that home link, encapsulated		intercepted by the Home Agent (HA) on that home link, encapsulated
	and tunneled to the MN's registered Care-of Address (CoA).		and tunneled to the MN's registered Care-of Address (CoA).
	The HA intercepts these packets acting as a ND proxy for this MN.		The HA intercepts these packets acting as a ND proxy for this MN.
	When a NS is intercepted on the home link, the HA checks if the		When a NS is intercepted on the home link, the HA checks if the
	Target address within the NS matches with any of the MN's Home		Target address within the NS matches with any of the MN's Home
	Address in the Binding Cache and if so, it replies with a Neighbor		Address in the Binding Cache and if so, it replies with a Neighbor
	Advertisement (NA) constructed as described in [RFC4861], containing		Advertisement (NA) constructed as described in [RFC4861], containing
	its own link layer address (HA_LL) as the Target Link Layer Address		its own link layer address (HA_LL) as the Target Link Layer Address
	Option (TLLAO). Then a timestamp (generated by the proxy) and nonce		Option (TLLAO). Then a timestamp (generated by the proxy) and nonce
	(if appropriate, acccording to [RFC3971]), MUST be included.		(if appropriate, according to [RFC3971]), MUST be included. Finally,
	Finally, a PSO option signing the message MUST be included as the		a PS option signing the message MUST be included as the last option
	last option of the message.		of the message.
	Node (N) Home Agent (HA) Mobile Node (MN)		Node (N) Home Agent (HA) Mobile Node (MN)
	on Home Link on Home Link on Foreign Link		on Home Link on Home Link on Foreign Link
	| | |		| | |
	| SRC = N | |		| SRC = N | |
	| DST = solicited_node(MN) | |		| DST = solicited_node(MN) | |
	| ICMPv6 NS | |		| ICMPv6 NS | |
	| TARGET = MN | |		| TARGET = MN | |
	| SLLAO = N_LL | |		| SLLAO = N_LL | |
	| [CGA] | |		| [CGA] | |
	| RSA signature | |		| RSA signature | |
	|------------------------->| |		|------------------------->| |
	| | |		| | |
	| SRC = HA | |		| SRC = HA | |
	| DST = N | |		| DST = N | |
	| ICMPv6 NA | |		| ICMPv6 NA | |
	| TARGET = MN | |		| TARGET = MN | |
	| TLLAO = HA_LL | |		| TLLAO = HA_LL | |
	| PSO signature | |		| PS signature | |
	|<-------------------------| |		|<-------------------------| |
	| | |		| | |
	| traffic | |		| traffic | |
	| dest= MN HoA | |		| dest= MN HoA | |
	|------------------------->| |		|------------------------->| |
	| | |		| | |
	| | tunnelled traffic |		| | tunnelled traffic |
	| | dest= MN CoA |		| | dest= MN CoA |
	| |------------------------->|		| |------------------------->|
	| | |		| | |
	Figure 2: Proxy ND role of the Home agent in MIPv6		Figure 2: Proxy ND role of the Home agent in MIPv6
	A node receiving the NA containing the PSO (e.g.: the CN in the home		A node receiving the NA containing the PS option (e.g.: the CN in the
	link, or a router) MUST apply the rules defined in Section 5.2.2.		home link, or a router) MUST apply the rules defined in
	Note that in this case the Override bit of the NA message is used to		Section 5.2.2. Note that in this case the Override bit of the NA
	control which messages should prevail each case: the message		message is used to control which messages should prevail each case:
	generated by the proxy once the MN moves from the home network, or		the message generated by the proxy once the MN moves from the home
	the MN if it comes back to the home link, as defined in the MIPv6		network, or the MN if it comes back to the home link, as defined in
	specification [RFC3775]		the MIPv6 specification [RFC3775]
	6.2. Scenario 2: Proxy Mobile IPv6		6.2. Scenario 2: Proxy Mobile IPv6
	Proxy Mobile IPv6 [RFC5213] is a network-based mobility management		Proxy Mobile IPv6 [RFC5213] is a network-based mobility management
	protocol that provides an IP mobility management support for MNs		protocol that provides an IP mobility management support for MNs
	without requiring MNs being involved in the mobility related		without requiring MNs being involved in the mobility related
	signaling. The IP mobility management is totally hidden to the MN in		signaling. The IP mobility management is totally hidden to the MN in
	a Proxy Mobile IPv6 domain and is performed by two functional		a Proxy Mobile IPv6 domain and is performed by two functional
	entities: the Local Mobility Anchor (LMA) and the Mobile Access		entities: the Local Mobility Anchor (LMA) and the Mobile Access
	Gateway (MAG).		Gateway (MAG).
	skipping to change at page 15, line 44		skipping to change at page 15, line 44
	| |<------------- PBA ---|		| |<------------- PBA ---|
	| | |		| | |
	| Accept PBA |		| Accept PBA |
	| | |		| | |
	| |==== Bi-Dir Tunnel ===|		| |==== Bi-Dir Tunnel ===|
	| | |		| | |
	| SRC = MAG4MN | |		| SRC = MAG4MN | |
	| DST = MN | |		| DST = MN | |
	| ICMPv6 RA | |		| ICMPv6 RA | |
	| SLL = MAG_LL | |		| SLL = MAG_LL | |
	| PSO | |		| PS | |
	|<---------------------| |		|<---------------------| |
	| | |		| | |
	| | |		| | |
	| | |		| | |
	Figure 3: Mobile node's handover in PMIPv6		Figure 3: Mobile node's handover in PMIPv6
	To avoid potential link-local address collisions between the MAG and		To avoid potential link-local address collisions between the MAG and
	the MN after a handoff to a new link, the Proxy Mobile IPv6		the MN after a handoff to a new link, the Proxy Mobile IPv6
	specification requires the MAG's link-local address configured on the		specification requires the MAG's link-local address configured on the
	link to which the MN is attached to, to be generated once by the LMA		link to which the MN is attached to, to be generated by the LMA when
	when the MN first attach to a PMIPv6 domain, and to be provided to		the MN first attach to a PMIPv6 domain, and to be provided to the new
	the new MN's serving MAG after each handoff. Thus, from the MN's		MN's serving MAG after each handoff. Thus, from the MN's point of
	point of view, the MAG's link-local address remains constant for the		view, the MAG's link-local address remains constant for the duration
	duration of that MN's session.		of that MN's session.
	The approach described above and the current SEND specification are		The approach described above and the current SEND specification are
	incompatible since sharing the same link-local address on different		incompatible since sharing the same link-local address on different
	MAGs would require all MAGs of a PMIPv6 domain to construct the CGA		MAGs would require all MAGs of a PMIPv6 domain to construct the CGA
	and the RSA Signature option with the same public-private key pair,		and the RSA Signature option with the same public-private key pair,
	which is not acceptable from a security point of view.		which is not acceptable from a security point of view.
	Using different public-private key pairs on different MAGs would mean		Using different public-private key pairs on different MAGs would mean
	different MAGs use different CGAs as link-local address. Thus the		different MAGs use different CGAs as link-local address. Thus the
	serving MAG's link-local address changes after each handoff of the MN		serving MAG's link-local address changes after each handoff of the MN
	skipping to change at page 16, line 38		skipping to change at page 16, line 38
	by means of a certificate associated to the PMIPv6 domain,		by means of a certificate associated to the PMIPv6 domain,
	authorizing each MAG to proxy securely ND messages. In addition, the		authorizing each MAG to proxy securely ND messages. In addition, the
	certificate must also authorize the MAG to advertise prefixes. Note		certificate must also authorize the MAG to advertise prefixes. Note
	that the inclusion of multiple KeyPurposeId values is supported by		that the inclusion of multiple KeyPurposeId values is supported by
	[I-D.ietf-csi-send-cert].		[I-D.ietf-csi-send-cert].
	When a MAG replies to a RS with a RA, the source address MUST be		When a MAG replies to a RS with a RA, the source address MUST be
	equal to the MAG link-local address associated to the MN in this		equal to the MAG link-local address associated to the MN in this
	PMIPv6 domain and its own link layer address as Source link-layer		PMIPv6 domain and its own link layer address as Source link-layer
	address. Then a timestamp (generated by the proxy) and nonce (if		address. Then a timestamp (generated by the proxy) and nonce (if
	appropriate, acccording to [RFC3971]), MUST be included. Finally, a		appropriate, according to [RFC3971]), MUST be included. Finally, a
	PSO option signing the message MUST be included as the last option of		PS option signing the message MUST be included as the last option of
	the message. This procedure is followed for any other ND message		the message. This procedure is followed for any other ND message
	that could be generated by the MAG to a MN.		that could be generated by the MAG to a MN.
	A node receiving a message from the MAG containing the PSO MUST apply		A node receiving a message from the MAG containing the PS option MUST
	the rules defined in Section 5.2.2.		apply the rules defined in Section 5.2.2. Note that unsolicited
			messages sent by MAG are validated by the host according to timestamp
			values specific to the MAG serving the link, not to any other MAG to
			which the host has been connected before in other links.
	6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy		6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy
	The description of the problems for deploying SEND in this scenario		The description of the problems for deploying SEND in this scenario
	can be found in [I-D.ietf-csi-sndp-prob].		can be found in [I-D.ietf-csi-sndp-prob].
	Link 1 Link 2		Link 1 Link 2
	Host A ND Proxy (P) Host B		Host A ND Proxy (P) Host B
	| | |		| | |
	skipping to change at page 18, line 18		skipping to change at page 18, line 25
	Address option - SLLAO, or a Target Local Link Address option -		Address option - SLLAO, or a Target Local Link Address option -
	TLLAO) is substituted with the link-layer address of the outgoing		TLLAO) is substituted with the link-layer address of the outgoing
	interface.		interface.
	2. Any CGA or RSA option MUST be removed.		2. Any CGA or RSA option MUST be removed.
	3. If a Nonce option existed in the original message, its value MUST		3. If a Nonce option existed in the original message, its value MUST
	be preserved in the proxied message. The Timestamp MUST be		be preserved in the proxied message. The Timestamp MUST be
	generated by the proxy.		generated by the proxy.
	4. The PSO option MUST be added as the last option in the message,		4. The PS option MUST be added as the last option in the message,
	signing all the information contained so far in the message.		signing all the information contained so far in the message.
	When any other IPv6 unicast packet is received on a proxy interface,		When any other IPv6 unicast packet is received on a proxy interface,
	if it is not locally destined then it is forwarded unchanged (other		if it is not locally destined then it is forwarded unchanged (other
	than using a new link-layer header) to the proxy interface for which		than using a new link-layer header) to the proxy interface for which
	the next hop address appears in the neighbor cache. If no neighbor		the next hop address appears in the neighbor cache. If no neighbor
	cache entry is present, the ND proxy should queue the packet and		cache entry is present, the ND proxy should queue the packet and
	initiate a Neighbor Discovery signalling as if the ICMPv6 NS message		initiate a Neighbor Discovery signalling as if the ICMPv6 NS message
	were locally generated.		were locally generated.
	In order to deploy this scenario, nodes in proxied segments MUST know		In order to deploy this scenario, nodes in proxied segments MUST know
	the certificate authorizing proxy operation. To do so it could be		the certificate authorizing proxy operation. To do so it could be
	required to configure at least one device per each proxied segment		required to configure at least one device per each proxied segment
	(may be the proxy itself) to propagate the required certification		(may be the proxy itself) to propagate the required certification
	path to authorize proxy operation by means of a CPS/CPA exchange.		path to authorize proxy operation by means of a CPS/CPA exchange.
	While more robust mechanisms could be developed for securing the
	scenario described in [RFC4389], if hosts have been upgraded to apply
	the rules stated in Section 5.2.2, for example to benefit from secure
	support for other scenarios, the application of this mechanism is
	straighforward.
	7. Backward Compatibility with RFC3971 nodes and non-SEND nodes		7. Backward Compatibility with RFC3971 nodes and non-SEND nodes
	In this section we discuss the interaction of Secure Proxy ND nodes		In this section we discuss the interaction of Secure ND Proxies and
	and SPND nodes with RFC3971 nodes and non-SEND nodes.		SPND nodes with RFC3971 nodes and non-SEND nodes.
	7.1. Backward Compatibility with RFC3971 nodes		7.1. Backward Compatibility with RFC3971 nodes
	RFC3971 nodes, i.e. SEND nodes not compliant with the modifications		RFC3971 nodes, i.e. SEND nodes not compliant with the modifications
	required in Section 5 cannot interpret correctly a PSO option		required in Section 5 cannot interpret correctly a PS option received
	received in a proxied ND message. These SEND nodes silently discard		in a proxied ND message. These SEND nodes silently discard the PS
	the PSO option, as specified in [RFC4861] for any unknown option. As		option, as specified in [RFC4861] for any unknown option. As a
	a result, these messages will be treated as unsecured as described in		result, these messages will be treated as unsecured as described in
	Section 8 "Transitions Issues" of the SEND specification [RFC3971].		Section 8 "Transitions Issues" of the SEND specification [RFC3971].
	When RFC3971 nodes and SPND nodes exchange ND messages (without proxy		When RFC3971 nodes and SPND nodes exchange ND messages (without proxy
	intervention), in either direction, messages are generated according		intervention), in either direction, messages are generated according
	to the SEND specification [RFC3971], so these nodes interoperate		to the SEND specification [RFC3971], so these nodes interoperate
	seamlessly.		seamlessly.
	In the scenarios in which the proxy translates ND messages, the		In the scenarios in which the proxy translates ND messages, the
	messages to translate can either be originated in a RFC3971 node or		messages to translate can either be originated in a RFC3971 node or
	in an SPND node, without interoperability issues.		in an SPND node, without interoperability issues.
	7.2. Backward Compatibility with non-SEND nodes		7.2. Backward Compatibility with non-SEND nodes
	Non-SEND nodes receiving NDP packets silently discard PSO options, as		Non-SEND nodes receiving NDP packets silently discard PS options, as
	specified in [RFC4861] for any unknown option. Therefore, these node		specified in [RFC4861] for any unknown option. Therefore, these
	interpret messages proxied by a Secure Proxy ND as any other ND		nodes interpret messages proxied by a Secure ND Proxy as any other ND
	message.		message.
	When non-SEND nodes and SPND nodes exchange ND messages (without		When non-SEND nodes and SPND nodes exchange ND messages (without
	proxy intervention), in either direction, the rules specified in		proxy intervention), in either direction, the rules specified in
	section 8 of [RFC3971] apply.		section 8 of [RFC3971] apply.
	A secure Proxy ND SHOULD support the use of secured and unsecured NDP		A Secure ND Proxy SHOULD support the use of secured and unsecured NDP
	messages at the same time, although it MAY have a configuration that		messages at the same time, although it MAY have a configuration that
	causes not to perform proxing for unsecured NDP messages. A secure		causes not to perform proxing for unsecured NDP messages. A Secure
	Proxy ND MAY also have a configuration option whereby it disables		ND Proxy MAY also have a configuration option whereby it disables
	secure ND proxying completely. This configuration SHOULD be switched		secure ND proxying completely. This configuration SHOULD be switched
	off by default, that is SEND is used. In the next paragraphs we		off by default, that is SEND is used by default. In the next
	discuss the recommended behavior of the Secure Proxy ND regarding to		paragraphs we discuss the recommended behavior of the Secure ND Proxy
	the protection level to provide to proxied messages in a mixed		regarding to the protection level to provide to proxied messages in a
	scenario involving SPND/RFC3971 nodes and non-SEND nodes. In		mixed scenario involving SPND/RFC3971 nodes and non-SEND nodes. In
	particular, two different situations occur depending on if the		particular, two different situations occur depending on if the
	proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes.		proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes.
	As a rule of thumb, if the proxied nodes can return to the link in		As a rule of thumb, if the proxied nodes can return to the link in
	which the proxy operates, the Secure Proxy ND MUST only generate PSO		which the proxy operates, the Secure ND Proxy MUST only generate PS
	options on behalf of nodes with SEND capabilities (i.e. that they		options on behalf of nodes with SEND capabilities (i.e. that they
	could use SEND to defend their messages if being in the same link		could use SEND to defend their messages if being in the same link
	than the proxy, either RFC3971 nodes or SPND nodes). This is		than the proxy, either RFC3971 nodes or SPND nodes). This is
	relevant to allow nodes preferring secured information over unsecured		relevant to allow nodes preferring secured information over unsecured
	one, and for executing the DAD procedure, as specified in [RFC3971].		one, and for executing the DAD procedure, as specified in [RFC3971].
	Therefore, the Secure Proxy ND MUST generate messages containing the		Therefore, the Secure ND Proxy MUST generate messages containing the
	PSO option for SPND and RFC3971 hosts, and MUST NOT generate messages		PS option for SPND and RFC3971 hosts, and MUST NOT generate messages
	containing the PSO option for non-SEND nodes. Note that ND		containing the PS option for non-SEND nodes. Note that ND
	advertisements in response to solicitations generated by a Secure		advertisements in response to solicitations generated by a Secure ND
	Proxy ND must be secured or not according to the previous		Proxy must be secured or not according to the previous considerations
	considerations (i.e. to the nature of the proxied node), and not		(i.e. to the nature of the proxied node), and not according to the
	according to the secure or unsecure nature of the solicitation		secure or unsecure nature of the solicitation message.
	message.
	To apply this rule, we have to consider that depending on the		To apply this rule, we have to consider that depending on the
	application scenario the proxy may translate ND messages generated by		application scenario the proxy may translate ND messages generated by
	a node or synthetise ND messages on behalf of a node that can return		a node or synthetise ND messages on behalf of a node that can return
	to the link in which the Secure Proxy ND operates.		to the link in which the Secure ND Proxy operates.
	o For translating ND messages for nodes that can arrive to the link		o For translating ND messages for nodes that can arrive to the link
	in which the proxy operates, the rule can be easily applied: only		in which the proxy operates, the rule can be easily applied: only
	messages validated in the Secure Proxy ND according to the SEND		messages validated in the Secure ND Proxy according to the SEND
	specification [RFC3971] MUST be proxied securely by the inclusion		specification [RFC3971] MUST be proxied securely by the inclusion
	of a PSO option. Unsecured ND messages could be proxied if		of a PS option. Unsecured ND messages could be proxied if
	unsecured operation is enabled in the proxy, but the message		unsecured operation is enabled in the proxy, but the message
	generated by the Secure Proxy ND for the received message MUST NOT		generated by the Secure ND Proxy for the received message MUST NOT
	include a PSO option.		include a PS option.
	o For synthesizing ND messages on behalf of remote nodes, different		o For synthesizing ND messages on behalf of remote nodes, different
	considerations should be made according to the particular		considerations should be made according to the particular
	application scenario.		application scenario.
	* For MIPv6, if the MN can return to the home link, it is		* For MIPv6, if the MN can return to the home link, it is
	required for the proxy to know if the node could use SEND to		required for the proxy to know if the node could use SEND to
	defend its address or not. A mismatch between the proxy and		defend its address or not. A mismatch between the proxy and
	proxied node behavior regarding to SEND operation would result		proxied node behavior regarding to SEND operation would result
	in unaproppriate operation. A HA including the PSO option for		in unaproppriate operation. A HA including the PS option for
	proxying a non-SEND MN would make ND messages sent by the proxy		proxying a non-SEND MN would make ND messages sent by the proxy
	to be more preferred than ND message of the non-SEND MN when		to be more preferred than ND message of the non-SEND MN when
	the MN returns to the home link (even if the proxied messages		the MN returns to the home link (even if the proxied messages
	have the Override bit set to 1). Not using the PSO option for		have the Override bit set to 1). Not using the PS option for a
	a RFC3971 or SPND MN would make more vulnerable the address in		RFC3971 or SPND MN would make more vulnerable the address in
	the home link when the MN is away than when it is in the home		the home link when the MN is away than when it is in the home
	link (and would defeat the purpose of the Secure Proxy ND		link (and would defeat the purpose of the Secure Proxy ND
	mechanism). Therefore, in this case the HA MUST know the SEND		mechanism). Therefore, in this case the HA MUST know the SEND
	capabilities of the MN, and MUST use PSO if the MN is a SPND or		capabilities of the MN, and MUST use PS option if the MN is a
	RFC3971 host, and MUST NOT use PSO for non-SEND hosts.		SPND or RFC3971 host, and MUST NOT use PS option for non-SEND
			hosts.
	* For the Proxy Mobile IPv6 scenario, we have to note that a node		* For the Proxy Mobile IPv6 scenario, we have to note that a node
	moving from a link in which PSO has been used to protect a		moving from a link in which PS option has been used to protect
	link-layer address to a link in which ND messages are not		a link-layer address to a link in which ND messages are not
	protected by SEND would prevent the MN from adquiring the new		protected by SEND would prevent the MN from adquiring the new
	information until the cached information expires. However, in		information until the cached information expires. However, in
	this case it is reasonable to consider that all MAGs provide		this case it is reasonable to consider that all MAGs provide
	the same security for protecting ND messages, and that either		the same security for protecting ND messages, and that either
	all MAGs will behave as Secure Proxy ND, or none, so		all MAGs will behave as Secure ND Proxy, or none, so
	configuration could be easier.		configuration could be easier.
	8. Security Considerations		8. Security Considerations
	The mechanism described in this document introduces a new Proxy		The mechanism described in this document introduces a new Proxy
	Signature Option (PSO) allowing a Secure Proxy ND to generate or		Signature (PS) Option allowing a Secure ND Proxy to generate or
	modify a SEND message for a proxied address. A SPND node will only		modify a SEND message for a proxied address. A SPND node will only
	accept such a message if it includes a valid PSO generated by an		accept such a message if it includes a valid PS option generated by
	authorized Secure Proxy ND. Such a message has equivalent protection		an authorized Secure ND Proxy. Such a message has equivalent
	to the threats presented in section 9 of [RFC3971] as a message		protection to the threats presented in section 9 of [RFC3971] as a
	signed with a RSA Signature option.		message signed with a RSA Signature option.
	The security of proxied ND messages not including a PSO option is the		The security of proxied ND messages not including a PS option is the
	same of an unsecured ND message. The security of a proxied ND		same of an unsecured ND message. The security of a proxied ND
	message received by a non-SEND host or RFC3971 host is the same of an		message received by a non-SEND host or RFC3971 host is the same of an
	unsecured ND message.		unsecured ND message.
	Thanks to the authorization certificate it is provisioned with, a		Thanks to the authorization certificate it is provisioned with, a
	proxy ND is authorized to issue ND signaling on behalf of nodes on		proxy ND is authorized to issue ND signaling on behalf of nodes on
	the subnet. Thus, a compromised proxy is able, like a compromised		the subnet. Thus, a compromised proxy is able, like a compromised
	router, to siphon off traffic from the host, or mount a man-in-the-		router, to siphon off traffic from the host, or mount a man-in-the-
	middle attack. However, when two on-link hosts communicate using		middle attack. However, when two on-link hosts communicate using
	their respective link-local addresses, the threats involved with a		their respective link-local addresses, the threats involved with a
	compromised router and a compromised proxy ND differs because the		compromised router and a compromised proxy ND differs because the
	router is not able to siphon off traffic exchanged between the hosts		router is not able to siphon off traffic exchanged between the hosts
	or mount a man-in-the-middle attack, while the proxy ND can, even if		or mount a man-in-the-middle attack, while the proxy ND can, even if
	the hosts use SEND.		the hosts use SEND.
	The messages for which a Secure Proxy ND performs its function, and		The messages for which a Secure ND Proxy performs its function, and
	the link for which this function is performed MUST be configured		the link for which this function is performed MUST be configured
	appropriately for each proxy and scenario. This configuration is		appropriately for each proxy and scenario. This configuration is
	specially relevant if Secure Proxy ND is used for translating ND		specially relevant if Secure Proxy ND is used for translating ND
	messages from one link to another.		messages from one link to another.
	Proper configuration of when the PSO option must or must not be		Proper configuration of when the PS option must or must not be
	included, depending on the proxied nodes being SEND or non-SEND may		included, depending on the proxied nodes being SEND or non-SEND may
	result in security considerations which are discussed in Section 7.		result in security considerations which are discussed in Section 7.
	Attacks to the timestamp of the secured ND message can be performed		Attacks to the timestamp of the secured ND message can be performed
	as described in section 7.3 of [I-D.ietf-csi-sndp-prob].		as described in section 7.3 of [I-D.ietf-csi-sndp-prob].
	9. IANA Considerations		9. IANA Considerations
	IANA is requested to allocate:		IANA is requested to allocate:
	A new IPv6 Neighbor Discovery Option type for the PSO, as TBA.		A new IPv6 Neighbor Discovery Option type for the PS option, as
	The value need to be allocated from the namespace specified in the		TBA. The value need to be allocated from the namespace specified
	IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at		in the IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS
	http://www.iana.org/assignments/icmpv6-parameters.		located at http://www.iana.org/assignments/icmpv6-parameters.
	A new 128-bit value under the CGA Message Type [RFC3972]		A new 128-bit value under the CGA Message Type [RFC3972]
	namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.		namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.
	10. References		10. Acknowledgements
	10.1. Normative References		The text has benefited from feedback provided by Jari Arkko, Jean-
			Michel Combes, Roque Gagliano, Tony Cheneau and Marcelo Bagnulo.
			11. References
			11.1. Normative References
	[I-D.ietf-csi-send-cert]		[I-D.ietf-csi-send-cert]
	Gagliano, R., Krishnan, S., and A. Kukec, "Certificate		Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
	profile and certificate management for SEND",		profile and certificate management for SEND",
	draft-ietf-csi-send-cert-03 (work in progress),		draft-ietf-csi-send-cert-03 (work in progress),
	March 2010.		March 2010.
	[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.
	skipping to change at page 24, line 46		skipping to change at page 25, line 46
	[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,		[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
	and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.		and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
	[RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1",		[RSA] RSA Laboratories, "RSA Encryption Standard, Version 2.1",
	PKCS 1 , November 2002.		PKCS 1 , November 2002.
	[SHA1] National Institute of Standards and Technology, "Secure		[SHA1] National Institute of Standards and Technology, "Secure
	Hash Standard", FIPS PUB 180-1 , April 1995.		Hash Standard", FIPS PUB 180-1 , April 1995.
	10.2. Informative References		11.2. Informative References
	[I-D.ietf-csi-sndp-prob]		[I-D.ietf-csi-sndp-prob]
	Combes, J., Krishnan, S., and G. Daley, "Securing Neighbor		Combes, J., Krishnan, S., and G. Daley, "Securing Neighbor
	Discovery Proxy: Problem Statement",		Discovery Proxy: Problem Statement",
	draft-ietf-csi-sndp-prob-04 (work in progress),		draft-ietf-csi-sndp-prob-04 (work in progress),
	January 2010.		January 2010.
			[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
			Discovery (ND) Trust Models and Threats", RFC 3756,
			May 2004.
	Authors' Addresses		Authors' Addresses
	Suresh Krishnan		Suresh Krishnan
	Ericsson		Ericsson
	8400 Decarie Blvd.		8400 Decarie Blvd.
	Town of Mount Royal, QC		Town of Mount Royal, QC
	Canada		Canada
	Phone: +1 514 345 7900 x42871		Phone: +1 514 345 7900 x42871
	Email: suresh.krishnan@ericsson.com		Email: suresh.krishnan@ericsson.com
End of changes. 76 change blocks.
	167 lines changed or deleted		180 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/