base.txt		issue51.txt
Secure Neighbor Discovery Working J. Arkko		Secure Neighbor Discovery Working J. Arkko, Editor
Group Ericsson		Group Ericsson
Internet-Draft J. Kempf		Internet-Draft J. Kempf
Expires: July 1, 2004 DoCoMo Communications Labs USA		Expires: July 1, 2004 DoCoMo Communications Labs USA
B. Sommerfeld		B. Sommerfeld
Sun Microsystems		Sun Microsystems
B. Zill		B. Zill
Microsoft		Microsoft
P. Nikander		P. Nikander
Ericsson		Ericsson
January 2004		January 2004
Skipping to change at page 1, line 48:
This Internet-Draft will expire on July 1, 2004.		This Internet-Draft will expire on July 1, 2004.
Copyright Notice		Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract		Abstract
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover		IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine the link-layer addresses of the		other nodes on the link, to determine the link-layer addresses of
nodes on the link, to find routers, and to maintain reachability		other nodes on the link, to find routers, and to maintain
information about the paths to active neighbors. If not secured, NDP		reachability information about the paths to active neighbors. If not
is vulnerable to various attacks. This document specifies security		secured, NDP is vulnerable to various attacks. This document
mechanisms for NDP. Unlike to the original NDP specifications, these		specifies security mechanisms for NDP. Unlike to the original NDP
mechanisms do not make use of IPsec.		specifications, these mechanisms do not make use of IPsec.
Table of Contents		Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . . 4		1.1 Specification of Requirements . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7		3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9		4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11		5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11
5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11		5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11
Skipping to change at page 2, line 28:
5.1.2 Processing Rules for Receivers . . . . . . . . 13		5.1.2 Processing Rules for Receivers . . . . . . . . 13
5.1.3 Configuration . . . . . . . . . . . . . . . . 14		5.1.3 Configuration . . . . . . . . . . . . . . . . 14
5.2 Signature Option . . . . . . . . . . . . . . . . . . .15		5.2 Signature Option . . . . . . . . . . . . . . . . . . .15
5.2.1 Processing Rules for Senders . . . . . . . . . 17		5.2.1 Processing Rules for Senders . . . . . . . . . 17
5.2.2 Processing Rules for Receivers . . . . . . . . 17		5.2.2 Processing Rules for Receivers . . . . . . . . 17
5.2.3 Configuration . . . . . . . . . . . . . . . . 18		5.2.3 Configuration . . . . . . . . . . . . . . . . 18
5.2.4 Performance Considerations . . . . . . . . . . 19		5.2.4 Performance Considerations . . . . . . . . . . 19
5.3 Timestamp and Nonce options . . . . . . . . . . . . .20		5.3 Timestamp and Nonce options . . . . . . . . . . . . .20
5.3.1 Timestamp Option . . . . . . . . . . . . . . . 20		5.3.1 Timestamp Option . . . . . . . . . . . . . . . 20
5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 21		5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 21
5.3.3 Processing rules for senders . . . . . . . . . 22		5.3.3 Processing rules for senders . . . . . . . . . 21
5.3.4 Processing rules for receivers . . . . . . . . 22		5.3.4 Processing rules for receivers . . . . . . . . 22
6. Authorization Delegation Discovery . . . . . . . . . . . . . 25		6. Authorization Delegation Discovery . . . . . . . . . . . . . 25
6.1 Certificate Format . . . . . . . . . . . . . . . . . .25		6.1 Certificate Format . . . . . . . . . . . . . . . . . .25
6.1.1 Router Authorization Certificate Profile . . . 25		6.1.1 Router Authorization Certificate Profile . . . 25
6.2 Certificate Transport . . . . . . . . . . . . . . . .28		6.2 Certificate Transport . . . . . . . . . . . . . . . .28
6.2.1 Delegation Chain Solicitation Message Format . 28		6.2.1 Delegation Chain Solicitation Message Format . 28
6.2.2 Delegation Chain Advertisement Message Format 30		6.2.2 Delegation Chain Advertisement Message Format 30
6.2.3 Trust Anchor Option . . . . . . . . . . . . . 32		6.2.3 Trust Anchor Option . . . . . . . . . . . . . 32
6.2.4 Certificate Option . . . . . . . . . . . . . . 34		6.2.4 Certificate Option . . . . . . . . . . . . . . 34
6.2.5 Processing Rules for Routers . . . . . . . . . 35		6.2.5 Processing Rules for Routers . . . . . . . . . 35
6.2.6 Processing Rules for Hosts . . . . . . . . . . 36		6.2.6 Processing Rules for Hosts . . . . . . . . . . 36
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38		7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .38		7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . .38
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38		7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38		7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38
7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39		7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 41		8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . 43		9. Security Considerations . . . . . . . . . . . . . . . . . . 43
9.1 Threats to the Local Link Not Covered by SEND . . . .43		9.1 Threats to the Local Link Not Covered by SEND . . . .43
9.2 How SEND Counters Threats to NDP . . . . . . . . . . .43		9.2 How SEND Counters Threats to NDP . . . . . . . . . . .43
9.2.1 Neighbor Solicitation/Advertisement Spoofing . 44		9.2.1 Neighbor Solicitation/Advertisement Spoofing . 44
9.2.2 Neighbor Unreachability Detection Failure . . 44		9.2.2 Neighbor Unreachability Detection Failure . . 44
9.2.3 Duplicate Address Detection DoS Attack . . . . 44		9.2.3 Duplicate Address Detection DoS Attack . . . . 44
9.2.4 Router Solicitation and Advertisement Attacks 45		9.2.4 Router Solicitation and Advertisement Attacks 45
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 45		9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 45
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 46		9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 46
9.3 Attacks against SEND Itself . . . . . . . . . . . . .46		9.3 Attacks against SEND Itself . . . . . . . . . . . . .46
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 48		10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 48
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49		11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 49
Normative References . . . . . . . . . . . . . . . . . . . . 50		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50
Informative References . . . . . . . . . . . . . . . . . . . 52		Normative References . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52		Informative References . . . . . . . . . . . . . . . . . . . 53
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 55		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 56		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 57		C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 57
		Intellectual Property and Copyright Statements . . . . . . . 58
1. Introduction		1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]		IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
and 2462 [8]. Nodes on the same link use NDP to discover each		and 2462 [8]. Nodes on the same link use NDP to discover each
other's presence, to determine each other's link-layer addresses, to		other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the		find routers, and to maintain reachability information about the
paths to active neighbors. NDP is used both by hosts and routers.		paths to active neighbors. NDP is used both by hosts and routers.
Its functions include Neighbor Discovery (ND), Router Discovery (RD),		Its functions include Neighbor Discovery (ND), Router Discovery (RD),
Address Autoconfiguration, Address Resolution, Neighbor		Address Autoconfiguration, Address Resolution, Neighbor
Unreachability Detection (NUD), Duplicate Address Detection (DAD),		Unreachability Detection (NUD), Duplicate Address Detection (DAD),
and Redirection.		and Redirection.
Original NDP specifications called for the use of IPsec for		The original NDP specifications called for the use of IPsec to
protecting the NDP messages. However, the RFCs do not give detailed		protect NDP messages. However, the RFCs do not give detailed
instructions for using IPsec to secure NDP. It turns out that in		instructions for using IPsec for this. In this particular
this particular application, IPsec can only be used with a manual		application, IPsec can only be used with a manual configuration of
configuration of security associations, due to chicken-and-egg		security associations, due to bootstrapping problems in using IKE
problems in using IKE [21, 16]. Furthermore, the number of such		[21, 16]. Furthermore, the number of such manually configured
manually configured security associations needed for protecting NDP		security associations needed for protecting NDP can be very large
can be very large [22], making that approach impractical for most		[22], making that approach impractical for most purposes.
purposes.
This document is organized as follows. Section 4 describes the		This document is organized as follows. Section 2 and Section 3
overall approach to securing NDP. This approach involves the use of		define some terminology and present a brief review of NDP,
new NDP options to carry public-key based signatures. A		respectively. Section 4 describes the overall approach to securing
zero-configuration mechanism is used for showing address ownership on		NDP. This approach involves the use of new NDP options to carry
individual nodes; routers are certified by a trust anchor [10]. The		public-key based signatures. A zero-configuration mechanism is used
formats, procedures, and cryptographic mechanisms for the		for showing address ownership on individual nodes; routers are
zero-configuration mechanism are described in a related specification		certified by a trust anchor [10]. The formats, procedures, and
[13].		cryptographic mechanisms for the zero-configuration mechanism are
		described in a related specification [13].
