draft-ietf-send-ndopt-03.txt   draft-ietf-send-ndopt-04.txt 
Secure Neighbor Discovery Working J. Arkko Secure Neighbor Discovery Working J. Arkko, Editor
Group Ericsson Group Ericsson
Internet-Draft J. Kempf Internet-Draft J. Kempf
Expires: July 24, 2004 DoCoMo Communications Labs USA Expires: August 16, 2004 DoCoMo Communications Labs USA
B. Sommerfeld B. Sommerfeld
Sun Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
P. Nikander P. Nikander
Ericsson Ericsson
January 24, 2004 February 16, 2004
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-03 draft-ietf-send-ndopt-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 24, 2004. This Internet-Draft will expire on August 16, 2004.
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 each the link-layer addresses other nodes on the link, to determine the link-layer addresses of
of the 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 to 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 . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11
5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11
5.1.1 Processing Rules for Senders . . . . . . . . . 12 5.1.1 Processing Rules for Senders . . . . . . . . . 12
5.1.2 Processing Rules for Receivers . . . . . . . . 13 5.1.2 Processing Rules for Receivers . . . . . . . . 13
5.1.3 Configuration . . . . . . . . . . . . . . . . 14 5.1.3 Configuration . . . . . . . . . . . . . . . . 14
5.2 Signature Option . . . . . . . . . . . . . . . . . . .14 5.2 Signature Option . . . . . . . . . . . . . . . . . . .15
5.2.1 Processing Rules for Senders . . . . . . . . . 16 5.2.1 Processing Rules for Senders . . . . . . . . . 17
5.2.2 Processing Rules for Receivers . . . . . . . . 17 5.2.2 Processing Rules for Receivers . . . . . . . . 17
5.2.3 Configuration . . . . . . . . . . . . . . . . 18 5.2.3 Configuration . . . . . . . . . . . . . . . . 18
5.2.4 Performance Considerations . . . . . . . . . . 19 5.2.4 Performance Considerations . . . . . . . . . . 19
5.3 Timestamp and Nonce options . . . . . . . . . . . . .19 5.3 Timestamp and Nonce options . . . . . . . . . . . . .20
5.3.1 Timestamp Option . . . . . . . . . . . . . . . 19 5.3.1 Timestamp Option . . . . . . . . . . . . . . . 20
5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 20 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 21
5.3.3 Processing rules for senders . . . . . . . . . 21 5.3.3 Processing rules for senders . . . . . . . . . 21
5.3.4 Processing rules for receivers . . . . . . . . 21 5.3.4 Processing rules for receivers . . . . . . . . 22
6. Authorization Delegation Discovery . . . . . . . . . . . . . 24 6. Authorization Delegation Discovery . . . . . . . . . . . . . 25
6.1 Certificate Format . . . . . . . . . . . . . . . . . .24 6.1 Certificate Format . . . . . . . . . . . . . . . . . .25
6.1.1 Router Authorization Certificate Profile . . . 24 6.1.1 Router Authorization Certificate Profile . . . 25
6.2 Certificate Transport . . . . . . . . . . . . . . . .27 6.2 Certificate Transport . . . . . . . . . . . . . . . .28
6.2.1 Delegation Chain Solicitation Message Format . 27 6.2.1 Delegation Chain Solicitation Message Format . 28
6.2.2 Delegation Chain Advertisement Message Format 29 6.2.2 Delegation Chain Advertisement Message Format 30
6.2.3 Trust Anchor Option . . . . . . . . . . . . . 31 6.2.3 Trust Anchor Option . . . . . . . . . . . . . 32
6.2.4 Certificate Option . . . . . . . . . . . . . . 32 6.2.4 Certificate Option . . . . . . . . . . . . . . 34
6.2.5 Processing Rules for Routers . . . . . . . . . 33 6.2.5 Processing Rules for Routers . . . . . . . . . 35
6.2.6 Processing Rules for Hosts . . . . . . . . . . 34 6.2.6 Processing Rules for Hosts . . . . . . . . . . 36
7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 37 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .37 7.1 CGAs . . . . . . . . . . . . . . . . . . . . . . . . .38
7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .37 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .38
7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .37 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .38
7.4 Limitations . . . . . . . . . . . . . . . . . . . . .38 7.4 Limitations . . . . . . . . . . . . . . . . . . . . .39
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 39 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . 43
9.1 Threats to the Local Link Not Covered by SEND . . . .41 9.1 Threats to the Local Link Not Covered by SEND . . . .43
9.2 How SEND Counters Threats to NDP . . . . . . . . . . .41 9.2 How SEND Counters Threats to NDP . . . . . . . . . . .43
9.2.1 Neighbor Solicitation/Advertisement Spoofing . 42 9.2.1 Neighbor Solicitation/Advertisement Spoofing . 44
9.2.2 Neighbor Unreachability Detection Failure . . 42 9.2.2 Neighbor Unreachability Detection Failure . . 44
9.2.3 Duplicate Address Detection DoS Attack . . . . 42 9.2.3 Duplicate Address Detection DoS Attack . . . . 44
9.2.4 Router Solicitation and Advertisement Attacks 43 9.2.4 Router Solicitation and Advertisement Attacks 45
9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 43 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 45
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 44 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 46
9.3 Attacks against SEND Itself . . . . . . . . . . . . .44 9.3 Attacks against SEND Itself . . . . . . . . . . . . .46
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 46 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 48
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 47 11. Protocol Variables . . . . . . . . . . . . . . . . . . . . . 49
Normative References . . . . . . . . . . . . . . . . . . . . 48 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50
Informative References . . . . . . . . . . . . . . . . . . . 50 Normative References . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51 Informative References . . . . . . . . . . . . . . . . . . . 53
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 53 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55
C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 54 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . 55 C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 57
Intellectual Property and Copyright Statements . . . . . . . 58
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.
Original NDP specifications called for the use of IPsec for The original NDP specifications called for the use of IPsec to
protecting the NDP messages. However, the RFCs do not give detailed protect NDP messages. However, the RFCs do not give detailed
instructions for using IPsec to secure NDP. It turns out that in instructions for using IPsec for this. In this particular
this particular application, IPsec can only be used with a manual application, IPsec can only be used with a manual configuration of
configuration of security associations, due to chicken-and-egg security associations, due to bootstrapping problems in using IKE
problems in using IKE [20, 15]. Furthermore, the number of such [21, 16]. Furthermore, the number of such manually configured
manually configured security associations needed for protecting NDP security associations needed for protecting NDP can be very large
can be very large [21], making that approach impractical for most [22], making that approach impractical for most purposes.
purposes.
This document is organized as follows. Section 4 describes the This document is organized as follows. Section 2 and Section 3
overall approach to securing NDP. This approach involves the use of define some terminology and present a brief review of NDP,
new NDP options to carry public-key based signatures. A respectively. Section 4 describes the overall approach to securing
zero-configuration mechanism is used for showing address ownership on NDP. This approach involves the use of new NDP options to carry
individual nodes; routers are certified by a trust anchor [10]. The public-key based signatures. A zero-configuration mechanism is used
formats, procedures, and cryptographic mechanisms for the for showing address ownership on individual nodes; routers are
zero-configuration mechanism are described in a related specification certified by a trust anchor [10]. The formats, procedures, and
[12]. cryptographic mechanisms for the zero-configuration mechanism are
described in a related specification [13].
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 certificate chains to
establish an authorization delegation chain to a common trust anchor. establish an authorization delegation chain to a common trust anchor.
Finally, Section 8 discusses the co-existence of secure and Finally, Section 8 discusses the co-existence of secure and
non-secure NDP on the same link and Section 9 discusses security non-secure NDP on the same link and Section 9 discusses security
considerations for Secure Neighbor Discovery. considerations for Secure Neighbor Discovery (SEND).
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 certificate chain
from a peer node to a trust anchor. from a peer node to a trust anchor.
Cryptographically Generated Address (CGA) Cryptographically Generated Address (CGA)
A technique [12] where the IPv6 address of a node is A technique [13] 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.
Duplicate Address Detection (DAD) Duplicate Address Detection (DAD)
A mechanism that 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 addresses. not using the same address.
Internet Control Message Protocol version 6 (ICMPv6)
The IPv6 control signaling protocol. Neighbor Discovery Protocol
is a part of ICMPv6.
Neighbor Discovery Protocol (NDP) Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [7, 8]. The IPv6 Neighbor Discovery Protocol [7, 8].
Neighbor Discovery Protocol is a part of ICMPv6 [9].
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 but ND. (NDP). NDP contains also other functions besides ND.
Neighbor Unreachability Detection (NUD) Neighbor Unreachability Detection (NUD)
This mechanism is used for tracking the reachability of neighbors. A mechanism used for tracking the reachability of neighbors.
Nonce Nonce
A random number generated by a node and used exactly once. In An unpredictable random or pseudorandom number generated by a node
SEND, nonces are used to ensure that a particular advertisement is and used exactly once. In SEND, nonces are used to assure that a
linked to the solicitation that triggered it. particular advertisement is linked to the solicitation that
triggered it.
Router Authorization Certificate Router Authorization Certificate
An X.509v3 [10] PKC certificate using the profile specified in An X.509v3 [10] public key certificate using the profile specified
Section 6.1.1. in Section 6.1.1.
SEND node SEND node
An IPv6 node that implements this specification. An IPv6 node that implements this specification.
non-SEND node Non-SEND node
An IPv6 node that does not implement this specification but uses An IPv6 node that does not implement this specification but uses
the legacy RFC 2461 and RFC 2462 mechanisms. only RFC 2461 and RFC 2462 without security.
Router Discovery (RD) Router Discovery (RD)
The Router Discovery function of the Neighbor Discovery Protocol. Router Discovery allows the hosts to discover what routers exist
on the link, and what prefixes are available. Router Discovery is
a part of the Neighbor Discovery Protocol.
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 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. Prefix discovery involves
determining which destinations are directly on a link; this determining which destinations are directly on a link; this
information is necessary in order to know whether a packet should information is necessary in order to know whether a packet should
be sent to a router or to the destination node directly. 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,
the hosts use any prefix information delivered to them during hosts use any prefix information delivered to them during Router
Router Discovery, and then test the newly formed addresses for Discovery, and then test the newly formed addresses for
uniqueness. A stateful mechanism, DHCPv6 [23], provides uniqueness. A stateful mechanism, DHCPv6 [20], provides
additional autoconfiguration features. additional 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
communications for the node in question. communications for the node in question.
o The Address Resolution function resolves a node's IPv6 address to o The Address Resolution function allows a node on the link to
the corresponding link-layer address for nodes on the link. resolve another node's IPv6 address to the corresponding
Address Resolution is defined in Section 7.2 of RFC 2461 [7], and link-layer address. Address Resolution is defined in Section 7.2
it is used for hosts and routers alike. Again, no higher level of RFC 2461 [7], and it is used for hosts and routers alike.
traffic can proceed until the sender knows the hardware address of Again, no higher level traffic can proceed until the sender knows
the destination node or the next hop router. Note the source link the link layer address of the destination node or the next hop
layer address is not checked against the information learned router. Note the source link layer address on link layer frames
through Address Resolution. This allows for an easier addition of is not checked against the information learned through Address
network elements such as bridges and proxies, and eases the stack Resolution. This allows for an easier addition of network
elements such as bridges and proxies, and eases the stack
implementation requirements as less information needs to be passed implementation requirements as less information needs to be passed
from layer to layer. from layer to layer.
o Neighbor Unreachability Detection (NUD) is used for tracking the o Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighboring nodes, both hosts and routers. NUD is reachability of neighboring nodes, both hosts and routers. NUD is
defined in Section 7.3 of RFC 2461 [7]. NUD is defined in Section 7.3 of RFC 2461 [7]. NUD is
security-sensitive, because an attacker could falsely claim that security-sensitive, because an attacker could falsely claim that
reachability exists when it in fact does not. reachability exists when it in fact does not.
The NDP messages follow the ICMPv6 message format. All NDP functions The NDP messages follow the ICMPv6 message format. All NDP functions
are realized using the Router Solicitation (RS), Router Advertisement are realized using the Router Solicitation (RS), Router Advertisement
(RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and
Redirect messages. An actual NDP message includes an NDP message Redirect messages. An actual NDP message includes an NDP message
header, consisting of an ICMPv6 header and ND message-specific data, header, consisting of an ICMPv6 header and ND message-specific data,
and zero or more NDP options. The NDP message options are formatted and zero or more NDP options. The NDP message options are formatted
in the Type-Length-Value format. in the Type-Length-Value format.
<------------NDP Message----------------> <------------NDP Message---------------->
*-------------------------------------------------------------* *-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND message- | ND Message | | IPv6 Header | ICMPv6 | ND Message- | ND Message |
| Next Header = 58 | Header | specific | Options | | Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | | | (ICMPv6) | | data | |
*-------------------------------------------------------------* *-------------------------------------------------------------*
<--NDP Message header--> <--NDP Message header-->
4. Secure Neighbor Discovery Overview 4. Secure Neighbor Discovery Overview
To secure the various functions, a set of new Neighbor Discovery To secure the various functions in NDP, a set of new Neighbor
options is introduced. They are used in to protect NDP messages. Discovery options is introduced. They are used to protect NDP
This specification introduces these options, an authorization messages. This specification introduces these options, an
delegation discovery process, an address ownership proof mechanism, authorization delegation discovery process, an address ownership
and requirements for the use of these components in NDP. proof mechanism, and requirements for the use of these components in
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 Certificate chains, 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 and a router must have
at least one common trust anchor before the host can adopt the at least one common trust anchor before the host can adopt the
router as its default router. Delegation Chain Solicitation and router as its default router. Delegation Chain Solicitation and
Advertisement messages are used to discover a certificate chain to Advertisement messages are used to discover a certificate chain to
the trust anchor without requiring the actual Router Discovery the trust anchor without requiring the actual Router Discovery
messages to carry lengthy certificate chains. The receipt of a messages to carry lengthy certificate chains. The receipt of a
protected Router Advertisement message for which no certificate protected Router Advertisement message for which no certificate
chain is available triggers this process. chain is available 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 or Router Advertisement is the "owner" of the sender of a Neighbor Discovery message is the "owner" of the
claimed address. A public-private key pair needs to be generated claimed address. A public-private key pair is generated by all
by all nodes before they can claim an address. A new NDP option, nodes before they can claim an address. A new NDP option, the CGA
the CGA option, is used to carry the public key and associated option, is used to carry the public key and associated parameters.
parameters.
This specification also allows one to use non-CGA addresses and to This specification also allows a node to use non-CGAs with
use certificates to authorize their use. However, the details of certificates to authorize their use. However, the details of such
such use have been left for future work. use are beyond the scope of this specification.
o A new NDP option, the Signature option, is used to protect all o A new NDP option, the Signature option, is used to protect all
messages relating to Neighbor and Router discovery. messages relating to Neighbor and Router discovery.
Public key signatures are used to protect the integrity of the Public key signatures protect the integrity of the messages and
messages and to authenticate the identity of their sender. The authenticate the identity of their sender. The authority of a
authority of a public key is established either with the public key is established either with the authorization delegation
authorization delegation process, using certificates, or through process, using certificates, or through the address ownership
the address ownership proof mechanism, using CGAs, or both, proof mechanism, using CGAs, or both, depending on configuration
depending on configuration and the type of the message protected. and the type of the message protected.
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 used. Given that Neighbor and options, Timestamp and Nonce, are introduced. Given that Neighbor
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 by all SEND
nodes. nodes.
skipping to change at page 11, line 38 skipping to change at page 11, line 38
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields is described as follows.
Type Type
TBD <To be assigned by IANA> for CGA. TBD <To be assigned by IANA for CGA>.
Length Length
The length of the option, in units of 8 octets. The length of the option (including the Type, Length, Collision
Cnt, Reserved, Modifier, Key Information, and Padding fields) in
units of 8 octets.
Collision Cnt Collision Cnt
An 8-bit collision count, which can get values 0, 1 and 2. Its An 8-bit collision count, which can be 0, 1 or 2. Its semantics
semantics are defined in [12]. are defined in [13].
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.
Modifier Modifier
A random 128-bit number used in CGA generation. Its semantics are A random 128-bit number used in CGA generation. Its semantics are
defined in [12]. defined in [13].
Key Information Key Information
A variable length field containing the public key of the sender, A variable length field containing the public key of the sender,
represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as
described in Section 4 of [12]. described in Section 4 of [13].
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 publicKey field in the Signature option are present, then the publicKey field in the CGA
former option MUST be the public key referred by the Key Hash option MUST be the public key referred by the Key Hash field in
field in the latter option. Packets received with two different the Signature option. Packets received with two different keys
keys MUST be silently discarded. Note that a future extension may MUST be silently discarded. Note that a future extension may
provide a mechanism which allows the owner of an address and the provide a mechanism which allows the owner of an address and the
signer to be different parties. signer to be different parties.
The length of the Key Information field is determined by the ASN.1 The length of the Key Information field is determined by the ASN.1
encoding. encoding.
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,
It begins after the ASN.1 encoding of the previous field has ends, beginning after the ASN.1 encoding of the previous field ends, and
and continues to the end of the option, as specified by the Length continuing to the end of the option, as specified by the Length
field. 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 The CGA option MUST be present in all Neighbor Solicitation and
Advertisement messages, and in Router Solicitation messages not sent Advertisement messages, and MUST be present in Router Solicitation
with the unspecified source address. The CGA option MAY be present messages unless they are sent with the unspecified source address.
in other messages. 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 Modifier, Collision Cnt, and Key Information fields in the CGA The Modifier, Collision Cnt, and Key Information fields in the CGA
option are filled in according to the rules presented above and in option are filled in according to the rules presented above and in
[12]. The used public key is taken from configuration; typically [13]. The public key in the Key Information field is taken from the
from a data structure associated with the source address. The node's configuration used to generate the CGA; typically from a data
address MUST be constructed as specified in Section 4 of [12]. structure associated with the source address. The address MUST be
Depending on the type of the message, this address appears in constructed as specified in Section 4 of [13]. Depending on the type
different places: of the message, this address appears in 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
the purpose of Duplicate Address Detection, and the source address Duplicate Address Detection, and the source address of the message
of the message otherwise. otherwise.
Neighbor Advertisement Neighbor Advertisement
The address MUST be the source address of the message. The address MUST be the source address of the message.
Router Solicitation Router Solicitation
The address MUST be the source address of the message. Note that The address MUST be the source address of the message. Note that
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 silently discarded. Router Solicitation messages option MUST be treated as insecure, i.e., processed in the same way
without the CGA option MUST be silently discarded, unless the source as NDP messages sent by a non-SEND node. The processing of insecure
address of the message is the unspecified address. messages is specified in Section 8. Note that SEND nodes that do not
attempt to interoperate with non-SEND nodes MAY simply discard the
insecure messages.
Router Solicitation messages without the CGA option MUST be also
treated as insecure, unless the source address of the message is the
unspecified address.
A message containing a CGA option MUST be checked as follows: A message 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 [12]. The inputs for the algorithm described in Section 5 of [13]. The inputs to the
algorithm are the contents of the Collision Cnt, Modifier, and the algorithm are the claimed address, as defined in the previous
Key Information fields, the claimed address in the packet (as section, and the concatenation from left to right of the following
discussed in the previous section), and the minimum acceptable Sec data: the contents of the 8-octet Modifier field, the 8-octet
value. If the CGA verification is successful, the recipient subnet-prefix part of the claimed address, the content of the
proceeds with the cryptographically more time consuming check of 1-octet Collision Cnt field, and contents of the variable-length
the signature. Key Information Field.
Note that a receiver which does not support CGA or has not specified If the CGA verification is successful, the recipient proceeds with
the cryptographically more time consuming check of the signature.
However, even if the CGA verification succeeds, no claims about
the validity of the use can be made, until the signature has been
checked.
Note that a receiver that does not support CGA or has not specified
its use for a given interface can still verify packets using trust its use for a given interface can still verify packets using trust
anchors, even if CGA had been used on a packet. In such a case, the anchors, even if a CGA is used on a packet. In such a case, the CGA
CGA property of the address is simply left unverified. property of 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 the public keys used in the The minimum acceptable key length for public keys used in the
generation of the CGA address. 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. Any implementation should that use these security associations. The upper limit SHOULD be
follow prudent cryptographic practice in determining the at least 2048 bits. Any implementation should follow prudent
appropriate key lengths. cryptographic practice in determining the appropriate key lengths.
minSec minSec
The minimum acceptable Sec value, if CGA verification is required The minimum acceptable Sec value, if CGA verification is required.
(see Section 2 in [12]). This parameter is intended to facilitate This parameter is intended to facilitate future extensions and
future extensions and experimental work. Currently, the minSec experimental work. Currently, the minSec value SHOULD always be
value SHOULD always be set to zero. 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, including the used Sec
and Modifier values, and the CGA address itself. and Modifier values, and the CGA address itself.
5.2 Signature Option 5.2 Signature Option
The Signature option allows public-key based signatures to be The Signature option allows public-key based signatures to be
attached to NDP messages. Both trust anchor authentication and CGAs attached to NDP messages. Configured trust anchors, CGAs, or both
can be used. The format of the Signature option is described in the are supported as the trusted root. The format of the Signature
following: option is 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 | Pad Length | Reserved | | Type | Length | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Key Hash | | Key Hash |
| | | |
| | | |
skipping to change at page 15, line 28 skipping to change at page 15, line 40
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of the fields is described below:
Type Type
TBD <To be assigned by IANA> for Signature. TBD <To be assigned by IANA for Signature>.
Length Length
The length of the option, in units of 8 octets. The length of the option (including the Type, Length, Pad Length,
Reserved, Key Hash, Digital Signature, and Padding fields) in
units of 8 octets.
Pad Length Pad Length
An 8-bit integer field, giving the length of the Pad field in An 8-bit integer field, giving the length of the Pad field in
units of an octet. units of an octet.
Reserved Reserved
An 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.
Key Hash Key Hash
A 128-bit field contains the most significant (leftmost) 128-bits A 128-bit field containing the most significant (leftmost)
of a SHA1 hash of the public key used for the constructing the 128-bits of a SHA-1 hash of the public key used for constructing
signature. The SHA1 is taken over the presentation used in the the signature. The SHA-1 hash is taken over the presentation used
Key Information field in the CGA option. Its purpose is to in the Key Information field of the CGA option. Its purpose is to
associate the signature to a particular key known by the receiver. associate the signature to a particular key known by the receiver.
Such a key can be either stored in the certificate cache of the Such a key can be either stored in the certificate cache of the
receiver, or be received in the CGA option in the same message. receiver, or be received in the CGA option in the same message.
Digital Signature Digital Signature
A variable length field contains the signature constructed using A variable length field containing a PKCS#1 signature, constructed
the sender's private key, over the the following sequence of using the sender's private key, over the the following sequence of
octets: octets:
1. The 128-bit CGA Type Tag [12] value for SEND, 0x086F CA5E 10B2 1. The 128-bit CGA Message Type tag [13] value for SEND, 0x086F
00C9 9C8C E001 6427 7C08 (generated randomly). CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
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 32-bit ICMP header.
5. The NDP message header. 5. The NDP message header.
6. All NDP options preceding the Signature option. 6. All NDP options preceding the Signature option.
The signature is constructed using the RSA algorithm and MUST be The signature value is computed with the RSASSA-PKCS1-v1_5
encoded as private key encryption in PKCS#1 format [13]. The algorithm and SHA-1 hash as defined in [14].
signature value is computed with the RSASSA-PKCS1-v1_5 algorithm
and SHA-1 hash as defined in [13].
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
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
This variable length field contains padding, as many bytes as is This variable length field contains padding, as many bytes as is
given by the Pad Length Field. given by the Pad Length field.
5.2.1 Processing Rules for Senders 5.2.1 Processing Rules for Senders
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages MUST contain the Signature option. Router and Redirect messages MUST contain the Signature option. Router
Solicitation messages not sent with the unspecified source address Solicitation messages not sent with the unspecified source address
MUST contain the Signature option. MUST contain the Signature option.
A node sending a message using the Signature option MUST construct A node sending a message using the Signature option MUST construct
the message as follows: the message as follows:
skipping to change at page 17, line 29 skipping to change at page 17, line 44
* The contents of the message, starting from the ICMPv6 header, * The contents of the message, starting from the ICMPv6 header,
up to but excluding the Signature option. up to but excluding the Signature option.
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 signature is put
to the Digital Signature field. to 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 silently and Redirect messages without the Signature option MUST be treated as
discarded. Router Solicitation messages without the Signature option insecure, i.e., processed in the same way as NDP messages sent by a
MUST be silently discarded, unless the source address of the message non-SEND node. See Section 8.
is the unspecified address.
Router Solicitation messages without the Signature option MUST be
also treated as insecure, unless the source address of the message is
the unspecified address.
A message containing a Signature option MUST be checked as follows: A message containing a Signature option MUST be checked as follows:
o The Signature option MUST appear as the last option. o The receiver MUST ignore any options the come after the first
Signature option.
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, or one known by either one learned from a preceding CGA option in the same
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. exceed the length of the 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 authorization delegation chain 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 silently discard packets also otherwise, discarded. The receiver MAY also otherwise silently discard packets,
e.g., as a response to an apparent CPU exhausting DoS attack. 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 All nodes that support the reception of the Signature options MUST be
record the following configuration information for each separate NDP configured with the following information for each separate NDP
message type: 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.1. 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 [12]. The sender may claim additional authority described in [13]. 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 public keys and names of the allowed trust anchor(s), if the
authorization method is not set to CGA. authorization method is not set to CGA.
All nodes that support the sending of Signature options MUST record All nodes that support the sending of Signature options MUST record
the following configuration information: 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 delegation chain from a trust anchor to this
key pair. key pair.
CGA flag CGA flag
A flag that indicates whether CGA is used or is not used. This A flag that indicates whether CGA is used or not. This flag may
flag may be per interface or per node. be per interface or per node. (Note that in future extensions of
the SEND protocol, this flag may 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 this option is computationally
expensive. In the NDP context, however, the hosts typically have the expensive. In the NDP context, however, the hosts typically have the
need to perform only a few signature operations as they enter a link, need to perform only a few signature operations as they enter a link,
and a few operations as they find a new on-link peer with which to and a few operations as they find a new on-link peer with which to
communicate. communicate.
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 ones per second, some of operations is on the order of a few dozen per second, some of which
which can be precomputed as discussed below. A large number of can be precomputed as explained below. A large number of router
router solicitations may cause higher demand for performing solicitations may cause higher demand for performing asymmetric
asymmetric operations, although RFC 2461 limits the rate at which operations, although RFC 2461 limits the rate at which responses to
responses to solicitations can be sent. 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 and Router Advertisements if the timing of such future advertisements
advertisements is known. Typically, solicited advertisements are is known. Typically, solicited advertisements are sent to the
sent to the unicast address from which the solicitation was sent. unicast address from which the solicitation was sent. Given that the
Given that the IPv6 header is covered by the signature, it is not IPv6 header is covered by the signature, it is not possible to
possible to precompute solicited-for advertisements. precompute solicited advertisements.
5.3 Timestamp and Nonce options 5.3 Timestamp and Nonce options
5.3.1 Timestamp Option 5.3.1 Timestamp Option
The purpose of the Timestamp option is to ensure that unsolicited The purpose of the Timestamp option is to assure that unsolicited
advertisements and redirects have not been replayed. The format of advertisements and redirects have not been replayed. The format of
this option is described in the following: 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 | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Timestamp + + Timestamp +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:
Type Type
TBD <To be assigned by IANA> for Timestamp. TBD <To be assigned by IANA for Timestamp>.
Length Length
The length of the option, in units of 8 octets, i.e., 2. The length of the option (including the Type, Length, Reserved,
and Timestamp fields) in units of 8 octets, i.e., 2.
Reserved Reserved
A 48-bit field reserved for future use. The value MUST be A 48-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.
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.
5.3.2 Nonce Option 5.3.2 Nonce Option
The purpose of the Nonce option is to ensure 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 receiving same a fresh response to a solicitation sent earlier by the node. 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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
. . . .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:
Type Type
TBD <To be assigned by IANA> for Nonce. TBD <To be assigned by IANA for Nonce>.
Length Length
The length of the option, in units of 8 octets. The length of the option (including the Type, Length, and Nonce
fields) in units of 8 octets.
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. 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.
5.3.3 Processing rules for senders 5.3.3 Processing rules for senders
All solicitation messages MUST include a Nonce. All solicited-for All solicitation messages MUST include a Nonce. When sending a
advertisements MUST include a Nonce, copying the nonce value from the solicitation, the sender MUST store the nonce internally so that it
received solicitation. When sending a solicitation, the sender MUST can recognize any replies containing that particular nonce.
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
received solicitation. Note that routers may decide to send a
multicast advertisement to all nodes instead of a response to a
specific host. In such case the router MAY still include the nonce
value for the host that triggered the multicast advertisement.
All solicitation, advertisement, and redirect messages MUST include a All solicitation, advertisement, and redirect messages MUST include a
Timestamp. Senders SHOULD set the Timestamp field to the current Timestamp. Senders SHOULD set the Timestamp field to the current
time, according to their real time clock. time, according to their real time clock.
If a message has both Nonce and Timestamp options, the Nonce option If a message has both Nonce and Timestamp options, the Nonce option
SHOULD precede the Timestamp option in order. SHOULD precede the Timestamp option in the message.
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-for advertisement or not. A system may a packet is a solicited advertisement. A system may implement the
implement the distinction in various means. Section 5.3.4.1 defines distinction in various ways. Section 5.3.4.1 defines the processing
the processing rules for solicited-for advertisements. Section rules for solicited advertisements. Section 5.3.4.2 defines the
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 any case: In addition, the following rules apply in all cases:
o Messages received without the Timestamp option MUST be silently o Messages received with the Signature option but without the
discarded. Timestamp option MUST be silently discarded.
o Solicitation messages received without the Nonce option MUST be o Solicitation messages received with the Signature option but
silently discarded. without the Nonce option MUST be silently discarded.
o Advertisements sent to a unicast destination address without a o Advertisements sent to a unicast destination address with the
Nonce option MUST be silently discarded. Signature option but without a Nonce option MUST be silently
discarded.
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 C.
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-for 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.
If the message contains a Nonce option, but the Nonce value is not If the message contains a Nonce option, but the Nonce value is not
recognized, the message MUST be silently discarded. recognized, the message MUST be silently discarded.
Otherwise, if the message does not contain a Nonce option, it MAY be Otherwise, if the message does not contain a Nonce option, it MAY be
considered as a non-solicited-for advertisement, and processed considered as an unsolicited advertisement, and processed according
according to Section 5.3.4.2. to Section 5.3.4.2.
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
3,600 seconds (1 hour), for fuzz factor 1 second, and for clock drift TIMESTAMP_DELTA, for fuzz factor TIMESTAMP_FUZZ, and for clock drift
1% (0.01). TIMESTAMP_DRIFT (see Section 11.
To facilitate timestamp checking, each node SHOULD store the To facilitate timestamp checking, each node SHOULD store the
following information per each peer: following information for each peer:
The receive time of the last received, accepted SEND message. o The receive time of the last received and accepted SEND message.
This is called RDlast. This is called RDlast.
The time stamp in the last received, accepted SEND message. This o The time stamp in the last received and accepted SEND message.
is called TSlast. This is called TSlast.
An accepted SEND message is any successfully verified Neighbor
Solicitation, Neighbor Advertisement, Router Solicitation, Router
Advertisement, or Redirect message from the given peer. It is
required that the Signature option has been used in such a message
before it can update 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 If the timestamp is NOT within the boundaries but the message is a
Neighbor Solicitation message that should be responded to by the Neighbor Solicitation message which should be answered by the
receiver, the receiver MAY respond to the message. However, if it receiver, the receiver MAY respond to the message. However, if it
does respond to the message, it MUST NOT create a neighbor cache does respond to the message, it MUST NOT create a Neighbor Cache
entry. This allows nodes that have large difference in their entry. This allows nodes that have large differences in their
clocks to still communicate with each other, by exchanging NS/NA clocks to still communicate with each other, by exchanging NS/NA
pairs. 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
o If TSnew < TSlast, which is possible if packets arrive rapidly and If this inequality does not hold, the receiver SHOULD silently
out of order, TSlast MUST NOT be updated, i.e., the stored TSlast discard the message. On the other hand, if the inequality holds,
for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD the receiver SHOULD process the message.
be updated. Independent on whether TSlast is updated or not,
RDlast is updated in any case. Moreover, if the above inequality holds and TSnew > TSlast, the
receiver SHOULD update RDlast and TSlast. Otherwise, the receiver
MUST NOT update update RDlast or TSlast.
6. Authorization Delegation Discovery 6. Authorization Delegation Discovery
Several protocols (NDP included) allow a node to automatically NDP allows a node to automatically configure itself based on
configure itself based on information it learns shortly after information learned shortly after connecting to a new link. It is
connecting to a new link. It is particularly easy to configure particularly easy to configure "rogue" routers on an unsecured link,
"rogue" routers on an unsecured link, and it is particularly and it is particularly difficult for a node to distinguish between
difficult for a node to distinguish between valid and invalid sources valid and invalid sources of router information, because the node
of information, when the node needs this information before being needs this information before being able to communicate with nodes
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 validating the be responsible for searching information to help validate the
router(s); however, given a chain of appropriately signed router(s); however, given a chain of appropriately signed
certificates, it can check someone else's search results and conclude certificates, it can check someone else's search results and conclude
that a particular message comes from an authorized source. In the that a particular message comes from an authorized source. In the
typical case, a router, which is already connected to beyond the typical case, a router already connected to beyond the link, can (if
link, can (if necessary) communicate with off-link nodes and necessary) communicate with off-link nodes and construct such a
construct such a certificate chain. 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 certificate chain with the
assistance of the router. assistance of the router.
6.1 Certificate Format 6.1 Certificate Format
The certificate chain of a router terminates in a Router The certificate chain 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 chains are not a common practice
in the Internet at the time this specification is being written, the in the Internet at the time this specification was written, the chain
chain MUST consist of standard Public Key Certificates (PKC, in the MUST consist of standard Public Key Certificates (PKC, in the sense
sense of [18]). The certificate chain MUST start from the identity of [19]). The certificate chain MUST start from the identity of a
of a trust anchor that is shared by the host and the router. This trust anchor that is shared by the host and the router. This allows
allows the host to anchor trust for the router's public key in the the host to anchor trust for the router's public key in the trust
trust anchor. Note that there MAY be multiple certificates issued by anchor. Note that there MAY be multiple certificates issued by a
a single trust anchor. single trust anchor.
6.1.1 Router Authorization Certificate Profile 6.1.1 Router Authorization Certificate Profile
Router Authorization Certificates be X.509v3 certificates, as defined Router Authorization Certificates are X.509v3 certificates, as
in RFC 3280 [10], and MUST contain at least one instance of the X.509 defined in RFC 3280 [10], and MUST contain at least one instance of
extension for IP addresses, as defined in [11]. The parent the X.509 extension for IP addresses, as defined in [12]. The parent
certificates in the certificate chain MUST contain one or more X.509 certificates in the certificate chain MUST contain one or more X.509
IP address extensions, back up to a trusted party (such as the user's IP address extensions, back up to a trusted party (such as the user's
ISP) that configured the original IP address space block for the ISP) that configured the original IP address space block for the
router in question, or delegated the right to do so for someone. The router in question, or delegated the right to do so. The
certificates for intermediate delegating authorities MUST contain certificates for the intermediate delegating authorities MUST contain
X.509 IP address extension(s) for subdelegations. The router's X.509 IP address extension(s) for subdelegations. The router's
certificate is signed by the delegating authority for the prefixes certificate is signed by the delegating authority for the prefixes
the router is authorized to to advertise. the router is authorized to 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 addressesOrRanges element. This element MUST contain an
addressPrefix element with an IPv6 address prefix for a prefix the addressPrefix element containing an IPv6 address prefix for a prefix
router or the intermediate entity is authorized to route. If the the router or the intermediate entity is authorized to route. If the
entity is allowed to route any prefix, the used IPv6 address prefix entity is allowed to route any prefix, the used IPv6 address prefix
is the null prefix, 0/0. The addressFamily element of the containing is the null prefix, ::/0. The addressFamily element of the
IPAddrBlocks sequence element MUST contain the IPv6 Address Family containing IPAddrBlocks sequence element MUST contain the IPv6
Identifier (0002), as specified in [11] for IPv6 prefixes. Instead Address Family Identifier (0002), as specified in [12] for IPv6
of an addressPrefix element, the addressesOrRange element MAY contain prefixes. Instead of an addressPrefix element, the addressesOrRange
an addressRange element for a range of prefixes, if more than one element MAY contain an addressRange element for a range of prefixes,
prefix is authorized. The X.509 IP address extension MAY contain if more than one prefix is authorized. The X.509 IP address
additional IPv6 prefixes, expressed either as an addressPrefix or an extension MAY contain additional IPv6 prefixes, expressed either as
addressRange. an addressPrefix or an addressRange.
A SEND node receiving a Router Authorization Certificate MUST first A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the delegating authority. Then the client MUST 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 prefixes or ranges, the client MAY attempt to
take an intersection of the ranges/prefixes, and use that take an intersection of the ranges/prefixes, and use that
intersection. If the addressPrefix in the certificate is the null intersection. If the addressPrefix in the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case the prefix, ::/0, such an intersection SHOULD be used. (In that case the
intersection is the parent prefix or range.) If the resulting intersection is the parent prefix or range.) If the resulting
intersection is empty, the client MUST NOT accept the certificate. intersection is empty, the client MUST NOT accept the certificate.
The above check SHOULD be done for all certificates in the chain. If The above check SHOULD be done for all certificates in the chain. If
any of the checks fail, the client MUST NOT accept the certificate. any of the checks fail, the client MUST NOT accept the certificate.
The client also needs to perform validation of advertised prefixes as The client also needs to perform validation of advertised prefixes as
discussed in Section 7.3. discussed in Section 7.3.
Care should be taken if the certificates used in SEND are re-used to Care should be taken if the certificates used in SEND are re-used to
provide authorization in other circumstances, for example with provide authorization in other circumstances, for example with
routing gateway protocols. It is necessary to ensure that the routing protocols. It is necessary to ensure that the authorization
authorization information is appropriate for all applications. SEND information is appropriate for all applications. SEND certificates
certificates may authorize a larger set of prefixes than the router may authorize a larger set of prefixes than the router is really
is really authorized to advertise on a given interface. For authorized to advertise on a given interface. For instance, SEND
instance, SEND allows the use of the null prefix. This prefix might allows the use of the null prefix. This prefix might cause
cause verification or routing problems in other applications. It is verification or routing problems in other applications. It is
RECOMMENDED that SEND certificates containing the null prefix are RECOMMENDED that SEND certificates containing the null prefix are
only used for SEND. only used for SEND.
Since it is possible that some PKC certificates used with SEND do not Since it is possible that some public key certificates used with SEND
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 certificate chain. Suppose that
ispgroup.com is the trust anchor. The host has this certificate for isp_group_example.net is the trust anchor. The host has this
it: certificate:
Certificate 1: Certificate 1:
Issuer: isp_group.com Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004 Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group.com 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 then to a linked served by When the host attaches to a link served by
router_x.isp_foo.com, it receives the following certificate chain: router_x.isp_foo_example.net, it receives the following certificate
chain:
Certificate 2: Certificate 2:
Issuer: isp_group.com Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004 Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo.com 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 ...
Certificate 3: Certificate 3:
Issuer: isp_foo.com 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.com 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 When processing the three certificates, the usual RFC 3280 [10]
certificate path validation is performed, for instance by checking certificate path validation is performed. Note, however, that at the
for revoked certificates. In addition, the IP addresses in the time a node is checking certificates received in a DCA from a router,
delegation extension must be subsumed by the IP addresses in the it typically does not have a connection to the Internet yet, and so
delegation extension in the issuer's certificate. So in this it is not possible to perform an on-line Certificate Revocation List
example, R1, ..., Rs must be subsumed by Q1,...,Qr, and Q1,...,Qr (CRL) check if such a check is necessary. Until such a check is
must be subsumed by P1,...,Pk. If the certificate chain is valid, performed, acceptance of the certificate MUST be considered
then router_foo.isp_foo_example.com is authorized to route the provisional, and the node MUST perform a check as soon as it has
prefixes R1,...,Rs. established a connection with the Internet through the router. If
the router has been compromised, it could interfere with the CRL
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 and use another router on the link instead.
In addition, the IP addresses in the delegation extension must be a
subset of the IP addresses in the delegation extension of the
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
the certificate chain is valid, then router_foo.isp_foo_example.com
is authorized to route the prefixes R1,...,Rs.
6.2 Certificate Transport 6.2 Certificate Transport
The Delegation Chain Solicitation (DCS) message is sent by a host The Delegation Chain Solicitation (DCS) message is sent by a host
when it wishes to request a certificate chain between a router and when it wishes to request a certificate chain between a router and
the one of the host's trust anchors. The Delegation Chain the one of the host's trust anchors. The Delegation Chain
Advertisement (DCA) message is sent as an answer to the DCS message. Advertisement (DCA) message is sent in reply to the DCS 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 certificate chain 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 certificate chains. 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. certificate chains - of the next router from a previous router, or
nodes may be preconfigured with certificate chains from roaming
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 certificate chain. However, the details of such usage are
left for future specification. beyond the scope of this specification.
6.2.1 Delegation Chain Solicitation Message Format 6.2.1 Delegation Chain Solicitation Message Format
Hosts send Delegation Chain Solicitations in order to prompt routers Hosts send Delegation Chain Solicitations in order to prompt routers
to generate Delegation Chain Advertisements. to generate Delegation Chain 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 |
skipping to change at page 28, line 18 skipping to change at page 29, 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 Delegation Chain 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, though. Its purpose is to avoid cryptographically hard, since its purpose is only to avoid
collisions.) collisions.
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:
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.2.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 types of Trust Anchors. 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.2.2 Delegation Chain Advertisement Message Format
skipping to change at page 29, line 35 skipping to change at page 31, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
addresses, and therefore this address not sufficient for the addresses, and therefore this address is not sufficient for the
unique identification of routers. unique identification of routers.
Destination Address Destination Address
Either the Solicited-Node multicast address of the receiver or Either the Solicited-Node multicast address of the receiver or
the link-scoped All-Nodes multicast address. the link-scoped All-Nodes multicast address.
Hop Limit Hop Limit
255 255
ICMP Fields: ICMP Fields:
Type Type
TBD <To be assigned by IANA> for Delegation Chain TBD <To be assigned by IANA for Delegation Chain
Advertisement. Advertisement>.
Code Code
0 0
Checksum Checksum
The ICMP checksum [9]. The ICMP checksum [9].
Identifier Identifier
skipping to change at page 30, line 40 skipping to change at page 32, line 10
the fragmentation at the IP layer, individual components of an the fragmentation at the IP layer, individual components of an
advertisement may be stored and used before all the components advertisement may be stored and used before all the components
have arrived; this makes them slightly more reliable and less have arrived; this makes them slightly more reliable and less
prone to Denial-of-Service attacks. prone to Denial-of-Service attacks.
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 trust anchor end of The components MUST be ordered so that the certificate after
the chain is the one sent first. Each certificate sent after the trust anchor is the one sent first. Each certificate sent
it can be verified with the previously sent certificates. The after the first can be verified with the previously sent
certificate of the sender comes last. certificates. The certificate of the sender comes last.
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
skipping to change at page 31, line 41 skipping to change at page 33, line 13
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:
Type Type
TBD <To be assigned by IANA> for Trust Anchor. TBD <To be assigned by IANA for Trust Anchor>.
Length Length
The length of the option, (including the Type, Length, Name Type, The length of the option, (including the Type, Length, Name Type,
Name Length, and Name fields,) in units of 8 octets. Pad Length, and Name fields) in units of 8 octets.
Name Type Name Type
The type of the name included in the Name field. This The type of the name included in the Name field. This
specification defines only one legal value for this field: specification defines two legal values for this field:
1 DER Encoded X.501 Name 1 DER Encoded X.501 Name
2 FQDN 2 FQDN
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.
skipping to change at page 32, line 32 skipping to change at page 33, line 49
DER encoded X.501 certificate Name, represented and encoded DER encoded X.501 certificate Name, represented and encoded
exactly as in the matching X.509v3 trust anchor certificate. exactly as in the matching X.509v3 trust anchor certificate.
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] "preferred name syntax" DNS format, as specified in RFC 1034 [1]
Section 3.5. Additionally, the restrictions discussed in RFC 3280 Section 3.5. Additionally, the restrictions discussed in RFC 3280
[10] Section 4.2.1.7 apply. [10] Section 4.2.1.7 apply.
All systems MUST implement support the DER Encoded X.501 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
characters. An implementation MAY support internationalized
domain names (IDNs) using the ToASCII operation; see [11] for more
information.
All systems MUST support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type. Implementations MAY support the FQDN name type.
6.2.4 Certificate Option 6.2.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 | Pad Length | | Type | Length | Cert Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ... | Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the fields are as follows:
Type Type
TBD <To be assigned by IANA> for Certificate. TBD <To be assigned by IANA for Certificate>.
Length Length
The length of the option, (including the Type, Length, Cert Type, The length of the option, (including the Type, Length, Cert Type,
Pad Length, and Certificate fields,) in units of 8 octets. Pad Length, and Certificate fields) in units of 8 octets.
Cert Type Cert Type
The type of the certificate included in the Certificate field. The type of the certificate included in the Certificate field.
This specification defines only one legal value for this field: This specification defines only one legal value for this field:
1 X.509v3 Certificate, as specified below 1 X.509v3 Certificate, as specified below
Pad Length Pad Length
skipping to change at page 33, line 32 skipping to change at page 35, line 7
receivers. receivers.
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.1.1.
6.2.5 Processing Rules for Routers 6.2.5 Processing Rules for Routers
Routers SHOULD possess a key pair and a certificate from at least one Routers should be configured with a key pair and a certificate from
certificate authority. at least one certificate authority.
A router MUST silently discard any received Delegation Chain A router MUST silently discard any received Delegation Chain
Solicitation messages that do not satisfy all of the following Solicitation messages that do not conform to the message format
validity checks: defined in Section 6.2.1. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future,
o All requirements listed in Section 6.2.1 are fulfilled. backward-compatible changes to the protocol may specify the contents
of the Reserved field or add new options; backward-incompatible
o If the message includes an IP Authentication Header, the message changes may use different Code values. The contents of any defined
authenticates correctly. options that are not specified to be used with Router Solicitation
messages MUST be ignored and the packet processed in the normal
The contents of the Reserved field, and of any unrecognized options, manner. The only defined option that may appear is the Trust Anchor
MUST be ignored. Future, backward-compatible changes to the protocol option. A solicitation that passes the validity checks is called a
may specify the contents of the Reserved field or add new options; "valid solicitation".
backward-incompatible changes may use different Code values. The
contents of any defined options that are not specified to be used
with Router Solicitation messages MUST be ignored and the packet
processed in the normal manner. The only defined option that may
appear is the Trust Anchor option. A solicitation that passes the
validity checks is called a "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. Routers SHOULD NOT send Delegation Chain source address, except when under load, as specified below. Routers
Advertisements more than MAX_DCA_RATE times within a second. When SHOULD NOT send Delegation Chain Advertisements more than
there are more solicitations than this, the router SHOULD send the MAX_DCA_RATE times within a second. When there are more
response to the All-Nodes multicast address regardless of the source solicitations, the router SHOULD send the response to the All-Nodes
address that appeared in the solicitation. multicast address regardless of the source address that appeared in
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 delegation chain to the solicited trust anchor can
be established. The anchor is identified by the Trust Anchor option. be established. The anchor is identified by the Trust Anchor option.
If the Trust Anchor option is represented as a DER Encoded X.501 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 Name, then the Name must be equal to the Subject field in the
anchor's certificate. If the Trust Anchor option is represented as anchor's certificate. If the Trust Anchor option is represented as
an FQDN, the FQDN must be equal to an FQDN in the subjectAltName an FQDN, the FQDN must be equal to an FQDN in the subjectAltName
field of the anchor's certificate. The router SHOULD include the field of the anchor's certificate. The router SHOULD include the
Trust Anchor option(s) in the advertisement for which the delegation Trust Anchor option(s) in the advertisement for which the delegation
skipping to change at page 34, line 38 skipping to change at page 36, line 9
If the router is unable to find a chain to the requested anchor, it If the router is unable to find a chain 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.2.6 Processing Rules for Hosts
Hosts SHOULD possess the public key and trust anchor name of at least Hosts SHOULD possess the public key and trust anchor name of at least
one certificate authority, they SHOULD possess their own key pair, one certificate authority, they SHOULD possess their own key pair,
and they MAY posses a certificate from the above mentioned and they MAY possess certificates from certificate authorities.
certificate authority.
A host MUST silently discard any received Delegation Chain A host MUST silently discard any received Delegation Chain
Advertisement messages that do not satisfy all of the following Advertisement messages that do not conform to the message format
validity checks: defined in Section 6.2.2. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future,
o All requirements listed in Section 6.2.2 are fulfilled. backward-compatible changes to the protocol MAY specify the contents
of the Reserved field or add new options; backward-incompatible
o If the message includes an IP Authentication Header, the message changes MUST use different Code values. The contents of any defined
authenticates correctly. options that are not specified to be used with Delegation Chain
Advertisement messages MUST be ignored and the packet processed in
The contents of the Reserved field, and of any unrecognized options, the normal manner. The only defined options that may appear are the
MUST be ignored. Future, backward-compatible changes to the protocol Certificate and Trust Anchor options. An advertisement that passes
may specify the contents of the Reserved field or add new options; the validity checks is called a "valid advertisement".
backward-incompatible changes may use different Code values. The
contents of any defined options that are not specified to be used
with Delegation Chain Advertisement messages MUST be ignored and the
packet processed in the normal manner. The only defined options that
may appear are the Certificate and Trust Anchor options. An
advertisement that passes the validity checks is called a "valid
advertisement".
Hosts SHOULD store certificate chains retrieved in Delegation Chain Hosts SHOULD store certificate chains retrieved in Delegation Chain
Discovery messages if they start from an anchor trusted by the host. Discovery messages if they start from an anchor trusted by the host.
The certificate chains SHOULD be verified, as defined in Section 6.1, The certificate chains MUST be verified, as defined in Section 6.1,
before storing them. Routers MUST send the certificates one by one, before storing them. Routers MUST send the certificates one by one,
starting from the trust anchor end of the chain. Except for starting from the trust anchor end of the chain. Except for
temporary purposes to allow for message loss and reordering, hosts temporary purposes to allow for message loss and reordering, hosts
SHOULD NOT store certificates received in a Delegation Chain SHOULD NOT store certificates received in a Delegation Chain
Advertisement unless they contain a certificate which can be Advertisement unless they contain a certificate which can be
immediately verified either to the trust anchor or to a certificate immediately verified either to the trust anchor or to a certificate
which has been verified earlier. that has been verified earlier.
Note that it may be useful to cache this information and implied Note that caching this information and the implied verification
verification results for use over multiple attachments to the results between network attachments for use over multiple attachments
network. to the network can help improve performance. But periodic
certificate revocation checks are still needed even with cached
results, to make 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 delegation chain 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 stored
in the hosts' cache of certificates, or there is no authorization in the hosts' cache of certificates, or there is no authorization
delegation chain to the host's trust anchor. In these situations, delegation chain to the host's trust anchor. In these situations,
the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain
Solicitation messages, each separated by at least DCS_INTERVAL Solicitation messages, each separated by at least DCS_INTERVAL
seconds. seconds.
Delegation Chain Solicitations SHOULD NOT be sent if the host has a Delegation Chain Solicitations SHOULD NOT be sent if the host has a
currently valid certificate chain from a reachable router to a trust currently valid certificate chain 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 Delegation Chain 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 it has already been selected. default router's IP address, if a default router has already been
selected.
If two hosts want to establish trust with the DCS and DCA messages, If two hosts want to establish trust with the DCS and DCA messages,
the DCS message SHOULD be sent to the Solicited-Node multicast the DCS 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 left for specified above for routers. However, the exact details are outside
a future 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).
7. Addressing 7. Addressing
7.1 CGA Addresses 7.1 CGAs
Nodes that use stateless address autoconfiguration, SHOULD generate a Nodes that use stateless address autoconfiguration SHOULD generate a
new CGA as specified in Section 4 of [12] for each new new CGA as specified in Section 4 of [13] each time they run the
autoconfiguration run. The nodes MAY continue to use the same public autoconfiguration procedure. The nodes MAY continue to use the same
key and modifier, and start the process from Step 4. public key and modifier, and start the process from Step 4 of the
generation algorithm.
By default, a SEND-enabled node SHOULD use only CGAs as 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 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 [22]. API, such as the one defined in [23].
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 silently discarded.
Note that RFC 2461 rules prevent a bogus router from sending a Note that RFC 2461 rules prevent a host from accepting a Redirect
Redirect message when the host is not using the bogus router as a message from a router that is not its default router. This prevents
default router. an attacker from tricking a node into redirecting traffic when the
attacker is not the default router.
7.3 Advertised Prefixes 7.3 Advertised Prefixes
The router's certificate defines the address range(s) that it is The router's certificate defines the address range(s) that it is
allowed to advertise. Upon processing a Prefix Information option allowed to advertise securely. A router MAY, however, advertise a
within a Router Advertisement, nodes SHOULD verify that the prefix combination of certified and uncertified prefixes. Uncertified
specified in this option falls within the range defined by the prefixes are treated as insecure, i.e., processed in the same way as
certificate, if the certificate contains a prefix extension. Options insecure router advertisements sent by non-SEND routers. The
failing this check MUST be silently discarded. processing of insecure messages is specified in Section 8. Note that
SEND nodes that do not attempt to interoperate with non-SEND nodes
MAY simply discard the insecure information.
Nodes SHOULD use one of the certified prefixes for stateless Certified prefixes fall into the following two categories:
autoconfiguration. If none of the advertised prefixes match, then
either there is a configuration problem or the advertising router is
an attacker, and the host MUST use a different advertising router as
its default router (if available). If the node is performing
stateful autoconfiguration, it SHOULD check the address provided by
the DHCP server against the certified prefixes and MUST NOT use the
address if the prefix is not certified.
In any case, the user should inform the network operator upon Constrained
receiving an address or prefix outside the certified range, since
this is either a misconfiguration or an attack.
If the network operator wants to constrain which routers are allowed If the network operator wants to constrain which routers are
to route particular prefixes, routers SHOULD be configured with allowed to route particular prefixes, routers should be configured
certificates having prefixes listed in the prefix extension. Routers with certificates having prefixes listed in the prefix extension.
so configured MUST advertise the prefixes which they are certified to Routers so configured SHOULD advertise the prefixes which they are
route, or a subset thereof. certified to route, or a subset thereof.
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 null should configure routers with certificates containing either the
prefix or no prefix extension at all. null prefix or no prefix extension at all.
Upon processing a Prefix Information option within a Router
Advertisement, nodes SHOULD verify that the prefix specified in this
option falls within the range defined by the certificate, if the
certificate contains a prefix extension. Options failing this check
are treated as containing uncertified prefixes.
Nodes SHOULD use one of the certified prefixes for stateless
autoconfiguration. If none of the advertised prefixes match, the
host SHOULD use a different advertising router as its default router,
if available. If the node is performing stateful autoconfiguration,
it SHOULD check the address provided by the DHCP server against the
certified prefixes and SHOULD NOT use the 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 certificate chain-based authorization specifications are
needed for such nodes. needed for such nodes.
It is outside the scope of this specification to describe the use of It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing trust anchor authorization between nodes with dynamically changing
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 [17] addresses. If the CGA method is not used, nodes of RFC 3041 [18] addresses. If the CGA method is not used, nodes
would be required to exchange certificate chains that terminate in a would be required to exchange certificate chains 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 a few
cases where such certificates are required by the link layer and it cases where such certificates are required 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 Neighbor Discovery. Proxy Neighbor Discovery is not supported by
this specification; it is planned to be specified in a future this specification.
document.
8. Transition Issues 8. Transition Issues
During the transition to secure links or as a policy consideration, During the transition to secure 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 secure and insecure nodes. Nodes that support SEND SHOULD support
the use of SEND and the legacy NDP at the same time. the use of SEND and plain NDP at the same time.
In a mixed environment, SEND nodes receive both secure and insecure In a mixed environment, SEND nodes receive both secure and insecure
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 "insecure" messages are ones that contain no signature
option. option.
SEND nodes send only secured messages. Legacy Neighbor Discovery SEND nodes MUST send only secured messages. Plain (non-SEND)
nodes will obviously send only insecure messages. Per RFC 2461 [7], Neighbor Discovery nodes will obviously send only insecure messages.
such nodes will ignore the unknown options and will treat secured Per RFC 2461 [7], such nodes will ignore the unknown options and will
messages in the same way as they treat insecure ones. Secured and treat secured messages in the same way as they treat insecure ones.
insecure nodes share the same network resources, such as prefixes and Secured and insecure nodes share the same network resources, such as
address spaces. prefixes and address spaces.
In a mixed environment SEND nodes follow the protocols defined in RFC In a mixed environment SEND nodes follow the protocols defined in RFC
2461 and RFC 2462 with the following exceptions: 2461 and RFC 2462 with the following exceptions:
o All solicitations sent by SEND nodes 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 insecure 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.
address. If after 3 consecutive attempts no non-unique address If after 3 consecutive attempts no non-unique address was
was generated, log a system error and give up attempting to generated, log a system error and give up attempting to generate
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 insecure 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. insecure Neighbor Advertisements and Solicitations.
o The node SHOULD have a configuration option that causes it to o The node MAY have a configuration option that causes it to ignore
ignore insecure advertisements even when performing Duplicate insecure advertisements even when performing Duplicate Address
Address Detection for the first tentative address. This Detection for the first tentative address. This configuration
configuration option SHOULD be disabled by default. This is option SHOULD be disabled by default. This is a recovery
recovery mechanism, in case attacks against the first address mechanism, in case attacks against the first address become
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/insecure 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 insecure. Received insecure 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. Received secured messages cause an List or Default Router List. The Neighbor Cache SHOULD implement
update of the matching entries and flagging of them as secured. a flag on entries indicating whether the entry issecured.
Received secured messages MUST cause an update of the matching
entries and flagging of them as secured.
o The conceptual sending algorithm is modified so that an insecure o The conceptual sending algorithm is modified so that an insecure
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 SEND node SHOULD have a configuration option that causes it to o A SEND node SHOULD have a configuration option that causes it to
ignore all insecure Neighbor Solicitation and Advertisement, ignore all insecure Neighbor Solicitation and Advertisement,
Router Solicitation and Advertisement, and Redirect messages. Router Solicitation and Advertisement, and Redirect messages.
This can be used to enforce SEND-only networks. This can be used to enforce SEND-only networks.
skipping to change at page 41, line 36 skipping to change at page 43, line 36
Even on a secure link layer, SEND does not require that the addresses Even on a secure link layer, SEND does not require that the addresses
on the link layer and Neighbor Advertisements correspond to each on the link layer and Neighbor Advertisements correspond to each
other. However, it is RECOMMENDED that such checks be performed other. However, it is RECOMMENDED that such checks be performed
where this is possible on the given link layer technology. where this is possible on the given link layer technology.
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
[16]. MLD contains no provision for security. An attacker could [17]. 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 [25]. The following subsections contain a regression of outlined in [24]. 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 [25]. The threat is that This threat is defined in Section 4.1.1 of [24]. 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 firm IPv6 source address and a Target Link-Layer Address with a Target Link-Layer Address extension and the IPv6 source
extension inserts an entry for the IPv6 address into its Neighbor address not equal to the unspecified address inserts an entry for
Cache. Also, a node performing Duplicate Address Detection (DAD) the IPv6 address into its Neighbor Cache. Also, a node
that receives a Neighbor Solicitation for the same address performing Duplicate Address Detection (DAD) that receives a
regards the situation as a collision and ceases to solicit for Neighbor Solicitation for the same address regards the situation
the address. as a 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
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 RFC 2461.
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 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 [25]. SEND counters This attack is described in Section 4.1.2 of [24]. 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 a 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 [25]. SEND counters This attack is described in Section 4.1.3 of [24]. 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 a 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 used on a link that also connects to non-SEND When a SEND node is performing DAD, it may listen for address
nodes, the SEND node ignores any insecure Neighbor Solicitations or collisions from non-SEND nodes for the first address it generates,
Advertisements that may be send by the non-SEND nodes. This protects but not for new attempts. This protects the SEND node from DAD DoS
the SEND node from DAD DoS attacks by non-SEND nodes or attackers attacks by non-SEND nodes or attackers simulating to non-SEND nodes,
simulating to non-SEND nodes, at the cost of a potential address at the cost of a potential address collision between a SEND node and
collision between a SEND node and non-SEND node. The probability and non-SEND node. The probability and effects of such an address
effects of such an address collision are discussed in [12]. collision are discussed in [13].
9.2.4 Router Solicitation and Advertisement Attacks 9.2.4 Router Solicitation and Advertisement Attacks
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
and 4.2.7 of [25]. SEND counters these attacks by requiring Router and 4.2.7 of [24]. SEND counters these attacks by requiring Router
Advertisements to contain a Signature option, and that the signature Advertisements to contain a Signature option, and that the signature
is calculated using the public key of a node that can prove its is calculated using the public key of a node that can prove its
authorization to route the subnet prefixes contained in any Prefix authorization to route the subnet prefixes contained in any Prefix
Information Options. The router proves its authorization by showing Information Options. The router proves its authorization by showing
a certificate containing the specific prefix or the indication that a certificate containing the specific prefix or the indication that
the router is allowed to route any prefix. A Router Advertisement the router is allowed to route any prefix. A Router Advertisement
without these protections is discarded. without these protections is discarded.
SEND does not protect against brute force attacks on the router, such SEND does not protect against brute force attacks on the router, such
as DoS attacks, or compromise of the router, as described in Sections as DoS attacks, or compromise of the router, as described in Sections
4.4.2 and 4.4.3 of [25]. 4.4.2 and 4.4.3 of [24].
9.2.5 Replay Attacks 9.2.5 Replay Attacks
This attack is described in Section 4.3.1 of [25]. SEND protects This attack is described in Section 4.3.1 of [24]. 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. SEND protects
against attacks from unsolicited messages such as Neighbor against attacks from unsolicited messages such as Neighbor
Advertisements, Router Advertisements, and Redirects by including a Advertisements, Router Advertisements, and Redirects by including a
Timestamp option. A window of vulnerability for replay attacks Timestamp option. A window of vulnerability for replay attacks
exists until the timestamp expires. exists until the timestamp expires.
skipping to change at page 44, line 7 skipping to change at page 46, line 7
containing the timestamp. The cached state allows the node to containing the timestamp. The cached state allows the node to
protect itself against replayed messages. However, once the node protect itself against replayed messages. However, once the node
flushes the state for whatever reason, an attacker can re-create the flushes the state for whatever reason, an attacker can re-create the
state by replaying an old message while the timestamp is still valid. state by replaying an old message while the timestamp is still valid.
Since most SEND nodes are likely to use fairly coarse grained Since most SEND nodes are likely to use fairly coarse grained
timestamps, as explained in Section 5.3.1, this may affect some timestamps, as explained in Section 5.3.1, this may affect some
nodes. nodes.
9.2.6 Neighbor Discovery DoS Attack 9.2.6 Neighbor Discovery DoS Attack
This attack is described in Section 4.3.2 of [25]. In this attack, This attack is described in Section 4.3.2 of [24]. 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 [12]. has been discussed in [13].
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 the verification process described in Section 5.2.2. In this
process, a simple hash verification of the CGA property of the process, a simple hash verification of the CGA property of the
address is performed before performing the more expensive signature address is performed before performing the more expensive signature
verification. verification. However, even if the CGA verification succeeds, no
claims about the validity of the message can be made, until the
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 Signature option, and start selectively discarding
packets if too many resources are spent. Implementations MAY also packets if too many resources are spent. Implementations MAY also
first discard packets that are not protected with CGA. 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
skipping to change at page 47, line 5 skipping to change at page 49, line 5
Host constants: Host constants:
MAX_DCS_MESSAGES 3 transmissions MAX_DCS_MESSAGES 3 transmissions
DCS_INTERVAL 4 seconds DCS_INTERVAL 4 seconds
Router constants: Router constants:
MAX_DCA_RATE 10 times per second MAX_DCA_RATE 10 times per second
11. IANA Considerations 11. Protocol Variables
TIMESTAMP_DELTA 3,600 seconds (1 hour)
TIMESTAMP_FUZZ 1 second
TIMESTAMP_DRIFT 1 % (0.01)
12. 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 Delegation Chain Solicitation message, described in Section
6.2.1. 6.2.1.
o The Delegation Chain Advertisement message, described in Section o The Delegation Chain Advertisement message, described in Section
6.2.2. 6.2.2.
skipping to change at page 47, line 34 skipping to change at page 50, line 34
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.2.3.
o The Certificate option, described in Section 6.2.4. o The Certificate option, described in Section 6.2.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
[12] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. [13] 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
Certificate option. Future values of this field can be allocated Certificate 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 X.509v3 Certificate 1 X.509v3 Certificate
Normative References Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD [1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987. 13, RFC 1034, November 1987.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 48, line 40 skipping to change at page 51, 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] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP [11] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[12] 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.
[12] Aura, T., "Cryptographically Generated Addresses (CGA)", [13] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-03 (work in progress), December 2003. draft-ietf-send-cga-03 (work in progress), December 2003.
[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS [14] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002. 1, November 2002.
[14] National Institute of Standards and Technology, "Secure Hash [15] 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
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", [16] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener [17] 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.
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless [18] 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.
[18] Farrell, S. and R. Housley, "An Internet Attribute Certificate [19] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002. Profile for Authorization", RFC 3281, April 2002.
[19] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [20] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Addressing Architecture", RFC 3513, April 2003. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[20] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", [21] 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.
[21] Arkko, J., "Manual SA Configuration for IPv6 Link Local [22] 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.
[22] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API [23] 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.
[23] Droms, R., "Dynamic Host Configuration Protocol for IPv6 [24] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), Discovery trust models and threats", draft-ietf-send-psreq-04
November 2002. (work in progress), October 2003.
[24] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.
[25] Nikander, P., "IPv6 Neighbor Discovery trust models and
threats", draft-ietf-send-psreq-00 (work in progress), October
2002.
[26] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000.
[27] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
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
 End of changes. 

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