base.txt		issue53.txt
Skipping to change at page 2, line 38:
5.3.3 Processing rules for senders . . . . . . . . . 21		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 . . . . . . . . . 34		6.2.5 Processing Rules for Routers . . . . . . . . . 35
6.2.6 Processing Rules for Hosts . . . . . . . . . . 35		6.2.6 Processing Rules for Hosts . . . . . . . . . . 36
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38		7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .38		7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .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
Skipping to change at page 4, line 22:
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		Original NDP specifications called for the use of IPsec for
protecting the NDP messages. However, the RFCs do not give detailed		protecting the 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 to secure NDP. It turns out that in
this particular application, IPsec can only be used with a manual		this particular application, IPsec can only be used with a manual
configuration of security associations, due to chicken-and-egg		configuration of security associations, due to chicken-and-egg
problems in using IKE [21, 15]. Furthermore, the number of such		problems in using IKE [22, 16]. Furthermore, the number of such
manually configured security associations needed for protecting NDP		manually configured security associations needed for protecting NDP
can be very large [22], making that approach impractical for most		can be very large [23], 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 4 describes the
overall approach to securing NDP. This approach involves the use of		overall approach to securing NDP. This approach involves the use of
new NDP options to carry public-key based signatures. A		new NDP options to carry public-key based signatures. A
zero-configuration mechanism is used for showing address ownership on		zero-configuration mechanism is used for showing address ownership on
individual nodes; routers are certified by a trust anchor [10]. The		individual nodes; routers are certified by a trust anchor [10]. The
formats, procedures, and cryptographic mechanisms for the		formats, procedures, and cryptographic mechanisms for the
zero-configuration mechanism are described in a related specification		zero-configuration mechanism are described in a related specification
[12].		[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.
1.1 Specification of Requirements		1.1 Specification of Requirements
Skipping to change at page 5, line 14:
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 [12] where the IPv6 address of a node is		A technique [13] where the 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 that 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)
Skipping to change at page 7, line 37:
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		the hosts use any prefix information delivered to them during
Router Discovery, and then test the newly formed addresses for		Router Discovery, and then test the newly formed addresses for
uniqueness. A stateful mechanism, DHCPv6 [19], 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
Skipping to change at page 12, line 4:
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 get values 0, 1 and 2. Its
semantics are defined in [12].		semantics 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
defined in [12].		defined in [13].
Key Information		Key Information
A variable length field containing the public key of the sender,		A variable length field containing the public key of the sender,
represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as		represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as
described in Section 4 of [12].		described in Section 4 of [13].
This specification requires that if both the CGA option and the		This specification requires that if both the CGA option and the
Signature option are present, then the publicKey field in the CGA		Signature option are present, then the publicKey field in the CGA
option MUST be the public key referred by the Key Hash field in		option MUST be the public key referred by the Key Hash field in
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
Skipping to change at page 13, line 7:
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 in Router Solicitation messages not sent		Advertisement messages, and in Router Solicitation messages not sent
with the unspecified source address. The CGA option MAY be present		with the unspecified source address. The CGA option MAY be present
in other messages.		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
[12]. The used public key is taken from configuration; typically		[13]. The used public key is taken from configuration; typically
from a data structure associated with the source address. The		from a data structure associated with the source address. The
address MUST be constructed as specified in Section 4 of [12].		address MUST be constructed as specified in Section 4 of [13].
Depending on the type of the message, this address appears in		Depending on the type of the message, this address appears in
different places:		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
Skipping to change at page 14, line 7:
insecure messages.		insecure messages.
Router Solicitation messages without the CGA option MUST be also		Router Solicitation messages without the CGA option MUST be also
treated as insecure, unless the source address of the message is the		treated as insecure, unless the source address of the message is the
unspecified address.		unspecified address.
A message containing a CGA option MUST be checked as follows:		A message containing a CGA option MUST be checked as follows:
If the interface has been configured to use CGA, the receiving		If the interface has been configured to use CGA, the receiving
node MUST verify the source address of the packet using the		node MUST verify the source address of the packet using the
algorithm described in Section 5 of [12]. The inputs to the		algorithm described in Section 5 of [13]. The inputs to the
algorithm are the claimed address, as defined in the previous		algorithm are the claimed address, as defined in the previous
section, and the concatenation from left to right of the following		section, and the concatenation from left to right of the following
data: the contents of the 8-octet Modifier field, the 8-octet		data: the contents of the 8-octet Modifier field, the 8-octet
subnet-prefix part of the claimed address, the content of the		subnet-prefix part of the claimed address, the content of the
1-octet Collision Cnt field, and contents of the variable-length		1-octet Collision Cnt field, and contents of the variable-length
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.
Skipping to change at page 14, line 45:
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
experimental work. Currently, the minSec value SHOULD always be		experimental work. Currently, the minSec value SHOULD always be
set to zero.		set to zero.
See Section 2 in [12].		See Section 2 in [13].
All nodes that support the sending of the CGA option MUST record the		All nodes that support the sending of the CGA option MUST record the
following configuration information:		following configuration information:
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
Skipping to change at page 16, line 28:
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 contains 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 [12] 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.
4. The 32-bit ICMP header.		4. The 32-bit ICMP header.
5. The NDP message header.		5. The NDP message header.
6. All NDP options preceding the Signature option.		6. All NDP options preceding the Signature option.
The signature value is computed with the RSASSA-PKCS1-v1_5		The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-1 hash as defined in [13].		algorithm and SHA-1 hash as defined in [14].
This field starts after the Key Hash field. The length of the		This field starts after the Key Hash field. The length of the
Digital Signature field is determined by the length of the		Digital Signature field is determined by the length of the
Signature option minus the length of the other fields (including		Signature option minus the length of the other fields (including
the variable length Pad field).		the variable length Pad field).
This variable length field contains padding, as many bytes as is		This variable length field contains padding, as many bytes as is
given by the Pad Length field.		given by the Pad Length field.
5.2.1 Processing Rules for Senders		5.2.1 Processing Rules for Senders
Skipping to change at page 18, line 50:
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
6.1. The sender may claim additional authorization through the		6.1. The sender may claim additional authorization through the
use of CGAs, but that is neither required nor verified.		use of CGAs, but that is neither required nor verified.
CGA		CGA
The CGA property of the sender's address is verified as		The CGA property of the sender's address is verified as
described in [12]. The sender may claim additional authority		described in [13]. The sender may claim additional authority
through a trust anchor, but that is neither required nor		through a trust anchor, but that is neither required nor
verified.		verified.
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.
Skipping to change at page 25, line 36:
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
as a router. Because authorization chains are not a common practice		as a router. Because authorization chains are not a common practice
in the Internet at the time this specification was written, the chain		in the Internet at the time this specification was written, the chain
MUST consist of standard Public Key Certificates (PKC, in the sense		MUST consist of standard Public Key Certificates (PKC, in the sense
of [18]). The certificate chain MUST start from the identity of a		of [19]). The certificate chain MUST start from the identity of a
trust anchor that is shared by the host and the router. This allows		trust anchor that is shared by the host and the router. This allows
the host to anchor trust for the router's public key in the trust		the host to anchor trust for the router's public key in the trust
anchor. Note that there MAY be multiple certificates issued by a		anchor. Note that there MAY be multiple certificates issued by a
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 [11]. 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 for someone. The
certificates for intermediate delegating authorities MUST contain		certificates for 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 with an IPv6 address prefix for a prefix the
router or the intermediate entity is authorized to route. If 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 [11] 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.
A SEND node receiving a Router Authorization Certificate MUST first		A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the		check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the		delegating authority. Then the client MUST check whether all the
addressPrefix or addressRange entries in the router's certificate are		addressPrefix or addressRange entries in the router's certificate are
Skipping to change at page 33, line 51:
DER encoded X.501 certificate Name, represented and encoded		DER encoded X.501 certificate Name, represented and encoded
exactly as in the matching X.509v3 trust anchor certificate.		exactly as in the matching X.509v3 trust anchor certificate.
When the Name Type field is set to 2, the Name field contains a		When the Name Type field is set to 2, the Name field contains a
Fully Qualified Domain Name of the trust anchor, for example,		Fully Qualified Domain Name of the trust anchor, for example,
"trustanchor.example.com". The name is stored as a string, in the		"trustanchor.example.com". The name is stored as a string, in the
"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
		slot" as defined in [11]. That is, it can contain only ASCII
		characters. An implementation MAY support internationalized
		domain names (IDNs) using the ToASCII operation; see [11] for more
		information.
