1/base.txt 2/issue27.txt
  Skipping to change at page 3, line 23:
11. Security Considerations . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . 46
11.1 Threats to the Local Link Not Covered by SEND . . . 46 11.1 Threats to the Local Link Not Covered by SEND . . . 46
11.2 How SEND Counters Threats to Neighbor Discovery . . 47 11.2 How SEND Counters Threats to Neighbor Discovery . . 47
11.2.1 Neighbor Solicitation/Advertisement Spoofing .47 11.2.1 Neighbor Solicitation/Advertisement Spoofing .47
11.2.2 Neighbor Unreachability Detection Failure . .48 11.2.2 Neighbor Unreachability Detection Failure . .48
11.2.3 Duplicate Address Detection DoS Attack . . . .48 11.2.3 Duplicate Address Detection DoS Attack . . . .48
11.2.4 Router Solicitation and Advertisement Attacks 49 11.2.4 Router Solicitation and Advertisement Attacks 49
11.2.5 Replay Attacks . . . . . . . . . . . . . . . .49 11.2.5 Replay Attacks . . . . . . . . . . . . . . . .49
11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49 11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49
11.3 Attacks against SEND Itself . . . . . . . . . . . . 50 11.3 Attacks against SEND Itself . . . . . . . . . . . . 50
12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . 52 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . 53 Normative References . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54 Informative References . . . . . . . . . . . . . . . . . . 54
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 56
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 57 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 57
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 58 C. Cache Management . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . 61 D. Comparison to AH-Based Approach . . . . . . . . . . . . . 59
Intellectual Property and Copyright Statements . . . . . . 62
1. Introduction 1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC 2461 [7]. IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC 2461 [7].
Nodes on the same link use NDP to discover each other's presence, to Nodes on the same link use NDP to discover each other's presence, to
determine each other's link-layer addresses, to find routers, and to determine each other's link-layer addresses, to find routers, and to
maintain reachability information about the paths to active maintain reachability information about the paths to active
neighbors. NDP is used both by hosts and routers. Its functions neighbors. NDP is used both by hosts and routers. Its functions
include Neighbor Discovery (ND), Router Discovery (RD), Address include Neighbor Discovery (ND), Router Discovery (RD), Address
Autoconfiguration, Address Resolution, Neighbor Unreachability Autoconfiguration, Address Resolution, Neighbor Unreachability
  Skipping to change at page 28, line 33:
0 0
Checksum Checksum
The ICMP checksum [9]. The ICMP checksum [9].
Identifier Identifier
A 16-bit unsigned integer field, acting as an identifier to A 16-bit unsigned integer field, acting as an identifier to
help matching advertisements to solicitations. The Identifier help matching advertisements to solicitations. The Identifier
field MUST be zero for unsolicited advertisements and MUST NOT field MUST be zero for advertisements sent to the All-Nodes
be zero for solicited advertisements. multicast address and MUST NOT be zero for others.
Component Component
A 16-bit unsigned integer field, used for informing the A 16-bit unsigned integer field, used for informing the
receiver which certificate is being sent, and how many are receiver which certificate is being sent, and how many are
still left to be sent in the whole chain. still left to be sent in the whole chain.
A single advertisement MUST be broken into separately sent A single advertisement MUST be broken into separately sent
components if there is more than one Certificate option, in components if there is more than one Certificate option, in
order to avoid excessive fragmentation at the IP layer. Unlike order to avoid excessive fragmentation at the IP layer. Unlike
  Skipping to change at page 33, line 49:
The contents of the Reserved field, and of any unrecognized options, The contents of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new options; may specify the contents of the Reserved field or add new options;
backward-incompatible changes may use different Code values. The backward-incompatible changes may use different Code values. The
contents of any defined options that are not specified to be used contents of any defined options that are not specified to be used
with Router Solicitation messages MUST be ignored and the packet with Router Solicitation messages MUST be ignored and the packet
processed in the normal manner. The only defined option that may processed in the normal manner. The only defined option that may
appear is the Trust Anchor option. A solicitation that passes the appear is the Trust Anchor option. A solicitation that passes the
validity checks is called a "valid solicitation". validity checks is called a "valid solicitation".
Routers MAY send unsolicited Delegation Chain Advertisements for Routers SHOULD send advertisements in response to valid solicitations
their configured trust anchor(s). When such advertisements are sent, received on an advertising interface. If the source address in the
their timing MUST follow the rules given for Router Advertisements in solicitation was the unspecified address, the router MUST send the
RFC 2461 [7]. The only defined options that may appear are the response to the link-scoped All-Nodes multicast address. If the
Certificate and Trust Anchor options. At least one Certificate source address was a unicast address, the router MUST send the
option MUST be present. Router SHOULD also include at least one response to the Solicited-Node multicast address corresponding to the
Trust Anchor option to indicate the trust anchor on which the source address. Routers SHOULD NOT send Delegation Chain
Certificate is based. Advertisements more than MAX_DCA_RATE times within a second. When
there are more solicitations than this, the router SHOULD send the
In addition to sending periodic, unsolicited advertisements, a router response to the All-Nodes multicast address regardless of the source
sends advertisements in response to valid solicitations received on address that appeared in the solicitation.
an advertising interface. If the source address in the solicitation
was the unspecified address, the router MUST send the response to the
link-scoped All-Nodes multicast address. If the source address was a
unicast address, the router MUST send the response to the
Solicited-Node multicast address corresponding to the source address.
In a solicited-for advertisement, the router SHOULD include suitable In an advertisement, the router SHOULD include suitable Certificate
Certificate options so that a delegation chain to the solicited trust options so that a delegation chain to the solicited trust anchor can
anchor can be established. The anchor is identified by the Trust be established. The anchor is identified by the Trust Anchor option.
Anchor option. If the Trust Anchor option is represented as a DER If the Trust Anchor option is represented as a DER Encoded X.501
Encoded X.501 Name, then the Name must be equal to the Subject field Name, then the Name must be equal to the Subject field in the
in the anchor's certificate. If the Trust Anchor option is anchor's certificate. If the Trust Anchor option is represented as
represented as an FQDN, the FQDN must be equal to an FQDN in the an FQDN, the FQDN must be equal to an FQDN in the subjectAltName
subjectAltName field of the anchor's certificate. The router SHOULD field of the anchor's certificate. The router SHOULD include the
include the Trust Anchor option(s) in the advertisement for which the Trust Anchor option(s) in the advertisement for which the delegation
delegation chain was found. chain was found.
If the router is unable to find a chain to the requested anchor, it If the router is unable to find a chain to the requested anchor, it
SHOULD send an advertisement without any certificates. In this case SHOULD send an advertisement without any certificates. In this case
the router SHOULD include the Trust Anchor options which were the router SHOULD include the Trust Anchor options which were
solicited. solicited.
Rate limiting of Delegation Chain Advertisements is performed as
specified for Router Advertisements in RFC 2461 [7].
6.7 Processing Rules for Hosts 6.7 Processing Rules for Hosts
Hosts SHOULD possess the public key and trust anchor name of at least Hosts SHOULD possess the public key and trust anchor name of at least
one certificate authority, they SHOULD possess their own key pair, one certificate authority, they SHOULD possess their own key pair,
and they MAY posses a certificate from the above mentioned and they MAY posses a certificate from the above mentioned
certificate authority. certificate authority.
A host MUST silently discard any received Delegation Chain A host MUST silently discard any received Delegation Chain
Advertisement messages that do not satisfy all of the following Advertisement messages that do not satisfy all of the following
validity checks: validity checks:
  Skipping to change at page 35, line 50:
