WDIFF

draft-ietf-send-ndopt-06.txt --> rfc3971.txt

Secure Neighbor Discovery

Network Working J. Arkko (Editor) Group J. Arkko, Ed.
Request for Comments: 3971 Ericsson
Internet-Draft
Category: Standards Track J. Kempf
Expires: January 15, 2005
DoCoMo Communications Labs USA
B. Sommerfeld
Sun Microsystems
B. Zill
Microsoft
P. Nikander
Ericsson
July 17, 2004
March 2005

SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-06

Status of this This Memo

This document is specifies an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of Internet standards track protocol for the
Internet Engineering
Task Force (IETF), its areas, community, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Please refer to the current edition of six months the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list status of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.

The list this protocol. Distribution of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 15, 2005. this memo is unlimited.

Abstract

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine the their link-layer addresses of
other nodes on the link, 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

Arkko (Editor), et al. Expires January 15, 2005 [Page 1]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 specifies security mechanisms for
NDP. Unlike those in the original NDP
specifications specifications, these
mechanisms do not make use of IPsec.

Arkko, et al. Standards Track [Page 1]

RFC 3971 SEcure Neighbor Discovery March 2005

Table of Contents

1. Introduction Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 3
1.1. Specification of Requirements . . . . . . . . . . . . 5 . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 . 4
3. Neighbor and Router Discovery Overview Overview. . . . . . . . . . . . 9 6
4. Secure Neighbor Discovery Overview Overview. . . . . . . . . . . . . . 11 8
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . 13
5.1 . 9
5.1. CGA Option Option. . . . . . . . . . . . . . . . . . . . . . . 13
5.1.1 10
5.1.1. Processing Rules for Senders . Senders. . . . . . . . . . 14
5.1.2 11
5.1.2. Processing Rules for Receivers . Receivers. . . . . . . . . 15
5.1.3 12
5.1.3. Configuration . . . . . . . . . . . . . . . . . 16
5.2 13
5.2. RSA Signature Option Option. . . . . . . . . . . . . . . . . . 16
5.2.1 14
5.2.1. Processing Rules for Senders Senders. . . . . . . . . . . 18
5.2.2 16
5.2.2. Processing Rules for Receivers . Receivers. . . . . . . . . 19
5.2.3 16
5.2.3. Configuration . . . . . . . . . . . . . . . . . 20
5.2.4 17
5.2.4. Performance Considerations Considerations. . . . . . . . . . . . 21
5.3 18
5.3. Timestamp and Nonce options Options . . . . . . . . . . . . . 21
5.3.1 Timestamp Option . 19
5.3.1. Timestamp Option. . . . . . . . . . . . . . . . 21
5.3.2 19
5.3.2. Nonce Option . Option. . . . . . . . . . . . . . . . . . 22
5.3.3 20
5.3.3. Processing rules Rules for senders Senders. . . . . . . . . . . 23
5.3.4 21
5.3.4. Processing rules Rules for receivers . Receivers. . . . . . . . . 24 21
6. Authorization Delegation Discovery Discovery. . . . . . . . . . . . . . 27
6.1 24
6.1. Authorization Model . . . . . . . . . . . . . . . . . 27
6.2 . 24
6.2. Deployment Model Model. . . . . . . . . . . . . . . . . . . . 28
6.3 25
6.3. Certificate Format Format. . . . . . . . . . . . . . . . . . . 29
6.3.1 26
6.3.1. Router Authorization Certificate Profile . Profile. . . . 29
6.3.2 26
6.3.2. Suitability of Standard Identity Certificates . 32
6.4 29
6.4. Certificate Transport . . . . . . . . . . . . . . . . 32
6.4.1 . 29
6.4.1. Certification Path Solicitation Message Format . 32
6.4.2 Format. 30
6.4.2. Certification Path Advertisement Message Format 34
6.4.3 32
6.4.3. Trust Anchor Option . . . . . . . . . . . . . . 37
6.4.4 34
6.4.4. Certificate Option . Option. . . . . . . . . . . . . . . 38
6.4.5 36
6.4.5. Processing Rules for Routers Routers. . . . . . . . . . . 39
6.4.6 37
6.4.6. Processing Rules for Hosts Hosts. . . . . . . . . . . . 40
6.5 38
6.5. Configuration . . . . . . . . . . . . . . . . . . . . 42 . 39
7. Addressing Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.1 CGAs 40
7.1. CGAs. . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 40
7.2. Redirect Addresses Addresses. . . . . . . . . . . . . . . . . . . 43
7.3 40
7.3. Advertised Subnet Prefixes Prefixes. . . . . . . . . . . . . . . 43
7.4 40
7.4. Limitations . . . . . . . . . . . . . . . . . . . . . 44 . 41
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . 46 . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . 49
9.1 . 44
9.1. Threats to the Local Link Not Covered by SEND . . . . 49
9.2 . 44
9.2. How SEND Counters Threats to NDP NDP. . . . . . . . . . . . 49

Arkko (Editor), et al. Expires January 15, 2005 [Page 2]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

9.2.1 45
9.2.1. Neighbor Solicitation/Advertisement Spoofing . Spoofing. . 50
9.2.2 45
9.2.2. Neighbor Unreachability Detection Failure . . . 50
9.2.3 46
9.2.3. Duplicate Address Detection DoS Attack . Attack. . . . . 50
9.2.4 46

Arkko, et al. Standards Track [Page 2]

RFC 3971 SEcure Neighbor Discovery March 2005

9.2.4. Router Solicitation and Advertisement Attacks . 51
9.2.5 46
9.2.5. Replay Attacks . Attacks. . . . . . . . . . . . . . . . . 51
9.2.6 47
9.2.6. Neighbor Discovery DoS Attack . . . . . . . . . 52
9.3 48
9.3. Attacks against SEND Itself . . . . . . . . . . . . . 52 . 48
10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . 54
10.1 . 49
10.1. Constants . . . . . . . . . . . . . . . . . . . . . . 54
10.2 . 49
10.2. Variables . . . . . . . . . . . . . . . . . . . . . . 54 . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 55
Normative References . 49
12. References. . . . . . . . . . . . . . . . . . . . 56
Informative References . . . . . . 50
12.1. Normative References. . . . . . . . . . . . . . 58
Authors' Addresses . . . . 50
12.2. Informative References. . . . . . . . . . . . . . . . . 51
Appendices. . 58
A. Contributors and Acknowledgments . . . . . . . . . . . . . . 60
B. Cache Management . . . . . . . . . . . . 53
A. Contributors and Acknowledgments. . . . . . . . . . . . 53
B. Cache Management. . . . . . . . . . . . . . . . . . . 61 . 53
C. Message Size When Carrying Certificates . . . . . . . . 54
Authors' Addresses. . . 62
Intellectual Property and . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statements . . . . . . . 63

Arkko (Editor), et al. Expires January 15, 2005 [Page 3]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 . . . . . . . . . . . . . 56

1. Introduction

IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [7] [4]
and 2462 [8]. [5]. Nodes on the same link use NDP to discover each
other's presence, to determine 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 both 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 for 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
[22, 18].
[19, 15]. Furthermore, the number of such manually configured security
associations needed for protecting NDP can be very large
[23], [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 [25]. [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. Section Sections 2 and Section 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 public key - based
signatures. A zero-configuration mechanism is used for showing

Arkko, et al. Standards Track [Page 3]

RFC 3971 SEcure Neighbor Discovery March 2005

address ownership on individual nodes; routers are certified by a
trust anchor [10]. [7]. The formats, procedures, and cryptographic
mechanisms for the zero-configuration mechanism are described in a
related specification [14]. [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 link, and Section 9 discusses security
considerations for Secure SEcure Neighbor Discovery (SEND).

Out of scope for this document is the

The use of identity certificates provisioned on end hosts for
authorizing address use, and 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 adddress address (also known as "proxy ND").
These are

Arkko (Editor), et al. Expires January 15, 2005 [Page 4]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 extensions of SEND that may be treated in separate documents
documents, should the need arise.

1.1

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].

Arkko (Editor), et al. Expires January 15, 2005 [Page 5]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

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 list is a time stamped 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.

Arkko, et al. Standards Track [Page 4]

RFC 3971 SEcure Neighbor Discovery March 2005

Certification Path Solicitation (CPS)

The solicitation message used in the ADD process.

Cryptographically Generated Address (CGA)

A technique [14] [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 [15]. [12].

Duplicate Address Detection (DAD)

A mechanism which assures 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 repertoire. set. See RFC 3490 [12].

Arkko (Editor), et al. Expires January 15, 2005 [Page 6]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
[9].

Neighbor Discovery (ND)

The Neighbor Discovery function of the Neighbor Discovery Protocol
(NDP). NDP contains other functions besides ND.

Neighbor Discovery Protocol (NDP)

The IPv6 Neighbor Discovery Protocol [7, 8].

The Neighbor Discovery Protocol is a part of ICMPv6 [9]. [6].

Neighbor Unreachability Detection (NUD)

A mechanism used for tracking the reachability of neighbors.

Arkko, et al. Standards Track [Page 5]

RFC 3971 SEcure Neighbor Discovery March 2005

Non-SEND node

An IPv6 node that does not implement this specification but uses
only the Neighbor Discovery protocol defined in RFC RFCs 2461 and RFC
2462, as updated, without security.

Nonce

An unpredictable random or pseudorandom 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 [10] [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 for the purposes
of protecting to protect Router
Discovery. A trust anchor is an entity that the host trusts to
authorize routers to act as routers. A trust

Arkko (Editor), et al. Expires January 15, 2005 [Page 7]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 anchor configuration
consists of a public key and some associated parameters (see
Section 6.5 for a detailed explanation of these parameters).

Arkko (Editor), et al. Expires January 15, 2005 [Page 8]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

3. Neighbor and Router Discovery Overview

The Neighbor Discovery Protocol has several functions. Many of these
functions
are overloaded on a few central message types, such as the ICMPv6
Neighbor Advertisement message. In this section section, we review some of
these tasks and their effects in order to understand 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.

Arkko, et al. Standards Track [Page 6]

RFC 3971 SEcure Neighbor Discovery March 2005

The main functions of NDP are the following. 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 [7]. [4]. The main purpose of Router
Discovery is to find neighboring routers that are 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 [7]. [4].

o Address Autoconfiguration is used for automatically assigning
addresses to a host [8]. [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,
Discovery and then test the newly formed addresses for uniqueness.
A stateful mechanism, DHCPv6 [21], [18], provides additional
autoconfiguration features.

o Duplicate Address Detection (DAD) is used for preventing address
collisions [8], [5]: for instance 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 is using
the same address. Since 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 link-
layer address. Address Resolution is defined in Section 7.2

Arkko (Editor), et al. Expires January 15, 2005 [Page 9]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 of
RFC 2461 [7], [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, proxies and eases the stack
implementation requirements requirements, as less information needs has to be passed
from layer to layer.

Arkko, et al. Standards Track [Page 7]

RFC 3971 SEcure Neighbor Discovery March 2005

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]. [4]. NUD is
security-sensitive, security
sensitive, because an attacker could falsely claim that reachability
exists when it 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.

Arkko (Editor), et al. Expires January 15, 2005 [Page 10]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

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.

Arkko, et al. Standards Track [Page 8]

RFC 3971 SEcure Neighbor Discovery March 2005

o Cryptographically Generated Addresses are used to assure 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 to 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

Arkko (Editor), et al. Expires January 15, 2005 [Page 11]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 signature algorithm is only necessary as a recovery
mechanism, in case a flaw is found in RSA. If that this happens, a
stronger signature algorithm can be selected selected, and SEND can be
revised. The relationship between the new algorithm and the RSA-based RSA-
based SEND described in this document would be similar to that
between the RSA-based SEND and Neighbor Discovery without SEND.
Information signed with the stronger algorithm has precedence over
that signed with RSA, in the same way as 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 solicitation-advertisement pairs, they are
protected using with the Nonce option.

Arkko (Editor), et al. Expires January 15, 2005 [Page 12]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

5. Neighbor Discovery Protocol Options

The options described in this section MUST be supported.

5.1 CGA Option

Arkko, et al. Standards Track [Page 9]

RFC 3971 SEcure Neighbor Discovery March 2005

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. follows:

Type

TBD <To be assigned by IANA for CGA>.

Length

The length of the option (including the Type, Length, Pad Length,
Reserved, CGA Parameters, and Padding fields) in units of 8
octets.

Pad Length

The number of padding octets beyond the end of the CGA Parameters
field but within the length specified by the Length field.
Padding octets MUST be set to zero by senders and ignored by
receivers.

Reserved

An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, sender and MUST be ignored by the
receiver.

Arkko (Editor),

Arkko, et al. Expires January 15, 2005 Standards Track [Page 13]

Internet-Draft 10]

RFC 3971 SEcure Neighbor Discovery (SEND) July 2004 March 2005

CGA Parameters

A variable length variable-length field containing the CGA Parameters data
structure described in Section 4 of [14]. [11].

This specification requires that if both the CGA option and the
RSA Signature option are present, then the public key found from
the CGA Parameters field in the CGA option MUST be the public key that referred
by the Key Hash field in the RSA Signature option. Packets
received with two different keys MUST be silently discarded. Note
that a future extension may provide a mechanism
which allows allowing the owner
of an address and the signer to be different parties.

Padding

A variable length variable-length field making the option length a multiple of 8,
containing as many octets as specified in the Pad Length field.

5.1.1

5.1.1. Processing Rules for Senders

If the node has been configured to use SEND, the CGA option MUST be
present in all Neighbor Solicitation and Advertisement messages, messages and
MUST be present in Router Solicitation messages unless they are 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
message as follows. follows:

The CGA Parameter field in the CGA option is filled in according to
the rules presented above and in [14]. [11]. The public key in the
field is taken from the node's configuration used to generate the CGA; CGA,
typically from a data structure associated with the source
address. The address MUST be constructed as specified in Section
4 of [14]. [11]. Depending on the type of the message, this address
appears in different places: places, as follows:

Redirect

The address MUST be the source address of the message.

Neighbor Solicitation

The address MUST be the Target Address for solicitations sent for
Duplicate Address Detection, and Detection; otherwise it MUST be the source
address of the message
otherwise.

Arkko (Editor), message.

Arkko, et al. Expires January 15, 2005 Standards Track [Page 14]

Internet-Draft 11]

RFC 3971 SEcure Neighbor Discovery (SEND) July 2004 March 2005

Neighbor Advertisement

The address MUST be the source address of the message.

Router Solicitation

The address MUST be the source address of the message. Note that
the CGA option is not used when the source address is the
unspecified address.

Router Advertisement

The address MUST be the source address of the message.

5.1.2

5.1.2. Processing Rules for Receivers

Neighbor Solicitation and Advertisement messages without the CGA
option MUST be treated as unsecured, i.e., unsecured (i.e., processed in the same way
as NDP messages sent by a non-SEND node. node). The processing of
unsecured messages is specified in Section 8. Note that SEND nodes
that do not attempt to interoperate with non-SEND nodes MAY simply
discard the unsecured messages.

Router Solicitation messages without the CGA option MUST also be
treated as unsecured, unless the source address of the message is the
unspecified address.

Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
Solicitation, and Router Advertisement messages containing a CGA
option MUST be checked as follows:

If the interface has been configured to use CGA, the receiving
node MUST verify the source address of the packet by using the
algorithm described in Section 5 of [14]. [11]. The inputs to the
algorithm are the claimed address, as defined in the previous
section, and the CGA Parameters field.

If the CGA verification is successful, the recipient proceeds with
a more time consuming time-consuming cryptographic check of the signature. Note
that even if the CGA verification succeeds, no claims about the
validity of the use can be made, made until the signature has been
checked.

A receiver that does not support CGA or has not specified its use for
a given interface can still verify packets by using trust anchors,
even if a CGA is used on a packet. In such a case, the CGA property
of the address is simply left unverified.

Arkko (Editor),

Arkko, et al. Expires January 15, 2005 Standards Track [Page 15]

Internet-Draft 12]

RFC 3971 SEcure Neighbor Discovery (SEND) July 2004

5.1.3 March 2005

5.1.3. Configuration

All nodes that support the verification of the CGA option MUST record
the following configuration information:

minbits

The minimum acceptable key length for public keys used in the
generation of CGAs. The default SHOULD be 1024 bits.
Implementations MAY also set an upper limit in order to limit for the amount of
computation they need to perform needed when verifying packets that use these security
associations. The upper limit SHOULD be at least 2048 bits. Any
implementation should follow prudent cryptographic practice in
determining the appropriate key lengths.

All nodes that support the sending of the CGA option MUST record the
following configuration information:

CGA parameters

Any information required to construct CGAs, as described in [14].

5.2 [11].

Arkko, et al. Standards Track [Page 13]

RFC 3971 SEcure Neighbor Discovery March 2005

5.2. RSA Signature Option

The RSA Signature option allows public-key based public key-based signatures to be
attached to NDP messages. The format of the RSA Signature option is
described in the following diagram:

Arkko (Editor), et al. Expires January 15, 2005 [Page 16]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

TBD <To be assigned by IANA for RSA Signature>.

Length

The length of the option (including the Type, Length, Reserved,
Key Hash, Digital Signature, and Padding fields) in units of 8
octets.

Reserved

A 16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.

Arkko, et al. Standards Track [Page 14]

RFC 3971 SEcure Neighbor Discovery March 2005

Key Hash

A 128-bit field containing the most significant (leftmost)
128-bits 128
bits of a SHA-1 [14] hash of the public key used for constructing
the signature. The SHA-1 hash is taken over the presentation used
in the Public Key field of the CGA Parameters data structure that
is
carried in the CGA option. Its purpose is to associate the
signature to a particular key known by the receiver. Such a key
can be either be stored in the certificate cache of the receiver, receiver or

Arkko (Editor), et al. Expires January 15, 2005 [Page 17]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
be received in the CGA option in the same message.

Digital Signature

A variable length variable-length field containing a PKCS#1 v1.5 signature,
constructed by using the sender's private key, key over the the following
sequence of octets:

1. The 128-bit CGA Message Type tag [14] [11] value for SEND, 0x086F
CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been
generated randomly by the editor of this specification.).

2. The 128-bit Source Address field from the IP header.

3. The 128-bit Destination Address field from the IP header.

4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the
ICMP header.

5. The NDP message header, starting from the octet after the ICMP
Checksum field and continuing up to but not including NDP
options.

6. All NDP options preceding the RSA Signature option.

The signature value is computed with the RSASSA-PKCS1-v1_5
algorithm and SHA-1 hash hash, as defined in [16]. [13].

This field starts after the Key Hash field. The length of the
Digital Signature field is determined by the length of the RSA
Signature option minus the length of the other fields (including
the variable length Pad field).

Padding

This variable length variable-length field contains padding, as many bytes long as
remains
remain after the end of the signature.

5.2.1

Arkko, et al. Standards Track [Page 15]

RFC 3971 SEcure Neighbor Discovery March 2005

5.2.1. Processing Rules for Senders

If the node has been configured to use SEND, Neighbor Solicitation,
Neighbor Advertisement, Router Advertisement, and Redirect messages
MUST contain the RSA Signature option. Router Solicitation messages
not sent with the unspecified source address MUST contain the RSA
Signature option.

A node sending a message using with the RSA Signature option MUST

Arkko (Editor), et al. Expires January 15, 2005 [Page 18]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 construct
the message as follows:

o The message is constructed in its entirety, without the RSA
Signature option.

o The RSA Signature option is added as the last option in the
message.

o The data to be signed is constructed as explained in Section 5.2,
under the description of the Digital Signature field.

o The message, in the form defined above, is signed by using the
configured private key, and the resulting PKCS#1 v1.5 signature is
put in the Digital Signature field.

5.2.2

5.2.2. Processing Rules for Receivers

Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages without the RSA Signature option MUST be
treated as unsecured, i.e., unsecured (i.e., processed in the same way as NDP messages
sent by a non-SEND node. node). See Section 8.

Router Solicitation messages without the RSA Signature option MUST
also be treated as unsecured, unless the source address of the
message is the unspecified address.

Redirect, Neighbor Solicitation, Neighbor Advertisement, Router
Solicitation, and Router Advertisement messages containing an RSA
Signature option MUST be checked as follows:

o The receiver MUST ignore any options that come after the first RSA
Signature option. (The options are ignored for both signature
verification and NDP processing purposes.)

o The Key Hash field MUST indicate the use of a known public key,
either one learned from a preceding CGA option in the same
message, or one known by other means.

Arkko, et al. Standards Track [Page 16]

RFC 3971 SEcure Neighbor Discovery March 2005

o The Digital Signature field MUST have correct encoding, encoding and MUST
not exceed the length of the RSA Signature option minus the
Padding.

o The Digital Signature verification MUST show that the signature
has been calculated as specified in the previous section.

o If the use of a trust anchor has been configured, a valid
certification path (see Section 6.3) MUST be known between the receiver's trust
anchor and the sender's public key.

Arkko (Editor), et al. Expires January 15, 2005 [Page 19]

Note that key MUST be known.

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
anchor.

Messages that do not pass all the above tests MUST be silently
discarded if the host has been configured to only accept only secured ND
messages. The messages MAY be accepted if the host has been
configured to accept both secured and unsecured messages, messages but MUST be
treated as an unsecured message. The receiver MAY also otherwise
silently discard packets, e.g., packets (e.g., as a response to an apparent CPU
exhausting DoS attack.

5.2.3 attack).

5.2.3. Configuration

All nodes that support the reception of the RSA Signature options
MUST allow the following information to be configured for each
separate NDP message type:

authorization method

This parameter determines the method through which the authority
of the sender is determined. It can have four values:

trust anchor

The authority of the sender is verified as described in
Section 6.3. The sender may claim additional authorization
through the use of CGAs, but that this is neither required nor
verified.

CGA

The CGA property of the sender's address is verified as
described in [14]. [11]. The sender may claim additional
authority through a trust anchor, but that this is neither
required nor verified.

Arkko, et al. Standards Track [Page 17]

RFC 3971 SEcure Neighbor Discovery March 2005

trust anchor and CGA

Both the trust anchor and the CGA verification is required.

trust anchor or CGA

Either the trust anchor or the CGA verification is required.

anchor

The allowed trust anchor(s), if the authorization method is not
set to CGA.

All nodes that support the sending of RSA Signature options MUST

Arkko (Editor), et al. Expires January 15, 2005 [Page 20]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 record the
following configuration information:

keypair

A public-private key pair. If authorization delegation is in
use,
there must exist a certification path from a trust anchor to this key pair. pair
must exist.

CGA flag

A flag that indicates whether CGA is used or not. This flag
may be per interface or per node. (Note that in future
extensions of the SEND protocol, this flag may also be per subnet-prefix.)

5.2.4
subnet prefix.)

