< draft-ietf-send-ndopt-05.txt   draft-ietf-send-ndopt-06.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: October 12, 2004 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
April 13, 2004 July 17, 2004
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-05 draft-ietf-send-ndopt-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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 October 12, 2004. 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 to 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 . . . . . . . . . . . . 4 1.1 Specification of Requirements . . . . . . . . . . . . 5
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 9
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 11
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 13
5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 11 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 Processing Rules for Senders . . . . . . . . . . 12 5.1.1 Processing Rules for Senders . . . . . . . . . . 14
5.1.2 Processing Rules for Receivers . . . . . . . . . 13 5.1.2 Processing Rules for Receivers . . . . . . . . . 15
5.1.3 Configuration . . . . . . . . . . . . . . . . . 14 5.1.3 Configuration . . . . . . . . . . . . . . . . . 16
5.2 Signature Option . . . . . . . . . . . . . . . . . . . 14 5.2 RSA Signature Option . . . . . . . . . . . . . . . . . 16
5.2.1 Processing Rules for Senders . . . . . . . . . . 16 5.2.1 Processing Rules for Senders . . . . . . . . . . 18
5.2.2 Processing Rules for Receivers . . . . . . . . . 17 5.2.2 Processing Rules for Receivers . . . . . . . . . 19
5.2.3 Configuration . . . . . . . . . . . . . . . . . 18 5.2.3 Configuration . . . . . . . . . . . . . . . . . 20
5.2.4 Performance Considerations . . . . . . . . . . . 19 5.2.4 Performance Considerations . . . . . . . . . . . 21
5.3 Timestamp and Nonce options . . . . . . . . . . . . . 19 5.3 Timestamp and Nonce options . . . . . . . . . . . . . 21
5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 19 5.3.1 Timestamp Option . . . . . . . . . . . . . . . . 21
5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 20 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . . 22
5.3.3 Processing rules for senders . . . . . . . . . . 21 5.3.3 Processing rules for senders . . . . . . . . . . 23
5.3.4 Processing rules for receivers . . . . . . . . . 22 5.3.4 Processing rules for receivers . . . . . . . . . 24
6. Authorization Delegation Discovery . . . . . . . . . . . . . 25 6. Authorization Delegation Discovery . . . . . . . . . . . . . 27
6.1 Certificate Format . . . . . . . . . . . . . . . . . . 25 6.1 Authorization Model . . . . . . . . . . . . . . . . . 27
6.1.1 Router Authorization Certificate Profile . . . . 25 6.2 Deployment Model . . . . . . . . . . . . . . . . . . . 28
6.2 Certificate Transport . . . . . . . . . . . . . . . . 28 6.3 Certificate Format . . . . . . . . . . . . . . . . . . 29
6.2.1 Delegation Chain Solicitation Message Format . . 28 6.3.1 Router Authorization Certificate Profile . . . . 29
6.2.2 Delegation Chain Advertisement Message Format . 30 6.3.2 Suitability of Standard Identity Certificates . 32
6.2.3 Trust Anchor Option . . . . . . . . . . . . . . 32 6.4 Certificate Transport . . . . . . . . . . . . . . . . 32
6.2.4 Certificate Option . . . . . . . . . . . . . . . 34 6.4.1 Certification Path Solicitation Message Format . 32
6.2.5 Processing Rules for Routers . . . . . . . . . . 35 6.4.2 Certification Path Advertisement Message Format 34
6.2.6 Processing Rules for Hosts . . . . . . . . . . . 36 6.4.3 Trust Anchor Option . . . . . . . . . . . . . . 37
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.4.4 Certificate Option . . . . . . . . . . . . . . . 38
7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.4.5 Processing Rules for Routers . . . . . . . . . . 39
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 38 6.4.6 Processing Rules for Hosts . . . . . . . . . . . 40
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . . 38 6.5 Configuration . . . . . . . . . . . . . . . . . . . . 42
7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 39 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 43
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 40 7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . . 43
9. Security Considerations . . . . . . . . . . . . . . . . . . 42 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . . 43
9.1 Threats to the Local Link Not Covered by SEND . . . . 42 7.3 Advertised Subnet Prefixes . . . . . . . . . . . . . . 43
9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 42 7.4 Limitations . . . . . . . . . . . . . . . . . . . . . 44
9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 43 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 46
9.2.2 Neighbor Unreachability Detection Failure . . . 43 9. Security Considerations . . . . . . . . . . . . . . . . . . 49
9.2.3 Duplicate Address Detection DoS Attack . . . . . 43 9.1 Threats to the Local Link Not Covered by SEND . . . . 49
9.2.4 Router Solicitation and Advertisement Attacks . 44 9.2 How SEND Counters Threats to NDP . . . . . . . . . . . 49
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 44 9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 50
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 45 9.2.2 Neighbor Unreachability Detection Failure . . . 50
9.3 Attacks against SEND Itself . . . . . . . . . . . . . 45 9.2.3 Duplicate Address Detection DoS Attack . . . . . 50
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 47 9.2.4 Router Solicitation and Advertisement Attacks . 51
11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 48 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 51
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . . 52
Normative References . . . . . . . . . . . . . . . . . . . . 50 9.3 Attacks against SEND Itself . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . . 52 10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 52 10.1 Constants . . . . . . . . . . . . . . . . . . . . . . 54
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 10.2 Variables . . . . . . . . . . . . . . . . . . . . . . 54
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 55 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 55
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 56 Normative References . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 57 Informative References . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 58
A. Contributors and Acknowledgments . . . . . . . . . . . . . . 60
B. Cache Management . . . . . . . . . . . . . . . . . . . . . . 61
C. Message Size When Carrying Certificates . . . . . . . . . . 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
Unreachability Detection (NUD), Duplicate Address Detection (DAD), Unreachability Detection (NUD), Duplicate Address Detection (DAD),
and Redirection. and Redirection.
The original NDP specifications called for the use of IPsec to The original NDP specifications called for the use of IPsec to
protect NDP messages. However, the RFCs do not give detailed protect NDP messages. However, the RFCs do not give detailed
instructions for using IPsec for this. In this particular instructions for using IPsec for this. In this particular
application, IPsec can only be used with a manual configuration of application, IPsec can only be used with a manual configuration of
security associations, due to bootstrapping problems in using IKE security associations, due to bootstrapping problems in using IKE
[21, 16]. Furthermore, the number of such manually configured [22, 18]. Furthermore, the number of such manually configured
security associations needed for protecting NDP can be very large security associations needed for protecting NDP can be very large
[22], making that approach impractical for most purposes. [23], making that approach impractical for most purposes.
The SEND protocol is designed to counter the threats to NDP. These
threats are described in detail in [25]. SEND is applicable in
environments where physical security on the link is not assured (such
as over wireless) and attacks on NDP are a concern.
This document is organized as follows. Section 2 and Section 3 define This document is organized as follows. Section 2 and Section 3 define
some terminology and present a brief review of NDP, respectively. some terminology and present a brief review of NDP, respectively.
Section 4 describes the overall approach to securing NDP. This Section 4 describes the overall approach to securing NDP. This
approach involves the use of new NDP options to carry public-key approach involves the use of new NDP options to carry public-key
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 [13]. 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 certificate chains to describes the mechanism for distributing certification paths to
establish an authorization delegation chain to a common 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
provisioned on end hosts for authorizing address use, and security of
NDP when the entity defending an address is not the same as the
entity claiming that adddress (also known as "proxy ND"). These are
extensions of SEND that may be treated in separate documents should
the need arise.
1.1 Specification of Requirements 1.1 Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in [2]. "MAY" in this document are to be interpreted as described in [2].
2. Terms 2. Terms
Authorization Delegation Discovery (ADD) Authorization Delegation Discovery (ADD)
A process through which SEND nodes can acquire a certificate chain A process through which SEND nodes can acquire a certification
from a peer node to a trust anchor. path from a peer node to a trust anchor.
Certificate Revocation List (CRL)
In one method of certificate revocation, an authority periodically
issues a signed data structure called the Certificate Revocation
List. This list is a time stamped list identifying revoked
certificates, signed by the issuer, and made freely available in a
public repository.
Certification Path Advertisement (CPA)
The advertisement message used in the ADD process.
Certification Path Solicitation (CPS)
The solicitation message used in the ADD process.
Cryptographically Generated Address (CGA) Cryptographically Generated Address (CGA)
A technique [13] whereby an IPv6 address of a node is A technique [14] whereby an IPv6 address of a node is
cryptographically generated using a one-way hash function from the cryptographically generated using a one-way hash function from the
node's public key and some other parameters. node's public key and some other parameters.
Distinguished Encoding Rules (DER)
An encoding scheme for data values, defined in [15].
Duplicate Address Detection (DAD) Duplicate Address Detection (DAD)
A mechanism which assures that two IPv6 nodes on the same link are A mechanism which assures that two IPv6 nodes on the same link are
not using the same address. not using the same address.
Neighbor Discovery Protocol (NDP) Fully Qualified Domain Name (FQDN)
The IPv6 Neighbor Discovery Protocol [7, 8]. A fully qualified domain name consists of a host and domain name,
including top-level domain.
Neighbor Discovery Protocol is a part of ICMPv6 [9]. Internationalized Domain Name (IDN)
Internationalized Domain Names can be used to represent domain
names that contain characters outside the ASCII repertoire. See
RFC 3490 [12].
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 also other functions besides ND. (NDP). NDP contains other functions besides ND.
Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [7, 8].
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
An IPv6 node that does not implement this specification but uses
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.1.1. in Section 6.3.1.
SEND node SEND node
An IPv6 node that implements this specification. An IPv6 node that implements this specification.
Non-SEND node
An IPv6 node that does not implement this specification but uses
only RFC 2461 and RFC 2462 without security.
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
Hosts are configured with a set of trust anchors for the purposes
of protecting Router Discovery. A trust anchor is an entity that
the host trusts to authorize routers to act as routers. A trust
anchor configuration consists of a public key and some associated
parameters (see Section 6.5 for a detailed explanation of these
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,
hosts use any prefix information delivered to them during Router hosts use any prefix information delivered to them during Router
Discovery, and then test the newly formed addresses for Discovery, and then test the newly formed addresses for
uniqueness. A stateful mechanism, DHCPv6 [20], provides additional uniqueness. A stateful mechanism, DHCPv6 [21], provides additional
autoconfiguration features. autoconfiguration features.
o Duplicate Address Detection (DAD) is used for preventing address o Duplicate Address Detection (DAD) is used for preventing address
collisions [8], for instance during Address Autoconfiguration. A collisions [8], for instance during Address Autoconfiguration. A
node that intends to assign a new address to one of its interfaces node that intends to assign a new address to one of its interfaces
first runs the DAD procedure to verify that there is no other node first runs the DAD procedure to verify that there is no other node
using the same address. Since the rules forbid the use of an using the same address. Since the rules forbid the use of an
address until it has been found unique, no higher layer traffic is address until it has been found unique, no higher layer traffic is
possible until this procedure has been completed. Thus, possible until this procedure has been completed. Thus,
preventing attacks against DAD can help ensure the availability of preventing attacks against DAD can help ensure the availability of
skipping to change at page 9, line 17 skipping to change at page 11, line 17
To secure the various functions in NDP, a set of new Neighbor To secure the various functions in NDP, a set of new Neighbor
Discovery options is introduced. They are used to protect NDP Discovery options is introduced. They are used to protect NDP
messages. This specification introduces these options, an messages. This specification introduces these options, an
authorization delegation discovery process, an address ownership authorization delegation discovery process, an address ownership
proof mechanism, and requirements for the use of these components in proof mechanism, and requirements for the use of these components in
NDP. NDP.
The components of the solution specified in this document are as The components of the solution specified in this document are as
follows: follows:
o Certificate chains, anchored on trusted parties, are expected to o Certification paths, anchored on trusted parties, are expected to
certify the authority of routers. A host and a router must have certify the authority of routers. A host must be configured with
at least one common trust anchor before the host can adopt the a trust anchor to which the router has a certification path before
router as its default router. Delegation Chain Solicitation and the host can adopt the router as its default router.
Advertisement messages are used to discover a certificate chain to Certification Path Solicitation and Advertisement messages are
the trust anchor without requiring the actual Router Discovery used to discover a certification path to the trust anchor without
messages to carry lengthy certificate chains. The receipt of a requiring the actual Router Discovery messages to carry lengthy
protected Router Advertisement message for which no certificate certification paths. The receipt of a protected Router
chain is available triggers the authorization delegation discovery Advertisement message for which no certification path is available
process. triggers the authorization delegation discovery process.
o Cryptographically Generated Addresses are used to assure that the o Cryptographically Generated Addresses are used to assure that the
sender of a Neighbor Discovery message is the "owner" of the sender of a Neighbor Discovery message is the "owner" of the
claimed address. A public-private key pair is generated by all claimed address. A public-private key pair is generated by all
nodes before they can claim an address. A new NDP option, the CGA nodes before they can claim an address. A new NDP option, the CGA
option, is used to carry the public key and associated parameters. option, is used to carry the public key and associated parameters.
This specification also allows a node to use non-CGAs with This specification also allows a node to use non-CGAs with
certificates to authorize their use. However, the details of such certificates to authorize their use. However, the details of such
use are beyond the scope of this specification. use are beyond the scope of this specification and are left for
future work.
o A new NDP option, the Signature option, is used to protect all o A new NDP option, the RSA Signature option, is used to protect all
messages relating to Neighbor and Router discovery. messages relating to Neighbor and Router discovery.
Public key signatures protect the integrity of the messages and Public key signatures protect the integrity of the messages and
authenticate the identity of their sender. The authority of a authenticate the identity of their sender. The authority of a
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
would break compatibility between implementations or increase
implementation complexity by forcing implementation of multiple
algorithms and the mechanism to select among them. A second
signature algorithm is only necessary as a recovery mechanism, in
case a flaw is found in RSA. If that happens, a stronger signature
algorithm can be selected and SEND can be revised. The
relationship between the new algorithm and the RSA-based SEND
described in this document would be similar to that between the
RSA-based SEND and Neighbor Discovery without SEND. Information
signed with the stronger algorithm has precedence over that signed
with RSA, in the same way as RSA-signed information now takes
precedence over unsigned information. Implementations of the
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
and Router Discovery messages are in some cases sent to multicast and Router Discovery messages are in some cases sent to multicast
addresses, the Timestamp option offers replay protection without addresses, the Timestamp option offers replay protection without
any previously established state or sequence numbers. When the any previously established state or sequence numbers. When the
messages are used in solicitation - advertisement pairs, they are messages are used in solicitation - advertisement pairs, they are
protected using the Nonce option. protected using the Nonce option.
5. Neighbor Discovery Protocol Options 5. Neighbor Discovery Protocol Options
The options described in this section MUST be supported by all SEND The options described in this section MUST be supported.
nodes.
5.1 CGA Option 5.1 CGA Option
The CGA option allows the verification of the sender's CGA. The The CGA option allows the verification of the sender's CGA. The
format of the CGA option is described as follows. format of the CGA option is described as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | Reserved | | Type | Length | Pad Length | Reserved |
skipping to change at page 12, line 9 skipping to change at page 14, line 8
Reserved Reserved
An 8-bit field reserved for future use. The value MUST be An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
CGA Parameters CGA Parameters
A variable length field containing the CGA Parameters data A variable length field containing the CGA Parameters data
structure described in Section 4 of [13]. structure described in Section 4 of [14].
This specification requires that if both the CGA option and the This specification requires that if both the CGA option and the
Signature option are present, then the public key found from the RSA Signature option are present, then the public key found from
CGA Parameters field in the CGA option MUST be the public key the CGA Parameters field in the CGA option MUST be the public key
referred by the Key Hash field in the Signature option. Packets referred by the Key Hash field in the RSA Signature option.
received with two different keys MUST be silently discarded. Note Packets received with two different keys MUST be silently
that a future extension may provide a mechanism which allows the discarded. Note that a future extension may provide a mechanism
owner of an address and the signer to be different parties. which allows the owner of an address and the signer to be
different parties.
Padding Padding
A variable length field making the option length a multiple of 8, A variable length field making the option length a multiple of 8,
containing as many octets as specified in the Pad Length field. containing as many octets as specified in the Pad Length field.
5.1.1 Processing Rules for Senders 5.1.1 Processing Rules for Senders
The CGA option MUST be present in all Neighbor Solicitation and If the node has been configured to use SEND, the CGA option MUST be
Advertisement messages, and MUST be present in Router Solicitation present in all Neighbor Solicitation and Advertisement messages, and
messages unless they are sent with the unspecified source address. MUST be present in Router Solicitation messages unless they are sent
The CGA option MAY be present in other messages. with the unspecified source address. The CGA option MAY be present in
other messages.
A node sending a message using the CGA option MUST construct the A node sending a message using the CGA option MUST construct the
message as follows. message as follows.
The CGA Parameter field in the CGA option is filled in according to The CGA Parameter field in the CGA option is filled in according to
the rules presented above and in [13]. The public key in the field is the rules presented above and in [14]. The public key in the field is
taken from the node's configuration used to generate the CGA; taken from the node's configuration used to generate the CGA;
typically from a data structure associated with the source address. typically from a data structure associated with the source address.
The address MUST be constructed as specified in Section 4 of [13]. The address MUST be constructed as specified in Section 4 of [14].
Depending on the type of the message, this address appears in Depending on the type of the message, this address appears in
different places: different places:
Redirect Redirect
The address MUST be the source address of the message. The address MUST be the source address of the message.
Neighbor Solicitation Neighbor Solicitation
The address MUST be the Target Address for solicitations sent for The address MUST be the Target Address for solicitations sent for
skipping to change at page 13, line 22 skipping to change at page 15, line 22
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 be also 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.
A message containing a CGA option MUST be checked as follows: Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
Solicitation, and Router Advertisement messages containing a CGA
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 [13]. 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.
Implementations MAY also set an upper limit in order to limit the Implementations MAY also set an upper limit in order to limit the
amount of computation they need to perform when verifying packets amount of computation they need to perform when verifying packets
that use these security associations. The upper limit SHOULD be at that use these security associations. The upper limit SHOULD be at
least 2048 bits. Any implementation should follow prudent least 2048 bits. Any implementation should follow prudent
cryptographic practice in determining the appropriate key lengths. cryptographic practice in determining the appropriate key lengths.
minSec
The minimum acceptable Sec value, if CGA verification is required.
This parameter is intended to facilitate future extensions and
experimental work. Currently, the minSec value SHOULD always be
set to zero.
See Section 2 in [13].
All nodes that support the sending of the CGA option MUST record the All nodes that support the sending of the CGA option MUST record the
following configuration information: following configuration information:
CGA parameters CGA parameters
Any information required to construct CGAs, including the used Sec Any information required to construct CGAs, as described in [14].
and Modifier values, and the CGA address itself.
5.2 Signature Option 5.2 RSA Signature Option
The Signature option allows public-key based signatures to be The RSA Signature option allows public-key based signatures to be
attached to NDP messages. Configured trust anchors, CGAs, or both are attached to NDP messages. The format of the RSA Signature option is
supported as the trusted root. The format of the Signature option is
described in the following diagram: described in the following diagram:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Key Hash | | Key Hash |
| | | |
skipping to change at page 15, line 30 skipping to change at page 17, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
TBD <To be assigned by IANA for Signature>. TBD <To be assigned by IANA for RSA Signature>.
Length Length
The length of the option (including the Type, Length, Reserved, The length of the option (including the Type, Length, Reserved,
Key Hash, Digital Signature, and Padding fields) in units of 8 Key Hash, Digital Signature, and Padding fields) in units of 8
octets. octets.
Reserved Reserved
A 16-bit field reserved for future use. The value MUST be A 16-bit field reserved for future use. The value MUST be
skipping to change at page 16, line 8 skipping to change at page 18, line 8
128-bits of a SHA-1 hash of the public key used for constructing 128-bits of a SHA-1 hash of the public key used for constructing
the signature. The SHA-1 hash is taken over the presentation used the signature. The SHA-1 hash is taken over the presentation used
in the Public Key field of the CGA Parameters data structure that in the Public Key field of the CGA Parameters data structure that
is carried in the CGA option. Its purpose is to associate the is carried in the CGA option. Its purpose is to associate the
signature to a particular key known by the receiver. Such a key signature to a particular key known by the receiver. Such a key
can be either stored in the certificate cache of the receiver, or can be either stored in the certificate cache of the receiver, or
be received in the CGA option in the same message. be received in the CGA option in the same message.
Digital Signature Digital Signature
A variable length field containing a PKCS#1 signature, constructed A variable length field containing a PKCS#1 v1.5 signature,
using the sender's private key, over the the following sequence of constructed using the sender's private key, over the the following
octets: sequence of octets:
1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F 1. The 128-bit CGA Message Type tag [14] value for SEND, 0x086F
CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
generated randomly by the editor of this specification.). generated randomly by the editor of this specification.).
2. The 128-bit Source Address field from the IP header. 2. The 128-bit Source Address field from the IP header.
3. The 128-bit Destination Address field from the IP header. 3. The 128-bit Destination Address field from the IP header.
4. The 32-bit ICMP header. 4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from
the ICMP header.
5. The NDP message header. 5. The NDP message header, starting from the octet after the ICMP
Checksum field and continuing up to but not including NDP
options.
6. All NDP options preceding the Signature option. 6. All NDP options preceding the RSA Signature option.
The signature value is computed with the RSASSA-PKCS1-v1_5 The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-1 hash as defined in [14]. algorithm and SHA-1 hash as defined in [16].
This field starts after the Key Hash field. The length of the This field starts after the Key Hash field. The length of the
Digital Signature field is determined by the length of the Digital Signature field is determined by the length of the RSA
Signature option minus the length of the other fields (including Signature option minus the length of the other fields (including
the variable length Pad field). the variable length Pad field).
Padding Padding
This variable length field contains padding, as many bytes as This variable length field contains padding, as many bytes as
remains after end of the signature. remains after end of the signature.
5.2.1 Processing Rules for Senders 5.2.1 Processing Rules for Senders
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, If the node has been configured to use SEND, Neighbor Solicitation,
and Redirect messages MUST contain the Signature option. Router Neighbor Advertisement, Router Advertisement, and Redirect messages
Solicitation messages not sent with the unspecified source address MUST contain the RSA Signature option. Router Solicitation messages
MUST contain the Signature option. not sent with the unspecified source address MUST contain the RSA
Signature option.
A node sending a message using the Signature option MUST construct
the message as follows:
o The message is constructed in its entirety, without the Signature
option.
o The Signature option is added as the last option in the message.
o For the purpose of constructing a signature, the following data
items are concatenated:
* The 128-bit CGA Type Tag. A node sending a message using the RSA Signature option MUST
construct the message as follows:
* The source address of the message. o The message is constructed in its entirety, without the RSA
Signature option.
* The destination address of the message. o The RSA Signature option is added as the last option in the
message.
* The contents of the message, starting from the ICMPv6 header, o The data to be signed is constructed as explained in Section 5.2,
up to but excluding the Signature option. 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 signature is put configured private key, and the resulting PKCS#1 v1.5 signature is
to 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 Signature option MUST be treated as and Redirect messages without the RSA Signature option MUST be
insecure, i.e., processed in the same way as NDP messages sent by a treated as unsecured, i.e., processed in the same way as NDP messages
non-SEND node. See Section 8. sent by a non-SEND node. See Section 8.
Router Solicitation messages without the Signature option MUST be Router Solicitation messages without the RSA Signature option MUST
also treated as insecure, unless the source address of the message is also be treated as unsecured, unless the source address of the
the unspecified address. message is the unspecified address.
A message containing a Signature option MUST be checked as follows: Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
Solicitation, and Router Advertisement messages containing an RSA
Signature option MUST be checked as follows:
o The receiver MUST ignore any options the come after the first o The receiver MUST ignore any options that come after the first RSA
Signature option. Signature option. (The options are ignored for both signature
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,
either one learned from a preceding CGA option in the same either one learned from a preceding CGA option in the same
message, or one known by other means. message, or one known by other means.
o The Digital Signature field MUST have correct encoding, and not o The Digital Signature field MUST have correct encoding, and not
exceed the length of the Signature option minus the Padding. exceed the length of the RSA Signature option minus the Padding.
o The Digital Signature verification MUST show that the signature o The Digital Signature verification MUST show that the signature
has been calculated as specified in the previous section. has been calculated as specified in the previous section.
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
authorization delegation chain 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. The receiver MAY also otherwise silently discard packets, discarded if the host has been configured to only accept secured ND
e.g., as a response to an apparent CPU exhausting DoS attack. messages. The messages MAY be accepted if the host has been
configured to accept both secured and unsecured messages, but MUST be
treated as an unsecured message. The receiver MAY also otherwise
silently discard packets, e.g., as a response to an apparent CPU
exhausting DoS attack.
5.2.3 Configuration 5.2.3 Configuration
All nodes that support the reception of the Signature options MUST be All nodes that support the reception of the RSA Signature options
configured with the following information for each separate NDP MUST allow the following information to be configured for each
message type: separate NDP message type:
authorization method authorization method
This parameter determines the method through which the authority This parameter determines the method through which the authority
of the sender is determined. It can have four values: of the sender is determined. It can have four values:
trust anchor trust anchor
The authority of the sender is verified as described in Section The authority of the sender is verified as described in Section
6.1. The sender may claim additional authorization through the 6.3. The sender may claim additional authorization through the
use of CGAs, but that is neither required nor verified. use of CGAs, but that is neither required nor verified.
CGA CGA
The CGA property of the sender's address is verified as The CGA property of the sender's address is verified as
described in [13]. The sender may claim additional authority described in [14]. The sender may claim additional authority
through a trust anchor, but that is neither required nor through a trust anchor, but that is neither required nor
verified. verified.
trust anchor and CGA trust anchor and CGA
Both the trust anchor and the CGA verification is required. Both the trust anchor and the CGA verification is required.
trust anchor or CGA trust anchor or CGA
Either the trust anchor or the CGA verification is required. Either the trust anchor or the CGA verification is required.
anchor anchor
The public keys and names of the allowed trust anchor(s), if the The allowed trust anchor(s), if the authorization method is not
authorization method is not set to CGA. set to CGA.
All nodes that support the sending of Signature options MUST record All nodes that support the sending of RSA Signature options MUST
the following configuration information: record the following configuration information:
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 delegation chain 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
and 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. which to communicate, or Neighbor Unreachability Detection with
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 20, line 41 skipping to change at page 22, line 41
Timestamp Timestamp
A 64-bit unsigned integer field containing a timestamp. The value A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1, 1970 00:00 UTC, indicates the number of seconds since January 1, 1970 00:00 UTC,
using a fixed point format. In this format the integer number of using a fixed point format. In this format the integer number of
seconds is contained in the first 48 bits of the field, and the seconds is contained in the first 48 bits of the field, and the
remaining 16 bits indicate the number of 1/64K fractions of a remaining 16 bits indicate the number of 1/64K fractions of a
second. second.
Implementation note: This format is compatible with the usual
representation of time under UNIX, although the number of bits
available for the integer and fraction parts may vary.
5.3.2 Nonce Option 5.3.2 Nonce Option
The purpose of the Nonce option is to assure that an advertisement is The purpose of the Nonce option is to assure that an advertisement is
a fresh response to a solicitation sent earlier by the node. The a fresh response to a solicitation sent earlier by the node. The
format of this option is described in the following: format of this option is described in the following:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce ... | | Type | Length | Nonce ... |
skipping to change at page 21, line 34 skipping to change at page 23, line 34
Nonce Nonce
A field containing a random number selected by the sender of the A field containing a random number selected by the sender of the
solicitation message. The length of the random number MUST be at solicitation message. The length of the random number MUST be at
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
All solicitation messages MUST include a Nonce. When sending a If the node has been configured to use SEND, all solicitation
solicitation, the sender MUST store the nonce internally so that it messages MUST include a Nonce. When sending a solicitation, the
can recognize any replies containing that particular nonce. sender MUST store the nonce internally so that it can recognize any
replies containing that particular nonce.
All solicited advertisements MUST include a Nonce, copied from the If the node has been configured to use SEND, all advertisements sent
in reply to a solicitation MUST include a Nonce, copied from the
received solicitation. Note that routers may decide to send a received solicitation. Note that routers may decide to send a
multicast advertisement to all nodes instead of a response to a multicast advertisement to all nodes instead of a response to a
specific host. In such case the router MAY still include the nonce specific host. In such case the router MAY still include the nonce
value for the host that triggered the multicast advertisement. value for the host that triggered the multicast advertisement.
Omitting the nonce value may, however, cause the host to ignore the (Omitting the nonce value may cause the host to ignore the router's
router's advertisement, unless the clocks in these nodes are advertisement, unless the clocks in these nodes are sufficiently
sufficiently synchronized so that timestamps can be relied on. synchronized so that timestamps function properly.)
All solicitation, advertisement, and redirect messages MUST include a
Timestamp. Senders SHOULD set the Timestamp field to the current
time, according to their real time clock.
If a message has both Nonce and Timestamp options, the Nonce option If the node has been configured to use SEND, all solicitation,
SHOULD precede the Timestamp option in the message. advertisement, and redirect messages MUST include a Timestamp.
Senders SHOULD set the Timestamp field to the current time, according
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 with the Signature option but without the o Messages received without at least one of the the Timestamp and
Nonce options MUST be treated as unsecured, i.e., processed in the
same way as NDP messages sent by a non-SEND node.
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 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 o Advertisements sent to a unicast destination address with the RSA
Signature option but without a Nonce option MUST be silently Signature option but without a Nonce option SHOULD be processed as
discarded. unsolicited advertisements.
o An implementation MAY utilize some mechanism such as a timestamp o An implementation MAY utilize some mechanism such as a timestamp
cache to strengthen resistance to replay attacks. When there is a cache to strengthen resistance to replay attacks. When there is a
very large number of nodes on the same link, or when a cache very large number of nodes on the same link, or when a cache
filling attack is in progress, it is possible that the cache filling attack is in progress, it is possible that the cache
holding the most recent timestamp per sender becomes full. In holding the most recent timestamp per sender becomes full. In
this case the node MUST remove some entries from the cache or this case the node MUST remove some entries from the cache or
refuse some new requested entries. The specific policy as to refuse some new requested entries. The specific policy as to
which entries are preferred over the others is left as an which entries are preferred over the others is left as an
implementation decision. However, typical policies may prefer implementation decision. However, typical policies may prefer
existing entries over new ones, CGAs with a large Sec value over existing entries over new ones, CGAs with a large Sec value over
smaller Sec values, and so on. The issue is briefly discussed in smaller Sec values, and so on. The issue is briefly discussed in
Appendix C. Appendix B.
o The receiver MUST be prepared to receive the Timestamp and Nonce o The receiver MUST be prepared to receive the Timestamp and Nonce
options in any order, as per RFC 2461 [7] Section 9. options in any order, as per RFC 2461 [7] Section 9.
5.3.4.1 Processing solicited advertisements 5.3.4.1 Processing solicited advertisements
The receiver MUST verify that it has recently sent a matching The receiver MUST verify that it has recently sent a matching
solicitation, and that the received advertisement contains a copy of solicitation, and that the received advertisement contains a copy of
the Nonce sent in the solicitation. the Nonce sent in the solicitation.
skipping to change at page 23, line 19 skipping to change at page 25, line 22
If the message is accepted, the receiver SHOULD store the receive If the message is accepted, the receiver SHOULD store the receive
time of the message and the time stamp time in the message, as time of the message and the time stamp time in the message, as
specified in Section 5.3.4.2. specified in Section 5.3.4.2.
5.3.4.2 Processing all other messages 5.3.4.2 Processing all other messages
Receivers SHOULD be configured with an allowed timestamp Delta value, Receivers SHOULD be configured with an allowed timestamp Delta value,
a "fuzz factor" for comparisons, and an allowed clock drift a "fuzz factor" for comparisons, and an allowed clock drift
parameter. The recommended default value for the allowed Delta is parameter. The recommended default value for the allowed Delta is
TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift
TIMESTAMP_DRIFT (see Section 11. TIMESTAMP_DRIFT (see Section 10.2).
To facilitate timestamp checking, each node SHOULD store the To facilitate timestamp checking, each node SHOULD store the
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 Signature option has been used in such a message Signature option MUST be used in such a message before it can update
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 If the timestamp is NOT within the boundaries but the message is a o Even if the timestamp is NOT within the boundaries but the message
Neighbor Solicitation message which should be answered by the is a Neighbor Solicitation message that should be answered by the
receiver, the receiver MAY respond to the message. However, if it receiver, the receiver SHOULD respond to the message. However, if
does respond to the message, it MUST NOT create a Neighbor Cache it does respond to the message, it MUST NOT create a Neighbor
entry. This allows nodes that have large differences in their Cache entry. This allows nodes that have large differences in
clocks to still communicate with each other, by exchanging NS/NA their clocks to still communicate with each other, by exchanging
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:
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
If this inequality does not hold, the receiver SHOULD silently If this inequality does not hold, the receiver SHOULD silently
discard the message. On the other hand, if the inequality holds, discard the message. On the other hand, if the inequality holds,
the receiver SHOULD process the message. the receiver SHOULD process the message.
Moreover, if the above inequality holds and TSnew > TSlast, the Moreover, if the above inequality holds and TSnew > TSlast, the
receiver SHOULD update RDlast and TSlast. Otherwise, the receiver receiver SHOULD update RDlast and TSlast. Otherwise, the receiver
MUST NOT update update RDlast or TSlast. MUST NOT update update RDlast or TSlast.
As unsolicited messages may be used in a Denial-of-Service attack to
cause the receiver to verify computationally expensive signatures,
all nodes SHOULD apply a mechanism to prevent excessive use of
resources for processing such messages.
6. Authorization Delegation Discovery 6. Authorization Delegation Discovery
NDP allows a node to automatically configure itself based on NDP allows a node to automatically configure itself based on
information learned shortly after connecting to a new link. It is information learned shortly after connecting to a new link. It is
particularly easy to configure "rogue" routers on an unsecured link, particularly easy to configure "rogue" routers on an unsecured link,
and it is particularly difficult for a node to distinguish between and it is particularly difficult for a node to distinguish between
valid and invalid sources of router information, because the node valid and invalid sources of router information, because the node
needs this information before being able to communicate with nodes needs this information before being able to communicate with nodes
outside of the link. outside of the link.
Since the newly-connected node cannot communicate off-link, it cannot Since the newly-connected node cannot communicate off-link, it cannot
be responsible for searching information to help validate the be responsible for searching information to help validate the
router(s); however, given a chain of appropriately signed router(s); however, given a certification path, the node can check
certificates, it can check someone else's search results and conclude someone else's search results and conclude that a particular message
that a particular message comes from an authorized source. In the comes from an authorized source. In the typical case, a router
typical case, a router already connected to beyond the link, can (if already connected beyond the link, can (if necessary) communicate
necessary) communicate with off-link nodes and construct such a with off-link nodes and construct such a certification path.
certificate chain.
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 certificate chain 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 Certificate Format 6.1 Authorization Model
The certificate chain of a router terminates in a Router To protect Router Discovery, SEND requires routers to be authorized
to act as routers. This authorization is provisioned in both routers
and hosts: routers are given certificates from a trust anchor and the
hosts are configured with the trust anchor(s) to authorize routers.
This provisioning is specific to SEND, and does not assume that
certificates already deployed for some other purpose can be used.
The authorization for routers in SEND is twofold:
o Routers are authorized to act as routers. The router belongs to
the set of routers trusted by the trust anchor. All routers in
this set have the same authorization.
o Optionally, routers may also be authorized to advertise a certain
set of subnet prefixes. A specific router is given a specific set
of subnet prefixes to advertise; other routers have an
authorization to advertise other subnet prefixes. Trust anchors
may also delegate a certain set of subnet prefixes to someone
(such as an ISP), who in turn delegates parts of this set to
individual routers.
Note that while communicating with hosts, routers typically present
also a number of other parameters beyond the above. For instance,
routers have their own IP addresses, subnet prefixes have lifetimes,
routers control the use of stateless and stateful address
autoconfiguration, and so on. However, the ability to be a router and
the subnet prefixes are the most fundamental parameters to authorize.
This is because the host needs to choose a router that it uses as its
default router, and because the advertised subnet prefixes have an
impact on the addresses the host uses. In addition, the subnet
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
to provide authorization in other circumstances, for example with
routing protocols. It is necessary to ensure that the authorization
information is appropriate for all applications. SEND certificates
may authorize a larger set of subnet prefixes than the router is
really authorized to advertise on a given interface. For instance,
SEND allows the use of the null prefix. This prefix might cause
verification or routing problems in other applications. It is
RECOMMENDED that SEND certificates containing the null prefix are
only used for SEND.
Note that end hosts need not be provisioned with their own certified
public keys, just as Web clients today do not require end host
provisioning with certified keys. Public keys for CGA generation do
not need to be certified, since such keys derive their ability to
authorize operations on the CGA by the tie to the address.
6.2 Deployment Model
The deployment model for trust anchors can be either a globally
rooted public key infrastructure, or a more local, decentralized
deployment model similar to the current model used for TLS in Web
servers. The centralized model assumes a global root capable of
authorizing routers and, optionally, the address space they
advertise. The end hosts are configured with the public keys of the
global root. The global root could operate, for instance, under the
Internet Assigned Numbers Authority (IANA) or as a co-operative among
Regional Internet Registries (RIRs). However, no such global root
currently exists.
In the decentralized model, end hosts are configured with a
collection of trusted public keys. The public keys could be issued
from a variety of places, for example: a) a public key for the end
host's own organization, b) a public key for the end host's home ISP
and for ISPs with which the home ISP has a roaming agreement, or c)
public keys for roaming brokers that act as intermediaries for ISPs
that don't want to run their own certification authority.
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
discussed in Section 8, a SEND node can fall back to the use of a
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.
6.3 Certificate Format
The certification path of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization chains are not a common practice as a router. Because authorization paths are not a common practice
in the Internet at the time this specification was written, the chain in the Internet at the time this specification was written, the path
MUST consist of standard Public Key Certificates (PKC, in the sense MUST consist of standard Public Key Certificates (PKC, in the sense
of [19]). The certificate chain MUST start from the identity of a of [11]). The certification path MUST start from the identity of a
trust anchor that is shared by the host and the router. This allows trust anchor that is shared by the host and the router. This allows
the host to anchor trust for the router's public key in the trust the host to anchor trust for the router's public key in the trust
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.1.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 MUST 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 [12]. The parent the X.509 extension for IP addresses, as defined in [13]. The parent
certificates in the certificate chain MUST contain one or more X.509 certificates in the certification path SHOULD contain one or more
IP address extensions, back up to a trusted party (such as the user's X.509 IP address extensions, back up to a trusted party (such as the
ISP) that configured the original IP address space block for the user's ISP) that configured the original IP address block for the
router in question, or delegated the right to do so. The certificates router in question, or delegated the right to do so. The certificates
for the intermediate delegating authorities MUST contain X.509 IP for the intermediate delegating authorities SHOULD contain X.509 IP
address extension(s) for subdelegations. The router's certificate is address extension(s) for subdelegations. The router's certificate is
signed by the delegating authority for the prefixes the router is signed by the delegating authority for the subnet prefixes the router
authorized to 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 [12] 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 SEND node receiving a Router Authorization Certificate MUST first A node receiving a Router Authorization Certificate MUST first check
check whether the certificate's signature was generated by the whether the certificate's signature was generated by the delegating
delegating authority. Then the client MUST 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 addressPrefix in the certificate is the null use that intersection. If the resulting intersection is empty, the
prefix, ::/0, such an intersection SHOULD be used. (In that case the client MUST NOT accept the certificate. If the addressPrefix in the
intersection is the parent prefix or range.) If the resulting certificate is missing or is the null prefix, ::/0, the parent prefix
intersection is empty, the client MUST NOT accept the certificate. or range SHOULD be used. If there is no parent prefix or range, the
subnet prefixes that the router advertises are said to be
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 chain. 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.
Care should be taken if the certificates used in SEND are re-used to Hosts MUST check the subjectPublicKeyInfo field within the last
provide authorization in other circumstances, for example with certificate in the certificate path to ensure that only RSA public
routing protocols. It is necessary to ensure that the authorization keys are used to attempt validation of router signatures, and MUST
information is appropriate for all applications. SEND certificates disregard the certificate for SEND if it does not contain an RSA key.
may authorize a larger set of prefixes than the router is really
authorized to advertise on a given interface. For instance, SEND
allows the use of the null prefix. This prefix might cause
verification or routing problems in other applications. It is
RECOMMENDED that SEND certificates containing the null prefix are
only used for SEND.
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
be off by default. That is, the system SHOULD have a default be off by default. That is, the system SHOULD have a default
configuration that requires rigorous prefix and range checks. configuration that requires rigorous prefix and range checks.
The following is an example of a certificate chain. Suppose that The following is an example of a certification path. Suppose that
isp_group_example.net is the trust anchor. The host has this isp_group_example.net is the trust anchor. The host has this
certificate: certificate:
Certificate 1: Certificate 1:
Issuer: isp_group_example.net Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004 Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group_example.net Subject: isp_group_example.net
Extensions: Extensions:
IP address delegation extension: IP address delegation extension:
Prefixes: P1, ..., Pk Prefixes: P1, ..., Pk
... possibly other extensions ... ... possibly other extensions ...
... other certificate parameters ... ... other certificate parameters ...
When the host attaches to a link served by When the host attaches to a link served by
router_x.isp_foo_example.net, it receives the following certificate router_x.isp_foo_example.net, it receives the following certification
chain: path:
Certificate 2: Certificate 2:
Issuer: isp_group_example.net Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004 Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo_example.net Subject: isp_foo_example.net
Extensions: Extensions:
IP address delegation extension: IP address delegation extension:
Prefixes: Q1, ..., Qk Prefixes: Q1, ..., Qk
... possibly other extensions ... ... possibly other extensions ...
... other certificate parameters ... ... other certificate parameters ...
skipping to change at page 27, line 48 skipping to change at page 31, line 27
... other certificate parameters ... ... other certificate parameters ...
Certificate 3: Certificate 3:
Issuer: isp_foo_example.net Issuer: isp_foo_example.net
Validity: Jan 1, 2004 through Dec 31, 2004 Validity: Jan 1, 2004 through Dec 31, 2004
Subject: router_x.isp_foo_example.net Subject: router_x.isp_foo_example.net
Extensions: Extensions:
IP address delegation extension: IP address delegation extension:
Prefixes R1, ..., Rk Prefixes R1, ..., Rk
... possibly other extensions ... ... possibly other extensions ...
... other certificate parameters ... ... other certificate parameters ...
When processing the three certificates, the usual RFC 3280 [10] When processing the three certificates, the usual RFC 3280 [10]
certificate path validation is performed. Note, however, that at the certificate path validation is performed. Note, however, that at the
time a node is checking certificates received in a DCA from a router, time a node is checking certificates received from a router, it
it typically does not have a connection to the Internet yet, and so typically does not have a connection to the Internet yet, and so it
it is not possible to perform an on-line Certificate Revocation List is not possible to perform an on-line Certificate Revocation List
(CRL) check if such a check is necessary. Until such a check is (CRL) check if such a check is necessary. Until such a check is
performed, acceptance of the certificate MUST be considered performed, acceptance of the certificate MUST be considered
provisional, and the node MUST perform a check as soon as it has provisional, and the node MUST perform a check as soon as it has
established a connection with the Internet through the router. If the established a connection with the Internet through the router. If the
router has been compromised, it could interfere with the CRL check. router has been compromised, it could interfere with the CRL check.
Should performance of the CRL check be disrupted or should the check Should performance of the CRL check be disrupted or should the check
fail, the node SHOULD immediately stop using the router as a default fail, the node SHOULD immediately stop using the router as a default
and use another router on the link instead. and use another router on the link instead.
In addition, the IP addresses in the delegation extension must be a In addition, the IP addresses in the delegation extension MUST be a
subset of the IP addresses in the delegation extension of the subset of the IP addresses in the delegation extension of the
issuer's certificate. So in this example, R1, ..., Rs must be a issuer's certificate. So in this example, R1, ..., Rs must be a
subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If
the certificate chain is valid, then router_foo.isp_foo_example.com the certification path is valid, then router_foo.isp_foo_example.com
is authorized to route the prefixes R1,...,Rs. is authorized to route the prefixes R1,...,Rs.
6.2 Certificate Transport 6.3.2 Suitability of Standard Identity Certificates
The Delegation Chain Solicitation (DCS) message is sent by a host Since deployment of the IP address extension is, itself, not common,
when it wishes to request a certificate chain between a router and a network service provider MAY choose to deploy standard identity
the one of the host's trust anchors. The Delegation Chain certificates on the router to supply the router's public key for
Advertisement (DCA) message is sent in reply to the DCS message. signed Router Advertisements.
If there is no prefix information further up in the certification
path, a host interprets a standard identity certificate as allowing
unconstrained prefix advertisements.
If the other certificates do contain prefix information, a standard
identity certificate is interpreted as allowing those subnet
prefixes.
6.4 Certificate Transport
The Certification Path Solicitation (CPS) message is sent by a host
when it wishes to request a certification path between a router and
one of the host's trust anchors. The Certification Path
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 certificate chain information on other messages. voluminous certification path information on other messages.
The Authorization Delegation Discovery (ADD) process does not exclude The Authorization Delegation Discovery (ADD) process does not exclude
other forms of discovering certificate chains. For instance, during other forms of discovering certification paths. For instance, during
fast movements mobile nodes may learn information - including the fast movements mobile nodes may learn information - including the
certificate chains - of the next router from a previous router, or certification paths - of the next router from a previous router, or
nodes may be preconfigured with certificate chains from roaming nodes may be preconfigured with certification paths from roaming
partners. partners.
Where hosts themselves are certified by a trust anchor, these Where hosts themselves are certified by a trust anchor, these
messages MAY also optionally be used between hosts to acquire the messages MAY also optionally be used between hosts to acquire the
peer's certificate chain. However, the details of such usage are peer's certification path. However, the details of such usage are
beyond the scope of this specification. beyond the scope of this specification.
6.2.1 Delegation Chain Solicitation Message Format 6.4.1 Certification Path Solicitation Message Format
Hosts send Delegation Chain Solicitations in order to prompt routers Hosts send Certification Path Solicitations in order to prompt
to generate Delegation Chain Advertisements. routers to generate Certification Path Advertisements.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved | | Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
Source Address Source Address
A link-local unicast address assigned to the sending interface, A link-local unicast address assigned to the sending interface,
or the unspecified address if no address is assigned to the or the unspecified address if no address is assigned to the
skipping to change at page 29, line 36 skipping to change at page 33, line 36
multicast address, or the address of the host's default router. multicast address, or the address of the host's default router.
Hop Limit Hop Limit
255 255
ICMP Fields: ICMP Fields:
Type Type
TBD <To be assigned by IANA for Delegation Chain Solicitation>. TBD <To be assigned by IANA for Certification Path
Solicitation>.
Code Code
0 0
Checksum Checksum
The ICMP checksum [9]. The ICMP checksum [9].
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 NOT be zero, and its value SHOULD be randomly field MUST NOT be zero, and its value SHOULD be randomly
generated. This randomness does not need to be generated. This randomness does not need to be
cryptographically hard, since its purpose is only to avoid cryptographically hard, since its purpose is only to avoid
collisions. collisions.
Reserved Component
An unused field. It MUST be initialized to zero by the sender This 16-bit unsigned integer field is set to 65,535 if the
and MUST be ignored by the receiver. sender desires to retrieve all certificates. Otherwise, it is
set to the component identifier corresponding to the
certificate that the receiver wants to retrieve (see Section
6.4.2 and Section 6.4.6).
Valid Options: Valid Options:
Trust Anchor Trust Anchor
One or more trust anchors that the client is willing to accept. One or more trust anchors that the client is willing to accept.
The first (or only) Trust Anchor option MUST contain a DER The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.2.3. If there is more than Encoded X.501 Name; see Section 6.4.3. If there is more than
one Trust Anchor option, the options past the first one may one Trust Anchor option, the options past the first one may
contain any type of trust anchor. contain any type of trust anchor.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST and continue processing the message. All included options MUST
have a length that is greater than zero. have a length that is greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets. ICMP length (derived from the IP length) MUST be 8 or more octets.
6.2.2 Delegation Chain Advertisement Message Format 6.4.2 Certification Path Advertisement Message Format
Routers send out Delegation Chain Advertisement messages in response Routers send out Certification Path Advertisement messages in
to a Delegation Chain Solicitation. response to a Certification Path Solicitation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component | | Identifier | All Components |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Component | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
Source Address Source Address
A link-local unicast address assigned to the interface from A link-local unicast address assigned to the interface from
which this message is sent. Note that routers may use multiple which this message is sent. Note that routers may use multiple
skipping to change at page 31, line 20 skipping to change at page 35, line 27
the link-scoped All-Nodes multicast address. the link-scoped All-Nodes multicast address.
Hop Limit Hop Limit
255 255
ICMP Fields: ICMP Fields:
Type Type
TBD <To be assigned by IANA for Delegation Chain TBD <To be assigned by IANA for Certification Path
Advertisement>. Advertisement>.
Code Code
0 0
Checksum Checksum
The ICMP checksum [9]. The ICMP checksum [9].
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.
Component All Components
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, and how many are receiver how many certificates are in the entire path.
still left to be sent in the whole chain.
A single advertisement MUST 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
messages for typical certification paths are listed in Appendix
C.
Component
A 16-bit unsigned integer field, used for informing the
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 MUST 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) certificate chain 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
and continue processing the message. All included options MUST and continue processing the message. All included options MUST
have a length that is greater than zero. have a length that is greater than zero.
ICMP length (derived from the IP length) MUST be 8 or more octets. ICMP length (derived from the IP length) MUST be 8 or more octets.
6.2.3 Trust Anchor Option 6.4.3 Trust Anchor Option
The format of the Trust Anchor option is described in the following: The format of the Trust Anchor option is described in the following:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Name Type | Pad Length | | Type | Length | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... | | Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 41 skipping to change at page 38, line 4
Pad Length Pad Length
The number of padding octets beyond the end of the Name field but The number of padding octets beyond the end of the Name field but
within the length specified by the Length field. Padding octets within the length specified by the Length field. Padding octets
MUST be set to zero by senders and ignored by receivers. MUST be set to zero by senders and ignored by receivers.
Name Name
When the Name Type field is set to 1, the Name field contains a When the Name Type field is set to 1, the Name field contains a
DER encoded X.501 certificate Name, represented and encoded DER encoded X.501 Name identifying the trust anchor. The value is
exactly as in the matching X.509v3 trust anchor certificate. encoded as defined in [15] and [10].
When the Name Type field is set to 2, the Name field contains a When the Name Type field is set to 2, the Name field contains a
Fully Qualified Domain Name of the trust anchor, for example, Fully Qualified Domain Name of the trust anchor, for example,
"trustanchor.example.com". The name is stored as a string, in the "trustanchor.example.com". The name is stored as a string, in the
"preferred name syntax" DNS format, as specified in RFC 1034 [1] DNS wire format, as specified in RFC 1034 [1]. Additionally, the
Section 3.5. Additionally, the restrictions discussed in RFC 3280 restrictions discussed in RFC 3280 [10] Section 4.2.1.7 apply.
[10] Section 4.2.1.7 apply.
In the FQDN case the Name field is an "IDN-unaware domain name In the FQDN case, the Name field is an "IDN-unaware domain name
slot" as defined in [11]. That is, it can contain only ASCII slot" as defined in [12]. That is, it can contain only ASCII
characters. An implementation MAY support internationalized characters. An implementation MAY support internationalized
domain names (IDNs) using the ToASCII operation; see [11] for more domain names (IDNs) using the ToASCII operation; see [12] for more
information. information.
All systems MUST support the DER Encoded X.501 Name. All systems MUST support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type. Implementations MAY support the FQDN name type.
Padding Padding
A variable length field making the option length a multiple of 8, A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field ends, and beginning after the previous field ends, and continuing to the end
continuing to the end of the option, as specified by the Length of the option, as specified by the Length field.
field.
6.2.4 Certificate Option 6.4.4 Certificate Option
The format of the certificate option is described in the following: The format of the certificate option is described in the following:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Cert Type | Reserved | | Type | Length | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ... | Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 15 skipping to change at page 39, line 22
Reserved Reserved
An 8-bit field reserved for future use. The value MUST be An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
Certificate Certificate
When the Cert Type field is set to 1, the Certificate field When the Cert Type field is set to 1, the Certificate field
contains an X.509v3 certificate [10], as described in Section contains an X.509v3 certificate [10], as described in Section
6.1.1. 6.3.1.
Padding Padding
A variable length field making the option length a multiple of 8, A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field ends, and beginning after the ASN.1 encoding of the previous field [10, 15]
continuing to the end of the option, as specified by the Length ends, and continuing to the end of the option, as specified by the
field. Length field.
6.2.5 Processing Rules for Routers
Routers should be configured with a key pair and a certificate from 6.4.5 Processing Rules for Routers
at least one certificate authority.
A router MUST silently discard any received Delegation Chain A router MUST silently discard any received Certification Path
Solicitation messages that do not conform to the message format Solicitation messages that do not conform to the message format
defined in Section 6.2.1. The contents of the Reserved field, and of defined in Section 6.4.1. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future, any unrecognized options, MUST be ignored. Future,
backward-compatible changes to the protocol may specify the contents backward-compatible changes to the protocol may specify the contents
of the Reserved field or add new options; backward-incompatible of the Reserved field or add new options; backward-incompatible
changes may use different Code values. The contents of any defined changes may use different Code values. The contents of any defined
options that are not specified to be used with Router Solicitation options that are not specified to be used with Router Solicitation
messages MUST be ignored and the packet processed in the normal messages MUST be ignored and the packet processed in the normal
manner. The only defined option that may appear is the Trust Anchor manner. The only defined option that may appear is the Trust Anchor
option. A solicitation that passes the validity checks is called a option. A solicitation that passes the validity checks is called a
"valid solicitation". "valid solicitation".
Routers SHOULD send advertisements in response to valid solicitations Routers SHOULD send advertisements in response to valid solicitations
received on an advertising interface. If the source address in the received on an advertising interface. If the source address in the
solicitation was the unspecified address, the router MUST send the solicitation was the unspecified address, the router MUST send the
response to the link-scoped All-Nodes multicast address. If the response to the link-scoped All-Nodes multicast address. If the
source address was a unicast address, the router MUST send the source address was a unicast address, the router MUST send the
response to the Solicited-Node multicast address corresponding to the response to the Solicited-Node multicast address corresponding to the
source address, except when under load, as specified below. Routers source address, except when under load, as specified below. Routers
SHOULD NOT send Delegation Chain Advertisements more than SHOULD NOT send Certification Path Advertisements more than
MAX_DCA_RATE times within a second. When there are more MAX_CPA_RATE times within a second. When there are more
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 delegation chain to the solicited trust anchor can options so that a certification path to the solicited trust anchor
be established. The anchor is identified by the Trust Anchor option. can be established (or a part of it, if the Component field in the
If the Trust Anchor option is represented as a DER Encoded X.501 solicitation is not equal to 65,535). Note also that a single
Name, then the Name must be equal to the Subject field in the advertisement is broken into separately sent components and ordered
anchor's certificate. If the Trust Anchor option is represented as in a particular way (see Section 6.4.2) when there is more than one
an FQDN, the FQDN must be equal to an FQDN in the subjectAltName certificate in the path.
field of the anchor's certificate. The router SHOULD include the
Trust Anchor option(s) in the advertisement for which the delegation
chain was found.
If the router is unable to find a chain to the requested anchor, it 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
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
be equal to an FQDN in the subjectAltName field of the anchor's
certificate. The router SHOULD include the Trust Anchor option(s) in
the advertisement for which the certification path was found.
If the router is unable to find a path to the requested anchor, it
SHOULD send an advertisement without any certificates. In this case SHOULD send an advertisement without any certificates. In this case
the router SHOULD include the Trust Anchor options which were the router SHOULD include the Trust Anchor options which were
solicited. solicited.
6.2.6 Processing Rules for Hosts 6.4.6 Processing Rules for Hosts
Hosts SHOULD possess the public key and trust anchor name of at least
one certificate authority, they SHOULD possess their own key pair,
and they MAY possess certificates from certificate authorities.
A host MUST silently discard any received Delegation Chain A host MUST silently discard any received Certification Path
Advertisement messages that do not conform to the message format Advertisement messages that do not conform to the message format
defined in Section 6.2.2. The contents of the Reserved field, and of defined in Section 6.4.2. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future, any unrecognized options, MUST be ignored. Future,
backward-compatible changes to the protocol MAY specify the contents backward-compatible changes to the protocol MAY specify the contents
of the Reserved field or add new options; backward-incompatible of the Reserved field or add new options; backward-incompatible
changes MUST use different Code values. The contents of any defined changes MUST use different Code values. The contents of any defined
options that are not specified to be used with Delegation Chain options that are not specified to be used with Certification Path
Advertisement messages MUST be ignored and the packet processed in Advertisement messages MUST be ignored and the packet processed in
the normal manner. The only defined options that may appear are the the normal manner. The only defined options that may appear are the
Certificate and Trust Anchor options. An advertisement that passes Certificate and Trust Anchor options. An advertisement that passes
the validity checks is called a "valid advertisement". the validity checks is called a "valid advertisement".
Hosts SHOULD store certificate chains retrieved in Delegation Chain Hosts SHOULD store certification paths retrieved in Certification
Discovery messages if they start from an anchor trusted by the host. Path Discovery messages if they start from an anchor trusted by the
The certificate chains MUST be verified, as defined in Section 6.1, host. The certification paths MUST be verified, as defined in Section
before storing them. Routers MUST send the certificates one by one, 6.3, before storing them. Routers send the certificates one by one,
starting from the trust anchor end of the chain. Except for temporary starting from the trust anchor end of the path.
purposes to allow for message loss and reordering, hosts SHOULD NOT
store certificates received in a Delegation Chain Advertisement Note: except for temporary purposes to allow for message loss and
unless they contain a certificate which can be immediately verified reordering, hosts might not store certificates received in a
either to the trust anchor or to a certificate that has been verified Certification Path Advertisement unless they contain a certificate
earlier. which can be immediately verified either to the trust anchor or to a
certificate that has been verified earlier. This measure is to
prevent Denial-of-Service attacks, whereby an attacker floods a host
with certificates that the host cannot validate and overwhelms memory
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 delegation chain 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 authorization available from a certificate in the hosts' cache of certificates, or
delegation chain to the host's trust anchor. In these situations, the there is no certification path to the one of the host's trust
host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain anchors. In these situations, the host MAY send a Certification Path
Solicitation messages, each separated by at least DCS_INTERVAL Solicitation message to retrieve the path. If there is no response
seconds. within CPS_RETRY seconds, the message should be retried. The wait
interval for each subsequent retransmission MUST exponentially
increase, doubling each time. If there is no response after
CPS_RETRY_MAX seconds, the host abandons the certification path
retrieval process. If the host receives only a part of a
certification path within CPS_RETRY_FRAGMENTS seconds of receiving
the first part, it MAY in addition transmit a Certification Path
Solicitation message with the Component field set to a value not
equal to 65,535. This message can be retransmitted using the same
process as in the initial message. If there are multiple missing
certificates, additional such CPS messages can be sent after getting
a response to first one. However, the complete retrieval process may
last at most CPS_RETRY_MAX seconds.
Delegation Chain Solicitations SHOULD NOT be sent if the host has a Certification Path Solicitations SHOULD NOT be sent if the host has a
currently valid certificate chain 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
Delegation Chain 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.
If two hosts want to establish trust with the DCS and DCA messages, If two hosts want to establish trust with the CPS and CPA messages,
the DCS message SHOULD be sent to the Solicited-Node multicast the CPS message SHOULD be sent to the Solicited-Node multicast
address of the receiver. The advertisements SHOULD be sent as address of the receiver. The advertisements SHOULD be sent as
specified above for routers. However, the exact details are outside specified above for routers. However, the exact details are outside
the scope of this specification. the scope of this specification.
When processing possible advertisements sent as responses to a When processing possible advertisements sent as responses to a
solicitation, the host MAY prefer to process first those solicitation, the host MAY prefer to process first those
advertisements with the same Identifier field value as in the advertisements with the same Identifier field value as in the
solicitation. This makes Denial-of-Service attacks against the solicitation. This makes Denial-of-Service attacks against the
mechanism harder (see Section 9.3). mechanism harder (see Section 9.3).
6.5 Configuration
End hosts are configured with a set of trust anchors for the purposes
of protecting Router Discovery. A trust anchor configuration consists
of the following items:
o A public key signature algorithm and associated public key, which
may optionally include parameters.
o A name as described in Section 6.4.3.
o An optional public key identifier.
o An optional list of address ranges for which the trust anchor is
authorized.
If the host has been configured to use SEND, it SHOULD possess the
above information for at least one trust anchor.
Routers are configured with a collection of certification paths and a
collection of certified keys and the certificates containing them,
down to the key and certificate for the router itself. Certified keys
are required for routers in order that a certification path can be
established between the router's certificate and the public key of a
trust anchor.
If the router has been configured to use SEND, it should be
configured with its own key pair and certificate, and at least one
certification path.
7. Addressing 7. Addressing
7.1 CGAs 7.1 CGAs
Nodes that use stateless address autoconfiguration SHOULD generate a
new CGA and a CGA Parameters data structure as specified in Section 4
of [13] each time they run the autoconfiguration procedure.
By default, a SEND-enabled node SHOULD use only CGAs for its own By default, a SEND-enabled node SHOULD use only CGAs for its own
addresses. Other types of addresses MAY be used in testing, addresses. Other types of addresses MAY be used in testing,
diagnostics or for other purposes. However, this document does not diagnostics or for other purposes. However, this document does not
describe how to choose between different types of addresses for describe how to choose between different types of addresses for
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 [23]. 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 silently discarded. 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 is not its default router. This prevents message from a router that the host is not using to reach the
an attacker from tricking a node into redirecting traffic when the destination mentioned in the redirect. This prevents an attacker from
attacker is not the default router. tricking a node into redirecting traffic when the attacker is not the
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 certificate chain-based authorization specifications are Future certification path-based authorization specifications are
needed for such nodes. needed for such nodes. This specification also does not apply to
addresses generated by the IPv6 stateless address autoconfiguration
using other fixed forms of interface identifiers (such as EUI-64) as
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 [18] 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 certificate chains 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.
SEND nodes MUST send only secured messages. Plain (non-SEND) A SEND node SHOULD have a configuration option that causes it to
Neighbor Discovery nodes will obviously send only insecure messages. ignore all unsecured Neighbor Solicitation and Advertisement, Router
Per RFC 2461 [7], such nodes will ignore the unknown options and will Solicitation and Advertisement, and Redirect messages. This can be
treat secured messages in the same way as they treat insecure ones. used to enforce SEND-only networks. The default for this
Secured and insecure nodes share the same network resources, such as configuration option SHOULD be that both secured and unsecured
prefixes and address spaces. messages are allowed.
In a mixed environment SEND nodes follow the protocols defined in RFC A SEND node MAY also have a configuration option that causes it to
2461 and RFC 2462 with the following exceptions: disable the use of SEND completely, even for the messages it sends
itself. The default for this configuration option SHOULD be off; that
is, that SEND is used. Plain (non-SEND) NDP nodes will obviously send
only unsecured messages. Per RFC 2461 [7], such nodes will ignore
the unknown options and will treat secured messages in the same way
as they treat unsecured ones. Secured and unsecured nodes share the
same network resources, such as subnet prefixes and address spaces.
SEND nodes configured to use SEND at least in their own messages
behave in a mixed environment as is explained below.
SEND adheres to the rules defined for the base NDP protocol with the
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. unsecured Neighbor Advertisements and Solicitations. (The security
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 issecured. 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 Neighbor Solicitations for the purpose of Neighbor Unreachabilty
Detection (NUD) MUST be sent to that neighbor's solicited-nodes
multicast address, if the entry is not secured with SEND.
Upper layer confirmations on unsecured neighbor cache entries
SHOULD NOT update neighbor cache state from STALE to REACHABLE on
a SEND node, if the neighbour cache entry has never previously
been REACHABLE. This ensures that if an entry spoofing a valid
SEND host is created by a non-SEND attacker without being
solicited, NUD will be done within 5 seconds of use of the entry
for data transmission.
As a result, in mixed mode attackers can take over a Neighbor
Cache entry of a SEND node for a longer time only if (a) the SEND
node was not communicating with the victim node so that there is
no secure entry for it and (b) the SEND node is not currently on
the link (or is unable to respond).
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 delegation chain 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
o A SEND node SHOULD have a configuration option that causes it to known to be secure as soon as one is available with completed
ignore all insecure Neighbor Solicitation and Advertisement, security checks.
Router Solicitation and Advertisement, and Redirect messages. This
can be used to enforce SEND-only networks.
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
[17]. 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
Multicast-Address-Specific Query to determine whether any listeners Multicast-Address-Specific Query to determine whether any listeners
are still on the address, at which point the victim can respond to are still on the address, at which point the victim can respond to
avoid being dropped from the group. This technique will work if the avoid being dropped from the group. This technique will work if the
router on the link has not been compromised. Other attacks using MLD router on the link has not been compromised. Other attacks using MLD
are possible, but they primarily lead to extraneous (but not are possible, but they primarily lead to extraneous (but not
overwhelming) traffic. overwhelming) traffic.
9.2 How SEND Counters Threats to NDP 9.2 How SEND Counters Threats to NDP
The SEND protocol is designed to counter the threats to NDP, as The SEND protocol is designed to counter the threats to NDP, as
outlined in [24]. The following subsections contain a regression of outlined in [25]. The following subsections contain a regression of
the SEND protocol against the threats, to illustrate what aspects of the SEND protocol against the threats, to illustrate what aspects of
the protocol counter each threat. the protocol counter each threat.
9.2.1 Neighbor Solicitation/Advertisement Spoofing 9.2.1 Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [24]. The threat is that This threat is defined in Section 4.1.1 of [25]. The threat is that
a spoofed message may cause a false entry in a node's Neighbor Cache. a spoofed message may cause a false entry in a node's Neighbor Cache.
There are two cases: There are two cases:
1. Entries made as a side effect of a Neighbor Solicitation or 1. Entries made as a side effect of a Neighbor Solicitation or
Router Solicitation. A router receiving a Router Solicitation Router Solicitation. A router receiving a Router Solicitation
with a Target Link-Layer Address extension and the IPv6 source with a Target Link-Layer Address extension and the IPv6 source
address not equal to the unspecified address inserts an entry for address not equal to the unspecified address inserts an entry for
the IPv6 address into its Neighbor Cache. Also, a node performing the IPv6 address into its Neighbor Cache. Also, a node performing
Duplicate Address Detection (DAD) that receives a Neighbor Duplicate Address Detection (DAD) that receives a Neighbor
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 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 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
This attack is described in Section 4.1.2 of [24]. SEND counters This attack is described in Section 4.1.2 of [25]. SEND counters
this attack by requiring a node responding to Neighbor Solicitations this attack by requiring a node responding to Neighbor Solicitations
sent as NUD probes to include a Signature option and proof of sent as NUD probes to include 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
probed. If these prerequisites are not met, the node performing NUD probed. If these prerequisites are not met, the node performing NUD
discards the responses. discards the responses.
9.2.3 Duplicate Address Detection DoS Attack 9.2.3 Duplicate Address Detection DoS Attack
This attack is described in Section 4.1.3 of [24]. 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 a 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 [13]. 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 [24]. SEND counters these attacks by requiring Router and 4.2.7 of [25]. SEND counters these attacks by requiring Router
Advertisements to contain a Signature option, and that the signature Advertisements to contain an RSA Signature option, and that the
is calculated using the public key of a node that can prove its signature is calculated using the public key of a node that can prove
authorization to route the subnet prefixes contained in any Prefix its authorization to route the subnet subnet prefixes contained in
Information Options. The router proves its authorization by showing any Prefix Information Options. The router proves its authorization
a certificate containing the specific prefix or the indication that by showing a certificate containing the specific prefix or the
the router is allowed to route any prefix. A Router Advertisement indication that the router is allowed to route any prefix. A Router
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 [24]. 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 [24]. SEND protects This attack is described in Section 4.3.1 of [25]. SEND protects
against attacks in Router Solicitation/Router Advertisement and against attacks in Router Solicitation/Router Advertisement and
Neighbor Solicitation/Neighbor Advertisement transactions by Neighbor Solicitation/Neighbor Advertisement transactions by
including a Nonce option in the solicitation and requiring the including a Nonce option in the solicitation and requiring the
advertisement to include a matching option. Together with the advertisement to include a matching option. Together with the
signatures this forms a challenge-response protocol. SEND protects signatures this forms a challenge-response protocol.
against attacks from unsolicited messages such as Neighbor
Advertisements, Router Advertisements, and Redirects by including a
Timestamp option. A window of vulnerability for replay attacks
exists until the timestamp expires.
When timestamps are used, SEND nodes are protected against replay SEND protects against attacks from unsolicited messages such as
attacks as long as they cache the state created by the message Neighbor Advertisements, Router Advertisements, and Redirects by
containing the timestamp. The cached state allows the node to including a Timestamp option. The following security issues are
protect itself against replayed messages. However, once the node relevant only for unsolicited messages:
flushes the state for whatever reason, an attacker can re-create the
state by replaying an old message while the timestamp is still valid. o A window of vulnerability for replay attacks exists until the
Since most SEND nodes are likely to use fairly coarse grained timestamp expires.
timestamps, as explained in Section 5.3.1, this may affect some
nodes. However, such vulnerabilities are only useful for attackers if the
advertised parameters change during the window. While some
parameters (such as the remaining lifetime of a prefix) change
often, radical changes typically happen only in the context of
some special case, such as switching to a new link layer address
due to a broken interface adapter.
SEND nodes are also protected against replay attacks as long as
they cache the state created by the message containing the
timestamp. The cached state allows the node to protect itself
against replayed messages. However, once the node flushes the
state for whatever reason, an attacker can re-create the state by
replaying an old message while the timestamp is still valid.
Since most SEND nodes are likely to use fairly coarse grained
timestamps, as explained in Section 5.3.1, this may affect some
nodes.
o Attacks against time synchronization protocols such as NTP [26]
may cause SEND nodes to have an incorrect timestamp value. This
can be used to launch replay attacks even outside the normal
window of vulnerability. To protect against such attacks, it is
recommended that SEND nodes keep independently maintained clocks,
or apply suitable security measures for the time synchronization
protocols.
9.2.6 Neighbor Discovery DoS Attack 9.2.6 Neighbor Discovery DoS Attack
This attack is described in Section 4.3.2 of [24]. In this attack, This attack is described in Section 4.3.2 of [25]. In this attack,
the attacker bombards the router with packets for fictitious the attacker bombards the router with packets for fictitious
addresses on the link, causing the router to busy itself with addresses on the link, causing the router to busy itself with
performing Neighbor Solicitations for addresses that do not exist. performing Neighbor Solicitations for addresses that do not exist.
SEND does not address this threat because it can be addressed by SEND does not address this threat because it can be addressed by
techniques such as rate limiting Neighbor Solicitations, restricting techniques such as rate limiting Neighbor Solicitations, restricting
the amount of state reserved for unresolved solicitations, and clever the amount of state reserved for unresolved solicitations, and clever
cache management. These are all techniques involved in implementing cache management. These are all techniques involved in implementing
Neighbor Discovery on the router. Neighbor Discovery on the router.
9.3 Attacks against SEND Itself 9.3 Attacks against SEND Itself
The CGAs have a 59-bit hash value. The security of the CGA mechanism The CGAs have a 59-bit hash value. The security of the CGA mechanism
has been discussed in [13]. has been discussed in [14].
Some Denial-of-Service attacks against NDP and SEND itself remain. Some Denial-of-Service attacks against NDP and SEND itself remain.
For instance, an attacker may try to produce a very high number of For instance, an attacker may try to produce a very high number of
packets that a victim host or router has to verify using asymmetric packets that a victim host or router has to verify using asymmetric
methods. While safeguards are required to prevent an excessive use methods. While safeguards are required to prevent an excessive use
of resources, this can still render SEND non-operational. of resources, this can still render SEND non-operational.
When CGA protection is used, SEND deals with the DoS attacks using When CGA protection is used, SEND deals with the DoS attacks using
the verification process described in Section 5.2.2. In this process, the verification process described in Section 5.2.2. In this process,
a simple hash verification of the CGA property of the address is a simple hash verification of the CGA property of the address is
performed before performing the more expensive signature performed before performing the more expensive signature
verification. However, even if the CGA verification succeeds, no verification. However, even if the CGA verification succeeds, no
claims about the validity of the message can be made, until the claims about the validity of the message can be made, until the
signature has been checked. signature has been checked.
When trust anchors and certificates are used for address validation When trust anchors and certificates are used for address validation
in SEND, the defenses are not quite as effective. Implementations in SEND, the defenses are not quite as effective. Implementations
SHOULD track the resources devoted to the processing of packets SHOULD track the resources devoted to the processing of packets
received with the Signature option, and start selectively discarding received with the RSA Signature option, and start selectively
packets if too many resources are spent. Implementations MAY also discarding packets if too many resources are spent. Implementations
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 delegation chains 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 certificate chains, forcing hosts to spend useless memory unnecessary certification paths, forcing hosts to spend useless
and verification resources for them. Hosts can defend against such memory and verification resources for them. Hosts can defend against
attacks by limiting the amount of resources devoted to the such attacks by limiting the amount of resources devoted to the
certificate chains 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 Constants 10. Protocol Values
10.1 Constants
Host constants: Host constants:
MAX_DCS_MESSAGES 3 transmissions CPS_RETRY 1 second
DCS_INTERVAL 4 seconds CPS_RETRY_FRAGMENTS 2 seconds
CPS_RETRY_MAX 15 seconds
Router constants: Router constants:
MAX_DCA_RATE 10 times per second MAX_CPA_RATE 10 times per second
11. Protocol Variables 10.2 Variables
TIMESTAMP_DELTA 3,600 seconds (1 hour) TIMESTAMP_DELTA 300 seconds (5 minutes)
TIMESTAMP_FUZZ 1 second TIMESTAMP_FUZZ 1 second
TIMESTAMP_DRIFT 1 % (0.01) TIMESTAMP_DRIFT 1 % (0.01)
12. IANA Considerations 11. IANA Considerations
This document defines two new ICMP message types, used in This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range: ICMPv6 type numbers from the informational message range:
o The Delegation Chain Solicitation message, described in Section o The Certification Path Solicitation message, described in Section
6.2.1. 6.4.1.
o The Delegation Chain Advertisement message, described in Section o The Certification Path Advertisement message, described in Section
6.2.2. 6.4.2.
This document defines six new Neighbor Discovery Protocol [7] This document defines six new Neighbor Discovery Protocol [7]
options, which must be assigned Option Type values within the option options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery Protocol messages: numbering space for Neighbor Discovery Protocol messages:
o The CGA option, described in Section 5.1. o The CGA option, described in Section 5.1.
o The Signature option, described in Section 5.2. o The RSA Signature option, described in Section 5.2.
o The Timestamp option, described in Section 5.3.1. o The Timestamp option, described in Section 5.3.1.
o The Nonce option, described in Section 5.3.2. o The Nonce option, described in Section 5.3.2.
o The Trust Anchor option, described in Section 6.2.3. o The Trust Anchor option, described in Section 6.4.3.
o The Certificate option, described in Section 6.2.4. o The Certificate option, described in Section 6.4.4.
This document defines a new 128-bit value under the CGA Message Type This document defines a new 128-bit value under the CGA Message Type
[13] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. [14] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
This document defines a new name space for the Name Type field in the This document defines a new name space for the Name Type field in the
Trust Anchor option. Future values of this field can be allocated Trust Anchor option. Future values of this field can be allocated
using Standards Action [6]. The current values for this field are: using Standards Action [6]. The current values for this field are:
1 DER Encoded X.501 Name 1 DER Encoded X.501 Name
2 FQDN 2 FQDN
Another new name space is allocated for the Cert Type field in the Another new name space is allocated for the Cert Type field in the
skipping to change at page 50, line 40 skipping to change at page 56, line 40
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[9] Conta, A. and S. Deering, "Internet Control Message Protocol [9] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
[10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 [10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002. Revocation List (CRL) Profile", RFC 3280, April 2002.
[11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing [11] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.
[12] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003. Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[12] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP [13] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", Addresses and AS Identifiers",
draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in progress), draft-ietf-pkix-x509-ipaddr-as-extn-03 (work in progress),
September 2003. September 2003.
[13] Aura, T., "Cryptographically Generated Addresses (CGA)", [14] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-03 (work in progress), December 2003. draft-ietf-send-cga-06 (work in progress), April 2004.
[14] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS [15] International Telecommunications Union, "Information Technology
- ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
[16] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002. 1, November 2002.
[15] National Institute of Standards and Technology, "Secure Hash [17] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http:// Standard", FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>. www.itl.nist.gov/fipspubs/fip180-1.htm>.
Informative References Informative References
[16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [18] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[17] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener [19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999. Discovery (MLD) for IPv6", RFC 2710, October 1999.
[18] Narten, T. and R. Draves, "Privacy Extensions for Stateless [20] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[19] Farrell, S. and R. Housley, "An Internet Attribute Certificate [21] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Profile for Authorization", RFC 3281, April 2002.
[20] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[21] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", [22] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
draft-arkko-icmpv6-ike-effects-02 (work in progress), March draft-arkko-icmpv6-ike-effects-02 (work in progress), March
2003. 2003.
[22] Arkko, J., "Manual SA Configuration for IPv6 Link Local [23] Arkko, J., "Manual SA Configuration for IPv6 Link Local
Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress), Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
June 2002. June 2002.
[23] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API [24] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
for Address Selection", draft-chakrabarti-ipv6-addrselect-02 for Address Selection", draft-chakrabarti-ipv6-addrselect-02
(work in progress), October 2003. (work in progress), October 2003.
[24] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor [25] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery trust models and threats", draft-ietf-send-psreq-04 Discovery trust models and threats", draft-ietf-send-psreq-04
(work in progress), October 2003. (work in progress), October 2003.
[26] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth
Annual Computer Security Conference Proceedings, December 1990.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: jari.arkko@ericsson.com EMail: jari.arkko@ericsson.com
James Kempf James Kempf
skipping to change at page 54, line 5 skipping to change at page 60, line 5
EMail: bzill@microsoft.com EMail: bzill@microsoft.com
Pekka Nikander Pekka Nikander
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Pekka.Nikander@nomadiclab.com EMail: Pekka.Nikander@nomadiclab.com
Appendix A. Contributors Appendix A. Contributors and Acknowledgments
Tuomas Aura contributed the transition mechanism specification in Tuomas Aura contributed the transition mechanism specification in
Section 8. Jonathan Trostle contributed the certificate chain example Section 8. Jonathan Trostle contributed the certification path
in Section 6.1.1. example in Section 6.3.1.
Appendix B. Acknowledgments
The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel The authors would also like to thank Tuomas Aura, Erik Nordmark,
Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier, Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien
Francis Dupont, and Pekka Savola for interesting discussions in this Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri Niemi,
problem space and feedback regarding the SEND protocol. Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for
interesting discussions in this problem space and feedback regarding
the SEND protocol.
Appendix C. Cache Management Appendix B. Cache Management
In this section we outline a cache management algorithm that allows a In this section we outline a cache management algorithm that allows a
node to remain partially functional even under a cache filling DoS node to remain partially functional even under a cache filling DoS
attack. This appendix is informational, and real implementations attack. This appendix is informational, and real implementations
SHOULD use different algorithms in order to avoid he dangers of SHOULD use different algorithms in order to avoid the dangers of
mono-cultural code. mono-cultural code.
There are at least two distinct cache related attack scenarios: There are at least two distinct cache related attack scenarios:
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 clearly make sure that cache filling attack. The goal here is to make sure that the
the nodes can continue to communicate even if the attack is going nodes can continue to communicate even if the attack is going on.
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
discriminative against those nodes that have a large clock out entries. Reducing the timestamp Delta value is very
difference, while an attacker can reduce its clock difference into discriminatory against those nodes that have a large clock
arbitrarily small. Throwing out old entries just because their clock difference, since an attacker can reduce its clock difference
difference is large seems like a bad approach. arbitrarily. Throwing out old entries just because their clock
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
In one example scenario using SEND, an Authorization Delegation
Discovery test run was made using a certification path length of
four. Three certificates are sent using Certification Path
Advertisement messages, since the trust anchor's certificate is
already known by both parties. With a key length of 1024 bits, the
certificate lengths in the test run ranged from 864 to 888 bytes; the
variation is due to the differences in the certificate issuer names
and address prefix extensions. The different certificates had between
one to four address prefix extensions.
The three Certification Path Advertisement messages ranged from 1050
to 1066 bytes on an Ethernet link layer. The certificate itself
accounts for the bulk of the packet. The rest is the trust anchor
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
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
 End of changes. 259 change blocks. 
606 lines changed or deleted 916 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/