base.txt		issue54.txt
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 . . . . . . . . . 21		5.3.3 Processing rules for senders . . . . . . . . . 22
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
Skipping to change at page 3, line 12:
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49
Normative References . . . . . . . . . . . . . . . . . . . . 50		Normative References . . . . . . . . . . . . . . . . . . . . 50
Informative References . . . . . . . . . . . . . . . . . . . 52		Informative References . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 55		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 55
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 56		C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 57		Intellectual Property and Copyright Statements . . . . . . . 57
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
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 [22, 16]. Furthermore, the number of such		problems in using IKE [21, 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 [23], making that approach impractical for most		can be very large [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 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
[13].		[13].
Skipping to change at page 12, line 44:
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		It begins after the ASN.1 encoding of the previous field has
ended, and continues to the end of the option, as specified by the		ended, and continues to the end of the option, as specified by the
Length 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 MUST be present in Router Solicitation
with the unspecified source address. The CGA option MAY be present		messages unless they are sent with the unspecified source address.
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 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 [13].		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
Skipping to change at page 14, line 17:
algorithm described in Section 5 of [13]. 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.
		However, even if the CGA verification succeeds, no claims about
		the validity of the use can be made, until the signature has been
		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 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:
Skipping to change at page 17, line 5:
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 [14].		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).
		Padding
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.
Skipping to change at page 21, line 40:
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
A field containing a random number selected by the sender of the		A field containing a random number selected by the sender of the
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.		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.
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-for advertisements MUST include a Nonce, copying the
nonce value from the received solicitation. Note that routers may		nonce value from the received solicitation. Note that routers may
decide to send a multicast advertisement to all nodes instead of a		decide to send a multicast advertisement to all nodes instead of a
Skipping to change at page 23, line 39:
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 per each peer:
The receive time of the last received, accepted SEND message.		The receive time of the last received, accepted SEND message.
This is called RDlast.		This is called RDlast.
The time stamp in the last received, accepted SEND message. This		The time stamp in the last received, accepted SEND message. This
is called TSlast.		is called TSlast.
		An accepted SEND message is any successfully verified Neighbor
		Solicitation, Neighbor Advertisement, Router Solicitation, Router
		Advertisement, or Redirect message from the given peer. It is
		required that the Signature option has been used in such a message
		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
Skipping to change at page 35, line 9:
receivers.		receivers.
Certificate		Certificate
When the Cert Type field is set to 1, the Certificate field		When the Cert Type field is set to 1, the Certificate field
contains an X.509v3 certificate [10], as described in Section		contains an X.509v3 certificate [10], as described in Section
6.1.1.		6.1.1.
6.2.5 Processing Rules for Routers		6.2.5 Processing Rules for Routers
Routers SHOULD possess a key pair and a certificate from at least one		Routers should be configured with a key pair and a certificate from
certificate authority.		at least one certificate authority.
A router MUST silently discard any received Delegation Chain		A router MUST silently discard any received Delegation Chain
Solicitation messages that do not conform to the message format		Solicitation messages that do not conform to the message format
defined in Section 6.2.1. The contents of the Reserved field, and of		defined in Section 6.2.1. 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 may use different Code values. The contents of any defined
options that are not specified to be used with Router Solicitation		options that are not specified to be used with Router Solicitation
messages MUST be ignored and the packet processed in the normal		messages MUST be ignored and the packet processed in the normal
Skipping to change at page 36, line 29:
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 may 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 SHOULD 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.		which has been verified earlier.
Note that it may be useful to cache this information and implied		Note that it may be useful to cache this information and implied
verification results for use over multiple attachments to the		verification results for use over multiple attachments to the
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 [13] for each new		new CGA as specified in Section 4 of [13] each time they run the
autoconfiguration run. The nodes MAY continue to use the same public		autoconfiguration procedure. The nodes MAY continue to use the same
key and modifier, and start the process from Step 4 of the generation		public key and modifier, and start the process from Step 4 of the
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 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 [24].		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.
Skipping to change at page 38, line 51:
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
MAY simply discard the insecure information.		MAY simply discard the insecure information.
Certified prefixes fall into the following two categories:		Certified prefixes fall into the following two categories:
Constrained		Constrained
If the network operator wants to constrain which routers are		If the network operator wants to constrain which routers are
allowed to route particular prefixes, routers SHOULD be configured		allowed to route particular prefixes, routers should be configured
with certificates having prefixes listed in the prefix extension.		with certificates having prefixes listed in the prefix extension.
Routers so configured SHOULD advertise the prefixes which they are		Routers so configured SHOULD advertise the prefixes which they are
certified to route, or a subset thereof.		certified to route, or a subset thereof.
Unconstrained		Unconstrained
Network operators that do not want to constrain routers this way		Network operators that do not want to constrain routers this way
SHOULD configure routers with certificates containing either the		should configure routers with certificates containing either the
null prefix or no prefix extension at all.		null prefix or no prefix extension at all.
Upon processing a Prefix Information option within a Router		Upon processing a Prefix Information option within a Router
Advertisement, nodes SHOULD verify that the prefix specified in this		Advertisement, nodes SHOULD verify that the prefix specified in this
option falls within the range defined by the certificate, if the		option falls within the range defined by the certificate, if the
certificate contains a prefix extension. Options failing this check		certificate contains a prefix extension. Options failing this check
are treated as containing uncertified prefixes.		are treated as containing uncertified prefixes.
Nodes SHOULD use one of the certified prefixes for stateless		Nodes SHOULD use one of the certified prefixes for stateless
autoconfiguration. If none of the advertised prefixes match, the		autoconfiguration. If none of the advertised prefixes match, the
Skipping to change at page 41, line 52:
was generated, log a system error and give up attempting to		was generated, log a system error and give up attempting to
generate an address for that interface.		generate 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 SHOULD have a configuration option that causes it to		o The node MAY have a configuration option that causes it to ignore
ignore insecure advertisements even when performing Duplicate		insecure advertisements even when performing Duplicate Address
Address Detection for the first tentative address. This		Detection for the first tentative address. This configuration
configuration option SHOULD be disabled by default. This is a		option SHOULD be disabled by default. This is a recovery
recovery mechanism, in case attacks against the first address		mechanism, in case attacks against the first address become
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. Received secured messages MUST cause
an 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
Skipping to change at page 43, line 50:
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 [26]. The following subsections contain a regression of		outlined in [24]. 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 [26]. The threat is that		This threat is defined in Section 4.1.1 of [24]. 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 [26]. SEND counters		This attack is described in Section 4.1.2 of [24]. 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 [26]. SEND counters		This attack is described in Section 4.1.3 of [24]. 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 performing DAD, it may listen for address
nodes, the SEND node ignores any insecure Neighbor Solicitations or		collisions from non-SEND nodes for the first address it generates,
Advertisements that may be send by the non-SEND nodes. This protects		but not for new attempts. This protects the SEND node from DAD DoS
the SEND node from DAD DoS attacks by non-SEND nodes or attackers		attacks by non-SEND nodes or attackers simulating to non-SEND nodes,
simulating to non-SEND nodes, at the cost of a potential address		at the cost of a potential address collision between a SEND node and
collision between a SEND node and non-SEND node. The probability and		non-SEND node. The probability and effects of such an address
effects of such an address collision are discussed in [13].		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 [26]. SEND counters these attacks by requiring Router		and 4.2.7 of [24]. 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 [26].		4.4.2 and 4.4.3 of [24].
9.2.5 Replay Attacks		9.2.5 Replay Attacks
This attack is described in Section 4.3.1 of [26]. SEND protects		This attack is described in Section 4.3.1 of [24]. 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 [26]. In this attack,		This attack is described in Section 4.3.2 of [24]. 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
Skipping to change at page 46, line 32:
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
address is performed before performing the more expensive signature		address is performed before performing the more expensive signature
verification.		verification. However, even if the CGA verification succeeds, no
		claims about the validity of the message can be made, until the
		signature has been checked.
When trust anchors and certificates are used for address validation		When trust anchors and certificates are used for address validation
in SEND, the defenses are not quite as effective. Implementations		in SEND, the defenses are not quite as effective. Implementations
SHOULD track the resources devoted to the processing of packets		SHOULD track the resources devoted to the processing of packets
received with the Signature option, and start selectively discarding		received with the Signature option, and start selectively discarding
packets if too many resources are spent. Implementations MAY also		packets if too many resources are spent. Implementations MAY also
first discard packets that are not protected with CGA.		first discard packets that are not protected with CGA.
The Authorization Delegation Discovery process may also be vulnerable		The Authorization Delegation Discovery process may also be vulnerable
to Denial-of-Service attacks. An attack may target a router by		to Denial-of-Service attacks. An attack may target a router by
Skipping to change at page 52, line 23:
[18] 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.
[19] 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.
[20] 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.
[21] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)		[21] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
Addressing Architecture", RFC 3513, April 2003.
[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.
[23] Arkko, J., "Manual SA Configuration for IPv6 Link Local		[22] 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.
[24] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API		[23] 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.
[25] Kent, S., "IP Encapsulating Security Payload (ESP)",		[24] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.
[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.
[27] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000.
[28] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
Authors' Addresses		Authors' Addresses
Jari Arkko		Jari Arkko
Ericsson		Ericsson
Jorvas 02420		Jorvas 02420
Finland		Finland
EMail: jari.arkko@ericsson.com		EMail: jari.arkko@ericsson.com
James Kempf		James Kempf
DoCoMo Communications Labs USA		DoCoMo Communications Labs USA
181 Metro Drive		181 Metro Drive
San Jose, CA 94043		San Jose, CA 94043
USA		USA
EMail: kempf@docomolabs-usa.com		EMail: kempf@docomolabs-usa.com
Bill Sommerfeld		Bill Sommerfeld
Sun Microsystems		Sun Microsystems
End of changes.
This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/