5.2.4. Performance Considerations

The construction and verification of the RSA Signature option is
computationally expensive. In the NDP context, however, hosts
typically need only have to perform only a few signature operations as they
enter a link, a few operations as they find a new on-link peer with
which to communicate, or Neighbor Unreachability Detection with
existing neighbors.

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 per second, some of which
can be precomputed as explained below. A large number of router
solicitations may cause a higher demand for performing asymmetric
operations, although the base NDP protocol limits the rate at which
multicast responses to solicitations can be sent.

Arkko, et al. Standards Track [Page 18]

RFC 3971 SEcure Neighbor Discovery March 2005

Signatures can be precomputed for unsolicited (multicast) Neighbor
and Router Advertisements if the timing of such the future advertisements
is known. Typically, solicited neighbor 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 advertisements.

5.3

5.3. Timestamp and Nonce options

5.3.1 Options

5.3.1. Timestamp Option

The purpose of the Timestamp option is to assure make sure that unsolicited
advertisements and redirects have not been replayed. The format of
this option is described in the following:

Arkko (Editor), et al. Expires January 15, 2005 [Page 21]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

Type

TBD <To be assigned by IANA for Timestamp>.

Length

The length of the option (including the Type, Length, Reserved,
and Timestamp fields) in units of 8 octets, octets; i.e., 2.

Reserved

A 48-bit field reserved for future use. The value MUST be
initialized to zero by the sender, sender and MUST be ignored by the
receiver.

Arkko, et al. Standards Track [Page 19]

RFC 3971 SEcure Neighbor Discovery March 2005

Timestamp

A 64-bit unsigned integer field containing a timestamp. The value
indicates the number of seconds since January 1, 1970 1970, 00:00 UTC,
by using a fixed point format. In this format format, the integer number
of 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
second.

Implementation note: This format is compatible with the usual
representation of time under UNIX, although the number of bits
available for the integer and fraction parts may vary.

5.3.2

5.3.2. Nonce Option

The purpose of the Nonce option is to assure make sure that an advertisement
is a fresh response to a solicitation sent earlier by the node. The
format of this option is described in the following:

Arkko (Editor), et al. Expires January 15, 2005 [Page 22]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

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 | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

TBD <To be assigned by IANA for Nonce>.

Length

The length of the option (including the Type, Length, and Nonce
fields) in units of 8 octets.

Nonce

A field containing a random number selected by the sender of the
solicitation message. The length of the random number MUST be at
least 6 bytes. The length of the random number MUST be selected
so that the length of the nonce option is a multiple of 8 octets.

5.3.3

Arkko, et al. Standards Track [Page 20]

RFC 3971 SEcure Neighbor Discovery March 2005

5.3.3. Processing rules Rules for senders Senders

If the node has been configured to use SEND, all solicitation
messages MUST include a Nonce. When sending a solicitation, the
sender MUST store the nonce internally so that it can recognize any
replies containing that particular nonce.

If the node has been configured to use SEND, all advertisements sent
in reply to a solicitation MUST include a Nonce, copied from the
received solicitation. Note that routers may decide to send a
multicast advertisement to all nodes instead of a response to a
specific host. In such case a case, the router MAY still include the
nonce value for the host that triggered the multicast advertisement.
(Omitting the nonce value may cause the host to ignore the router's
advertisement, unless the clocks in these nodes are sufficiently
synchronized so that timestamps function properly.)

