WDIFF

draft-ietf-send-ndopt-00.txt --> draft-ietf-send-ndopt-01.txt

Secure Neighbor Discovery Working J. Arkko
Group Ericsson
Internet-Draft J. Kempf
Expires: April 16, June 30, 2004 DoCoMo Communications Labs USA
B. Sommerfeld
Sun Microsystems
B. Zill
Microsoft
P. Nikander
Ericsson
October 17,
December 31, 2003

SEcure Neighbor Discovery (SEND)
draft-ietf-send-ndopt-00
draft-ietf-send-ndopt-01

Status of this Memo

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

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

Internet-Drafts are draft documents valid for a maximum of six months
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 of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.

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

This Internet-Draft will expire on April 16, June 30, 2004.

Abstract

IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
other nodes on the link, to determine each the link-layer addresses
of the 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, et al. Expires April 16, June 30, 2004 [Page 1]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

secured, NDP is vulnerable to various attacks. This document
specifies security mechanisms for NDP. Unlike to the original NDP
specifications, these mechanisms do not make use of IPsec.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Specification of Requirements . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Neighbor and Router Discovery Overview . . . . . . . . . . . 7
4. Secure Neighbor Discovery Overview . . . . . . . . . . . . 11 . 9
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . . . . . 12 11
5.1 Ordering of the new options . . . . . . . . . . . . . . . 12
5.2 CGA Option . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1 .11
5.1.1 Processing Rules for Senders . . . . . . . . . . . . . . . 14
5.2.2 12
5.1.2 Processing Rules for Receivers . . . . . . . . . . . . . . 15
5.2.3 13
5.1.3 Configuration . . . . . . . . . . . . . . . . . . . . . . 15
5.3 14
5.2 Signature Option . . . . . . . . . . . . . . . . . . . . . 15
5.3.1 .14
5.2.1 Processing Rules for Senders . . . . . . . . . . . . . . . 18
5.3.2 16
5.2.2 Processing Rules for Receivers . . . . . . . . 17
5.2.3 Configuration . . . . . . 18
5.3.3 Configuration . . . . . . . . . . . . 18
5.2.4 Performance Considerations . . . . . . . . . . 19
5.4
5.3 Timestamp and Nonce options . . . . . . . . . . . . . . . 20
5.4.1 .19
5.3.1 Timestamp Option . . . . . . . . . . . . . . . 19
5.3.2 Nonce Option . . . . . . 20
5.4.2 Nonce Option . . . . . . . . . . . . . . 20
5.3.3 Processing rules for senders . . . . . . . . . 21
5.4.3
5.3.4 Processing rules for senders . . receivers . . . . . . . . 21
6. Authorization Delegation Discovery . . . . . 22
5.4.4 Processing rules for receivers . . . . . . . . 24
6.1 Certificate Format . . . . . . 22
5.5 Proxy Neighbor Discovery . . . . . . . . . . . .24
6.1.1 Router Authorization Certificate Profile . . . 24
6.2 Certificate Transport . . . 24
6. Authorization Delegation Discovery . . . . . . . . . . . . 25
6.1 .26
6.2.1 Delegation Chain Solicitation Message Format . . . . . . . 25
6.2 27
6.2.2 Delegation Chain Advertisement Message Format 29
6.2.3 Trust Anchor Option . . . . . . 27
6.3 Trust Anchor Option . . . . . . . 31
6.2.4 Certificate Option . . . . . . . . . . . . 29
6.4 Certificate Option . . 32
6.2.5 Processing Rules for Routers . . . . . . . . . 33
6.2.6 Processing Rules for Hosts . . . . . . . . . 30
6.5 Router Authorization Certificate Format . 34
7. Addressing . . . . . . . . 31
6.5.1 Router Authorization Certificate Profile . . . . . . . . . 31
6.6 Processing Rules for Routers . . . . . . . . 36
7.1 CGA Addresses . . . . . . . 32
6.7 Processing Rules for Hosts . . . . . . . . . . . . .36
7.2 Redirect Addresses . . . . 34
7. Securing Neighbor Discovery with SEND . . . . . . . . . . 37
7.1 Neighbor Solicitation Messages . . . .36
7.3 Advertised Prefixes . . . . . . . . . . . 37
7.1.1 Sending Secure Neighbor Solicitations . . . . . . . . . . 37
7.1.2 Receiving Secure Neighbor Solicitations . . . . . . . . . 37
7.2 Neighbor Advertisement Messages . . . . . . . . . . . . . 37
7.2.1 Sending Secure Neighbor Advertisements . . . . . . . . . . 37
7.2.2 Receiving Secure Neighbor Advertisements . . . . . . . . . 38
7.3 Other Requirements .36
7.4 Limitations . . . . . . . . . . . . . . . . . . . . 38 .37
8. Securing Router Discovery with SEND . . . Transition Issues . . . . . . . . 40
8.1 Router Solicitation Messages . . . . . . . . . . . . . . . 40
8.1.1 Sending Secure Router Solicitations . . . 38
9. Security Considerations . . . . . . . . 40
8.1.2 Receiving Secure Router Solicitations . . . . . . . . . . 40
8.2 Router Advertisement Messages
9.1 Threats to the Local Link Not Covered by SEND . . . .40
9.2 How SEND Counters Threats to NDP . . . . . . . . . . .40
9.2.1 Neighbor Solicitation/Advertisement Spoofing . 41
8.2.1 Sending Secure Router Advertisements . . . . .
9.2.2 Neighbor Unreachability Detection Failure . . 41
9.2.3 Duplicate Address Detection DoS Attack . . . . 41

Arkko, et al. Expires April 16, June 30, 2004 [Page 2]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

8.2.2 Receiving Secure

9.2.4 Router Advertisements Solicitation and Advertisement Attacks 42
9.2.5 Replay Attacks . . . . . . . . . . 41
8.3 Redirect Messages . . . . . . 42
9.2.6 Neighbor Discovery DoS Attack . . . . . . . . 43
9.3 Attacks against SEND Itself . . . . . . 41
8.3.1 Sending Redirects . . . . . . .43
10. Protocol Constants . . . . . . . . . . . . . . 41
8.3.2 Receiving Redirects . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . 42
8.4 Other Requirements . . . . . . . . 46
Normative References . . . . . . . . . . . . 42
9. Co-Existence of SEND and non-SEND nodes . . . . . . . . 47
Informative References . 43
10. Performance Considerations . . . . . . . . . . . . . . . . 45
11. Security Considerations . . 48
Authors' Addresses . . . . . . . . . . . . . . . 46
11.1 Threats to the Local Link Not Covered by SEND . . . . . . 46
11.2 How SEND Counters Threats to Neighbor Discovery 49
A. Contributors . . . . . 47
11.2.1 Neighbor Solicitation/Advertisement Spoofing . . . . . . . 47
11.2.2 Neighbor Unreachability Detection Failure . . . . . . . . 48
11.2.3 Duplicate Address Detection DoS Attack . . . . 50
B. Acknowledgments . . . . . . 48
11.2.4 Router Solicitation and Advertisement Attacks . . . . . . 49
11.2.5 Replay Attacks . . . . . . . . . . 51
C. Cache Management . . . . . . . . . . . . 49
11.2.6 Neighbor Discovery DoS Attack . . . . . . . . . . . . . . 49
11.3 Attacks against SEND Itself . . . . . . . . . . . . . . . 50
12. IANA Considerations . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 55
A. Contributors . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . . 57
B. IPR Considerations . . . . . . . . . . . . . . . . . . . . 58
C. Cache Management . . . . . . . . . . . . . . . . . . . . . 59
D. Comparison to AH-Based Approach . . . . . . . . . . . . . 60
Intellectual Property and Copyright Statements . . . . . . 63 53

Arkko, et al. Expires April 16, June 30, 2004 [Page 3]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

1. Introduction

IPv6 defines the Neighbor Discovery Protocol (NDP) in RFC RFCs 2461 [6]. [7]
and 2462 [8]. Nodes on the same link use NDP to discover each
other's presence, to determine each other's link-layer addresses, to
find routers, and to maintain reachability information about the
paths to active neighbors. NDP is used both by 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.

RFC 2461

Original NDP specifications called for the use of IPsec for
protecting the NDP messages. However, it does the RFCs do not specify give detailed
instructions for using IPsec to secure NDP. It turns out that in
this particular application, IPsec can only be used with a manual
configuration of security associations, due to chicken-and-egg
problems in using IKE [22] [19]. [20, 15]. Furthermore, the number of such
manually configured security associations needed for protecting NDP
can be very large [23], [21], making that approach impractical for most
purposes.

This document is organized as follows. Section 4 describes the
overall approach to securing NDP. This approach involves the use of
new NDP options to carry public-key based signatures. A
zero-configuration mechanism is used for showing address ownership on
individual nodes; routers are certified by a trust anchor [11]. [10]. The
formats, procedures, and cryptographic mechanisms for the
zero-configuration mechanism are described in a related specification
[26].
[12].

The required new NDP options are discussed in Section 5. Section 6
describes the mechanism for distributing certificate chains to
establish an authorization delegation chain to a common trust anchor. The required new NDP options are discussed in Section 5.
Section 7 and

Finally, Section 8 show how to apply these components to
securing Neighbor and Router Discovery.

Finally, Section 9 discusses the co-existence of secure and
non-secure Neighbor Discovery NDP on the same link, Section 10 discusses
performance considerations, link and Section 11 9 discusses security
considerations for Secure Neighbor Discovery.

1.1 Specification of Requirements

In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in [2].

Arkko, et al. Expires April 16, June 30, 2004 [Page 4]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

2. Terms

Authorization Delegation Discovery (ADD)

A process through which SEND nodes can acquire a certificate chain
from a peer node to a trust anchor.

Cryptographically Generated Addresses (CGAs) Address (CGA)

A technique [26] [30] [12] where the IPv6 address of a node is
cryptographically generated using a one-way hash function from the
node's public key and some other parameters.

Duplicate Address Detection (DAD)

A mechanism defined in RFC 2462 [7] that assures that two IPv6 nodes on the same link are
not using the same addresses.

Internet Control Message Protocol version 6 (ICMPv6)

The IPv6 control signaling protocol. Neighbor Discovery Protocol
is a part of ICMPv6.

Neighbor Discovery Protocol (NDP)

The IPv6 Neighbor Discovery Protocol [6]. [7, 8].

Neighbor Discovery (ND)

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

Neighbor Unreachability Detection (NUD)

This mechanism defined in RFC 2461 [6] is used for tracking the reachability of neighbors.

Nonce

A random number generated by a node and used exactly once, and
never again. once. In
SEND, nonces are used to ensure that a particular advertisement is
linked to the solicitation that triggered it.

Router Authorization Certificate

An X.509v3 [11] [10] PKC certificate using the profile specified in
Section 6.5.1. 6.1.1.

Arkko, et al. Expires April 16, June 30, 2004 [Page 5]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

SEND node

An IPv6 node that implements this specification.

non-SEND node

An IPv6 node that does not implement this specification but uses
the legacy RFC 2461 and RFC 2462 mechanisms.

Router Discovery (RD)

The Router Discovery function of the Neighbor Discovery Protocol
(NDP). Protocol.

Arkko, et al. Expires April 16, June 30, 2004 [Page 6]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

3. Neighbor and Router Discovery Overview

IPv6

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

In IPv6, many

The main functions of NDP are the tasks traditionally preformed at lower the
layers, such as ARP, have been moved following.

o The Router Discovery function allows IPv6 hosts to discover the IP layer. As a
consequence, a set of unified mechanisms can be applied across link
layers, any introduced security mechanisms or other extensions can be
adopted more easily, and a clear separation
local routers on an attached link. Router Discovery is described
in Section 6 of the roles between the
IP and link layer has been achieved. RFC 2461 [7]. The main functions purpose of IPv6 Neighbor Router
Discovery is to find neighboring routers that are willing to
forward packets on behalf of hosts. 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 to the following. destination node directly.

o Neighbor Unreachability Detection (NUD) The Redirect function is used for tracking the
reachability of neighboring nodes, both automatically redirecting a host
to a better first-hop router, or to inform hosts and routers. NUD that a
destination is
defined in fact a neighbor (i.e., on-link). Redirect is
specified in Section 7.3 8 of RFC 2461 [6]. NUD [7].

o Address Autoconfiguration is
security-sensitive, because an attacker could falsely claim that
reachability exists when it in fact does not. used for automatically assigning
addresses to a host [8]. This allows hosts to operate without
explicit configuration related to IP connectivity. The default
autoconfiguration mechanism is stateless. To create IP addresses,
the hosts use any prefix information delivered to them during
Router Discovery, and then test the newly formed addresses for
uniqueness. A stateful mechanism, DHCPv6 [23], provides
additional autoconfiguration features.

o Duplicate Address Detection (DAD) is used for preventing address
collisions [7]. [8], for instance during Address Autoconfiguration. A
node that intends to assign a new address to one of its interfaces
first runs the DAD procedure to verify that there is no other node
using the same address. Since the rules forbid the use of an
address until it has been found unique, no higher layer traffic is
possible until this procedure has been completed. Thus,
preventing attacks against DAD can help ensure the availability of
communications for the node in question.

o Address Resolution is similar to IPv4 ARP [18]. The Address Resolution function resolves a node's IPv6 address to
the corresponding link-layer address for nodes on the link.
Address Resolution is defined in Section 7.2 of RFC 2461 [6], [7], and

Arkko, et al. Expires June 30, 2004 [Page 7]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

it is used for hosts and routers alike. Again, no higher level
traffic can proceed until the sender knows the hardware address of
the destination node or the next hop router. Note that like its
predecessor in ARP, IPv6 Neighbor Discovery does not check the source link
layer address is not checked against the information learned
through Address Resolution. This allows for an easier addition of
network elements such as bridges and proxies, and eases the stack
implementation requirements as less information needs to be passed
from layer to layer.

Arkko, et al. Expires April 16, 2004 [Page 7]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

o Address Autoconfiguration Neighbor Unreachability Detection (NUD) is used for automatically assigning
addresses to a host [7]. This allows hosts to operate without
explicit configuration related to IP connectivity. The Address
Autoconfiguration mechanism defined in [7] is stateless. To create
IP addresses, tracking the
reachability of neighboring nodes, both hosts use any prefix information delivered to
them during Router Discovery, and then test the newly formed
addresses for uniqueness using the DAD procedure. A stateful
mechanism, DHCPv6 [24], provides additional Autoconfiguration
features. Router and Prefix Discovery and Duplicate Address
Detection have an effect on the Address Autoconfiguration tasks.

o The Redirect function is used for automatically redirecting hosts
to an alternate router. Redirect routers. NUD is specified
defined in Section 8 7.3 of RFC 2461 [6]. It [7]. NUD is similar to the ICMPv4 Redirect function [17].

o The Router Discovery function allows IPv6 hosts to discover the
local routers on
security-sensitive, because an attached link. Router Discovery is described
in Section 6 of RFC 2461 [6]. The main purpose of Router
Discovery is to find neighboring routers attacker could falsely claim that are willing to
forward packets on behalf of hosts. Prefix discovery involves
determining which destinations are directly on a link; this
information is necessary
reachability exists when it in order to know whether a packet should
be sent to a router or to the destination node directly.
Typically, address autoconfiguration and other tasks can not
proceed until suitable routers and prefixes have been found. fact does not.

