base.txt   issue28.txt 
  Skipping to change at page 2, line 35:
5.3.1 Timestamp Option . . . . . . . . . . . . . . .19 5.3.1 Timestamp Option . . . . . . . . . . . . . . .19
5.3.2 Nonce Option . . . . . . . . . . . . . . . . .20 5.3.2 Nonce Option . . . . . . . . . . . . . . . . .20
5.3.3 Processing rules for senders . . . . . . . . .21 5.3.3 Processing rules for senders . . . . . . . . .21
5.3.4 Processing rules for receivers . . . . . . . .21 5.3.4 Processing rules for receivers . . . . . . . .21
5.4 Proxy Neighbor Discovery . . . . . . . . . . . . . . 23 5.4 Proxy Neighbor Discovery . . . . . . . . . . . . . . 23
6. Authorization Delegation Discovery . . . . . . . . . . . . 24 6. Authorization Delegation Discovery . . . . . . . . . . . . 24
6.1 Certificate Format . . . . . . . . . . . . . . . . . 24 6.1 Certificate Format . . . . . . . . . . . . . . . . . 24
6.1.1 Router Authorization Certificate Profile . . .24 6.1.1 Router Authorization Certificate Profile . . .24
6.2 Certificate Transport . . . . . . . . . . . . . . . 25 6.2 Certificate Transport . . . . . . . . . . . . . . . 25
6.2.1 Delegation Chain Solicitation Message Format .26 6.2.1 Delegation Chain Solicitation Message Format .26
6.2.2 Delegation Chain Advertisement Message Format 27 6.2.2 Delegation Chain Advertisement Message Format 28
6.2.3 Trust Anchor Option . . . . . . . . . . . . .30 6.2.3 Trust Anchor Option . . . . . . . . . . . . .30
6.2.4 Certificate Option . . . . . . . . . . . . . .31 6.2.4 Certificate Option . . . . . . . . . . . . . .31
6.2.5 Processing Rules for Routers . . . . . . . . .32 6.2.5 Processing Rules for Routers . . . . . . . . .32
6.2.6 Processing Rules for Hosts . . . . . . . . . .33 6.2.6 Processing Rules for Hosts . . . . . . . . . .33
7. Securing Neighbor Discovery with SEND . . . . . . . . . . 36 7. Securing Neighbor Discovery with SEND . . . . . . . . . . 35
7.1 Neighbor Solicitation Messages . . . . . . . . . . . 36 7.1 Neighbor Solicitation Messages . . . . . . . . . . . 35
7.1.1 Sending Secure Neighbor Solicitations . . . .36 7.1.1 Sending Secure Neighbor Solicitations . . . .35
7.1.2 Receiving Secure Neighbor Solicitations . . .36 7.1.2 Receiving Secure Neighbor Solicitations . . .35
7.2 Neighbor Advertisement Messages . . . . . . . . . . 36 7.2 Neighbor Advertisement Messages . . . . . . . . . . 35
7.2.1 Sending Secure Neighbor Advertisements . . . .36 7.2.1 Sending Secure Neighbor Advertisements . . . .35
7.2.2 Receiving Secure Neighbor Advertisements . . .37 7.2.2 Receiving Secure Neighbor Advertisements . . .36
7.3 Other Requirements . . . . . . . . . . . . . . . . . 37 7.3 Other Requirements . . . . . . . . . . . . . . . . . 36
8. Securing Router Discovery with SEND . . . . . . . . . . . 39 8. Securing Router Discovery with SEND . . . . . . . . . . . 38
8.1 Router Solicitation Messages . . . . . . . . . . . . 39 8.1 Router Solicitation Messages . . . . . . . . . . . . 38
8.1.1 Sending Secure Router Solicitations . . . . .39 8.1.1 Sending Secure Router Solicitations . . . . .38
8.1.2 Receiving Secure Router Solicitations . . . .39 8.1.2 Receiving Secure Router Solicitations . . . .38
8.2 Router Advertisement Messages . . . . . . . . . . . 39 8.2 Router Advertisement Messages . . . . . . . . . . . 38
8.2.1 Sending Secure Router Advertisements . . . . .40 8.2.1 Sending Secure Router Advertisements . . . . .39
8.2.2 Receiving Secure Router Advertisements . . . .40 8.2.2 Receiving Secure Router Advertisements . . . .39
8.3 Redirect Messages . . . . . . . . . . . . . . . . . 40 8.3 Redirect Messages . . . . . . . . . . . . . . . . . 39
8.3.1 Sending Redirects . . . . . . . . . . . . . .40 8.3.1 Sending Redirects . . . . . . . . . . . . . .39
8.3.2 Receiving Redirects . . . . . . . . . . . . .41 8.3.2 Receiving Redirects . . . . . . . . . . . . .40
8.4 Other Requirements . . . . . . . . . . . . . . . . . 41 8.4 Other Requirements . . . . . . . . . . . . . . . . . 40
9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 42 9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 41
10. Performance Considerations . . . . . . . . . . . . . . . . 44 10. Performance Considerations . . . . . . . . . . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . 45 11. Security Considerations . . . . . . . . . . . . . . . . . 44
11.1 Threats to the Local Link Not Covered by SEND . . . 45 11.1 Threats to the Local Link Not Covered by SEND . . . 44
11.2 How SEND Counters Threats to Neighbor Discovery . . 46 11.2 How SEND Counters Threats to Neighbor Discovery . . 45
11.2.1 Neighbor Solicitation/Advertisement Spoofing .46 11.2.1 Neighbor Solicitation/Advertisement Spoofing .45
11.2.2 Neighbor Unreachability Detection Failure . .47 11.2.2 Neighbor Unreachability Detection Failure . .46
11.2.3 Duplicate Address Detection DoS Attack . . . .47 11.2.3 Duplicate Address Detection DoS Attack . . . .46
11.2.4 Router Solicitation and Advertisement Attacks 48 11.2.4 Router Solicitation and Advertisement Attacks 47
11.2.5 Replay Attacks . . . . . . . . . . . . . . . .48 11.2.5 Replay Attacks . . . . . . . . . . . . . . . .47
11.2.6 Neighbor Discovery DoS Attack . . . . . . . .48 11.2.6 Neighbor Discovery DoS Attack . . . . . . . .47
11.3 Attacks against SEND Itself . . . . . . . . . . . . 49 11.3 Attacks against SEND Itself . . . . . . . . . . . . 48
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 50 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 49
13. IANA Considerations . . . . . . . . . . . . . . . . . . . 51 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 50
Normative References . . . . . . . . . . . . . . . . . . . 52 Normative References . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . 53 Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 55 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 54
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 55
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 57 C. Cache Management . . . . . . . . . . . . . . . . . . . . . 56
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 58 D. Comparison to AH-Based Approach . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . 61 Intellectual Property and Copyright Statements . . . . . . 60
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 26, line 38:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved | | Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
Source Address Source Address
An IP address assigned to the sending interface, or the A link-local unicast address assigned to the sending interface,
unspecified address if no address is assigned to the sending or the unspecified address if no address is assigned to the
interface. sending interface.
Destination Address Destination Address
Typically the All-Routers multicast address, the Solicited-Node Typically the All-Routers multicast address, the Solicited-Node
multicast address, or the address of the host's default router. multicast address, or the address of the host's default router.
Hop Limit Hop Limit
255 255
ICMP Fields: ICMP Fields:
  Skipping to change at page 27, line 44:
Trust Anchor Trust Anchor
One or more trust anchors that the client is willing to accept. One or more trust anchors that the client is willing to accept.
The first (or only) Trust Anchor option MUST contain a DER The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.2.3. If there are more than Encoded X.501 Name; see Section 6.2.3. If there are more than
one Trust Anchor options, the options past the first one may one Trust Anchor options, the options past the first one may
contain any types of Trust Anchors. contain any types of Trust Anchors.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. and continue processing the message. All included options MUST
have a length that is greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets.
6.2.2 Delegation Chain Advertisement Message Format 6.2.2 Delegation Chain Advertisement Message Format
Routers send out Delegation Chain Advertisement messages in response Routers send out Delegation Chain Advertisement messages in response
to a Delegation Chain Solicitation. to a Delegation Chain Solicitation.
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 | Code | Checksum | | Type | Code | Checksum |
  Skipping to change at page 28, line 21:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
Source Address Source Address
MUST be a unicast address assigned to the interface from which A link-local unicast address assigned to the interface from
this message is sent. which this message is sent. Note that routers may use multiple
addresses, and therefore this address not sufficient for the
unique identification of routers.
Destination Address Destination Address
Either the Solicited-Node multicast address of the receiver or Either the Solicited-Node multicast address of the receiver or
the link-scoped All-Nodes multicast address. the link-scoped All-Nodes multicast address.
Hop Limit Hop Limit
255 255
  Skipping to change at page 30, line 7:
Trust Anchor Trust Anchor
Zero or more Trust Anchor options may be included to help Zero or more Trust Anchor options may be included to help
receivers decide which advertisements are useful for them. If receivers decide which advertisements are useful for them. If
present, these options MUST appear in the first component of a present, these options MUST appear in the first component of a
multi-component advertisement. multi-component advertisement.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. and continue processing the message. All included options MUST
have a length that is greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets.
6.2.3 Trust Anchor Option 6.2.3 Trust Anchor Option
The format of the Trust Anchor option is as described in the The format of the Trust Anchor option is as described in the
following: 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 | Name Type | Pad Length | | Type | Length | Name Type | Pad Length |
  Skipping to change at page 32, line 20:
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 possess a key pair and a certificate from at least one
certificate authority. 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 satisfy all of the following Solicitation messages that do not satisfy all of the following
validity checks: validity checks:
o The IP Hop Limit field MUST have a value of 255, i.e., the packet o All requirements listed in Section 6.2.1 are fulfilled.
could not possibly have been forwarded by a router.
o If the message includes an IP Authentication Header, the message o If the message includes an IP Authentication Header, the message
authenticates correctly. authenticates correctly.
o ICMP Checksum is valid.
o ICMP Code is 0.
o ICMP length (derived from the IP length) is 8 or more octets.
o Identifier field is non-zero.
o All included options have a length that is greater than zero.
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".
  Skipping to change at page 33, line 37:
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:
o IP Source Address MUST be a unicast address. Note that routers o All requirements listed in Section 6.2.2 are fulfilled.
may use multiple addresses, and therefore this address not
sufficient for the unique identification of routers.
o IP Destination Address MUST be either the link-scoped All-Nodes
multicast address or the Solicited-Node multicast address
corresponding to one of the unicast addresses assigned to the
host.
o The IP Hop Limit field MUST have a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
o If the message includes an IP Authentication Header, the message o If the message includes an IP Authentication Header, the message
authenticates correctly. authenticates correctly.
o ICMP Checksum is valid.
o ICMP Code is 0.
o ICMP length (derived from the IP length) is 16 or more octets.
o All included options have a length that is greater than zero.
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 Delegation Chain Advertisement messages MUST be ignored and the with Delegation Chain Advertisement messages MUST be ignored and the
packet processed in the normal manner. The only defined options that packet processed in the normal manner. The only defined options that
may appear are the Certificate and Trust Anchor options. An may appear are the Certificate and Trust Anchor options. An
advertisement that passes the validity checks is called a "valid advertisement that passes the validity checks is called a "valid
advertisement". advertisement".
 End of changes. 

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