If the node has been configured to use SEND, all solicitation,
advertisement, and redirect messages MUST include a Timestamp.
Senders SHOULD set the Timestamp field to the current time, according

Arkko (Editor), et al. Expires January 15, 2005 [Page 23]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
to their real time clock.

5.3.4 clocks.

5.3.4. Processing rules Rules for receivers Receivers

The processing of the Nonce and Timestamp options depends on whether
a packet is a solicited advertisement. A system may implement the
distinction in various ways. Section 5.3.4.1 defines the processing
rules for solicited advertisements. Section 5.3.4.2 defines the
processing rules for all other messages.

In addition, the following rules apply in all cases:

o Messages received without at least one of the the Timestamp and Nonce
options MUST be treated as unsecured, i.e., unsecured (i.e., processed in the same
way as NDP messages sent by a non-SEND node. node).

o Messages received with the RSA Signature option but without the
Timestamp option MUST be silently discarded.

o Solicitation messages received with the RSA Signature option but
without the Nonce option MUST be silently discarded.

o Advertisements sent to a unicast destination address with the RSA
Signature option but without a Nonce option SHOULD be processed as
unsolicited advertisements.

Arkko, et al. Standards Track [Page 21]

RFC 3971 SEcure Neighbor Discovery March 2005

o An implementation MAY utilize use some mechanism such as a timestamp 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
attack is in progress, it is possible that the cache holding the
most recent timestamp per sender becomes will become full. In this case case,
the node MUST remove some entries from the cache or refuse some
new requested entries. The specific policy as to which entries
are preferred over the others is left as an implementation decision.
However, typical policies may prefer existing entries over to new ones,
CGAs with a large Sec value over to smaller Sec values, and so on. The
issue is briefly discussed in Appendix B.

o The receiver MUST be prepared to receive the Timestamp and Nonce
options in any order, as per RFC 2461 [7] [4], Section 9.

5.3.4.1

5.3.4.1. Processing solicited advertisements Solicited Advertisements

The receiver MUST verify that it has recently sent a matching
solicitation, and that the received advertisement contains a copy of
the Nonce sent in the solicitation.

Arkko (Editor), et al. Expires January 15, 2005 [Page 24]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

If the message contains a Nonce option, option but the Nonce value is not
recognized, the message MUST be silently discarded.

Otherwise, if the message does not contain a Nonce option, it MAY be
considered as an unsolicited advertisement, advertisement and processed according to
Section 5.3.4.2.

If the message is accepted, the receiver SHOULD store the receive
time of the message and the time stamp timestamp time in the message, as
specified in Section 5.3.4.2.

5.3.4.2

5.3.4.2. Processing all other messages All Other Messages

Receivers SHOULD be configured with an allowed timestamp Delta value,
a "fuzz factor" for comparisons, and an allowed clock drift
parameter. The recommended default value for the allowed Delta is
TIMESTAMP_DELTA,
TIMESTAMP_DELTA; for fuzz factor TIMESTAMP_FUZZ, TIMESTAMP_FUZZ; and for clock drift drift,
TIMESTAMP_DRIFT (see Section 10.2).

To facilitate timestamp checking, each node SHOULD store the
following information for each peer:

o The receive time of the last received and accepted SEND message.
This is called RDlast.

o The time stamp in the last received and accepted SEND message.
This is called TSlast.

Arkko, et al. Standards Track [Page 22]

RFC 3971 SEcure Neighbor Discovery March 2005

An accepted SEND message is any successfully verified Neighbor
Solicitation, Neighbor Advertisement, Router Solicitation, Router
Advertisement, or Redirect message from the given peer. The RSA
Signature option MUST be used in such a message before it can update
the above variables.

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
stored in the cache) cache), the received timestamp, TSnew, is checked checked,
and the packet is accepted if the timestamp is recent enough with
respect to
the reception time of the packet, RDnew:

-Delta < (RDnew - TSnew) < +Delta

The RDnew and TSnew values SHOULD be stored into in the cache as RDlast
and TSlast.

o Even if If the timestamp is NOT within the boundaries but the message is a
Neighbor Solicitation message that should be answered by the

Arkko (Editor), et al. Expires January 15, 2005 [Page 25]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

receiver, receiver should answer, the
receiver SHOULD respond to the message. However, even if it does
respond to the message, it MUST NOT create a Neighbor Cache entry.
This allows nodes that have large differences in their clocks to still communicate
continue communicating with each other, other by exchanging NS/NA pairs.

o When a message is received from a known peer, i.e., peer (i.e., one that
already has an entry in the cache, cache), the time stamp timestamp is checked
against the previously received SEND message:

TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz

If this inequality does not hold, the receiver SHOULD silently
discard the message. On If, on the other hand, if the inequality holds,
the receiver SHOULD process the message.

Moreover, if the above inequality holds and TSnew > TSlast, the
receiver SHOULD update RDlast and TSlast. Otherwise, the receiver
MUST NOT update update RDlast or TSlast.

As unsolicited messages may be used in a Denial-of-Service attack to
cause
make the receiver to verify computationally expensive signatures, all
nodes SHOULD apply a mechanism to prevent excessive use of resources
for processing such messages.

Arkko (Editor),

Arkko, et al. Expires January 15, 2005 Standards Track [Page 26]

Internet-Draft 23]

RFC 3971 SEcure Neighbor Discovery (SEND) July 2004 March 2005

6. Authorization Delegation Discovery

NDP allows a node to automatically configure itself automatically based on
information learned shortly after connecting to a new link. It is
particularly easy to configure "rogue" routers on an unsecured link,
and it is particularly difficult for a node to distinguish between
valid and invalid sources of router information, because the node
needs this information before being able to communicate communicating with nodes outside of the
link.

Since

As the newly-connected node cannot communicate off-link, it cannot be
responsible for searching information to help validate the
router(s); however, router(s).
However, given a certification path, the node can check someone
else's search results and conclude that a particular message comes
from an authorized source. In the typical case, a router already
connected beyond the link, link can (if necessary) communicate if necessary with off-link
nodes and construct such a certification path.

The Secure Neighbor Discovery Protocol mandates a certificate format
and introduces two new ICMPv6 messages that are used between hosts and routers
to allow the host to learn a certification path with the assistance
of the router.

6.1

6.1. Authorization Model

To protect Router Discovery, SEND requires that routers to be authorized
to act as routers. This authorization is provisioned in both routers
and hosts: routers hosts. Routers are given certificates from a trust anchor anchor, and
the hosts are configured with the trust anchor(s) to authorize
routers. This provisioning is specific to SEND, SEND and does not assume
that certificates already deployed for some other purpose can be
used.

The authorization for routers in SEND is twofold:

o Routers are authorized to act as routers. The router belongs to
the set of routers trusted by the trust anchor. All routers in
this set have the same authorization.

o Optionally, routers may also be authorized to advertise a certain
set of subnet prefixes. A specific router is given a specific set
of subnet prefixes to advertise; other routers have an
authorization to advertise other subnet prefixes. Trust anchors
may also delegate a certain set of subnet prefixes to someone
(such as an ISP), who ISP) who, in turn turn, delegates parts of this set to
individual routers.

Arkko, et al. Standards Track [Page 24]

RFC 3971 SEcure Neighbor Discovery March 2005

Note that while communicating with hosts, routers typically present also
present a number of other parameters beyond the above. For instance,

Arkko (Editor), et al. Expires January 15, 2005 [Page 27]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
routers have their own IP addresses, subnet prefixes have lifetimes,
and routers control the use of stateless and stateful address
autoconfiguration, and so on.
autoconfiguration. However, the ability to be a router and the
subnet prefixes are the most fundamental parameters to authorize.
This is because the host needs to choose a router that it uses as its
default router, and because the advertised subnet prefixes have an
impact on the addresses the host uses. In addition, the The subnet prefixes also
represent a claim about the topological location of the router in the
network.

Care should be taken if the certificates used in SEND are also used
to provide authorization in other circumstances, circumstances; for example example, with
routing protocols. It is necessary to ensure that the authorization
information is appropriate for all applications. SEND certificates
may authorize a larger set of subnet prefixes than the router is
really
authorized to advertise on a given interface. For instance, SEND
allows the use of the null prefix. This prefix prefix, which might cause verification or
routing problems in other applications. It is RECOMMENDED that SEND
certificates containing the null prefix are only used for SEND.

Note that end hosts need not be provisioned with their own certified
public keys, just as Web clients today do not require end host
provisioning with certified keys. Public keys for CGA generation do
not need to be certified, since such as these keys derive their ability to
authorize operations on the CGA by the tie to the address.

6.2

6.2. Deployment Model