The Neighbor Discovery NDP messages follow the ICMPv6 message format.
They have ICMPv6 types from 133 to 137. The IPv6 Next Header value
for ICMPv6 is 58. The actual All NDP functions
are realized using the Router Solicitation (RS), Router Advertisement
(RA), Neighbor Discovery 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.

The NDP message options are formatted in the Type-Length-Value
format.

All IPv6 NDP functions are realized using the following ICMPv6
messages:

ICMPv6 Type Message
------------------------------------

Arkko, et al. Expires April 16, June 30, 2004 [Page 8]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

133 Router Solicitation (RS)
134 Router Advertisement (RA)
135 Neighbor Solicitation (NS)
136

4. Secure Neighbor Advertisement (NA)
137 Redirect

The Discovery Overview

To secure the various functions functions, a set of new Neighbor Discovery
options is introduced. They are realized using used in to protect NDP messages.
This specification introduces these messages as follows:

o Router Discovery uses the RS options, an authorization
delegation discovery process, an address ownership proof mechanism,
and RA messages.

o Duplicate Address Detection uses requirements for the NS and NA messages.

o Address Autoconfiguration uses use of these components in NDP.

The components of the NS, NA, RS, and RA messages. solution specified in this document are as
follows:

o Address Resolution uses Certificate chains, anchored on trusted parties, are expected to
certify the NS authority of routers. A host and NA messages.

o Neighbor Unreachability Detection uses a router must have
at least one common trust anchor before the NS and NA messages.

o Redirect uses host can adopt the Redirect message.

The NDP
router as its default router. Delegation Chain Solicitation and
Advertisement messages are always meant to be used within to discover a link, and never
intended certificate chain to leak outside of it. The destination and source addresses
used in these
the trust anchor without requiring the actual Router Discovery
messages are as follows:

o Neighbor Solicitation: to carry lengthy certificate chains. The destination address receipt of a
protected Router Advertisement message for which no certificate
chain is either available triggers this process.

o Cryptographically Generated Addresses are used to assure that the
Solicited-Node multicast address,
sender of a unicast address, Neighbor or Router Advertisement is the "owner" of the
claimed address. A public-private key pair needs to be generated
by all nodes before they can claim an anycast address. The source address A new NDP option,
the CGA option, is either used to carry the unspecified address (in
DAD) or a unicast address assigned public key and associated
parameters.

This specification also allows one to use non-CGA addresses and to
use certificates to authorize their use. However, the sending interface. In a
typical case, details of
such use have been left for future work.

o A new NDP option, the source address Signature option, is equal used to protect all
messages relating to Neighbor and Router discovery.

Public key signatures are used to protect the source address integrity of the outgoing packet, locally triggering the need
messages and to send authenticate the
solicitation.

o Neighbor Advertisement: identity of their sender. The destination address
authority of a public key is established either a
unicast address with the
authorization delegation process, using certificates, or through
the link-scoped All-Nodes multicast address
[12]. The source address is a unicast address assigned to ownership proof mechanism, using CGAs, or both,
depending on configuration and the
sending interface. type of the message protected.

o In order to prevent replay attacks, two new Neighbor Discovery
options, Timestamp and Nonce, are used. Given that Neighbor and
Router Solicitation: The destination address is typically the
All-Routers multicast address [12]. The source address is either
the unspecified address or a unicast address assigned Discovery messages are in some cases sent to multicast
addresses, the
sending interface. An unspecified source address does not have Timestamp option offers replay protection without
any special semantics; it is just an optimization for startup.

o Router Advertisement: The destination address can be either a
unicast previously established state or sequence numbers. When the link-scoped All-Nodes multicast address [12]. The
source address is a link-local address assigned to the sending
interface.
messages are used in solicitation - advertisement pairs, they are

Arkko, et al. Expires April 16, June 30, 2004 [Page 9]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

o Redirect: This message is always sent to the source address of

protected using the
packet that triggered Nonce option.

Arkko, et al. Expires June 30, 2004 [Page 10]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

5. Neighbor Discovery Protocol Options

The options described in this section MUST be supported by all SEND
nodes.

5.1 CGA Option

The CGA option allows the Redirect. Hosts verify that verification of the IP
source address sender's CGA. The
format of the Redirect CGA option is the same as the current
first-hop router for the specified ICMP Destination Address.
Rules in [12] dictate that anycast, or multicast addresses may not
be used described as source addresses. If the source address is an
unspecified address, it is impossible to send a Redirect, since follows.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Collision Cnt | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Modifier |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Key Information .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The meaning of the unspecified address fields is forbidden described as the destination address.
Therefore, the destination address must always follows.

Type

TBD <To be a unicast
address.

The source address is a link-local address assigned to by IANA> for CGA.

Length

The length of the sending
interface. option, in units of 8 octets.

Collision Cnt

An 8-bit collision count, which can get values 0, 1 and 2. Its
semantics are defined in [12].

Arkko, et al. Expires April 16, June 30, 2004 [Page 10] 11]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

4. Secure Neighbor Discovery Overview

To secure

Reserved

An 8-bit field reserved for future use. The value MUST be
initialized to zero by the various functions, a set of new Neighbor Discovery
options introduced. They are sender, and MUST be ignored by the
receiver.

Modifier

A random 128-bit number used in to protect Neighbor and Router
Discovery messages. This specification introduces these options, an
authorization delegation discovery process, an address ownership
proof mechanism, and requirements for CGA generation. Its semantics are
defined in [12].

Key Information

A variable length field containing the use of these components for
Neighbor Discovery.

The components public key of the solution specified in this document are sender,
represented as
follows:

o Certificate chains, anchored on trusted parties, are expected to
certify the authority an ASN.1 type SubjectPublicKeyInfo [10], encoded as
described in Section 4 of routers. A host and a router must have
at least one common trust anchor before the host can adopt [12].

This specification requires that if both the
router as its default router. Delegation Chain Solicitation CGA option and
Advertisement messages the
Signature option are used to discover a certificate chain to present, then the trust anchor without requiring publicKey field in the actual Router Discovery
messages to carry lengthy certificate chains.

o Cryptographically Generated Addresses are used to assure that
former option MUST be the
sender of public key referred by the Key Hash
field in the latter option. Packets received with two different
keys MUST be silently discarded. Note that a Neighbor or Router Advertisement is future extension may
provide a mechanism which allows the "owner" owner of an address and the
claimed address. A public-private key pair needs
signer to be generated different parties.

The length of the Key Information field is determined by all nodes before they can claim an address. the ASN.1
encoding.

Padding

A new Neighbor
Discovery option, variable length field making the CGA option, is used to carry option length a multiple of 8.
It begins after the public key ASN.1 encoding of the previous field has ends,
and associated parameters.

This specification also allows one to use non-CGA addresses and to
use certificates continues to authorized their use. However, the details end of
such use have been left for future work.

o A new Neighbor Discovery option, the Signature option, is used to
protect as specified by the Length
field.

5.1.1 Processing Rules for Senders

The CGA option MUST be present in all messages relating to Neighbor Solicitation and
Advertisement messages, and in Router discovery.

Public key signatures are used to protect the integrity of the Solicitation messages and to authenticate not sent
with the identity of their sender. unspecified source address. The
authority of CGA option MAY be present
in other messages.

A node sending a public key is established either with the
authorization delegation process, using certificates, or through
the address ownership proof mechanism, message using CGAs, or both,
depending on configuration and the type of CGA option MUST construct the
message protected.

o In order to prevent replay attacks, two new Neighbor Discovery
options, Timestamp and Nonce, are used. Given that Neighbor as follows.

The Modifier, Collision Cnt, and
Router Discovery messages are Key Information fields in some cases sent to multicast
addresses, the Timestamp CGA
option offers replay protection without
any previously established state or sequence numbers. When the
messages are used filled in solicitation - advertisement pairs, they
protected using according to the Nonce option. rules presented above and in

Arkko, et al. Expires April 16, June 30, 2004 [Page 11] 12]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

5. Neighbor Discovery Options

[12]. The following new NDP options and mechanisms are REQUIRED to be
implemented by all SEND nodes:

o used public key is taken from configuration; typically
from a data structure associated with the source address. The CGA option MAY be present in all Neighbor Discovery messages,
and SHOULD
address MUST be present constructed as specified in most cases.

o The Signature option is REQUIRED Section 4 of [12].
Depending on the type of the message, this address appears in all Neighbor Discovery
messages.

o
different places:

Redirect

The Nonce option is REQUIRED in all address MUST be the source address of the message.

Neighbor Discovery
solicitations, and in all solicited advertisements.

o Solicitation

The Timestamp option is REQUIRED in all Neighbor Discovery
advertisements address MUST be the Target Address for solicitations sent for
the purpose of Duplicate Address Detection, and Redirects.

o Proxy the source address
of the message otherwise.

Neighbor Discovery is not supported by this specification;
it is planned to Advertisement

The address MUST be specified in a future document.

5.1 Ordering the source address of the new options message.

Router Solicitation

The ordering address MUST be the source address of the new options MUST obey message. Note that
the following rules:

The CGA option MUST appear before is not used when the Signature option.

The Nonce option SHOULD appear before source address is the Timestamp option.
unspecified address.

Router Advertisement

The Signature option address MUST NOT be be followed CGA, Nonce, or
Timestamp options.

It is RECOMMENDED that the options appear in source address of the message.

5.1.2 Processing Rules for Receivers

Neighbor Solicitation and Advertisement messages without the following order:
CGA, Nonce, Timestamp, Signature.

5.2 CGA Option

The
option MUST be silently discarded. Router Solicitation messages
without the CGA option allows MUST be silently discarded, unless the verification source
address of the sender's CGA. The
format of message is the unspecified address.

A message containing a CGA option is described MUST be checked as follows.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 follows:

If the interface has been configured to use CGA, the receiving
node MUST verify the source address of the packet using the
algorithm described in Section 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Modifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| of [12]. The inputs for the
algorithm are the contents of the Collision Cnt | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cnt, Modifier, and the
Key Information fields, the claimed address in the packet (as
discussed in the previous section), and the minimum acceptable Sec
value. If the CGA verification is successful, the recipient
proceeds with the cryptographically more time consuming check of

Arkko, et al. Expires April 16, June 30, 2004 [Page 12] 13]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

| |
. .
. Key Information .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The meaning

the signature.

Note that a receiver which does not support CGA or has not specified
its use for a given interface can still verify packets using trust
anchors, even if CGA had been used on a packet. In such a case, the
CGA property of the fields address is described as follows.

Type

TBD <To be assigned by IANA> for CGA.

Length simply left unverified.

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 of for the option, in units of 8 octets.

Modifier

A random number public keys used in the
generation of the CGA generation. Its semantics are defined
in [26].

Collision Cnt

An 8-bit collision count, which can get values 0, 1 and 2. Its
semantics are defined in [26].

Reserved

A 24-bit field reserved for future use. address. The value MUST default SHOULD be
initialized 1024 bits.
Implementations MAY also set an upper limit in order to zero by the sender, and MUST be ignored by the
receiver.

Key Information

A variable length field containing limit the public key
amount of the sender,
represented as an ASN.1 type SubjectPublicKeyInfo [11], encoded as
described computation they need to perform when verifying packets
that use these security associations. Any implementation should
follow prudent cryptographic practice in determining the
appropriate key lengths.

minSec

The minimum acceptable Sec value, if CGA verification is required
(see Section 4 of [26]. 2 in [12]). This specification requires parameter is intended to facilitate
future extensions and experimental work. Currently, the minSec
value SHOULD always be set to zero.

All nodes that if both support the sending of the CGA option and MUST record the
Signature option are present, then
following configuration information:

CGA parameters

Any information required to construct CGAs, including the publicKey field in used Sec
and Modifier values, and the
former CGA address itself.

5.2 Signature Option

The Signature option MUST allows public-key based signatures to be
attached to NDP messages. Both trust anchor authentication and CGAs
can be used. The format of the public key referred by Signature option is described in the Key Hash
following:

Arkko, et al. Expires April 16, June 30, 2004 [Page 13] 14]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

field in the latter option. Packets received with two different
keys MUST be silently discarded. Note that a future extension may
provide a mechanism which allows the owner of an address and the
signer to be different parties.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The length meaning of the Key Information field fields is determined described below:

Type

TBD <To be assigned by the ASN.1
encoding.

Padding

A variable IANA> for Signature.

Length

The length field making of the option length a multiple option, in units of 8.
It begins after 8 octets.

Pad Length

An 8-bit integer field, giving the ASN.1 encoding length of the previous Pad field has ends,
and continues to the end in
units of an octet.

Reserved

An an 8-bit field reserved for future use. The value MUST be
initialized to zero by the option, as specified sender, and MUST be ignored by the Length
field.

5.2.1 Processing Rules for Senders
receiver.

Key Hash

A node sending 128-bit field contains the most significant (leftmost) 128-bits
of a message using SHA1 hash of the CGA option MUST construct public key used for the
message as follows. constructing the

Arkko, et al. Expires June 30, 2004 [Page 15]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

signature. The Modifier, Collision Cnt, and SHA1 is taken over the presentation used in the
Key Information fields field in the CGA
option are filled in according option. Its purpose is to
associate the rules presented above and in
[26]. The used public key is taken from configuration; typically
from signature to a data structure associated with particular key known by the source address.

An address MUST receiver.
Such a key can be constructed as specified either stored in Section 4 of [26]. In
the typical case, the address is constructed long before it is used.

Depending on the type certificate cache of the message, this address appears in
different places:

Redirect

The address MUST
receiver, or be received in the source address of CGA option in the same message.

Neighbor Solicitation

The address MUST be

Digital Signature

A variable length field contains the Target Address for solicitations sent for signature constructed using
the purpose sender's private key, over the the following sequence of Duplicate
octets:

1. The 128-bit CGA Type Tag [12] value for SEND, 0x086F CA5E 10B2
00C9 9C8C E001 6427 7C08 (generated randomly).

2. The 128-bit Source Address Detection, and field from the source address
of IP header.

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

4. The 32-bit ICMP header.

5. The NDP message otherwise.

Neighbor Advertisement header.

6. All NDP options preceding the Signature option.

The address signature is constructed using the RSA algorithm and MUST be
encoded as private key encryption in PKCS#1 format [13]. The
signature value is computed with the source address of RSASSA-PKCS1-v1_5 algorithm
and SHA-1 hash as defined in [13].

This field starts after the message.

Arkko, et al. Expires April 16, 2004 [Page 14]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Router Solicitation Key Hash field. The address MUST be length of the source address
Digital Signature field is determined by the length of the message, unless
Signature option minus the
source address is length of the unspecified address. other fields (including
the variable length Pad field).

This variable length field contains padding, as many bytes as is
given by the Pad Length Field.

5.2.1 Processing Rules for Senders

Neighbor Solicitation, Neighbor Advertisement, Router Advertisement

The address Advertisement,
and Redirect messages MUST be contain the Signature option. Router
Solicitation messages not sent with the unspecified source address of
MUST contain the message.

5.2.2 Processing Rules for Receivers Signature option.

A message containing node sending a CGA message using the Signature option MUST be checked construct
the message as follows:

Arkko, et al. Expires June 30, 2004 [Page 16]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

o The message is constructed in its entirety, without the interface has been configued to use CGA, it Signature
option.