The required new NDP options are discussed in Section 5. Section 6		The required new NDP options are discussed in Section 5. Section 6
describes the mechanism for distributing certificate chains to		describes the mechanism for distributing certificate chains to
establish an authorization delegation chain to a common trust anchor.		establish an authorization delegation chain to a common trust anchor.
Finally, Section 8 discusses the co-existence of secure and		Finally, Section 8 discusses the co-existence of secure and
non-secure NDP on the same link and Section 9 discusses security		non-secure NDP on the same link and Section 9 discusses security
considerations for Secure Neighbor Discovery.		considerations for Secure Neighbor Discovery (SEND).
1.1 Specification of Requirements		1.1 Specification of Requirements
In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key		of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and		words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in [2].		"MAY" in this document are to be interpreted as described in [2].
2. Terms		2. Terms
Authorization Delegation Discovery (ADD)		Authorization Delegation Discovery (ADD)
A process through which SEND nodes can acquire a certificate chain		A process through which SEND nodes can acquire a certificate chain
from a peer node to a trust anchor.		from a peer node to a trust anchor.
Cryptographically Generated Address (CGA)		Cryptographically Generated Address (CGA)
A technique [13] where the IPv6 address of a node is		A technique [13] whereby an IPv6 address of a node is
cryptographically generated using a one-way hash function from the		cryptographically generated using a one-way hash function from the
node's public key and some other parameters.		node's public key and some other parameters.
Duplicate Address Detection (DAD)		Duplicate Address Detection (DAD)
A mechanism that assures that two IPv6 nodes on the same link are		A mechanism which assures that two IPv6 nodes on the same link are
not using the same address.		not using the same address.
Neighbor Discovery Protocol (NDP)		Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [7, 8].		The IPv6 Neighbor Discovery Protocol [7, 8].
Neighbor Discovery Protocol is a part of ICMPv6 [9].		Neighbor Discovery Protocol is a part of ICMPv6 [9].
Neighbor Discovery (ND)		Neighbor Discovery (ND)
The Neighbor Discovery function of the Neighbor Discovery Protocol		The Neighbor Discovery function of the Neighbor Discovery Protocol
(NDP). NDP contains also other functions but ND.		(NDP). NDP contains also other functions besides ND.
Neighbor Unreachability Detection (NUD)		Neighbor Unreachability Detection (NUD)
This mechanism is used for tracking the reachability of neighbors.		A mechanism used for tracking the reachability of neighbors.
Nonce		Nonce
An unpredictable random or pseudorandom number generated by a node		An unpredictable random or pseudorandom number generated by a node
and used exactly once. In SEND, nonces are used to ensure that a		and used exactly once. In SEND, nonces are used to assure that a
particular advertisement is linked to the solicitation that		particular advertisement is linked to the solicitation that
triggered it.		triggered it.
Router Authorization Certificate		Router Authorization Certificate
An X.509v3 [10] certificate using the profile specified in Section		An X.509v3 [10] public key certificate using the profile specified
6.1.1.		in Section 6.1.1.
SEND node		SEND node
An IPv6 node that implements this specification.		An IPv6 node that implements this specification.
Non-SEND node		Non-SEND node
An IPv6 node that does not implement this specification but uses		An IPv6 node that does not implement this specification but uses
only RFC 2461 and RFC 2462 mechanisms.		only RFC 2461 and RFC 2462 without security.
Router Discovery (RD)		Router Discovery (RD)
Router Discovery allows the hosts to discover what routers exist		Router Discovery allows the hosts to discover what routers exist
on the link, and what prefixes are available. Router Discovery is		on the link, and what prefixes are available. Router Discovery is
a part of the Neighbor Discovery Protocol.		a part of the Neighbor Discovery Protocol.
3. Neighbor and Router Discovery Overview		3. Neighbor and Router Discovery Overview
The Neighbor Discovery Protocol has several functions. Many of these		The Neighbor Discovery Protocol has several functions. Many of these
Skipping to change at page 7, line 35:
o The Redirect function is used for automatically redirecting a host		o The Redirect function is used for automatically redirecting a host
to a better first-hop router, or to inform hosts that a		to a better first-hop router, or to inform hosts that a
destination is in fact a neighbor (i.e., on-link). Redirect is		destination is in fact a neighbor (i.e., on-link). Redirect is
specified in Section 8 of RFC 2461 [7].		specified in Section 8 of RFC 2461 [7].
o Address Autoconfiguration is used for automatically assigning		o Address Autoconfiguration is used for automatically assigning
addresses to a host [8]. This allows hosts to operate without		addresses to a host [8]. This allows hosts to operate without
explicit configuration related to IP connectivity. The default		explicit configuration related to IP connectivity. The default
autoconfiguration mechanism is stateless. To create IP addresses,		autoconfiguration mechanism is stateless. To create IP addresses,
the hosts use any prefix information delivered to them during		hosts use any prefix information delivered to them during Router
Router Discovery, and then test the newly formed addresses for		Discovery, and then test the newly formed addresses for
uniqueness. A stateful mechanism, DHCPv6 [20], provides		uniqueness. A stateful mechanism, DHCPv6 [20], provides
additional autoconfiguration features.		additional autoconfiguration features.
o Duplicate Address Detection (DAD) is used for preventing address		o Duplicate Address Detection (DAD) is used for preventing address
collisions [8], for instance during Address Autoconfiguration. A		collisions [8], for instance during Address Autoconfiguration. A
node that intends to assign a new address to one of its interfaces		node that intends to assign a new address to one of its interfaces
first runs the DAD procedure to verify that there is no other node		first runs the DAD procedure to verify that there is no other node
using the same address. Since the rules forbid the use of an		using the same address. Since the rules forbid the use of an
address until it has been found unique, no higher layer traffic is		address until it has been found unique, no higher layer traffic is
possible until this procedure has been completed. Thus,		possible until this procedure has been completed. Thus,
preventing attacks against DAD can help ensure the availability of		preventing attacks against DAD can help ensure the availability of
communications for the node in question.		communications for the node in question.
o The Address Resolution function resolves a node's IPv6 address to		o The Address Resolution function allows a node on the link to
the corresponding link-layer address for nodes on the link.		resolve another node's IPv6 address to the corresponding
Address Resolution is defined in Section 7.2 of RFC 2461 [7], and		link-layer address. Address Resolution is defined in Section 7.2
it is used for hosts and routers alike. Again, no higher level		of RFC 2461 [7], and it is used for hosts and routers alike.
traffic can proceed until the sender knows the hardware address of		Again, no higher level traffic can proceed until the sender knows
the destination node or the next hop router. Note the source link		the link layer address of the destination node or the next hop
layer address is not checked against the information learned		router. Note the source link layer address on link layer frames
through Address Resolution. This allows for an easier addition of		is not checked against the information learned through Address
network elements such as bridges and proxies, and eases the stack		Resolution. This allows for an easier addition of network
		elements such as bridges and proxies, and eases the stack
implementation requirements as less information needs to be passed		implementation requirements as less information needs to be passed
from layer to layer.		from layer to layer.
o Neighbor Unreachability Detection (NUD) is used for tracking the		o Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighboring nodes, both hosts and routers. NUD is		reachability of neighboring nodes, both hosts and routers. NUD is
defined in Section 7.3 of RFC 2461 [7]. NUD is		defined in Section 7.3 of RFC 2461 [7]. NUD is
security-sensitive, because an attacker could falsely claim that		security-sensitive, because an attacker could falsely claim that
reachability exists when it in fact does not.		reachability exists when it in fact does not.
The NDP messages follow the ICMPv6 message format. All NDP functions		The NDP messages follow the ICMPv6 message format. All NDP functions
Skipping to change at page 9, line 7:
<------------NDP Message---------------->		<------------NDP Message---------------->
*-------------------------------------------------------------*		*-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND Message- | ND Message |		| IPv6 Header | ICMPv6 | ND Message- | ND Message |
| Next Header = 58 | Header | specific | Options |		| Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | |		| (ICMPv6) | | data | |
*-------------------------------------------------------------*		*-------------------------------------------------------------*
<--NDP Message header-->		<--NDP Message header-->
4. Secure Neighbor Discovery Overview		4. Secure Neighbor Discovery Overview
To secure the various functions, a set of new Neighbor Discovery		To secure the various functions in NDP, a set of new Neighbor
options is introduced. They are used in to protect NDP messages.		Discovery options is introduced. They are used to protect NDP
This specification introduces these options, an authorization		messages. This specification introduces these options, an
delegation discovery process, an address ownership proof mechanism,		authorization delegation discovery process, an address ownership
and requirements for the use of these components in NDP.		proof mechanism, and requirements for the use of these components in
		NDP.
The components of the solution specified in this document are as		The components of the solution specified in this document are as
follows:		follows:
o Certificate chains, anchored on trusted parties, are expected to		o Certificate chains, anchored on trusted parties, are expected to
certify the authority of routers. A host and a router must have		certify the authority of routers. A host and a router must have
at least one common trust anchor before the host can adopt the		at least one common trust anchor before the host can adopt the
router as its default router. Delegation Chain Solicitation and		router as its default router. Delegation Chain Solicitation and
Advertisement messages are used to discover a certificate chain to		Advertisement messages are used to discover a certificate chain to
the trust anchor without requiring the actual Router Discovery		the trust anchor without requiring the actual Router Discovery
messages to carry lengthy certificate chains. The receipt of a		messages to carry lengthy certificate chains. The receipt of a
protected Router Advertisement message for which no certificate		protected Router Advertisement message for which no certificate
chain is available triggers this process.		chain is available triggers the authorization delegation discovery
		process.