The deployment model for trust anchors can be either a globally
rooted public key infrastructure, infrastructure or a more local, decentralized
deployment model similar to the current model that currently used for TLS in Web
servers. The centralized model assumes a global root capable of
authorizing routers and, optionally, the address space they
advertise. The end hosts are configured with the public keys of the
global root. The global root could operate, for instance, under the
Internet Assigned Numbers Authority (IANA) or as a co-operative among
Regional Internet Registries (RIRs). However, no such global root
currently exists.

In the decentralized model, end hosts are configured with a
collection of trusted public keys. The public keys could be issued
from a variety of places, various places; for example: example, a) a public key for the end host's
own organization, b) a public key for the end host's home ISP and for
ISPs with which the home ISP has a roaming agreement, or c) public
keys for roaming brokers that act acting as intermediaries for ISPs that don't
want to run their own certification authority.

Arkko (Editor),

Arkko, et al. Expires January 15, 2005 Standards Track [Page 28]

Internet-Draft 25]

RFC 3971 SEcure Neighbor Discovery (SEND) July 2004 March 2005

This decentralized model works even when a SEND node is used both in
networks that have certified routers and in networks that do not. As
discussed in Section 8, a SEND node can fall back to the use of a
non-SEND router. This makes it possible to start with a local trust
anchor even if there is no trust anchor for all possible networks.

6.3

6.3. Certificate Format

The certification path of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act
as a router. Because authorization paths are not a common practice
in the Internet at the time of this specification was written, writing, the path MUST consist of
standard Public Key Certificates (PKC, in the sense of [11]). [8]). The
certification path 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.3.1

6.3.1. Router Authorization Certificate Profile

Router Authorization Certificates are X.509v3 certificates, as
defined in RFC 3280 [10], [7], and SHOULD contain at least one instance of
the X.509 extension for IP addresses, as defined in [13]. [10]. The parent
certificates in the certification path SHOULD 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 block for the
router in question, or that delegated the right to do so. The
certificates for the intermediate delegating authorities SHOULD
contain X.509 IP address extension(s) for subdelegations. The
router's certificate is signed by the delegating authority for the
subnet prefixes the router is authorized to advertise.

The X.509 IP address extension MUST contain at least one
addressesOrRanges element. This element MUST contain an
addressPrefix element containing an IPv6 address prefix for a prefix
that the router or the intermediate entity is authorized to route.
If the entity is allowed to route any prefix, the used IPv6 address prefix
used is the null prefix, ::/0. The addressFamily element of the containing
IPAddrBlocks sequence element MUST contain the IPv6 Address Family
Identifier (0002), as specified in [13] [10], for IPv6 subnet prefixes.
Instead of an addressPrefix element, the addressesOrRange element MAY
contain an addressRange element for a range of subnet prefixes, if
more than one prefix is authorized. The X.509 IP address extension
MAY contain additional IPv6 subnet prefixes, expressed either as either an
addressPrefix or an addressRange.

Arkko, et al. Standards Track [Page 26]

RFC 3971 SEcure Neighbor Discovery March 2005

A node receiving a Router Authorization Certificate MUST first check

Arkko (Editor), et al. Expires January 15, 2005 [Page 29]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
whether the certificate's signature was generated by the delegating
authority. Then the client SHOULD 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 subnet prefixes or ranges, the client MAY
attempt to take an intersection of the ranges/subnet prefixes, prefixes and to
use that intersection. If the resulting intersection is empty, the
client MUST NOT accept the certificate. If the addressPrefix in the
certificate is missing or is the null prefix, ::/0, the parent prefix
or range SHOULD be used. If there is no parent prefix or range, the
subnet prefixes that the router advertises are said to be
unconstrained (see Section 7.3). That is, the router is allowed to
advertise any prefix.

The above check checks SHOULD be done for all certificates in the path. If
any of the checks fail, the client MUST NOT accept the certificate.
The client also needs has to perform validation of advertised subnet
prefixes as discussed in Section 7.3.

Hosts MUST check the subjectPublicKeyInfo field within the last
certificate in the certificate path to ensure that only RSA public
keys are used to attempt validation of router signatures, and signatures. Hosts MUST
disregard the certificate for SEND if it does not contain an RSA key.

Since

As it is possible that some public key 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 switched off by default. That is, the The system SHOULD have a default
configuration that requires rigorous prefix and range checks.

The following is an example of a certification path. Suppose that
isp_group_example.net is the trust anchor. The host has this
certificate:

Certificate 1:
Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_group_example.net
Extensions:
IP address delegation extension:
Prefixes: P1, ..., Pk
... possibly other extensions ...
... other certificate parameters ...

Arkko (Editor),

Arkko, et al. Expires January 15, 2005 Standards Track [Page 30]

Internet-Draft 27]

RFC 3971 SEcure Neighbor Discovery (SEND) July 2004 March 2005

When the host attaches to a link served by
router_x.isp_foo_example.net, it receives the following certification
path:

Certificate 2:
Issuer: isp_group_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: isp_foo_example.net
Extensions:
IP address delegation extension:
Prefixes: Q1, ..., Qk
... possibly other extensions ...
... other certificate parameters ...

Certificate 3:
Issuer: isp_foo_example.net
Validity: Jan 1, 2004 through Dec 31, 2004
Subject: router_x.isp_foo_example.net
Extensions:
IP address delegation extension:
Prefixes R1, ..., Rk
... possibly other extensions ...

... other certificate parameters ...

When processing the three certificates, certificates are processed, the usual RFC 3280 [10] [7]
certificate path validation is performed. Note, however, that at the
time when a
node is checking checks certificates received from a router, it typically does
not have a connection to the Internet yet, and so it is not possible
to perform an on-line Certificate Revocation List (CRL) check check, if such a check is
necessary. Until such a this check is performed, acceptance of the
certificate MUST be considered provisional, and the node MUST perform
a check as soon as it has established a connection with the Internet
through the router. If the router has been compromised, it could
interfere with the CRL check. Should performance of the CRL check be
disrupted or should the check fail, the node SHOULD immediately stop
using the router as a default and use another router on the link
instead.

In addition, the IP addresses in the delegation extension MUST be a
subset of the IP addresses in the delegation extension of the
issuer's certificate. So in this example, R1, ..., Rs must be a
subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If
the certification path is valid, then router_foo.isp_foo_example.com
is authorized to route the prefixes R1,...,Rs.

Arkko (Editor),

Arkko, et al. Expires January 15, 2005 Standards Track [Page 31]

Internet-Draft 28]

RFC 3971 SEcure Neighbor Discovery (SEND) July 2004

6.3.2 March 2005

6.3.2. Suitability of Standard Identity Certificates

Since

As deployment of the IP address extension is, itself, not common, a
network service provider MAY choose to deploy standard identity
certificates on the router to supply the router's public key for
signed Router Advertisements.

If there is no prefix information further up in the certification
path, a host interprets a standard identity certificate as allowing
unconstrained prefix advertisements.

If the other certificates do contain prefix information, a standard
identity certificate is interpreted as allowing those subnet
prefixes.

6.4

6.4. Certificate Transport

The Certification Path Solicitation (CPS) message is sent by a host
when it wishes to request a certification path between a router and
one of the host's trust anchors. The Certification Path
Advertisement (CPA) message is sent in reply to the CPS message.
These messages are kept separate from the rest of Neighbor and Router
Discovery, in order
Discovery to reduce the effect of the potentially voluminous
certification path information on other messages.

The Authorization Delegation Discovery (ADD) process does not exclude
other forms of discovering certification paths. For instance, during
fast movements movements, mobile nodes may learn information - including (including the
certification paths - of paths) about the next router from a previous router, or
nodes may be preconfigured with certification paths from roaming
partners.

Where hosts themselves are certified by a trust anchor, these
messages MAY also optionally be used between hosts to acquire the
peer's certification path. However, the details of such usage are
beyond the scope of this specification.

6.4.1

Arkko, et al. Standards Track [Page 29]

RFC 3971 SEcure Neighbor Discovery March 2005

6.4.1. Certification Path Solicitation Message Format

Hosts send Certification Path Solicitations in order to prompt
routers to generate Certification Path Advertisements.

Arkko (Editor), et al. Expires January 15, 2005 [Page 32]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

IP Fields:

Source Address

A link-local unicast address assigned to the sending interface,
or to the unspecified address if no address is assigned to the
sending interface.

Destination Address

Typically the All-Routers multicast address, the Solicited-Node
multicast address, or the address of the host's default router.

Hop Limit

255

ICMP Fields:

Type

TBD <To be assigned by IANA for Certification Path
Solicitation>.

148

Code

Checksum

The ICMP checksum [9]. [6].

Arkko, et al. Standards Track [Page 30]

RFC 3971 SEcure Neighbor Discovery March 2005

Identifier

A 16-bit unsigned integer field, acting as an identifier to
help matching match advertisements to solicitations. The Identifier
field MUST NOT be zero, and its value SHOULD be randomly
generated. This randomness does not need have to be