o The Signature option is REQUIRED
that added as the receiving node verifies last option in the message.

o For the purpose of constructing a signature, the following data
items are concatenated:

* The 128-bit CGA Type Tag.

* The source address of the packet
using the algorithm described in Section 5 of [26]. message.

* The inputs
for the algorithm are destination address of the message.

* The contents of the Modifier, Collision Cnt,
and message, starting from the Key Information fields, ICMPv6 header,
up to but excluding the claimed address Signature option.

o The message, in the packet
(as discussed in form defined above, is signed using the previous section),
configured private key, and the minimum acceptable
Sec value. If the CGA verification resulting PKCS#1 signature is successful, put
to the recipient
proceeds with Digital Signature field.

5.2.2 Processing Rules for Receivers

Neighbor Solicitation, Neighbor Advertisement, Router Advertisement,
and Redirect messages without the cryptographically more time consuming check of Signature option MUST be silently
discarded. Router Solicitation messages without the signature.

Note that a receiver which does not support CGA or has not specified
its use for a given interface can still verify packets using trust
anchors, even if CGA had been used on a packet. In such a case, Signature option
MUST be silently discarded, unless the
CGA property source address of the address message
is simply left unverified.

5.2.3 Configuration

All nodes that support the verification of the CGA unspecified address.

A message containing a Signature option MUST record
the following configuration information:

minbits be checked as follows:

o The minimum acceptable key length for Signature option MUST appear as the public keys used in last option.

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

o The default SHOULD be 1024 bits.
Implementations MAY also set an upper limit in order to limit Digital Signature field MUST have correct encoding, and not
exceed the
amount length of computation they need to perform when verifying packets
that use these security associations. Any implementation should
follow prudent cryptographic practise in determining the
appropriate key lengths.

5.3 Signature Option option.

o The Digital Signature option allows public-key based signatures to 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
authorization delegation chain MUST be known between the
receiver's trust anchor and the sender's public key.

Arkko, et al. Expires April 16, June 30, 2004 [Page 15] 17]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

attached to NDP messages. Both trust anchor authentication and CGAs
can be used. The format of

Note that the Signature option is described in the
following:

The meaning of receiver may verify just the fields is described below:

Type

TBD <To be assigned by IANA> for Signature.

Length

The length CGA property of the option, a
packet, even if, in units of 8 octets.

Pad Length

An 8-bit integer field, giving addition to CGA, the length of sender has used a trust
anchor.

Messages that do not pass all the Pad field in
units of an octet.

Reserved

An an 8-bit field reserved for future use. The value above tests MUST be
initialized silently
discarded. The receiver MAY silently discard packets also otherwise,
e.g., as a response to zero by an apparent CPU exhausting DoS attack.

5.2.3 Configuration

All nodes that support the sender, and reception of the Signature options MUST be ignored by
record the
receiver.

Arkko, et al. Expires April 16, 2004 [Page 16]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Key Hash

A 128-bit field contains following configuration information for each separate NDP
message type:

authorization method

This parameter determines the most significant (leftmost) 128-bits
of a SHA1 hash method through which the authority
of the public key used for the constructing the
signature. The SHA1 sender is taken over the presentation used in the
Key Information field in determined. It can have four values:

trust anchor

The authority of the CGA option. Its purpose sender is to
associate the signature to a particular key known by the receiver.
Such a key can be either stored verified as described in Section
6.1. The sender may claim additional authorization through the certificate cache
use of CGAs, but that is neither required nor verified.

CGA

The CGA property of the
receiver, or be received sender's address is verified as
described in the [12]. The sender may claim additional authority
through a trust anchor, but that is neither required nor
verified.

trust anchor and CGA option in the same message.

Digital Signature

A variable length field contains

Both the signature constructed using trust anchor and the sender's private key, over CGA verification is required.

trust anchor or CGA

Either the trust anchor or the following sequence of
octets:

1. The 128-bit CGA Type Tag [26] value for SEND, 0xXXXX XXXX XXXX
XXXX XXXX XXXX XXXX XXXX (To be generated randomly).

2. verification is required.

anchor

The 128-bit Source Address field from public keys and names of the IP header.

3. The 128-bit Destination Address field from allowed trust anchor(s), if
authorization method is not set to CGA.

All nodes that support the IP header.

4. The 32-bit ICMP header, i.e., sending of Signature options MUST record
the Type, Code, and Checksum
fields.

5. The following configuration information:

Arkko, et al. Expires June 30, 2004 [Page 18]

Internet-Draft SEcure Neighbor Discovery message header, i.e., the Reserved
field (SEND) December 2003

keypair

A public-private key pair. If authorization delegation is in the Router Solicitation message, the Cur Hop Limit,
M, O, Reserved, Router Lifetime, Reachable Time, use,
there must exist a delegation chain from a trust anchor to this
key pair.

CGA flag

A flag that indicates whether CGA is used or is not used. This
flag may be per interface or per node.

5.2.4 Performance Considerations

The construction and Retrans
Timer fields in verification of this option is computationally
expensive. In the Router Advertisement message, Reserved and
Target Address fields in NDP context, however, the Neighbor Solicitation message, R,
S, O, Reserved, and Target Address fields in hosts typically have the Neighbor
Advertisement message, and Reserved, Target Address,
need to perform only a few signature operations as they enter a link,
and
Destination Address fields in a few operations as they find a new on-link peer with which to
communicate.

Routers are required to perform a larger number of operations,
particularly when the Redirect message.

6. All NDP options preceding frequency of router advertisements is high due
to mobility requirements. Still, the Signature option.

The number of required signature
operations is constructed using on the RSA algorithm and MUST order of a few dozen ones per second, some of
which can be
encoded precomputed as private key encryption in PKCS#1 format [15]. The
signature value is computed with discussed below. A large number of
router solicitations may cause higher demand for performing
asymmetric operations, although RFC 2461 limits the RSASSA-PKCS1-v2_1 algorithm rate at which
responses to solicitations can be sent.

Signatures can be precomputed for unsolicited (multicast) Neighbor
and SHA-1 hash as defined in [15].

This field starts after Router Advertisements, if the Key Hash field. The length timing of the
Digital Signature field such future
advertisements is determined by known. Typically, solicited advertisements are
sent to the length of unicast address from which the
Signature option minus solicitation was sent.
Given that the length IPv6 header is covered by the signature, it is not
possible to precompute solicited-for advertisements.

5.3 Timestamp and Nonce options

5.3.1 Timestamp Option

The purpose of the other fields (including Timestamp option is to ensure that unsolicited
advertisements and redirects have not been replayed. The format of
this option is described in the variable length Pad field). following:

Arkko, et al. Expires April 16, June 30, 2004 [Page 17] 19]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

This variable length field contains padding, as many bytes as is
given by the Pad

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

5.3.1 Processing Rules for Senders

A node sending a message using the Signature option MUST construct | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the message fields are as follows:

Type

TBD <To be assigned by IANA> for Timestamp.

Length

The message is constructed length of the option, in its entirety.

o units of 8 octets, i.e., 2.

Reserved

A 48-bit field reserved for future use. The Signature option is added as value MUST be
initialized to zero by the last option in sender, and MUST be ignored by the message.

o For
receiver.

Timestamp

A 64-bit unsigned integer field containing a timestamp. The value
indicates the purpose number of constructing seconds since January 1,, 1970 00:00 UTC,
using a signature, fixed point format. In this format the following data
items are concatenated:

* The 128-bit CGA Type Tag.

* The source address of the message.

* The destination address of the message.

* The contents integer number of the message, starting from the ICMPv6 header,
up to but excluding the Signature option.

o The message,
seconds is contained in the form defined above, is signed using first 48 bits of the
configured private key, field, and the resulting PKCS#1 signature is put
to
remaining 16 bits indicate the Digital Signature field.

5.3.2 Processing Rules for Receivers

A message containing number of 1/64K fractions of a Signature option MUST be checked as follows:

o The Signature option MUST appear as the last option.

o
second.

5.3.2 Nonce Option

The Key Hash field MUST indicate the use purpose of the Nonce option is to ensure that an advertisement is
a known public key,
either one learned from fresh response to a preceeding CGA option, or one known solicitation sent earlier by
other means.

o TheDigital Signature field MUST have correct encoding, and do not
exceed the length of the Signature option.

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

o If the use format of a trust anchor has been configured, a valid
authorization delegation chain MUST be known between this option is described in the following:

Arkko, et al. Expires April 16, June 30, 2004 [Page 18] 20]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

receiver's trust anchor and the sender's public key.

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

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

Where the above tests MUST fields are as follows:

Type

TBD <To be silently
discarded. assigned by IANA> for Nonce.

Length

The receiver MAY silently drop packets also otherwise,
e.g., as a response to an apparent CPU exhausting DoS attack.

5.3.3 Configuration

All nodes that support the reception length of the Signature options MUST
record the following configuration information for each separate
Neighbor Discovery Protocol message type:

authorization method

This parameter determines the method through which the authority option, in units of 8 octets.

Nonce

A field containing a random number selected by the sender is determined. It can have four values:

trust anchor

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

CGA
solicitation message. The CGA property length of the sender's address is verified as
described in [26]. The sender may claim additional authority
through random number MUST be at
least 6 bytes.

5.3.3 Processing rules for senders

All solicitation messages MUST include a trust anchor, but that is neither required nor
verified.

trust anchor and CGA

Both Nonce. All solicited-for
advertisements MUST include a Nonce, copying the trust anchor and nonce value from the CGA verification is required.

trust anchor or CGA

Either
received solicitation. When sending a solicitation, the trust anchor or sender MUST
store the CGA verification is required.

anchor nonce internally so that it can recognize any replies
containing that particular nonce.

All solicitation, advertisement, and redirect messages MUST include a
Timestamp. Senders SHOULD set the Timestamp field to the current
time, according to their real time clock.

If a message has both Nonce and Timestamp options, the Nonce option
SHOULD precede the Timestamp option in order.

5.3.4 Processing rules for receivers

The public keys processing of the allowed trust anchor(s), if authorization
method Nonce and Timestamp options depends on whether
a packet is not set to CGA. a solicited-for advertisement or not. A system may
implement the distinction in various means. Section 5.3.4.1 defines

Arkko, et al. Expires April 16, June 30, 2004 [Page 19] 21]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

minSec

The minimum acceptable Sec value, if CGA verification is required
(see

the processing rules for solicited-for advertisements. Section 2
5.3.4.2 defines the processing rules for all other messages.

In addition, the following rules apply in [26]). This parameter is intended to facilitate
future extensions and experimental work. Currently, any case:

o Messages received without the minSec
value SHOULD always Timestamp option MUST be set to zero.

All nodes that support silently
discarded.

o Solicitation messages received without the sending of Signature options Nonce option MUST record
the following configuration information:

keypair

A public-private key pair. If authorization delegation is in use,
there must exist be
silently discarded.

o Advertisements sent to a delegation chain from unicast destination address without a trust anchor
Nonce option MUST be silently discarded.

o An implementation may utilize some mechanism such as a timestamp
cache to this
key pair.

CGA flag

A flag that indicates whether CGA strengthen resistance to replay attacks. When there is used a
very large number of nodes on the same link, or when a cache
filling attack is not used. This
flag may be in progress, it is possible that the cache
holding the most recent timestamp per interface sender becomes full. In
this case the node MUST remove some entries from the cache or per node.

CGA parameters

Optionally any information required
refuse some new requested entries. The specific policy as to construct CGAs, including
which entries are preferred over the used others is left as an
implementation decision. However, typical policies may prefer
existing entries over new ones, CGAs with a large Sec value over
smaller Sec and Modifier values, and so on. The issue is briefly discussed in
Appendix C.

o The receiver MUST be prepared to receive the CGA address itself.

5.4 Timestamp and Nonce
options

5.4.1 Timestamp Option in any order, as per RFC 2461 [7] Section 9.

5.3.4.1 Processing solicited-for advertisements

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

If the message contains a Nonce option, but the Nonce value is to ensure that unsolicited
advertisements and redirects have not been replayed. The format of
recognized, the Timestamp option message MUST be silently discarded.

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

If the message is described accepted, the receiver SHOULD store the receive
time of the message and the time stamp time 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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the fields are message, as follows:
specified in Section 5.3.4.2

Arkko, et al. Expires April 16, June 30, 2004 [Page 20] 22]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

Type

TBD <To

5.3.4.2 Processing all other messages

Receivers SHOULD be assigned by IANA> configured with an allowed timestamp Delta value,
a "fuzz factor" for Timestamp.

Length comparisons, and an allowed clock drift
parameter. The length of recommended default value for the option, in units of 8 octets, i.e., 2.

Reserved

A 48-bit field reserved allowed Delta is
3,600 seconds (1 hour), for future use. fuzz factor 1 second, and for clock drift
1% (0.01).

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

The value MUST be
initialized to zero by receive time of the sender, and MUST be ignored by last received, accepted SEND message.
This is called RDlast.

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

Receivers SHOULD then check the
receiver. Timestamp

A 64-bit unsigned integer field containing as follows:

o When a timestamp. The value
indicates the number of seconds since January 1,, 1970 00:00 UTC,
using message is received from a fixed point format. In this format the integer number of
seconds new peer, i.e., one that is contained not
stored in the first 48 bits of cache, the field, received timestamp, TSnew, is checked and
the
remaining 16 bits indicate the number of 1/64K fractions of a
second.

5.4.2 Nonce Option

The purpose of the Nonce option packet is to ensure that an advertisement accepted if the timestamp is
a fresh response recent enough with
respect to a solicitation sent earlier by the receiving same
node. The format reception time of the Nonce option is packet, RDnew:

-Delta < (RDnew - TSnew) < +Delta

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

o If the
following:

Where timestamp is NOT within the fields are as follows:

Type

TBD <To be assigned by IANA> for Nonce.

Arkko, et al. Expires April 16, 2004 [Page 21]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Length

The length of boundaries but the option, in units of 8 octets.

Nonce

A field containing message is a random number selected
Neighbor Solicitation message that should be responded to by the sender of
receiver, the receiver MAY respond to the
solicitation message. The length of However, if it
does respond to the random number MUST be at
least 6 bytes.

5.4.3 Processing rules for senders

All solicitation messages MUST include a Nonce. All solicited-for
announcements message, it MUST include a Nonce, copying the nonce value from the
received solicitation. When sending NOT create a solication, the sender MUST
store the nonce internally so that it can recognize any replies
containing neighbor cache
entry. This allows nodes that particular nonce.

All NDP messages MUST include a Timestamp. Senders SHOULD set the
Timestamp field to the current time, according to have large difference in their real time
clock.

If
clocks to still communicate with each other, by exchanging NS/NA
pairs.

o When a message is received from a known peer, i.e., one that
already has both Nonce and Timestamp options, an entry in the Nonce option
SHOULD precede cache, the Timestamp option in order. The receiver time stamp is checked
against the previously received SEND message:

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

o If TSnew < TSlast, which is possible if packets arrive rapidly and
out of order, TSlast MUST NOT be
prepared to receive them in any order, as per RFC 2461 [6] Section 9.

5.4.4 Processing rules for receivers