chain. Except for temporary purposes to allow for message loss and chain. Except for temporary purposes to allow for message loss and
reordering, hosts SHOULD NOT store certificates received in a reordering, hosts SHOULD NOT store certificates received in a
Delegation Chain Advertisement unless they contain a certificate Delegation Chain Advertisement unless they contain a certificate
which can be immediately verified either to the trust anchor or to a which can be immediately verified either to the trust anchor or to a
certificate which has been verified earlier. certificate 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
network. network.
When an interface becomes enabled, a host may be unwilling to wait The host has a need to retrieve a delegation chain when a Router
for the next unsolicited Delegation Chain Advertisement. To obtain Advertisement has been received with a public key that is not stored
such advertisements quickly, a host MAY transmit up to in the hosts' cache of certificates, or there is no authorization
MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each delegation chain to the host's trust anchor. In these situations,
separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain
Chain Solicitations MAY be sent after any of the following events: Solicitation messages, each separated by at least DCS_INTERVAL
seconds.
o The interface is initialized at system startup time.
o The interface is reinitialized after a temporary interface failure
or after being temporarily disabled by system management.
o The system changes from being a router to being a host, by having
its IP forwarding capability turned off by system management.
o The host attaches to a link for the first time.
o A movement has been indicated by lower layers or has been inferred
from changed information in a Router Advertisement.
o The host re-attaches to a link after being detached for some time.
o A Router Advertisement has been received with a public key that is
not stored in the hosts' cache of certificates, or there is no
authorization delegation chain to the host's trust anchor.
Delegation Chain Solicitations SHOULD NOT be sent if the host has a Delegation Chain Solicitations SHOULD NOT be sent if the host has a
currently valid certificate chain from a reachable router to a trust currently valid certificate chain from a reachable router to a trust
anchor. anchor.
When soliciting certificates for a router, a host MUST send When soliciting certificates for a router, a host MUST send
Delegation Chain Solicitations either to the All-Routers multicast Delegation Chain Solicitations either to the All-Routers multicast
address, if it has not selected a default router yet, or to the address, if it has not selected a default router yet, or to the
default router's IP address, if it has already been selected. default router's IP address, if it has already been selected.
If two hosts want to establish trust with the DCS and DCA messages, If two hosts want to establish trust with the DCS and DCA messages,
the DCS message SHOULD be sent to the Solicited-Node multicast the DCS message SHOULD be sent to the Solicited-Node multicast
address of the receiver. The advertisements SHOULD be sent as address of the receiver. The advertisements SHOULD be sent as
specified above for routers. However, the exact details are left for specified above for routers. However, the exact details are left for
a future specification. a future specification.
Delegation Chain Solicitations SHOULD be rate limited and timed
similarly with Router Solicitations, as specified in RFC 2461 [7].
When processing possible advertisements sent as responses to a When processing possible advertisements sent as responses to a
solicitation, the host MAY prefer to process first those solicitation, the host MAY prefer to process first those
advertisements with the same Identifier field value as in the advertisements with the same Identifier field value as in the
solicitation. This makes Denial-of-Service attacks against the solicitation. This makes Denial-of-Service attacks against the
mechanism harder (see Section 11.3). mechanism harder (see Section 11.3).
7. Securing Neighbor Discovery with SEND 7. Securing Neighbor Discovery with SEND
This section describes how to use the mechanisms from Section 5, This section describes how to use the mechanisms from Section 5,
Section 6, and the reference [12] in order to provide security for Section 6, and the reference [12] in order to provide security for
Neighbor Discovery. Neighbor Discovery.
There is no requirement that nodes use both Secure Neighbor Discovery There is no requirement that nodes use both Secure Neighbor Discovery
(as described in this Section) and Secure Router Discovery (as (as described in this section) and Secure Router Discovery (as
described in Section 8. They MAY be used indepedently. described in Section 8. They MAY be used indepedently.
7.1 Neighbor Solicitation Messages 7.1 Neighbor Solicitation Messages
All Neighbor Solicitation messages are protected with SEND. All Neighbor Solicitation messages are protected with SEND.
7.1.1 Sending Secure Neighbor Solicitations 7.1.1 Sending Secure Neighbor Solicitations
Secure Neighbor Solicitation messages are sent as described in RFC Secure Neighbor Solicitation messages are sent as described in RFC
2461 and 2462, with the additional requirements as listed in the 2461 and 2462, with the additional requirements as listed in the
  Skipping to change at page 51, line 5:
in. in.
Attackers may also target hosts by sending a large number of Attackers may also target hosts by sending a large number of
unnecessary certificate chains, forcing hosts to spend useless memory unnecessary certificate chains, forcing hosts to spend useless memory
and verification resources for them. Hosts can defend against such and verification resources for them. Hosts can defend against such
attacks by limiting the amount of resources devoted to the attacks by limiting the amount of resources devoted to the
certificate chains and their verification. Hosts SHOULD also certificate chains and their verification. Hosts SHOULD also
prioritize advertisements that sent as a response to their prioritize advertisements that sent as a response to their
solicitations above unsolicited advertisements. solicitations above unsolicited advertisements.
12. IANA Considerations 12. Protocol Constants
Host constants:
MAX_DCS_MESSAGES 3 transmissions
DCS_INTERVAL 4 seconds
Router constants:
MAX_DCA_RATE 10 times per second
13. IANA Considerations
This document defines two new ICMP message types, used in This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range: ICMPv6 type numbers from the informational message range:
o The Delegation Chain Solicitation message, described in Section o The Delegation Chain Solicitation message, described in Section
6.1. 6.1.
o The Delegation Chain Advertisement message, described in Section o The Delegation Chain Advertisement message, described in Section
6.2. 6.2.

Diff produced by rfcdiff v0.34, from http://www.levkowetz.com/ietf/tools/rfcdiff/