Arkko (Editor), et al. Expires January 15, 2005 [Page 33]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
cryptographically hard, since as its purpose is only to avoid
collisions.

Component

This 16-bit unsigned integer field is set to 65,535 if the
sender desires seeks to retrieve all certificates. Otherwise, it is
set to the component identifier corresponding to the
certificate that the receiver wants to retrieve (see Section Sections
6.4.2 and Section 6.4.6).

Valid Options:

Trust Anchor

One or more trust anchors that the client is willing to accept.
The first (or only) Trust Anchor option MUST contain a DER
Encoded X.501 Name; see Section 6.4.3. If there is more than
one Trust Anchor option, the options past beyond the first one may
contain any type of trust anchor.

Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize
and continue processing the message. All included options MUST
have a length that is greater than zero.

ICMP length (derived from the IP length) MUST be 8 or more octets.

6.4.2

Arkko, et al. Standards Track [Page 31]

RFC 3971 SEcure Neighbor Discovery March 2005

6.4.2. Certification Path Advertisement Message Format

Routers send out Certification Path Advertisement messages in
response to a Certification Path Solicitation.

Arkko (Editor), et al. Expires January 15, 2005 [Page 34]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

IP Fields:

Source Address

A link-local unicast address assigned to the interface from
which this message is sent. Note that routers may use multiple
addresses, and therefore this address is not sufficient for the
unique identification of routers.

Destination Address

Either the Solicited-Node multicast address of the receiver or
the link-scoped All-Nodes multicast address.

Hop Limit

255

ICMP Fields:

Type

TBD <To be assigned by IANA for Certification Path
Advertisement>.

149

Code

Checksum

The ICMP checksum [9]. [6].

Arkko, et al. Standards Track [Page 32]

RFC 3971 SEcure Neighbor Discovery March 2005

Identifier

A 16-bit unsigned integer field, acting as an identifier to
help matching match advertisements to solicitations. The Identifier
field MUST be zero for advertisements sent to the All-Nodes
multicast address and MUST NOT be zero for others.

All Components

A 16-bit unsigned integer field, used for informing to inform the receiver how many of
the number of certificates are in the entire path.

A single advertisement SHOULD be broken into separately sent
components if there is more than one certificate in the path,
in order to avoid excessive fragmentation at the IP layer.

Arkko (Editor), et al. Expires January 15, 2005 [Page 35]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

Individual certificates in a path MAY be stored and used as
received before all the certificates have arrived; this makes
the protocol slightly more reliable and less prone to
Denial-of-Service Denial-
of-Service attacks.

Example

Examples of packet lengths of Certification Path Advertisement
messages for typical certification paths are listed in Appendix
C.

Component

A 16-bit unsigned integer field, used for informing to inform the receiver
which certificate is being sent.

The first message in a an N-component advertisement has the
Component field set to N-1, the second set to N-2, and so on.
Zero
A zero indicates that there are no more components coming in
this advertisement.

The sending of path components SHOULD be ordered so that the
certificate after the trust anchor is sent first. Each
certificate sent after the first can be verified with the
previously sent certificates. The certificate of the sender
comes last. The trust anchor certificate SHOULD NOT be sent.

Reserved

An unused field. It MUST be initialized to zero by the sender
and MUST be ignored by the receiver.

Arkko, et al. Standards Track [Page 33]

RFC 3971 SEcure Neighbor Discovery March 2005

Valid Options:

Certificate

One certificate is provided in each Certificate option, option to
establish part of a certification path to a trust anchor.

The certificate of the trust anchor itself SHOULD NOT be sent.

Trust Anchor

Zero or more Trust Anchor options may be included to help
receivers decide which advertisements are useful for them. If
present, these options MUST appear in the first component of a
multi-component advertisement.

Arkko (Editor), et al. Expires January 15, 2005 [Page 36]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

The ICMP length (derived from the IP length) MUST be 8 or more
octets.

6.4.3

6.4.3. Trust Anchor Option

The format of the Trust Anchor option is described in the following:

Type

TBD <To be assigned by IANA for Trust Anchor>.

Length

The length of the option, option (including the Type, Length, Name Type,
Pad Length, and Name fields) fields), in units of 8 octets.

Arkko, et al. Standards Track [Page 34]

RFC 3971 SEcure Neighbor Discovery March 2005

Name Type

The type of the name included in the Name field. This
specification defines two legal values for this field:

1 DER Encoded X.501 Name
2 FQDN

Pad Length

The number of padding octets beyond the end of the Name field but
within the length specified by the Length field. Padding octets
MUST be set to zero by senders and ignored by receivers.

Name

When the Name Type field is set to 1, the Name field contains a

Arkko (Editor), et al. Expires January 15, 2005 [Page 37]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
DER encoded X.501 Name identifying the trust anchor. The value is
encoded as defined in [15] [12] and [10]. [7].

When the Name Type field is set to 2, the Name field contains a
Fully Qualified Domain Name of the trust anchor, anchor; for example,
"trustanchor.example.com". The name is stored as a string, in the
DNS wire format, as specified in RFC 1034 [1]. Additionally, the
restrictions discussed in RFC 3280 [10] [7], Section 4.2.1.7 apply.

In the FQDN case, the Name field is an "IDN-unaware domain name
slot"
slot", as defined in [12]. [9]. That is, it can contain only ASCII
characters. An implementation MAY support internationalized
domain names (IDNs) using the ToASCII operation; see [12] [9] for more
information.

All systems MUST support the DER Encoded X.501 Name.
Implementations MAY support the FQDN name type.

Padding

A variable length variable-length field making the option length a multiple of 8,
beginning after the previous field ends, ends and continuing to the end
of the option, as specified by the Length field.

6.4.4 Certificate Option

The format

Arkko, et al. Standards Track [Page 35]

RFC 3971 SEcure Neighbor Discovery March 2005

6.4.4. Certificate Option

The format of the certificate option is described in the following:

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 | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

TBD <To be assigned by IANA for Certificate>.

Length

The length of the option, option (including the Type, Length, Cert Type,
Pad Length, and Certificate fields) fields), in units of 8 octets.

Arkko (Editor), et al. Expires January 15, 2005 [Page 38]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

Cert Type

The type of the certificate included in the Certificate field.
This specification defines only one legal value for this field:

1 X.509v3 Certificate, as specified below

Reserved

An 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, sender and MUST be ignored by the
receiver.

Certificate

When the Cert Type field is set to 1, the Certificate field
contains an X.509v3 certificate [10], [7], as described in Section
6.3.1.

Padding