The processing of updated, i.e., the Nonce and Timestamp options depends stored TSlast
for a given node MUST NOT ever decrease. Otherwise TSlast SHOULD
be updated. Independent on whether
a packet TSlast is a solicited-for advertisement updated or not. A system may
implement the distinction not,
RDlast is updated in various means. Section 5.4.4.1 defines
the processing rules for solicited-for advertisements. Section
5.4.4.2 defines the processing rules for all other messages.

An implementation may utilize some mechanism such as any case.

Arkko, et al. Expires June 30, 2004 [Page 23]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

6. Authorization Delegation Discovery

Several protocols (NDP included) allow a timestamp
cache node to strengthen resistance automatically
configure itself based on information it learns shortly after
connecting to replay attacks. When there is a
very large number of nodes new link. It is particularly easy to configure
"rogue" routers on the same an unsecured link, or when a cache filling
attack is in progress, and it is possible that the cache holding particularly
difficult for a node to distinguish between valid and invalid sources
of information, when the most
recent timestamp per sender becomes full. In node needs this case information before being
able to communicate with nodes outside of the node MUST
remove some entries from link.

Since the cache or refuse some new requested
entries. The specific policy as newly-connected node cannot communicate off-link, it cannot
be responsible for searching information to which entries are preferred over help validating the others is left as
router(s); however, given a chain of appropriately signed
certificates, it can check someone else's search results and conclude
that a particular message comes from an implementation decision. However, authorized source. In the
typical
policies may prefer existing entries over new ones, CGAs with case, a large
Sec value over smaller Sec values, router, which is already connected to beyond the
link, can (if necessary) communicate with off-link nodes and so on.
construct such a certificate chain.

The issue is briefly
discussed in Appendix C.

Arkko, et al. Expires April 16, 2004 [Page 22]

Internet-Draft SEcure Secure Neighbor Discovery (SEND) October 2003

5.4.4.1 Processing solicited-for advertisements

The receiver MUST verify that it has recently send Protocol mandates a matching
solicitation, certificate format
and introduces two new ICMPv6 messages that are used between hosts
and routers to allow the received advertisement does contain host to learn a copy
of the Nonce sent in certificate chain with the solicitation.

If
assistance of the message does not contain router.

6.1 Certificate Format

The certificate chain of a Nonce option, it MAY be considered
as router terminates in a non-solicited-for announcement, and processed according Router
Authorization Certificate that authorizes a specific IPv6 node to
Section 5.4.4.2.

If the message does contain act
as a Nonce option, but the Nonce value is router. Because authorization chains are not recognized, a common practice
in the message MUST be silently dropped.

If Internet at the message time this specification is accepted, the receiver SHOULD store being written, the receive
time
chain MUST consist of the message and the time stamp time in the message, as
specified standard Public Key Certificates (PKC, in Section 5.4.4.2

5.4.4.2 Processing all other messages

Receivers SHOULD be configured with an allowed timestamp Delta value
and an allowed clock drift parameter. The recommended default value
for the allowed Delta is 3,600 seconds (1 hour) and for clock dritf
1% (0.01).

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

The receive time
sense of the last received, acepted SEND message. This
is called RDlast. [18]). The time stamp in the last received, accepted SEND message. This
is called TSlast.

Receivers SHOULD then check the Timestamp field as follows:

o When a message is received certificate chain MUST start from the identity
of a new peer, i.e., one trust anchor that is not
stored in the cache, shared by the received timestamp, TSnew, is checked host and the packet is accepted if router. This
allows the timestamp is recent enough with
respect host to anchor trust for the receival time of router's public key in the packet, RDnew:

-Delta < (RDnew - TSnew) < +Delta

The RDnew and TSnew values SHOULD
trust anchor. Note that there MAY be stored into the cache multiple certificates issued by
a single trust anchor.

6.1.1 Router Authorization Certificate Profile

Router Authorization Certificates be X.509v3 certificates, as
RDlast defined
in RFC 3280 [10], and TSlast.

o If the timestamp is NOT within MUST contain at least one instance of the boundaries but X.509
extension for IP addresses, as defined in [11]. The parent
certificates in the message is certificate chain MUST contain one or more X.509
IP address extensions, back up to a
Neighbor Solicitation message trusted party (such as the user's
ISP) that should be responded to by configured the
receiver, original IP address space block for the receiver MAY respond to
router in question, or delegated the message. However, if it right to do so for someone. The
certificates for intermediate delegating authorities MUST contain
X.509 IP address extension(s) for subdelegations. The router's

Arkko, et al. Expires April 16, June 30, 2004 [Page 23] 24]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

does respond to

certificate is signed by the message, it delegating authority for the prefixes
the router is authorized to to advertise.

The X.509 IP address extension MUST NOT create a neighbor cache
entry. contain at least one
addressesOrRanges element. This allows nodes that have large difference in their
clocks to still communicate element MUST contain an
addressPrefix element with each other, by exchanging NS/NA
pairs.

o When a message is received from a known peer, i.e., one that
already has an entry in IPv6 address prefix for a prefix the cache,
router or the time stamp intermediate entity is checked
against the previously received SEND message:

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

o authorized to advertise. If TSnew < TSlast, which the
entity is possible if packets arrive rapidly and
out allowed to route any prefix, the used IPv6 address prefix
is the null prefix, 0/0. The addressFamily element of order, TSlast the containing
IPAddrBlocks sequence element MUST NOT be updated, i.e., contain the stored TSlast IPv6 Address Family
Identifier (0002), as specified in [11] for IPv6 prefixes. Instead
of an addressPrefix element, the addressesOrRange element MAY contain
an addressRange element for a given range of prefixes, if more than one
prefix is authorized. The X.509 IP address extension MAY contain
additional IPv6 prefixes, expressed either as an addressPrefix or an
addressRange.

A SEND node receiving a Router Authorization Certificate MUST NOT ever decrease. Otherwise TSlast SHOULD
be updated. Independent on first
check whether TSlast is updated the certificate's signature was generated by the
delegating authority. Then the client MUST check whether all the
addressPrefix or not,
RDlast is updated 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 case.

5.5 Proxy Neighbor Discovery

The Target Address
addressPrefix entries in Neighbor Advertisement the delegating authority's certificate. If
an addressPrefix or addressRange is required to be equal
to not contained within the source address
delegating authority's prefixes or ranges, the client MAY attempt to
take an intersection of the packet, except ranges/prefixes, and use that
intersection. If the addressPrefix in the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case of proxy
Neighbor Discovery. Proxy Neighbor Discovery the
intersection is not supported by
this specification; it the parent prefix or range.) If the resulting
intersection is planned to be specified in a future
document.

Arkko, et al. Expires April 16, 2004 [Page 24]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

6. Authorization Delegation Discovery

Several protocols, including empty, the IPv6 Neighbor Discovery Protocol,
allow a node to automatically configure itself based on information
it learns shortly after connecting to a new link. It is particularly
easy to configure "rogue" routers on an unsecured link, and it is
particularly difficult client MUST NOT accept the certificate.

The above check SHOULD be done for a node to distinguish between valid and
invalid sources all certificates in the chain. If
any of information, when the node checks fail, the client MUST NOT accept the certificate.
The client also needs this information
before being able to communicate with nodes outside perform validation of the link. advertised prefixes as
discussed in Section 7.3.

Since the newly-connected node cannot communicate off-link, it can is possible that some PKC certificates used with SEND do not be responsible for searching information to help validating
immediately contain the
router(s); however, given a chain of appropriately signed
certificates, it can check someone else's search results and conclude
that a particular message comes from X.509 IP address extension element, an authorized source. In
implementation MAY contain facilities that allow the
typical case, a router, which is already connected prefix and range
checks to beyond be relaxed. However, any such configuration options SHOULD
be off by default. That is, the
link, can (if necessary) communicate with off-link nodes system SHOULD have a default
configuration that requires rigorous prefix and
construct such range checks.

The following is an example of a certificate chain.

The Secure Neighbor Discovery Protocol introduces two new ICMPv6
messages Suppose that are used between hosts and routers to allow
ispgroup.com is the trust anchor. The host has this certificate for
it:

Arkko, et al. Expires June 30, 2004 [Page 25]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

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

When the host attaches then to
learn a linked served by
router_x.isp_foo.com, it receives the following certificate chain with chain:

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

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

When processing the assistance of three certificates, the router. Where
hosts themselves are certified usual RFC 3280
certificate path validation is performed, for instance by a trust anchor, these messages MAY
also optionally checking
for revoked certificates. In addition, the IP addresses in the
delegation extension must be used between hosts to acquire subsumed by the IP addresses in the
delegation extension in the issuer's certificate. So in this
example, R1, ..., Rs must be subsumed by Q1,...,Qr, and Q1,...,Qr
must be subsumed by P1,...,Pk. If the peer's certificate chain. However, chain is valid,
then router_foo.isp_foo_example.com is authorized to route the details of such usage are left for
future specification.
prefixes R1,...,Rs.

6.2 Certificate Transport

The Delegation Chain Solicitation (DCS) message is sent by a host
when it wishes to request a certificate chain between a router and
the one of the host's trust anchors. The Delegation Chain

Arkko, et al. Expires June 30, 2004 [Page 26]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

Advertisement (DCA) message is sent as an answer to the DCS message.
It MAY be periodically sent to the link-scoped All-Nodes multicast
address.
These messages are separate from the rest of Neighbor and Router
Discovery, in order to reduce the effect of the potentially
voluminous certificate chain information on other messages.

The Authorization Delegation Discovery (ADD) process does not exclude
other forms of discovering certificate chains. For instance, during
fast movements mobile nodes may learn information - including the
certificate chains - of the next router from a previous router.

6.1

Where hosts themselves are certified by a trust anchor, these
messages MAY also optionally be used between hosts to acquire the
peer's certificate chain. However, the details of such usage are
left for future specification.

6.2.1 Delegation Chain Solicitation Message Format

Hosts send Delegation Chain Solicitations in order to prompt routers
to generate Delegation Chain Advertisements quickly. Advertisements.

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

Arkko, et al. Expires April 16, 2004 [Page 25]

IP Fields:

Source Address

An IP

A link-local unicast address assigned to the sending interface,
or 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

Arkko, et al. Expires June 30, 2004 [Page 27]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

ICMP Fields:

Type

TBD <To be assigned by IANA> for Delegation Chain Solicitation.

Code

Checksum

The ICMP checksum [8]. [9].

Identifier

A 16-bit unsigned integer field, acting as an identifier to
help matching advertisements to solicitations. The Identifier
field MUST NOT be zero, and its value SHOULD be randomly
generated. (This randomness does not need to be
cryptographically hard, though. Its purpose is to avoid
collisions.)

Arkko, et al. Expires April 16, 2004 [Page 26]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Reserved

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

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.3. 6.2.3. If there are is more than
one Trust Anchor options, option, the options past the first one may
contain any types of Trust Anchors.

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.

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

Arkko, et al. Expires June 30, 2004 [Page 28]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

6.2.2 Delegation Chain Advertisement Message Format

Routers send out Delegation Chain Advertisement messages
periodically, or in response
to a Delegation Chain Solicitation.

IP Fields:

Source Address

MUST be a

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

Arkko, et al. Expires April 16, 2004 [Page 27]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Hop Limit

255

ICMP Fields:

Type

TBD <To be assigned by IANA> for Delegation Chain
Advertisement.

Code

Arkko, et al. Expires June 30, 2004 [Page 29]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

Checksum

The ICMP checksum [8]. [9].

Identifier

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

Component

A 16-bit unsigned integer field, used for informing the
receiver which certificate is being sent, and how many are
still left to be sent in the whole chain.

A single advertisement MUST be broken into separately sent
components if there is more than one Certificate option, in
order to avoid excessive fragmentation at the IP layer. Unlike
the fragmentation at the IP layer, individual components of an
advertisement may be stored and used before all the components
have arrived; this makes them slightly more reliable and less
prone to Denial-of-Service attacks.

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

The components MUST be ordered so that the trust anchor end of
the chain is the one sent first. Each certificate sent after
it can be verified with the previously sent certificates. The

Arkko, et al. Expires April 16, 2004 [Page 28]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003
certificate of the sender comes last.

Reserved

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

Valid Options:

Certificate

One certificate is provided in each Certificate option, to
establish a (part of a) certificate chain to a trust anchor.

The certificate of the trust anchor itself SHOULD NOT be

Arkko, et al. Expires June 30, 2004 [Page 30]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

included.

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.

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.

6.3 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.2.3 Trust Anchor Option

The format of the Trust Anchor option is as 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 | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the fields are as follows:

Type

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

Length

The length of the option, (including the Type, Length, Name Type,

Arkko, et al. Expires April 16, 2004 [Page 29]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003
Name Length, and Name fields,) in units of 8 octets.

Name Type

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

1 DER Encoded X.501 Name
2 FQDN

Arkko, et al. Expires June 30, 2004 [Page 31]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

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
DER encoded X.501 certificate Name, represented and encoded
exactly as in the matching X.509v3 trust anchor certificate.

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

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

6.4

6.2.4 Certificate Option

The format of the certificate option is as 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 | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the fields are as follows:

Arkko, et al. Expires April 16, 2004 [Page 30]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Type

TBD <To be assigned by IANA> for Certificate.

Length

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

Cert

Arkko, et al. Expires June 30, 2004 [Page 32]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

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

Pad Length

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

Certificate

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

6.5 Router Authorization Certificate Format

The certificate chain of a router terminates in a Router
Authorization Certificate that authorizes a specific IPv6 node to act
as
6.1.1.

6.2.5 Processing Rules for Routers

Routers SHOULD possess a router. Because authorization chains are not key pair and a common practice
in the Internet certificate from at the time this specification is being written, the
chain least one
certificate authority.

A router MUST consist silently discard any received Delegation Chain
Solicitation messages that do not satisfy all of standard Public Key Certificates (PKC, the following
validity checks:

o All requirements listed in Section 6.2.1 are fulfilled.

o If the
sense of [21]). The certificates chain MUST start from message includes an IP Authentication Header, the identity message
authenticates correctly.

The contents of a trust anchor that is shared by the host Reserved field, and the router. This
allows the host of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to anchor trust for the router's public key in protocol
may specify the
trust anchor. Note contents of the Reserved field or add new options;
backward-incompatible changes may use different Code values. The
contents of any defined options that there MAY are not specified to be multiple certificates issued by
a single trust anchor.

6.5.1 Router Authorization Certificate Profile used
with Router Authorization Certificates Solicitation messages MUST be X.509v3 certificates, as defined
in RFC 3280 [11], ignored and MUST contain at least one instance of the X.509
extension for IP addresses, as defined packet
processed in [13]. the normal manner. The parent
certificates in 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 certificate chain MUST contain one or more X.509

Arkko, et al. Expires April 16, June 30, 2004 [Page 31] 33]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

IP address extensions, back up

response to the delegating authority (the
Regional Address Registry or IANA) that delegated link-scoped All-Nodes multicast address. If the original IP
source address space block. The certificates for intermediate delegating
authorities was a unicast address, the router MUST contain X.509 IP address extension(s) for
subdelegations. The router's certificate is signed by send the delegating
authority for
response to the prefixes Solicited-Node multicast address corresponding to the
source address. Routers SHOULD NOT send Delegation Chain
Advertisements more than MAX_DCA_RATE times within a second. When
there are more solicitations than this, the router is authorized to SHOULD send the
response to advertize.

