Request for Comments: 3971 Ericsson
Category: Standards Track J. Kempf
DoCoMo Communications Labs USA
B. Zill
Microsoft
P. Nikander
Ericsson
March 2005
SEcure Neighbor Discovery (SEND)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine their link-layer addresses to
find routers, and to maintain reachability information about the
paths to active neighbors. If not secured, NDP is vulnerable to
various attacks. This document specifies security mechanisms for
NDP. Unlike those in the original NDP specifications, these
mechanisms do not use IPsec.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Neighbor and Router Discovery Overview. . . . . . . . . . . . 6
4. Secure Neighbor Discovery Overview. . . . . . . . . . . . . . 8
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . . 9
5.1. CGA Option. . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Processing Rules for Senders. . . . . . . . . . 11
5.1.2. Processing Rules for Receivers. . . . . . . . . 12
5.1.3. Configuration . . . . . . . . . . . . . . . . . 13
5.2. RSA Signature Option. . . . . . . . . . . . . . . . . . 14
5.2.1. Processing Rules for Senders. . . . . . . . . . 16
5.2.2. Processing Rules for Receivers. . . . . . . . . 16
5.2.3. Configuration . . . . . . . . . . . . . . . . . 17
5.2.4. Performance Considerations. . . . . . . . . . . 18
5.3. Timestamp and Nonce Options . . . . . . . . . . . . . . 19
5.3.1. Timestamp Option. . . . . . . . . . . . . . . . 19
5.3.2. Nonce Option. . . . . . . . . . . . . . . . . . 20
5.3.3. Processing Rules for Senders. . . . . . . . . . 21
5.3.4. Processing Rules for Receivers. . . . . . . . . 21
6. Authorization Delegation Discovery. . . . . . . . . . . . . . 24
6.1. Authorization Model . . . . . . . . . . . . . . . . . . 24
6.2. Deployment Model. . . . . . . . . . . . . . . . . . . . 25
6.3. Certificate Format. . . . . . . . . . . . . . . . . . . 26
6.3.1. Router Authorization Certificate Profile. . . . 26
6.3.2. Suitability of Standard Identity Certificates . 29
6.4. Certificate Transport . . . . . . . . . . . . . . . . . 29
6.4.1. Certification Path Solicitation Message Format. 30
6.4.2. Certification Path Advertisement Message Format 32
6.4.3. Trust Anchor Option . . . . . . . . . . . . . . 34
6.4.4. Certificate Option. . . . . . . . . . . . . . . 36
6.4.5. Processing Rules for Routers. . . . . . . . . . 37
6.4.6. Processing Rules for Hosts. . . . . . . . . . . 38
6.5. Configuration . . . . . . . . . . . . . . . . . . . . . 39
7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. CGAs. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2. Redirect Addresses. . . . . . . . . . . . . . . . . . . 40
7.3. Advertised Subnet Prefixes. . . . . . . . . . . . . . . 40
7.4. Limitations . . . . . . . . . . . . . . . . . . . . . . 41
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9.1. Threats to the Local Link Not Covered by SEND . . . . . 44
9.2. How SEND Counters Threats to NDP. . . . . . . . . . . . 45
9.2.1. Neighbor Solicitation/Advertisement Spoofing. . 45
9.2.2. Neighbor Unreachability Detection Failure . . . 46
9.2.3. Duplicate Address Detection DoS Attack. . . . . 46
9.2.4. Router Solicitation and Advertisement Attacks . 46
9.2.5. Replay Attacks. . . . . . . . . . . . . . . . . 47
9.2.6. Neighbor Discovery DoS Attack . . . . . . . . . 48
9.3. Attacks against SEND Itself . . . . . . . . . . . . . . 48
10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Constants . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Variables . . . . . . . . . . . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. Normative References. . . . . . . . . . . . . . . . . . 50
12.2. Informative References. . . . . . . . . . . . . . . . . 51
Appendices. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A. Contributors and Acknowledgments. . . . . . . . . . . . 53
B. Cache Management. . . . . . . . . . . . . . . . . . . . 53
C. Message Size When Carrying Certificates . . . . . . . . 54
Authors’ Addresses. . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statements . . . . . . . . . . . . . . . . . . . . 56
1. Introduction
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [4]
and 2462 [5]. Nodes on the same link use NDP to discover each
other’s presence and link-layer addresses, to find routers, and to
maintain reachability information about the paths to active
neighbors. NDP is used by both hosts and routers. Its functions
include Neighbor Discovery (ND), Router Discovery (RD), Address
Autoconfiguration, Address Resolution, Neighbor Unreachability
Detection (NUD), Duplicate Address Detection (DAD), and Redirection.
The original NDP specifications called for the use of IPsec to
protect NDP messages. However, the RFCs do not give detailed
instructions for using IPsec to do this. In this particular
application, IPsec can only be used with a manual configuration of
security associations, due to bootstrapping problems in using IKE
[19, 15]. Furthermore, the number of manually configured security
associations needed for protecting NDP can be very large [20], making
that approach impractical for most purposes.
The SEND protocol is designed to counter the threats to NDP. These
threats are described in detail in [22]. SEND is applicable in
environments where physical security on the link is not assured (such
as over wireless) and attacks on NDP are a concern.
This document is organized as follows. Sections 2 and 3 define some
terminology and present a brief review of NDP, respectively. Section
4 describes the overall approach to securing NDP. This approach
involves the use of new NDP options to carry public key - based
signatures. A zero-configuration mechanism is used for showing
address ownership on individual nodes; routers are certified by a
trust anchor [7]. The formats, procedures, and cryptographic
mechanisms for the zero-configuration mechanism are described in a
related specification [11].
The required new NDP options are discussed in Section 5. Section 6
describes the mechanism for distributing certification paths to
establish an authorization delegation chain to a trust anchor.
Finally, Section 8 discusses the co-existence of secured and
unsecured NDP on the same link, and Section 9 discusses security
considerations for SEcure Neighbor Discovery (SEND).
The use of identity certificates provisioned on end hosts for
authorizing address use is out of the scope for this document, as is
the security of NDP when the entity defending an address is not the
same as the entity claiming that address (also known as "proxy ND").
These are extensions of SEND that may be treated in separate
documents, should the need arise.
1.1. Specification of Requirements
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" are to be interpreted as described in [2].
2. Terms
Authorization Delegation Discovery (ADD)
A process through which SEND nodes can acquire a certification
path from a peer node to a trust anchor.
Certificate Revocation List (CRL)
In one method of certificate revocation, an authority periodically
issues a signed data structure called the Certificate Revocation
List. This is a time-stamped list identifying revoked
certificates, signed by the issuer, and made freely available in a
public repository.
Certification Path Advertisement (CPA)
The advertisement message used in the ADD process.
Certification Path Solicitation (CPS)
The solicitation message used in the ADD process.
Cryptographically Generated Address (CGA)
A technique [11] whereby an IPv6 address of a node is
cryptographically generated by using a one-way hash function from
the node’s public key and some other parameters.
Distinguished Encoding Rules (DER)
An encoding scheme for data values, defined in [12].
Duplicate Address Detection (DAD)
A mechanism assuring that two IPv6 nodes on the same link are not
using the same address.
Fully Qualified Domain Name (FQDN)
A fully qualified domain name consists of a host and domain name,
including the top-level domain.
Internationalized Domain Name (IDN)
Internationalized Domain Names can be used to represent domain
names that contain characters outside the ASCII set. See RFC 3490
[9].
Neighbor Discovery (ND)
The Neighbor Discovery function of the Neighbor Discovery Protocol
(NDP). NDP contains functions besides ND.
Neighbor Discovery Protocol (NDP)
The IPv6 Neighbor Discovery Protocol [7, 8].
The Neighbor Discovery Protocol is a part of ICMPv6 [6].
Neighbor Unreachability Detection (NUD)
A mechanism used for tracking the reachability of neighbors.
Non-SEND node
An IPv6 node that does not implement this specification but uses
only the Neighbor Discovery protocol defined in RFCs 2461 and
2462, as updated, without security.
Nonce
An unpredictable random or pseudo-random number generated by a
node and used exactly once. In SEND, nonces are used to assure
that a particular advertisement is linked to the solicitation that
triggered it.
Router Authorization Certificate
An X.509v3 [7] public key certificate using the profile specified
in Section 6.3.1.
SEND node
An IPv6 node that implements this specification.
Router Discovery (RD)
Router Discovery allows the hosts to discover what routers exist
on the link, and what subnet prefixes are available. Router
Discovery is a part of the Neighbor Discovery Protocol.
Trust Anchor
Hosts are configured with a set of trust anchors to protect Router
Discovery. A trust anchor is an entity that the host trusts to
authorize routers to act as routers. A trust anchor configuration
consists of a public key and some associated parameters (see
Section 6.5 for a detailed explanation of these parameters).
3. Neighbor and Router Discovery Overview
The Neighbor Discovery Protocol has several functions. Many of these
are overloaded on a few central message types, such as the ICMPv6
Neighbor Advertisement message. In this section, we review some of
these tasks and their effects in order to better understand how the
messages should be treated. This section is not normative, and if
this section and the original Neighbor Discovery RFCs are in
conflict, the original RFCs, as updated, take precedence.
The main functions of NDP are as follows:
o The Router Discovery function allows IPv6 hosts to discover the
local routers on an attached link. Router Discovery is described
in Section 6 of RFC 2461 [4]. The main purpose of Router
Discovery is to find neighboring routers willing to forward
packets on behalf of hosts. Subnet prefix discovery involves
determining which destinations are directly on a link; this
information is necessary in order to know whether a packet should
be sent to a router or directly to the destination node.
o The Redirect function is used for automatically redirecting a host
to a better first-hop router, or to inform hosts that a
destination is in fact a neighbor (i.e., on-link). Redirect is
specified in Section 8 of RFC 2461 [4].
o Address Autoconfiguration is used for automatically assigning
addresses to a host [5]. This allows hosts to operate without
explicit configuration related to IP connectivity. The default
autoconfiguration mechanism is stateless. To create IP addresses,
hosts use any prefix information delivered to them during Router
Discovery and then test the newly formed addresses for uniqueness.
A stateful mechanism, DHCPv6 [18], provides additional
autoconfiguration features.
o Duplicate Address Detection (DAD) is used for preventing address
collisions [5]: 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 no other node is using
the same address. As 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 allows a node on the link to
resolve another node’s IPv6 address to the corresponding link-
layer address. Address Resolution is defined in Section 7.2 of
RFC 2461 [4], and it is used for hosts and routers alike. Again,
no higher level traffic can proceed until the sender knows the
link layer address of the destination node or the next hop router.
Note that the source link layer address on link layer frames 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 has 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 [4]. NUD is security
sensitive, because an attacker could claim that reachability
exists when in fact it does not.
The NDP messages follow the ICMPv6 message format. All NDP functions
are realized by 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---------------->
*-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND Message- | ND Message |
| Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | |
*-------------------------------------------------------------*
<--NDP Message header-->
4. Secure Neighbor Discovery Overview
To secure the various functions in NDP, a set of new Neighbor
Discovery options is introduced. They are used to protect NDP
messages. This specification introduces these options, an
authorization delegation discovery process, an address ownership
proof mechanism, and requirements for the use of these components in
NDP.
The components of the solution specified in this document are as
follows:
o Certification paths, anchored on trusted parties, are expected to
certify the authority of routers. A host must be configured with
a trust anchor to which the router has a certification path before
the host can adopt the router as its default router.
Certification Path Solicitation and Advertisement messages are
used to discover a certification path to the trust anchor without
requiring the actual Router Discovery messages to carry lengthy
certification paths. The receipt of a protected Router
Advertisement message for which no certification path is available
triggers the authorization delegation discovery process.
o Cryptographically Generated Addresses are used to make sure that
the sender of a Neighbor Discovery message is the "owner" of the
claimed address. A public-private key pair is generated by all
nodes before they can claim an address. A new NDP option, the CGA
option, is used to carry the public key and associated parameters.
This specification also allows a node to use non-CGAs with
certificates that authorize their use. However, the details of
such use are beyond the scope of this specification and are left
for future work.
o A new NDP option, the RSA Signature option, is used to protect all
messages relating to Neighbor and Router discovery.
Public key signatures protect the integrity of the messages and
authenticate the identity of their sender. The authority of a
public key is established either with the authorization delegation
process, by using certificates, or through the address ownership
proof mechanism, by using CGAs, or with both, depending on
configuration and the type of the message protected.
Note: RSA is mandated because having multiple signature algorithms
would break compatibility between implementations or increase
implementation complexity by forcing the implementation of
multiple algorithms and the mechanism to select among them. A
second signature algorithm is only necessary as a recovery
mechanism, in case a flaw is found in RSA. If this happens, a
stronger signature algorithm can be selected, and SEND can be
revised. The relationship between the new algorithm and the RSA-
based SEND described in this document would be similar to that
between the RSA-based SEND and Neighbor Discovery without SEND.
Information signed with the stronger algorithm has precedence over
that signed with RSA, in the same way that RSA-signed information
now takes precedence over unsigned information. Implementations
of the current and revised specs would still be compatible.
o In order to prevent replay attacks, two new Neighbor Discovery
options, Timestamp and Nonce, are introduced. Given that Neighbor
and Router Discovery messages are in some cases sent to multicast
addresses, the Timestamp option offers replay protection without
any previously established state or sequence numbers. When the
messages are used in solicitation-advertisement pairs, they are
protected with the Nonce option.
5. Neighbor Discovery Protocol Options
The options described in this section MUST be supported.
5.1. CGA Option
The CGA option allows the verification of the sender’s CGA. The
format of the CGA option is described as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | Reserved |