draft-ietf-send-ndopt-00.txt   draft-ietf-send-ndopt-01.txt 
Secure Neighbor Discovery Working J. Arkko Secure Neighbor Discovery Working J. Arkko
Group Ericsson Group Ericsson
Internet-Draft J. Kempf Internet-Draft J. Kempf
Expires: April 16, 2004 DoCoMo Communications Labs USA Expires: June 30, 2004 DoCoMo Communications Labs USA
B. Sommerfeld B. Sommerfeld
Sun Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
P. Nikander P. Nikander
Ericsson Ericsson
October 17, 2003 December 31, 2003
SEcure Neighbor Discovery (SEND) SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-00 draft-ietf-send-ndopt-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 16, 2004. This Internet-Draft will expire on June 30, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine each the link-layer addresses other nodes on the link, to determine each the link-layer addresses
of the nodes on the link, to find routers, and to maintain of the nodes on the link, to find routers, and to maintain
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
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Specification of Requirements . . . . . . . . . . . . 4
3. Neighbor and Router Discovery Overview . . . . . . . . . . 7 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 11 3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7
5. Neighbor Discovery Options . . . . . . . . . . . . . . . . 12 4. Secure Neighbor Discovery Overview . . . . . . . . . . . . . 9
5.1 Ordering of the new options . . . . . . . . . . . . . . . 12 5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 11
5.2 CGA Option . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1 CGA Option . . . . . . . . . . . . . . . . . . . . . .11
5.2.1 Processing Rules for Senders . . . . . . . . . . . . . . . 14 5.1.1 Processing Rules for Senders . . . . . . . . . 12
5.2.2 Processing Rules for Receivers . . . . . . . . . . . . . . 15 5.1.2 Processing Rules for Receivers . . . . . . . . 13
5.2.3 Configuration . . . . . . . . . . . . . . . . . . . . . . 15 5.1.3 Configuration . . . . . . . . . . . . . . . . 14
5.3 Signature Option . . . . . . . . . . . . . . . . . . . . . 15 5.2 Signature Option . . . . . . . . . . . . . . . . . . .14
5.3.1 Processing Rules for Senders . . . . . . . . . . . . . . . 18 5.2.1 Processing Rules for Senders . . . . . . . . . 16
5.3.2 Processing Rules for Receivers . . . . . . . . . . . . . . 18 5.2.2 Processing Rules for Receivers . . . . . . . . 17
5.3.3 Configuration . . . . . . . . . . . . . . . . . . . . . . 19 5.2.3 Configuration . . . . . . . . . . . . . . . . 18
5.4 Timestamp and Nonce options . . . . . . . . . . . . . . . 20 5.2.4 Performance Considerations . . . . . . . . . . 19
5.4.1 Timestamp Option . . . . . . . . . . . . . . . . . . . . . 20 5.3 Timestamp and Nonce options . . . . . . . . . . . . .19
5.4.2 Nonce Option . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.1 Timestamp Option . . . . . . . . . . . . . . . 19
5.4.3 Processing rules for senders . . . . . . . . . . . . . . . 22 5.3.2 Nonce Option . . . . . . . . . . . . . . . . . 20
5.4.4 Processing rules for receivers . . . . . . . . . . . . . . 22 5.3.3 Processing rules for senders . . . . . . . . . 21
5.5 Proxy Neighbor Discovery . . . . . . . . . . . . . . . . . 24 5.3.4 Processing rules for receivers . . . . . . . . 21
6. Authorization Delegation Discovery . . . . . . . . . . . . 25 6. Authorization Delegation Discovery . . . . . . . . . . . . . 24
6.1 Delegation Chain Solicitation Message Format . . . . . . . 25 6.1 Certificate Format . . . . . . . . . . . . . . . . . .24
6.2 Delegation Chain Advertisement Message Format . . . . . . 27 6.1.1 Router Authorization Certificate Profile . . . 24
6.3 Trust Anchor Option . . . . . . . . . . . . . . . . . . . 29 6.2 Certificate Transport . . . . . . . . . . . . . . . .26
6.4 Certificate Option . . . . . . . . . . . . . . . . . . . . 30 6.2.1 Delegation Chain Solicitation Message Format . 27
6.5 Router Authorization Certificate Format . . . . . . . . . 31 6.2.2 Delegation Chain Advertisement Message Format 29
6.5.1 Router Authorization Certificate Profile . . . . . . . . . 31 6.2.3 Trust Anchor Option . . . . . . . . . . . . . 31
6.6 Processing Rules for Routers . . . . . . . . . . . . . . . 32 6.2.4 Certificate Option . . . . . . . . . . . . . . 32
6.7 Processing Rules for Hosts . . . . . . . . . . . . . . . . 34 6.2.5 Processing Rules for Routers . . . . . . . . . 33
7. Securing Neighbor Discovery with SEND . . . . . . . . . . 37 6.2.6 Processing Rules for Hosts . . . . . . . . . . 34
7.1 Neighbor Solicitation Messages . . . . . . . . . . . . . . 37 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1.1 Sending Secure Neighbor Solicitations . . . . . . . . . . 37 7.1 CGA Addresses . . . . . . . . . . . . . . . . . . . .36
7.1.2 Receiving Secure Neighbor Solicitations . . . . . . . . . 37 7.2 Redirect Addresses . . . . . . . . . . . . . . . . . .36
7.2 Neighbor Advertisement Messages . . . . . . . . . . . . . 37 7.3 Advertised Prefixes . . . . . . . . . . . . . . . . .36
7.2.1 Sending Secure Neighbor Advertisements . . . . . . . . . . 37 7.4 Limitations . . . . . . . . . . . . . . . . . . . . .37
7.2.2 Receiving Secure Neighbor Advertisements . . . . . . . . . 38 8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 38
7.3 Other Requirements . . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . 40
8. Securing Router Discovery with SEND . . . . . . . . . . . 40 9.1 Threats to the Local Link Not Covered by SEND . . . .40
8.1 Router Solicitation Messages . . . . . . . . . . . . . . . 40 9.2 How SEND Counters Threats to NDP . . . . . . . . . . .40
8.1.1 Sending Secure Router Solicitations . . . . . . . . . . . 40 9.2.1 Neighbor Solicitation/Advertisement Spoofing . 41
8.1.2 Receiving Secure Router Solicitations . . . . . . . . . . 40 9.2.2 Neighbor Unreachability Detection Failure . . 41
8.2 Router Advertisement Messages . . . . . . . . . . . . . . 41 9.2.3 Duplicate Address Detection DoS Attack . . . . 41
8.2.1 Sending Secure Router Advertisements . . . . . . . . . . . 41 9.2.4 Router Solicitation and Advertisement Attacks 42
8.2.2 Receiving Secure Router Advertisements . . . . . . . . . . 41 9.2.5 Replay Attacks . . . . . . . . . . . . . . . . 42
8.3 Redirect Messages . . . . . . . . . . . . . . . . . . . . 41 9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 43
8.3.1 Sending Redirects . . . . . . . . . . . . . . . . . . . . 41 9.3 Attacks against SEND Itself . . . . . . . . . . . . .43
8.3.2 Receiving Redirects . . . . . . . . . . . . . . . . . . . 42 10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 45
8.4 Other Requirements . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
9. Co-Existence of SEND and non-SEND nodes . . . . . . . . . 43 Normative References . . . . . . . . . . . . . . . . . . . . 47
10. Performance Considerations . . . . . . . . . . . . . . . . 45 Informative References . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 49
11.1 Threats to the Local Link Not Covered by SEND . . . . . . 46 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
11.2 How SEND Counters Threats to Neighbor Discovery . . . . . 47 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 51
11.2.1 Neighbor Solicitation/Advertisement Spoofing . . . . . . . 47 C. Cache Management . . . . . . . . . . . . . . . . . . . . . . 52
11.2.2 Neighbor Unreachability Detection Failure . . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . 53
11.2.3 Duplicate Address Detection DoS Attack . . . . . . . . . . 48
11.2.4 Router Solicitation and Advertisement Attacks . . . . . . 49
11.2.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 49
11.2.6 Neighbor Discovery DoS Attack . . . . . . . . . . . . . . 49
11.3 Attacks against SEND Itself . . . . . . . . . . . . . . . 50
12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . 57
B. IPR Considerations . . . . . . . . . . . . . . . . . . . . 58
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 59
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . 63
1. Introduction 1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC 2461 [6]. IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7]
Nodes on the same link use NDP to discover each other's presence, to and 2462 [8]. Nodes on the same link use NDP to discover each
determine each other's link-layer addresses, to find routers, and to other's presence, to determine each other's link-layer addresses, to
maintain reachability information about the paths to active find routers, and to maintain reachability information about the
neighbors. NDP is used both by hosts and routers. Its functions paths to active neighbors. NDP is used both by hosts and routers.
include Neighbor Discovery (ND), Router Discovery (RD), Address Its functions include Neighbor Discovery (ND), Router Discovery (RD),
Autoconfiguration, Address Resolution, Neighbor Unreachability Address Autoconfiguration, Address Resolution, Neighbor
Detection (NUD), Duplicate Address Detection (DAD), and Redirection. Unreachability Detection (NUD), Duplicate Address Detection (DAD),
and Redirection.
RFC 2461 called for the use of IPsec for protecting the NDP messages. Original NDP specifications called for the use of IPsec for
However, it does not specify detailed instructions for using IPsec to protecting the NDP messages. However, the RFCs do not give detailed
secure NDP. It turns out that in this particular application, IPsec instructions for using IPsec to secure NDP. It turns out that in
can only be used with a manual configuration of security this particular application, IPsec can only be used with a manual
associations, due to chicken-and-egg problems in using IKE [22] [19]. configuration of security associations, due to chicken-and-egg
Furthermore, the number of such manually configured security problems in using IKE [20, 15]. Furthermore, the number of such
associations needed for protecting NDP can be very large [23], making manually configured security associations needed for protecting NDP
that approach impractical for most purposes. can be very large [21], making that approach impractical for most
purposes.
This document is organized as follows. Section 4 describes the This document is organized as follows. Section 4 describes the
overall approach to securing NDP. This approach involves the use of overall approach to securing NDP. This approach involves the use of
new NDP options to carry public-key based signatures. A new NDP options to carry public-key based signatures. A
zero-configuration mechanism is used for showing address ownership on zero-configuration mechanism is used for showing address ownership on
individual nodes; routers are certified by a trust anchor [11]. The individual nodes; routers are certified by a trust anchor [10]. The
formats, procedures, and cryptographic mechanisms for the formats, procedures, and cryptographic mechanisms for the
zero-configuration mechanism are described in a related specification zero-configuration mechanism are described in a related specification
[26]. [12].
Section 6 describes the mechanism for distributing certificate chains The required new NDP options are discussed in Section 5. Section 6
to establish an authorization delegation chain to a common trust describes the mechanism for distributing certificate chains to
anchor. The required new NDP options are discussed in Section 5. establish an authorization delegation chain to a common trust anchor.
Section 7 and Section 8 show how to apply these components to
securing Neighbor and Router Discovery.
Finally, Section 9 discusses the co-existence of secure and Finally, Section 8 discusses the co-existence of secure and
non-secure Neighbor Discovery on the same link, Section 10 discusses non-secure NDP on the same link and Section 9 discusses security
performance considerations, and Section 11 discusses security
considerations for Secure Neighbor Discovery. considerations for Secure Neighbor Discovery.
1.1 Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
"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 Addresses (CGAs) Cryptographically Generated Address (CGA)
A technique [26] [30] where the IPv6 address of a node is A technique [12] where the 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 defined in RFC 2462 [7] that assures that two IPv6 A mechanism that assures that two IPv6 nodes on the same link are
nodes on the same link are not using the same addresses. not using the same addresses.
Internet Control Message Protocol version 6 (ICMPv6) Internet Control Message Protocol version 6 (ICMPv6)
The IPv6 control signaling protocol. Neighbor Discovery is a part The IPv6 control signaling protocol. Neighbor Discovery Protocol
of ICMPv6. is a part of ICMPv6.
Neighbor Discovery Protocol (NDP) Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [6]. The IPv6 Neighbor Discovery Protocol [7, 8].
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 but ND.
Neighbor Unreachability Detection (NUD) Neighbor Unreachability Detection (NUD)
This mechanism defined in RFC 2461 [6] is used for tracking the This mechanism is used for tracking the reachability of neighbors.
reachability of neighbors.
Nonce Nonce
A random number generated by a node and used exactly once, and A random number generated by a node and used exactly once. In
never again. In SEND, nonces are used to ensure that a particular SEND, nonces are used to ensure that a particular advertisement is
advertisement is linked to the solicitation that triggered it. linked to the solicitation that triggered it.
Router Authorization Certificate Router Authorization Certificate
An X.509v3 [11] PKC certificate using the profile specified in An X.509v3 [10] PKC certificate using the profile specified in
Section 6.5.1. 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. the legacy RFC 2461 and RFC 2462 mechanisms.
Router Discovery (RD) Router Discovery (RD)
The Router Discovery function of the Neighbor Discovery Protocol The Router Discovery function of the Neighbor Discovery Protocol.
(NDP).
3. Neighbor and Router Discovery Overview 3. Neighbor and Router Discovery Overview
IPv6 Neighbor and Router Discovery have several functions. Many of The Neighbor Discovery Protocol has several functions. Many of these
these functions are overloaded on a few central message types, such functions are overloaded on a few central message types, such as the
as the ICMPv6 Neighbor Discovery 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.
In IPv6, many of the tasks traditionally preformed at lower the The main functions of NDP are the following.
layers, such as ARP, have been moved to the IP layer. As a
consequence, a set of unified mechanisms can be applied across link
layers, any introduced security mechanisms or other extensions can be
adopted more easily, and a clear separation of the roles between the
IP and link layer has been achieved.
The main functions of IPv6 Neighbor Discovery are the following.
o Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighboring nodes, both hosts and routers. NUD is
defined in Section 7.3 of RFC 2461 [6]. NUD is
security-sensitive, because an attacker could falsely claim that
reachability exists when it in fact does not.
o Duplicate Address Detection (DAD) is used for preventing address
collisions [7]. A 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 using the same address. Since the rules
forbid the use of an address until it has been found unique, no
higher layer traffic is possible until this procedure has been
completed. Thus, preventing attacks against DAD can help ensure
the availability of communications for the node in question.
o Address Resolution is similar to IPv4 ARP [18]. The Address
Resolution function resolves a node's IPv6 address to the
corresponding link-layer address for nodes on the link. Address
Resolution is defined in Section 7.2 of RFC 2461 [6], and it is
used for hosts and routers alike. Again, no higher level traffic
can proceed until the sender knows the hardware address of the
destination node or the next hop router. Note that like its
predecessor in ARP, IPv6 Neighbor Discovery does not check the
source link layer address against the information learned through
Address 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
from layer to layer.
o Address Autoconfiguration is used for automatically assigning
addresses to a host [7]. This allows hosts to operate without
explicit configuration related to IP connectivity. The Address
Autoconfiguration mechanism defined in [7] is stateless. To create
IP addresses, the hosts use any prefix information delivered to
them during Router Discovery, and then test the newly formed
addresses for uniqueness using the DAD procedure. A stateful
mechanism, DHCPv6 [24], provides additional Autoconfiguration
features. Router and Prefix Discovery and Duplicate Address
Detection have an effect on the Address Autoconfiguration tasks.
o The Redirect function is used for automatically redirecting hosts
to an alternate router. Redirect is specified in Section 8 of RFC
2461 [6]. It is similar to the ICMPv4 Redirect function [17].
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 [6]. 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 to the destination node directly.
Typically, address autoconfiguration and other tasks can not
proceed until suitable routers and prefixes have been found.
The Neighbor Discovery messages follow the ICMPv6 message format. o The Redirect function is used for automatically redirecting a host
They have ICMPv6 types from 133 to 137. The IPv6 Next Header value to a better first-hop router, or to inform hosts that a
for ICMPv6 is 58. The actual Neighbor Discovery message includes an destination is in fact a neighbor (i.e., on-link). Redirect is
NDP message header, consisting of an ICMPv6 header and ND specified in Section 8 of RFC 2461 [7].
message-specific data, and zero or more NDP options.
o Address Autoconfiguration is used for automatically assigning
addresses to a host [8]. This allows hosts to operate without
explicit configuration related to IP connectivity. The default
autoconfiguration mechanism is stateless. To create IP addresses,
the hosts use any prefix information delivered to them during
Router Discovery, and then test the newly formed addresses for
uniqueness. A stateful mechanism, DHCPv6 [23], provides
additional autoconfiguration features.
o Duplicate Address Detection (DAD) is used for preventing address
collisions [8], for instance during Address Autoconfiguration. A
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
using the same address. Since the rules forbid the use of an
address until it has been found unique, no higher layer traffic is
possible until this procedure has been completed. Thus,
preventing attacks against DAD can help ensure the availability of
communications for the node in question.
o The Address Resolution function resolves a node's IPv6 address to
the corresponding link-layer address for nodes on the link.
Address Resolution is defined in Section 7.2 of RFC 2461 [7], and
it is used for hosts and routers alike. Again, no higher level
traffic can proceed until the sender knows the hardware address of
the destination node or the next hop router. Note the source link
layer address is not checked against the information learned
through Address 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
from layer to layer.
o Neighbor Unreachability Detection (NUD) is used for tracking the
reachability of neighboring nodes, both hosts and routers. NUD is
defined in Section 7.3 of RFC 2461 [7]. NUD is
security-sensitive, because an attacker could falsely claim that
reachability exists when it in fact does not.
The NDP messages follow the ICMPv6 message format. All NDP functions
are realized using the Router Solicitation (RS), Router Advertisement
(RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and
Redirect messages. An actual NDP message includes an NDP message
header, consisting of an ICMPv6 header and ND message-specific data,
and zero or more NDP options. The NDP message options are formatted
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-->
The NDP message options are formatted in the Type-Length-Value
format.
All IPv6 NDP functions are realized using the following ICMPv6
messages:
ICMPv6 Type Message
------------------------------------
133 Router Solicitation (RS)
134 Router Advertisement (RA)
135 Neighbor Solicitation (NS)
136 Neighbor Advertisement (NA)
137 Redirect
The various functions are realized using these messages as follows:
o Router Discovery uses the RS and RA messages.
o Duplicate Address Detection uses the NS and NA messages.
o Address Autoconfiguration uses the NS, NA, RS, and RA messages.
o Address Resolution uses the NS and NA messages.
o Neighbor Unreachability Detection uses the NS and NA messages.
o Redirect uses the Redirect message.
The NDP messages are always meant to be used within a link, and never
intended to leak outside of it. The destination and source addresses
used in these messages are as follows:
o Neighbor Solicitation: The destination address is either the
Solicited-Node multicast address, a unicast address, or an anycast
address. The source address is either the unspecified address (in
DAD) or a unicast address assigned to the sending interface. In a
typical case, the source address is equal to the source address of
the outgoing packet, locally triggering the need to send the
solicitation.
o Neighbor Advertisement: The destination address is either a
unicast address or the link-scoped All-Nodes multicast address
[12]. The source address is a unicast address assigned to the
sending interface.
o Router Solicitation: The destination address is typically the
All-Routers multicast address [12]. The source address is either
the unspecified address or a unicast address assigned to the
sending interface. An unspecified source address does not have
any special semantics; it is just an optimization for startup.
o Router Advertisement: The destination address can be either a
unicast or the link-scoped All-Nodes multicast address [12]. The
source address is a link-local address assigned to the sending
interface.
o Redirect: This message is always sent to the source address of the
packet that triggered the Redirect. Hosts verify that the IP
source address of the Redirect is the same as the current
first-hop router for the specified ICMP Destination Address.
Rules in [12] dictate that anycast, or multicast addresses may not
be used as source addresses. If the source address is an
unspecified address, it is impossible to send a Redirect, since
the unspecified address is forbidden as the destination address.
Therefore, the destination address must always be a unicast
address.
The source address is a link-local address assigned to the sending
interface.
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, a set of new Neighbor Discovery
options introduced. They are used in to protect Neighbor and Router options is introduced. They are used in to protect NDP messages.
Discovery messages. This specification introduces these options, an This specification introduces these options, an authorization
authorization delegation discovery process, an address ownership delegation discovery process, an address ownership proof mechanism,
proof mechanism, and requirements for the use of these components for and requirements for the use of these components in NDP.
Neighbor Discovery.
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. messages to carry lengthy certificate chains. The receipt of a
protected Router Advertisement message for which no certificate
chain is available triggers this 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 or Router Advertisement is the "owner" of the
claimed address. A public-private key pair needs to be generated claimed address. A public-private key pair needs to be generated
by all nodes before they can claim an address. A new Neighbor by all nodes before they can claim an address. A new NDP option,
Discovery option, the CGA option, is used to carry the public key the CGA option, is used to carry the public key and associated
and associated parameters. parameters.
This specification also allows one to use non-CGA addresses and to This specification also allows one to use non-CGA addresses and to
use certificates to authorized their use. However, the details of use certificates to authorize their use. However, the details of
such use have been left for future work. such use have been left for future work.
o A new Neighbor Discovery option, the Signature option, is used to o A new NDP option, the Signature option, is used to protect all
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 are used to protect the integrity of the
messages and to authenticate the identity of their sender. The messages and to authenticate the identity of their sender. The
authority of a public key is established either with the authority of a public key is established either with the
authorization delegation process, using certificates, or through authorization delegation process, using certificates, or through
the address ownership proof mechanism, using CGAs, or both, the address ownership proof mechanism, using CGAs, or both,
depending on configuration and the type of the message protected. depending on configuration 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 used. Given that Neighbor and
Router Discovery messages are in some cases sent to multicast 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 messages are used in solicitation - advertisement pairs, they are
protected using the Nonce option. protected using the Nonce option.
5. Neighbor Discovery Options 5. Neighbor Discovery Protocol Options
The following new NDP options and mechanisms are REQUIRED to be
implemented by all SEND nodes:
o The CGA option MAY be present in all Neighbor Discovery messages,
and SHOULD be present in most cases.
o The Signature option is REQUIRED in all Neighbor Discovery
messages.
o The Nonce option is REQUIRED in all Neighbor Discovery
solicitations, and in all solicited advertisements.
o The Timestamp option is REQUIRED in all Neighbor Discovery
advertisements and Redirects.
o Proxy Neighbor Discovery is not supported by this specification;
it is planned to be specified in a future document.
5.1 Ordering of the new options
The ordering of the new options MUST obey the following rules:
The CGA option MUST appear before the Signature option.
The Nonce option SHOULD appear before the Timestamp option.
The Signature option MUST NOT be be followed CGA, Nonce, or
Timestamp options.
It is RECOMMENDED that the options appear in the following order: The options described in this section MUST be supported by all SEND
CGA, Nonce, Timestamp, Signature. nodes.
5.2 CGA Option 5.1 CGA Option
The CGA option allows the verification of the sender's CGA. The The CGA option allows the verification of the sender's CGA. The
format of the CGA option is described as follows. format of the CGA option is described as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Modifier | | Type | Length | Collision Cnt | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Collision Cnt | Reserved | | |
| Modifier |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Key Information . . Key Information .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Padding . . Padding .
skipping to change at page 13, line 27 skipping to change at page 11, line 48
The meaning of the fields is described as follows. 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, in units of 8 octets.
Modifier
A random number used in CGA generation. Its semantics are defined
in [26].
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 get values 0, 1 and 2. Its
semantics are defined in [26]. semantics are defined in [12].
Reserved Reserved
A 24-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
A random 128-bit number used in CGA generation. Its semantics are
defined in [12].
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 [11], encoded as represented as an ASN.1 type SubjectPublicKeyInfo [10], encoded as
described in Section 4 of [26]. described in Section 4 of [12].
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
former option MUST be the public key referred by the Key Hash former option MUST be the public key referred by the Key Hash
field in the latter option. Packets received with two different field in the latter option. Packets received with two different
keys MUST be silently discarded. Note that a future extension may keys 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, It begins after the ASN.1 encoding of the previous field has ends,
and continues to the end of the option, as specified by the Length and continues to the end of the option, as specified by the Length
field. field.
5.2.1 Processing Rules for Senders 5.1.1 Processing Rules for Senders
The CGA option MUST be present in all Neighbor Solicitation and
Advertisement messages, and in Router Solicitation messages not sent
with the unspecified source address. The CGA option MAY be present
in other messages.
A node sending a message using the CGA option MUST construct the A node sending a message using the CGA option MUST construct the
message as follows. message as follows.
The 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
[26]. The used public key is taken from configuration; typically [12]. The used public key is taken from configuration; typically
from a data structure associated with the source address. from a data structure associated with the source address. The
address MUST be constructed as specified in Section 4 of [12].
An address MUST be constructed as specified in Section 4 of [26]. In
the typical case, the address is constructed long before it is used.
Depending on the type of the message, this address appears in Depending on the type of the message, this address appears in
different places: different places:
Redirect Redirect
The address MUST be the source address of the message. The address MUST be the source address of the message.
Neighbor Solicitation Neighbor Solicitation
The address MUST be the Target Address for solicitations sent for The address MUST be the Target Address for solicitations sent for
the purpose of Duplicate Address Detection, and the source address the purpose of Duplicate Address Detection, and the source address
of the message otherwise. of the message 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, unless the The address MUST be the source address of the message. Note that
source address is the unspecified address. the CGA option is not used when the source address is the
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.2.2 Processing Rules for Receivers 5.1.2 Processing Rules for Receivers
Neighbor Solicitation and Advertisement messages without the CGA
option MUST be silently discarded. Router Solicitation messages
without the CGA option MUST be silently discarded, 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 configued to use CGA, it is REQUIRED If the interface has been configured to use CGA, the receiving
that the receiving node verifies the source address of the packet node MUST verify the source address of the packet using the
using the algorithm described in Section 5 of [26]. The inputs algorithm described in Section 5 of [12]. The inputs for the
for the algorithm are the contents of the Modifier, Collision Cnt, algorithm are the contents of the Collision Cnt, Modifier, and the
and the Key Information fields, the claimed address in the packet Key Information fields, the claimed address in the packet (as
(as discussed in the previous section), and the minimum acceptable discussed in the previous section), and the minimum acceptable Sec
Sec value. If the CGA verification is successful, the recipient value. If the CGA verification is successful, the recipient
proceeds with the cryptographically more time consuming check of proceeds with the cryptographically more time consuming check of
the signature. the signature.
Note that a receiver which does not support CGA or has not specified Note that a receiver which 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 CGA had been used on a packet. In such a case, the
CGA property of the address is simply left unverified. CGA property of the address is simply left unverified.
5.2.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 the public keys used in the
generation of the CGA address. The default SHOULD be 1024 bits. generation of the CGA address. 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. Any implementation should
follow prudent cryptographic practise in determining the follow prudent cryptographic practice in determining the
appropriate key lengths. appropriate key lengths.
5.3 Signature Option minSec
The minimum acceptable Sec value, if CGA verification is required
(see Section 2 in [12]). This parameter is intended to facilitate
future extensions and experimental work. Currently, the minSec
value SHOULD always be set to zero.
All nodes that support the sending of the CGA option MUST record the
following configuration information:
CGA parameters
Any information required to construct CGAs, including the used Sec
and Modifier values, and the CGA address itself.
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. Both trust anchor authentication and CGAs
can be used. The format of the Signature option is described in the can be used. The format of the Signature option is described in the
following: 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 | Pad Length | Reserved | | Type | Length | Pad Length | Reserved |
skipping to change at page 17, line 21 skipping to change at page 16, line 16
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 contains the signature constructed using
the sender's private key, over the the following sequence of the sender's private key, over the the following sequence of
octets: octets:
1. The 128-bit CGA Type Tag [26] value for SEND, 0xXXXX XXXX XXXX 1. The 128-bit CGA Type Tag [12] value for SEND, 0x086F CA5E 10B2
XXXX XXXX XXXX XXXX XXXX (To be generated randomly). 00C9 9C8C E001 6427 7C08 (generated randomly).
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, i.e., the Type, Code, and Checksum 4. The 32-bit ICMP header.
fields.
5. The Neighbor Discovery message header, i.e., the Reserved 5. The NDP message header.
field in the Router Solicitation message, the Cur Hop Limit,
M, O, Reserved, Router Lifetime, Reachable Time, and Retrans
Timer fields in the Router Advertisement message, Reserved and
Target Address fields in the Neighbor Solicitation message, R,
S, O, Reserved, and Target Address fields in the Neighbor
Advertisement message, and Reserved, Target Address, and
Destination Address fields in the Redirect message.
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 is constructed using the RSA algorithm and MUST be
encoded as private key encryption in PKCS#1 format [15]. The encoded as private key encryption in PKCS#1 format [13]. The
signature value is computed with the RSASSA-PKCS1-v2_1 algorithm signature value is computed with the RSASSA-PKCS1-v1_5 algorithm
and SHA-1 hash as defined in [15]. 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).
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.3.1 Processing Rules for Senders 5.2.1 Processing Rules for Senders
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages MUST contain the Signature option. Router
Solicitation messages not sent with the unspecified source address
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:
o The message is constructed in its entirety. o The message is constructed in its entirety, without the Signature
option.
o The Signature option is added as the last option in the message. o The Signature option is added as the last option in the message.
o For the purpose of constructing a signature, the following data o For the purpose of constructing a signature, the following data
items are concatenated: items are concatenated:
* The 128-bit CGA Type Tag. * The 128-bit CGA Type Tag.
* The source address of the message. * The source address of the message.
* The destination address of the message. * The destination address of the message.
* 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.3.2 Processing Rules for Receivers 5.2.2 Processing Rules for Receivers
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages without the Signature option MUST be silently
discarded. Router Solicitation messages without the Signature option
MUST be silently discarded, 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 Signature option MUST appear as the last 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 preceeding CGA option, or one known by either one learned from a preceding CGA option, or one known by
other means. other means.
o TheDigital Signature field MUST have correct encoding, and do 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.
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 drop packets also otherwise, discarded. The receiver MAY silently discard packets also otherwise,
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.3.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
record the following configuration information for each separate record the following configuration information for each separate NDP
Neighbor Discovery Protocol 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.5. 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 [26]. The sender may claim additional authority described in [12]. 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 of the allowed trust anchor(s), if authorization The public keys and names of the allowed trust anchor(s), if
method is not set to CGA. authorization method is not set to CGA.
minSec
The minimum acceptable Sec value, if CGA verification is required
(see Section 2 in [26]). This parameter is intended to facilitate
future extensions and experimental work. Currently, the minSec
value SHOULD always be set to zero.
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 is not used. This
flag may be per interface or per node. flag may be per interface or per node.
CGA parameters 5.2.4 Performance Considerations
Optionally any information required to construct CGAs, including The construction and verification of this option is computationally
the used Sec and Modifier values, and the CGA address itself. expensive. In the NDP context, however, the hosts typically have the
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
communicate.
5.4 Timestamp and Nonce options Routers are required to perform a larger number of operations,
particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of required signature
operations is on the order of a few dozen ones per second, some of
which can be precomputed as discussed below. A large number of
router solicitations may cause higher demand for performing
asymmetric operations, although RFC 2461 limits the rate at which
responses to solicitations can be sent.
5.4.1 Timestamp Option Signatures can be precomputed for unsolicited (multicast) Neighbor
and Router Advertisements, if the timing of such future
advertisements is known. Typically, solicited advertisements are
sent to the unicast address from which the solicitation was sent.
Given that the IPv6 header is covered by the signature, it is not
possible to precompute solicited-for advertisements.
5.3 Timestamp and Nonce options
5.3.1 Timestamp Option
The purpose of the Timestamp option is to ensure that unsolicited The purpose of the Timestamp option is to ensure that unsolicited
advertisements and redirects have not been replayed. The format of advertisements and redirects have not been replayed. The format of
the Timestamp 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 +
skipping to change at page 21, line 28 skipping to change at page 20, line 42
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.4.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 ensure 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 receiving same
node. The format of the Nonce option is as described in the node. The format of this option is described in the following:
following:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce ... | | Type | Length | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
. . . .
. . . .
| | | |
skipping to change at page 22, line 15 skipping to change at page 21, line 32
Length Length
The length of the option, in units of 8 octets. The length of the option, 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.
5.4.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. All solicited-for
announcements MUST include a Nonce, copying the nonce value from the advertisements MUST include a Nonce, copying the nonce value from the
received solicitation. When sending a solication, the sender MUST received solicitation. When sending a solicitation, the sender MUST
store the nonce internally so that it can recognize any replies store the nonce internally so that it can recognize any replies
containing that particular nonce. containing that particular nonce.
All NDP messages MUST include a Timestamp. Senders SHOULD set the All solicitation, advertisement, and redirect messages MUST include a
Timestamp field to the current time, according to their real time Timestamp. Senders SHOULD set the Timestamp field to the current
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. The receiver MUST be SHOULD precede the Timestamp option in order.
prepared to receive them in any order, as per RFC 2461 [6] Section 9.
5.4.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-for advertisement or not. A system may
implement the distinction in various means. Section 5.4.4.1 defines implement the distinction in various means. Section 5.3.4.1 defines
the processing rules for solicited-for advertisements. Section the processing rules for solicited-for advertisements. Section
5.4.4.2 defines the processing rules for all other messages. 5.3.4.2 defines the processing rules for all other messages.
An implementation may utilize some mechanism such as a timestamp In addition, the following rules apply in any case:
o Messages received without the Timestamp option MUST be silently
discarded.
o Solicitation messages received without the Nonce option MUST be
silently discarded.
o Advertisements sent to a unicast destination address without a
Nonce option MUST be silently discarded.
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 filling very large number of nodes on the same link, or when a cache
attack is in progress, it is possible that the cache holding the most filling attack is in progress, it is possible that the cache
recent timestamp per sender becomes full. In this case the node MUST holding the most recent timestamp per sender becomes full. In
remove some entries from the cache or refuse some new requested this case the node MUST remove some entries from the cache or
entries. The specific policy as to which entries are preferred over refuse some new requested entries. The specific policy as to
the others is left as an implementation decision. However, typical which entries are preferred over the others is left as an
policies may prefer existing entries over new ones, CGAs with a large implementation decision. However, typical policies may prefer
Sec value over smaller Sec values, and so on. The issue is briefly existing entries over new ones, CGAs with a large Sec value over
discussed in Appendix C. smaller Sec values, and so on. The issue is briefly discussed in
Appendix C.
5.4.4.1 Processing solicited-for advertisements o The receiver MUST be prepared to receive the Timestamp and Nonce
options in any order, as per RFC 2461 [7] Section 9.
The receiver MUST verify that it has recently send a matching 5.3.4.1 Processing solicited-for advertisements
solicitation, and that the received advertisement does contain a copy
of the Nonce sent in the solicitation.
If the message does not contain a Nonce option, it MAY be considered The receiver MUST verify that it has recently sent a matching
as a non-solicited-for announcement, and processed according to solicitation, and that the received advertisement contains a copy of
Section 5.4.4.2. the Nonce sent in the solicitation.
If the message does contain a Nonce option, but the Nonce value is If the message contains a Nonce option, but the Nonce value is not
not recognized, the message MUST be silently dropped. recognized, the message MUST be silently discarded.
Otherwise, if the message does not contain a Nonce option, it MAY be
considered as a non-solicited-for advertisement, and processed
according 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.4.4.2 specified in Section 5.3.4.2
5.4.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,
and an allowed clock drift parameter. The recommended default value a "fuzz factor" for comparisons, and an allowed clock drift
for the allowed Delta is 3,600 seconds (1 hour) and for clock dritf parameter. The recommended default value for the allowed Delta is
3,600 seconds (1 hour), for fuzz factor 1 second, and for clock drift
1% (0.01). 1% (0.01).
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 per each peer:
The receive time of the last received, acepted SEND message. This The receive time of the last received, accepted SEND message.
is called RDlast. This is called RDlast.
The time stamp in the last received, accepted SEND message. This The time stamp in the last received, accepted SEND message. This
is called TSlast. is called TSlast.
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 receival 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 that should be responded to 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 difference 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 > TSlast + (RDnew - RDlast) x (1 - drift) TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
o If TSnew < TSlast, which is possible if packets arrive rapidly and o If TSnew < TSlast, which is possible if packets arrive rapidly and
out of order, TSlast MUST NOT be updated, i.e., the stored TSlast out of order, TSlast MUST NOT be updated, i.e., the stored TSlast
for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD
be updated. Independent on whether TSlast is updated or not, be updated. Independent on whether TSlast is updated or not,
RDlast is updated in any case. RDlast is updated in any case.
5.5 Proxy Neighbor Discovery
The Target Address in Neighbor Advertisement is required to be equal
to the source address of the packet, except in the case of proxy
Neighbor Discovery. Proxy Neighbor Discovery is not supported by
this specification; it is planned to be specified in a future
document.
6. Authorization Delegation Discovery 6. Authorization Delegation Discovery
Several protocols, including the IPv6 Neighbor Discovery Protocol, Several protocols (NDP included) allow a node to automatically
allow a node to automatically configure itself based on information configure itself based on information it learns shortly after
it learns shortly after connecting to a new link. It is particularly connecting to a new link. It is particularly easy to configure
easy to configure "rogue" routers on an unsecured link, and it is "rogue" routers on an unsecured link, and it is particularly
particularly difficult for a node to distinguish between valid and difficult for a node to distinguish between valid and invalid sources
invalid sources of information, when the node needs this information of information, when the node needs this information before being
before being able to communicate with nodes outside of the link. able to communicate with nodes outside of the link.
Since the newly-connected node cannot communicate off-link, it can Since the newly-connected node cannot communicate off-link, it cannot
not be responsible for searching information to help validating the be responsible for searching information to help validating 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, which is already connected to beyond the
link, can (if necessary) communicate with off-link nodes and link, can (if necessary) communicate with off-link nodes and
construct such a certificate chain. construct such a certificate chain.
The Secure Neighbor Discovery Protocol introduces two new ICMPv6 The Secure Neighbor Discovery Protocol mandates a certificate format
messages that are used between hosts and routers to allow the host to and introduces two new ICMPv6 messages that are used between hosts
learn a certificate chain with the assistance of the router. Where and routers to allow the host to learn a certificate chain with the
hosts themselves are certified by a trust anchor, these messages MAY assistance of the router.
also optionally be used between hosts to acquire the peer's
certificate chain. However, the details of such usage are left for 6.1 Certificate Format
future specification.
The certificate chain of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization chains are not a common practice
in the Internet at the time this specification is being written, the
chain MUST consist of standard Public Key Certificates (PKC, in the
sense of [18]). The certificate chain MUST start from the identity
of a trust anchor that is shared by the host and the router. This
allows the host to anchor trust for the router's public key in the
trust anchor. Note that there MAY be multiple certificates issued by
a single trust anchor.
6.1.1 Router Authorization Certificate Profile
Router Authorization Certificates be X.509v3 certificates, as defined
in RFC 3280 [10], and MUST contain at least one instance of the X.509
extension for IP addresses, as defined in [11]. The parent
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
ISP) that configured the original IP address space block for the
router in question, or delegated the right to do so for someone. The
certificates for intermediate delegating authorities MUST contain
X.509 IP address extension(s) for subdelegations. The router's
certificate is signed by the delegating authority for the prefixes
the router is authorized to to advertise.
The X.509 IP address extension MUST contain at least one
addressesOrRanges element. This element MUST contain an
addressPrefix element with an IPv6 address prefix for a prefix the
router or the intermediate entity is authorized to advertise. If the
entity is allowed to route any prefix, the used IPv6 address prefix
is the null prefix, 0/0. The addressFamily element of the containing
IPAddrBlocks sequence element MUST contain the IPv6 Address Family
Identifier (0002), as specified in [11] for IPv6 prefixes. Instead
of an addressPrefix element, the addressesOrRange element MAY contain
an addressRange element for a range of prefixes, if more than one
prefix is authorized. The X.509 IP address extension MAY contain
additional IPv6 prefixes, expressed either as an addressPrefix or an
addressRange.
A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the
addressPrefix or addressRange entries in the router's certificate are
contained within the address ranges in the delegating authority's
certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority's certificate. If
an addressPrefix or addressRange is not contained within the
delegating authority's prefixes or ranges, the client MAY attempt to
take an intersection of the ranges/prefixes, and use that
intersection. If the addressPrefix in the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case the
intersection is the parent prefix or range.) If the resulting
intersection is empty, the client MUST NOT accept the certificate.
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.
The client also needs to perform validation of advertised prefixes as
discussed in Section 7.3.
Since it is possible that some PKC certificates used with SEND do not
immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default
configuration that requires rigorous prefix and range checks.
The following is an example of a certificate chain. Suppose that
ispgroup.com is the trust anchor. The host has this certificate for
it:
Certificate 1:
Issuer: isp_group.com
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group.com
Extensions:
IP address delegation extension:
Prefixes: P1, ..., Pk
... possibly other extensions ...
... other certificate parameters ...
When the host attaches then to a linked served by
router_x.isp_foo.com, it receives the following certificate chain:
Certificate 2:
Issuer: isp_group.com
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo.com
Extensions:
IP address delegation extension:
Prefixes: Q1, ..., Qk
... possibly other extensions ...
... other certificate parameters ...
Certificate 3:
Issuer: isp_foo.com
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: router_x.isp_foo.com
Extensions:
IP address delegation extension:
Prefixes R1, ..., Rk
... possibly other extensions ...
... other certificate parameters ...
When processing the three certificates, the usual RFC 3280
certificate path validation is performed, for instance by checking
for revoked certificates. In addition, the IP addresses in the
delegation extension must be subsumed by the IP addresses in the
delegation extension in the issuer's certificate. So in this
example, R1, ..., Rs must be subsumed by Q1,...,Qr, and Q1,...,Qr
must be subsumed by 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
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 as an answer to the DCS message.
It MAY be periodically sent to the link-scoped All-Nodes multicast These messages are separate from the rest of Neighbor and Router
address. These messages are separate from the rest of Neighbor and Discovery, in order to reduce the effect of the potentially
Router 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.
6.1 Delegation Chain Solicitation Message Format Where hosts themselves are certified by a trust anchor, these
messages MAY also optionally be used between hosts to acquire the
peer's certificate chain. However, the details of such usage are
left for future specification.
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 quickly. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved | | Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
Source Address Source Address
An IP address assigned to the sending interface, or the A link-local unicast address assigned to the sending interface,
unspecified address if no address is assigned to the sending or the unspecified address if no address is assigned to the
interface. sending interface.
Destination Address Destination Address
Typically the All-Routers multicast address, the Solicited-Node Typically the All-Routers multicast address, the Solicited-Node
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
skipping to change at page 26, line 41 skipping to change at page 28, line 16
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 [8]. 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, though. Its purpose is 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.
skipping to change at page 27, line 15 skipping to change at page 28, line 38
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.3. If there are more than Encoded X.501 Name; see Section 6.2.3. If there is more than
one Trust Anchor options, 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 types of Trust Anchors.
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. and continue processing the message. All included options MUST
have a length that is greater than zero.
6.2 Delegation Chain Advertisement Message Format ICMP length (derived from the IP length) MUST be 8 or more octets.
Routers send out Delegation Chain Advertisement messages 6.2.2 Delegation Chain Advertisement Message Format
periodically, or in response to a Delegation Chain Solicitation.
Routers send out Delegation Chain Advertisement messages in response
to a Delegation Chain Solicitation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component | | Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ... | Options ...
+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-
IP Fields: IP Fields:
Source Address Source Address
MUST be a unicast address assigned to the interface from which A link-local unicast address assigned to the interface from
this message is sent. which this message is sent. Note that routers may use multiple
addresses, and therefore this address not sufficient for the
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
skipping to change at page 28, line 19 skipping to change at page 30, line 4
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 [8]. The ICMP checksum [9].
Identifier Identifier
A 16-bit unsigned integer field, acting as an identifier to A 16-bit unsigned integer field, acting as an identifier to
help matching advertisements to solicitations. The Identifier help matching advertisements to solicitations. The Identifier
field MUST be zero for unsolicited advertisements and MUST NOT field MUST be zero for advertisements sent to the All-Nodes
be zero for solicited advertisements. multicast address and MUST NOT be zero for others.
Component Component
A 16-bit unsigned integer field, used for informing the A 16-bit unsigned integer field, used for informing the
receiver which certificate is being sent, and how many are receiver which certificate is being sent, and how many are
still left to be sent in the whole chain. still left to be sent in the whole chain.
A single advertisement MUST be broken into separately sent A single advertisement MUST be broken into separately sent
components if there is more than one Certificate option, in components if there is more than one Certificate option, in
order to avoid excessive fragmentation at the IP layer. Unlike order to avoid excessive fragmentation at the IP layer. Unlike
skipping to change at page 29, line 18 skipping to change at page 30, line 51
An unused field. It MUST be initialized to zero by the sender An unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
Valid Options: Valid Options:
Certificate Certificate
One certificate is provided in each Certificate option, to One certificate is provided in each Certificate option, to
establish a (part of a) certificate chain to a trust anchor. establish a (part of a) certificate chain to a trust anchor.
The certificate of the trust anchor itself SHOULD NOT be
included.
Trust Anchor Trust Anchor
Zero or more Trust Anchor options may be included to help Zero or more Trust Anchor options may be included to help
receivers decide which advertisements are useful for them. If receivers decide which advertisements are useful for them. If
present, these options MUST appear in the first component of a present, these options MUST appear in the first component of a
multi-component advertisement. multi-component advertisement.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. and continue processing the message. All included options MUST
have a length that is greater than zero.
6.3 Trust Anchor Option ICMP length (derived from the IP length) MUST be 8 or more octets.
The format of the Trust Anchor option is as described in the 6.2.3 Trust Anchor Option
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: Where the fields are as follows:
skipping to change at page 30, line 31 skipping to change at page 32, line 21
When the Name Type field is set to 1, the Name field contains a When the Name Type field is set to 1, the Name field contains a
DER encoded X.501 certificate Name, represented and encoded DER encoded X.501 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
[11] Section 4.2.1.7 apply. [10] Section 4.2.1.7 apply.
All systems MUST implement support the DER Encoded X.501 Name. All systems MUST implement support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type. Implementations MAY support the FQDN name type.
6.4 Certificate Option 6.2.4 Certificate Option
The format of the certificate option is as described in the The format of the certificate option is described in the following:
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: Where the fields are as follows:
skipping to change at page 31, line 24 skipping to change at page 33, line 15
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
The number of padding octets beyond the end of the Certificate The number of padding octets beyond the end of the Certificate
field but within the length specified by the Length field. Padding field but within the length specified by the Length field.
octets MUST be set to zero by senders and ignored by receivers. Padding octets MUST be set to zero by senders and ignored by
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 [11], as described in Section contains an X.509v3 certificate [10], as described in Section
6.5.1. 6.1.1.
6.5 Router Authorization Certificate Format
The certificate chain of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization chains are not a common practice
in the Internet at the time this specification is being written, the
chain MUST consist of standard Public Key Certificates (PKC, in the
sense of [21]). The certificates chain MUST start from the identity
of a trust anchor that is shared by the host and the router. This
allows the host to anchor trust for the router's public key in the
trust anchor. Note that there MAY be multiple certificates issued by
a single trust anchor.
6.5.1 Router Authorization Certificate Profile
Router Authorization Certificates be X.509v3 certificates, as defined
in RFC 3280 [11], and MUST contain at least one instance of the X.509
extension for IP addresses, as defined in [13]. The parent
certificates in the certificate chain MUST contain one or more X.509
IP address extensions, back up to the delegating authority (the
Regional Address Registry or IANA) that delegated the original IP
address space block. The certificates for intermediate delegating
authorities MUST contain X.509 IP address extension(s) for
subdelegations. The router's certificate is signed by the delegating
authority for the prefixes the router is authorized to to advertize.
The X.509 IP address extension MUST contain at least one
addressesOrRanges element that contains an addressPrefix element with
an IPv6 address prefix for a prefix the router or the intermediate
entity is authorized to advertize. If the entity is allowed to route
any prefix, the used IPv6 address prefix is the null prefix, 0/0.
The addressFamily element of the containing IPAddrBlocks sequence
element MUST contain the IPv6 AFI (0002), as specified in [13] for
IPv6 prefixes. Instead of an addressPrefix element, the
addressesOrRange element MAY contain an addressRange element for a
range of prefixes, if more than one prefix is authorized. The X.509
IP address extension MAY contain additional IPv6 prefixes, expressed
either as an addressPrefix or an addressRange.
A SEND node receiving a Router Authorization Certificate MUST first
check whether the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the
addressPrefix or addressRange entries in the router's certificate are
contained within the address ranges in the delegating authority's
certificate, and whether the addressPrefix entries match any
addressPrefix entries in the delegating authority's certificate. If
an addressPrefix or addressRange is not contained within the
delegating authority's prefixes or ranges, the client MAY attept to
take an intersection of the ranges/prefixes, and use that
intersection. If the addressPrefix in the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case the
intersection is the parent prefix or range.) If the resulting
intersection is empty, the client MUST NOT accept the certificate.
The above check SHOULD be done for all certificates in the chain
received through DCA messages. If any of the checks fail, the client
MUST NOT accept the certificate.
Since it is possible that some PKC certificates used with SEND do not 6.2.5 Processing Rules for Routers
immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default
configuration that requires rigorious prefix and range checks.
6.6 Processing Rules for Routers
Routers SHOULD possess a key pair and a certificate from at least one Routers SHOULD possess a key pair and a certificate from at least one
certificate authority. 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 satisfy all of the following
validity checks: validity checks:
o The IP Hop Limit field MUST have a value of 255, i.e., the packet o All requirements listed in Section 6.2.1 are fulfilled.
could not possibly have been forwarded by a router.
o If the message includes an IP Authentication Header, the message o If the message includes an IP Authentication Header, the message
authenticates correctly. authenticates correctly.
o ICMP Checksum is valid.
o ICMP Code is 0.
o ICMP length (derived from the IP length) is 8 or more octets.
o Identifier field is non-zero.
o All included options have a length that is greater than zero.
The contents of the Reserved field, and of any unrecognized options, The contents of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new options; may specify the contents of the Reserved field or add new options;
backward-incompatible changes may use different Code values. The backward-incompatible changes may use different Code values. The
contents of any defined options that are not specified to be used contents of any defined options that are not specified to be used
with Router Solicitation messages MUST be ignored and the packet with Router Solicitation messages MUST be ignored and the packet
processed in the normal manner. The only defined option that may processed in the normal manner. The only defined option that may
appear is the Trust Anchor option. A solicitation that passes the appear is the Trust Anchor option. A solicitation that passes the
validity checks is called a "valid solicitation". validity checks is called a "valid solicitation".
Routers MAY send unsolicited Delegation Chain Advertisements for Routers SHOULD send advertisements in response to valid solicitations
their configured trust anchor(s). When such advertisements are sent, received on an advertising interface. If the source address in the
their timing MUST follow the rules given for Router Advertisements in solicitation was the unspecified address, the router MUST send the
RFC 2461 [6]. The only defined options that may appear are the response to the link-scoped All-Nodes multicast address. If the
Certificate and Trust Anchor options. At least one Certificate option source address was a unicast address, the router MUST send the
MUST be present. Router SHOULD also include at least one Trust response to the Solicited-Node multicast address corresponding to the
Anchor option to indicate the trust anchor on which the Certificate source address. Routers SHOULD NOT send Delegation Chain
is based. Advertisements more than MAX_DCA_RATE times within a second. When
there are more solicitations than this, the router SHOULD send the
In addition to sending periodic, unsolicited advertisements, a router response to the All-Nodes multicast address regardless of the source
sends advertisements in response to valid solicitations received on address that appeared in the solicitation.
an advertising interface. If the source address in the solicitation
was the unspecified address, the router MUST send the response to the
link-scoped All-Nodes multicast address. If the source address was a
unicast address, the router MUST send the response to the
Solicited-Node multicast address corresponding to the source address.
In a solicited-for advertisement, the router SHOULD include suitable In an advertisement, the router SHOULD include suitable Certificate
Certificate options so that a delegation chain to the solicited trust options so that a delegation chain to the solicited trust anchor can
anchor can be established. The anchor is identified by the Trust be established. The anchor is identified by the Trust Anchor option.
Anchor option. If the Trust Anchor option is represented as a DER If the Trust Anchor option is represented as a DER Encoded X.501
Encoded X.501 Name, then the Name must be equal to the Subject field Name, then the Name must be equal to the Subject field in the
in the anchor's certificate. If the Trust Anchor option is anchor's certificate. If the Trust Anchor option is represented as
represented as an FQDN, the FQDN must be equal to an FQDN in the an FQDN, the FQDN must be equal to an FQDN in the subjectAltName
subjectAltName field of the anchor's certificate. The router SHOULD field of the anchor's certificate. The router SHOULD include the
include the Trust Anchor option(s) in the advertisement for which the Trust Anchor option(s) in the advertisement for which the delegation
delegation chain was found. chain was found.
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.
Rate limiting of Delegation Chain Advertisements is performed as 6.2.6 Processing Rules for Hosts
specified for Router Advertisements in RFC 2461 [6].
6.7 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 posses a certificate from the above mentioned
certificate authority. 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 satisfy all of the following
validity checks: validity checks:
o IP Source Address MUST be a unicast address. Note that routers o All requirements listed in Section 6.2.2 are fulfilled.
may use multiple addresses, and therefore this address not
sufficient for the unique identification of routers.
o IP Destination Address MUST be either the link-scoped All-Nodes
multicast address or the Solicited-Node multicast address
corresponding to one of the unicast addresses assigned to the
host.
o The IP Hop Limit field MUST have a value of 255, i.e., the packet
could not possibly have been forwarded by a router.
o If the message includes an IP Authentication Header, the message o If the message includes an IP Authentication Header, the message
authenticates correctly. authenticates correctly.
o ICMP Checksum is valid.
o ICMP Code is 0.
o ICMP length (derived from the IP length) is 16 or more octets.
o All included options have a length that is greater than zero.
The contents of the Reserved field, and of any unrecognized options, The contents of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol MUST be ignored. Future, backward-compatible changes to the protocol
may specify the contents of the Reserved field or add new options; may specify the contents of the Reserved field or add new options;
backward-incompatible changes may use different Code values. The backward-incompatible changes may use different Code values. The
contents of any defined options that are not specified to be used contents of any defined options that are not specified to be used
with Delegation Chain Advertisement messages MUST be ignored and the with Delegation Chain Advertisement messages MUST be ignored and the
packet processed in the normal manner. The only defined options that packet processed in the normal manner. The only defined options that
may appear are the Certificate and Trust Anchor options. An may appear are the Certificate and Trust Anchor options. An
advertisement that passes the validity checks is called a "valid advertisement that passes the validity checks is called a "valid
advertisement". 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 certificates chains SHOULD be verified, as defined in Section The certificate chains SHOULD be verified, as defined in Section 6.1,
6.5, before storing them. Routers are required to send the before storing them. Routers MUST send the certificates one by one,
certificates one by one, starting from the trust anchor end of the starting from the trust anchor end of the chain. Except for
chain. Except for temporary purposes to allow for message loss and temporary purposes to allow for message loss and reordering, hosts
reordering, hosts SHOULD NOT store certificates received in a SHOULD NOT store certificates received in a Delegation Chain
Delegation Chain Advertisement unless they contain a certificate Advertisement unless they contain a certificate which can be
which can be immediately verified either to the trust anchor or to a immediately verified either to the trust anchor or to a certificate
certificate which has been verified earlier. which has been verified earlier.
Note that it may be useful to cache this information and implied Note that it may be useful to cache this information and implied
verification results for use over multiple attachments to the verification results for use over multiple attachments to the
network. network.
When an interface becomes enabled, a host may be unwilling to wait The host has a need to retrieve a delegation chain when a Router
for the next unsolicited Delegation Chain Advertisement. To obtain Advertisement has been received with a public key that is not stored
such advertisements quickly, a host MAY transmit up to in the hosts' cache of certificates, or there is no authorization
MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each delegation chain to the host's trust anchor. In these situations,
separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation the host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain
Chain Solicitations MAY be sent after any of the following events: Solicitation messages, each separated by at least DCS_INTERVAL
seconds.
o The interface is initialized at system startup time.
o The interface is reinitialized after a temporary interface failure
or after being temporarily disabled by system management.
o The system changes from being a router to being a host, by having
its IP forwarding capability turned off by system management.
o The host attaches to a link for the first time.
o A movement has been indicated by lower layers or has been inferred
from changed information in a Router Advertisement.
o The host re-attaches to a link after being detached for some time.
o A Router Advertisement has been received with a public key that is
not stored in the hosts' cache of certificates, or there is no
authorization delegation chain to the host's trust anchor.
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 it 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 left for
a future specification. a future specification.
Delegation Chain Solicitations SHOULD be rate limited and timed
similarly with Router Solicitations, as specified in RFC 2461 [6].
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 11.3). mechanism harder (see Section 9.3).
7. Securing Neighbor Discovery with SEND
This section describes how to use the mechanisms from Section 5,
Section 6, and the reference [26] in order to provide security for
Neighbor Discovery.
There is no requirement that nodes use both Secure Neighbor Discovery
(as described in this Section) and Secure Router Discovery (as
described in Section 8. They MAY be used indepedently.
7.1 Neighbor Solicitation Messages
All Neighbor Solicitation messages are protected with SEND.
7.1.1 Sending Secure Neighbor Solicitations
Secure Neighbor Solicitation messages are sent as described in RFC
2461 and 2462, with the additional requirements as listed in the
following:
All Neighbor Solicitation messages sent MUST contain the Nonce,
Timestamp, and Signature options, and MAY contain the CGA option.
The Signature option MUST be constructed with the sender's key
pair, using the configured authorization method(s), and if
applicable, using the trust anchor and/or minSec value as
configured.
7.1.2 Receiving Secure Neighbor Solicitations
Received Neighbor Solicitation messages are processed as described in 7. Addressing
RFC 2461 and 2462, with the additional SEND-related requirements as
listed in the following:
Neighbor Solicitation messages received without the Nonce, 7.1 CGA Addresses
Timestamp, or Signature option MUST be silently discarded. The
Signature option MUST be constructed with the expected
authorization method(s), the used key being within the configured
minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value.
7.2 Neighbor Advertisement Messages Nodes that use stateless address autoconfiguration, SHOULD generate a
new CGA as specified in Section 4 of [12] for each new
autoconfiguration run. The nodes MAY continue to use the same public
key and modifier, and start the process from Step 4.
All Neighbor Advertisement messages are protected with SEND. By default, a SEND-enabled node SHOULD use only CGAs as its own
addresses. Other types of addresses MAY be used in testing,
diagnostics or other purposes. However, this document does not
describe how to choose between different types of addresses for
different communications. A dynamic selection can be provided by an
API, such as the one defined in [22].
7.2.1 Sending Secure Neighbor Advertisements 7.2 Redirect Addresses
Secure Neighbor Advertisement messages are sent as described in RFC
2461 and 2462, with the additional requirements as listed in the
following:
All Neighbor Advertisement messages sent MUST be sent with the If the Target Address and Destination Address fields in the ICMP
Timestamp and Signature options and MAY be sent with the CGA Redirect message are equal, then this message is used to inform hosts
option. The Signature option MUST be constructed with the sender's that a destination is in fact a neighbor. In this case the receiver
key pair, setting the authorization method and additional MUST verify that the given address falls within the range defined by
information as configured. the router's certificate. Redirect messages failing this check MUST
be silently discarded.
Neighbor Advertisements sent in response to a Neighbor Note that RFC 2461 rules prevent a bogus router from sending a
Solicitation MUST additionally contain a copy of the Nonce option Redirect message when the host is not using the bogus router as a
included in the solicitation. default router.
7.2.2 Receiving Secure Neighbor Advertisements 7.3 Advertised Prefixes
Received Neighbor Advertisement messages are processed as described The router's certificate defines the address range(s) that it is
in RFC 2461 and 2462, with the additional SEND-related requirements allowed to advertise. Upon processing a Prefix Information option
as listed in the following: 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 MUST be silently discarded.
Any eighbor Advertisement messages received without the Timestamp Nodes SHOULD use one of the certified prefixes for stateless
or Signature options MUST be silently discarded. The Signature autoconfiguration. If none of the advertised prefixes match, then
option MUST be constructed with the expected authorization either there is a configuration problem or the advertising router is
method(s), the used key being within the configured minimum (and an attacker, and the host MUST use a different advertising router as
maximum) allowable key size, and if applicable, using an its default router (if available). If the node is performing
acceptable trust anchor and/or minSec value. 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.
Received Neighbor Advertisements sent to a unicast destination In any case, the user should inform the network operator upon
address without a Nonce option MUST be silently discarded. receiving an address or prefix outside the certified range, since
this is either a misconfiguration or an attack.
7.3 Other Requirements If the network operator wants to constrain which routers support
particular prefixes, routers SHOULD be configured with certificates
having prefixes listed in the prefix extension. Routers so
configured MUST advertise exactly the prefixes for which they are
certified.
Upon receiving a message for which the receiver has no certificate Network operators that do not want to constrain particular routers to
chain to a trust anchor, the receiver MAY use Authorization specific prefixes SHOULD configure routers with certificates
Delegation Discovery to learn the certificate chain of the peer. containing either the null prefix or no prefix extension at all.
Nodes that use stateless address autoconfiguration, SHOULD generate a 7.4 Limitations
new CGA as specified in Section 4 of [26] for each new
autoconfiguration run. The nodes MAY continue to use the same public
key and modifier, and start the process from Step 4.
This specification does not address the protection of Neighbor This specification does not address the protection of NDP packets for
Discovery packets for nodes that are configured with a static address nodes that are configured with a static address (e.g., PREFIX::1).
(e.g., PREFIX::1). Future certificate chain based authorization Future certificate chain based authorization specifications are
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 [9] addresses. If the CGA method is not used, nodes of RFC 3041 [17] 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.
8. Securing Router Discovery with SEND The Target Address in Neighbor Advertisement is required to be equal
to the source address of the packet, except in the case of proxy
This section describes how to use the mechanisms from Section 5, Neighbor Discovery. Proxy Neighbor Discovery is not supported by
Section 6, and the reference [26] in order to provide security for this specification; it is planned to be specified in a future
Router Discovery. document.
8.1 Router Solicitation Messages
All Router Solicitation messages are protected with SEND.
8.1.1 Sending Secure Router Solicitations
Secure Router Solicitation messages are sent as described in RFC
2461, with the additional requirements as listed in the following:
Router Solicitation messages sent with an unspecified source
address MUST have the Nonce and Timestamp options.
Other Router Solicitations MUST have the Nonce, Timestamp, and
Signature options. The Signature option MUST be configured with
the sender's key pair, setting the authorization method and
additional information as is configured.
8.1.2 Receiving Secure Router Solicitations
Received Router Solicitation messages are processed as described in
RFC 2461, with the additional SEND-related requirements as listed in
the following:
Router Solicitation message sent with an unspecified source
address and without the Nonce or Timestamp options MUST be
silently discarded.
Router Solicitation messages received with another type of source
address but without the Nonce, Timestamp, or Signature options
MUST be silently discarded.
The Signature option MUST be constructed with the configured
authorization method(s), the used key being within the configured
minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value.
The configured authorization methods MUST include the trust anchor
authorization method, and MAY be additionally configured to
require CGA authorization.
8.2 Router Advertisement Messages
All Router Advertisement messages are protected with SEND.
8.2.1 Sending Secure Router Advertisements
Secure Router Advertisement messages are sent as described in RFC
2461, with the additional requirements as listed in the following:
All Router Advertisement messages sent MUST contain a Timestamp
and Signature options. The Signature option MUST be configured to
protect the advertisement with the trust anchor authorization
method and MAY be configured to additionally protect it with the
CGA authorization method.
Router Advertisements sent in response to a Router Solicitation
MUST contain a copy of the Nonce option included in the
solicitation.
8.2.2 Receiving Secure Router Advertisements
Received Router Advertisement messages are processed as described in
RFC 2461, with the additional SEND-related requirements as listed in
the following:
Router Advertisement messages received without the Timestamp and
Signature options MUST be silently discarded.
Received Router Advertisements sent to a unicast destination
address without a Nonce option MUST be silently discarded.
The Signature option MUST be constructed with the configured
authorization method(s), the used key being within the configured
minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value.
The configured authorization methods MUST include the trust anchor
authorization method, and MAY be additionally configured to
require CGA authorization.
8.3 Redirect Messages
All Redirect messages are protected with SEND.
8.3.1 Sending Redirects
Secure Redirect messages are sent as described in RFC 2461, with the
additional requirements as listed in the following:
All Redirect messages sent MUST contain the Timestamp and
Signature options. The Signature option MUST be configured to use
the trust anchor authorization method, and MAY be additionally
configured to use the CGA method.
8.3.2 Receiving Redirects
Received Redirect messages are processed as described in RFC 2461,
with the additional SEND-related requirements as listed in the
following:
Redirect messages received without the Timestamp or Signature
options MUST be silently discarded.
The Signature option MUST be constructed with the configured
authorization method(s), the used key being within the configured
minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value.
The configured authorization methods MUST include the trust anchor
authorization method, and MAY be additionally configured to
require CGA authorization.
The receiver MUST verify that the Redirect message comes from an
IP address to which the host may have earlier sent the packet that
the Redirect message now partially returns. That is, the source
address of the Redirect message must be the default router or the
on-link destination host for traffic sent to the destination of
the returned packet. If this is not the case, the message MUST be
silently discarded.
This step prevents a bogus router from sending a Redirect message
when the host is not using the bogus router as a default router.
8.4 Other Requirements
Hosts SHOULD use Authorization Delegation Discovery to learn the
certificate chain of their default router (or peer host), as
explained in Section 6. The receipt of a protected Router
Advertisement message for which no router Authorization Certificate
and certificate chain is available triggers Authorization Delegation
Discovery.
9. Co-Existence of SEND and non-SEND nodes 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 Neighbor Discovery Protocol at the the use of SEND and the legacy NDP at the same time.
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 send only secured messages. Legacy Neighbor Discovery
nodes will obviously send only insecure messages. Such nodes will (as nodes will obviously send only insecure messages. Per RFC 2461 [7],
per RFC 2461 [6]) ignore the unknown options and will treat secured such nodes will ignore the unknown options and will treat secured
messages in the same way as they treat insecure ones. Secured and messages in the same way as they treat insecure ones. Secured and
insecure nodes share the same network resources, such as prefixes and insecure nodes share the same network resources, such as prefixes and
address spaces. address spaces.
In a mixed environment SEND routers and hosts follow the protocols In a mixed environment SEND nodes follow the protocols defined in RFC
defined in RFC 2461 and RFC 2462 with the following exceptions: 2461 and RFC 2462 with the following exceptions:
All solicitations sent by SEND nodes MUST be secured. o All solicitations sent by SEND nodes MUST be secured.
Unsolicited Neighbor and Router Advertisements sent by a SEND o Unsolicited advertisements sent by a SEND node MUST be secured.
router MUST be secured.
Secured solicitations MUST contain the Nonce option. Secured o A SEND node MUST send a secured advertisement in response to a
advertisements sent in response to a secured solicitation MUST secured solicitation. Advertisements sent in response to an
contain a copy of the Nonce option from the solicitation. insecure solicitation MUST be secured as well, but MUST NOT
Unsolicited advertisements and ones sent in response to an contain the Nonce option.
insecure solicitation MUST NOT contain the Nonce option.
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 address. If after 3 consecutive attempts no non-unique address
was generated, log a system error and give up attempting to was generated, log a system error and give up attempting to
generate an address for that interface. generate 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.
The node SHOULD have a configuration option that causes it to o The node SHOULD have a configuration option that causes it to
ignore insecure advertisements even when performing Duplicate ignore insecure advertisements even when performing Duplicate
Address Detection for the first tentative address. This Address Detection for the first tentative address. This
configuration option SHOULD be disabled by default. (This is configuration option SHOULD be disabled by default. This is
recovery mechanism for the unlikely case that attacks against the recovery mechanism, in case attacks against the first address
first address become common.) become common.
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. Received secured messages cause an
update of the matching entries and flagging of them as secured. update of the matching entries and flagging of them as secured.
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.
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 ND, RD and Redirect messages. (This can be ignore all insecure Neighbor Solicitation and Advertisement,
used to enforce SEND-only networks.) Router Solicitation and Advertisement, and Redirect messages.
This can be used to enforce SEND-only networks.
10. Performance Considerations
The computations related to the Signature option are computationally
relatively expensive. In the application which Signature option has
been designed for, however, the nodes typically have the 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
communicate.
Routers are required to perform a larger number of operations, 9. Security Considerations
particularly when the frequency of router advertisements is high due
to mobility requirements. Still, the number of required signature
operations is on the order of a few dozen ones per second, some of
which can be precomputed as discussed below. A large number of
router solicitations may cause higher demand for performing
asymmetric operations, although RFC 2461 limits the rate at which
responses to solicitations can be sent.
Signatures related to the use of the Signature option be precomputed 9.1 Threats to the Local Link Not Covered by SEND
for Multicast Neighbor and Router Advertisements. Typically,
solicited advertisements are sent to the unicast address from which
the solicitation was sent. Given that the IPv6 header is covered by
the signature, it is typically not possible to precompute
solicited-for advertisements.
11. Security Considerations SEND does not provide confidentiality for NDP communications.
11.1 Threats to the Local Link Not Covered by SEND SEND does not compensate for an insecure link layer. For instance,
there is no assurance that payload packets actually come from the
same peer that the NDP was run against.
SEND does not compensate for an insecure link layer. In particular, There may be no cryptographic binding in SEND between the link layer
there is no cryptographic binding in SEND between the link layer
frame address and the IPv6 address. On an insecure link layer that frame address and the IPv6 address. On an insecure link layer that
allows nodes to spoof the link layer address of other nodes, an allows nodes to spoof the link layer address of other nodes, an
attacker could disrupt IP service by sending out a Neighbor attacker could disrupt IP service by sending out a Neighbor
Advertisement having the source address on the link layer frame of a Advertisement having the source address on the link layer frame of a
victim, a valid CGA address and a valid signature corresponding to victim, a valid CGA address and a valid signature corresponding to
itself, and a Target Link-layer Address extension corresponding to itself, and a Target Link-layer Address extension corresponding to
the victim. The attacker could then proceed to cause a traffic the victim. The attacker could then proceed to cause a traffic
stream to bombard the victim in a DoS attack. To protect against stream to bombard the victim in a DoS attack. This attack cannot be
such attacks, link layer security MUST be used. An example of such prevented just by securing the link layer.
for 802 type networks is port-based access control defined in the
802.1X standard [34].
Specifically, the 802.1X standard provides a mechanism by which a
nodes can be authenticated to a particular point of attachment to a
LAN (called a "port" in the standard). If the MAC on frames sent by a
node does not correspond to the MAC of the node originally
authenticated to this port, then the point of attachment drops the
frames. Authorization to use the port is determined by the MAC
address of the node that originally authenticated to the port. The
way 802.1X protects against this attack is that, if a node
authenticated to a particular port attempts to spoof the MAC address
of another node, the port will drop the frames. Naturally, this
requires that all ports by which nodes can attach to the LAN use
802.1X authentication, and that all node physically attach through a
port, as is the case with 802.3 switched LAN. For shared media, such
as multiple nodes authenticated through the same 802.11 AP (which
acts as a single port for all nodes), other measures are necessary,
since an attacker on the wireless link can spoof the MAC address of a
victim on the same wireless link.
802.1X does not provide protection for the layer 2 frame - layer 3 Even on a secure link layer, SEND does not require that the addresses
packet address binding in traffic (that is, real time filtering to on the link layer and Neighbor Advertisements correspond to each
check this binding), and neither does SEND. 802.1X provides other. However, it is RECOMMENDED that such checks be performed
authentication and filtering of MAC address to port; SEND provides where this is possible on the given link layer technology.
protection for the layer 2 - layer 3 binding information in the
Neighbor Discovery packet, via the CGA address (authorization to use
the address via the public key) and the signature on the packet
(authentication of contents as from authorized IP address possessor).
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 [6]. 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
[20]. MLD contains no provision for security. An attacker could [16]. 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.
11.2 How SEND Counters Threats to Neighbor Discovery 9.2 How SEND Counters Threats to NDP
The SEND protocol is designed to counter the threats to IPv6 Neighbor The SEND protocol is designed to counter the threats to NDP, as
Discovery, as outlined in [27]. The following subsections contain a outlined in [25]. The following subsections contain a regression of
regression of the SEND protocol against the threats, to illustrate the SEND protocol against the threats, to illustrate what aspects of
what aspects of the protocol counter each threat. the protocol counter each threat.
11.2.1 Neighbor Solicitation/Advertisement Spoofing 9.2.1 Neighbor Solicitation/Advertisement Spoofing
This threat is defined in Section 4.1.1 of [27]. The threat is that This threat is defined in Section 4.1.1 of [25]. The threat is that
a spoofed Neighbor Solicitation or Neighbor Advertisement causes a a spoofed message may cause a false entry in a node's Neighbor Cache.
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. There are two cases: Router Solicitation. A router receiving a Router Solicitation
with a firm IPv6 source address and a Target Link-Layer Address
1. A router receiving a Router Solicitation with a firm IPv6 extension inserts an entry for the IPv6 address into its Neighbor
source address and a Target Link-Layer Address extension Cache. Also, a node performing Duplicate Address Detection (DAD)
inserts an entry for the IPv6 address into its Neighbor that receives a Neighbor Solicitation for the same address
Cache. regards the situation as a collision and ceases to solicit for
the address.
2. A node doing Duplicate Address Detection (DAD) that receives
a Neighbor Solicitation for the same address regards the
situation as a collision and ceases to solicit for the
address.
2. Entries made as a result of a Neighbor Advertisement sent as a
response to a Neighbor Solicitation for purposes of on-link
address resolution.
11.2.1.1 Solicitations with Effect
SEND counters the threat of solicitations with effect in the
following ways:
1. As discussed in Section 5, SEND nodes preferably send Router
Solicitations with a CGA address and a Signature option, which
the router can verify, so the Neighbor Cache binding is correct.
If a SEND node must send a Router Solicitation with the
unspecified address, the router will not update its Neighbor
Cache, as per RFC 2461.
See Section 11.2.5, below, for discussion about replay protection and In either case, SEND counters these treats by requiring the
timestamps. Signature and CGA options to be present in such solicitations.
11.2.1.2 Address Resolution SEND nodes can send Router Solicitation messages with a CGA
source address and a CGA option, which the router can verify, so
the Neighbor Cache binding is correct. If a SEND node must send
a Router Solicitation with the unspecified address, the router
will not update its Neighbor Cache, as per RFC 2461.
SEND counters attacks on address resolution by requiring that the 2. Entries made as a result of a Neighbor Advertisement message.
responding node include a signature option on the packet, and that SEND counters this threat by requiring the Signature and CGA
the node's interface identifier either be a CGA, or that the node be options to be present in these advertisements.
able to produce a certificate authorizing that node to use the public
key.
The Neighbor Solicitation and Advertisement pairs implement a See also Section 9.2.5, below, for discussion about replay protection
challenge-response protocol, as explained in Section 7 and discussed and timestamps.
in Section 11.2.5 below.
11.2.2 Neighbor Unreachability Detection Failure 9.2.2 Neighbor Unreachability Detection Failure
This attack is described in Section 4.1.2 of [27]. SEND counters This attack is described in Section 4.1.2 of [25]. SEND counters
this attack by requiring a node responding to Neighbor Solicitations this attack by requiring a node responding to Neighbor Solicitations
sent as NUD probes to include a Signature option and proof of sent as NUD probes to include 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.
11.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 [27]. SEND counters This attack is described in Section 4.1.3 of [25]. SEND counters
this attack by requiring the Neighbor Advertisements sent as this attack by requiring the Neighbor Advertisements sent as
responses to DAD to include a Signature option and proof of responses to DAD to include 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 used on a link that also connects to non-SEND
nodes, the SEND node ignores any insecure Neighbor Solicitations or nodes, the SEND node ignores any insecure Neighbor Solicitations or
Advertisements that may be send by the non-SEND nodes. This protects Advertisements that may be send by the non-SEND nodes. This protects
the SEND node from DAD DoS attacks by non-SEND nodes or attackers the SEND node from DAD DoS attacks by non-SEND nodes or attackers
simulating to non-SEND nodes, at the cost of a potential address simulating to non-SEND nodes, at the cost of a potential address
collision between a SEND node and non-SEND node. The probability and collision between a SEND node and non-SEND node. The probability and
effects of such an address collision are discussed in [26]. effects of such an address collision are discussed in [12].
11.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 [27]. SEND counters these attacks by requiring Router and 4.2.7 of [25]. SEND counters these attacks by requiring Router
Advertisements to contain a Signature option, and that the signature Advertisements to contain 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 dropped. 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 [27]. 4.4.2 and 4.4.3 of [25].
11.2.5 Replay Attacks 9.2.5 Replay Attacks
This attack is described in Section 4.3.1 of [27]. SEND protects This attack is described in Section 4.3.1 of [25]. SEND protects
against attacks in Router Solicitation/Router Advertisement and against attacks in Router Solicitation/Router Advertisement and
Neighbor Solicitation/Neighbor Advertisement transactions by Neighbor Solicitation/Neighbor Advertisement transactions by
including a Nonce option in the solicitation and requiring the including a Nonce option in the solicitation and requiring the
advertisement to include a matching option. Together with the advertisement to include a matching option. Together with the
signatures this forms a challenge-response protocol. SEND protects signatures this forms a challenge-response protocol. 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.
When timestamps are used, SEND nodes are protected against replay When timestamps are used, SEND nodes are protected against replay
attacks as long as they cache the state created by the message attacks as long as they cache the state created by the message
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.4.1, this may affect some timestamps, as explained in Section 5.3.1, this may affect some
nodes. nodes.
11.2.6 Neighbor Discovery DoS Attack 9.2.6 Neighbor Discovery DoS Attack
This attack is described in Section 4.3.2 of [27]. In this attack, This attack is described in Section 4.3.2 of [25]. In this attack,
the attacker bombards the router with packets for fictitious the attacker bombards the router with packets for fictitious
addresses on the link, causing the router to busy itself with addresses on the link, causing the router to busy itself with
performing Neighbor Solicitations for addresses that do not exist. performing Neighbor Solicitations for addresses that do not exist.
SEND does not address this threat because it can be addressed by SEND does not address this threat because it can be addressed by
techniques such as rate limiting Neighbor Solicitations, restricting techniques such as rate limiting Neighbor Solicitations, restricting
the amount of state reserved for unresolved solicitations, and clever the amount of state reserved for unresolved solicitations, and clever
cache management. These are all techniques involved in implementing cache management. These are all techniques involved in implementing
Neighbor Discovery on the router. Neighbor Discovery on the router.
11.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 [26]. has been discussed in [12].
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.3.2. In this process, the verification process described in Section 5.2.2. In this
a simple hash verification of the CGA property of the address is process, a simple hash verification of the CGA property of the
performed first before performing the more expensive signature address is performed before performing the more expensive signature
verification. verification.
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 dropping 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 drop 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
requesting a large number of delegation chains to be discovered for requesting a large number of delegation chains to be discovered for
different trust anchors. Routers SHOULD defend against such attacks different trust anchors. Routers SHOULD defend against such attacks
by caching discovered information (including negative responses) and by caching discovered information (including negative responses) and
by limiting the number of different discovery processes they engage by limiting the number of different discovery processes they engage
in. in.
Attackers may also target hosts by sending a large number of Attackers may also target hosts by sending a large number of
unnecessary certificate chains, forcing hosts to spend useless memory unnecessary certificate chains, forcing hosts to spend useless memory
and verification resources for them. Hosts can defend against such and verification resources for them. Hosts can defend against such
attacks by limiting the amount of resources devoted to the attacks by limiting the amount of resources devoted to the
certificate chains and their verification. Hosts SHOULD also certificate chains and their verification. Hosts SHOULD also
prioritize advertisements that sent as a response to their prioritize advertisements that sent as a response to their
solicitations above unsolicited advertisements. solicitations above unsolicited advertisements.
12. IANA Considerations 10. Protocol Constants
Host constants:
MAX_DCS_MESSAGES 3 transmissions
DCS_INTERVAL 4 seconds
Router constants:
MAX_DCA_RATE 10 times per second
11. IANA Considerations
This document defines two new ICMP message types, used in This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range: ICMPv6 type numbers from the informational message range:
o The Delegation Chain Solicitation message, described in Section o The Delegation Chain Solicitation message, described in Section
6.1. 6.2.1.
o The Delegation Chain Advertisement message, described in Section o The Delegation Chain Advertisement message, described in Section
6.2. 6.2.2.
This document defines six new Neighbor Discovery Protocol [6] This document defines six new Neighbor Discovery Protocol [7]
options, which must be assigned Option Type values within the option options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery Protocol messages: numbering space for Neighbor Discovery Protocol messages:
o The Trust Anchor option, described in Section 6.3. o The CGA option, described in Section 5.1.
o The Certificate option, described in Section 6.4.
o The CGA option, described in Section 5.2. o The Signature option, described in Section 5.2.
o The Signature option, described in Section 5.3. o The Timestamp option, described in Section 5.3.1.
o The Timestamp option, described in Section 5.4.1. o The Nonce option, described in Section 5.3.2.
o The Nonce option, described in Section 5.4.2. o The Trust Anchor option, described in Section 6.2.3.
This document defines a new 128-bit CGA Message Type [26] value, o The Certificate option, described in Section 6.2.4.
0xXXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX (To be generated randomly).
XXX: Use existing name spaces for these? This document defines a new 128-bit value under the CGA Message Type
[12] 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 [5]. using standards action [6]. The current values for this field are:
1 DER Encoded X.501 Name
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 [5]. using standards action [6]. The current values for this field are:
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] Kent, S. and R. Atkinson, "Security Architecture for the [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [4] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
[4] Piper, D., "The Internet IP Security Domain of Interpretation [5] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998. for ISAKMP", RFC 2407, November 1998.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[7] Thomson, S. and T. Narten, "IPv6 Stateless Address [8] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[8] 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.
[9] Narten, T. and R. Draves, "Privacy Extensions for Stateless [10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[10] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC
3279, April 2002.
[11] 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.
[12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [11] Lynn, C., "X.509 Extensions for IP Addresses and AS
Addressing Architecture", RFC 3513, April 2003.
[13] Lynn, C., "X.509 Extensions for IP Addresses and AS
Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-02 (work in Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-02 (work in
progress), September 2003. progress), September 2003.
[14] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in [12] Aura, T., "Cryptographically Generated Addresses (CGA)",
IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July draft-ietf-send-cga-03 (work in progress), December 2003.
2003.
[15] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS [13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002. 1, November 2002.
[16] National Institute of Standards and Technology, "Secure Hash [14] 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
[17] Postel, J., "Internet Control Message Protocol", STD 5, RFC [15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
792, September 1981.
[18] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, RFC
826, November 1982.
[19] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998. RFC 2409, November 1998.
[20] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener [16] 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.
[21] Farrell, S. and R. Housley, "An Internet Attribute Certificate [17] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[18] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002. Profile for Authorization", RFC 3281, April 2002.
[22] Arkko, J., "Effects of ICMPv6 on IKE", [19] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[20] 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.
[23] Arkko, J., "Manual Configuration of Security Associations for [21] Arkko, J., "Manual SA Configuration for IPv6 Link Local
IPv6 Neighbor Discovery", draft-arkko-manual-icmpv6-sas-02 Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
(work in progress), March 2003. June 2002.
[24] Droms, R., "Dynamic Host Configuration Protocol for IPv6 [22] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
for Address Selection", draft-chakrabarti-ipv6-addrselect-02
(work in progress), October 2003.
[23] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress), (DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002. November 2002.
[25] Kent, S., "IP Encapsulating Security Payload (ESP)", [24] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003. draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.
[26] Aura, T., "Cryptographically Generated Addresses (CGA)", [25] Nikander, P., "IPv6 Neighbor Discovery trust models and
draft-ietf-send-cga-01 (work in progress), August 2003. threats", draft-ietf-send-psreq-00 (work in progress), October
[27] Nikander, P., "IPv6 Neighbor Discovery trust models and
threats", draft-ietf-send-psreq-03 (work in progress), April
2003.
[28] Montenegro, G. and C. Castelluccia, "SUCV Identifiers and
Addresses", draft-montenegro-sucv-03 (work in progress), July
2002. 2002.
[29] International Organization for Standardization, "The Directory [26] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000. - Authentication Framework", ISO Standard X.509, 2000.
[30] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6", [27] Institute of Electrical and Electronics Engineers, "Local and
Computer Communications Review, April 2001.
[31] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", Proceedings of the Cambridge
Security Protocols Workshop, April 2001.
[32] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and
M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security
Workshop, September 2002.
[33] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses",
NDSS, February 2002.
[34] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control", Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001. IEEE Standard 802.1X, September 2001.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
skipping to change at page 57, line 8 skipping to change at page 50, line 8
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Pekka.Nikander@nomadiclab.com EMail: Pekka.Nikander@nomadiclab.com
Appendix A. Contributors Appendix A. Contributors
Tuomas Aura contributed the transition mechanism specification in Tuomas Aura contributed the transition mechanism specification in
Section 9. Section 8.
Appendix B. IPR Considerations Appendix B. Acknowledgments
The optional CGA part of SEND uses public keys and hashes to prove The authors would like to thank Tuomas Aura, Erik Nordmark, Gabriel
address ownership. Several IPR claims have been made about such Montenegro, Pasi Eronen, and Francis Dupont for interesting
methods. discussions in this problem space.
Appendix C. Cache Management Appendix C. Cache Management
In this section we outline a cache management algorithm that allows a In this section we outline a cache management algorithm that allows a
node to remain partially functional even under a cache filling DoS node to remain partially functional even under a cache filling DoS
attack. This appendix is informational, and real implementations attack. This appendix is informational, and real implementations
SHOULD use different algorithms in order to avoid he dangers of SHOULD use different algorithms in order to avoid he dangers of
monocultural code. mono-cultural code.
There are at least two distinct cache related attack scenarios: There are at least two distinct cache related attack scenarios:
1. There are a number of nodes on a link, and someone launches a 1. There are a number of nodes on a link, and someone launches a
cache filling attack. The goal here is clearly make sure that cache filling attack. The goal here is clearly make sure that
the nodes can continue to communicate even if the attack is going the nodes can continue to communicate even if the attack is going
on. on.
2. There is already a cache filling attack going on, and a new node 2. There is already a cache filling attack going on, and a new node
arrives to the link. The goal here is to make it possible for arrives to the link. The goal here is to make it possible for
the new node to become attached to the network, inspite of the the new node to become attached to the network, inspite of the
attack. attack.
From this point of view, it is clearly better to be very selective in From this point of view, it is clearly better to be very selective in
how to throw out entries. Reducing the timestamp Delta value is very how to throw out entries. Reducing the timestamp Delta value is very
discriminative against those nodess that have a large clock discriminative against those nodes that have a large clock
difference, while an attacker can reduce its clock difference into difference, while an attacker can reduce its clock difference into
arbitrarily small. Throwing out old entries just because their clock arbitrarily small. Throwing out old entries just because their clock
difference is large seems like a bad approach. difference is large seems like a bad approach.
A reasonable idea seems to be to have a separate cache space for new A reasonable idea seems to be to have a separate cache space for new
entries and old entries, and under an attack more eagerly drop new entries and old entries, and under an attack more eagerly drop new
cache entries than old ones. One could track traffic, and only allow cache entries than old ones. One could track traffic, and only allow
those new entries that receive genuine traffic to be converted into those new entries that receive genuine traffic to be converted into
old cache entries. While such a scheme will make attacks harder, it old cache entries. While such a scheme will make attacks harder, it
will not fully prevent them. For example, an attacker could send a will not fully prevent them. For example, an attacker could send a
little traffic (i.e. a ping or TCP syn) after each NS to trick the little traffic (i.e. a ping or TCP syn) after each NS to trick the
victim into promoting its cache entry to the old cache. Hence, the victim into promoting its cache entry to the old cache. Hence, the
node may be more intelligent in keeping its cache entries, and not node may be more intelligent in keeping its cache entries, and not
just have a black/white old/new boundary. just have a black/white old/new boundary.
It also looks like a good idea to consider the sec parameter when It also looks like a good idea to consider the sec parameter when
forcing cache entries out, and let those entries with a larger sec a forcing cache entries out, and let those entries with a larger sec a
higher chance of staying in. higher chance of staying in.
Appendix D. Comparison to AH-Based Approach
This approach has the following benefits compared to the previous
Working Group document approach:
o The full implementation of the security mechanism, including
Nonces and CGAs, exists within one module. There is no need to
analyze the security of the mechanism across NDP, IPsec, and CGA
layers.
o The CGA part of the solution has been separated into its own
specification. This is possible because the CGA handling is done
in its own option. (The authorization method configuration flag
is the only thing common to the CGA and Signature options.)
o No extensions or modifications of IPsec processing are required:
SPD entries are not required to distinguish ICMP types, AH does
not need to support public keys or CGAs, and destination address
acgnostic security associations are not needed.
o It is not necessary to allocate a new multicast address to
represent the Solicited-Node multicast address for SEND nodes.
o It is not necessary to change the Neighbor Discovery behavior with
regards to the use of the unspecified address. Since all
information is available within the Neighbor Discovery messages,
unspecified source addresses can be used, still being able to
correlate the CGA property with the Target Address in a Neighbor
Solicitation during Duplicate Address Detection.
o The transition mechanisms for links with both SEND and non-SEND
nodes are significantly simpler. In particular, non-SEND nodes
will be able to receive DAD probes and other messages sent by the
SEND nodes.
o Only a single set of Neighbor Discovery messages from the router
needs to be transmitted on a link. This helps avoid extra
overhead for mobility beacons and other frequently occurring
messaging.
o Given that the asymmetric computations required in SEND are
computationally expensive, it is necessary to control the number
of these operations in order to avoid Denial-of-Service attacks.
This control is easier to arrange with "application layer"
information. For instance, a router need not verify more Router
Solicitations with an unspecified source address than it can
respond to according to the RFC 2461 rules.
o There is no need for an API to communicate certificate chains
requests and certificate chains between the IPsec and Neighbor
Discovery modules.
Also, a good implementation of SEND would not require the user to
configure it (beyond perhaps enabling it). In order to achieve
this with IPsec, a set of policy entries needs to be automatically
created upon system start.
o There is no need for the CGA parameters to be stored both in the
IPsec and Neighbor Discovery modules, where they are needed for
the construction of Authentication Headers and addresses,
respectively.
o It is not necessary to change existing BITS or BITW IPsec
implementations to support SEND and AH_RSA_Sig. There would have
been two problems associated with such changes:
* A SEND implementation in such environment could not proceed
until this modification were completed.
* Typical hardware that processes IPsec packets may not be easily
changed to process asymmetric transforms. (Of course, such
packets can be passed to the main CPU at the node, assuming
this can easily be done in the given implementation.)
o In addition, many IPsec implementations are highly optimized
because they are on the fast path for packet processing. For
example, the Linux implementation runs in the kernel interrupt
thread. Some of the SEND modifications might have required IPsec
processing to wait on a semaphore while, for example, a
certificate chain is fetched, an operation that takes place out of
band in regular IPsec processing because it is done using IKE.
While it might have been possible that the implemenation could
have been arranged so that general IPsec processing wasqn't
impacted, the resulting code would have been more complex.
The use of IPsec to protect NDP would have been possible, but the
limits and capabilities of IPsec would have to be stretched. Small
changes in the NDP protocol (or our understanding of the issues)
might have caused a situation which had no longer been easily handled
when the "application" and the security existed at different layers.
Although IPsec as defined in RFC 2402 just defines a header format,
RFC 2401 and the ensuing years of implementation have evolved a
complex interconnected set of components for IPsec which would have
required some modification to accommodate SEND.
On the other hand, IPsec is the current solution for securing NDP in
the original NDP RFCs. Even if the current IPsec can be used only in
very limited networks to secure NDP, it could have been argued that
it would have been logical to continue its use. Also, the existence
of an asymmetric transform in IPsec would have been potentially
useful in other contexts as well.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 63, line 27 skipping to change at page 53, line 27
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 

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