The X.509 IP the All-Nodes multicast address regardless of the source
address extension MUST contain at least one
addressesOrRanges element that contains an addressPrefix element with appeared in the solicitation.

In an IPv6 address prefix for a prefix advertisement, the router or SHOULD include suitable Certificate
options so that a delegation chain to the intermediate
entity solicited trust anchor can
be established. The anchor is authorized to advertize. identified by the Trust Anchor option.
If the entity Trust Anchor option is allowed to route
any prefix, represented as a DER Encoded X.501
Name, then the used IPv6 address prefix is Name must be equal to the null prefix, 0/0.
The addressFamily element of Subject field in the containing IPAddrBlocks sequence
element MUST contain
anchor's certificate. If the IPv6 AFI (0002), as specified in [13] for
IPv6 prefixes. Instead of an addressPrefix element, the
addressesOrRange element MAY contain an addressRange element for a
range of prefixes, if more than one prefix Trust Anchor option is authorized. The X.509
IP address extension MAY contain additional IPv6 prefixes, expressed
either represented as
an addressPrefix or an addressRange.

A SEND node receiving a Router Authorization Certificate MUST first
check whether FQDN, the certificate's signature was generated by FQDN must be equal to an FQDN in the
delegating authority. Then subjectAltName
field of the client MUST check whether all anchor's certificate. The router SHOULD include the
addressPrefix or addressRange entries
Trust Anchor option(s) in the router's certificate are
contained within advertisement for which the address ranges in delegation
chain was found.

If the delegating authority's
certificate, and whether router is unable to find a chain to the addressPrefix entries match requested anchor, it
SHOULD send an advertisement without any
addressPrefix entries in certificates. In this case
the delegating authority's certificate. If
an addressPrefix or addressRange is not contained within router SHOULD include the
delegating authority's prefixes or ranges, Trust Anchor options which were
solicited.

6.2.6 Processing Rules for Hosts

Hosts SHOULD possess the client MAY attept to
take an intersection public key and trust anchor name of the ranges/prefixes, at least
one certificate authority, they SHOULD possess their own key pair,
and use they MAY posses a certificate from the above mentioned
certificate authority.

A host MUST silently discard any received Delegation Chain
Advertisement messages that
intersection. If do not satisfy all of the addressPrefix following
validity checks:

o All requirements listed in Section 6.2.2 are fulfilled.

o If the certificate is the null
prefix, 0/0, such an intersection SHOULD be used. (In that case the
intersection is the parent prefix or range.) If the resulting
intersection is empty, the client MUST NOT accept the certificate.

The above check SHOULD be done for all certificates in the chain
received through DCA messages. If any of the checks fail, the client
MUST NOT accept the certificate.

Since it is possible that some PKC certificates used with SEND do not
immediately contain the X.509 IP address extension element, an
implementation MAY contain facilities that allow the prefix and range
checks to be relaxed. However, any such configuration options SHOULD
be off by default. That is, the system SHOULD have a default
configuration that requires rigorious prefix and range checks.

6.6 Processing Rules for Routers

Arkko, et al. Expires April 16, 2004 [Page 32]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Routers SHOULD possess a key pair and a certificate from at least one
certificate authority.

A router MUST silently discard any received Delegation Chain
Solicitation messages that do not satisfy all of the following
validity checks:

o The IP Hop Limit field MUST have a value of 255, i.e., the packet
could not possibly have been forwarded by a router.

o If the message includes message includes an IP Authentication Header, the message
authenticates correctly.

o ICMP Checksum is valid.

o ICMP Code is 0.

o ICMP length (derived from the IP length) is 8 or more octets.

o Identifier field is non-zero.

o All included options have a length that is greater than zero.

The contents of the Reserved field, and of any unrecognized options,
MUST be ignored. Future, 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 Delegation Chain Advertisement messages MUST be ignored and the
packet processed in the normal manner. The only defined option that may
appear is the Trust Anchor option. A solicitation that passes the
validity checks is called a "valid solicitation".

Routers MAY send unsolicited Delegation Chain Advertisements for
their configured trust anchor(s). When such advertisements are sent,
their timing MUST follow the rules given for Router Advertisements in
RFC 2461 [6]. The only defined options options that

Arkko, et al. Expires June 30, 2004 [Page 34]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

may appear are the Certificate and Trust Anchor options. At least one Certificate option
MUST be present. Router SHOULD also include at least one Trust
Anchor option to indicate the trust anchor on which An
advertisement that passes the Certificate validity checks is based.

In addition to sending periodic, unsolicited advertisements, called a router
sends advertisements "valid
advertisement".

Hosts SHOULD store certificate chains retrieved in response to valid solicitations received on Delegation Chain
Discovery messages if they start from an advertising interface. If anchor trusted by the source address host.
The certificate chains SHOULD be verified, as defined in the solicitation
was the unspecified address, the router Section 6.1,
before storing them. Routers MUST send the response to the
link-scoped All-Nodes multicast address. If the source address was a
unicast address, the router MUST send certificates one by one,
starting from the response to trust anchor end of the

Arkko, et al. Expires April 16, 2004 [Page 33]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Solicited-Node multicast address corresponding chain. Except for
temporary purposes to the source address.

In a solicited-for advertisement, the router allow for message loss and reordering, hosts
SHOULD include suitable
Certificate options so that NOT store certificates received in a delegation chain Delegation Chain
Advertisement unless they contain a certificate which can be
immediately verified either to the solicited trust anchor can be established. The anchor is identified by the Trust
Anchor option. If the Trust Anchor option is represented as or to a DER
Encoded X.501 Name, then the Name must certificate
which has been verified earlier.

Note that it may be equal useful to the Subject field
in the anchor's certificate. If the Trust Anchor option is
represented as an FQDN, the FQDN must be equal cache this information and implied
verification results for use over multiple attachments to an FQDN in the
subjectAltName field of the anchor's certificate.
network.

The router SHOULD
include the Trust Anchor option(s) in the advertisement for which the host has a need to retrieve a delegation chain was found.

If when a Router
Advertisement has been received with a public key that is not stored
in the router hosts' cache of certificates, or there is unable to find a no authorization
delegation chain to the requested anchor, it
SHOULD send an advertisement without any certificates. host's trust anchor. In this case
the router SHOULD include these situations,
the Trust Anchor options which were
solicited.

Rate limiting of host MAY transmit up to MAX_DCS_MESSAGES Delegation Chain Advertisements is performed as
specified for Router Advertisements in RFC 2461 [6].

6.7 Processing Rules for Hosts

Hosts SHOULD possess the public key and trust anchor name of
Solicitation messages, each separated by at least
one certificate authority, they DCS_INTERVAL
seconds.

Delegation Chain Solicitations SHOULD possess their own key pair,
and they MAY posses NOT be sent if the host has a
currently valid certificate chain from the above mentioned
certificate authority.

A a reachable router to a trust
anchor.

When soliciting certificates for a router, a host MUST silently discard any received send
Delegation Chain
Advertisement messages that do not satisfy all of the following
validity checks:

o IP Source Address MUST be a unicast address. Note that routers
may use multiple addresses, and therefore this address not
sufficient for the unique identification of routers.

o IP Destination Address MUST be Solicitations either to the link-scoped All-Nodes All-Routers multicast address
address, if it has not selected a default router yet, or to the
default router's IP address, if it has already been selected.

If two hosts want to establish trust with the DCS and DCA messages,
the DCS message SHOULD be sent to the Solicited-Node multicast
address
corresponding to one of the unicast addresses assigned receiver. The advertisements SHOULD be sent as
specified above for routers. However, the exact details are left for
a future specification.

When processing possible advertisements sent as responses to a
solicitation, the
host.

o The IP Hop Limit host MAY prefer to process first those
advertisements with the same Identifier field MUST have a value of 255, i.e., the packet
could not possibly have been forwarded by a router.

o If as in the message includes an IP Authentication Header,
solicitation. This makes Denial-of-Service attacks against the message
authenticates correctly.

o ICMP Checksum is valid.
mechanism harder (see Section 9.3).

Arkko, et al. Expires April 16, June 30, 2004 [Page 34] 35]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

o ICMP Code is 0.

o ICMP length (derived from the IP length) is 16 or more octets.

o All included options have a length

7. Addressing

7.1 CGA Addresses

Nodes that is greater than zero.

The contents use stateless address autoconfiguration, SHOULD generate a
new CGA as specified in Section 4 of [12] for each new
autoconfiguration run. The nodes MAY continue to use the Reserved field, same public
key and of any unrecognized options,
MUST be ignored. Future, backward-compatible changes to the protocol
may specify modifier, and start the contents process from Step 4.

By default, a SEND-enabled node SHOULD use only CGAs as its own
addresses. Other types of the Reserved field addresses MAY be used in testing,
diagnostics or add new options;
backward-incompatible changes may use other purposes. However, this document does not
describe how to choose between different Code values. The
contents types of any addresses for
different communications. A dynamic selection can be provided by an
API, such as the one defined options that in [22].

7.2 Redirect Addresses

If the Target Address and Destination Address fields in the ICMP
Redirect message are not specified to be equal, then this message is used
with Delegation Chain Advertisement to inform hosts
that a destination is in fact a neighbor. In this case the receiver
MUST verify that the given address falls within the range defined by
the router's certificate. Redirect messages failing this check MUST
be ignored and silently discarded.

Note that RFC 2461 rules prevent a bogus router from sending a
Redirect message when the
packet processed in host is not using the normal manner. bogus router as a
default router.

7.3 Advertised Prefixes

The only defined options that
may appear are router's certificate defines the Certificate and Trust Anchor options. An
advertisement address range(s) that passes the validity checks it is called
allowed to advertise. Upon processing a "valid
advertisement".

Hosts Prefix Information option
within a Router Advertisement, nodes SHOULD store certificate chains retrieved verify that the prefix
specified in Delegation Chain
Discovery messages if they start from an anchor trusted by this option falls within the host.
The certificates chains SHOULD be verified, as range defined in Section
6.5, before storing them. Routers are required to send by the
certificates one by one, starting from the trust anchor end of
certificate, if the
chain. Except for temporary purposes to allow for message loss and
reordering, hosts SHOULD NOT store certificates received in a
Delegation Chain Advertisement unless they contain a certificate
which can be immediately verified either to the trust anchor or to contains a
certificate which has been verified earlier.

Note that it may be useful to cache prefix extension. Options
failing this information and implied
verification results for check MUST be silently discarded.

Nodes SHOULD use over multiple attachments to one of the
network.

When an interface becomes enabled, a host may be unwilling to wait certified prefixes for the next unsolicited Delegation Chain Advertisement. To obtain
such advertisements quickly, a host MAY transmit up to
MAX_RTR_SOLICITATIONS Delegation Chain Solicitation messages, each
separated by at least RTR_SOLICITATION_INTERVAL seconds. Delegation
Chain Solicitations MAY be sent after any stateless
autoconfiguration. If none of the following events:

o The interface is initialized at system startup time.

o The interface advertised prefixes match, then
either there is reinitialized after a temporary interface failure configuration problem or after being temporarily disabled by system management.

o The system changes from being a the advertising router to being is
an attacker, and the host MUST use a host, by having different advertising router as
its IP forwarding capability turned off default router (if available). If the node is performing
stateful autoconfiguration, it SHOULD check the address provided by system management.

o The host attaches to a link for
the first time. DHCP server against the certified prefixes and MUST NOT use the
address if the prefix is not certified.

In any case, the user should inform the network operator upon

Arkko, et al. Expires April 16, June 30, 2004 [Page 35] 36]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

o A movement has been indicated by lower layers

receiving an address or has been inferred
from changed information in prefix outside the certified range, since
this is either a Router Advertisement.

o The host re-attaches misconfiguration or an attack.

If the network operator wants to a link after being detached for some time.

o A Router Advertisement has been received constrain which routers support
particular prefixes, routers SHOULD be configured with a public key certificates
having prefixes listed in the prefix extension. Routers so
configured MUST advertise exactly the prefixes for which they are
certified.

Network operators that is do not stored in want to constrain particular routers to
specific prefixes SHOULD configure routers with certificates
containing either the hosts' cache of certificates, null prefix or there is no
authorization delegation chain to the host's trust anchor.

Delegation Chain Solicitations SHOULD NOT be sent if prefix extension at all.

7.4 Limitations

This specification does not address the host has protection of NDP packets for
nodes that are configured with a
currently valid static address (e.g., PREFIX::1).
Future certificate chain from a reachable router to a trust
anchor.

When soliciting certificates based authorization specifications are
needed for a router, a host MUST send
Delegation Chain Solicitations either to such nodes.

It is outside the All-Routers multicast
address, if it has not selected a default router yet, or scope of this specification to describe the
default router's IP address, if it has already been selected.

If two hosts want to establish use of
trust anchor authorization between nodes with the DCS and DCA messages,
the DCS message SHOULD dynamically changing
addresses. Such dynamically changing addresses may be sent to the Solicited-Node multicast result of
stateful or stateless address autoconfiguration, or through the use
of RFC 3041 [17] addresses. If the receiver. The advertisements SHOULD CGA method is not used, nodes
would be sent as
specified above for routers. However, required to exchange certificate chains that terminate in a
certificate authorizing a node to use an IP address having a
particular interface identifier. This specification does not specify
the exact details format of such certificates, since there are left for currently a future specification.

Delegation Chain Solicitations SHOULD be rate limited few
cases where such certificates are required by the link layer and timed
similarly with Router Solicitations, as specified in RFC 2461 [6].

When processing possible advertisements sent as responses it
is up to the link layer to provide certification for the interface
identifier. This may be the subject of a
solicitation, future specification. It
is also outside the host MAY prefer scope of this specification to process first those
advertisements describe how
stateful address autoconfiguration works with the same Identifier field value as CGA method.

The Target Address in Neighbor Advertisement is required to be equal
to the
solicitation. This makes Denial-of-Service attacks against source address of the
mechanism harder (see Section 11.3). packet, except in the case of proxy
Neighbor Discovery. Proxy Neighbor Discovery is not supported by
this specification; it is planned to be specified in a future
document.

Arkko, et al. Expires April 16, June 30, 2004 [Page 36] 37]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

7. Securing Neighbor Discovery

8. Transition Issues

During the transition to secure links or as a policy consideration,
network operators may want to run a particular link with a mixture of
secure and insecure nodes. Nodes that support SEND

This section describes how to use SHOULD support
the mechanisms from Section 5,
Section 6, use of SEND and the reference [26] in order to provide security for
Neighbor Discovery.

There is no requirement that nodes use both Secure Neighbor Discovery
(as described in this Section) legacy NDP at the same time.