o Cryptographically Generated Addresses are used to assure that the		o Cryptographically Generated Addresses are used to assure that the
sender of a Neighbor Discovery message is the "owner" of the		sender of a Neighbor Discovery message is the "owner" of the
claimed address. A public-private key pair needs to be generated		claimed address. A public-private key pair is generated by all
by all nodes before they can claim an address. A new NDP option,		nodes before they can claim an address. A new NDP option, the CGA
the CGA option, is used to carry the public key and associated		option, is used to carry the public key and associated parameters.
parameters.
This specification also allows one to use non-CGA addresses and to		This specification also allows a node to use non-CGAs with
use certificates to authorize their use. However, the details of		certificates to authorize their use. However, the details of such
such use have been left for future work.		use are beyond the scope of this specification.
o A new NDP option, the Signature option, is used to protect all		o A new NDP option, the Signature option, is used to protect all
messages relating to Neighbor and Router discovery.		messages relating to Neighbor and Router discovery.
Public key signatures are used to protect the integrity of the		Public key signatures protect the integrity of the messages and
messages and to authenticate the identity of their sender. The		authenticate the identity of their sender. The authority of a
authority of a public key is established either with the		public key is established either with the authorization delegation
authorization delegation process, using certificates, or through		process, using certificates, or through the address ownership
the address ownership proof mechanism, using CGAs, or both,		proof mechanism, using CGAs, or both, depending on configuration
depending on configuration and the type of the message protected.		and the type of the message protected.
o In order to prevent replay attacks, two new Neighbor Discovery		o In order to prevent replay attacks, two new Neighbor Discovery
options, Timestamp and Nonce, are used. Given that Neighbor and		options, Timestamp and Nonce, are introduced. Given that Neighbor
Router Discovery messages are in some cases sent to multicast		and Router Discovery messages are in some cases sent to multicast
addresses, the Timestamp option offers replay protection without		addresses, the Timestamp option offers replay protection without
any previously established state or sequence numbers. When the		any previously established state or sequence numbers. When the
messages are used in solicitation - advertisement pairs, they are		messages are used in solicitation - advertisement pairs, they are
protected using the Nonce option.		protected using the Nonce option.
5. Neighbor Discovery Protocol Options		5. Neighbor Discovery Protocol Options
The options described in this section MUST be supported by all SEND		The options described in this section MUST be supported by all SEND
nodes.		nodes.
Skipping to change at page 11, line 38:
. .		. .
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |		| |
. .		. .
. Padding .		. Padding .
. .		. .
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields is described as follows.
Type		Type
TBD <To be assigned by IANA for CGA>.		TBD <To be assigned by IANA for CGA>.
Length		Length
The length of the option (including the Type, Length, Collision		The length of the option (including the Type, Length, Collision
Cnt, Reserved, Modifier, Key Information, and Padding fields) in		Cnt, Reserved, Modifier, Key Information, and Padding fields) in
units of 8 octets.		units of 8 octets.
Collision Cnt		Collision Cnt
An 8-bit collision count, which can get values 0, 1 and 2. Its		An 8-bit collision count, which can be 0, 1 or 2. Its semantics
semantics are defined in [13].		are defined in [13].
Reserved		Reserved
An 8-bit field reserved for future use. The value MUST be		An 8-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.
Modifier		Modifier
A random 128-bit number used in CGA generation. Its semantics are		A random 128-bit number used in CGA generation. Its semantics are
Skipping to change at page 12, line 36:
the Signature option. Packets received with two different keys		the Signature option. Packets received with two different keys
MUST be silently discarded. Note that a future extension may		MUST be silently discarded. Note that a future extension may
provide a mechanism which allows the owner of an address and the		provide a mechanism which allows the owner of an address and the
signer to be different parties.		signer to be different parties.
The length of the Key Information field is determined by the ASN.1		The length of the Key Information field is determined by the ASN.1
encoding.		encoding.
Padding		Padding
A variable length field making the option length a multiple of 8.		A variable length field making the option length a multiple of 8,
It begins after the ASN.1 encoding of the previous field has		beginning after the ASN.1 encoding of the previous field ends, and
ended, and continues to the end of the option, as specified by the		continuing to the end of the option, as specified by the Length
Length field.		field.
5.1.1 Processing Rules for Senders		5.1.1 Processing Rules for Senders
The CGA option MUST be present in all Neighbor Solicitation and		The CGA option MUST be present in all Neighbor Solicitation and
Advertisement messages, and MUST be present in Router Solicitation		Advertisement messages, and MUST be present in Router Solicitation
messages unless they are sent with the unspecified source address.		messages unless they are sent with the unspecified source address.
The CGA option MAY be present in other messages.		The CGA option MAY be present in other messages.
A node sending a message using the CGA option MUST construct the		A node sending a message using the CGA option MUST construct the
message as follows.		message as follows.
The Modifier, Collision Cnt, and Key Information fields in the CGA		The Modifier, Collision Cnt, and Key Information fields in the CGA
option are filled in according to the rules presented above and in		option are filled in according to the rules presented above and in
[13]. The used public key is taken from configuration; typically		[13]. The public key in the Key Information field is taken from the
from a data structure associated with the source address. The		node's configuration used to generate the CGA; typically from a data
address MUST be constructed as specified in Section 4 of [13].		structure associated with the source address. The address MUST be
Depending on the type of the message, this address appears in		constructed as specified in Section 4 of [13]. Depending on the type
different places:		of the message, this address appears in different places:
Redirect		Redirect
The address MUST be the source address of the message.		The address MUST be the source address of the message.
Neighbor Solicitation		Neighbor Solicitation
The address MUST be the Target Address for solicitations sent for		The address MUST be the Target Address for solicitations sent for
the purpose of Duplicate Address Detection, and the source address		Duplicate Address Detection, and the source address of the message
of the message otherwise.		otherwise.
Neighbor Advertisement		Neighbor Advertisement
The address MUST be the source address of the message.		The address MUST be the source address of the message.
Router Solicitation		Router Solicitation
The address MUST be the source address of the message. Note that		The address MUST be the source address of the message. Note that
the CGA option is not used when the source address is the		the CGA option is not used when the source address is the
unspecified address.		unspecified address.
Skipping to change at page 14, line 23:
Key Information Field.		Key Information Field.
If the CGA verification is successful, the recipient proceeds with		If the CGA verification is successful, the recipient proceeds with
the cryptographically more time consuming check of the signature.		the cryptographically more time consuming check of the signature.
However, even if the CGA verification succeeds, no claims about		However, even if the CGA verification succeeds, no claims about
the validity of the use can be made, until the signature has been		the validity of the use can be made, until the signature has been
checked.		checked.
Note that a receiver that does not support CGA or has not specified		Note that a receiver that does not support CGA or has not specified
its use for a given interface can still verify packets using trust		its use for a given interface can still verify packets using trust
anchors, even if CGA had been used on a packet. In such a case, the		anchors, even if a CGA is used on a packet. In such a case, the CGA
CGA property of the address is simply left unverified.		property of the address is simply left unverified.
5.1.3 Configuration		5.1.3 Configuration
All nodes that support the verification of the CGA option MUST record		All nodes that support the verification of the CGA option MUST record
the following configuration information:		the following configuration information:
minbits		minbits
The minimum acceptable key length for the public keys used in the		The minimum acceptable key length for public keys used in the
generation of the CGA address. The default SHOULD be 1024 bits.		generation of CGAs. The default SHOULD be 1024 bits.
Implementations MAY also set an upper limit in order to limit the		Implementations MAY also set an upper limit in order to limit the
amount of computation they need to perform when verifying packets		amount of computation they need to perform when verifying packets
that use these security associations. The upper limit SHOULD be		that use these security associations. The upper limit SHOULD be
at least 2048 bits. Any implementation should follow prudent		at least 2048 bits. Any implementation should follow prudent
cryptographic practice in determining the appropriate key lengths.		cryptographic practice in determining the appropriate key lengths.
minSec		minSec
The minimum acceptable Sec value, if CGA verification is required.		The minimum acceptable Sec value, if CGA verification is required.
This parameter is intended to facilitate future extensions and		This parameter is intended to facilitate future extensions and
Skipping to change at page 15, line 14:
CGA parameters		CGA parameters
Any information required to construct CGAs, including the used Sec		Any information required to construct CGAs, including the used Sec
and Modifier values, and the CGA address itself.		and Modifier values, and the CGA address itself.
5.2 Signature Option		5.2 Signature Option
The Signature option allows public-key based signatures to be		The Signature option allows public-key based signatures to be
attached to NDP messages. Configured trust anchors, CGAs, or both		attached to NDP messages. Configured trust anchors, CGAs, or both
can be used as the trusted root. The format of the Signature option		are supported as the trusted root. The format of the Signature
is described in the following:		option is described 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 | Pad Length | Reserved |		| Type | Length | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |		| |
| Key Hash |		| Key Hash |
| |		| |
| |		| |
Skipping to change at page 15, line 40:
. .		. .
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |		| |
. .		. .
. Padding .		. Padding .
. .		. .
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields is described below:
Type		Type
TBD <To be assigned by IANA for Signature>.		TBD <To be assigned by IANA for Signature>.
Length		Length
The length of the option (including the Type, Length, Pad Length,		The length of the option (including the Type, Length, Pad Length,
Reserved, Key Hash, Digital Signature, and Padding fields) in		Reserved, Key Hash, Digital Signature, and Padding fields) in
units of 8 octets.		units of 8 octets.
Skipping to change at page 16, line 18:
units of an octet.		units of an octet.
Reserved		Reserved
An 8-bit field reserved for future use. The value MUST be		An 8-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 contains the most significant (leftmost) 128-bits		A 128-bit field containing the most significant (leftmost)
of a SHA-1 hash of the public key used for the constructing the		128-bits of a SHA-1 hash of the public key used for constructing
signature. The SHA-1 is taken over the presentation used in the		the signature. The SHA-1 hash is taken over the presentation used
Key Information field in the CGA option. Its purpose is to		in the Key Information field of the CGA option. Its purpose is to
associate the signature to a particular key known by the receiver.		associate the signature to a particular key known by the receiver.
Such a key can be either stored in the certificate cache of the		Such a key can be either stored in the certificate cache of the
receiver, or be received in the CGA option in the same message.		receiver, or be received in the CGA option in the same message.
Digital Signature		Digital Signature
A variable length field contains a PKCS#1 signature constructed		A variable length field containing a PKCS#1 signature, constructed
using the sender's private key, over the the following sequence of		using the sender's private key, over the the following sequence of
octets:		octets:
1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F		1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F
CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been		CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
generated randomly by the editor of this specification.).		generated randomly by the editor of this specification.).
2. The 128-bit Source Address field from the IP header.		2. The 128-bit Source Address field from the IP header.
3. The 128-bit Destination Address field from the IP header.		3. The 128-bit Destination Address field from the IP header.
Skipping to change at page 18, line 11:
Router Solicitation messages without the Signature option MUST be		Router Solicitation messages without the Signature option MUST be
also treated as insecure, unless the source address of the message is		also treated as insecure, unless the source address of the message is
the unspecified address.		the unspecified address.
A message containing a Signature option MUST be checked as follows:		A message containing a Signature option MUST be checked as follows:
o The receiver MUST ignore any options the come after the first		o The receiver MUST ignore any options the come after the first
Signature option.		Signature option.
o The Key Hash field MUST indicate the use of a known public key,		o The Key Hash field MUST indicate the use of a known public key,
either one learned from a preceding CGA option, or one known by		either one learned from a preceding CGA option in the same
other means.		message, or one known by other means.
o The Digital Signature field MUST have correct encoding, and not		o The Digital Signature field MUST have correct encoding, and not
exceed the length of the Signature option minus the Padding.		exceed the length of the Signature option minus the Padding.
o The Digital Signature verification MUST show that the signature		o The Digital Signature verification MUST show that the signature
has been calculated as specified in the previous section.		has been calculated as specified in the previous section.
o If the use of a trust anchor has been configured, a valid		o If the use of a trust anchor has been configured, a valid
authorization delegation chain MUST be known between the		authorization delegation chain MUST be known between the
receiver's trust anchor and the sender's public key.		receiver's trust anchor and the sender's public key.
Note that the receiver may verify just the CGA property of a		Note that the receiver may verify just the CGA property of a
packet, even if, in addition to CGA, the sender has used a trust		packet, even if, in addition to CGA, the sender has used a trust
anchor.		anchor.
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. The receiver MAY silently discard packets also otherwise,		discarded. The receiver MAY also otherwise silently discard packets,
e.g., as a response to an apparent CPU exhausting DoS attack.		e.g., as a response to an apparent CPU exhausting DoS attack.
5.2.3 Configuration		5.2.3 Configuration
All nodes that support the reception of the Signature options MUST		All nodes that support the reception of the Signature options MUST be
record the following configuration information for each separate NDP		configured with the following information for each separate NDP
message type:		message type:
authorization method		authorization method
This parameter determines the method through which the authority		This parameter determines the method through which the authority
of the sender is determined. It can have four values:		of the sender is determined. It can have four values:
trust anchor		trust anchor
The authority of the sender is verified as described in Section		The authority of the sender is verified as described in Section
Skipping to change at page 19, line 17:
trust anchor and CGA		trust anchor and CGA
Both the trust anchor and the CGA verification is required.		Both the trust anchor and the CGA verification is required.
trust anchor or CGA		trust anchor or CGA
Either the trust anchor or the CGA verification is required.		Either the trust anchor or the CGA verification is required.
anchor		anchor
The public keys and names of the allowed trust anchor(s), if		The public keys and names of the allowed trust anchor(s), if the
authorization method is not set to CGA.		authorization method is not set to CGA.
All nodes that support the sending of Signature options MUST record		All nodes that support the sending of Signature options MUST record
the following configuration information:		the following configuration information:
keypair		keypair
A public-private key pair. If authorization delegation is in use,		A public-private key pair. If authorization delegation is in use,
there must exist a delegation chain from a trust anchor to this		there must exist a delegation chain from a trust anchor to this
key pair.		key pair.
CGA flag		CGA flag
A flag that indicates whether CGA is used or is not used. This		A flag that indicates whether CGA is used or not. This flag may
flag may be per interface or per node. (Note that in future		be per interface or per node. (Note that in future extensions of
extensions of the SEND protocol, this flag may be per		the SEND protocol, this flag may be per subnet-prefix.)
subnet-prefix.)
5.2.4 Performance Considerations		5.2.4 Performance Considerations
The construction and verification of this option is computationally		The construction and verification of this option is computationally
expensive. In the NDP context, however, the hosts typically have the		expensive. In the NDP context, however, the hosts typically have the
need to perform only a few signature operations as they enter a link,		need to perform only a few signature operations as they enter a link,
and a few operations as they find a new on-link peer with which to		and a few operations as they find a new on-link peer with which to
communicate.		communicate.
Routers are required to perform a larger number of operations,		Routers are required to perform a larger number of operations,
particularly when the frequency of router advertisements is high due		particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of required signature		to mobility requirements. Still, the number of required signature
operations is on the order of a few dozen per second, some of which		operations is on the order of a few dozen per second, some of which
can be precomputed as explained below. A large number of router		can be precomputed as explained below. A large number of router
solicitations may cause higher demand for performing asymmetric		solicitations may cause higher demand for performing asymmetric
operations, although RFC 2461 limits the rate at which responses to		operations, although RFC 2461 limits the rate at which responses to
solicitations can be sent.		solicitations can be sent.
Signatures can be precomputed for unsolicited (multicast) Neighbor		Signatures can be precomputed for unsolicited (multicast) Neighbor
and Router Advertisements, if the timing of such future		and Router Advertisements if the timing of such future advertisements
advertisements is known. Typically, solicited advertisements are		is known. Typically, solicited advertisements are sent to the
sent to the unicast address from which the solicitation was sent.		unicast address from which the solicitation was sent. Given that the
Given that the IPv6 header is covered by the signature, it is not		IPv6 header is covered by the signature, it is not possible to
possible to precompute solicited-for advertisements.		precompute solicited advertisements.
5.3 Timestamp and Nonce options		5.3 Timestamp and Nonce options
5.3.1 Timestamp Option		5.3.1 Timestamp Option
The purpose of the Timestamp option is to ensure that unsolicited		The purpose of the Timestamp option is to assure that unsolicited
advertisements and redirects have not been replayed. The format of		advertisements and redirects have not been replayed. The format of
this option is described in the following:		this option is described in the following:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |		| |
+ Timestamp +		+ Timestamp +
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:
Type		Type
TBD <To be assigned by IANA for Timestamp>.		TBD <To be assigned by IANA for Timestamp>.
Length		Length
The length of the option (including the Type, Length, Reserved,		The length of the option (including the Type, Length, Reserved,
and Timestamp fields) in units of 8 octets, i.e., 2.		and Timestamp fields) in units of 8 octets, i.e., 2.
Reserved		Reserved
Skipping to change at page 21, line 16:
A 64-bit unsigned integer field containing a timestamp. The value		A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1, 1970 00:00 UTC,		indicates the number of seconds since January 1, 1970 00:00 UTC,
using a fixed point format. In this format the integer number of		using a fixed point format. In this format the integer number of
seconds is contained in the first 48 bits of the field, and the		seconds is contained in the first 48 bits of the field, and the
remaining 16 bits indicate the number of 1/64K fractions of a		remaining 16 bits indicate the number of 1/64K fractions of a
second.		second.
5.3.2 Nonce Option		5.3.2 Nonce Option
The purpose of the Nonce option is to ensure that an advertisement is		The purpose of the Nonce option is to assure that an advertisement is
a fresh response to a solicitation sent earlier by the receiving same		a fresh response to a solicitation sent earlier by the node. The
node. The format of this option is described in the following:		format of this option is described in the following:
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 | Nonce ... |		| Type | Length | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |		| |
. .		. .
. .		. .
| |		| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:
Type		Type
TBD <To be assigned by IANA for Nonce>.		TBD <To be assigned by IANA for Nonce>.
Length		Length
The length of the option (including the Type, Length, and Nonce		The length of the option (including the Type, Length, and Nonce
fields) in units of 8 octets.		fields) in units of 8 octets.
Nonce		Nonce
Skipping to change at page 22, line 11:
solicitation message. The length of the random number MUST be at		solicitation message. The length of the random number MUST be at
least 6 bytes. The length of the random number MUST be selected		least 6 bytes. The length of the random number MUST be selected
so that the length of the nonce option is a multiple of 8 octets.		so that the length of the nonce option is a multiple of 8 octets.
5.3.3 Processing rules for senders		5.3.3 Processing rules for senders
All solicitation messages MUST include a Nonce. When sending a		All solicitation messages MUST include a Nonce. When sending a
solicitation, the sender MUST store the nonce internally so that it		solicitation, the sender MUST store the nonce internally so that it
can recognize any replies containing that particular nonce.		can recognize any replies containing that particular nonce.
All solicited-for advertisements MUST include a Nonce, copying the		All solicited advertisements MUST include a Nonce, copied from the
nonce value from the received solicitation. Note that routers may		received solicitation. Note that routers may decide to send a
decide to send a multicast advertisement to all nodes instead of a		multicast advertisement to all nodes instead of a response to a
response to a specific host. In such case the router MAY still		specific host. In such case the router MAY still include the nonce
include the nonce value for the host that triggered the multicast		value for the host that triggered the multicast advertisement.
advertisement.
All solicitation, advertisement, and redirect messages MUST include a		All solicitation, advertisement, and redirect messages MUST include a
Timestamp. Senders SHOULD set the Timestamp field to the current		Timestamp. Senders SHOULD set the Timestamp field to the current
time, according to their real time clock.		time, according to their real time clock.
If a message has both Nonce and Timestamp options, the Nonce option		If a message has both Nonce and Timestamp options, the Nonce option
SHOULD precede the Timestamp option in order.		SHOULD precede the Timestamp option in the message.
5.3.4 Processing rules for receivers		5.3.4 Processing rules for receivers
The processing of the Nonce and Timestamp options depends on whether		The processing of the Nonce and Timestamp options depends on whether
a packet is a solicited-for advertisement or not. A system may		a packet is a solicited advertisement. A system may implement the
implement the distinction in various means. Section 5.3.4.1 defines		distinction in various ways. Section 5.3.4.1 defines the processing
the processing rules for solicited-for advertisements. Section		rules for solicited advertisements. Section 5.3.4.2 defines the
5.3.4.2 defines the processing rules for all other messages.		processing rules for all other messages.
In addition, the following rules apply in any case:		In addition, the following rules apply in all cases:
o Messages received with the Signature option but without the		o Messages received with the Signature option but without the
Timestamp option MUST be silently discarded.		Timestamp option MUST be silently discarded.
o Solicitation messages received with the Signature option but		o Solicitation messages received with the Signature option but
without the Nonce option MUST be silently discarded.		without the Nonce option MUST be silently discarded.
o Advertisements sent to a unicast destination address with the		o Advertisements sent to a unicast destination address with the
Signature option but without a Nonce option MUST be silently		Signature option but without a Nonce option MUST be silently
discarded.		discarded.
o An implementation may utilize some mechanism such as a timestamp		o An implementation MAY utilize some mechanism such as a timestamp
cache to strengthen resistance to replay attacks. When there is a		cache to strengthen resistance to replay attacks. When there is a
very large number of nodes on the same link, or when a cache		very large number of nodes on the same link, or when a cache
filling attack is in progress, it is possible that the cache		filling attack is in progress, it is possible that the cache
holding the most recent timestamp per sender becomes full. In		holding the most recent timestamp per sender becomes full. In
this case the node MUST remove some entries from the cache or		this case the node MUST remove some entries from the cache or
refuse some new requested entries. The specific policy as to		refuse some new requested entries. The specific policy as to
which entries are preferred over the others is left as an		which entries are preferred over the others is left as an
implementation decision. However, typical policies may prefer		implementation decision. However, typical policies may prefer
existing entries over new ones, CGAs with a large Sec value over		existing entries over new ones, CGAs with a large Sec value over
smaller Sec values, and so on. The issue is briefly discussed in		smaller Sec values, and so on. The issue is briefly discussed in
Appendix C.		Appendix C.
o The receiver MUST be prepared to receive the Timestamp and Nonce		o The receiver MUST be prepared to receive the Timestamp and Nonce
options in any order, as per RFC 2461 [7] Section 9.		options in any order, as per RFC 2461 [7] Section 9.
5.3.4.1 Processing solicited-for advertisements		5.3.4.1 Processing solicited advertisements
The receiver MUST verify that it has recently sent a matching		The receiver MUST verify that it has recently sent a matching
solicitation, and that the received advertisement contains a copy of		solicitation, and that the received advertisement contains a copy of
the Nonce sent in the solicitation.		the Nonce sent in the solicitation.
If the message contains a Nonce option, but the Nonce value is not		If the message contains a Nonce option, but the Nonce value is not
recognized, the message MUST be silently discarded.		recognized, the message MUST be silently discarded.
Otherwise, if the message does not contain a Nonce option, it MAY be		Otherwise, if the message does not contain a Nonce option, it MAY be
considered as a non-solicited-for advertisement, and processed		considered as an unsolicited advertisement, and processed according
according to Section 5.3.4.2.		to Section 5.3.4.2.
If the message is accepted, the receiver SHOULD store the receive		If the message is accepted, the receiver SHOULD store the receive
time of the message and the time stamp time in the message, as		time of the message and the time stamp time in the message, as
specified in Section 5.3.4.2.		specified in Section 5.3.4.2.
5.3.4.2 Processing all other messages		5.3.4.2 Processing all other messages
Receivers SHOULD be configured with an allowed timestamp Delta value,		Receivers SHOULD be configured with an allowed timestamp Delta value,
a "fuzz factor" for comparisons, and an allowed clock drift		a "fuzz factor" for comparisons, and an allowed clock drift
parameter. The recommended default value for the allowed Delta is		parameter. The recommended default value for the allowed Delta is
3,600 seconds (1 hour), for fuzz factor 1 second, and for clock drift		TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift
1% (0.01).		TIMESTAMP_DRIFT (see Section 11.
To facilitate timestamp checking, each node SHOULD store the		To facilitate timestamp checking, each node SHOULD store the
following information per each peer:		following information for each peer:
The receive time of the last received, accepted SEND message.		o The receive time of the last received and accepted SEND message.
This is called RDlast.		This is called RDlast.
The time stamp in the last received, accepted SEND message. This		o The time stamp in the last received and accepted SEND message.
is called TSlast.		This is called TSlast.
An accepted SEND message is any successfully verified Neighbor		An accepted SEND message is any successfully verified Neighbor
Solicitation, Neighbor Advertisement, Router Solicitation, Router		Solicitation, Neighbor Advertisement, Router Solicitation, Router
Advertisement, or Redirect message from the given peer. It is		Advertisement, or Redirect message from the given peer. It is
required that the Signature option has been used in such a message		required that the Signature option has been used in such a message
before it can update the above variables.		before it can update the above variables.
Receivers SHOULD then check the Timestamp field as follows:		Receivers SHOULD then check the Timestamp field as follows:
o When a message is received from a new peer, i.e., one that is not		o When a message is received from a new peer, i.e., one that is not
Skipping to change at page 24, line 13:
before it can update the above variables.		before it can update the above variables.
Receivers SHOULD then check the Timestamp field as follows:		Receivers SHOULD then check the Timestamp field as follows:
o When a message is received from a new peer, i.e., one that is not		o When a message is received from a new peer, i.e., one that is not
stored in the cache, the received timestamp, TSnew, is checked and		stored in the cache, the received timestamp, TSnew, is checked and
the packet is accepted if the timestamp is recent enough with		the packet is accepted if the timestamp is recent enough with
respect to the reception time of the packet, RDnew:		respect to the reception time of the packet, RDnew:
-Delta < (RDnew - TSnew) < +Delta		-Delta < (RDnew - TSnew) < +Delta
The RDnew and TSnew values SHOULD be stored into the cache as		The RDnew and TSnew values SHOULD be stored into the cache as
RDlast and TSlast.		RDlast and TSlast.
o If the timestamp is NOT within the boundaries but the message is a		o If the timestamp is NOT within the boundaries but the message is a
Neighbor Solicitation message that should be responded to by the		Neighbor Solicitation message which should be answered by the
receiver, the receiver MAY respond to the message. However, if it		receiver, the receiver MAY respond to the message. However, if it
does respond to the message, it MUST NOT create a neighbor cache		does respond to the message, it MUST NOT create a Neighbor Cache
entry. This allows nodes that have large difference in their		entry. This allows nodes that have large differences in their
clocks to still communicate with each other, by exchanging NS/NA		clocks to still communicate with each other, by exchanging NS/NA
pairs.		pairs.
o When a message is received from a known peer, i.e., one that		o When a message is received from a known peer, i.e., one that
already has an entry in the cache, the time stamp is checked		already has an entry in the cache, the time stamp is checked
against the previously received SEND message:		against the previously received SEND message:
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz		TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
If this inequality does not hold, the receiver SHOULD silently		If this inequality does not hold, the receiver SHOULD silently
discard the message. On the other hand, if the inequality holds,		discard the message. On the other hand, if the inequality holds,
the receiver SHOULD process the message.		the receiver SHOULD process the message.
Moreover, if the above inequality holds and TSnew > TSlast, the		Moreover, if the above inequality holds and TSnew > TSlast, the
receiver SHOULD update RDlast and TSlast. Otherwise, the receiver		receiver SHOULD update RDlast and TSlast. Otherwise, the receiver
MUST NOT update update RDlast or TSlast.		MUST NOT update update RDlast or TSlast.
6. Authorization Delegation Discovery		6. Authorization Delegation Discovery
Several protocols (NDP included) allow a node to automatically		NDP allows a node to automatically configure itself based on
configure itself based on information it learns shortly after		information learned shortly after connecting to a new link. It is
connecting to a new link. It is particularly easy to configure		particularly easy to configure "rogue" routers on an unsecured link,
"rogue" routers on an unsecured link, and it is particularly		and it is particularly difficult for a node to distinguish between
difficult for a node to distinguish between valid and invalid sources		valid and invalid sources of router information, because the node
of information, when the node needs this information before being		needs this information before being able to communicate with nodes
able to communicate with nodes outside of the link.		outside of the link.
Since the newly-connected node cannot communicate off-link, it cannot		Since the newly-connected node cannot communicate off-link, it cannot
be responsible for searching information to help validating the		be responsible for searching information to help validate the
router(s); however, given a chain of appropriately signed		router(s); however, given a chain of appropriately signed
certificates, it can check someone else's search results and conclude		certificates, it can check someone else's search results and conclude
that a particular message comes from an authorized source. In the		that a particular message comes from an authorized source. In the
typical case, a router, which is already connected to beyond the		typical case, a router already connected to beyond the link, can (if
link, can (if necessary) communicate with off-link nodes and		necessary) communicate with off-link nodes and construct such a
construct such a certificate chain.		certificate chain.
The Secure Neighbor Discovery Protocol mandates a certificate format		The Secure Neighbor Discovery Protocol mandates a certificate format
and introduces two new ICMPv6 messages that are used between hosts		and introduces two new ICMPv6 messages that are used between hosts
and routers to allow the host to learn a certificate chain with the		and routers to allow the host to learn a certificate chain with the
assistance of the router.		assistance of the router.
6.1 Certificate Format		6.1 Certificate Format
The certificate chain of a router terminates in a Router		The certificate chain of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act		Authorization Certificate that authorizes a specific IPv6 node to act
Skipping to change at page 25, line 50:
single trust anchor.		single trust anchor.
6.1.1 Router Authorization Certificate Profile		6.1.1 Router Authorization Certificate Profile
Router Authorization Certificates are X.509v3 certificates, as		Router Authorization Certificates are X.509v3 certificates, as
defined in RFC 3280 [10], and MUST contain at least one instance of		defined in RFC 3280 [10], and MUST contain at least one instance of
the X.509 extension for IP addresses, as defined in [12]. The parent		the X.509 extension for IP addresses, as defined in [12]. The parent
certificates in the certificate chain MUST contain one or more X.509		certificates in the certificate chain MUST contain one or more X.509
IP address extensions, back up to a trusted party (such as the user's		IP address extensions, back up to a trusted party (such as the user's
ISP) that configured the original IP address space block for the		ISP) that configured the original IP address space block for the
router in question, or delegated the right to do so for someone. The		router in question, or delegated the right to do so. The
certificates for intermediate delegating authorities MUST contain		certificates for the intermediate delegating authorities MUST contain
X.509 IP address extension(s) for subdelegations. The router's		X.509 IP address extension(s) for subdelegations. The router's
certificate is signed by the delegating authority for the prefixes		certificate is signed by the delegating authority for the prefixes
the router is authorized to to advertise.		the router is authorized to to advertise.
The X.509 IP address extension MUST contain at least one		The X.509 IP address extension MUST contain at least one
addressesOrRanges element. This element MUST contain an		addressesOrRanges element. This element MUST contain an
addressPrefix element with an IPv6 address prefix for a prefix the		addressPrefix element containing an IPv6 address prefix for a prefix
router or the intermediate entity is authorized to route. If the		the router or the intermediate entity is authorized to route. If the
entity is allowed to route any prefix, the used IPv6 address prefix		entity is allowed to route any prefix, the used IPv6 address prefix
is the null prefix, ::/0. The addressFamily element of the		is the null prefix, ::/0. The addressFamily element of the
containing IPAddrBlocks sequence element MUST contain the IPv6		containing IPAddrBlocks sequence element MUST contain the IPv6
Address Family Identifier (0002), as specified in [12] for IPv6		Address Family Identifier (0002), as specified in [12] for IPv6
prefixes. Instead of an addressPrefix element, the addressesOrRange		prefixes. Instead of an addressPrefix element, the addressesOrRange
element MAY contain an addressRange element for a range of prefixes,		element MAY contain an addressRange element for a range of prefixes,
if more than one prefix is authorized. The X.509 IP address		if more than one prefix is authorized. The X.509 IP address
extension MAY contain additional IPv6 prefixes, expressed either as		extension MAY contain additional IPv6 prefixes, expressed either as
an addressPrefix or an addressRange.		an addressPrefix or an addressRange.
Skipping to change at page 27, line 5:
provide authorization in other circumstances, for example with		provide authorization in other circumstances, for example with
routing protocols. It is necessary to ensure that the authorization		routing protocols. It is necessary to ensure that the authorization
information is appropriate for all applications. SEND certificates		information is appropriate for all applications. SEND certificates
may authorize a larger set of prefixes than the router is really		may authorize a larger set of prefixes than the router is really
authorized to advertise on a given interface. For instance, SEND		authorized to advertise on a given interface. For instance, SEND
allows the use of the null prefix. This prefix might cause		allows the use of the null prefix. This prefix might cause
verification or routing problems in other applications. It is		verification or routing problems in other applications. It is
RECOMMENDED that SEND certificates containing the null prefix are		RECOMMENDED that SEND certificates containing the null prefix are
only used for SEND.		only used for SEND.
Since it is possible that some PKC certificates used with SEND do not		Since it is possible that some public key certificates used with SEND
immediately contain the X.509 IP address extension element, an		do not immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range		implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD		checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default		be off by default. That is, the system SHOULD have a default
configuration that requires rigorous prefix and range checks.		configuration that requires rigorous prefix and range checks.
The following is an example of a certificate chain. Suppose that		The following is an example of a certificate chain. Suppose that
isp_group_example.net is the trust anchor. The host has this		isp_group_example.net is the trust anchor. The host has this
certificate for it:		certificate:
Certificate 1:		Certificate 1:
Issuer: isp_group_example.net		Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004		Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group_example.net		Subject: isp_group_example.net
Extensions:		Extensions:
IP address delegation extension:		IP address delegation extension:
Prefixes: P1, ..., Pk		Prefixes: P1, ..., Pk
... possibly other extensions ...		... possibly other extensions ...
... other certificate parameters ...		... other certificate parameters ...
When the host attaches then to a linked served by		When the host attaches to a link served by
router_x.isp_foo_example.net, it receives the following certificate		router_x.isp_foo_example.net, it receives the following certificate
chain:		chain:
Certificate 2:		Certificate 2:
Issuer: isp_group_example.net		Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004		Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo_example.net		Subject: isp_foo_example.net
Extensions:		Extensions:
IP address delegation extension:		IP address delegation extension:
Prefixes: Q1, ..., Qk		Prefixes: Q1, ..., Qk
Skipping to change at page 28, line 15:
it is not possible to perform an on-line Certificate Revocation List		it is not possible to perform an on-line Certificate Revocation List
(CRL) check if such a check is necessary. Until such a check is		(CRL) check if such a check is necessary. Until such a check is
performed, acceptance of the certificate MUST be considered		performed, acceptance of the certificate MUST be considered
provisional, and the node MUST perform a check as soon as it has		provisional, and the node MUST perform a check as soon as it has
established a connection with the Internet through the router. If		established a connection with the Internet through the router. If
the router has been compromised, it could interfere with the CRL		the router has been compromised, it could interfere with the CRL
check. Should performance of the CRL check be disrupted or should		check. Should performance of the CRL check be disrupted or should
the check fail, the node SHOULD immediately stop using the router as		the check fail, the node SHOULD immediately stop using the router as
a default and use another router on the link instead.		a default and use another router on the link instead.
In addition, the IP addresses in the delegation extension must be		In addition, the IP addresses in the delegation extension must be a
subsumed by the IP addresses in the delegation extension in the		subset of the IP addresses in the delegation extension of the
issuer's certificate. So in this example, R1, ..., Rs must be		issuer's certificate. So in this example, R1, ..., Rs must be a
subsumed by Q1,...,Qr, and Q1,...,Qr must be subsumed by P1,...,Pk.		subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If
If the certificate chain is valid, then		the certificate chain is valid, then router_foo.isp_foo_example.com
router_foo.isp_foo_example.com is authorized to route the prefixes		is authorized to route the prefixes R1,...,Rs.
R1,...,Rs.
6.2 Certificate Transport		6.2 Certificate Transport
The Delegation Chain Solicitation (DCS) message is sent by a host		The Delegation Chain Solicitation (DCS) message is sent by a host
when it wishes to request a certificate chain between a router and		when it wishes to request a certificate chain between a router and
the one of the host's trust anchors. The Delegation Chain		the one of the host's trust anchors. The Delegation Chain
Advertisement (DCA) message is sent as an answer to the DCS message.		Advertisement (DCA) message is sent in reply to the DCS message.
These messages are separate from the rest of Neighbor and Router		These messages are separate from the rest of Neighbor and Router
Discovery, in order to reduce the effect of the potentially		Discovery, in order to reduce the effect of the potentially
voluminous certificate chain information on other messages.		voluminous certificate chain information on other messages.
The Authorization Delegation Discovery (ADD) process does not exclude		The Authorization Delegation Discovery (ADD) process does not exclude
other forms of discovering certificate chains. For instance, during		other forms of discovering certificate chains. For instance, during
fast movements mobile nodes may learn information - including the		fast movements mobile nodes may learn information - including the
certificate chains - of the next router from a previous router.		certificate chains - of the next router from a previous router, or
		nodes may be preconfigured with certificate chains from roaming
		partners.