A variable length field making the option length a multiple of 8,
beginning after the ASN.1 encoding of the previous field [10, [7, 15]
ends,
ends and continuing to the end of the option, as specified by the
Length field.

6.4.5

Arkko, et al. Standards Track [Page 36]

RFC 3971 SEcure Neighbor Discovery March 2005

6.4.5. Processing Rules for Routers

A router MUST silently discard any received Certification Path
Solicitation messages that do not conform to the message format
defined in Section 6.4.1. The contents of the Reserved field, field and of
any unrecognized options, options MUST be ignored. Future,
backward-compatible backward-
compatible changes to the protocol may specify the contents of the
Reserved field or add new options; backward-incompatible changes may
use different Code values. The contents of any defined options that
are not specified to be used with Router Solicitation messages MUST
be ignored ignored, and the packet processed in the normal manner. The only
defined option that may appear is the Trust Anchor option. A
solicitation that passes the validity checks is called a "valid
solicitation".

Routers SHOULD send advertisements in response to valid solicitations
received on 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

Arkko (Editor), et al. Expires January 15, 2005 [Page 39]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
source address, except when under load, as specified below. Routers
SHOULD NOT send Certification Path Advertisements more than
MAX_CPA_RATE times within a second. When there are more
solicitations, the router SHOULD send the response to the All-Nodes
multicast address regardless of the source address that appeared in
the solicitation.

In an advertisement, the router SHOULD include suitable Certificate
options so that a certification path can be established to the
solicited trust anchor
can be established (or a part of it, if the Component field in
the solicitation is not equal to 65,535). Note also that a single
advertisement is broken into separately sent components and ordered
in a particular way (see Section 6.4.2) when there is more than one
certificate in the path.

The anchor is identified by the Trust Anchor option. If the Trust
Anchor option is represented as a DER Encoded X.501 Name, then the
Name must be equal to the Subject field in the anchor's certificate.
If the Trust Anchor option is represented as an FQDN, the FQDN must
be equal to an FQDN in the subjectAltName field of the anchor's
certificate. The router SHOULD include the Trust Anchor option(s) in
the advertisement for which the certification path was found.

If the router is unable to find a path to the requested anchor, it
SHOULD send an advertisement without any certificates. In this case case,
the router SHOULD include the Trust Anchor options which that were
solicited.

6.4.6

Arkko, et al. Standards Track [Page 37]

RFC 3971 SEcure Neighbor Discovery March 2005

6.4.6. Processing Rules for Hosts

A host MUST silently discard any received Certification Path
Advertisement messages that do not conform to the message format
defined in Section 6.4.2. The contents of the Reserved field, and of
any unrecognized options, MUST be ignored. Future,
backward-compatible backward-
compatible changes to the protocol MAY specify the contents of the
Reserved field or add new options; backward-incompatible changes MUST
use different Code values. The contents of any defined options that are not
specified to be used with Certification Path Advertisement messages
MUST be ignored ignored, and the packet processed in the normal manner. The
only defined options that may appear are the Certificate and Trust
Anchor options. An advertisement that passes the validity checks is
called a "valid advertisement".

Hosts SHOULD store certification paths retrieved in Certification
Path Discovery messages if they start from an anchor trusted by the
host. The certification paths MUST be verified, as defined in
Section 6.3, before storing them. Routers send the certificates one
by one, starting from the trust anchor end of the path.

Arkko (Editor), et al. Expires January 15, 2005 [Page 40]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

Note: except for temporary purposes Except to allow for message loss and
reordering, reordering for temporary
purposes, hosts might not store certificates received in a
Certification Path Advertisement unless they contain a certificate
which
that can be immediately verified either to the trust anchor or to a
certificate that has been verified earlier. This measure is intended
to prevent Denial-of-Service attacks, whereby an attacker floods a
host with certificates that the host cannot validate and overwhelms
memory for certificate storage.

Note that caching this information information, and the implied verification
results between network attachments for use over multiple attachments
to the network network, can help improve performance. But periodic
certificate revocation checks are still needed needed, even with cached
results, to make sure that the certificates are still valid.

The host has a need to SHOULD retrieve a certification path when a Router
Advertisement has been received with a public key that is not
available from a certificate in the hosts' cache of certificates, cache, or when there is no
certification path to the one of the host's trust anchors. In these
situations, the host MAY send a Certification Path Solicitation
message to retrieve the path. If there is no response within
CPS_RETRY seconds, the message should be retried. The wait interval
for each subsequent retransmission MUST exponentially increase,
doubling each time. If there is no response after CPS_RETRY_MAX
seconds, the host abandons the certification path retrieval process.
If the host receives only a part of a certification path within
CPS_RETRY_FRAGMENTS seconds of receiving the first part, it MAY in

Arkko, et al. Standards Track [Page 38]

RFC 3971 SEcure Neighbor Discovery March 2005

addition transmit a Certification Path Solicitation message with the
Component field set to a value not equal to 65,535. This message can
be retransmitted by using the same process as in for the initial
message. If there are multiple missing certificates, additional such CPS
messages can be sent after getting a response to first one. However,
the complete retrieval process may last at most CPS_RETRY_MAX
seconds.

Certification Path Solicitations SHOULD NOT be sent if the host has a
currently valid certification path from a reachable router to a trust
anchor.

When soliciting certificates for a router, a host MUST send
Certification Path Solicitations either to the All-Routers multicast
address, if it has not selected a default router yet, or to the
default router's IP address, if a default router has already been
selected.

If two hosts want to establish trust with the CPS and CPA messages,
the CPS message SHOULD be sent to the Solicited-Node multicast
address of the receiver. The advertisements SHOULD be sent as

Arkko (Editor), et al. Expires January 15, 2005 [Page 41]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
specified above for routers. However, the exact details are outside
the scope of this specification.

When processing possible advertisements sent as responses to a
solicitation, the host MAY prefer to process first those advertisements
with the same Identifier field value as in that of the
solicitation. solicitation
first. This makes Denial-of-Service attacks against the mechanism
harder (see Section 9.3).

6.5

6.5. Configuration

End hosts are configured with a set of trust anchors for the purposes
of protecting in order to
protect Router Discovery. A trust anchor configuration consists of
the following items:

o A public key signature algorithm and associated public key, which
may optionally include parameters.

o A name as described in Section 6.4.3.

o An optional public key identifier.

o An optional list of address ranges for which the trust anchor is
authorized.

If the host has been configured to use SEND, it SHOULD possess the
above information for at least one trust anchor.

Arkko, et al. Standards Track [Page 39]

RFC 3971 SEcure Neighbor Discovery March 2005

Routers are configured with a collection of certification paths and a
collection of certified keys and the certificates containing them, certified keys, down to the key
and certificate for the router itself. Certified keys are required
for routers in order so that a certification path can be established between
the router's certificate and the public key of a trust anchor.

If the router has been configured to use SEND, it should be
configured with its own key pair and certificate, and with at least
one certification path.

Arkko (Editor), et al. Expires January 15, 2005 [Page 42]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

7. Addressing

7.1

7.1. CGAs

By default, a SEND-enabled node SHOULD use only CGAs for its own
addresses. Other types of addresses MAY be used in testing,
diagnostics in
diagnostics, or for 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 [24].

7.2 [21].

7.2. Redirect Addresses

If the Target Address and Destination Address fields in the ICMP
Redirect message are equal, then this message is used to inform hosts
that a destination is is, in fact fact, a neighbor. In this case case, the
receiver MUST verify that the given address falls within the range
defined by the router's certificate. Redirect messages failing this
check MUST be treated as unsecured, as described in Section 7.3.

Note that base NDP rules prevent a host from accepting a Redirect
message from a router that the host is not using to reach the
destination mentioned in the redirect. This prevents an attacker
from tricking a node into redirecting traffic when the attacker is
not the default router.

7.3

7.3. Advertised Subnet Prefixes

The router's certificate defines the address range(s) that it is
allowed to advertise securely. A router MAY, however, advertise a
combination of certified and uncertified subnet prefixes.
Uncertified subnet prefixes are treated as unsecured, i.e., unsecured (i.e., processed
in the same way as unsecured router advertisements sent by non-SEND routers.
routers). The processing of unsecured messages is specified in
Section 8. Note that SEND nodes that do not attempt to interoperate
with non-SEND nodes MAY simply discard the unsecured information.

Arkko, et al. Standards Track [Page 40]

RFC 3971 SEcure Neighbor Discovery March 2005

Certified subnet prefixes fall into the following two categories:

Constrained

If the network operator wants to constrain which routers are
allowed to route particular subnet prefixes, routers should be
configured with certificates having subnet prefixes listed in the
prefix extension. Routers so configured These routers SHOULD advertise the subnet
prefixes which that they are certified to route, or a subset thereof.

Arkko (Editor), et al. Expires January 15, 2005 [Page 43]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

Unconstrained

Network operators that do not want to constrain routers this way
should configure routers with certificates containing either the
null prefix or no prefix extension at all.

Upon processing a Prefix Information option within a Router
Advertisement, nodes SHOULD verify that the prefix specified in this
option falls within the range defined by the certificate, if the
certificate contains a prefix extension. Options failing this check
are treated as containing uncertified subnet prefixes.

Nodes SHOULD use one of the certified subnet prefixes for stateless
autoconfiguration. If none of the advertised subnet prefixes match,
the host SHOULD use a different advertising router as its default
router, if one is available. If the node is performing stateful
autoconfiguration, it SHOULD check the address provided by the DHCP
server against the certified subnet prefixes and SHOULD NOT use the
address if the prefix is not certified.

7.4

7.4. Limitations

This specification does not address the protection of NDP packets for
nodes that are configured with a static address (e.g., PREFIX::1). Future
certification path-based authorization specifications are needed for such
these nodes. This specification also does not apply to addresses
generated by the IPv6 stateless address autoconfiguration
using other from a
fixed forms of interface identifiers (such as EUI-64) as
a basis. EUI-64).

It is outside the scope of this specification to describe the use of
trust anchor authorization between nodes with dynamically changing
addresses. Such dynamically changing These addresses may be the result of stateful or
stateless address autoconfiguration, or through may have resulted from the
use of RFC 3041 [20] [17] addresses. If the CGA method is not used, nodes
are required to exchange certification paths that terminate in a
certificate authorizing a node to use an IP address having a
particular interface identifier. This specification does not specify
the format of such these certificates, since as there are currently only a few

Arkko, et al. Standards Track [Page 41]

RFC 3971 SEcure Neighbor Discovery March 2005

cases where such certificates they are provided by the link layer layer, and it is up to the
link layer to provide certification for the interface identifier.
This may be the subject of a future specification. It is also
outside the scope of this specification to describe how stateful
address autoconfiguration works with the CGA method.

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
Discovery, which is not supported by this

Arkko (Editor), et al. Expires January 15, 2005 [Page 44]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004 specification.

Arkko (Editor), et al. Expires January 15, 2005 [Page 45]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

8. Transition Issues

During the transition to secured links links, or as a policy consideration,
network operators may want to run a particular link with a mixture of
nodes accepting secured and unsecured messages. Nodes that support
SEND SHOULD support the use of secured and unsecured NDP messages at
the same time.