In a mixed environment, SEND nodes receive both secure and Secure Router Discovery (as
described in Section 8. They MAY be used indepedently.

7.1 Neighbor Solicitation Messages

All Neighbor Solicitation insecure
messages are protected with SEND.

7.1.1 Sending Secure Neighbor Solicitations

Secure Neighbor Solicitation but give priority to "secured" ones. Here, the "secured"
messages are sent ones that contain a valid signature option, as described in RFC
2461 specified
above, and 2462, with the additional requirements as listed in the
following:

All Neighbor Solicitation "insecure" messages sent MUST contain the Nonce,
Timestamp, and Signature options, and MAY are ones that contain the CGA no signature
option.
The Signature option MUST be constructed with the sender's key
pair, using

SEND nodes send only secured messages. Legacy Neighbor Discovery
nodes will obviously send only insecure messages. Per RFC 2461 [7],
such nodes will ignore the configured authorization method(s), unknown options and if
applicable, using will treat secured
messages in the trust anchor and/or minSec value same way as
configured.

7.1.2 Receiving Secure Neighbor Solicitations

Received Neighbor Solicitation messages are processed they treat insecure ones. Secured and
insecure nodes share the same network resources, such as described prefixes and
address spaces.

In a mixed environment SEND nodes follow the protocols defined in RFC
2461 and 2462, RFC 2462 with the additional SEND-related requirements as
listed in the following:

Neighbor Solicitation messages received without the Nonce,
Timestamp, or Signature option following exceptions:

o All solicitations sent by SEND nodes MUST be silently discarded. The
Signature option secured.

o Unsolicited advertisements sent by a SEND node MUST be constructed with the expected
authorization method(s), the used key being within the configured
minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value.

7.2 Neighbor Advertisement Messages

All Neighbor Advertisement messages are protected with SEND.

7.2.1 Sending Secure Neighbor secured.

o A SEND node MUST send a secured advertisement in response to a
secured solicitation. Advertisements

Arkko, et al. Expires April 16, 2004 [Page 37]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Secure Neighbor Advertisement messages are sent as described in RFC
2461 and 2462, with the additional requirements as listed in the
following:

All Neighbor Advertisement messages sent response to an
insecure solicitation MUST be sent with the
Timestamp and Signature options and MAY be sent with the CGA
option. The Signature option secured as well, but MUST be constructed with NOT
contain the sender's
key pair, setting Nonce option.

o A SEND node that uses the CGA authorization method and additional
information as configured. for protecting
Neighbor Advertisements sent Solicitations SHOULD perform Duplicate Address Detection
as follows. If Duplicate Address Detection indicates the
tentative address is already in response to use, generate a Neighbor
Solicitation MUST additionally contain new tentative CGA
address. If after 3 consecutive attempts no non-unique address
was generated, log a copy of the Nonce option
included in system error and give up attempting to
generate an address for that interface.

When performing Duplicate Address Detection for the solicitation.

7.2.2 Receiving Secure first
tentative address, accept both secured and insecure Neighbor
Advertisements

Received Neighbor Advertisement messages are processed as described
in RFC 2461 and 2462, with the additional SEND-related requirements Solicitations received as listed in response to the following:

Any eighbor Advertisement messages received without
Neighbor Solicitations. When performing Duplicate Address
Detection for the Timestamp second or Signature options MUST be silently discarded. third tentative address, ignore
insecure Neighbor Advertisements and Solicitations.

o The Signature
option MUST be constructed with the expected authorization
method(s), the used key being within the configured minimum (and
maximum) allowable key size, and if applicable, using an
acceptable trust anchor and/or minSec value.

Received Neighbor Advertisements sent to a unicast destination
address without node SHOULD have a Nonce configuration option MUST be silently discarded.

7.3 Other Requirements

Upon receiving a message for which the receiver has no certificate
chain to a trust anchor, the receiver MAY use Authorization
Delegation Discovery to learn the certificate chain of the peer.

Nodes that use stateless address autoconfiguration, SHOULD generate a
new CGA as specified in Section 4 of [26] for each new
autoconfiguration run. The nodes MAY continue causes it to use the same public
key and modifier, and start the process from Step 4.

This specification does not address the protection of Neighbor
Discovery packets for nodes that are configured with a static address
(e.g., PREFIX::1). Future certificate chain based authorization
specifications are needed for such nodes.

Arkko, et al. Expires April 16, June 30, 2004 [Page 38]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

It is outside the scope of this specification to describe

ignore insecure advertisements even when performing Duplicate
Address Detection for the use of
trust anchor authorization between nodes with dynamically changing
addresses. Such dynamically changing addresses may first tentative address. This
configuration option SHOULD be disabled by default. This is
recovery mechanism, in case attacks against the result of
stateful or stateless first address autoconfiguration, or through
become common.

o The Neighbor Cache, Prefix List and Default Router list entries
MUST have a secured/insecure flag that indicates whether the use
message that caused the creation or last update of RFC 3041 [9] addresses. If the CGA method is not used, nodes
would be required entry was
secured or insecure. Received insecure messages MUST NOT cause
changes to exchange certificate chains that terminate existing secured entries in a
certificate authorizing a node to use an IP address having a
particular interface identifier. This specification does not specify the format Neighbor Cache, Prefix
List or Default Router List. Received secured messages cause an
update of such certificates, since there are currently a few
cases where such certificates are required by the link layer matching entries and it flagging of them as secured.

o The conceptual sending algorithm is up to the link layer to provide certification modified so that an insecure
router is selected only if there is no reachable SEND router for
the interface
identifier. This may be prefix. That is, the subject of algorithm for selecting a future specification. It
is also outside the scope of this specification default router
favors reachable SEND routers over reachable non-SEND ones.

o A SEND node SHOULD have a configuration option that causes it to describe how
stateful address autoconfiguration works with the CGA method.
ignore all insecure Neighbor Solicitation and Advertisement,
Router Solicitation and Advertisement, and Redirect messages.
This can be used to enforce SEND-only networks.

Arkko, et al. Expires April 16, June 30, 2004 [Page 39]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

8. Securing Router Discovery with SEND

This section describes how

9. Security Considerations

9.1 Threats to use the mechanisms Local Link Not Covered by SEND

SEND does not provide confidentiality for NDP communications.

SEND does not compensate for an insecure link layer. For instance,
there is no assurance that payload packets actually come from Section 5,
Section 6, and the reference [26]
same peer that the NDP was run against.

There may be no cryptographic binding in order to provide security for
Router Discovery.

8.1 Router Solicitation Messages

All Router Solicitation messages are protected with SEND.

8.1.1 Sending Secure Router Solicitations

Secure Router Solicitation messages are sent as described in RFC
2461, with SEND between the additional requirements as listed in link layer
frame address and the following:

Router Solicitation messages sent with IPv6 address. On an unspecified insecure link layer that
allows nodes to spoof the link layer address of other nodes, an
attacker could disrupt IP service by sending out a Neighbor
Advertisement having the source address MUST have on the Nonce link layer frame of a
victim, a valid CGA address and Timestamp options.

Other Router Solicitations MUST have the Nonce, Timestamp, a valid signature corresponding to
itself, and
Signature options. a Target Link-layer Address extension corresponding to
the victim. The Signature option MUST attacker could then proceed to cause a traffic
stream to bombard the victim in a DoS attack. This attack cannot be configured with
prevented just by securing the sender's key pair, setting link layer.

Even on a secure link layer, SEND does not require that the authorization method addresses
on the link layer and
additional information as Neighbor Advertisements correspond to each
other. However, it is configured.

8.1.2 Receiving Secure Router Solicitations

Received Router Solicitation messages are processed as described in
RFC 2461, with RECOMMENDED that such checks be performed
where this is possible on the additional SEND-related requirements as listed given link layer technology.

Prior to participating in Neighbor Discovery and Duplicate Address
Detection, nodes must subscribe to the following:

Router Solicitation message sent with an unspecified source
address link-scoped All-Nodes
Multicast Group and without the Nonce or Timestamp options MUST be
silently discarded.

Router Solicitation messages received with another type of source Solicited-Node Multicast Group for the
address but without that they are claiming for their addresses; RFC 2461 [7].
Subscribing to a multicast group requires that the Nonce, Timestamp, or Signature options
MUST be silently discarded.

The Signature option MUST nodes use MLD
[16]. MLD contains no provision for security. An attacker could
send an MLD Done message to unsubscribe a victim from the
Solicited-Node Multicast address. However, the victim should be constructed with able
to detect such an attack because the configured
authorization method(s), router sends a
Multicast-Address-Specific Query to determine whether any listeners
are still on the used key address, at which point the victim can respond to
avoid being within dropped from the configured
minimum (and maximum) allowable key size, and group. This technique will work if applicable, the
router on the link has not been compromised. Other attacks using
an acceptable trust anchor and/or minSec value. MLD
are possible, but they primarily lead to extraneous (but not
overwhelming) traffic.

9.2 How SEND Counters Threats to NDP

The configured authorization methods MUST include SEND protocol is designed to counter the trust anchor
authorization method, and MAY be additionally configured threats to
require CGA authorization. NDP, as
outlined in [25]. The following subsections contain a regression of
the SEND protocol against the threats, to illustrate what aspects of
the protocol counter each threat.

Arkko, et al. Expires April 16, June 30, 2004 [Page 40]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

8.2 Router Advertisement Messages

All Router Advertisement messages are protected with SEND.

8.2.1 Sending Secure Router Advertisements

Secure Router Advertisement messages are sent as described in RFC
2461, with the additional requirements as listed

9.2.1 Neighbor Solicitation/Advertisement Spoofing

This threat is defined in the following:

All Router Advertisement messages sent MUST contain a Timestamp
and Signature options. Section 4.1.1 of [25]. The Signature option MUST be configured to
protect the advertisement with the trust anchor authorization
method and MAY be configured to additionally protect it with the
CGA authorization method.

Router Advertisements sent threat is that
a spoofed message may cause a false entry in response to a Router Solicitation
MUST contain node's Neighbor Cache.
There are two cases:

1. Entries made as a copy side effect of the Nonce option included in the
solicitation.

8.2.2 Receiving Secure a Neighbor Solicitation or
Router Advertisements

Received Solicitation. A router receiving a Router Advertisement messages are processed as described in
RFC 2461, Solicitation
with a firm IPv6 source address and a Target Link-Layer Address
extension inserts an entry for the additional SEND-related requirements as listed in IPv6 address into its Neighbor
Cache. Also, a node performing Duplicate Address Detection (DAD)
that receives a Neighbor Solicitation for the following:

Router Advertisement messages received without same address
regards the Timestamp situation as a collision and ceases to solicit for
the address.

In either case, SEND counters these treats by requiring the
Signature and CGA options MUST to be silently discarded.

Received present in such solicitations.

SEND nodes can send Router Advertisements sent to Solicitation messages with a unicast destination CGA
source address without and a Nonce option MUST be silently discarded.

The Signature option MUST be constructed with CGA option, which the configured
authorization method(s), router can verify, so
the used key being within Neighbor Cache binding is correct. If a SEND node must send
a Router Solicitation with the configured
minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value.

The configured authorization methods MUST include unspecified address, the trust anchor
authorization method, and MAY be additionally configured to
require CGA authorization.

8.3 Redirect Messages

All Redirect messages are protected with SEND.

8.3.1 Sending Redirects

Arkko, et al. Expires April 16, 2004 [Page 41]

Internet-Draft SEcure router
will not update its Neighbor Discovery (SEND) October 2003

Secure Redirect messages are sent Cache, as described in per RFC 2461, with the
additional requirements 2461.

2. Entries made as listed in the following:

All Redirect messages sent MUST contain a result of a Neighbor Advertisement message.
SEND counters this threat by requiring the Timestamp and
Signature options. The Signature option MUST and CGA
options to be configured present in these advertisements.

See also Section 9.2.5, below, for discussion about replay protection
and timestamps.

9.2.2 Neighbor Unreachability Detection Failure

This attack is described in Section 4.1.2 of [25]. SEND counters
this attack by requiring a node responding to use
the trust anchor authorization method, Neighbor Solicitations
sent as NUD probes to include a Signature option and MAY be additionally
configured proof of
authorization to use the CGA method.

8.3.2 Receiving Redirects

Received Redirect messages interface identifier in the address being
probed. If these prerequisites are processed as not met, the node performing NUD
discards the responses.

9.2.3 Duplicate Address Detection DoS Attack

This attack is described in RFC 2461,
with Section 4.1.3 of [25]. SEND counters
this attack by requiring the additional SEND-related requirements Neighbor Advertisements sent as listed in the
following:

Redirect messages received without the Timestamp or Signature
options MUST be silently discarded.

The
responses to DAD to include a Signature option MUST be constructed with the configured and proof of
authorization method(s), to use the used key interface identifier in the address being within
tested. If these prerequisites are not met, the configured
minimum (and maximum) allowable key size, and if applicable, using
an acceptable trust anchor and/or minSec value.

The configured authorization methods MUST include the trust anchor
authorization method, and MAY be additionally configured to
require CGA authorization.

The receiver MUST verify that the Redirect message comes from an
IP address to which the host may have earlier sent the packet that
the Redirect message now partially returns. That is, the source
address of the Redirect message must be the default router or the
on-link destination host for traffic sent to the destination of
the returned packet. If this is not the case, the message MUST be
silently discarded.

This step prevents a bogus router from sending a Redirect message
when the host is not using the bogus router as a default router.

8.4 Other Requirements

Hosts SHOULD use Authorization Delegation Discovery to learn node performing DAD
discards the
certificate chain of their default router (or peer host), as
explained in Section 6. The receipt of a protected Router
Advertisement message for which no router Authorization Certificate
and certificate chain is available triggers Authorization Delegation
Discovery. responses.

Arkko, et al. Expires April 16, June 30, 2004 [Page 42] 41]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

9. Co-Existence of

When a SEND and node is used on a link that also connects to non-SEND nodes

During
nodes, the transition to secure links SEND node ignores any insecure Neighbor Solicitations or as a policy consideration,
network operators
Advertisements that may want to run a particular link with a mixture of
secure and insecure be send by the non-SEND nodes. Nodes that support SEND SHOULD support This protects
the use of SEND and the legacy Neighbor Discovery Protocol node from DAD DoS attacks by non-SEND nodes or attackers
simulating to non-SEND nodes, at the
same time.

In cost of a potential address
collision between a mixed environment, SEND nodes receive both secure node and insecure
messages but give priority to "secured" ones. Here, the "secured"
messages non-SEND node. The probability and
effects of such an address collision are ones that discussed in [12].

9.2.4 Router Solicitation and Advertisement Attacks

These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
and 4.2.7 of [25]. SEND counters these attacks by requiring Router
Advertisements to contain a valid signature Signature option, as specified
above, and "insecure" messages are ones that contain no the signature
option.

SEND nodes send only secured messages. Legacy Neighbor Discovery
nodes will obviously send only insecure messages. Such nodes will (as
per RFC 2461 [6]) ignore
is calculated using the unknown options and will treat secured
messages public key of a node that can prove its
authorization to route the subnet prefixes contained in any Prefix
Information Options. The router proves its authorization by showing
a certificate containing the same way as they treat insecure ones. Secured and
insecure nodes share specific prefix or the same network resources, indication that
the router is allowed to route any prefix. A Router Advertisement
without these protections is discarded.

SEND does not protect against brute force attacks on the router, such
as prefixes and
address spaces.

In a mixed environment SEND routers and hosts follow DoS attacks, or compromise of the protocols
defined router, as described in RFC 2461 Sections
4.4.2 and RFC 2462 with the following exceptions:

All solicitations sent by 4.4.3 of [25].

9.2.5 Replay Attacks

This attack is described in Section 4.3.1 of [25]. SEND nodes MUST be secured.

Unsolicited Neighbor and protects
against attacks in Router Advertisements sent Solicitation/Router Advertisement and
Neighbor Solicitation/Neighbor Advertisement transactions by
including a SEND
router MUST be secured.