Where hosts themselves are certified by a trust anchor, these		Where hosts themselves are certified by a trust anchor, these
messages MAY also optionally be used between hosts to acquire the		messages MAY also optionally be used between hosts to acquire the
peer's certificate chain. However, the details of such usage are		peer's certificate chain. However, the details of such usage are
left for future specification.		beyond the scope of this specification.
6.2.1 Delegation Chain Solicitation Message Format		6.2.1 Delegation Chain Solicitation Message Format
Hosts send Delegation Chain Solicitations in order to prompt routers		Hosts send Delegation Chain Solicitations in order to prompt routers
to generate Delegation Chain Advertisements.		to generate Delegation Chain Advertisements.
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 | Code | Checksum |		| Type | Code | Checksum |
Skipping to change at page 29, line 51:
Checksum		Checksum
The ICMP checksum [9].		The ICMP checksum [9].
Identifier		Identifier
A 16-bit unsigned integer field, acting as an identifier to		A 16-bit unsigned integer field, acting as an identifier to
help matching advertisements to solicitations. The Identifier		help matching advertisements to solicitations. The Identifier
field MUST NOT be zero, and its value SHOULD be randomly		field MUST NOT be zero, and its value SHOULD be randomly
generated. (This randomness does not need to be		generated. This randomness does not need to be
cryptographically hard, though. Its purpose is to avoid		cryptographically hard, since its purpose is only to avoid
collisions.)		collisions.
Reserved		Reserved
An unused field. It MUST be initialized to zero by the sender		An unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.		and MUST be ignored by the receiver.
Valid Options:		Valid Options:
Trust Anchor		Trust Anchor
One or more trust anchors that the client is willing to accept.		One or more trust anchors that the client is willing to accept.
The first (or only) Trust Anchor option MUST contain a DER		The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.2.3. If there is more than		Encoded X.501 Name; see Section 6.2.3. If there is more than
one Trust Anchor option, the options past the first one may		one Trust Anchor option, the options past the first one may
contain any types of Trust Anchors.		contain any type of trust anchor.
Future versions of this protocol may define new option types.		Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize		Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST		and continue processing the message. All included options MUST
have a length that is greater than zero.		have a length that is greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets.		ICMP length (derived from the IP length) MUST be 8 or more octets.
6.2.2 Delegation Chain Advertisement Message Format		6.2.2 Delegation Chain Advertisement Message Format
Skipping to change at page 32, line 10:
the fragmentation at the IP layer, individual components of an		the fragmentation at the IP layer, individual components of an
advertisement may be stored and used before all the components		advertisement may be stored and used before all the components
have arrived; this makes them slightly more reliable and less		have arrived; this makes them slightly more reliable and less
prone to Denial-of-Service attacks.		prone to Denial-of-Service attacks.
The first message in a N-component advertisement has the		The first message in a N-component advertisement has the
Component field set to N-1, the second set to N-2, and so on.		Component field set to N-1, the second set to N-2, and so on.
Zero indicates that there are no more components coming in this		Zero indicates that there are no more components coming in this
advertisement.		advertisement.
The components MUST be ordered so that the trust anchor end of		The components MUST be ordered so that the certificate after
the chain is the one sent first. Each certificate sent after		the trust anchor is the one sent first. Each certificate sent
it can be verified with the previously sent certificates. The		after the first can be verified with the previously sent
certificate of the sender comes last.		certificates. The certificate of the sender comes last.
Reserved		Reserved
An unused field. It MUST be initialized to zero by the sender		An unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.		and MUST be ignored by the receiver.
Valid Options:		Valid Options:
Certificate		Certificate
Skipping to change at page 33, line 13:
The format of the Trust Anchor option is described in the following:		The format of the Trust Anchor option is described in the following:
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 | Name Type | Pad Length |		| Type | Length | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...		| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:
Type		Type
TBD <To be assigned by IANA for Trust Anchor>.		TBD <To be assigned by IANA for Trust Anchor>.
Length		Length
The length of the option, (including the Type, Length, Name Type,		The length of the option, (including the Type, Length, Name Type,
Pad Length, and Name fields) in units of 8 octets.		Pad Length, and Name fields) in units of 8 octets.
Name Type		Name Type
Skipping to change at page 34, line 8:
"preferred name syntax" DNS format, as specified in RFC 1034 [1]		"preferred name syntax" DNS format, as specified in RFC 1034 [1]
Section 3.5. Additionally, the restrictions discussed in RFC 3280		Section 3.5. Additionally, the restrictions discussed in RFC 3280
[10] Section 4.2.1.7 apply.		[10] Section 4.2.1.7 apply.
In the FQDN case the Name field is an "IDN-unaware domain name		In the FQDN case the Name field is an "IDN-unaware domain name
slot" as defined in [11]. That is, it can contain only ASCII		slot" as defined in [11]. That is, it can contain only ASCII
characters. An implementation MAY support internationalized		characters. An implementation MAY support internationalized
domain names (IDNs) using the ToASCII operation; see [11] for more		domain names (IDNs) using the ToASCII operation; see [11] for more
information.		information.
All systems MUST implement support the DER Encoded X.501 Name.		All systems MUST support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type.		Implementations MAY support the FQDN name type.
6.2.4 Certificate Option		6.2.4 Certificate Option
The format of the certificate option is described in the following:		The format of the certificate option is described in the following:
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 | Cert Type | Pad Length |		| Type | Length | Cert Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...		| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:
Type		Type
TBD <To be assigned by IANA for Certificate>.		TBD <To be assigned by IANA for Certificate>.
Length		Length
The length of the option, (including the Type, Length, Cert Type,		The length of the option, (including the Type, Length, Cert Type,
Pad Length, and Certificate fields) in units of 8 octets.		Pad Length, and Certificate fields) in units of 8 octets.
Cert Type		Cert Type
Skipping to change at page 35, line 34:
Routers SHOULD send advertisements in response to valid solicitations		Routers SHOULD send advertisements in response to valid solicitations
received on an advertising interface. If the source address in the		received on an advertising interface. If the source address in the
solicitation was the unspecified address, the router MUST send the		solicitation was the unspecified address, the router MUST send the
response to the link-scoped All-Nodes multicast address. If the		response to the link-scoped All-Nodes multicast address. If the
source address was a unicast address, the router MUST send the		source address was a unicast address, the router MUST send the
response to the Solicited-Node multicast address corresponding to the		response to the Solicited-Node multicast address corresponding to the
source address, except when under load, as specified below. Routers		source address, except when under load, as specified below. Routers
SHOULD NOT send Delegation Chain Advertisements more than		SHOULD NOT send Delegation Chain Advertisements more than
MAX_DCA_RATE times within a second. When there are more		MAX_DCA_RATE times within a second. When there are more
solicitations than this, the router SHOULD send the response to the		solicitations, the router SHOULD send the response to the All-Nodes
All-Nodes multicast address regardless of the source address that		multicast address regardless of the source address that appeared in
appeared in the solicitation.		the solicitation.
In an advertisement, the router SHOULD include suitable Certificate		In an advertisement, the router SHOULD include suitable Certificate
options so that a delegation chain to the solicited trust anchor can		options so that a delegation chain to the solicited trust anchor can
be established. The anchor is identified by the Trust Anchor option.		be established. The anchor is identified by the Trust Anchor option.
If the Trust Anchor option is represented as a DER Encoded X.501		If the Trust Anchor option is represented as a DER Encoded X.501
Name, then the Name must be equal to the Subject field in the		Name, then the Name must be equal to the Subject field in the
anchor's certificate. If the Trust Anchor option is represented as		anchor's certificate. If the Trust Anchor option is represented as
an FQDN, the FQDN must be equal to an FQDN in the subjectAltName		an FQDN, the FQDN must be equal to an FQDN in the subjectAltName
field of the anchor's certificate. The router SHOULD include the		field of the anchor's certificate. The router SHOULD include the
Trust Anchor option(s) in the advertisement for which the delegation		Trust Anchor option(s) in the advertisement for which the delegation
Skipping to change at page 36, line 11:
If the router is unable to find a chain to the requested anchor, it		If the router is unable to find a chain to the requested anchor, it
SHOULD send an advertisement without any certificates. In this case		SHOULD send an advertisement without any certificates. In this case
the router SHOULD include the Trust Anchor options which were		the router SHOULD include the Trust Anchor options which were
solicited.		solicited.
6.2.6 Processing Rules for Hosts		6.2.6 Processing Rules for Hosts
Hosts SHOULD possess the public key and trust anchor name of at least		Hosts SHOULD possess the public key and trust anchor name of at least
one certificate authority, they SHOULD possess their own key pair,		one certificate authority, they SHOULD possess their own key pair,
and they MAY possess a certificate from the above mentioned		and they MAY possess certificates from certificate authorities.
certificate authority.
A host MUST silently discard any received Delegation Chain		A host MUST silently discard any received Delegation Chain
Advertisement messages that do not conform to the message format		Advertisement messages that do not conform to the message format
defined in Section 6.2.2. The contents of the Reserved field, and of		defined in Section 6.2.2. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future,		any unrecognized options, MUST be ignored. Future,
backward-compatible changes to the protocol may specify the contents		backward-compatible changes to the protocol MAY specify the contents
of the Reserved field or add new options; backward-incompatible		of the Reserved field or add new options; backward-incompatible
changes may use different Code values. The contents of any defined		changes MUST use different Code values. The contents of any defined
options that are not specified to be used with Delegation Chain		options that are not specified to be used with Delegation Chain
Advertisement messages MUST be ignored and the packet processed in		Advertisement messages MUST be ignored and the packet processed in
the normal manner. The only defined options that may appear are the		the normal manner. The only defined options that may appear are the
Certificate and Trust Anchor options. An advertisement that passes		Certificate and Trust Anchor options. An advertisement that passes
the validity checks is called a "valid advertisement".		the validity checks is called a "valid advertisement".
Hosts SHOULD store certificate chains retrieved in Delegation Chain		Hosts SHOULD store certificate chains retrieved in Delegation Chain
Discovery messages if they start from an anchor trusted by the host.		Discovery messages if they start from an anchor trusted by the host.
The certificate chains MUST be verified, as defined in Section 6.1,		The certificate chains MUST be verified, as defined in Section 6.1,
before storing them. Routers MUST send the certificates one by one,		before storing them. Routers MUST send the certificates one by one,
starting from the trust anchor end of the chain. Except for		starting from the trust anchor end of the chain. Except for
temporary purposes to allow for message loss and reordering, hosts		temporary purposes to allow for message loss and reordering, hosts
SHOULD NOT store certificates received in a Delegation Chain		SHOULD NOT store certificates received in a Delegation Chain
Advertisement unless they contain a certificate which can be		Advertisement unless they contain a certificate which can be
immediately verified either to the trust anchor or to a certificate		immediately verified either to the trust anchor or to a certificate
which has been verified earlier.		that has been verified earlier.
Note that it may be useful to cache this information and implied		Note that caching this information and the implied verification
verification results for use over multiple attachments to the		results between network attachments for use over multiple attachments
network.		to the network can help improve performance. But periodic
		certificate revocation checks are still needed even with cached
		results, to make sure that the certificates are still valid.
