base.txt   issue99.txt 
Secure Neighbor Discovery Working J. Arkko (Editor) Secure Neighbor Discovery Working J. Arkko (Editor)
Group Ericsson Group Ericsson
Internet-Draft J. Kempf Internet-Draft J. Kempf
Expires: January 11, 2005 DoCoMo Communications Labs USA Expires: January 15, 2005 DoCoMo Communications Labs USA
B. Sommerfeld B. Sommerfeld
Sun Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
P. Nikander P. Nikander
Ericsson Ericsson
July 13, 2004 July 17, 2004
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-pre06 draft-ietf-send-ndopt-pre06
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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 11, 2005. This Internet-Draft will expire on January 15, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 the link-layer addresses of other nodes on the link, to determine the link-layer addresses of
other nodes on the link, to find routers, and to maintain other nodes on the link, to find routers, and to maintain
reachability information about the paths to active neighbors. If not reachability information about the paths to active neighbors. If not
secured, NDP is vulnerable to various attacks. This document secured, NDP is vulnerable to various attacks. This document
specifies security mechanisms for NDP. Unlike the original NDP specifies security mechanisms for NDP. Unlike the original NDP
specifications, these mechanisms do not make use of IPsec. specifications these mechanisms do not make use of IPsec.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . . 5 1.1 Specification of Requirements . . . . . . . . . . . . 5
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 9 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 9
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 11 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 11
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 13 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 13
5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 13 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 2, line 33 skipping to change at page 2, line 33
5.3 Timestamp and Nonce options . . . . . . . . . . . . . 21 5.3 Timestamp and Nonce options . . . . . . . . . . . . . 21
5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 21 5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 21
5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 22 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 22
5.3.3 Processing rules for senders . . . . . . . . . . 23 5.3.3 Processing rules for senders . . . . . . . . . . 23
5.3.4 Processing rules for receivers . . . . . . . . . 24 5.3.4 Processing rules for receivers . . . . . . . . . 24
6. Authorization Delegation Discovery . . . . . . . . . . . . . 27 6. Authorization Delegation Discovery . . . . . . . . . . . . . 27
6.1 Authorization Model . . . . . . . . . . . . . . . . . 27 6.1 Authorization Model . . . . . . . . . . . . . . . . . 27
6.2 Deployment Model . . . . . . . . . . . . . . . . . . . 28 6.2 Deployment Model . . . . . . . . . . . . . . . . . . . 28
6.3 Certificate Format . . . . . . . . . . . . . . . . . . 29 6.3 Certificate Format . . . . . . . . . . . . . . . . . . 29
6.3.1 Router Authorization Certificate Profile . . . . 29 6.3.1 Router Authorization Certificate Profile . . . . 29
6.3.2 Suitability of Standard Identity Certificates . 31 6.3.2 Suitability of Standard Identity Certificates . 32
6.4 Certificate Transport . . . . . . . . . . . . . . . . 32 6.4 Certificate Transport . . . . . . . . . . . . . . . . 32
6.4.1 Certification Path Solicitation Message Format . 32 6.4.1 Certification Path Solicitation Message Format . 32
6.4.2 Certification Path Advertisement Message Format 34 6.4.2 Certification Path Advertisement Message Format 34
6.4.3 Trust Anchor Option . . . . . . . . . . . . . . 36 6.4.3 Trust Anchor Option . . . . . . . . . . . . . . 37
6.4.4 Certificate Option . . . . . . . . . . . . . . . 38 6.4.4 Certificate Option . . . . . . . . . . . . . . . 38
6.4.5 Processing Rules for Routers . . . . . . . . . . 39 6.4.5 Processing Rules for Routers . . . . . . . . . . 39
6.4.6 Processing Rules for Hosts . . . . . . . . . . . 40 6.4.6 Processing Rules for Hosts . . . . . . . . . . . 40
6.5 Configuration . . . . . . . . . . . . . . . . . . . . 41 6.5 Configuration . . . . . . . . . . . . . . . . . . . . 42
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 43 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 43 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 43
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 43 7.3 Advertised Subnet Prefixes . . . . . . . . . . . . . . 43
7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 44 7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 44
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 46 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . 48 9. Security Considerations . . . . . . . . . . . . . . . . . . 49
9.1 Threats to the Local Link Not Covered by SEND . . . . 48 9.1 Threats to the Local Link Not Covered by SEND . . . . 49
9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 48 9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 49
9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 49 9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 50
9.2.2 Neighbor Unreachability Detection Failure . . . 49 9.2.2 Neighbor Unreachability Detection Failure . . . 50
9.2.3 Duplicate Address Detection DoS Attack . . . . . 49 9.2.3 Duplicate Address Detection DoS Attack . . . . . 50
9.2.4 Router Solicitation and Advertisement Attacks . 50 9.2.4 Router Solicitation and Advertisement Attacks . 51
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 50 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 51
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 51 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 52
9.3 Attacks against SEND Itself . . . . . . . . . . . . . 51 9.3 Attacks against SEND Itself . . . . . . . . . . . . . 52
10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 53 10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 54
10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 53 10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 54
10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 53 10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 54
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 54 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 55
Normative References . . . . . . . . . . . . . . . . . . . . 55 Normative References . . . . . . . . . . . . . . . . . . . . 56
Informative References . . . . . . . . . . . . . . . . . . . 57 Informative References . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 58
A. Contributors and Acknowledgments . . . . . . . . . . . . . . 59 A. Contributors and Acknowledgments . . . . . . . . . . . . . . 60
B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 60 B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 61
C. Message Size When Carrying Certificates . . . . . . . . . . 61 C. Message Size When Carrying Certificates . . . . . . . . . . 62
Intellectual Property and Copyright Statements . . . . . . . 62 Intellectual Property and Copyright Statements . . . . . . . 63
1. Introduction 1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7] IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
and 2462 [8]. Nodes on the same link use NDP to discover each and 2462 [8]. Nodes on the same link use NDP to discover each
other's presence, to determine each other's link-layer addresses, to other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the find routers, and to maintain reachability information about the
paths to active neighbors. NDP is used both by hosts and routers. paths to active neighbors. NDP is used both by hosts and routers.
Its functions include Neighbor Discovery (ND), Router Discovery (RD), Its functions include Neighbor Discovery (ND), Router Discovery (RD),
Address Autoconfiguration, Address Resolution, Neighbor Address Autoconfiguration, Address Resolution, Neighbor
skipping to change at page 4, line 44 skipping to change at page 4, line 44
based signatures. A zero-configuration mechanism is used for showing based signatures. A zero-configuration mechanism is used for showing
address ownership on individual nodes; routers are certified by a address ownership on individual nodes; routers are certified by a
trust anchor [10]. The formats, procedures, and cryptographic trust anchor [10]. The formats, procedures, and cryptographic
mechanisms for the zero-configuration mechanism are described in a mechanisms for the zero-configuration mechanism are described in a
related specification [14]. related specification [14].
The required new NDP options are discussed in Section 5. Section 6 The required new NDP options are discussed in Section 5. Section 6
describes the mechanism for distributing certification paths to describes the mechanism for distributing certification paths to
establish an authorization delegation chain to a trust anchor. establish an authorization delegation chain to a trust anchor.
Finally, Section 8 discusses the co-existence of secure and Finally, Section 8 discusses the co-existence of secured and
non-secure NDP on the same link and Section 9 discusses security unsecured NDP on the same link and Section 9 discusses security
considerations for Secure Neighbor Discovery (SEND). considerations for Secure Neighbor Discovery (SEND).
Out of scope for this document is the use of identity certificates Out of scope for this document is the use of identity certificates
provisioned on end hosts for authorizing address use, and security of provisioned on end hosts for authorizing address use, and security of
NDP when the entity defending an address is not the same as the NDP when the entity defending an address is not the same as the
entity claiming that adddress (also known as "proxy ND"). These are entity claiming that adddress (also known as "proxy ND"). These are
extensions of SEND that may be treated in separate documents should extensions of SEND that may be treated in separate documents should
the need arise. the need arise.
1.1 Specification of Requirements 1.1 Specification of Requirements
skipping to change at page 7, line 13 skipping to change at page 7, line 13
Neighbor Discovery (ND) Neighbor Discovery (ND)
The Neighbor Discovery function of the Neighbor Discovery Protocol The Neighbor Discovery function of the Neighbor Discovery Protocol
(NDP). NDP contains other functions besides ND. (NDP). NDP contains other functions besides ND.
Neighbor Discovery Protocol (NDP) Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [7, 8]. The IPv6 Neighbor Discovery Protocol [7, 8].
Neighbor Discovery Protocol is a part of ICMPv6 [9]. The Neighbor Discovery Protocol is a part of ICMPv6 [9].
Neighbor Unreachability Detection (NUD) Neighbor Unreachability Detection (NUD)
A mechanism used for tracking the reachability of neighbors. A mechanism used for tracking the reachability of neighbors.
Non-SEND node Non-SEND node
An IPv6 node that does not implement this specification but uses An IPv6 node that does not implement this specification but uses
only RFC 2461 and RFC 2462 without security. only the Neighbor Discovery protocol defined in RFC 2461 and RFC
2462, as updated, without security.
Nonce Nonce
An unpredictable random or pseudorandom number generated by a node An unpredictable random or pseudorandom number generated by a node
and used exactly once. In SEND, nonces are used to assure that a and used exactly once. In SEND, nonces are used to assure that a
particular advertisement is linked to the solicitation that particular advertisement is linked to the solicitation that
triggered it. triggered it.
Router Authorization Certificate Router Authorization Certificate
An X.509v3 [10] public key certificate using the profile specified An X.509v3 [10] public key certificate using the profile specified
in Section 6.3.1. in Section 6.3.1.
SEND node SEND node
An IPv6 node that implements this specification. An IPv6 node that implements this specification.
Router Discovery (RD) Router Discovery (RD)
Router Discovery allows the hosts to discover what routers exist Router Discovery allows the hosts to discover what routers exist
on the link, and what prefixes are available. Router Discovery is on the link, and what subnet prefixes are available. Router
a part of the Neighbor Discovery Protocol. Discovery is a part of the Neighbor Discovery Protocol.
Trust Anchor Trust Anchor
Hosts are configured with a set of trust anchors for the purposes Hosts are configured with a set of trust anchors for the purposes
of protecting Router Discovery. A trust anchor is an entity that of protecting Router Discovery. A trust anchor is an entity that
the host trusts to authorize routers to act as routers. A trust the host trusts to authorize routers to act as routers. A trust
anchor configuration consists of a public key and some associated anchor configuration consists of a public key and some associated
parameters (see Section 6.5 for a detailed explanation of these parameters (see Section 6.5 for a detailed explanation of these
parameters). parameters).
3. Neighbor and Router Discovery Overview 3. Neighbor and Router Discovery Overview
The Neighbor Discovery Protocol has several functions. Many of these The Neighbor Discovery Protocol has several functions. Many of these
functions are overloaded on a few central message types, such as the functions are overloaded on a few central message types, such as the
ICMPv6 Neighbor Advertisement message. In this section we review ICMPv6 Neighbor Advertisement message. In this section we review
some of these tasks and their effects in order to understand better some of these tasks and their effects in order to understand better
how the messages should be treated. This section is not normative, how the messages should be treated. This section is not normative,
and if this section and the original Neighbor Discovery RFCs are in and if this section and the original Neighbor Discovery RFCs are in
conflict, the original RFCs take precedence. conflict, the original RFCs, as updated, take precedence.
The main functions of NDP are the following. The main functions of NDP are the following.
o The Router Discovery function allows IPv6 hosts to discover the o The Router Discovery function allows IPv6 hosts to discover the
local routers on an attached link. Router Discovery is described local routers on an attached link. Router Discovery is described
in Section 6 of RFC 2461 [7]. The main purpose of Router in Section 6 of RFC 2461 [7]. The main purpose of Router
Discovery is to find neighboring routers that are willing to Discovery is to find neighboring routers that are willing to
forward packets on behalf of hosts. Prefix discovery involves forward packets on behalf of hosts. Subnet prefix discovery
determining which destinations are directly on a link; this involves determining which destinations are directly on a link;
information is necessary in order to know whether a packet should this information is necessary in order to know whether a packet
be sent to a router or directly to the destination node. should be sent to a router or directly to the destination node.
o The Redirect function is used for automatically redirecting a host o The Redirect function is used for automatically redirecting a host
to a better first-hop router, or to inform hosts that a to a better first-hop router, or to inform hosts that a
destination is in fact a neighbor (i.e., on-link). Redirect is destination is in fact a neighbor (i.e., on-link). Redirect is
specified in Section 8 of RFC 2461 [7]. specified in Section 8 of RFC 2461 [7].
o Address Autoconfiguration is used for automatically assigning o Address Autoconfiguration is used for automatically assigning
addresses to a host [8]. This allows hosts to operate without addresses to a host [8]. This allows hosts to operate without
explicit configuration related to IP connectivity. The default explicit configuration related to IP connectivity. The default
autoconfiguration mechanism is stateless. To create IP addresses, autoconfiguration mechanism is stateless. To create IP addresses,
skipping to change at page 12, line 4 skipping to change at page 12, line 4
public key is established either with the authorization delegation public key is established either with the authorization delegation
process, using certificates, or through the address ownership process, using certificates, or through the address ownership
proof mechanism, using CGAs, or both, depending on configuration proof mechanism, using CGAs, or both, depending on configuration
and the type of the message protected. and the type of the message protected.
Note: RSA is mandated because having multiple signature algorithms Note: RSA is mandated because having multiple signature algorithms
would break compatibility between implementations or increase would break compatibility between implementations or increase
implementation complexity by forcing implementation of multiple implementation complexity by forcing implementation of multiple
algorithms and the mechanism to select among them. A second algorithms and the mechanism to select among them. A second
signature algorithm is only necessary as a recovery mechanism, in signature algorithm is only necessary as a recovery mechanism, in
case RSA is found to be insecure. If that happens, a stronger case a flaw is found in RSA. If that happens, a stronger signature
signature algorithm can be selected and SEND can be revised. The algorithm can be selected and SEND can be revised. The
relationship between the new algorithm and the RSA-based SEND relationship between the new algorithm and the RSA-based SEND
described in this document would be similar to that between the described in this document would be similar to that between the
RSA-based SEND and Neighbor Discovery without SEND. Information RSA-based SEND and Neighbor Discovery without SEND. Information
signed with the stronger algorithm has precedence over that signed signed with the stronger algorithm has precedence over that signed
with RSA, in the same way as RSA-signed information now takes with RSA, in the same way as RSA-signed information now takes
precedence over unsigned information. Implementations of the precedence over unsigned information. Implementations of the
current and revised specs would still be compatible. current and revised specs would still be compatible.
o In order to prevent replay attacks, two new Neighbor Discovery o In order to prevent replay attacks, two new Neighbor Discovery
options, Timestamp and Nonce, are introduced. Given that Neighbor options, Timestamp and Nonce, are introduced. Given that Neighbor
skipping to change at page 15, line 21 skipping to change at page 15, line 21
the CGA option is not used when the source address is the the CGA option is not used when the source address is the
unspecified address. unspecified address.
Router Advertisement Router Advertisement
The address MUST be the source address of the message. The address MUST be the source address of the message.
5.1.2 Processing Rules for Receivers 5.1.2 Processing Rules for Receivers
Neighbor Solicitation and Advertisement messages without the CGA Neighbor Solicitation and Advertisement messages without the CGA
option MUST be treated as insecure, i.e., processed in the same way option MUST be treated as unsecured, i.e., processed in the same way
as NDP messages sent by a non-SEND node. The processing of insecure as NDP messages sent by a non-SEND node. The processing of unsecured
messages is specified in Section 8. Note that SEND nodes that do not messages is specified in Section 8. Note that SEND nodes that do not
attempt to interoperate with non-SEND nodes MAY simply discard the attempt to interoperate with non-SEND nodes MAY simply discard the
insecure messages. unsecured messages.
Router Solicitation messages without the CGA option MUST also be Router Solicitation messages without the CGA option MUST also be
treated as insecure, unless the source address of the message is the treated as unsecured, unless the source address of the message is the
unspecified address. unspecified address.
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
Solicitation, and Router Advertisement messages containing a CGA Solicitation, and Router Advertisement messages containing a CGA
option MUST be checked as follows: option MUST be checked as follows:
If the interface has been configured to use CGA, the receiving If the interface has been configured to use CGA, the receiving
node MUST verify the source address of the packet using the node MUST verify the source address of the packet using the
algorithm described in Section 5 of [14]. The inputs to the algorithm described in Section 5 of [14]. The inputs to the
algorithm are the claimed address, as defined in the previous algorithm are the claimed address, as defined in the previous
section, and the CGA Parameters field. section, and the CGA Parameters field.
If the CGA verification is successful, the recipient proceeds with If the CGA verification is successful, the recipient proceeds with
the cryptographically more time consuming check of the signature. more time consuming cryptographic check of the signature. Note
However, even if the CGA verification succeeds, no claims about that even if the CGA verification succeeds, no claims about the
the validity of the use can be made, until the signature has been validity of the use can be made, until the signature has been
checked. checked.
Note that a receiver that does not support CGA or has not specified A receiver that does not support CGA or has not specified its use for
its use for a given interface can still verify packets using trust a given interface can still verify packets using trust anchors, even
anchors, even if a CGA is used on a packet. In such a case, the CGA if a CGA is used on a packet. In such a case, the CGA property of
property of the address is simply left unverified. the address is simply left unverified.
5.1.3 Configuration 5.1.3 Configuration
All nodes that support the verification of the CGA option MUST record All nodes that support the verification of the CGA option MUST record
the following configuration information: the following configuration information:
minbits minbits
The minimum acceptable key length for public keys used in the The minimum acceptable key length for public keys used in the
generation of CGAs. The default SHOULD be 1024 bits. generation of CGAs. The default SHOULD be 1024 bits.
skipping to change at page 19, line 22 skipping to change at page 19, line 22
under the description of the Digital Signature field. under the description of the Digital Signature field.
o The message, in the form defined above, is signed using the o The message, in the form defined above, is signed using the
configured private key, and the resulting PKCS#1 v1.5 signature is configured private key, and the resulting PKCS#1 v1.5 signature is
put in the Digital Signature field. put in the Digital Signature field.
5.2.2 Processing Rules for Receivers 5.2.2 Processing Rules for Receivers
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages without the RSA Signature option MUST be and Redirect messages without the RSA Signature option MUST be
treated as insecure, i.e., processed in the same way as NDP messages treated as unsecured, i.e., processed in the same way as NDP messages
sent by a non-SEND node. See Section 8. sent by a non-SEND node. See Section 8.
Router Solicitation messages without the RSA Signature option MUST Router Solicitation messages without the RSA Signature option MUST
also be treated as insecure, unless the source address of the message also be treated as unsecured, unless the source address of the
is the unspecified address. message is the unspecified address.
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
Solicitation, and Router Advertisement messages containing an RSA Solicitation, and Router Advertisement messages containing an RSA
Signature option MUST be checked as follows: Signature option MUST be checked as follows:
o The receiver MUST ignore any options that come after the first RSA o The receiver MUST ignore any options that come after the first RSA
Signature option. (The options are ignored for both signature Signature option. (The options are ignored for both signature
verification and NDP processing purposes.) verification and NDP processing purposes.)
o The Key Hash field MUST indicate the use of a known public key, o The Key Hash field MUST indicate the use of a known public key,
skipping to change at page 20, line 9 skipping to change at page 20, line 9
o If the use of a trust anchor has been configured, a valid o If the use of a trust anchor has been configured, a valid
certification path (see Section 6.3) MUST be known between the certification path (see Section 6.3) MUST be known between the
receiver's trust anchor and the sender's public key. receiver's trust anchor and the sender's public key.
Note that the receiver may verify just the CGA property of a Note that the receiver may verify just the CGA property of a
packet, even if, in addition to CGA, the sender has used a trust packet, even if, in addition to CGA, the sender has used a trust
anchor. anchor.
Messages that do not pass all the above tests MUST be silently Messages that do not pass all the above tests MUST be silently
discarded if the host has been configured to only accept secure ND discarded if the host has been configured to only accept secured ND
messages. The messages MAY be accepted it the host has been messages. The messages MAY be accepted if the host has been
configured to accept both secure and insecure messages, but MUST be configured to accept both secured and unsecured messages, but MUST be
treated as an insecure message. The receiver MAY also otherwise treated as an unsecured message. The receiver MAY also otherwise
silently discard packets, e.g., as a response to an apparent CPU silently discard packets, e.g., as a response to an apparent CPU
exhausting DoS attack. exhausting DoS attack.
5.2.3 Configuration 5.2.3 Configuration
All nodes that support the reception of the RSA Signature options All nodes that support the reception of the RSA Signature options
MUST allow the following information to be configured for each MUST allow the following information to be configured for each
separate NDP message type: separate NDP message type:
authorization method authorization method
skipping to change at page 21, line 15 skipping to change at page 21, line 15
keypair keypair
A public-private key pair. If authorization delegation is in use, A public-private key pair. If authorization delegation is in use,
there must exist a certification path from a trust anchor to this there must exist a certification path from a trust anchor to this
key pair. key pair.
CGA flag CGA flag
A flag that indicates whether CGA is used or not. This flag may be A flag that indicates whether CGA is used or not. This flag may be
per interface or per node. (Note that in future extensions of the per interface or per node. (Note that in future extensions of the
SEND protocol, this flag may be per subnet-prefix.) SEND protocol, this flag may also be per subnet-prefix.)
5.2.4 Performance Considerations 5.2.4 Performance Considerations
The construction and verification of this option is computationally The construction and verification of the RSA Signature option is
expensive. In the NDP context, however, the hosts typically have the computationally expensive. In the NDP context, however, hosts
need to perform only a few signature operations as they enter a link, typically need to perform only a few signature operations as they
a few operations as they find a new on-link peer with which to enter a link, a few operations as they find a new on-link peer with
communicate, or perform Neighbor Unreachability Detection with which to communicate, or Neighbor Unreachability Detection with
existing ones. existing neighbors.
Routers are required to perform a larger number of operations, Routers are required to perform a larger number of operations,
particularly when the frequency of router advertisements is high due particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of required signature to mobility requirements. Still, the number of required signature
operations is on the order of a few dozen per second, some of which operations is on the order of a few dozen per second, some of which
can be precomputed as explained below. A large number of router can be precomputed as explained below. A large number of router
solicitations may cause higher demand for performing asymmetric solicitations may cause higher demand for performing asymmetric
operations, although RFC 2461 limits the rate at which responses to operations, although the base NDP protocol limits the rate at which
solicitations can be sent. responses to solicitations can be sent.
Signatures can be precomputed for unsolicited (multicast) Neighbor Signatures can be precomputed for unsolicited (multicast) Neighbor
and Router Advertisements if the timing of such future advertisements and Router Advertisements if the timing of such future advertisements
is known. Typically, solicited advertisements are sent to the unicast is known. Typically, solicited advertisements are sent to the unicast
address from which the solicitation was sent. Given that the IPv6 address from which the solicitation was sent. Given that the IPv6
header is covered by the signature, it is not possible to precompute header is covered by the signature, it is not possible to precompute
solicited advertisements. solicited advertisements.
5.3 Timestamp and Nonce options 5.3 Timestamp and Nonce options
skipping to change at page 23, line 38 skipping to change at page 23, line 38
least 6 bytes. The length of the random number MUST be selected so least 6 bytes. The length of the random number MUST be selected so
that the length of the nonce option is a multiple of 8 octets. that the length of the nonce option is a multiple of 8 octets.
5.3.3 Processing rules for senders 5.3.3 Processing rules for senders
If the node has been configured to use SEND, all solicitation If the node has been configured to use SEND, all solicitation
messages MUST include a Nonce. When sending a solicitation, the messages MUST include a Nonce. When sending a solicitation, the
sender MUST store the nonce internally so that it can recognize any sender MUST store the nonce internally so that it can recognize any
replies containing that particular nonce. replies containing that particular nonce.
If the node has been configured to use SEND, all solicited If the node has been configured to use SEND, all advertisements sent
advertisements MUST include a Nonce, copied from the received in reply to a solicitation MUST include a Nonce, copied from the
solicitation. Note that routers may decide to send a multicast received solicitation. Note that routers may decide to send a
advertisement to all nodes instead of a response to a specific host. multicast advertisement to all nodes instead of a response to a
In such case the router MAY still include the nonce value for the specific host. In such case the router MAY still include the nonce
host that triggered the multicast advertisement. (Omitting the nonce value for the host that triggered the multicast advertisement.
value may cause the host to ignore the router's advertisement, unless (Omitting the nonce value may cause the host to ignore the router's
the clocks in these nodes are sufficiently synchronized so that advertisement, unless the clocks in these nodes are sufficiently
timestamps can be relied on.) synchronized so that timestamps function properly.)
If the node has been configured to use SEND, all solicitation, If the node has been configured to use SEND, all solicitation,
advertisement, and redirect messages MUST include a Timestamp. advertisement, and redirect messages MUST include a Timestamp.
Senders SHOULD set the Timestamp field to the current time, according Senders SHOULD set the Timestamp field to the current time, according
to their real time clock. to their real time clock.
5.3.4 Processing rules for receivers 5.3.4 Processing rules for receivers
The processing of the Nonce and Timestamp options depends on whether The processing of the Nonce and Timestamp options depends on whether
a packet is a solicited advertisement. A system may implement the a packet is a solicited advertisement. A system may implement the
distinction in various ways. Section 5.3.4.1 defines the processing distinction in various ways. Section 5.3.4.1 defines the processing
rules for solicited advertisements. Section 5.3.4.2 defines the rules for solicited advertisements. Section 5.3.4.2 defines the
processing rules for all other messages. processing rules for all other messages.
In addition, the following rules apply in all cases: In addition, the following rules apply in all cases:
o Messages received without at least one of the the Timestamp and o Messages received without at least one of the the Timestamp and
Nonce options MUST be treated as insecure, i.e., processed in the Nonce options MUST be treated as unsecured, i.e., processed in the
same way as NDP messages sent by a non-SEND node. same way as NDP messages sent by a non-SEND node.
o Messages received with the RSA Signature option but without the o Messages received with the RSA Signature option but without the
Timestamp option MUST be silently discarded. Timestamp option MUST be silently discarded.
o Solicitation messages received with the RSA Signature option but o Solicitation messages received with the RSA Signature option but
without the Nonce option MUST be silently discarded. without the Nonce option MUST be silently discarded.
o Advertisements sent to a unicast destination address with the RSA o Advertisements sent to a unicast destination address with the RSA
Signature option but without a Nonce option SHOULD be processed as Signature option but without a Nonce option SHOULD be processed as
skipping to change at page 25, line 34 skipping to change at page 25, line 34
following information for each peer: following information for each peer:
o The receive time of the last received and accepted SEND message. o The receive time of the last received and accepted SEND message.
This is called RDlast. This is called RDlast.
o The time stamp in the last received and accepted SEND message. o The time stamp in the last received and accepted SEND message.
This is called TSlast. This is called TSlast.
An accepted SEND message is any successfully verified Neighbor An accepted SEND message is any successfully verified Neighbor
Solicitation, Neighbor Advertisement, Router Solicitation, Router Solicitation, Neighbor Advertisement, Router Solicitation, Router
Advertisement, or Redirect message from the given peer. It is Advertisement, or Redirect message from the given peer. The RSA
required that the RSA Signature option has been used in such a Signature option MUST be used in such a message before it can update
message before it can update the above variables. the above variables.
Receivers SHOULD then check the Timestamp field as follows: Receivers SHOULD then check the Timestamp field as follows:
o When a message is received from a new peer, i.e., one that is not o When a message is received from a new peer (i.e., one that is not
stored in the cache, the received timestamp, TSnew, is checked and stored in the cache) the received timestamp, TSnew, is checked and
the packet is accepted if the timestamp is recent enough with the packet is accepted if the timestamp is recent enough with
respect to the reception time of the packet, RDnew: respect to the reception time of the packet, RDnew:
-Delta < (RDnew - TSnew) < +Delta -Delta < (RDnew - TSnew) < +Delta
The RDnew and TSnew values SHOULD be stored into the cache as The RDnew and TSnew values SHOULD be stored into the cache as
RDlast and TSlast. RDlast and TSlast.
o Even if the timestamp is NOT within the boundaries but the message o Even if the timestamp is NOT within the boundaries but the message
is a Neighbor Solicitation message which should be answered by the is a Neighbor Solicitation message that should be answered by the
receiver, the receiver SHOULD respond to the message. However, if receiver, the receiver SHOULD respond to the message. However, if
it does respond to the message, it MUST NOT create a Neighbor it does respond to the message, it MUST NOT create a Neighbor
Cache entry. This allows nodes that have large differences in Cache entry. This allows nodes that have large differences in
their clocks to still communicate with each other, by exchanging their clocks to still communicate with each other, by exchanging
NS/NA pairs. NS/NA pairs.
o When a message is received from a known peer, i.e., one that o When a message is received from a known peer, i.e., one that
already has an entry in the cache, the time stamp is checked already has an entry in the cache, the time stamp is checked
against the previously received SEND message: against the previously received SEND message:
skipping to change at page 27, line 32 skipping to change at page 27, line 32
The Secure Neighbor Discovery Protocol mandates a certificate format The Secure Neighbor Discovery Protocol mandates a certificate format
and introduces two new ICMPv6 messages that are used between hosts and introduces two new ICMPv6 messages that are used between hosts
and routers to allow the host to learn a certification path with the and routers to allow the host to learn a certification path with the
assistance of the router. assistance of the router.
6.1 Authorization Model 6.1 Authorization Model
To protect Router Discovery, SEND requires routers to be authorized To protect Router Discovery, SEND requires routers to be authorized
to act as routers. This authorization is provisioned in both routers to act as routers. This authorization is provisioned in both routers
and hosts: routers are given certificates from a trust anchor and the and hosts: routers are given certificates from a trust anchor and the
hosts are configured with the trust anchor(s) that they trust to hosts are configured with the trust anchor(s) to authorize routers.
authorize routers. This provisioning is specific to SEND, and does This provisioning is specific to SEND, and does not assume that
not assume that certificates already deployed for some other purpose certificates already deployed for some other purpose can be used.
can be used.
The authorization for routers in SEND is twofold: The authorization for routers in SEND is twofold:
o Routers are authorized to act as routers. The router belongs to o Routers are authorized to act as routers. The router belongs to
the set of routers trusted by the trust anchor. All routers in the set of routers trusted by the trust anchor. All routers in
this set have the same authorization. this set have the same authorization.
o Optionally, routers may also be authorized to advertise a certain o Optionally, routers may also be authorized to advertise a certain
set of prefixes. A specific router is given a specific set of set of subnet prefixes. A specific router is given a specific set
prefixes to advertise; other routers have an authorization to of subnet prefixes to advertise; other routers have an
advertise other prefixes. Trust anchors may also delegate a authorization to advertise other subnet prefixes. Trust anchors
certain set of prefixes to someone (such as an ISP), who in turn may also delegate a certain set of subnet prefixes to someone
delegates parts of this set to individual routers. (such as an ISP), who in turn delegates parts of this set to
individual routers.
Note that while communicating with hosts, routers typically present Note that while communicating with hosts, routers typically present
also a number of other parameters beyond the above. For instance, also a number of other parameters beyond the above. For instance,
routers have their own IP addresses, prefixes have lifetimes, routers routers have their own IP addresses, subnet prefixes have lifetimes,
control the use of stateless and stateful address autoconfiguration, routers control the use of stateless and stateful address
and so on. However, the ability to be a router and the prefixes are autoconfiguration, and so on. However, the ability to be a router and
the most fundamental parameters to authorize. This is because the the subnet prefixes are the most fundamental parameters to authorize.
host needs to choose a router that it uses as its defaulr router, and This is because the host needs to choose a router that it uses as its
because the advertised prefixes have an impact on the addresses the default router, and because the advertised subnet prefixes have an
host uses. In addition, the prefixes also represent a claim about the impact on the addresses the host uses. In addition, the subnet
topological location in the network. prefixes also represent a claim about the topological location of the
router in the network.
Care should be taken if the certificates used in SEND are also used Care should be taken if the certificates used in SEND are also used
to provide authorization in other circumstances, for example with to provide authorization in other circumstances, for example with
routing protocols. It is necessary to ensure that the authorization routing protocols. It is necessary to ensure that the authorization
information is appropriate for all applications. SEND certificates information is appropriate for all applications. SEND certificates
may authorize a larger set of prefixes than the router is really may authorize a larger set of subnet prefixes than the router is
authorized to advertise on a given interface. For instance, SEND really authorized to advertise on a given interface. For instance,
allows the use of the null prefix. This prefix might cause SEND allows the use of the null prefix. This prefix might cause
verification or routing problems in other applications. It is verification or routing problems in other applications. It is
RECOMMENDED that SEND certificates containing the null prefix are RECOMMENDED that SEND certificates containing the null prefix are
only used for SEND. only used for SEND.
Note that end hosts need not be provisioned with their own certified Note that end hosts need not be provisioned with their own certified
public keys, just as Web clients today do not require end host public keys, just as Web clients today do not require end host
provisioning with certified keys. Public keys for CGA generation do provisioning with certified keys. Public keys for CGA generation do
not need to be certified, since such keys derive their ability to not need to be certified, since such keys derive their ability to
authorize operations on the CGA by the tie to the address. authorize operations on the CGA by the tie to the address.
6.2 Deployment Model 6.2 Deployment Model
The deployment model for trust anchors can be either a globally The deployment model for trust anchors can be either a globally
rooted public key infrastructure, or a more local, decentralized rooted public key infrastructure, or a more local, decentralized
deployment model similar to the current model used for TLS in Web deployment model similar to the current model used for TLS in Web
servers. The centralized model assumes a global root capable of servers. The centralized model assumes a global root capable of
authorizing routers and, optionally, the address space they authorizing routers and, optionally, the address space they
advertise. The end hosts are configured with the public keys of the advertise. The end hosts are configured with the public keys of the
global root. The global root could operate, for instance, under the global root. The global root could operate, for instance, under the
Internet Assigned Numbers Authority (IANA) or as a co-operation among Internet Assigned Numbers Authority (IANA) or as a co-operative among
Regional Internet Registries (RIRs). However, no such global root Regional Internet Registries (RIRs). However, no such global root
currently exists. currently exists.
In the decentralized model, end hosts are configured with a In the decentralized model, end hosts are configured with a
collection of trusted public keys that form the trust anchors. The collection of trusted public keys. The public keys could be issued
public keys could be issued from a variety of places, for example: a) from a variety of places, for example: a) a public key for the end
a public key for the end host's own organization, b) a public key for host's own organization, b) a public key for the end host's home ISP
the end host's home ISP and for ISPs with which the home ISP has a and for ISPs with which the home ISP has a roaming agreement, or c)
roaming agreement, or c) public keys for roaming brokers that act as public keys for roaming brokers that act as intermediaries for ISPs
intermediaries for ISPs that don't want to run their own that don't want to run their own certification authority.
certification authority.
This decentralized model works even when a SEND node is used both in This decentralized model works even when a SEND node is used both in
networks that have certified routers and in networks that do not. As networks that have certified routers and in networks that do not. As
discussed in Section 8, a SEND node can fallback to the use of a discussed in Section 8, a SEND node can fallback to the use of a
non-SEND router. This makes it possible to start with a local trust non-SEND router. This makes it possible to start with a local trust
anchor even if there is no trust anchor for all possible networks. anchor even if there is no trust anchor for all possible networks.
6.3 Certificate Format 6.3 Certificate Format
The certification path of a router terminates in a Router The certification path of a router terminates in a Router
skipping to change at page 29, line 30 skipping to change at page 29, line 30
anchor. Note that there MAY be multiple certificates issued by a anchor. Note that there MAY be multiple certificates issued by a
single trust anchor. single trust anchor.
6.3.1 Router Authorization Certificate Profile 6.3.1 Router Authorization Certificate Profile
Router Authorization Certificates are X.509v3 certificates, as Router Authorization Certificates are X.509v3 certificates, as
defined in RFC 3280 [10], and SHOULD contain at least one instance of defined in RFC 3280 [10], and SHOULD contain at least one instance of
the X.509 extension for IP addresses, as defined in [13]. The parent the X.509 extension for IP addresses, as defined in [13]. The parent
certificates in the certification path SHOULD contain one or more certificates in the certification path SHOULD contain one or more
X.509 IP address extensions, back up to a trusted party (such as the X.509 IP address extensions, back up to a trusted party (such as the
user's ISP) that configured the original IP address space block for user's ISP) that configured the original IP address block for the
the router in question, or delegated the right to do so. The router in question, or delegated the right to do so. The certificates
certificates for the intermediate delegating authorities SHOULD for the intermediate delegating authorities SHOULD contain X.509 IP
contain X.509 IP address extension(s) for subdelegations. The address extension(s) for subdelegations. The router's certificate is
router's certificate is signed by the delegating authority for the signed by the delegating authority for the subnet prefixes the router
prefixes the router is authorized to advertise. is authorized to advertise.
The X.509 IP address extension MUST contain at least one The X.509 IP address extension MUST contain at least one
addressesOrRanges element. This element MUST contain an addressPrefix addressesOrRanges element. This element MUST contain an addressPrefix
element containing an IPv6 address prefix for a prefix the router or element containing an IPv6 address prefix for a prefix the router or
the intermediate entity is authorized to route. If the entity is the intermediate entity is authorized to route. If the entity is
allowed to route any prefix, the used IPv6 address prefix is the null allowed to route any prefix, the used IPv6 address prefix is the null
prefix, ::/0. The addressFamily element of the containing prefix, ::/0. The addressFamily element of the containing
IPAddrBlocks sequence element MUST contain the IPv6 Address Family IPAddrBlocks sequence element MUST contain the IPv6 Address Family
Identifier (0002), as specified in [13] for IPv6 prefixes. Instead Identifier (0002), as specified in [13] for IPv6 subnet prefixes.
of an addressPrefix element, the addressesOrRange element MAY contain Instead of an addressPrefix element, the addressesOrRange element MAY
an addressRange element for a range of prefixes, if more than one contain an addressRange element for a range of subnet prefixes, if
prefix is authorized. The X.509 IP address extension MAY contain more than one prefix is authorized. The X.509 IP address extension
additional IPv6 prefixes, expressed either as an addressPrefix or an MAY contain additional IPv6 subnet prefixes, expressed either as an
addressRange. addressPrefix or an addressRange.
A node receiving a Router Authorization Certificate MUST first check A node receiving a Router Authorization Certificate MUST first check
whether the certificate's signature was generated by the delegating whether the certificate's signature was generated by the delegating
authority. Then the client SHOULD check whether all the authority. Then the client SHOULD check whether all the
addressPrefix or addressRange entries in the router's certificate are addressPrefix or addressRange entries in the router's certificate are
contained within the address ranges in the delegating authority's contained within the address ranges in the delegating authority's
certificate, and whether the addressPrefix entries match any certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority's certificate. If addressPrefix entries in the delegating authority's certificate. If
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 subnet prefixes or ranges, the client MAY
take an intersection of the ranges/prefixes, and use that attempt to take an intersection of the ranges/subnet prefixes, and
intersection. If the resulting intersection is empty, the client MUST use that intersection. If the resulting intersection is empty, the
NOT accept the certificate. If the addressPrefix in the certificate client MUST NOT accept the certificate. If the addressPrefix in the
is missing or is the null prefix, ::/0, the parent prefix or range certificate is missing or is the null prefix, ::/0, the parent prefix
SHOULD be used. If there is no parent prefix or range, the prefixes or range SHOULD be used. If there is no parent prefix or range, the
that the router advertises are said to be unconstrained (see Section subnet prefixes that the router advertises are said to be
7.3). That is, the router is allowed to advertise any prefix. unconstrained (see Section 7.3). That is, the router is allowed to
advertise any prefix.
The above check SHOULD be done for all certificates in the path. If The above check SHOULD be done for all certificates in the path. 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 The client also needs to perform validation of advertised subnet
discussed in Section 7.3. prefixes as discussed in Section 7.3.
Hosts MUST check the subjectPublicKeyInfo field within the last Hosts MUST check the subjectPublicKeyInfo field within the last
certificate in the certificate path to ensure that only RSA public certificate in the certificate path to ensure that only RSA public
keys are used to attempt validation of router signatures, and MUST keys are used to attempt validation of router signatures, and MUST
disregard the certificate for SEND if it does not contain an RSA key. disregard the certificate for SEND if it does not contain an RSA key.
Since it is possible that some public key certificates used with SEND Since it is possible that some public key certificates used with SEND
do not immediately contain the X.509 IP address extension element, an do not 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
skipping to change at page 32, line 11 skipping to change at page 32, line 16
Since deployment of the IP address extension is, itself, not common, Since deployment of the IP address extension is, itself, not common,
a network service provider MAY choose to deploy standard identity a network service provider MAY choose to deploy standard identity
certificates on the router to supply the router's public key for certificates on the router to supply the router's public key for
signed Router Advertisements. signed Router Advertisements.
If there is no prefix information further up in the certification If there is no prefix information further up in the certification
path, a host interprets a standard identity certificate as allowing path, a host interprets a standard identity certificate as allowing
unconstrained prefix advertisements. unconstrained prefix advertisements.
If the other certificates do contain prefix information, a standard If the other certificates do contain prefix information, a standard
identity certificate is interpreted as allowing those prefixes. identity certificate is interpreted as allowing those subnet
prefixes.
6.4 Certificate Transport 6.4 Certificate Transport
The Certification Path Solicitation (CPS) message is sent by a host The Certification Path Solicitation (CPS) message is sent by a host
when it wishes to request a certification path between a router and when it wishes to request a certification path between a router and
one of the host's trust anchors. The Certification Path one of the host's trust anchors. The Certification Path
Advertisement (CPA) message is sent in reply to the CPS message. Advertisement (CPA) message is sent in reply to the CPS message.
These messages are separate from the rest of Neighbor and Router These messages are separate from the rest of Neighbor and Router
Discovery, in order to reduce the effect of the potentially Discovery, in order to reduce the effect of the potentially
voluminous certification path information on other messages. voluminous certification path information on other messages.
skipping to change at page 35, line 33 skipping to change at page 35, line 46
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 advertisements sent to the All-Nodes field MUST be zero for advertisements sent to the All-Nodes
multicast address and MUST NOT be zero for others. multicast address and MUST NOT be zero for others.
All Components All Components
A 16-bit unsigned integer field, used for informing the A 16-bit unsigned integer field, used for informing the
receiver how many certificates there are in the whole path. receiver how many certificates are in the entire path.
A single advertisement SHOULD be broken into separately sent A single advertisement SHOULD be broken into separately sent
components if there is more than one Certificate option, in components if there is more than one certificate in the path,
order to avoid excessive fragmentation at the IP layer. Unlike in order to avoid excessive fragmentation at the IP layer.
the fragmentation at the IP layer, individual components of an
advertisement may be stored and used before all the components Individual certificates in a path MAY be stored and used as
have arrived; this makes them slightly more reliable and less received before all the certificates have arrived; this makes
prone to Denial-of-Service attacks. the protocol slightly more reliable and less prone to
Denial-of-Service attacks.
Example packet lengths of Certification Path Advertisement Example packet lengths of Certification Path Advertisement
messages for typical certification paths are listed in Appendix messages for typical certification paths are listed in Appendix
C. C.
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. receiver which certificate is being sent.
The first message in a N-component advertisement has the The first message in a N-component advertisement has the
Component field set to N-1, the second set to N-2, and so on. Component field set to N-1, the second set to N-2, and so on.
Zero indicates that there are no more components coming in this Zero indicates that there are no more components coming in this
advertisement. advertisement.
The components SHOULD be ordered so that the certificate after The sending of path components SHOULD be ordered so that the
the trust anchor is the one sent first. Each certificate sent certificate after the trust anchor is sent first. Each
after the first can be verified with the previously sent certificate sent after the first can be verified with the
certificates. The certificate of the sender comes last. previously sent certificates. The certificate of the sender
comes last. The trust anchor certificate SHOULD NOT be sent.
Reserved Reserved
An unused field. It MUST be initialized to zero by the sender An unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
Valid Options: Valid Options:
Certificate Certificate
One certificate is provided in each Certificate option, to One certificate is provided in each Certificate option, to
establish a (part of a) certification path to a trust anchor. establish part of a certification path to a trust anchor.
The certificate of the trust anchor itself SHOULD NOT be The certificate of the trust anchor itself SHOULD NOT be sent.
included.
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
skipping to change at page 40, line 3 skipping to change at page 40, line 16
solicitations, the router SHOULD send the response to the All-Nodes solicitations, the router SHOULD send the response to the All-Nodes
multicast address regardless of the source address that appeared in multicast address regardless of the source address that appeared in
the solicitation. the solicitation.
In an advertisement, the router SHOULD include suitable Certificate In an advertisement, the router SHOULD include suitable Certificate
options so that a certification path to the solicited trust anchor options so that a certification path to the solicited trust anchor
can be established (or a part of it, if the Component field in the can be established (or a part of it, if the Component field in the
solicitation is not equal to 65,535). Note also that a single solicitation is not equal to 65,535). Note also that a single
advertisement is broken into separately sent components and ordered advertisement is broken into separately sent components and ordered
in a particular way (see Section 6.4.2) when there is more than one in a particular way (see Section 6.4.2) when there is more than one
Certificate option. certificate in the path.
The anchor is identified by the Trust Anchor option. If the Trust The anchor is identified by the Trust Anchor option. If the Trust
Anchor option is represented as a DER Encoded X.501 Name, then the Anchor option is represented as a DER Encoded X.501 Name, then the
Name must be equal to the Subject field in the anchor's certificate. Name must be equal to the Subject field in the anchor's certificate.
If the Trust Anchor option is represented as an FQDN, the FQDN must If the Trust Anchor option is represented as an FQDN, the FQDN must
be equal to an FQDN in the subjectAltName field of the anchor's be equal to an FQDN in the subjectAltName field of the anchor's
certificate. The router SHOULD include the Trust Anchor option(s) in certificate. The router SHOULD include the Trust Anchor option(s) in
the advertisement for which the certification path was found. the advertisement for which the certification path was found.
If the router is unable to find a path to the requested anchor, it If the router is unable to find a path to the requested anchor, it
skipping to change at page 41, line 7 skipping to change at page 41, line 20
with certificates that the host cannot validate and overwhelms memory with certificates that the host cannot validate and overwhelms memory
for certificate storage. for certificate storage.
Note that caching this information and the implied verification Note that caching this information and the implied verification
results between network attachments for use over multiple attachments results between network attachments for use over multiple attachments
to the network can help improve performance. But periodic certificate to the network can help improve performance. But periodic certificate
revocation checks are still needed even with cached results, to make revocation checks are still needed even with cached results, to make
sure that the certificates are still valid. sure that the certificates are still valid.
The host has a need to retrieve a certification path when a Router The host has a need to retrieve a certification path when a Router
Advertisement has been received with a public key that is not stored Advertisement has been received with a public key that is not
in the hosts' cache of certificates, or there is no certification available from a certificate in the hosts' cache of certificates, or
path to the host's trust anchor. In these situations, the host MAY there is no certification path to the one of the host's trust
transmit up to MAX_CPS_MESSAGES Certification Path Solicitation anchors. In these situations, the host MAY transmit up to
messages, each separated by at least CPS_INTERVAL seconds. In MAX_CPS_MESSAGES Certification Path Solicitation messages, each
addition, hosts MAY also transmit up to MAX_CPS_MESSAGES separated by at least CPS_INTERVAL seconds. In addition, hosts MAY
Certification Path Solicitation messages with the Component field set also transmit up to MAX_CPS_MESSAGES Certification Path Solicitation
to a value not equal to 65,535, if they have received only a part of messages with the Component field set to a value not equal to 65,535,
a certification path. if they have received only a part of a certification path.
Certification Path Solicitations SHOULD NOT be sent if the host has a Certification Path Solicitations SHOULD NOT be sent if the host has a
currently valid certification path from a reachable router to a trust currently valid certification path 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
Certification Path Solicitations either to the All-Routers multicast Certification Path 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 a default router has already been default router's IP address, if a default router has already been
selected. selected.
skipping to change at page 42, line 4 skipping to change at page 42, line 17
of protecting Router Discovery. A trust anchor configuration consists of protecting Router Discovery. A trust anchor configuration consists
of the following items: of the following items:
o A public key signature algorithm and associated public key, which o A public key signature algorithm and associated public key, which
may optionally include parameters. may optionally include parameters.
o A name as described in Section 6.4.3. o A name as described in Section 6.4.3.
o An optional public key identifier. o An optional public key identifier.
o An optional list of address ranges the trust anchor is authorized o An optional list of address ranges for which the trust anchor is
for. authorized.
If the host has been configured to use SEND, it SHOULD possess the If the host has been configured to use SEND, it SHOULD possess the
above information for at least one trust anchor. above information for at least one trust anchor.
Routers are configured with a collection of certification paths and a Routers are configured with a collection of certification paths and a
collection of certified keys and the certificates containing them, collection of certified keys and the certificates containing them,
down to the key and certificate for the router itself. Certified keys down to the key and certificate for the router itself. Certified keys
are required for routers in order that a certification path can be are required for routers in order that a certification path can be
established between the router's certificate and the public key of a established between the router's certificate and the public key of a
trust anchor. trust anchor.
skipping to change at page 43, line 22 skipping to change at page 43, line 22
different communications. A dynamic selection can be provided by an different communications. A dynamic selection can be provided by an
API, such as the one defined in [24]. API, such as the one defined in [24].
7.2 Redirect Addresses 7.2 Redirect Addresses
If the Target Address and Destination Address fields in the ICMP If the Target Address and Destination Address fields in the ICMP
Redirect message are equal, then this message is used to inform hosts 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 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 MUST verify that the given address falls within the range defined by
the router's certificate. Redirect messages failing this check MUST the router's certificate. Redirect messages failing this check MUST
be treated as insecure, as described in Section 7.3. be treated as unsecured, as described in Section 7.3.
Note that RFC 2461 rules prevent a host from accepting a Redirect Note that base NDP rules prevent a host from accepting a Redirect
message from a router that the host is not using to reach the message from a router that the host is not using to reach the
destination mentioned in the redirect. This prevents an attacker from destination mentioned in the redirect. This prevents an attacker from
tricking a node into redirecting traffic when the attacker is not the tricking a node into redirecting traffic when the attacker is not the
default router. default router.
7.3 Advertised Prefixes 7.3 Advertised Subnet 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 securely. A router MAY, however, advertise a allowed to advertise securely. A router MAY, however, advertise a
combination of certified and uncertified prefixes. Uncertified combination of certified and uncertified subnet prefixes. Uncertified
prefixes are treated as insecure, i.e., processed in the same way as subnet prefixes are treated as unsecured, i.e., processed in the same
insecure router advertisements sent by non-SEND routers. The way as unsecured router advertisements sent by non-SEND routers. The
processing of insecure messages is specified in Section 8. Note that processing of unsecured messages is specified in Section 8. Note that
SEND nodes that do not attempt to interoperate with non-SEND nodes SEND nodes that do not attempt to interoperate with non-SEND nodes
MAY simply discard the insecure information. MAY simply discard the unsecured information.
Certified prefixes fall into the following two categories: Certified subnet prefixes fall into the following two categories:
Constrained Constrained
If the network operator wants to constrain which routers are If the network operator wants to constrain which routers are
allowed to route particular prefixes, routers should be configured allowed to route particular subnet prefixes, routers should be
with certificates having prefixes listed in the prefix extension. configured with certificates having subnet prefixes listed in the
Routers so configured SHOULD advertise the prefixes which they are prefix extension. Routers so configured SHOULD advertise the
certified to route, or a subset thereof. subnet prefixes which they are certified to route, or a subset
thereof.
Unconstrained Unconstrained
Network operators that do not want to constrain routers this way Network operators that do not want to constrain routers this way
should configure routers with certificates containing either the should configure routers with certificates containing either the
null prefix or no prefix extension at all. null prefix or no prefix extension at all.
Upon processing a Prefix Information option within a Router Upon processing a Prefix Information option within a Router
Advertisement, nodes SHOULD verify that the prefix specified in this Advertisement, nodes SHOULD verify that the prefix specified in this
option falls within the range defined by the certificate, if the option falls within the range defined by the certificate, if the
certificate contains a prefix extension. Options failing this check certificate contains a prefix extension. Options failing this check
are treated as containing uncertified prefixes. are treated as containing uncertified subnet prefixes.
Nodes SHOULD use one of the certified prefixes for stateless Nodes SHOULD use one of the certified subnet prefixes for stateless
autoconfiguration. If none of the advertised prefixes match, the host autoconfiguration. If none of the advertised subnet prefixes match,
SHOULD use a different advertising router as its default router, if the host SHOULD use a different advertising router as its default
available. If the node is performing stateful autoconfiguration, it router, if available. If the node is performing stateful
SHOULD check the address provided by the DHCP server against the autoconfiguration, it SHOULD check the address provided by the DHCP
certified prefixes and SHOULD NOT use the address if the prefix is server against the certified subnet prefixes and SHOULD NOT use the
not certified. address if the prefix is not certified.
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 certification path-based authorization specifications are Future certification path-based authorization specifications are
needed for such nodes. This specification also does not apply to needed for such nodes. This specification also does not apply to
addresses generated by the IPv6 stateless address autoconfiguration addresses generated by the IPv6 stateless address autoconfiguration
using other fixed forms of interface identifiers (such as EUI-64) as using other fixed forms of interface identifiers (such as EUI-64) as
a basis. a basis.
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
addresses. Such dynamically changing addresses may be the result of addresses. Such dynamically changing addresses may be the result of
stateful or stateless address autoconfiguration, or through the use stateful or stateless address autoconfiguration, or through the use
of RFC 3041 [20] addresses. If the CGA method is not used, nodes of RFC 3041 [20] addresses. If the CGA method is not used, nodes are
would be required to exchange certification paths that terminate in a required to exchange certification paths that terminate in a
certificate authorizing a node to use an IP address having a certificate authorizing a node to use an IP address having a
particular interface identifier. This specification does not specify particular interface identifier. This specification does not specify
the format of such certificates, since there are currently a few the format of such certificates, since there are currently only a few
cases where such certificates are required by the link layer and it cases where such certificates are provided by the link layer and it
is up to the link layer to provide certification for the interface is up to the link layer to provide certification for the interface
identifier. This may be the subject of a future specification. It identifier. This may be the subject of a future specification. It
is also outside the scope of this specification to describe how is also outside the scope of this specification to describe how
stateful address autoconfiguration works with the CGA method. stateful address autoconfiguration works with the CGA method.
The Target Address in Neighbor Advertisement is required to be equal The Target Address in Neighbor Advertisement is required to be equal
to the source address of the packet, except in the case of proxy to the source address of the packet, except in the case of proxy
Neighbor Discovery. Proxy Neighbor Discovery is not supported by this Neighbor Discovery. Proxy Neighbor Discovery is not supported by this
specification. specification.
8. Transition Issues 8. Transition Issues
During the transition to secure links or as a policy consideration, During the transition to secured links or as a policy consideration,
network operators may want to run a particular link with a mixture of network operators may want to run a particular link with a mixture of
secure and insecure nodes. Nodes that support SEND SHOULD support nodes accepting secured and unsecured messages. Nodes that support
the use of SEND and plain NDP at the same time. SEND SHOULD support the use of secured and unsecured NDP messages at
the same time.
In a mixed environment, SEND nodes receive both secure and insecure In a mixed environment, SEND nodes receive both secured and unsecured
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 "unsecured" messages are ones that contain no signature
option. option.
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 Neighbor Solicitation and Advertisement, Router ignore all unsecured Neighbor Solicitation and Advertisement, Router
Solicitation and Advertisement, and Redirect messages. This can be Solicitation and Advertisement, and Redirect messages. This can be
used to enforce SEND-only networks. The default for this used to enforce SEND-only networks. The default for this
configuration option SHOULD be that both secure and insecure messages configuration option SHOULD be that both secured and unsecured
are allowed. messages are allowed.
A SEND node MAY also have a configuration option that causes it to A SEND node MAY also have a configuration option that causes it to
disable the use of SEND completely, even for the messages it sends disable the use of SEND completely, even for the messages it sends
itself. The default for this configuration option SHOULD be that SEND itself. The default for this configuration option SHOULD be off; that
is used. Plain (non-SEND) Neighbor Discovery nodes will obviously is, that SEND is used. Plain (non-SEND) NDP nodes will obviously send
send only insecure messages. Per RFC 2461 [7], such nodes will only unsecured messages. Per RFC 2461 [7], such nodes will ignore
ignore the unknown options and will treat secured messages in the the unknown options and will treat secured messages in the same way
same way as they treat insecure ones. Secured and insecure nodes as they treat unsecured ones. Secured and unsecured nodes share the
share the same network resources, such as prefixes and address same network resources, such as subnet prefixes and address spaces.
spaces.
SEND nodes configured to use SEND at least in their own messages SEND nodes configured to use SEND at least in their own messages
behave in a mixed environment as is explained below. behave in a mixed environment as is explained below.
Protocols defined in RFC 2461 and RFC 2462 are followed with the SEND adheres to the rules defined for the base NDP protocol with the
following exceptions: following exceptions:
o All solicitations sent by a SEND node MUST be secured. o All solicitations sent by a SEND node MUST be secured.
o Unsolicited advertisements sent by a SEND node MUST be secured. o Unsolicited advertisements sent by a SEND node MUST be secured.
o A SEND node MUST send a secured advertisement in response to a o A SEND node MUST send a secured advertisement in response to a
secured solicitation. Advertisements sent in response to an secured solicitation. Advertisements sent in response to an
insecure solicitation MUST be secured as well, but MUST NOT unsecured solicitation MUST be secured as well, but MUST NOT
contain the Nonce option. contain the Nonce option.
o A SEND node that uses the CGA authorization method for protecting o 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.
If after 3 consecutive attempts no non-unique address was If after 3 consecutive attempts no non-unique address was
generated, log a system error and give up attempting to generate generated, log a system error and give up attempting to generate
an address for that interface. 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 unsecured 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. (The security unsecured Neighbor Advertisements and Solicitations. (The security
implications of this are discussed in Section 9.2.3 and [14].) implications of this are discussed in Section 9.2.3 and [14].)
o The node MAY have a configuration option that causes it to ignore o The node MAY have a configuration option that causes it to ignore
insecure advertisements even when performing Duplicate Address unsecured advertisements even when performing Duplicate Address
Detection for the first tentative address. This configuration Detection for the first tentative address. This configuration
option SHOULD be disabled by default. This is a recovery option SHOULD be disabled by default. This is a recovery
mechanism, in case attacks against the first address become mechanism, in case attacks against the first address become
common. common.
o The Neighbor Cache, Prefix List and Default Router list entries o The Neighbor Cache, Prefix List and Default Router list entries
MUST have a secured/insecure flag that indicates whether the MUST have a secured/unsecured 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 unsecured. Received unsecured 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. The Neighbor Cache SHOULD implement a List or Default Router List. The Neighbor Cache SHOULD implement a
flag on entries indicating whether the entry is secured. Received flag on entries indicating whether the entry is secured. Received
secured messages MUST cause an update of the matching entries and secured messages MUST cause an update of the matching entries and
flagging of them as secured. flagging of them as secured.
o The conceptual sending algorithm is modified so that an insecure o The conceptual sending algorithm is modified so that an unsecured
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.
o A node MAY adopt an insecure router, including a SEND router for o A node MAY adopt a router sending unsecured messages, or a router
which full security checks have not yet been completed, while for which secured messages have been received, but for which full
security checking for the SEND router is underway. Security checks security checks have not yet been completed, while security
in this case include certification path solicitation, certificate checking is underway. Security checks in this case include
verification, CRL checks, and RA signature checks. A node MAY also certification path solicitation, certificate verification, CRL
adopt an insecure router if a SEND router becomes unreachable, but checks, and RA signature checks. A node MAY also adopt a router
SHOULD attempt to find a SEND router as soon as possible, since sending unsecured messages if a router known to be secured becomes
the unreachability may be the result of an attack. Note that while unreachable, but SHOULD attempt to find a router known to be
this can speed up attachment to a new network, accepting an secured as soon as possible, since the unreachability may be the
insecure router opens the node to possible attacks, and nodes that result of an attack. Note that while this can speed up attachment
choose to accept insecure routers do so at their own risk. The to a new network, accepting a router sending unsecured messages or
node SHOULD in any case prefer the SEND router as soon as one is for which security checks are not complete opens the node to
available with completed security checks. possible attacks, and nodes that choose to accept such routers do
so at their own risk. The node SHOULD in any case prefer a router
known to be secure as soon as one is available with completed
security checks.
9. Security Considerations 9. Security Considerations
9.1 Threats to the Local Link Not Covered by SEND 9.1 Threats to the Local Link Not Covered by SEND
SEND does not provide confidentiality for NDP communications. SEND does not provide confidentiality for NDP communications.
SEND does not compensate for an insecure link layer. For instance, SEND does not compensate for an unsecured link layer. For instance,
there is no assurance that payload packets actually come from the there is no assurance that payload packets actually come from the
same peer that the NDP was run against. same peer against which the NDP was run.
There may be no cryptographic binding in SEND between the link layer There may be no cryptographic binding in SEND between the link layer
frame address and the IPv6 address. On an insecure link layer that frame address and the IPv6 address. On an unsecured link layer that
allows nodes to spoof the link layer address of other nodes, an allows nodes to spoof the link layer address of other nodes, an
attacker could disrupt IP service by sending out a Neighbor attacker could disrupt IP service by sending out a Neighbor
Advertisement having the source address on the link layer frame of a Advertisement with the link layer source address on the frame being
victim, a valid CGA address and a valid signature corresponding to the source address of a victim, a valid CGA address and a valid
itself, and a Target Link-layer Address extension corresponding to signature corresponding to itself, and a Target Link-layer Address
the victim. The attacker could then proceed to cause a traffic extension corresponding to the victim. The attacker could then
stream to bombard the victim in a DoS attack. This attack cannot be proceed to cause a traffic stream to bombard the victim in a DoS
prevented just by securing the link layer. attack. This attack cannot be prevented just by securing the link
layer.
Even on a secure link layer, SEND does not require that the addresses Even on a secured link layer, SEND does not require that the
on the link layer and Neighbor Advertisements correspond to each addresses on the link layer and Neighbor Advertisements correspond to
other. However, it is RECOMMENDED that such checks be performed where each other. However, it is RECOMMENDED that such checks be performed
this is possible on the given link layer technology. if the link layer technology permits.
Prior to participating in Neighbor Discovery and Duplicate Address Prior to participating in Neighbor Discovery and Duplicate Address
Detection, nodes must subscribe to the link-scoped All-Nodes Detection, nodes must subscribe to the link-scoped All-Nodes
Multicast Group and the Solicited-Node Multicast Group for the Multicast Group and the Solicited-Node Multicast Group for the
address that they are claiming for their addresses; RFC 2461 [7]. address that they are claiming for their addresses; RFC 2461 [7].
Subscribing to a multicast group requires that the nodes use MLD Subscribing to a multicast group requires that the nodes use MLD
[19]. MLD contains no provision for security. An attacker could [19]. MLD contains no provision for security. An attacker could
send an MLD Done message to unsubscribe a victim from the send an MLD Done message to unsubscribe a victim from the
Solicited-Node Multicast address. However, the victim should be able Solicited-Node Multicast address. However, the victim should be able
to detect such an attack because the router sends a to detect such an attack because the router sends a
skipping to change at page 49, line 26 skipping to change at page 50, line 27
Solicitation for the same address regards the situation as a Solicitation for the same address regards the situation as a
collision and ceases to solicit for the address. collision and ceases to solicit for the address.
In either case, SEND counters these treats by requiring the RSA In either case, SEND counters these treats by requiring the RSA
Signature and CGA options to be present in such solicitations. Signature and CGA options to be present in such solicitations.
SEND nodes can send Router Solicitation messages with a CGA SEND nodes can send Router Solicitation messages with a CGA
source address and a CGA option, which the router can verify, so source address and a CGA option, which the router can verify, so
the Neighbor Cache binding is correct. If a SEND node must send the Neighbor Cache binding is correct. If a SEND node must send
a Router Solicitation with the unspecified address, the router a Router Solicitation with the unspecified address, the router
will not update its Neighbor Cache, as per RFC 2461. will not update its Neighbor Cache, as per base NDP.
2. Entries made as a result of a Neighbor Advertisement message. 2. Entries made as a result of a Neighbor Advertisement message.
SEND counters this threat by requiring the RSA Signature and CGA SEND counters this threat by requiring the RSA Signature and CGA
options to be present in these advertisements. options to be present in these advertisements.
See also Section 9.2.5, below, for discussion about replay protection See also Section 9.2.5, below, for discussion about replay protection
and timestamps. and timestamps.
9.2.2 Neighbor Unreachability Detection Failure 9.2.2 Neighbor Unreachability Detection Failure
skipping to change at page 50, line 7 skipping to change at page 51, line 9
This attack is described in Section 4.1.3 of [25]. SEND counters This attack is described in Section 4.1.3 of [25]. SEND counters
this attack by requiring the Neighbor Advertisements sent as this attack by requiring the Neighbor Advertisements sent as
responses to DAD to include an RSA Signature option and proof of responses to DAD to include an RSA 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
tested. If these prerequisites are not met, the node performing DAD tested. If these prerequisites are not met, the node performing DAD
discards the responses. discards the responses.
When a SEND node is performing DAD, it may listen for address When a SEND node is performing DAD, it may listen for address
collisions from non-SEND nodes for the first address it generates, collisions from non-SEND nodes for the first address it generates,
but not for new attempts. This protects the SEND node from DAD DoS but not for new attempts. This protects the SEND node from DAD DoS
attacks by non-SEND nodes or attackers simulating to non-SEND nodes, attacks by non-SEND nodes or attackers simulating non-SEND nodes, at
at the cost of a potential address collision between a SEND node and the cost of a potential address collision between a SEND node and a
non-SEND node. The probability and effects of such an address non-SEND node. The probability and effects of such an address
collision are discussed in [14]. collision are discussed in [14].
9.2.4 Router Solicitation and Advertisement Attacks 9.2.4 Router Solicitation and Advertisement Attacks
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
and 4.2.7 of [25]. SEND counters these attacks by requiring Router and 4.2.7 of [25]. SEND counters these attacks by requiring Router
Advertisements to contain an RSA Signature option, and that the Advertisements to contain an RSA Signature option, and that the
signature is calculated using the public key of a node that can prove signature is calculated using the public key of a node that can prove
its authorization to route the subnet prefixes contained in any its authorization to route the subnet subnet prefixes contained in
Prefix Information Options. The router proves its authorization by any Prefix Information Options. The router proves its authorization
showing a certificate containing the specific prefix or the by showing a certificate containing the specific prefix or the
indication that the router is allowed to route any prefix. A Router indication that the router is allowed to route any prefix. A Router
Advertisement without these protections is discarded. Advertisement without these protections is discarded.
SEND does not protect against brute force attacks on the router, such SEND does not protect against brute force attacks on the router, such
as DoS attacks, or compromise of the router, as described in Sections as DoS attacks, or compromise of the router, as described in Sections
4.4.2 and 4.4.3 of [25]. 4.4.2 and 4.4.3 of [25].
9.2.5 Replay Attacks 9.2.5 Replay Attacks
This attack is described in Section 4.3.1 of [25]. SEND protects This attack is described in Section 4.3.1 of [25]. SEND protects
skipping to change at page 52, line 17 skipping to change at page 53, line 20
SHOULD track the resources devoted to the processing of packets SHOULD track the resources devoted to the processing of packets
received with the RSA Signature option, and start selectively received with the RSA Signature option, and start selectively
discarding packets if too many resources are spent. Implementations discarding packets if too many resources are spent. Implementations
MAY also first discard packets that are not protected with CGA. MAY also first discard packets that are not protected with CGA.
The Authorization Delegation Discovery process may also be vulnerable The Authorization Delegation Discovery process may also be vulnerable
to Denial-of-Service attacks. An attack may target a router by to Denial-of-Service attacks. An attack may target a router by
requesting a large number of certification paths to be discovered for requesting a large number of certification paths to be discovered for
different trust anchors. Routers SHOULD defend against such attacks different trust anchors. Routers SHOULD defend against such attacks
by caching discovered information (including negative responses) and by caching discovered information (including negative responses) and
by limiting the number of different discovery processes they engage by limiting the number of different discovery processes in which they
in. engage.
Attackers may also target hosts by sending a large number of Attackers may also target hosts by sending a large number of
unnecessary certification paths, forcing hosts to spend useless unnecessary certification paths, forcing hosts to spend useless
memory and verification resources for them. Hosts can defend against memory and verification resources for them. Hosts can defend against
such attacks by limiting the amount of resources devoted to the such attacks by limiting the amount of resources devoted to the
certification paths and their verification. Hosts SHOULD also certification paths and their verification. Hosts SHOULD also
prioritize advertisements that sent as a response to their prioritize advertisements sent as a response to solicitations the
solicitations above unsolicited advertisements. hosts have sent above unsolicited advertisements.
10. Protocol Values 10. Protocol Values
10.1 Constants 10.1 Constants
Host constants: Host constants:
MAX_CPS_MESSAGES 3 transmissions MAX_CPS_MESSAGES 3 transmissions
CPS_INTERVAL 4 seconds CPS_INTERVAL 4 seconds
skipping to change at page 60, line 23 skipping to change at page 61, line 23
1. There are a number of nodes on a link, and someone launches a 1. There are a number of nodes on a link, and someone launches a
cache filling attack. The goal here is to make sure that the cache filling attack. The goal here is to make sure that the
nodes can continue to communicate even if the attack is going on. nodes can continue to communicate even if the attack is going on.
2. There is already a cache filling attack going on, and a new node 2. There is already a cache filling attack going on, and a new node
arrives to the link. The goal here is to make it possible for arrives to the link. The goal here is to make it possible for
the new node to become attached to the network, in spite of the the new node to become attached to the network, in spite of the
attack. attack.
From this point of view, it is clearly better to be very selective in Since the intent is to limit the damage to existing, valid cache
how to throw out entries. Reducing the timestamp Delta value is very entries, it is clearly better to be very selective in how to throw
out entries. Reducing the timestamp Delta value is very
discriminatory against those nodes that have a large clock discriminatory against those nodes that have a large clock
difference, while an attacker can reduce its clock difference to difference, since an attacker can reduce its clock difference
arbitrarily small. Throwing out old entries just because their clock arbitrarily. Throwing out old entries just because their clock
difference is large seems like a bad approach. difference is large therefore seems like a bad approach.
A reasonable idea seems to be to have a separate cache space for new A reasonable idea seems to be to have a separate cache space for new
entries and old entries, and under an attack more eagerly drop new entries and old entries, and under an attack more eagerly drop new
cache entries than old ones. One could track traffic, and only allow cache entries than old ones. One could track traffic, and only allow
those new entries that receive genuine traffic to be converted into those new entries that receive genuine traffic to be converted into
old cache entries. While such a scheme will make attacks harder, it old cache entries. While such a scheme can make attacks harder, it
will not fully prevent them. For example, an attacker could send a will not fully prevent them. For example, an attacker could send a
little traffic (i.e. a ping or TCP syn) after each NS to trick the little traffic (i.e. a ping or TCP syn) after each NS to trick the
victim into promoting its cache entry to the old cache. Hence, the victim into promoting its cache entry to the old cache. To counter
node may be more intelligent in keeping its cache entries, and not this, the node can be more intelligent in keeping its cache entries,
just have a black/white old/new boundary. and not just have a black/white old/new boundary.
It also looks like a good idea to consider the Sec parameter when Consideration of the Sec parameter from the CGA Parameters when
forcing cache entries out, and let those entries with a larger Sec a forcing cache entries out - by keeping entries with larger Sec
higher chance of staying in. parameters preferentially - also appears to be a possible approach,
since CGAs with higher Sec parameters are harder to spoof.
Appendix C. Message Size When Carrying Certificates Appendix C. Message Size When Carrying Certificates
In one example scenario using SEND, an Authorization Delegation In one example scenario using SEND, an Authorization Delegation
Discovery test run was made using a certification path length four. Discovery test run was made using a certification path length of
This results in having to send three certificates using the four. Three certificates are sent using Certification Path
Certification Path Advertisement messages as the trust anchor's Advertisement messages, since the trust anchor's certificate is
certificate is already known by both parties. Using a key length of already known by both parties. With a key length of 1024 bits, the
1024 bits, the implementation used in the test run used certificates certificate lengths in the test run ranged from 864 to 888 bytes; the
ranging from 864 to 888 bytes long; the variation is due to the variation is due to the differences in the certificate issuer names
differences in the certificate issuer names and prefix extensions in and address prefix extensions. The different certificates had between
the certificates. The different certificates had one to four prefix one to four address prefix extensions.
extensions.
The three Certification Path Advertisement messages ranged from 1050 The three Certification Path Advertisement messages ranged from 1050
to 1066 bytes on an Ethernet link layer. The certificate itself to 1066 bytes on an Ethernet link layer. The certificate itself
accounts for the bulk of the packet. The rest is the trust anchor accounts for the bulk of the packet. The rest is the trust anchor
option, ICMP header, IPv6 header, and link layer header. option, ICMP header, IPv6 header, and link layer header.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
 End of changes. 

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