base.txt   issue44.txt 
Secure Neighbor Discovery Working J. Arkko Secure Neighbor Discovery Working J. Arkko
Group Ericsson Group Ericsson
Internet-Draft J. Kempf Internet-Draft J. Kempf
Expires: June 29, 2004 DoCoMo Communications Labs USA Expires: June 30, 2004 DoCoMo Communications Labs USA
B. Sommerfeld B. Sommerfeld
Sun Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
P. Nikander P. Nikander
Ericsson Ericsson
December 30, 2003 December 31, 2003
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-pre01 draft-ietf-send-ndopt-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
  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 29, 2004. This Internet-Draft will expire on June 30, 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 2, line 44:
6.2.1 Delegation Chain Solicitation Message Format . 27 6.2.1 Delegation Chain Solicitation Message Format . 27
6.2.2 Delegation Chain Advertisement Message Format 29 6.2.2 Delegation Chain Advertisement Message Format 29
6.2.3 Trust Anchor Option . . . . . . . . . . . . . 31 6.2.3 Trust Anchor Option . . . . . . . . . . . . . 31
6.2.4 Certificate Option . . . . . . . . . . . . . . 32 6.2.4 Certificate Option . . . . . . . . . . . . . . 32
6.2.5 Processing Rules for Routers . . . . . . . . . 33 6.2.5 Processing Rules for Routers . . . . . . . . . 33
6.2.6 Processing Rules for Hosts . . . . . . . . . . 34 6.2.6 Processing Rules for Hosts . . . . . . . . . . 34
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 36 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .36 7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .36
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .36 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .36
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .36 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .36
7.4 Limitations . . . . . . . . . . . . . . . . . . . . .36 7.4 Limitations . . . . . . . . . . . . . . . . . . . . .37
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 38 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . 40
9.1 Threats to the Local Link Not Covered by SEND . . . .40 9.1 Threats to the Local Link Not Covered by SEND . . . .40
9.2 How SEND Counters Threats to NDP . . . . . . . . . . .40 9.2 How SEND Counters Threats to NDP . . . . . . . . . . .40
9.2.1 Neighbor Solicitation/Advertisement Spoofing . 41 9.2.1 Neighbor Solicitation/Advertisement Spoofing . 41
9.2.2 Neighbor Unreachability Detection Failure . . 41 9.2.2 Neighbor Unreachability Detection Failure . . 41
9.2.3 Duplicate Address Detection DoS Attack . . . . 41 9.2.3 Duplicate Address Detection DoS Attack . . . . 41
9.2.4 Router Solicitation and Advertisement Attacks 42 9.2.4 Router Solicitation and Advertisement Attacks 42
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 42 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 42
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 43 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 43
  Skipping to change at page 25, line 38:
an addressPrefix or addressRange is not contained within the an addressPrefix or addressRange is not contained within the
delegating authority's prefixes or ranges, the client MAY attempt to delegating authority's prefixes or ranges, the client MAY attempt to
take an intersection of the ranges/prefixes, and use that take an intersection of the ranges/prefixes, and use that
intersection. If the addressPrefix in the certificate is the null intersection. If the addressPrefix in the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case the prefix, 0/0, such an intersection SHOULD be used. (In that case the
intersection is the parent prefix or range.) If the resulting intersection is the parent prefix or range.) If the resulting
intersection is empty, the client MUST NOT accept the certificate. intersection is empty, the client MUST NOT accept the certificate.
The above check SHOULD be done for all certificates in the chain. If The above check SHOULD be done for all certificates in the chain. If
any of the checks fail, the client MUST NOT accept the certificate. any of the checks fail, the client MUST NOT accept the certificate.
The client also needs to perform validation of advertised prefixes as
discussed in Section 7.3.
Since it is possible that some PKC certificates used with SEND do not Since it is possible that some PKC certificates used with SEND do not
immediately contain the X.509 IP address extension element, an immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default be off by default. That is, the system SHOULD have a default
configuration that requires rigorous prefix and range checks. configuration that requires rigorous prefix and range checks.
The following is an example of a certificate chain. Suppose that The following is an example of a certificate chain. Suppose that
ispgroup.com is the trust anchor. The host has this certificate for ispgroup.com is the trust anchor. The host has this certificate for
  Skipping to change at page 36, line 38:
be silently discarded. be silently discarded.
Note that RFC 2461 rules prevent a bogus router from sending a Note that RFC 2461 rules prevent a bogus router from sending a
Redirect message when the host is not using the bogus router as a Redirect message when the host is not using the bogus router as a
default router. default router.
7.3 Advertised Prefixes 7.3 Advertised Prefixes
The router's certificate defines the address range(s) that it is The router's certificate defines the address range(s) that it is
allowed to advertise. Upon processing a Prefix Information option allowed to advertise. Upon processing a Prefix Information option
within a Router Advertisement, the receiver MUST verify that the within a Router Advertisement, nodes SHOULD verify that the prefix
prefix specified in this option falls within the range defined by the specified in this option falls within the range defined by the
certificate. Router Advertisements failing this check MUST be certificate, if the certificate contains a prefix extension. Options
silently discarded. failing this check MUST be silently discarded.
Nodes SHOULD use one of the certified prefixes for stateless
autoconfiguration. If none of the advertised prefixes match, then
either there is a configuration problem or the advertising router is
an attacker, and the host MUST use a different advertising router as
its default router (if available). If the node is performing
stateful autoconfiguration, it SHOULD check the address provided by
the DHCP server against the certified prefixes and MUST NOT use the
address if the prefix is not certified.
In any case, the user should inform the network operator upon
receiving an address or prefix outside the certified range, since
this is either a misconfiguration or an attack.
If the network operator wants to constrain which routers support
particular prefixes, routers SHOULD be configured with certificates
having prefixes listed in the prefix extension. Routers so
configured MUST advertise exactly the prefixes for which they are
certified.
Network operators that do not want to constrain particular routers to
specific prefixes SHOULD configure routers with certificates
containing either the null prefix or no prefix extension at all.
7.4 Limitations 7.4 Limitations
This specification does not address the protection of NDP packets for This specification does not address the protection of NDP packets for
nodes that are configured with a static address (e.g., PREFIX::1). nodes that are configured with a static address (e.g., PREFIX::1).
Future certificate chain based authorization specifications are Future certificate chain based authorization specifications are
needed for such nodes. needed for such nodes.
It is outside the scope of this specification to describe the use of It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing trust anchor authorization between nodes with dynamically changing
 End of changes. 

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