The host has a need to retrieve a delegation chain when a Router		The host has a need to retrieve a delegation chain when a Router
Advertisement has been received with a public key that is not stored		Advertisement has been received with a public key that is not stored
in the hosts' cache of certificates, or there is no authorization		in the hosts' cache of certificates, or there is no authorization
delegation chain to the host's trust anchor. In these situations,		delegation chain to the host's trust anchor. In these situations,
the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain		the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain
Solicitation messages, each separated by at least DCS_INTERVAL		Solicitation messages, each separated by at least DCS_INTERVAL
seconds.		seconds.
Delegation Chain Solicitations SHOULD NOT be sent if the host has a		Delegation Chain Solicitations SHOULD NOT be sent if the host has a
currently valid certificate chain from a reachable router to a trust		currently valid certificate chain from a reachable router to a trust
anchor.		anchor.
When soliciting certificates for a router, a host MUST send		When soliciting certificates for a router, a host MUST send
Delegation Chain Solicitations either to the All-Routers multicast		Delegation Chain Solicitations either to the All-Routers multicast
address, if it has not selected a default router yet, or to the		address, if it has not selected a default router yet, or to the
default router's IP address, if it has already been selected.		default router's IP address, if a default router has already been
		selected.
If two hosts want to establish trust with the DCS and DCA messages,		If two hosts want to establish trust with the DCS and DCA messages,
the DCS message SHOULD be sent to the Solicited-Node multicast		the DCS message SHOULD be sent to the Solicited-Node multicast
address of the receiver. The advertisements SHOULD be sent as		address of the receiver. The advertisements SHOULD be sent as
specified above for routers. However, the exact details are left for		specified above for routers. However, the exact details are outside
a future specification.		the scope of this specification.
When processing possible advertisements sent as responses to a		When processing possible advertisements sent as responses to a
solicitation, the host MAY prefer to process first those		solicitation, the host MAY prefer to process first those
advertisements with the same Identifier field value as in the		advertisements with the same Identifier field value as in the
solicitation. This makes Denial-of-Service attacks against the		solicitation. This makes Denial-of-Service attacks against the
mechanism harder (see Section 9.3).		mechanism harder (see Section 9.3).
7. Addressing		7. Addressing
7.1 CGA Addresses		7.1 CGAs
Nodes that use stateless address autoconfiguration SHOULD generate a		Nodes that use stateless address autoconfiguration SHOULD generate a
new CGA as specified in Section 4 of [13] each time they run the		new CGA as specified in Section 4 of [13] each time they run the
autoconfiguration procedure. The nodes MAY continue to use the same		autoconfiguration procedure. The nodes MAY continue to use the same
public key and modifier, and start the process from Step 4 of the		public key and modifier, and start the process from Step 4 of the
generation algorithm.		generation algorithm.
By default, a SEND-enabled node SHOULD use only CGAs as its own		By default, a SEND-enabled node SHOULD use only CGAs for its own
addresses. Other types of addresses MAY be used in testing,		addresses. Other types of addresses MAY be used in testing,
diagnostics or other purposes. However, this document does not		diagnostics or for other purposes. However, this document does not
describe how to choose between different types of addresses for		describe how to choose between different types of addresses for
different communications. A dynamic selection can be provided by an		different communications. A dynamic selection can be provided by an
API, such as the one defined in [23].		API, such as the one defined in [23].
7.2 Redirect Addresses		7.2 Redirect Addresses
If the Target Address and Destination Address fields in the ICMP		If the Target Address and Destination Address fields in the ICMP
Redirect message are equal, then this message is used to inform hosts		Redirect message are equal, then this message is used to inform hosts
that a destination is in fact a neighbor. In this case the receiver		that a destination is in fact a neighbor. In this case the receiver
MUST verify that the given address falls within the range defined by		MUST verify that the given address falls within the range defined by
the router's certificate. Redirect messages failing this check MUST		the router's certificate. Redirect messages failing this check MUST
be silently discarded.		be silently discarded.
Note that RFC 2461 rules prevent a bogus router from sending a		Note that RFC 2461 rules prevent a host from accepting a Redirect
Redirect message when the host is not using the bogus router as a		message from a router that is not its default router. This prevents
default router.		an attacker from tricking a node into redirecting traffic when the
		attacer is not the default router.