Secured solicitations MUST contain the Nonce option. Secured
advertisements sent option in response to a secured the solicitation MUST
contain and requiring the
advertisement to include a copy of matching option. Together with the Nonce option
signatures this forms a challenge-response protocol. SEND protects
against attacks from the solicitation.
Unsolicited advertisements unsolicited messages such as Neighbor
Advertisements, Router Advertisements, and ones sent in response to an
insecure solicitation MUST NOT contain the Nonce Redirects by including a
Timestamp option. A SEND node that uses the CGA authorization method window of vulnerability for protecting
Neighbor Solicitations SHOULD perform Duplicate Address Detection
as follows. If Duplicate Address Detection indicates replay attacks
exists until the
tentative address is already in use, generate a new tentative CGA
address. If after 3 consecutive attempts no non-unique address
was generated, log a system error and give up attempting to
generate an address for that interface. timestamp expires.

When performing Duplicate Address Detection for the first
tentative address, accept both secured and insecure Neighbor
Advertisements and Solicitations received timestamps are used, SEND nodes are protected against replay
attacks as response long as they cache the state created by the message
containing the timestamp. The cached state allows the node to
protect itself against replayed messages. However, once the
Neighbor Solicitations. When performing Duplicate Address
Detection node
flushes the state for whatever reason, an attacker can re-create the second or third tentative address, ignore
state by replaying an old message while the timestamp is still valid.
Since most SEND nodes are likely to use fairly coarse grained
timestamps, as explained in Section 5.3.1, this may affect some
nodes.

Arkko, et al. Expires April 16, June 30, 2004 [Page 43] 42]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

insecure

9.2.6 Neighbor Advertisements and Solicitations.

The node SHOULD have a configuration option that causes it Discovery DoS Attack

This attack is described in Section 4.3.2 of [25]. In this attack,
the attacker bombards the router with packets for fictitious
addresses on the link, causing the router to
ignore insecure advertisements even when busy itself with
performing Duplicate
Address Detection Neighbor Solicitations for the first tentative address. This
configuration option SHOULD addresses that do not exist.
SEND does not address this threat because it can be disabled addressed by default. (This is
recovery mechanism
techniques such as rate limiting Neighbor Solicitations, restricting
the amount of state reserved for unresolved solicitations, and clever
cache management. These are all techniques involved in implementing
Neighbor Discovery on the unlikely case that attacks router.

9.3 Attacks against the
first address become common.) SEND Itself

The Neighbor Cache, Prefix List and Default Router list entries
MUST CGAs have a secured/insecure flag that indicates whether the
message that caused the creation or last update 59-bit hash value. The security of the entry was
secured or insecure. Received insecure messages MUST NOT cause
changes to existing secured entries CGA mechanism
has been discussed in the Neighbor Cache, Prefix
List or Default Router List. Received secured messages cause an
update of the matching entries [12].

Some Denial-of-Service attacks against NDP and flagging SEND itself remain.
For instance, an attacker may try to produce a very high number of them as secured.

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

A SEND node SHOULD have a configuration option that causes it to
ignore all insecure ND, RD and Redirect messages. (This can be
used to enforce SEND-only networks.)

Arkko, et al. Expires April 16, 2004 [Page 44]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

10. Performance Considerations

The computations related to the Signature option are computationally
relatively expensive. In the application which Signature option has
been designed for, however, the nodes typically have the need to
perform only a few signature operations as they enter a link, and a
few operations as they find a new on-link peer with which to
communicate.

Routers verify using asymmetric
methods. While safeguards are required to perform prevent an excessive use
of resources, this can still render SEND non-operational.

When CGA protection is used, SEND deals with the DoS attacks using
the verification process described in Section 5.2.2. In this
process, a larger number simple hash verification of operations,
particularly when the frequency CGA property of router advertisements the
address is high due
to mobility requirements. Still, performed before performing the number of required more expensive signature
operations is on
verification.

When trust anchors and certificates are used for address validation
in SEND, the order of a few dozen ones per second, some of
which can be precomputed defenses are not quite as discussed below. A large number of
router solicitations may cause higher demand for performing
asymmetric operations, although RFC 2461 limits effective. Implementations
SHOULD track the rate at which
responses to solicitations can be sent.

Signatures related resources devoted to the use processing of packets
received with the Signature option be precomputed
for Multicast Neighbor option, and Router Advertisements. Typically,
solicited advertisements start selectively discarding
packets if too many resources are sent to the unicast address from which
the solicitation was sent. Given spent. Implementations MAY also
first discard packets that are not protected with CGA.

The Authorization Delegation Discovery process may also be vulnerable
to Denial-of-Service attacks. An attack may target a router by
requesting a large number of delegation chains to be discovered for
different trust anchors. Routers SHOULD defend against such attacks
by caching discovered information (including negative responses) and
by limiting the IPv6 header is covered number of different discovery processes they engage
in.

Attackers may also target hosts by sending a large number of
unnecessary certificate chains, forcing hosts to spend useless memory
and verification resources for them. Hosts can defend against such
attacks by limiting the signature, it is typically not possible amount of resources devoted to precompute
solicited-for the

Arkko, et al. Expires June 30, 2004 [Page 43]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

certificate chains and their verification. Hosts SHOULD also
prioritize advertisements that sent as a response to their
solicitations above unsolicited advertisements.

Arkko, et al. Expires April 16, June 30, 2004 [Page 44]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

10. Protocol Constants

Host constants:

MAX_DCS_MESSAGES 3 transmissions
DCS_INTERVAL 4 seconds

Router constants:

MAX_DCA_RATE 10 times per second

Arkko, et al. Expires June 30, 2004 [Page 45]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

11. Security IANA Considerations

11.1 Threats to the Local Link Not Covered by SEND

SEND does not compensate for an insecure link layer. In particular,
there is no cryptographic binding

This document defines two new ICMP message types, used in SEND between
Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the link layer
frame address and the IPv6 address. On an insecure link layer that
allows nodes to spoof the link layer address of other nodes, an
attacker could disrupt IP service by sending out a Neighbor informational message range:

o The Delegation Chain Solicitation message, described in Section
6.2.1.

o The Delegation Chain Advertisement having the source address on message, described in Section
6.2.2.

This document defines six new Neighbor Discovery Protocol [7]
options, which must be assigned Option Type values within the link layer frame of a
victim, a valid option
numbering space for Neighbor Discovery Protocol messages:

o The CGA address and a valid signature corresponding to
itself, and a Target Link-layer Address extension corresponding to
the victim. option, described in Section 5.1.

o The attacker could then proceed to cause Signature option, described in Section 5.2.

o The Timestamp option, described in Section 5.3.1.

o The Nonce option, described in Section 5.3.2.

o The Trust Anchor option, described in Section 6.2.3.

o The Certificate option, described in Section 6.2.4.

This document defines a traffic
stream to bombard new 128-bit value under the victim in CGA Message Type
[12] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.

This document defines a DoS attack. To protect against
such attacks, link layer security MUST be used. An example of such new name space for 802 type networks is port-based access control defined in the
802.1X standard [34].

Specifically, the 802.1X standard provides a mechanism by which a
nodes can be authenticated to a particular point of attachment to a
LAN (called a "port" Name Type field in the standard). If the MAC on frames sent by a
node does not correspond to the MAC
Trust Anchor option. Future values of the node originally
authenticated to this port, then the point of attachment drops the
frames. Authorization to use the port is determined by the MAC
address of the node that originally authenticated to the port. The
way 802.1X protects against this attack is that, if a node
authenticated to a particular port attempts to spoof the MAC address
of another node, the port will drop the frames. Naturally, this
requires that all ports by which nodes can attach to the LAN use
802.1X authentication, and that all node physically attach through a
port, as is the case with 802.3 switched LAN. For shared media, such
as multiple nodes authenticated through the same 802.11 AP (which
acts as a single port for all nodes), other measures are necessary,
since an attacker on the wireless link field can spoof the MAC address of a
victim on the same wireless link.

802.1X does not provide protection be allocated
using standards action [6]. The current values for the layer 2 frame - layer 3
packet address binding in traffic (that is, real time filtering to
check this binding), and neither does SEND. 802.1X provides
authentication and filtering of MAC address to port; SEND provides
protection field are:

1 DER Encoded X.501 Name

2 FQDN

Another new name space is allocated for the layer 2 - layer 3 binding information Cert Type field in the
Neighbor Discovery packet, via the CGA address (authorization to use
the address via the public key) and the signature on the packet
(authentication
Certificate option. Future values of contents as from authorized IP address possessor).

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 this field can be allocated
using standards action [6]. The current values for the this field are:

1 X.509v3 Certificate

Arkko, et al. Expires April 16, June 30, 2004 [Page 46]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

address that they are claiming for their addresses;

Normative References

[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 2461 [6].
Subscribing to a multicast group requires that the nodes use MLD
[20]. MLD contains no provision 1034, November 1987.

[2] Bradner, S., "Key words for security. An attacker could
send an MLD Done message to unsubscribe a victim from the
Solicited-Node Multicast address. However, the victim should be able
to detect such an 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
overwhelming) traffic.

11.2 How SEND Counters Threats to Neighbor Discovery

The SEND protocol is designed to counter the threats to IPv6 Neighbor
Discovery, as outlined use in [27]. The following subsections contain a
regression of the SEND protocol against the threats, RFCs to illustrate
what aspects of the protocol counter each threat.

11.2.1 Neighbor Solicitation/Advertisement Spoofing

This threat is defined in Section 4.1.1 of [27]. The threat is that
a spoofed Neighbor Solicitation or Neighbor Advertisement causes 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. There are two cases:

1. A router receiving a Router Solicitation with a firm IPv6
source address Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[3] Kent, S. and a Target Link-Layer Address extension
inserts an entry for the IPv6 address into its Neighbor
Cache.

2. A node doing Duplicate Address Detection (DAD) that receives
a Neighbor Solicitation R. Atkinson, "Security Architecture for the same address regards the
situation as a collision
Internet Protocol", RFC 2401, November 1998.

[4] Kent, S. and ceases to solicit for the
address.

2. Entries made as a result R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.

[5] Piper, D., "The Internet IP Security Domain of a Neighbor Advertisement sent as a
response to a Neighbor Solicitation Interpretation
for purposes of on-link
address resolution.

11.2.1.1 Solicitations with Effect

SEND counters the threat of solicitations with effect ISAKMP", RFC 2407, November 1998.

