base.txt		issue56.txt
Skipping to change at page 5, line 40:
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 but ND.
Neighbor Unreachability Detection (NUD)		Neighbor Unreachability Detection (NUD)
This mechanism is used for tracking the reachability of neighbors.		This mechanism is used for tracking the reachability of neighbors.
Nonce		Nonce
A random number generated by a node and used exactly once. In		An unpredictable random or pseudorandom number generated by a node
SEND, nonces are used to ensure that a particular advertisement is		and used exactly once. In SEND, nonces are used to ensure that a
linked to the solicitation that triggered it.		particular advertisement is linked to the solicitation that
		triggered it.
Router Authorization Certificate		Router Authorization Certificate
An X.509v3 [10] certificate using the profile specified in Section		An X.509v3 [10] certificate using the profile specified in Section
6.1.1.		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 mechanisms.
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.
Skipping to change at page 8, line 29:
The NDP messages follow the ICMPv6 message format. All NDP functions		The NDP messages follow the ICMPv6 message format. All NDP functions
are realized using the Router Solicitation (RS), Router Advertisement		are realized using the Router Solicitation (RS), Router Advertisement
(RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and		(RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and
Redirect messages. An actual NDP message includes an NDP message		Redirect messages. An actual NDP message includes an NDP message
header, consisting of an ICMPv6 header and ND message-specific data,		header, consisting of an ICMPv6 header and ND message-specific data,
and zero or more NDP options. The NDP message options are formatted		and zero or more NDP options. The NDP message options are formatted
in the Type-Length-Value format.		in the Type-Length-Value format.
<------------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, a set of new Neighbor Discovery
options is introduced. They are used in to protect NDP messages.		options is introduced. They are used in to protect NDP messages.
This specification introduces these options, an authorization		This specification introduces these options, an authorization
Skipping to change at page 9, line 27:
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 this 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 or Router Advertisement 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 needs to be generated
by all nodes before they can claim an address. A new NDP option,		by all nodes before they can claim an address. A new NDP option,
the CGA option, is used to carry the public key and associated		the CGA 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 one to use non-CGA addresses and to
use certificates to authorize their use. However, the details of		use certificates to authorize their use. However, the details of
such use have been left for future work.		such use have been left for future work.
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
Skipping to change at page 12, line 24:
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 [12].
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 [12].
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		Signature option are present, then the publicKey field in the CGA
former option MUST be the public key referred by the Key Hash		option MUST be the public key referred by the Key Hash field in
field in the latter option. Packets received with two different		the Signature option. Packets received with two different keys
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 ends,		It begins after the ASN.1 encoding of the previous field has
and continues to the end of the option, as specified by the Length		ended, and continues to the end of the option, as specified by the
field.		Length 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 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.
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 for the		algorithm described in Section 5 of [12]. The inputs to the
algorithm are the contents of the Collision Cnt, Modifier, and the		algorithm are the claimed address, as defined in the previous
Key Information fields, the claimed address in the packet (as		section, and the concatenation from left to right of the following
discussed in the previous section), and the minimum acceptable Sec		data: the contents of the 8-octet Modifier field, the 8-octet
value. If the CGA verification is successful, the recipient		subnet-prefix part of the claimed address, the content of the
proceeds with the cryptographically more time consuming check of		1-octet Collision Cnt field, and contents of the variable-length
the signature.		Key Information Field.
Note that a receiver which does not support CGA or has not specified		If the CGA verification is successful, the recipient proceeds with
		the cryptographically more time consuming check of the signature.
		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 CGA had been used on a packet. In such a case, the
CGA property of the address is simply left unverified.		CGA 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
Skipping to change at page 14, line 37:
The minimum acceptable key length for the public keys used in the		The minimum acceptable key length for the public keys used in the
generation of the CGA address. The default SHOULD be 1024 bits.		generation of the CGA address. 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.
(see Section 2 in [12]). This parameter is intended to facilitate		This parameter is intended to facilitate future extensions and
future extensions and experimental work. Currently, the minSec		experimental work. Currently, the minSec value SHOULD always be
value SHOULD always be set to zero.		set to zero.
		See Section 2 in [12].
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
The Signature option allows public-key based signatures to be		The Signature option allows public-key based signatures to be
attached to NDP messages. Both trust anchor authentication and CGAs		attached to NDP messages. Configured trust anchors, CGAs, or both
can be used. The format of the Signature option is described in the		can be used as the trusted root. The format of the Signature option
following:		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 | Pad Length | Reserved |		| Type | Length | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |		| |
| Key Hash |		| Key Hash |
| |		| |
| |		| |
Skipping to change at page 16, line 14:
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 contains the most significant (leftmost) 128-bits
of a SHA1 hash of the public key used for the constructing the		of a SHA-1 hash of the public key used for the constructing the
signature. The SHA1 is taken over the presentation used in the		signature. The SHA-1 is taken over the presentation used in the
Key Information field in the CGA option. Its purpose is to		Key Information field in 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 the signature constructed using		A variable length field contains a PKCS#1 signature constructed
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 Type Tag [12] value for SEND, 0x086F CA5E 10B2		1. The 128-bit CGA Message Type tag [12] value for SEND, 0x086F
00C9 9C8C E001 6427 7C08 (generated randomly).		CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
		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 is constructed using the RSA algorithm and MUST be		The signature value is computed with the RSASSA-PKCS1-v1_5
encoded as private key encryption in PKCS#1 format [13]. The		algorithm and SHA-1 hash as defined in [13].
signature value is computed with the RSASSA-PKCS1-v1_5 algorithm
and SHA-1 hash as defined in [13].
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
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,		Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages MUST contain the Signature option. Router		and Redirect messages MUST contain the Signature option. Router
Solicitation messages not sent with the unspecified source address		Solicitation messages not sent with the unspecified source address
MUST contain the Signature option.		MUST contain the Signature option.
A node sending a message using the Signature option MUST construct		A node sending a message using the Signature option MUST construct
the message as follows:		the message as follows:
Skipping to change at page 18, line 10:
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, or one known by
other means.		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.		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
Skipping to change at page 19, line 46:
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 discussed 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 is known. Typically, solicited advertisements are		advertisements is known. Typically, solicited advertisements are
sent to the unicast address from which the solicitation was sent.		sent to the unicast address from which the solicitation was sent.
Given that the IPv6 header is covered by the signature, it is not		Given that the IPv6 header is covered by the signature, it is not
possible to precompute solicited-for advertisements.		possible to precompute solicited-for advertisements.
Skipping to change at page 38, line 12:
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 [12] 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.		key and modifier, and start the process from Step 4 of the 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 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 [23].
7.2 Redirect Addresses		7.2 Redirect Addresses
Skipping to change at page 41, line 6:
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 SHOULD have a configuration option that causes it to		o The node SHOULD have a configuration option that causes it to
ignore insecure advertisements even when performing Duplicate		ignore insecure advertisements even when performing Duplicate
Address Detection for the first tentative address. This		Address Detection for the first tentative address. This
configuration option SHOULD be disabled by default. This is		configuration option SHOULD be disabled by default. This is a
recovery mechanism, in case attacks against the first address		recovery mechanism, in case attacks against the first address
become common.		become 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 cause an		List or Default Router List. Received secured messages MUST cause
update of the matching entries and flagging of them as secured.		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.
End of changes.
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/