7.3 Advertised Prefixes		7.3 Advertised Prefixes
The router's certificate defines the address range(s) that it is		The router's certificate defines the address range(s) that it is
allowed to advertise securely. A router MAY, however, advertise a		allowed to advertise securely. A router MAY, however, advertise a
combination of certified and uncertified prefixes. Uncertified		combination of certified and uncertified prefixes. Uncertified
prefixes are treated as insecure, i.e., processed in the same way as		prefixes are treated as insecure, i.e., processed in the same way as
insecure router advertisements sent by non-SEND routers. The		insecure router advertisements sent by non-SEND routers. The
processing of insecure messages is specified in Section 8. Note that		processing of insecure messages is specified in Section 8. Note that
SEND nodes that do not attempt to interoperate with non-SEND nodes		SEND nodes that do not attempt to interoperate with non-SEND nodes
Skipping to change at page 39, line 32:
host SHOULD use a different advertising router as its default router,		host SHOULD use a different advertising router as its default router,
if available. If the node is performing stateful autoconfiguration,		if available. If the node is performing stateful autoconfiguration,
it SHOULD check the address provided by the DHCP server against the		it SHOULD check the address provided by the DHCP server against the
certified prefixes and SHOULD NOT use the address if the prefix is		certified prefixes and SHOULD NOT use the address if the prefix is
not certified.		not certified.
7.4 Limitations		7.4 Limitations
This specification does not address the protection of NDP packets for		This specification does not address the protection of NDP packets for
nodes that are configured with a static address (e.g., PREFIX::1).		nodes that are configured with a static address (e.g., PREFIX::1).
Future certificate chain based authorization specifications are		Future certificate chain-based authorization specifications are
needed for such nodes.		needed for such nodes.
It is outside the scope of this specification to describe the use of		It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing		trust anchor authorization between nodes with dynamically changing
addresses. Such dynamically changing addresses may be the result of		addresses. Such dynamically changing addresses may be the result of
stateful or stateless address autoconfiguration, or through the use		stateful or stateless address autoconfiguration, or through the use
of RFC 3041 [18] addresses. If the CGA method is not used, nodes		of RFC 3041 [18] addresses. If the CGA method is not used, nodes
would be required to exchange certificate chains that terminate in a		would be required to exchange certificate chains that terminate in a
certificate authorizing a node to use an IP address having a		certificate authorizing a node to use an IP address having a
particular interface identifier. This specification does not specify		particular interface identifier. This specification does not specify
the format of such certificates, since there are currently a few		the format of such certificates, since there are currently a few
cases where such certificates are required by the link layer and it		cases where such certificates are required by the link layer and it
is up to the link layer to provide certification for the interface		is up to the link layer to provide certification for the interface
identifier. This may be the subject of a future specification. It		identifier. This may be the subject of a future specification. It
is also outside the scope of this specification to describe how		is also outside the scope of this specification to describe how
stateful address autoconfiguration works with the CGA method.		stateful address autoconfiguration works with the CGA method.
The Target Address in Neighbor Advertisement is required to be equal		The Target Address in Neighbor Advertisement is required to be equal
to the source address of the packet, except in the case of proxy		to the source address of the packet, except in the case of proxy
Neighbor Discovery. Proxy Neighbor Discovery is not supported by		Neighbor Discovery. Proxy Neighbor Discovery is not supported by
this specification; it is planned to be specified in a future		this specification.
document.
8. Transition Issues		8. Transition Issues
During the transition to secure links or as a policy consideration,		During the transition to secure links or as a policy consideration,
network operators may want to run a particular link with a mixture of		network operators may want to run a particular link with a mixture of
secure and insecure nodes. Nodes that support SEND SHOULD support		secure and insecure nodes. Nodes that support SEND SHOULD support
the use of SEND and plain NDP at the same time.		the use of SEND and plain NDP at the same time.
In a mixed environment, SEND nodes receive both secure and insecure		In a mixed environment, SEND nodes receive both secure and insecure
messages but give priority to "secured" ones. Here, the "secured"		messages but give priority to "secured" ones. Here, the "secured"
messages are ones that contain a valid signature option, as specified		messages are ones that contain a valid signature option, as specified
above, and "insecure" messages are ones that contain no signature		above, and "insecure" messages are ones that contain no signature
option.		option.
SEND nodes send only secured messages. Plain (non-SEND) Neighbor		SEND nodes MUST send only secured messages. Plain (non-SEND)
Discovery nodes will obviously send only insecure messages. Per RFC		Neighbor Discovery nodes will obviously send only insecure messages.
2461 [7], such nodes will ignore the unknown options and will treat		Per RFC 2461 [7], such nodes will ignore the unknown options and will
secured messages in the same way as they treat insecure ones.		treat secured messages in the same way as they treat insecure ones.
Secured and insecure nodes share the same network resources, such as		Secured and insecure nodes share the same network resources, such as
prefixes and address spaces.		prefixes and address spaces.
In a mixed environment SEND nodes follow the protocols defined in RFC		In a mixed environment SEND nodes follow the protocols defined in RFC
2461 and RFC 2462 with the following exceptions:		2461 and RFC 2462 with the following exceptions:
o All solicitations sent by a SEND node MUST be secured.		o All solicitations sent by a SEND node MUST be secured.
o Unsolicited advertisements sent by a SEND node MUST be secured.		o Unsolicited advertisements sent by a SEND node MUST be secured.
o A SEND node MUST send a secured advertisement in response to a		o A SEND node MUST send a secured advertisement in response to a
secured solicitation. Advertisements sent in response to an		secured solicitation. Advertisements sent in response to an
insecure solicitation MUST be secured as well, but MUST NOT		insecure solicitation MUST be secured as well, but MUST NOT
contain the Nonce option.		contain the Nonce option.
o A SEND node that uses the CGA authorization method for protecting		o A SEND node that uses the CGA authorization method for protecting
Neighbor Solicitations SHOULD perform Duplicate Address Detection		Neighbor Solicitations SHOULD perform Duplicate Address Detection
as follows. If Duplicate Address Detection indicates the		as follows. If Duplicate Address Detection indicates the
tentative address is already in use, generate a new tentative CGA		tentative address is already in use, generate a new tentative CGA.
address. If after 3 consecutive attempts no non-unique address		If after 3 consecutive attempts no non-unique address was
was generated, log a system error and give up attempting to		generated, log a system error and give up attempting to generate
generate an address for that interface.		an address for that interface.
When performing Duplicate Address Detection for the first		When performing Duplicate Address Detection for the first
tentative address, accept both secured and insecure Neighbor		tentative address, accept both secured and insecure Neighbor
Advertisements and Solicitations received as response to the		Advertisements and Solicitations received as response to the
Neighbor Solicitations. When performing Duplicate Address		Neighbor Solicitations. When performing Duplicate Address
Detection for the second or third tentative address, ignore		Detection for the second or third tentative address, ignore
insecure Neighbor Advertisements and Solicitations.		insecure Neighbor Advertisements and Solicitations.
o The node MAY have a configuration option that causes it to ignore		o The node MAY have a configuration option that causes it to ignore
insecure advertisements even when performing Duplicate Address		insecure advertisements even when performing Duplicate Address
Detection for the first tentative address. This configuration		Detection for the first tentative address. This configuration
option SHOULD be disabled by default. This is a recovery		option SHOULD be disabled by default. This is a recovery
mechanism, in case attacks against the first address become		mechanism, in case attacks against the first address become
common.		common.
o The Neighbor Cache, Prefix List and Default Router list entries		o The Neighbor Cache, Prefix List and Default Router list entries
MUST have a secured/insecure flag that indicates whether the		MUST have a secured/insecure flag that indicates whether the
message that caused the creation or last update of the entry was		message that caused the creation or last update of the entry was
secured or insecure. Received insecure messages MUST NOT cause		secured or insecure. Received insecure messages MUST NOT cause
changes to existing secured entries in the Neighbor Cache, Prefix		changes to existing secured entries in the Neighbor Cache, Prefix
List or Default Router List. Received secured messages MUST cause		List or Default Router List. The Neighbor Cache SHOULD implement
an update of the matching entries and flagging of them as secured.		a flag on entries indicating whether the entry issecured.
		Received secured messages MUST cause an update of the matching
		entries and flagging of them as secured.