All systems MUST implement support the DER Encoded X.501 Name.		All systems MUST implement 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Skipping to change at page 38, line 10:
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 CGA Addresses
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 [12] for each new		new CGA as specified in Section 4 of [13] for each new
autoconfiguration run. The nodes MAY continue to use the same public		autoconfiguration run. The nodes MAY continue to use the same public
key and modifier, and start the process from Step 4 of the generation		key and modifier, and start the process from Step 4 of the generation
algorithm.		algorithm.
By default, a SEND-enabled node SHOULD use only CGAs as its own		By default, a SEND-enabled node SHOULD use only CGAs as 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 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 [24].
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.
Skipping to change at page 39, line 39:
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 [17] 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.
Skipping to change at page 43, line 36:
Even on a secure link layer, SEND does not require that the addresses		Even on a secure link layer, SEND does not require that the addresses
on the link layer and Neighbor Advertisements correspond to each		on the link layer and Neighbor Advertisements correspond to each
other. However, it is RECOMMENDED that such checks be performed		other. However, it is RECOMMENDED that such checks be performed
where this is possible on the given link layer technology.		where this is possible on the given link layer technology.
Prior to participating in Neighbor Discovery and Duplicate Address		Prior to participating in Neighbor Discovery and Duplicate Address
Detection, nodes must subscribe to the link-scoped All-Nodes		Detection, nodes must subscribe to the link-scoped All-Nodes
Multicast Group and the Solicited-Node Multicast Group for the		Multicast Group and the Solicited-Node Multicast Group for the
address that they are claiming for their addresses; RFC 2461 [7].		address that they are claiming for their addresses; RFC 2461 [7].
Subscribing to a multicast group requires that the nodes use MLD		Subscribing to a multicast group requires that the nodes use MLD
[16]. MLD contains no provision for security. An attacker could		[17]. MLD contains no provision for security. An attacker could
send an MLD Done message to unsubscribe a victim from the		send an MLD Done message to unsubscribe a victim from the
Solicited-Node Multicast address. However, the victim should be able		Solicited-Node Multicast address. However, the victim should be able
to detect such an attack because the router sends a		to detect such an attack because the router sends a
Multicast-Address-Specific Query to determine whether any listeners		Multicast-Address-Specific Query to determine whether any listeners
are still on the address, at which point the victim can respond to		are still on the address, at which point the victim can respond to
avoid being dropped from the group. This technique will work if the		avoid being dropped from the group. This technique will work if the
router on the link has not been compromised. Other attacks using MLD		router on the link has not been compromised. Other attacks using MLD
are possible, but they primarily lead to extraneous (but not		are possible, but they primarily lead to extraneous (but not
overwhelming) traffic.		overwhelming) traffic.
9.2 How SEND Counters Threats to NDP		9.2 How SEND Counters Threats to NDP
The SEND protocol is designed to counter the threats to NDP, as		The SEND protocol is designed to counter the threats to NDP, as
outlined in [25]. The following subsections contain a regression of		outlined in [26]. The following subsections contain a regression of
the SEND protocol against the threats, to illustrate what aspects of		the SEND protocol against the threats, to illustrate what aspects of
the protocol counter each threat.		the protocol counter each threat.
9.2.1 Neighbor Solicitation/Advertisement Spoofing		9.2.1 Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [25]. The threat is that		This threat is defined in Section 4.1.1 of [26]. The threat is that
a spoofed message may cause a false entry in a node's Neighbor Cache.		a spoofed message may cause a false entry in a node's Neighbor Cache.
There are two cases:		There are two cases:
1. Entries made as a side effect of a Neighbor Solicitation or		1. Entries made as a side effect of a Neighbor Solicitation or
Router Solicitation. A router receiving a Router Solicitation		Router Solicitation. A router receiving a Router Solicitation
with a Target Link-Layer Address extension and the IPv6 source		with a Target Link-Layer Address extension and the IPv6 source
address not equal to the unspecified address inserts an entry for		address not equal to the unspecified address inserts an entry for
the IPv6 address into its Neighbor Cache. Also, a node		the IPv6 address into its Neighbor Cache. Also, a node
performing Duplicate Address Detection (DAD) that receives a		performing Duplicate Address Detection (DAD) that receives a
Neighbor Solicitation for the same address regards the situation		Neighbor Solicitation for the same address regards the situation
Skipping to change at page 44, line 38:
2. Entries made as a result of a Neighbor Advertisement message.		2. Entries made as a result of a Neighbor Advertisement message.
SEND counters this threat by requiring the Signature and CGA		SEND counters this threat by requiring the Signature and CGA
options to be present in these advertisements.		options to be present in these advertisements.
See also Section 9.2.5, below, for discussion about replay protection		See also Section 9.2.5, below, for discussion about replay protection
and timestamps.		and timestamps.
9.2.2 Neighbor Unreachability Detection Failure		9.2.2 Neighbor Unreachability Detection Failure
This attack is described in Section 4.1.2 of [25]. SEND counters		This attack is described in Section 4.1.2 of [26]. SEND counters
this attack by requiring a node responding to Neighbor Solicitations		this attack by requiring a node responding to Neighbor Solicitations
sent as NUD probes to include a Signature option and proof of		sent as NUD probes to include a Signature option and proof of
authorization to use the interface identifier in the address being		authorization to use the interface identifier in the address being
probed. If these prerequisites are not met, the node performing NUD		probed. If these prerequisites are not met, the node performing NUD
discards the responses.		discards the responses.
9.2.3 Duplicate Address Detection DoS Attack		9.2.3 Duplicate Address Detection DoS Attack
This attack is described in Section 4.1.3 of [25]. SEND counters		This attack is described in Section 4.1.3 of [26]. SEND counters
this attack by requiring the Neighbor Advertisements sent as		this attack by requiring the Neighbor Advertisements sent as
responses to DAD to include a Signature option and proof of		responses to DAD to include a Signature option and proof of
authorization to use the interface identifier in the address being		authorization to use the interface identifier in the address being
tested. If these prerequisites are not met, the node performing DAD		tested. If these prerequisites are not met, the node performing DAD
discards the responses.		discards the responses.
When a SEND node is used on a link that also connects to non-SEND		When a SEND node is used on a link that also connects to non-SEND
nodes, the SEND node ignores any insecure Neighbor Solicitations or		nodes, the SEND node ignores any insecure Neighbor Solicitations or
Advertisements that may be send by the non-SEND nodes. This protects		Advertisements that may be send by the non-SEND nodes. This protects
the SEND node from DAD DoS attacks by non-SEND nodes or attackers		the SEND node from DAD DoS attacks by non-SEND nodes or attackers
simulating to non-SEND nodes, at the cost of a potential address		simulating to non-SEND nodes, at the cost of a potential address
collision between a SEND node and non-SEND node. The probability and		collision between a SEND node and non-SEND node. The probability and
effects of such an address collision are discussed in [12].		effects of such an address collision are discussed in [13].
9.2.4 Router Solicitation and Advertisement Attacks		9.2.4 Router Solicitation and Advertisement Attacks
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,		These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
and 4.2.7 of [25]. SEND counters these attacks by requiring Router		and 4.2.7 of [26]. SEND counters these attacks by requiring Router
Advertisements to contain a Signature option, and that the signature		Advertisements to contain a Signature option, and that the signature
is calculated using the public key of a node that can prove its		is calculated using the public key of a node that can prove its
authorization to route the subnet prefixes contained in any Prefix		authorization to route the subnet prefixes contained in any Prefix
Information Options. The router proves its authorization by showing		Information Options. The router proves its authorization by showing
a certificate containing the specific prefix or the indication that		a certificate containing the specific prefix or the indication that
the router is allowed to route any prefix. A Router Advertisement		the router is allowed to route any prefix. A Router Advertisement
without these protections is discarded.		without these protections is discarded.
SEND does not protect against brute force attacks on the router, such		SEND does not protect against brute force attacks on the router, such
as DoS attacks, or compromise of the router, as described in Sections		as DoS attacks, or compromise of the router, as described in Sections
4.4.2 and 4.4.3 of [25].		4.4.2 and 4.4.3 of [26].
9.2.5 Replay Attacks		9.2.5 Replay Attacks
This attack is described in Section 4.3.1 of [25]. SEND protects		This attack is described in Section 4.3.1 of [26]. SEND protects
against attacks in Router Solicitation/Router Advertisement and		against attacks in Router Solicitation/Router Advertisement and
Neighbor Solicitation/Neighbor Advertisement transactions by		Neighbor Solicitation/Neighbor Advertisement transactions by
including a Nonce option in the solicitation and requiring the		including a Nonce option in the solicitation and requiring the
advertisement to include a matching option. Together with the		advertisement to include a matching option. Together with the
signatures this forms a challenge-response protocol. SEND protects		signatures this forms a challenge-response protocol. SEND protects
against attacks from unsolicited messages such as Neighbor		against attacks from unsolicited messages such as Neighbor
Advertisements, Router Advertisements, and Redirects by including a		Advertisements, Router Advertisements, and Redirects by including a
Timestamp option. A window of vulnerability for replay attacks		Timestamp option. A window of vulnerability for replay attacks
exists until the timestamp expires.		exists until the timestamp expires.
Skipping to change at page 46, line 7:
containing the timestamp. The cached state allows the node to		containing the timestamp. The cached state allows the node to
protect itself against replayed messages. However, once the node		protect itself against replayed messages. However, once the node
flushes the state for whatever reason, an attacker can re-create the		flushes the state for whatever reason, an attacker can re-create the
state by replaying an old message while the timestamp is still valid.		state by replaying an old message while the timestamp is still valid.
Since most SEND nodes are likely to use fairly coarse grained		Since most SEND nodes are likely to use fairly coarse grained
timestamps, as explained in Section 5.3.1, this may affect some		timestamps, as explained in Section 5.3.1, this may affect some
nodes.		nodes.
9.2.6 Neighbor Discovery DoS Attack		9.2.6 Neighbor Discovery DoS Attack
This attack is described in Section 4.3.2 of [25]. In this attack,		This attack is described in Section 4.3.2 of [26]. In this attack,
the attacker bombards the router with packets for fictitious		the attacker bombards the router with packets for fictitious
addresses on the link, causing the router to busy itself with		addresses on the link, causing the router to busy itself with
performing Neighbor Solicitations for addresses that do not exist.		performing Neighbor Solicitations for addresses that do not exist.
SEND does not address this threat because it can be addressed by		SEND does not address this threat because it can be addressed by
techniques such as rate limiting Neighbor Solicitations, restricting		techniques such as rate limiting Neighbor Solicitations, restricting
the amount of state reserved for unresolved solicitations, and clever		the amount of state reserved for unresolved solicitations, and clever
cache management. These are all techniques involved in implementing		cache management. These are all techniques involved in implementing
Neighbor Discovery on the router.		Neighbor Discovery on the router.
9.3 Attacks against SEND Itself		9.3 Attacks against SEND Itself
The CGAs have a 59-bit hash value. The security of the CGA mechanism		The CGAs have a 59-bit hash value. The security of the CGA mechanism
has been discussed in [12].		has been discussed in [13].
Some Denial-of-Service attacks against NDP and SEND itself remain.		Some Denial-of-Service attacks against NDP and SEND itself remain.
For instance, an attacker may try to produce a very high number of		For instance, an attacker may try to produce a very high number of
packets that a victim host or router has to verify using asymmetric		packets that a victim host or router has to verify using asymmetric
methods. While safeguards are required to prevent an excessive use		methods. While safeguards are required to prevent an excessive use
of resources, this can still render SEND non-operational.		of resources, this can still render SEND non-operational.
When CGA protection is used, SEND deals with the DoS attacks using		When CGA protection is used, SEND deals with the DoS attacks using
the verification process described in Section 5.2.2. In this		the verification process described in Section 5.2.2. In this
process, a simple hash verification of the CGA property of the		process, a simple hash verification of the CGA property of the
Skipping to change at page 49, line 34:
o The Timestamp option, described in Section 5.3.1.		o The Timestamp option, described in Section 5.3.1.
o The Nonce option, described in Section 5.3.2.		o The Nonce option, described in Section 5.3.2.
o The Trust Anchor option, described in Section 6.2.3.		o The Trust Anchor option, described in Section 6.2.3.
o The Certificate option, described in Section 6.2.4.		o The Certificate option, described in Section 6.2.4.
This document defines a new 128-bit value under the CGA Message Type		This document defines a new 128-bit value under the CGA Message Type
[12] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.		[13] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
This document defines a new name space for the Name Type field in the		This document defines a new name space for the Name Type field in the
Trust Anchor option. Future values of this field can be allocated		Trust Anchor option. Future values of this field can be allocated
using Standards Action [6]. The current values for this field are:		using Standards Action [6]. The current values for this field are:
1 DER Encoded X.501 Name		1 DER Encoded X.501 Name
2 FQDN		2 FQDN
Another new name space is allocated for the Cert Type field in the		Another new name space is allocated for the Cert Type field in the
Skipping to change at page 50, line 40:
Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
[9] Conta, A. and S. Deering, "Internet Control Message Protocol		[9] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.		Specification", RFC 2463, December 1998.
[10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509		[10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate		Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.		Revocation List (CRL) Profile", RFC 3280, April 2002.
[11] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP		[11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
		Domain Names in Applications (IDNA)", RFC 3490, March 2003.
		[12] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers",		Addresses and AS Identifiers",
draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in progress),		draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in progress),
September 2003.		September 2003.
[12] Aura, T., "Cryptographically Generated Addresses (CGA)",		[13] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-03 (work in progress), December 2003.		draft-ietf-send-cga-03 (work in progress), December 2003.
[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS		[14] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002.		1, November 2002.
[14] National Institute of Standards and Technology, "Secure Hash		[15] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http://		Standard", FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>.		www.itl.nist.gov/fipspubs/fip180-1.htm>.
Informative References		Informative References
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",		[16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.		RFC 2409, November 1998.
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener		[17] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.		Discovery (MLD) for IPv6", RFC 2710, October 1999.
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless		[18] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.		Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[18] Farrell, S. and R. Housley, "An Internet Attribute Certificate		[19] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.		Profile for Authorization", RFC 3281, April 2002.
[19] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.		[20] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6		Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.		(DHCPv6)", RFC 3315, July 2003.
[20] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)		[21] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.		Addressing Architecture", RFC 3513, April 2003.
[21] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",		[22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
draft-arkko-icmpv6-ike-effects-02 (work in progress), March		draft-arkko-icmpv6-ike-effects-02 (work in progress), March
2003.		2003.
[22] Arkko, J., "Manual SA Configuration for IPv6 Link Local		[23] Arkko, J., "Manual SA Configuration for IPv6 Link Local
Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),		Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
June 2002.		June 2002.
[23] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API		[24] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
for Address Selection", draft-chakrabarti-ipv6-addrselect-02		for Address Selection", draft-chakrabarti-ipv6-addrselect-02
(work in progress), October 2003.		(work in progress), October 2003.
[24] Kent, S., "IP Encapsulating Security Payload (ESP)",		[25] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.		draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.
[25] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor		[26] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery trust models and threats", draft-ietf-send-psreq-04		Discovery trust models and threats", draft-ietf-send-psreq-04
(work in progress), October 2003.		(work in progress), October 2003.
[26] International Organization for Standardization, "The Directory		[27] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000.		- Authentication Framework", ISO Standard X.509, 2000.
[27] Institute of Electrical and Electronics Engineers, "Local and		[28] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",		Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.		IEEE Standard 802.1X, September 2001.
Authors' Addresses		Authors' Addresses
Jari Arkko		Jari Arkko
Ericsson		Ericsson
Jorvas 02420		Jorvas 02420
Finland		Finland
End of changes.
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/