base.txt   issue43.txt 
  Skipping to change at page 1, line 39:
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 18, 2004. This Internet-Draft will expire on June 19, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine each the link-layer addresses other nodes on the link, to determine each the link-layer addresses
of the nodes on the link, to find routers, and to maintain of the nodes on the link, to find routers, and to maintain
  Skipping to change at page 3, line 8:
7.2.2 Receiving Secure Neighbor Advertisements . . .36 7.2.2 Receiving Secure Neighbor Advertisements . . .36
7.3 Other Requirements . . . . . . . . . . . . . . . . . 36 7.3 Other Requirements . . . . . . . . . . . . . . . . . 36
8. Securing Router Discovery with SEND . . . . . . . . . . . 38 8. Securing Router Discovery with SEND . . . . . . . . . . . 38
8.1 Router Solicitation Messages . . . . . . . . . . . . 38 8.1 Router Solicitation Messages . . . . . . . . . . . . 38
8.1.1 Sending Secure Router Solicitations . . . . .38 8.1.1 Sending Secure Router Solicitations . . . . .38
8.1.2 Receiving Secure Router Solicitations . . . .38 8.1.2 Receiving Secure Router Solicitations . . . .38
8.2 Router Advertisement Messages . . . . . . . . . . . 38 8.2 Router Advertisement Messages . . . . . . . . . . . 38
8.2.1 Sending Secure Router Advertisements . . . . .39 8.2.1 Sending Secure Router Advertisements . . . . .39
8.2.2 Receiving Secure Router Advertisements . . . .39 8.2.2 Receiving Secure Router Advertisements . . . .39
8.3 Redirect Messages . . . . . . . . . . . . . . . . . 39 8.3 Redirect Messages . . . . . . . . . . . . . . . . . 39
8.3.1 Sending Redirects . . . . . . . . . . . . . .39 8.3.1 Sending Redirects . . . . . . . . . . . . . .40
8.3.2 Receiving Redirects . . . . . . . . . . . . .40 8.3.2 Receiving Redirects . . . . . . . . . . . . .40
8.4 Other Requirements . . . . . . . . . . . . . . . . . 40 8.4 Other Requirements . . . . . . . . . . . . . . . . . 40
9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 41 9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 42
10. Performance Considerations . . . . . . . . . . . . . . . . 43 10. Performance Considerations . . . . . . . . . . . . . . . . 44
11. Security Considerations . . . . . . . . . . . . . . . . . 44 11. Security Considerations . . . . . . . . . . . . . . . . . 45
11.1 Threats to the Local Link Not Covered by SEND . . . 44 11.1 Threats to the Local Link Not Covered by SEND . . . 45
11.2 How SEND Counters Threats to Neighbor Discovery . . 45 11.2 How SEND Counters Threats to Neighbor Discovery . . 46
11.2.1 Neighbor Solicitation/Advertisement Spoofing .45 11.2.1 Neighbor Solicitation/Advertisement Spoofing .46
11.2.2 Neighbor Unreachability Detection Failure . .46 11.2.2 Neighbor Unreachability Detection Failure . .47
11.2.3 Duplicate Address Detection DoS Attack . . . .46 11.2.3 Duplicate Address Detection DoS Attack . . . .47
11.2.4 Router Solicitation and Advertisement Attacks 47 11.2.4 Router Solicitation and Advertisement Attacks 48
11.2.5 Replay Attacks . . . . . . . . . . . . . . . .47 11.2.5 Replay Attacks . . . . . . . . . . . . . . . .48
11.2.6 Neighbor Discovery DoS Attack . . . . . . . .47 11.2.6 Neighbor Discovery DoS Attack . . . . . . . .48
11.3 Attacks against SEND Itself . . . . . . . . . . . . 48 11.3 Attacks against SEND Itself . . . . . . . . . . . . 49
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 49 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . 50
13. IANA Considerations . . . . . . . . . . . . . . . . . . . 50 13. IANA Considerations . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . 51 Normative References . . . . . . . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . 52 Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 54 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 55
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 55 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 56
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 56 C. Cache Management . . . . . . . . . . . . . . . . . . . . . 57
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 57 D. Comparison to AH-Based Approach . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . 60 Intellectual Property and Copyright Statements . . . . . . 61
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 39, line 41:
The Signature option MUST be constructed with the configured The Signature option MUST be constructed with the configured
authorization method(s), the used key being within the configured authorization method(s), the used key being within the configured
minimum (and maximum) allowable key size, and if applicable, using minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value. an acceptable trust anchor and/or minSec value.
The configured authorization methods MUST include the trust anchor The configured authorization methods MUST include the trust anchor
authorization method, and MAY be additionally configured to authorization method, and MAY be additionally configured to
require CGA authorization. require CGA authorization.
The sender's certificate defines the address range(s) that this
router is allowed to advertise. Upon processing a Prefix
Information option within a Router Advertisement, the receiver
MUST verify that the prefix specified in this option falls within
the range defined by the certificate. Router Advertisements
failing this check MUST be silently discarded.
8.3 Redirect Messages 8.3 Redirect Messages
All Redirect messages are protected with SEND. All Redirect messages are protected with SEND.
8.3.1 Sending Redirects 8.3.1 Sending Redirects
Secure Redirect messages are sent as described in RFC 2461, with the Secure Redirect messages are sent as described in RFC 2461, with the
additional requirements as listed in the following: additional requirements as listed in the following:
All Redirect messages sent MUST contain the Timestamp and All Redirect messages sent MUST contain the Timestamp and
  Skipping to change at page 40, line 30:
an acceptable trust anchor and/or minSec value. an acceptable trust anchor and/or minSec value.
The configured authorization methods MUST include the trust anchor The configured authorization methods MUST include the trust anchor
authorization method, and MAY be additionally configured to authorization method, and MAY be additionally configured to
require CGA authorization. require CGA authorization.
Note that RFC 2461 rules already prevent a bogus router from Note that RFC 2461 rules already prevent a bogus router from
sending a Redirect message when the host is not using the bogus sending a Redirect message when the host is not using the bogus
router as a default router. router as a default router.
If the Target Address and Destination Address fields in the ICMP
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 MUST verify that the given address falls within the range
defined by the router's certificate. Redirect messages failing
this check MUST be silently discarded.
8.4 Other Requirements 8.4 Other Requirements
Hosts SHOULD use Authorization Delegation Discovery to learn the Hosts SHOULD use Authorization Delegation Discovery to learn the
certificate chain of their default router (or peer host), as certificate chain of their default router (or peer host), as
explained in Section 6. The receipt of a protected Router explained in Section 6. The receipt of a protected Router
Advertisement message for which no router Authorization Certificate Advertisement message for which no router Authorization Certificate
and certificate chain is available triggers Authorization Delegation and certificate chain is available triggers Authorization Delegation
Discovery. Discovery.
9. Co-Existence of SEND and non-SEND nodes 9. Co-Existence of SEND and non-SEND nodes
 End of changes. 

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