o The conceptual sending algorithm is modified so that an insecure		o The conceptual sending algorithm is modified so that an insecure
router is selected only if there is no reachable SEND router for		router is selected only if there is no reachable SEND router for
the prefix. That is, the algorithm for selecting a default router		the prefix. That is, the algorithm for selecting a default router
favors reachable SEND routers over reachable non-SEND ones.		favors reachable SEND routers over reachable non-SEND ones.
o A SEND node SHOULD have a configuration option that causes it to		o A SEND node SHOULD have a configuration option that causes it to
ignore all insecure Neighbor Solicitation and Advertisement,		ignore all insecure Neighbor Solicitation and Advertisement,
Router Solicitation and Advertisement, and Redirect messages.		Router Solicitation and Advertisement, and Redirect messages.
This can be used to enforce SEND-only networks.		This can be used to enforce SEND-only networks.
Skipping to change at page 49, line 5:
Host constants:		Host constants:
MAX_DCS_MESSAGES 3 transmissions		MAX_DCS_MESSAGES 3 transmissions
DCS_INTERVAL 4 seconds		DCS_INTERVAL 4 seconds
Router constants:		Router constants:
MAX_DCA_RATE 10 times per second		MAX_DCA_RATE 10 times per second
11. IANA Considerations		11. Protocol Variables
		TIMESTAMP_DELTA 3,600 seconds (1 hour)
		TIMESTAMP_FUZZ 1 second
		TIMESTAMP_DRIFT 1 % (0.01)
		12. IANA Considerations
This document defines two new ICMP message types, used in		This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned		Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range:		ICMPv6 type numbers from the informational message range:
o The Delegation Chain Solicitation message, described in Section		o The Delegation Chain Solicitation message, described in Section
6.2.1.		6.2.1.
o The Delegation Chain Advertisement message, described in Section		o The Delegation Chain Advertisement message, described in Section
6.2.2.		6.2.2.
End of changes.
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/