draft-ietf-csi-proxy-send-02.txt		draft-ietf-csi-proxy-send-03.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: Standards Track QUALCOMM Inc.
	Expires: September 4, 2010 M. Bonola		Expires: September 23, 2010 M. Bonola
	Rome Tor Vergata University		Rome Tor Vergata University
	A. Garcia-Martinez		A. Garcia-Martinez
	UC3M		UC3M
	March 3, 2010		March 22, 2010
	Secure Proxy ND Support for SEND		Secure Proxy ND Support for SEND
	draft-ietf-csi-proxy-send-02		draft-ietf-csi-proxy-send-03
	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 send, 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 support 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 to IETF 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), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 4, 2010.		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
	skipping to change at page 2, line 34		skipping to change at page 2, line 34
	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 . . . . . . . . . . . . . . 15		6.2. Scenario 2: Proxy Mobile IPv6 . . . . . . . . . . . . . . 14
	6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 17		6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy . . . . . . 16
	7. Backward Compatibility with RFC3971 nodes and non-SEND		7. Backward Compatibility with RFC3971 nodes and non-SEND
	nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 20		7.1. Backward Compatibility with RFC3971 nodes . . . . . . . . 19
	7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 20		7.2. Backward Compatibility with non-SEND nodes . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 23		8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 25		10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
	10.2. Informative References . . . . . . . . . . . . . . . . . . 25		10.2. Informative References . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
	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
	skipping to change at page 6, line 22		skipping to change at page 6, line 22
	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.
	To be able to separate the roles of ownership and advertiser the		To be able to separate the roles of ownership and advertiser the
	following extensions to the SEND protocol are defined:		following extensions to the SEND protocol are defined:
	o A Secure Proxy ND certificate, which is a certificate authorizing		o A Secure Proxy ND certificate, which is a certificate authorizing
	an entity to act as an ND proxy. It is a X509v3 certificate in		an entity to act as an ND proxy. It is a X509v3 certificate in
	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 as a		the same certificate. This certificate can be exchanged through
	result of the Authorization Delegation Discovery process defined		the Authorization Delegation Discovery process defined in
	in [RFC3971].		[RFC3971].
	o A new Neighbor Discovery option called Proxy Signature option		o A new Neighbor Discovery option called Proxy Signature option
	(PSO). This option contains the hash value of the public key of		(PSO). 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 PSO, it MUST
	NOT contain CGA and RSA Signature options. This option can be		NOT contain CGA and RSA Signature options. This option can be
	appended to any ND message: NA, NS, RS, RA and Redirect.		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 is		NA, NS, RS, RA, and Redirect. When any of these messages
	received with a valid Proxy Signature option, it is considered as		containing a valid Proxy Signature option is validated, it is
	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 Proxy ND which proxies ND messages on behalf of a node
	can use the PSO option to protect the proxied messages. This		can use the PSO option to protect the proxied messages. This
	Secure Proxy ND becomes part of the trusted infrastructure just		Secure Proxy ND 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 know the Secure Proxy ND certificate (in		messages, the nodes must be aware of the Secure Proxy ND
	the format described in [I-D.ietf-csi-send-cert]) and must apply		certificate (in the format described in [I-D.ietf-csi-send-cert])
	the modified processing rules specified in this document. We call		and must apply the modified processing rules specified in this
	this nodes 'SPND nodes'. Note that the rules for generating ND		document. We call these nodes 'SPND nodes'. Note that the rules
	messages in SPND nodes do not change, so these nodes behave as		for generating ND messages in SPND nodes do not change, so these
	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] must handle the certificate format specified in
	[I-D.ietf-csi-send-cert], and must be configured with the		[I-D.ietf-csi-send-cert], and must be configured with the
	appropriate certification path.		appropriate certification path.
	The proposed approach resolves the incompatibilities between the		The proposed approach resolves the incompatibilities between the
	current SEND specification and the application scenarios described in		current SEND specification and the application scenarios described in
	Section 6.		Section 6.
	5. Secure Proxy ND Specification		5. Secure Proxy ND Specification
	A Secure Proxy ND performs all the operation described in the SEND		A Secure Proxy ND 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 Proxy ND. 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 option (PSO). 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 PSO is appended as the last option in the message.
	skipping to change at page 9, line 17		skipping to change at page 9, line 17
	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.
	Reserved		Reserved
	A 11-bit field reserved for future use. The value MUST be		A 16-bit field reserved for future use. The value MUST be
	initialized to zero by the sender, and MUST be ignored by the		initialized to zero by the sender, and MUST be ignored by the
	receiver.		receiver.
	Key Hash		Key Hash
	A 128-bit field containing the most significant (leftmost) 128		A 128-bit field containing the most significant (leftmost) 128
	bits of a SHA-1 [SHA1] hash of the public key used for		bits of a SHA-1 [SHA1] hash of the public key used for
	constructing the signature. Its purpose is to associate the		constructing the signature. Its purpose is to associate the
	signature to a particular key known by the receiver. Such a key		signature to a particular key known by the receiver. Such a key
	MUST be the same one within the corresponding Secure Proxy ND's		MUST be the same one within the corresponding Secure Proxy ND's
	skipping to change at page 10, line 42		skipping to change at page 10, line 42
	A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST		A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST
	contain a Proxy Signature option (PSO) and MUST NOT contain CGA and		contain a Proxy Signature option (PSO) and MUST NOT contain CGA and
	RSA Signature options.		RSA Signature options.
	A Secure Proxy ND sending a SEND message with the PSO Signature		A Secure Proxy ND sending a SEND message with the PSO Signature
	option MUST construct the message as follows:		option MUST construct the message as follows:
	1. The SEND message is constructed without the PSO as follows:		1. The SEND message is constructed without the PSO as follows:
	A. If the Secure Proxy ND is locally generating the SEND message		A. If the Secure Proxy ND is locally generating the SEND message
	for a proxied address, the message is 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 Proxy ND is forwarding a SEND message, first
	the authenticity of the intercepted message is verified as		the authenticity of the intercepted message MUST be verified
	specified in SEND specification [RFC3971], Section 5. If the		as specified in SEND specification [RFC3971], Section 5. If
	SEND message is valid, any CGA or RSA option MUST be removed		the SEND message is valid, any CGA or RSA option MUST be
	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 Proxy ND is forwarding a SEND message already
	containing a PSO, first the authenticity of the intercepted		containing a PSO, first the authenticity of the intercepted
	message is verified as specified in Section 6.2.2 of this		message is verified as specified in Section 5.2.2 of this
	draft. If the SEND message is valid, the original PSO MUST		specification. If the SEND message is valid, the original
	be removed from the message. The intercepted message is		PSO MUST be removed from the message. The intercepted
	finally modified as described in Section 4 of the ND Proxy		message is finally modified as described in Section 4 of the
	specification[RFC4389].		ND Proxy specification [RFC4389].
	2. Timestamp and Nonce options are included according to the rules		2. Timestamp and Nonce options MUST be included according to the
	specified in SEND [RFC3971]. The value in the Timestamp option		rules specified in SEND [RFC3971]. The value in the Timestamp
	MUST be generated by the Proxy. If the proxy is forwarding a		option MUST be generated by the Proxy. If the proxy is
	message, the Nonce value in the proxied message MUST be the same		forwarding a message, the Nonce value in the proxied message MUST
	as in the forwarded message.		be the same as in the forwarded message.
	3. The Proxy Signature option is added as the last option in the		3. The Proxy Signature option MUST be added as the last option in
	message.		the message.
	4. The data is 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
	skipping to change at page 12, line 5		skipping to change at page 12, line 5
	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. Timestamp and Nonce options MUST be processed as specified in
	[RFC3971] Section 5.3.4, except for replacing 'RSA Signature		[RFC3971] Section 5.3.4, except for replacing 'RSA Signature
	option' by 'PSO option'.		option' by 'PSO option'.
	6. Messages with the Override bit [RFC4861] set should override an		6. 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 it is		a RSA Signature option or a PSO option validation. When the
	not set the advertisement will not update a cached link-layer		Override bit is not set, the advertisement MUST NOT update a
	address created securily by means of RSA Signature option or PSO		cached link-layer address created securily by means of RSA
	option validation.		Signature option or PSO 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 IP address extensions that authorizes the		certificate to hold a X.509 extension for IP addresses that
	fe80::/64 prefix. Some scenarios ([RFC4389], [RFC5213]) impose that		authorizes the fe80::/64 prefix. However, some scenarios ([RFC4389],
	the Secure ND proxy provides proxying function for the Link-Local		[RFC5213]) impose that the Secure ND proxy provides proxying function
	address of a node. When Secure ND proxy functionality on a Link-		for the Link-Local address of a node. When Secure ND proxy
	Local address is required, either a list of link-local addresses, or		functionality for a Link-Local address is required, either a list of
	the fe80::/64 prefix MUST be explicitly authorized to be proxied in		link-local addresses, or the fe80::/64 prefix MUST be explicitly
	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 messages are generated in reaction to ND		nodes. In the third one, ND message generation is trigged by the
	messages being received by other interfaces of the proxied node.		reception of ND messages in other interfaces of the proxy.
	6.1. Scenario 1: Mobile IPv6		6.1. Scenario 1: Mobile IPv6
	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].
	The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a Mobile Node (MN)		The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a Mobile Node (MN)
	to move from one link to another while maintaining reachability at a		to move from one link to another while maintaining reachability at a
	stable address, the so-called MN's Home Address (HoA). When a MN		stable address, the so-called MN's Home Address (HoA). When a MN
	attaches to a foreign network, all the packets sent to the MN's HoA		attaches to a foreign network, all the packets sent to the MN's HoA
	by a Correspondent Node (CN) on the home link, or a router, are		by a Correspondent Node (CN) on the home link or a router, are
	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.
	Lets assume that the nodes in the home link use SEND. When a secured		When a NS is intercepted on the home link, the HA checks if the
	NS is intercepted on the home link, the HA checks the validity of the		Target address within the NS matches with any of the MN's Home
	received message according to the rules stated in [RFC3971]. If the		Address in the Binding Cache and if so, it replies with a Neighbor
	message is valid, it checks if the Target address within the NS		Advertisement (NA) constructed as described in [RFC4861], containing
	matches with any of the MN's Home Address in the Binding Cache and if		its own link layer address (HA_LL) as the Target Link Layer Address
	so, it replies with a Neighbor Advertisement (NA) constructed as		Option (TLLAO). Then a timestamp (generated by the proxy) and nonce
	described in [RFC4861], so it contains its own link layer address		(if appropriate, acccording to [RFC3971]), MUST be included.
	(HA_LL) as the Target Link Layer Address Option (TLLAO), with a PSO		Finally, a PSO option signing the message MUST be included as the
	option signing the message, added as the last option of the message.		last option 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] | |
	skipping to change at page 14, line 37		skipping to change at page 14, line 37
	|------------------------->| |		|------------------------->| |
	| | |		| | |
	| | 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 PSO (e.g.: the CN in the home
	link, or a router) must have a certificate of the public key of the		link, or a router) MUST apply the rules defined in Section 5.2.2.
	HA acting as a Secure Proxy ND. To do so, a certificate for the HA		Note that in this case the Override bit of the NA message is used to
	could be made available through the Authorization Delegation		control which messages should prevail each case: the message
	Discovery process [RFC3971] performed at the home link, i.e. the		generated by the proxy once the MN moves from the home network, or
	devices responding to CPS messages should be configured to include in		the MN if it comes back to the home link, as defined in the MIPv6
	CPA messages information about the HA certificate.		specification [RFC3775]
	The Override bit of the NA message is used to control which messages
	should prevail each case: the message generated by the proxy once the
	MN moves from the home network, or the MN if it come back to the home
	link, as defined in 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).
	When the MN connects to a new access link it will send a multicast		When the MN connects to a new access link, it will send a multicast
	ICMPv6 Router Solicitation (RS). The MAG on the new access link,		ICMPv6 Router Solicitation (RS). The MAG on the new access link,
	upon detecting the MN's attachment, will signal the LMA for updating		upon detecting the MN's attachment, will signal the LMA for updating
	the binding state of the MN (Proxy Binding Update - PBU) and once the		the binding state of the MN (Proxy Binding Update - PBU) and once the
	signaling is complete (it receives a Proxy Binding Ack - PBA), it		signaling is completed (it receives a Proxy Binding Ack - PBA), it
	will reply to the MN with a ICMPv6 Router Advertisement (RA)		will reply to the MN with a ICMPv6 Router Advertisement (RA)
	containing the home network prefix(es) that were assigned to that		containing the home network prefix(es) that were assigned to that
	mobility session, making the MN believe it is still on the same link		mobility session, making the MN believe it is still on the same link
	and not triggering the IPv6 address reconfiguration (figure		and not triggering the IPv6 address reconfiguration (Figure 3).
	Figure 3).
	MN new MAG LMA		MN new MAG LMA
	| | |		| | |
	MN Attached | |		MN Attached | |
	| | |		| | |
	| MN Attached Event from MN/Network |		| MN Attached Event from MN/Network |
	| | |		| | |
	| SRC = MN | |		| SRC = MN | |
	| DST = all-routers | |		| DST = all-routers | |
	| ICMPv6 RS | |		| ICMPv6 RS | |
	skipping to change at page 16, line 49		skipping to change at page 16, line 15
	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 once by the LMA
	when the MN first attach to a PMIPv6 domain, and to be provided to		when the MN first attach to a PMIPv6 domain, and to be provided to
	the new MN's serving MAG after each handoff. Thus, from the MN's		the new MN's serving MAG after each handoff. Thus, from the MN's
	point of view, the MAG's link-local address remains constant for the		point of view, the MAG's link-local address remains constant for the
	duration of that MN's session.		duration of that MN's session.
	Each MAG can be granted a certificate per each link-local address		The approach described above and the current SEND specification are
	expected by any MN that could attach to the link. However, the use		incompatible since sharing the same link-local address on different
	of Secure Proxy ND can greatly reduce the number of certificates		MAGs would require all MAGs of a PMIPv6 domain to construct the CGA
	needed. In this case, each MAG is configured to act as a proxy by		and the RSA Signature option with the same public-private key pair,
	means of a certification path from a trust anchor associated to the		which is not acceptable from a security point of view.
	PMIPv6 domain, authorizing each MAG to proxy securely ND messages.
	When a secured RS message is issued by the MN, the MAG checks its		Using different public-private key pairs on different MAGs would mean
	validity according to the rules stated in [RFC3971]. If the message		different MAGs use different CGAs as link-local address. Thus the
	is valid, it replies with a RA with source address equal to the MAG		serving MAG's link-local address changes after each handoff of the MN
	link-local address associated to the MN in this PMIPv6 domain and its		which is contradiction with the way MAG link-local address assignment
	own link layer address as Source link-layer address, with the PSO		occurs in a PMIPv6 domain.
	option signing the message, added as the last option of the message.
	When the MN receives this message, it may issue a CPS message in		To provide SEND protection, each MAG is configured to act as a proxy
	order to obtain the certification path associated to the public key		by means of a certificate associated to the PMIPv6 domain,
	of the PSO (or may have this certification path already available).		authorizing each MAG to proxy securely ND messages. In addition, the
	The MN node must be configured with a trust anchor related with the		certificate must also authorize the MAG to advertise prefixes. Note
	MAG's certificate. The MAG (or other device) could be configured to		that the inclusion of multiple KeyPurposeId values is supported by
	provide its certification path in a CPS message as a response to a		[I-D.ietf-csi-send-cert].
	CPA message issued by the MN. With this information, the MN can
	validate the RS information, and use the same link-local address to
	access to the MAG.
	The MAG will intercept secured NS messages and reply with NA messages		When a MAG replies to a RS with a RA, the source address MUST be
	containing its own link layer address as the Target Link Layer		equal to the MAG link-local address associated to the MN in this
	Address Option (TLLAO), with a PSO option signing the message, added		PMIPv6 domain and its own link layer address as Source link-layer
	as the last option of the message. The same applies for Redirect		address. Then a timestamp (generated by the proxy) and nonce (if
	messages.		appropriate, acccording to [RFC3971]), MUST be included. Finally, a
			PSO option signing the message MUST be included as the last option of
			the message. This procedure is followed for any other ND message
			that could be generated by the MAG to a MN.
			A node receiving a message from the MAG containing the PSO MUST apply
			the rules defined in Section 5.2.2.
	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 47		skipping to change at page 17, line 47
	The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a		The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
	method by which multiple link layer segments are bridged into a		method by which multiple link layer segments are bridged into a
	single segment and specifies the IP-layer support that enables		single segment and specifies the IP-layer support that enables
	bridging under these circumstances.		bridging under these circumstances.
	A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy		A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy
	interface to check whether it contains one of the following secured		interface to check whether it contains one of the following secured
	ICMPv6 messages: NS, NA, RA, or Redirect. The Secure ND Proxy MUST		ICMPv6 messages: NS, NA, RA, or Redirect. The Secure ND Proxy MUST
	verify the authenticity of the received ND message, according to		verify the authenticity of the received ND message, according to
	[RFC3971]. If the SEND message is valid, then it proxied the		[RFC3971]. If the SEND message is valid, then it proxies the
	original message with the following changes:		original message with the following changes:
	1. The message is processed according to [RFC4389]. This includes		1. The message MUST be processed according to [RFC4389]. This
	changing the source link layer address will be the address of the		includes changing the source link layer address to the address of
	outgoing interface, maintaining the destination link layer		the outgoing interface, maintaining the destination link layer
	address as the address in the neighbor entry corresponding to the		address as the address in the neighbor entry corresponding to the
	destination IPv6 address, etc. In particular any link layer		destination IPv6 address, etc. In particular any link layer
	address within the payload (that is, in a Source Local Link		address within the payload (that is, in a Source Local Link
	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 is removed.		2. Any CGA or RSA option MUST be removed.
	3. If a Nonce option existed in the original message, its value is		3. If a Nonce option existed in the original message, its value MUST
	preserved in the proxied message. The Timestamp is generated by		be preserved in the proxied message. The Timestamp MUST be
	the proxy.		generated by the proxy.
	4. The PSO option is added as the last option in the message,		4. The PSO 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.
	Moreover, when any other IPv6 unicast packet is received on a proxy		When any other IPv6 unicast packet is received on a proxy interface,
	interface, if it is not locally destined then it is forwarded		if it is not locally destined then it is forwarded unchanged (other
	unchanged (other than using a new link-layer header) to the proxy		than using a new link-layer header) to the proxy interface for which
	interface for which the next hop address appears in the neighbor		the next hop address appears in the neighbor cache. If no neighbor
	cache. If no neighbor cache entry is present, the ND proxy should		cache entry is present, the ND proxy should queue the packet and
	queue the packet and initiate a Neighbor Discovery signalling as if		initiate a Neighbor Discovery signalling as if the ICMPv6 NS message
	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		While more robust mechanisms could be developed for securing the
	scenario described in [RFC4389], if hosts have been upgraded to apply		scenario described in [RFC4389], if hosts have been upgraded to apply
	the rules stated in Section 5.2.2, for example, to benefit from		the rules stated in Section 5.2.2, for example to benefit from secure
	secure support for other scenarios, the application of this mechanism		support for other scenarios, the application of this mechanism is
	is straighforward.		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 Proxy ND nodes
	and SPND nodes with RFC3971 nodes and non-SEND nodes.		and 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 PSO option
	skipping to change at page 20, line 30		skipping to change at page 19, line 30
	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
	Plain ND nodes receiving NDP packets silently discard PSO options, as		Non-SEND nodes receiving NDP packets silently discard PSO options, as
	specified in [RFC4861] for any unknown option. Therefore, these node		specified in [RFC4861] for any unknown option. Therefore, these node
	interpret messages proxied by a Secure Proxy ND as any other ND		interpret messages proxied by a Secure Proxy ND 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 Proxy ND 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		Proxy ND 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. In the next paragraphs we
	discuss the recommended behavior of the Secure Proxy ND regarding to		discuss the recommended behavior of the Secure Proxy ND regarding to
	which protection level provide to proxied messages in a mixed		the protection level to provide to proxied messages in a mixed
	scenario involving SPND/RFC3971 nodes and non-SEND nodes. In		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, the Secure Proxy ND should only generate PSO		As a rule of thumb, if the proxied nodes can return to the link in
	options for nodes which have SEND capabilities (i.e. that they could		which the proxy operates, the Secure Proxy ND MUST only generate PSO
	use SEND to defend their messages if being in the same link than the		options on behalf of nodes with SEND capabilities (i.e. that they
	proxy, either RFC3971 nodes or SPND nodes). This is relevant to		could use SEND to defend their messages if being in the same link
	allow nodes preferring secured information over unsecured one, and		than the proxy, either RFC3971 nodes or SPND nodes). This is
	for executing the DAD procedure, as specified in [RFC3971].		relevant to allow nodes preferring secured information over unsecured
	Therefore, the Secure Proxy ND SHOULD generate messages containing		one, and for executing the DAD procedure, as specified in [RFC3971].
	the PSO option for SPND and RFC3971 hosts, and SHOULD NOT generate		Therefore, the Secure Proxy ND MUST generate messages containing the
	messages containing the PSO option for non-SEND nodes. Note that ND		PSO option for SPND and RFC3971 hosts, and MUST NOT generate messages
			containing the PSO 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
	Proxy ND must be secured or not according to the previous		Proxy ND must be secured or not according to the previous
	considerations (i.e. to the nature of the proxied node), and not		considerations (i.e. to the nature of the proxied node), and not
	according to the secure or unsecure nature of the solicitation		according to the 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.		a node or synthetise ND messages on behalf of a node that can return
			to the link in which the Secure Proxy ND operates.
	o For ND translated messages, the rule can be easily applied: only		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
	messages validated in the Secure Proxy ND according to the SEND		messages validated in the Secure Proxy ND 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 PSO 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 Proxy ND for the received message MUST NOT
	include a PSO option.		include a PSO option.
	o For ND messages synthesised 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 PSO 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 if the		to be more preferred than ND message of the non-SEND MN when
	MN returns to the home link (even if the proxied messages have		the MN returns to the home link (even if the proxied messages
	the Override bit set to 1). Not using the PSO option for a		have the Override bit set to 1). Not using the PSO option for
	RFC3971 or SPND MN would make more vulnerable the address in		a 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.		capabilities of the MN, and MUST use PSO if the MN is a SPND or
			RFC3971 host, and MUST NOT use PSO for non-SEND hosts.
	* We can state the same for the Proxy Mobile IPv6 scenario as for		* For the Proxy Mobile IPv6 scenario, we have to note that a node
	the MIPv6 scenario. Note that a node moving from a link in		moving from a link in which PSO has been used to protect a
	which PSO has been used to protect a link-layer address to a		link-layer address to a link in which ND messages are not
	link in which ND messages are not SEND-enabled would prevent		protected by SEND would prevent the MN from adquiring the new
	the node from adquiring the new information until the		information until the cached information expires. However, in
	corresponding cache expires. However, in this case it is		this case it is reasonable to consider that all MAGs provide
	reasonable to consider that all MAGs provide the same security		the same security for protecting ND messages, and that either
	for protecting ND messages, and that either all MAGs will		all MAGs will behave as Secure Proxy ND, or none, so
	behave as Secure Proxy ND, or none, so configuration could be		configuration could be easier.
	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 Option (PSO) allowing a Secure Proxy ND to generate or
	modify a SEND message for a proxied address. An 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 PSO generated by an
	authorized Secure Proxy ND. Such a message has equivalent protection		authorized Secure Proxy ND. Such a message has equivalent protection
	to the threats presented in section 9 of [RFC3971] as a message		to the threats presented in section 9 of [RFC3971] as a message
	signed with a RSA Signature option.		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 PSO 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.
	skipping to change at page 23, line 31		skipping to change at page 22, line 31
	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 perform its function, and		The messages for which a Secure Proxy ND 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 PSO option must or must not be
	included, depending on the proxied node being SEND or non-SEND may		included, depending on the proxied nodes being SEND or non-SEND may
	result in security considerations, as 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 describe 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 PSO, as TBA.
	The value need to be allocated from the namespace specified in the		The value need to be allocated from the namespace specified in the
	IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at		IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at
	http://www.iana.org/assignments/icmpv6-parameters.		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. References
	10.1. Normative References		10.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-02 (work in progress),		draft-ietf-csi-send-cert-03 (work in progress),
	February 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.
	[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
End of changes. 55 change blocks.
	171 lines changed or deleted		169 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/