In a mixed environment, SEND nodes receive both secured and unsecured
messages but give priority to secured ones. Here, the "secured"
messages are ones those that contain a valid signature option, as
specified above, and "unsecured" messages are ones those that contain no
signature option.

A SEND node SHOULD have a configuration option that causes it to
ignore all unsecured Neighbor Solicitation and Advertisement, Router
Solicitation and Advertisement, and Redirect messages. This can be
used to enforce SEND-only networks. The default for this
configuration option SHOULD be that both secured and unsecured
messages are allowed.

A SEND node MAY also have a configuration option that causes whereby it to
disable disables
the use of SEND completely, even for the messages it sends itself. The default for this
This configuration option SHOULD be off; switched off by default; that is, that
SEND is used. Plain (non-SEND) NDP nodes will obviously send only
unsecured messages. Per RFC 2461 [7], [4], such nodes will ignore the
unknown options and will treat secured messages in the same way
as that
they treat unsecured ones. Secured and unsecured nodes share the
same network resources, such as subnet prefixes and address spaces.

SEND nodes configured to use SEND at least in their own messages
behave in a mixed environment as is explained below.

SEND adheres to the rules defined for the base NDP protocol protocol, with the
following exceptions:

o All solicitations sent by a SEND node MUST be secured.

Arkko, et al. Standards Track [Page 42]

RFC 3971 SEcure Neighbor Discovery March 2005

o Unsolicited advertisements sent by a SEND node MUST be secured.

o A SEND node MUST send a secured advertisement in response to a
secured solicitation. Advertisements sent in response to an
unsecured solicitation MUST be secured as well, but MUST NOT
contain the Nonce option.

o A SEND node that uses the CGA authorization method for protecting to protect
Neighbor Solicitations SHOULD perform Duplicate Address Detection
as follows. If Duplicate Address Detection indicates that the

Arkko (Editor), et al. Expires January 15, 2005 [Page 46]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
tentative address is already in use, generate the node generates a new
tentative CGA. If after 3 three consecutive attempts no non-unique
address was is generated, log it logs a system error and give gives up
attempting to generate an address for that interface.

When performing Duplicate Address Detection for the first
tentative address, accept the node accepts both secured and unsecured
Neighbor Advertisements and Solicitations received as in response to
the Neighbor Solicitations. When performing Duplicate Address
Detection for the second or third tentative address, ignore it ignores
unsecured Neighbor Advertisements and Solicitations. (The
security implications of this are discussed in Section 9.2.3 and [14].)
in [11].)

o The node MAY have a configuration option that causes whereby it to ignore ignores
unsecured advertisements advertisements, even when performing Duplicate Address
Detection for the first tentative address. This configuration
option SHOULD be disabled by default. This is a recovery
mechanism,
mechanism for cases in case which attacks against the first address
become common.

o The Neighbor Cache, Prefix List List, and Default Router list entries
MUST have a secured/unsecured flag that indicates whether the
message that caused the creation or last update of the entry was
secured or unsecured. Received unsecured messages MUST NOT cause
changes to existing secured entries in the Neighbor Cache, Prefix
List
List, or Default Router List. The Neighbor Cache SHOULD implement a
flag on entries indicating whether the entry is secured. Received secured messages MUST
cause an update of the matching entries and
flagging of them entries, which MUST be flagged as
secured.

o Neighbor Solicitations for the purpose of Neighbor Unreachabilty Unreachability
Detection (NUD) MUST be sent to that neighbor's solicited-nodes
multicast address, address if the entry is not secured with SEND.

Upper layer confirmations on unsecured neighbor cache entries
SHOULD NOT update neighbor cache state from STALE to REACHABLE on
a SEND node, node if the neighbour neighbor cache entry has never previously been
REACHABLE. This ensures that if an entry spoofing a valid SEND

Arkko, et al. Standards Track [Page 43]

RFC 3971 SEcure Neighbor Discovery March 2005

host is created by a non-SEND attacker without being solicited,
NUD will be done within 5 seconds of use of with the entry for data transmission. transmission within five
seconds of use.

As a result, in mixed mode mode, attackers can take over a Neighbor
Cache entry of a SEND node for a longer time only if (a) the SEND
node was not communicating with the victim node node, so that there is
no secure entry for it it, and (b) the SEND node is not currently on
the link (or is unable to respond).

Arkko (Editor), et al. Expires January 15, 2005 [Page 47]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

o The conceptual sending algorithm is modified so that an unsecured
router is selected only if there is no reachable SEND router for
the prefix. That is, the algorithm for selecting a default router
favors reachable SEND routers over reachable non-SEND ones.

o A node MAY adopt a router sending unsecured messages, or a router
for which secured messages have been received, received but for which full
security checks have not yet been completed, while security
checking is underway. Security checks in this case include
certification path solicitation, certificate verification, CRL
checks, and RA signature checks. A node MAY also adopt a router
sending unsecured messages if a router known to be secured becomes
unreachable, but because the unreachability may be the result of
an attack it SHOULD attempt to find a router known to be secured
as soon as possible, since the unreachability may be the
result of an attack. possible. Note that while although this can speed up
attachment to a new network, accepting a router that is sending
unsecured messages or for which security checks are not complete
opens the node to possible attacks, and nodes attacks. Nodes that choose to accept
such routers do so at their own risk. The node SHOULD SHOULD, in any case
case, prefer a router known to be secure as soon as one is made
available with completed security checks.

Arkko (Editor), et al. Expires January 15, 2005 [Page 48]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004

9. Security Considerations

9.1

9.1. Threats to the Local Link Not Covered by SEND

SEND does not provide confidentiality for NDP communications.

SEND does not compensate for an unsecured link layer. For instance,
there is no assurance that payload packets actually come from the
same peer against which the NDP was run.

There may not be no cryptographic binding in SEND between the link layer
frame address and the IPv6 address. On an An unsecured link layer that
allows could
allow nodes to spoof the link layer address of other nodes, an nodes. An
attacker could disrupt IP service by sending out a Neighbor
Advertisement on an unsecured link layer, with the link layer source
address on the frame being set as the source address of a victim, a valid

Arkko, et al. Standards Track [Page 44]

RFC 3971 SEcure Neighbor Discovery March 2005

CGA address and a valid signature corresponding to itself, and a
Target Link-layer Address extension corresponding to the victim. The
attacker could then
proceed to cause make a traffic stream to bombard the victim in a DoS
attack. This attack cannot be prevented just by securing the link layer.

Even on a secured link layer, SEND does not require that the
addresses on the link layer and Neighbor Advertisements correspond to
each other. correspond.
However, it performing these checks is RECOMMENDED that such checks be performed if the link layer
technology permits.

Prior to participating in Neighbor Discovery and Duplicate Address
Detection, nodes must subscribe to the link-scoped All-Nodes
Multicast Group and the Solicited-Node Multicast Group for the
address that they are claiming for as their addresses; RFC 2461 [7]. [4].
Subscribing to a multicast group requires that the nodes use MLD
[19].
[16]. MLD contains no provision for security. An attacker could
send an MLD Done message to unsubscribe a victim from the
Solicited-Node Solicited-
Node Multicast address. However, the victim should be able to detect such an
this attack because the router sends a Multicast-Address-Specific
Query to determine whether any listeners 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 router on the link has not
been compromised. Other attacks using MLD are possible, but they
primarily lead to extraneous (but not necessarily overwhelming)
traffic.

9.2

9.2. How SEND Counters Threats to NDP

The SEND protocol is designed to counter the threats to NDP, as
outlined in [25]. [22]. The following subsections contain a regression of
the SEND protocol against the threats, to illustrate what which aspects of

Arkko (Editor), et al. Expires January 15, 2005 [Page 49]

Internet-Draft SEcure Neighbor Discovery (SEND) July 2004
the protocol counter each threat.

9.2.1

9.2.1. Neighbor Solicitation/Advertisement Spoofing

This threat is defined in Section 4.1.1 of [25]. [22]. The threat is that
a spoofed message may cause a false entry in a node's Neighbor Cache.
There are two cases:

1. Entries made as a side effect of a Neighbor Solicitation or Router
Solicitation. A router receiving a Router Solicitation with a
Target Link-Layer Address extension and the IPv6 source address not equal
unequal to the unspecified address inserts an entry for the IPv6
address into its Neighbor Cache. Also, a node performing
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.

Arkko, et al. Standards Track [Page 45]

RFC 3971 SEcure Neighbor Discovery March 2005

In either case, SEND counters these treats threats by requiring that the
RSA Signature and CGA options to be present in such these solicitations.

SEND nodes can send Router Solicitation messages with a CGA source
address and a CGA option, which the router can verify, so that 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 base NDP.

2. Entries made as a result of a Neighbor Advertisement message.
SEND counters this threat by requiring that the RSA Signature and
CGA options to be present in these advertisements.