base.txt   issue45.txt 
  Skipping to change at page 3, line 17:
8.3 Redirect Messages . . . . . . . . . . . . . . . . . 40 8.3 Redirect Messages . . . . . . . . . . . . . . . . . 40
8.3.1 Sending Redirects . . . . . . . . . . . . . .41 8.3.1 Sending Redirects . . . . . . . . . . . . . .41
8.3.2 Receiving Redirects . . . . . . . . . . . . .41 8.3.2 Receiving Redirects . . . . . . . . . . . . .41
8.4 Other Requirements . . . . . . . . . . . . . . . . . 41 8.4 Other Requirements . . . . . . . . . . . . . . . . . 41
9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 43 9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 43
10. Performance Considerations . . . . . . . . . . . . . . . . 45 10. Performance Considerations . . . . . . . . . . . . . . . . 45
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 . . 46 11.2 How SEND Counters Threats to Neighbor Discovery . . 46
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 . .47
11.2.3 Duplicate Address Detection DoS Attack . . . .48 11.2.3 Duplicate Address Detection DoS Attack . . . .47
11.2.4 Router Solicitation and Advertisement Attacks 48 11.2.4 Router Solicitation and Advertisement Attacks 48
11.2.5 Replay Attacks . . . . . . . . . . . . . . . .48 11.2.5 Replay Attacks . . . . . . . . . . . . . . . .48
11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49 11.2.6 Neighbor Discovery DoS Attack . . . . . . . .49
11.3 Attacks against SEND Itself . . . . . . . . . . . . 49 11.3 Attacks against SEND Itself . . . . . . . . . . . . 49
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 51 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 51
13. IANA Considerations . . . . . . . . . . . . . . . . . . . 52 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 52
Normative References . . . . . . . . . . . . . . . . . . . 53 Normative References . . . . . . . . . . . . . . . . . . . 53
Informative References . . . . . . . . . . . . . . . . . . 54 Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 57 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 57
  Skipping to change at page 36, line 26:
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
following: following:
All Neighbor Solicitation messages sent MUST contain the Nonce, All Neighbor Solicitation messages sent MUST contain the Nonce,
Timestamp, and Signature options, and MAY contain the CGA option. Timestamp, CGA, and Signature options. The Signature option MUST
The Signature option MUST be constructed with the sender's key be constructed with the sender's key pair, using the configured
pair, using the configured authorization method(s), and if authorization method(s), and if applicable, using the trust anchor
applicable, using the trust anchor and/or minSec value as and/or minSec value as configured.
configured.
7.1.2 Receiving Secure Neighbor Solicitations 7.1.2 Receiving Secure Neighbor Solicitations
Received Neighbor Solicitation messages are processed as described in Received Neighbor Solicitation messages are processed as described in
RFC 2461 and 2462, with the additional SEND-related requirements as RFC 2461 and 2462, with the additional SEND-related requirements as
listed in the following: listed in the following:
Neighbor Solicitation messages received without the Nonce, Neighbor Solicitation messages received without the Nonce,
Timestamp, or Signature option MUST be silently discarded. The Timestamp, or Signature option MUST be silently discarded. The
Signature option MUST be constructed with the expected Signature option MUST be constructed with the expected
  Skipping to change at page 39, line 23:
All Router Solicitation messages are protected with SEND. All Router Solicitation messages are protected with SEND.
8.1.1 Sending Secure Router Solicitations 8.1.1 Sending Secure Router Solicitations
Secure Router Solicitation messages are sent as described in RFC Secure Router Solicitation messages are sent as described in RFC
2461, with the additional requirements as listed in the following: 2461, with the additional requirements as listed in the following:
Router Solicitation messages sent with an unspecified source Router Solicitation messages sent with an unspecified source
address MUST have the Nonce and Timestamp options. address MUST have the Nonce and Timestamp options.
Other Router Solicitations MUST have the Nonce, Timestamp, and Other Router Solicitations MUST have the Nonce, Timestamp, CGA,
Signature options. The Signature option MUST be configured with and Signature options. The Signature option MUST be configured
the sender's key pair, setting the authorization method and with the sender's key pair, setting the authorization method and
additional information as is configured. additional information as is configured.
8.1.2 Receiving Secure Router Solicitations 8.1.2 Receiving Secure Router Solicitations
Received Router Solicitation messages are processed as described in Received Router Solicitation messages are processed as described in
RFC 2461, with the additional SEND-related requirements as listed in RFC 2461, with the additional SEND-related requirements as listed in
the following: the following:
Router Solicitation message sent with an unspecified source Router Solicitation message sent with an unspecified source
address and without the Nonce or Timestamp options MUST be address and without the Nonce or Timestamp options MUST be
  Skipping to change at page 43, line 20:
the use of SEND and the legacy Neighbor Discovery Protocol at the the use of SEND and the legacy Neighbor Discovery Protocol at the
same time. same time.
In a mixed environment, SEND nodes receive both secure and insecure In a mixed environment, SEND nodes receive both secure and insecure
messages but give priority to "secured" ones. Here, the "secured" messages but give priority to "secured" ones. Here, the "secured"
messages are ones that contain a valid signature option, as specified messages are ones that contain a valid signature option, as specified
above, and "insecure" messages are ones that contain no signature above, and "insecure" messages are ones that contain no signature
option. option.
SEND nodes send only secured messages. Legacy Neighbor Discovery SEND nodes send only secured messages. Legacy Neighbor Discovery
nodes will obviously send only insecure messages. Such nodes will nodes will obviously send only insecure messages. Per RFC 2461 [7],
(as per RFC 2461 [7]) ignore the unknown options and will treat such nodes will ignore the unknown options and will treat secured
secured messages in the same way as they treat insecure ones. messages in the same way as they treat insecure ones. Secured and
Secured and insecure nodes share the same network resources, such as insecure nodes share the same network resources, such as prefixes and
prefixes and address spaces. address spaces.
In a mixed environment SEND routers and hosts follow the protocols In a mixed environment SEND nodes follow the protocols defined in RFC
defined in RFC 2461 and RFC 2462 with the following exceptions: 2461 and RFC 2462 with the following exceptions:
All solicitations sent by SEND nodes MUST be secured. All solicitations sent by SEND nodes MUST be secured.
Unsolicited Neighbor and Router Advertisements sent by a SEND Unsolicited advertisements sent by a SEND node MUST be secured.
router MUST be secured.
Secured solicitations MUST contain the Nonce option. Secured A SEND node MUST send a secured advertisement in response to a
advertisements sent in response to a secured solicitation MUST secured solicitation. Advertisements sent in response to an
contain a copy of the Nonce option from the solicitation. insecure solicitation MUST be secured as well, but MUST NOT
Unsolicited advertisements and ones sent in response to an contain the Nonce option.
insecure solicitation MUST NOT contain the Nonce option.
A SEND node that uses the CGA authorization method for protecting A SEND node that uses the CGA authorization method for protecting
Neighbor Solicitations SHOULD perform Duplicate Address Detection Neighbor Solicitations SHOULD perform Duplicate Address Detection
as follows. If Duplicate Address Detection indicates the as follows. If Duplicate Address Detection indicates the
tentative address is already in use, generate a new tentative CGA tentative address is already in use, generate a new tentative CGA
address. If after 3 consecutive attempts no non-unique address address. If after 3 consecutive attempts no non-unique address
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.
The node SHOULD have a configuration option that causes it to 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
recovery mechanism for the unlikely case that attacks against the recovery mechanism, in case attacks against the first address
first address become common.) become common.
The Neighbor Cache, Prefix List and Default Router list entries 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 cause an
update of the matching entries and flagging of them as secured. update of the matching entries and flagging of them as secured.
The conceptual sending algorithm is modified so that an insecure 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.
A SEND node SHOULD have a configuration option that causes it to A SEND node SHOULD have a configuration option that causes it to
ignore all insecure ND, RD and Redirect messages. (This can be ignore all insecure Neighbor Solicitation and Advertisement,
used to enforce SEND-only networks.) Router Solicitation and Advertisement, and Redirect messages.
This can be used to enforce SEND-only networks.
10. Performance Considerations 10. Performance Considerations
The computations related to the Signature option are computationally The computations related to the Signature option are computationally
relatively expensive. In the application which Signature option has relatively expensive. In the application which Signature option has
been designed for, however, the nodes typically have the need to been designed for, however, the nodes typically have the need to
perform only a few signature operations as they enter a link, and a 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 few operations as they find a new on-link peer with which to
communicate. communicate.
  Skipping to change at page 47, line 9:
11.2 How SEND Counters Threats to Neighbor Discovery 11.2 How SEND Counters Threats to Neighbor Discovery
The SEND protocol is designed to counter the threats to IPv6 Neighbor The SEND protocol is designed to counter the threats to IPv6 Neighbor
Discovery, as outlined in [27]. The following subsections contain a Discovery, as outlined in [27]. The following subsections contain a
regression of the SEND protocol against the threats, to illustrate regression of the SEND protocol against the threats, to illustrate
what aspects of the protocol counter each threat. what aspects of the protocol counter each threat.
11.2.1 Neighbor Solicitation/Advertisement Spoofing 11.2.1 Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [27]. The threat is that This threat is defined in Section 4.1.1 of [27]. The threat is that
a spoofed Neighbor Solicitation or Neighbor Advertisement causes a a spoofed message may cause a false entry in a node's Neighbor Cache.
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. There are two cases: Router Solicitation. A router receiving a Router Solicitation
with a firm IPv6 source address and a Target Link-Layer Address
1. A router receiving a Router Solicitation with a firm IPv6 extension inserts an entry for the IPv6 address into its Neighbor
source address and a Target Link-Layer Address extension Cache. Also, a node performing Duplicate Address Detection (DAD)
inserts an entry for the IPv6 address into its Neighbor that receives a Neighbor Solicitation for the same address
Cache. regards the situation as a collision and ceases to solicit for
the address.
2. A node doing Duplicate Address Detection (DAD) that receives
a Neighbor Solicitation for the same address regards the
situation as a collision and ceases to solicit for the
address.
2. Entries made as a result of a Neighbor Advertisement sent as a
response to a Neighbor Solicitation for purposes of on-link
address resolution.
11.2.1.1 Solicitations with Effect
SEND counters the threat of solicitations with effect in the
following ways:
1. As discussed in Section 5, SEND nodes preferably send Router
Solicitations with a CGA address and a Signature option, which
the router can verify, so the Neighbor Cache binding is correct.
If a SEND node must send a Router Solicitation with the
unspecified address, the router will not update its Neighbor
Cache, as per RFC 2461.
See Section 11.2.5, below, for discussion about replay protection and In either case, SEND counters these treats by requiring the
timestamps. Signature and CGA options to be present in such solicitations.
11.2.1.2 Address Resolution As discussed in Section 8.1, SEND nodes preferably send Router
Solicitations with a CGA source address, which the router can
verify, so the Neighbor Cache binding is correct. If a SEND node
must send a Router Solicitation with the unspecified address, the
router will not update its Neighbor Cache, as per RFC 2461.
SEND counters attacks on address resolution by requiring that the 2. Entries made as a result of a Neighbor Advertisement message.
responding node include a signature option on the packet, and that SEND counters this threat by requiring the Signature and CGA
the node's interface identifier either be a CGA, or that the node be options to be present in these advertisements.
able to produce a certificate authorizing that node to use the public
key.
The Neighbor Solicitation and Advertisement pairs implement a See also Section 11.2.5, below, for discussion about replay
challenge-response protocol, as explained in Section 7 and discussed protection and timestamps.
in Section 11.2.5 below.
11.2.2 Neighbor Unreachability Detection Failure 11.2.2 Neighbor Unreachability Detection Failure
This attack is described in Section 4.1.2 of [27]. SEND counters This attack is described in Section 4.1.2 of [27]. 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.
 End of changes. 

This html diff was produced by rfcdiff v0.42, available from http://www.levkowetz.com/ietf/tools/rfcdiff/