[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.

[7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.

[8] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.

[9] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the
following ways: Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.

[10] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.

[11] Lynn, C., "X.509 Extensions for IP Addresses and AS
Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-02 (work in
progress), September 2003.

[12] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-03 (work in progress), December 2003.

[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002.

[14] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>.

Arkko, et al. Expires April 16, June 30, 2004 [Page 47]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

1. As discussed in Section 5, SEND nodes preferably send Router
Solicitations with a CGA address

Informative References

[15] Harkins, D. and a Signature option, which
the router can verify, so the Neighbor Cache binding is correct.
If a SEND node must send a Router Solicitation with the
unspecified address, the router will not update its Neighbor
Cache, as per D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2461.

See Section 11.2.5, below, 2409, November 1998.

[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for discussion about replay protection IPv6", RFC 2710, October 1999.

[17] Narten, T. and
timestamps.

11.2.1.2 R. Draves, "Privacy Extensions for Stateless
Address Resolution

SEND counters attacks on address resolution by requiring that the
responding node include a signature option on the packet, Autoconfiguration in IPv6", RFC 3041, January 2001.

[18] Farrell, S. and that
the node's interface identifier either be a CGA, or that the node be
able to produce a certificate authorizing that node to use the public
key.

The Neighbor Solicitation R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.

[19] Hinden, R. and Advertisement pairs implement a
challenge-response protocol, as explained in Section 7 S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.

[20] Arkko, J., "Effects of ICMPv6 on IKE and discussed IPsec Policies",
draft-arkko-icmpv6-ike-effects-02 (work in Section 11.2.5 below.

11.2.2 Neighbor Unreachability Detection Failure

This attack is described progress), March
2003.

[21] Arkko, J., "Manual SA Configuration for IPv6 Link Local
Messages", draft-arkko-manual-icmpv6-sas-01 (work in Section 4.1.2 of [27]. SEND counters
this attack by requiring a node responding to Neighbor Solicitations
sent as NUD probes to include a Signature option progress),
June 2002.

[22] Nordmark, E., Chakrabarti, S. and proof of
authorization to use the interface identifier in the address being
probed. If these prerequisites are not met, the node performing NUD
discards the responses.

11.2.3 Duplicate J. Laganier, "IPv6 Socket API
for Address Detection DoS Attack

This attack is described Selection", draft-chakrabarti-ipv6-addrselect-02
(work in Section 4.1.3 of [27]. SEND counters
this attack by requiring the progress), October 2003.

[23] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002.

[24] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.

[25] Nikander, P., "IPv6 Neighbor Advertisements sent as
responses to DAD to include a Signature option Discovery trust models and proof of
authorization to use the interface identifier
threats", draft-ietf-send-psreq-00 (work in the address being
tested. If these prerequisites are not met, the node performing DAD
discards the responses.

When a SEND node is used on a link that also connects to non-SEND
nodes, the SEND node ignores any insecure Neighbor Solicitations or
Advertisements that may be send by the non-SEND nodes. This protects
the SEND node from DAD DoS attacks by non-SEND nodes or attackers
simulating to non-SEND nodes, at the cost progress), October
2002.

[26] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000.

[27] Institute of a potential address
collision between a SEND node Electrical and non-SEND node. The probability Electronics Engineers, "Local and
effects of such an address collision are discussed in [26].
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.

Arkko, et al. Expires April 16, June 30, 2004 [Page 48]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

11.2.4 Router Solicitation and Advertisement Attacks

These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6,
and 4.2.7 of [27]. SEND counters these attacks by requiring Router
Advertisements to contain a Signature option, and that the signature
is calculated using the public key of a node that can prove its
authorization to route the subnet prefixes contained in any Prefix
Information Options. The router proves its authorization by showing
a certificate containing the specific prefix or the indication that
the router is allowed to route any prefix. A Router Advertisement
without these protections is dropped.

SEND does not protect against brute force attacks on the router, such
as DoS attacks, or compromise of the router, as described in Sections
4.4.2 and 4.4.3 of [27].

11.2.5 Replay Attacks

This attack is described in Section 4.3.1 of [27]. SEND protects
against attacks in Router Solicitation/Router Advertisement and
Neighbor Solicitation/Neighbor Advertisement transactions by
including a Nonce option in the solicitation and requiring the
advertisement to include a matching option. Together with the
signatures this forms a challenge-response protocol. SEND protects
against attacks from unsolicited messages such as Neighbor
Advertisements, Router Advertisements, and Redirects by including a
Timestamp option. A window of vulnerability for replay attacks
exists until the timestamp expires.

When timestamps are used, SEND nodes are protected against replay
attacks as long as they cache the state created by the message
containing the timestamp. The cached state allows the node to
protect itself against replayed messages. However, once the node
flushes the state for whatever reason, an attacker can re-create the
state by replaying an old message while the timestamp is still valid.
Since most SEND nodes are likely to use fairly coarse grained
timestamps, as explained in Section 5.4.1, this may affect some
nodes.

11.2.6 Neighbor Discovery DoS Attack

This attack is described in Section 4.3.2 of [27]. In this attack,
the attacker bombards the router with packets for fictitious
addresses on the link, causing the router to busy itself with
performing Neighbor Solicitations for addresses that do not exist.
SEND does not address this threat because it can be addressed by
techniques such as rate limiting Neighbor Solicitations, restricting
the amount of state reserved for unresolved solicitations, and clever

Arkko, et al. Expires April 16, 2004 [Page 49]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

cache management. These are all techniques involved in implementing
Neighbor Discovery on the router.

11.3 Attacks against SEND Itself

The CGAs have a 59-bit hash value. The security of the CGA mechanism
has been discussed in [26].

Some Denial-of-Service attacks against NDP and SEND itself remain.
For instance, an attacker may try to produce a very high number of
packets that a victim host or router has to verify using asymmetric
methods. While safeguards are required to prevent an excessive use
of resources, this can still render SEND non-operational.

When CGA protection is used, SEND deals with the DoS attacks using
the verification process described in Section 5.3.2. In this process,
a simple hash verification of the CGA property of the address is
performed first before performing the more expensive signature
verification.

When trust anchors and certificates are used for address validation
in SEND, the defenses are not quite as effective. Implementations
SHOULD track the resources devoted to the processing of packets
received with the Signature option, and start selectively dropping
packets if too many resources are spent. Implementations MAY also
first drop packets that are not protected with CGA.

The Authorization Delegation Discovery process may also be vulnerable
to Denial-of-Service attacks. An attack may target a router by
requesting a large number of delegation chains to be discovered for
different trust anchors. Routers SHOULD defend against such attacks
by caching discovered information (including negative responses) and
by limiting the number of different discovery processes they engage
in.

Attackers may also target hosts by sending a large number of
unnecessary certificate chains, forcing hosts to spend useless memory
and verification resources for them. Hosts can defend against such
attacks by limiting the amount of resources devoted to the
certificate chains and their verification. Hosts SHOULD also
prioritize advertisements that sent as a response to their
solicitations above unsolicited advertisements.

Arkko, et al. Expires April 16, 2004 [Page 50]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

12. IANA Considerations

This document defines two new ICMP message types, used in
Authorization Delegation Discovery. These messages must be assigned
ICMPv6 type numbers from the informational message range:

o The Delegation Chain Solicitation message, described in Section
6.1.

o The Delegation Chain Advertisement message, described in Section
6.2.

This document defines six new Neighbor Discovery Protocol [6]
options, which must be assigned Option Type values within the option
numbering space for Neighbor Discovery Protocol messages:

o The Trust Anchor option, described in Section 6.3.

o The Certificate option, described in Section 6.4.

o The CGA option, described in Section 5.2.

o The Signature option, described in Section 5.3.

o The Timestamp option, described in Section 5.4.1.

o The Nonce option, described in Section 5.4.2.

This document defines a new 128-bit CGA Message Type [26] value,
0xXXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX (To be generated randomly).

XXX: Use existing name spaces for these?

This document defines a new name space for the Name Type field in the
Trust Anchor option. Future values of this field can be allocated
using standards action [5].

Another new name space is allocated for the Cert Type field in the
Certificate option. Future values of this field can be allocated
using standards action [5].

Arkko, et al. Expires April 16, 2004 [Page 51]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Normative References

[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.

[2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.

[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.

[4] Piper, D., "The Internet IP Security Domain of Interpretation
for ISAKMP", RFC 2407, November 1998.

[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.

[6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.

[7] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.

[8] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.

[9] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.

[10] Bassham, L., Polk, W. and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC
3279, April 2002.

[11] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.

[12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.

[13] Lynn, C., "X.509 Extensions for IP Addresses and AS
Identifiers", draft-ietf-pkix-x509-ipaddr-as-extn-02 (work in
progress), September 2003.

[14] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in

Arkko, et al. Expires April 16, 2004 [Page 52]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
2003.

[15] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS
1, November 2002.

[16] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS PUB 180-1, April 1995, <http://
www.itl.nist.gov/fipspubs/fip180-1.htm>.

Arkko, et al. Expires April 16, 2004 [Page 53]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Informative References

[17] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.

[18] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, RFC
826, November 1982.

[19] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.

[20] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.

[21] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization", RFC 3281, April 2002.

[22] Arkko, J., "Effects of ICMPv6 on IKE",
draft-arkko-icmpv6-ike-effects-02 (work in progress), March
2003.

[23] Arkko, J., "Manual Configuration of Security Associations for
IPv6 Neighbor Discovery", draft-arkko-manual-icmpv6-sas-02
(work in progress), March 2003.

[24] Droms, R., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-28 (work in progress),
November 2002.

[25] Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-06 (work in progress), July 2003.

[26] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-01 (work in progress), August 2003.

[27] Nikander, P., "IPv6 Neighbor Discovery trust models and
threats", draft-ietf-send-psreq-03 (work in progress), April
2003.

[28] Montenegro, G. and C. Castelluccia, "SUCV Identifiers and
Addresses", draft-montenegro-sucv-03 (work in progress), July
2002.

[29] International Organization for Standardization, "The Directory
- Authentication Framework", ISO Standard X.509, 2000.

Arkko, et al. Expires April 16, 2004 [Page 54]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

[30] O'Shea, G. and M. Roe, "Child-proof Authentication for MIPv6",
Computer Communications Review, April 2001.

[31] Nikander, P., "Denial-of-Service, Address Ownership, and Early
Authentication in the IPv6 World", Proceedings of the Cambridge
Security Protocols Workshop, April 2001.

[32] Arkko, J., Aura, T., Kempf, J., Mantyla, V., Nikander, P. and
M. Roe, "Securing IPv6 Neighbor Discovery", Wireless Security
Workshop, September 2002.

[33] Montenegro, G. and C. Castelluccia, "Statistically Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses",
NDSS, February 2002.

[34] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.

Authors' Addresses

Jari Arkko
Ericsson

Jorvas 02420
Finland

EMail: jari.arkko@ericsson.com

James Kempf
DoCoMo Communications Labs USA
181 Metro Drive
San Jose, CA 94043
USA

EMail: kempf@docomolabs-usa.com

Bill Sommerfeld
Sun Microsystems
1 Network Drive UBUR02-212
Burlington, MA 01803
USA

EMail: sommerfeld@east.sun.com

Arkko, et al. Expires April 16, 2004 [Page 55]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Brian Zill
Microsoft

USA

EMail: bzill@microsoft.com

Pekka Nikander
Ericsson

Jorvas 02420
Finland

EMail: Pekka.Nikander@nomadiclab.com

Arkko, et al. Expires April 16, 2004 [Page 56]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Appendix A. Contributors

Tuomas Aura contributed the transition mechanism specification in
Section 9.

Arkko, et al. Expires April 16, 2004 [Page 57]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Appendix B. IPR Considerations

The optional CGA part of SEND uses public keys and hashes to prove
address ownership. Several IPR claims have been made about such
methods.

Arkko, et al. Expires April 16, 2004 [Page 58]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Appendix C. Cache Management

In this section we outline a cache management algorithm that allows a
node to remain partially functional even under a cache filling DoS
attack. This appendix is informational, and real implementations
SHOULD use different algorithms in order to avoid he dangers of
monocultural code.

There are at least two distinct cache related attack scenarios:

1. There are a number of nodes on a link, and someone launches a
cache filling attack. The goal here is clearly make sure that
the nodes can continue to communicate even if the attack is going
on.

2. There is already a cache filling attack going on, and a new node
arrives to the link. The goal here is to make it possible for
the new node to become attached to the network, inspite of the
attack.

From this point of view, it is clearly better to be very selective in
how to throw out entries. Reducing the timestamp Delta value is very
discriminative against those nodess that have a large clock
difference, while an attacker can reduce its clock difference into
arbitrarily small. Throwing out old entries just because their clock
difference is large seems like a bad approach.

A reasonable idea seems to be to have a separate cache space for new
entries and old entries, and under an attack more eagerly drop new
cache entries than old ones. One could track traffic, and only allow
those new entries that receive genuine traffic to be converted into
old cache entries. While such a scheme will make attacks harder, it
will not fully prevent them. For example, an attacker could send a
little traffic (i.e. a ping or TCP syn) after each NS to trick the
victim into promoting its cache entry to the old cache. Hence, the
node may be more intelligent in keeping its cache entries, and not
just have a black/white old/new boundary.

It also looks like a good idea to consider the sec parameter when
forcing cache entries out, and let those entries with a larger sec a
higher chance of staying in.

Authors' Addresses

Jari Arkko
Ericsson

Jorvas 02420
Finland

EMail: jari.arkko@ericsson.com

James Kempf
DoCoMo Communications Labs USA
181 Metro Drive
San Jose, CA 94043
USA

EMail: kempf@docomolabs-usa.com

Bill Sommerfeld
Sun Microsystems
1 Network Drive UBUR02-212
Burlington, MA 01803
USA

EMail: sommerfeld@east.sun.com

Brian Zill
Microsoft

USA

EMail: bzill@microsoft.com

Pekka Nikander
Ericsson

Jorvas 02420
Finland

EMail: Pekka.Nikander@nomadiclab.com

Arkko, et al. Expires April 16, June 30, 2004 [Page 59] 49]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003

Appendix D. Comparison to AH-Based Approach

This approach has the following benefits compared to the previous
Working Group document approach:

o The full implementation of the security mechanism, including
Nonces and CGAs, exists within one module. There is no need to
analyze the security of the mechanism across NDP, IPsec, and CGA
layers.

o The CGA part of the solution has been separated into its own
specification. This is possible because the CGA handling is done
in its own option. (The authorization method configuration flag
is the only thing common to the CGA and Signature options.)

o No extensions or modifications of IPsec processing are required:
SPD entries are not required to distinguish ICMP types, AH does
not need to support public keys or CGAs, and destination address
acgnostic security associations are not needed.

o It is not necessary to allocate a new multicast address to
represent the Solicited-Node multicast address for SEND nodes.

o It is not necessary to change the Neighbor Discovery behavior with
regards to the use of the unspecified address. Since all
information is available within the Neighbor Discovery messages,
unspecified source addresses can be used, still being able to
correlate the CGA property with the Target Address in a Neighbor
Solicitation during Duplicate Address Detection.

o The transition mechanisms for links with both SEND and non-SEND
nodes are significantly simpler. In particular, non-SEND nodes
will be able to receive DAD probes and other messages sent by the
SEND nodes.

o Only a single set of Neighbor Discovery messages from the router
needs to be transmitted on a link. This helps avoid extra
overhead for mobility beacons and other frequently occurring
messaging.

o Given that the asymmetric computations required in SEND are
computationally expensive, it is necessary to control December 2003

Appendix A. Contributors

Tuomas Aura contributed the number
of these operations transition mechanism specification in order to avoid Denial-of-Service attacks.
This control is easier to arrange with "application layer"
information. For instance, a router need not verify more Router
Solicitations with an unspecified source address than it can
respond to according to the RFC 2461 rules.
Section 8.

Arkko, et al. Expires April 16, June 30, 2004 [Page 60] 50]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

o There is no need for an API

Appendix B. Acknowledgments

The authors would like to communicate certificate chains
requests and certificate chains between the IPsec thank Tuomas Aura, Erik Nordmark, Gabriel
Montenegro, Pasi Eronen, and Francis Dupont for interesting
discussions in this problem space.

Arkko, et al. Expires June 30, 2004 [Page 51]

Internet-Draft SEcure Neighbor Discovery modules.

Also, a good implementation of SEND would not require the user to
configure it (beyond perhaps enabling it). (SEND) December 2003

Appendix C. Cache Management

In order to achieve this with IPsec, section we outline a set of policy entries needs cache management algorithm that allows a
node to be automatically
created upon system start.

o There remain partially functional even under a cache filling DoS
attack. This appendix is no need for the CGA parameters to be stored both in the
IPsec and Neighbor Discovery modules, where they are needed for
the construction of Authentication Headers informational, and addresses,
respectively.

o It is not necessary to change existing BITS or BITW IPsec real implementations to support SEND and AH_RSA_Sig. There would have
been two problems associated with such changes:

* A SEND implementation
SHOULD use different algorithms in such environment could not proceed
until this modification were completed.

* Typical hardware that processes IPsec packets may not be easily
changed to process asymmetric transforms. (Of course, such
packets can be passed order to the main CPU at the node, assuming
this can easily be done in the given implementation.)

o In addition, many IPsec implementations avoid he dangers of
mono-cultural code.

There are highly optimized
because they at least two distinct cache related attack scenarios:

1. There are on the fast path for packet processing. For
example, the Linux implementation runs in the kernel interrupt
thread. Some a number of the SEND modifications might have required IPsec
processing to wait nodes on a semaphore while, for example, link, and someone launches a
certificate chain
cache filling attack. The goal here is fetched, an operation clearly make sure that takes place out of
band in regular IPsec processing because it
the nodes can continue to communicate even if the attack is done using IKE.
While going
on.

2. There is already a cache filling attack going on, and a new node
arrives to the link. The goal here is to make it might have been possible that for
the implemenation could
have been arranged so that general IPsec processing wasqn't
impacted, new node to become attached to the resulting code would have been more complex.

The use network, in spite of IPsec to protect NDP would have been possible, but the
limits and capabilities
attack.

From this point of IPsec would have view, it is clearly better to be stretched. Small
changes very selective in
how to throw out entries. Reducing the NDP protocol (or our understanding of the issues)
might timestamp Delta value is very
discriminative against those nodes that have caused a situation which had no longer been easily handled
when the "application" large clock
difference, while an attacker can reduce its clock difference into
arbitrarily small. Throwing out old entries just because their clock
difference is large seems like a bad approach.

A reasonable idea seems to be to have a separate cache space for new
entries and old entries, and under an attack more eagerly drop new
cache entries than old ones. One could track traffic, and the security existed at different layers.
Although IPsec as defined in RFC 2402 just defines only allow
those new entries that receive genuine traffic to be converted into
old cache entries. While such a header format,
RFC 2401 and the ensuing years of implementation have evolved scheme will make attacks harder, it
will not fully prevent them. For example, an attacker could send a
complex interconnected set of components for IPsec which would have
required some modification
little traffic (i.e. a ping or TCP syn) after each NS to accommodate SEND.

On the other hand, IPsec is trick the current solution for securing NDP in

Arkko, et al. Expires April 16, 2004 [Page 61]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003
victim into promoting its cache entry to the original NDP RFCs. Even if old cache. Hence, the current IPsec can
node may be used only more intelligent in
very limited networks to secure NDP, it could have been argued that
it would keeping its cache entries, and not
just have been logical a black/white old/new boundary.

It also looks like a good idea to continue its use. Also, consider the existence sec parameter when
forcing cache entries out, and let those entries with a larger sec a
higher chance of an asymmetric transform in IPsec would have been potentially
useful in other contexts as well. staying in.

Arkko, et al. Expires April 16, June 30, 2004 [Page 62] 52]

Internet-Draft SEcure Neighbor Discovery (SEND) October December 2003

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.

Arkko, et al. Expires June 30, 2004 [Page 53]

Internet-Draft SEcure Neighbor Discovery (SEND) December 2003

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Arkko, et al. Expires April 16, 2004 [Page 63]

Internet-Draft SEcure Neighbor Discovery (SEND) October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Arkko, et al. Expires April 16, June 30, 2004 [Page 64] 54]

----