[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-arkko-send-ndopt) 00 01 03 04 05 06 RFC 3971

Secure Neighbor Discovery Working                      J. Arkko (Editor)
Group                                                           Ericsson
Internet-Draft                                                  J. Kempf
Expires: January 15, 2005                 DoCoMo Communications Labs USA
                                                           B. Sommerfeld
                                                        Sun Microsystems
                                                                 B. Zill
                                                               Microsoft
                                                             P. Nikander
                                                                Ericsson
                                                           July 17, 2004


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

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 January 15, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
   other nodes on the link, to determine the link-layer addresses of
   other nodes on the link, to find routers, and to maintain
   reachability information about the paths to active neighbors. If not
   secured, NDP is vulnerable to various attacks.  This document



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   specifies security mechanisms for NDP. Unlike the original NDP
   specifications these mechanisms do not make use of IPsec.

Table of Contents

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


               9.2.1 Neighbor Solicitation/Advertisement Spoofing . . 50
               9.2.2 Neighbor Unreachability Detection Failure  . . . 50
               9.2.3 Duplicate Address Detection DoS Attack . . . . . 50
               9.2.4 Router Solicitation and Advertisement Attacks  . 51
               9.2.5 Replay Attacks . . . . . . . . . . . . . . . . . 51
               9.2.6 Neighbor Discovery DoS Attack  . . . . . . . . . 52
         9.3   Attacks against SEND Itself  . . . . . . . . . . . . . 52
   10.   Protocol Values  . . . . . . . . . . . . . . . . . . . . . . 54
         10.1  Constants  . . . . . . . . . . . . . . . . . . . . . . 54
         10.2  Variables  . . . . . . . . . . . . . . . . . . . . . . 54
   11.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 55
         Normative References . . . . . . . . . . . . . . . . . . . . 56
         Informative References . . . . . . . . . . . . . . . . . . . 58
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 58
   A.    Contributors and Acknowledgments . . . . . . . . . . . . . . 60
   B.    Cache Management . . . . . . . . . . . . . . . . . . . . . . 61
   C.    Message Size When Carrying Certificates  . . . . . . . . . . 62
         Intellectual Property and Copyright Statements . . . . . . . 63

































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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


1. Introduction

   IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [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.

   The original NDP specifications called for the use of IPsec to
   protect NDP messages. However, the RFCs do not give detailed
   instructions for using IPsec for this.  In this particular
   application, IPsec can only be used with a manual configuration of
   security associations, due to bootstrapping problems in using IKE
   [22, 18].  Furthermore, the number of such manually configured
   security associations needed for protecting NDP can be very large
   [23], making that approach impractical for most purposes.

   The SEND protocol is designed to counter the threats to NDP. These
   threats are described in detail in [25]. SEND is applicable in
   environments where physical security on the link is not assured (such
   as over wireless) and attacks on NDP are a concern.

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

   The required new NDP options are discussed in Section 5. Section 6
   describes the mechanism for distributing certification paths to
   establish an authorization delegation chain to a trust anchor.

   Finally, Section 8 discusses the co-existence of secured and
   unsecured NDP on the same link and Section 9 discusses security
   considerations for Secure Neighbor Discovery (SEND).

   Out of scope for this document is the use of identity certificates
   provisioned on end hosts for authorizing address use, and security of
   NDP when the entity defending an address is not the same as the
   entity claiming that adddress (also known as "proxy ND"). These are



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   extensions of SEND that may be treated in separate documents should
   the need arise.

1.1 Specification of Requirements

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










































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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


2. Terms

   Authorization Delegation Discovery (ADD)

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

   Certificate Revocation List (CRL)

      In one method of certificate revocation, an authority periodically
      issues a signed data structure called the Certificate Revocation
      List. This list is a time stamped list identifying revoked
      certificates, signed by the issuer, and made freely available in a
      public repository.

   Certification Path Advertisement (CPA)

      The advertisement message used in the ADD process.

   Certification Path Solicitation (CPS)

      The solicitation message used in the ADD process.

   Cryptographically Generated Address (CGA)

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

   Distinguished Encoding Rules (DER)

      An encoding scheme for data values, defined in [15].

   Duplicate Address Detection (DAD)

      A mechanism which assures that two IPv6 nodes on the same link are
      not using the same address.

   Fully Qualified Domain Name (FQDN)

      A fully qualified domain name consists of a host and domain name,
      including top-level domain.

   Internationalized Domain Name (IDN)

      Internationalized Domain Names can be used to represent domain
      names that contain characters outside the ASCII repertoire.  See
      RFC 3490 [12].



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   Neighbor Discovery (ND)

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

   Neighbor Discovery Protocol (NDP)

      The IPv6 Neighbor Discovery Protocol [7, 8].

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

   Neighbor Unreachability Detection (NUD)

      A mechanism used for tracking the reachability of neighbors.

   Non-SEND node

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

   Nonce

      An unpredictable random or pseudorandom number generated by a node
      and used exactly once. In SEND, nonces are used to assure that a
      particular advertisement is linked to the solicitation that
      triggered it.

   Router Authorization Certificate

      An X.509v3 [10] public key certificate using the profile specified
      in Section 6.3.1.

   SEND node

      An IPv6 node that implements this specification.

   Router Discovery (RD)

      Router Discovery allows the hosts to discover what routers exist
      on the link, and what subnet prefixes are available. Router
      Discovery is a part of the Neighbor Discovery Protocol.

   Trust Anchor

      Hosts are configured with a set of trust anchors for the purposes
      of protecting Router Discovery. A trust anchor is an entity that
      the host trusts to authorize routers to act as routers. A trust



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      anchor configuration consists of a public key and some associated
      parameters (see Section 6.5 for a detailed explanation of these
      parameters).
















































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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


3. Neighbor and Router Discovery Overview

   The Neighbor Discovery Protocol has several functions. Many of these
   functions are overloaded on a few central message types, such as the
   ICMPv6 Neighbor Advertisement message.  In this section 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, as updated, take precedence.

   The main functions of NDP are the following.

   o  The Router Discovery function allows IPv6 hosts to discover the
      local routers on an attached link.  Router Discovery is described
      in Section 6 of RFC 2461 [7].  The main purpose of Router
      Discovery is to find neighboring routers that are willing to
      forward packets on behalf of hosts.  Subnet prefix discovery
      involves determining which destinations are directly on a link;
      this information is necessary in order to know whether a packet
      should be sent to a router or directly to the destination node.

   o  The Redirect function is used for automatically redirecting a host
      to a better first-hop router, or to inform hosts that a
      destination is in fact a neighbor (i.e., on-link). Redirect is
      specified in Section 8 of RFC 2461 [7].

   o  Address Autoconfiguration is used for automatically assigning
      addresses to a host [8]. This allows hosts to operate without
      explicit configuration related to IP connectivity.  The default
      autoconfiguration mechanism is stateless. To create IP addresses,
      hosts use any prefix information delivered to them during Router
      Discovery, and then test the newly formed addresses for
      uniqueness. A stateful mechanism, DHCPv6 [21], provides additional
      autoconfiguration features.

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

   o  The Address Resolution function allows a node on the link to
      resolve another node's IPv6 address to the corresponding
      link-layer address.  Address Resolution is defined in Section 7.2



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      of RFC 2461 [7], and it is used for hosts and routers alike.
      Again, no higher level traffic can proceed until the sender knows
      the link layer address of the destination node or the next hop
      router. Note the source link layer address on link layer frames is
      not checked against the information learned through Address
      Resolution.  This allows for an easier addition of network
      elements such as bridges and proxies, and eases the stack
      implementation requirements as less information needs to be passed
      from layer to layer.

   o  Neighbor Unreachability Detection (NUD) is used for tracking the
      reachability of neighboring nodes, both hosts and routers. NUD is
      defined in Section 7.3 of RFC 2461 [7].  NUD is
      security-sensitive, because an attacker could falsely claim that
      reachability exists when it in fact does not.

   The NDP messages follow the ICMPv6 message format. All NDP functions
   are realized using the Router Solicitation (RS), Router Advertisement
   (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and
   Redirect messages. An actual NDP message includes an NDP message
   header, consisting of an ICMPv6 header and ND message-specific data,
   and zero or more NDP options. The NDP message options are formatted
   in the Type-Length-Value format.

                         <------------NDP Message---------------->
     *-------------------------------------------------------------*
     | IPv6 Header      | ICMPv6   | ND Message- | ND Message      |
     | Next Header = 58 | Header   | specific    | Options         |
     | (ICMPv6)         |          | data        |                 |
     *-------------------------------------------------------------*
                         <--NDP Message header-->




















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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


4. Secure Neighbor Discovery Overview

   To secure the various functions in NDP, a set of new Neighbor
   Discovery options is introduced.  They are used to protect NDP
   messages. This specification introduces these options, an
   authorization delegation discovery process, an address ownership
   proof mechanism, and requirements for the use of these components in
   NDP.

   The components of the solution specified in this document are as
   follows:

   o  Certification paths, anchored on trusted parties, are expected to
      certify the authority of routers.  A host must be configured with
      a trust anchor to which the router has a certification path before
      the host can adopt the router as its default router.
      Certification Path Solicitation and Advertisement messages are
      used to discover a certification path to the trust anchor without
      requiring the actual Router Discovery messages to carry lengthy
      certification paths. The receipt of a protected Router
      Advertisement message for which no certification path is available
      triggers the authorization delegation discovery process.

   o  Cryptographically Generated Addresses are used to assure that the
      sender of a Neighbor Discovery message is the "owner" of the
      claimed address.  A public-private key pair is generated by all
      nodes before they can claim an address.  A new NDP option, the CGA
      option, is used to carry the public key and associated parameters.

      This specification also allows a node to use non-CGAs with
      certificates to authorize their use.  However, the details of such
      use are beyond the scope of this specification and are left for
      future work.

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

      Public key signatures protect the integrity of the messages and
      authenticate the identity of their sender.  The authority of a
      public key is established either with the authorization delegation
      process, using certificates, or through the address ownership
      proof mechanism, using CGAs, or both, depending on configuration
      and the type of the message protected.

      Note: RSA is mandated because having multiple signature algorithms
      would break compatibility between implementations or increase
      implementation complexity by forcing implementation of multiple
      algorithms and the mechanism to select among them. A second



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      signature algorithm is only necessary as a recovery mechanism, in
      case a flaw is found in RSA. If that happens, a stronger signature
      algorithm can be selected and SEND can be revised. The
      relationship between the new algorithm and the RSA-based SEND
      described in this document would be similar to that between the
      RSA-based SEND and Neighbor Discovery without SEND. Information
      signed with the stronger algorithm has precedence over that signed
      with RSA, in the same way as RSA-signed information now takes
      precedence over unsigned information. Implementations of the
      current and revised specs would still be compatible.

   o  In order to prevent replay attacks, two new Neighbor Discovery
      options, Timestamp and Nonce, are introduced.  Given that Neighbor
      and Router Discovery messages are in some cases sent to multicast
      addresses, the Timestamp option offers replay protection without
      any previously established state or sequence numbers.  When the
      messages are used in solicitation - advertisement pairs, they are
      protected using the Nonce option.

































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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


5. Neighbor Discovery Protocol Options

   The options described in this section MUST be supported.

5.1 CGA Option

   The CGA option allows the verification of the sender's CGA. The
   format of the CGA option is described as follows.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |   Pad Length  |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        CGA Parameters                         .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                           Padding                             .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD <To be assigned by IANA for CGA>.

   Length

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

   Pad Length

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

   Reserved

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   CGA Parameters

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

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

   Padding

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


5.1.1 Processing Rules for Senders

   If the node has been configured to use SEND, the CGA option MUST be
   present in all Neighbor Solicitation and Advertisement messages, and
   MUST be present in Router Solicitation messages unless they are sent
   with the unspecified source address. The CGA option MAY be present in
   other messages.

   A node sending a message using the CGA option MUST construct the
   message as follows.

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

   Redirect

      The address MUST be the source address of the message.

   Neighbor Solicitation

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   Neighbor Advertisement

      The address MUST be the source address of the message.

   Router Solicitation

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

   Router Advertisement

      The address MUST be the source address of the message.


5.1.2 Processing Rules for Receivers

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

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

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

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

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

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


5.1.3 Configuration

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

   minbits

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

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

   CGA parameters

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


5.2 RSA Signature Option

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























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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

   Type

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

   Length

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

   Reserved

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

   Key Hash

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      be received in the CGA option in the same message.

   Digital Signature

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

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

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

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

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

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

      6.  All NDP options preceding the RSA Signature option.

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

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

   Padding

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


5.2.1 Processing Rules for Senders

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

   A node sending a message using the RSA Signature option MUST



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   construct the message as follows:

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

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

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

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


5.2.2 Processing Rules for Receivers

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

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

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

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

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

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

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

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



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

      Note that the receiver may verify just the CGA property of a
      packet, even if, in addition to CGA, the sender has used a trust
      anchor.

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

5.2.3 Configuration

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

   authorization method

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

      trust anchor

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

      CGA

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

      trust anchor and CGA

         Both the trust anchor and the CGA verification is required.

      trust anchor or CGA

         Either the trust anchor or the CGA verification is required.

   anchor

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

   All nodes that support the sending of RSA Signature options MUST



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   record the following configuration information:

   keypair

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

   CGA flag

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


5.2.4 Performance Considerations

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

   Routers are required to perform a larger number of operations,
   particularly when the frequency of router advertisements is high due
   to mobility requirements.  Still, the number of required signature
   operations is on the order of a few dozen per second, some of which
   can be precomputed as explained below.  A large number of router
   solicitations may cause higher demand for performing asymmetric
   operations, although the base NDP protocol limits the rate at which
   responses to solicitations can be sent.

   Signatures can be precomputed for unsolicited (multicast) Neighbor
   and Router Advertisements if the timing of such future advertisements
   is known. Typically, solicited advertisements are sent to the unicast
   address from which the solicitation was sent. Given that the IPv6
   header is covered by the signature, it is not possible to precompute
   solicited advertisements.

5.3 Timestamp and Nonce options

5.3.1 Timestamp Option

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




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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

   Type

      TBD <To be assigned by IANA for Timestamp>.

   Length

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

   Reserved

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

   Timestamp

      A 64-bit unsigned integer field containing a timestamp. The value
      indicates the number of seconds since January 1, 1970 00:00 UTC,
      using a fixed point format. In this format the integer number of
      seconds is contained in the first 48 bits of the field, and the
      remaining 16 bits indicate the number of 1/64K fractions of a
      second.

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


5.3.2 Nonce Option

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





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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |    Length     |  Nonce ...                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
       |                                                               |
       .                                                               .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD <To be assigned by IANA for Nonce>.

   Length

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

   Nonce

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


5.3.3 Processing rules for senders

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

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

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   to their real time clock.

5.3.4 Processing rules for receivers

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

   In addition, the following rules apply in all cases:

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

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

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

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

   o  An implementation MAY utilize some mechanism such as a timestamp
      cache to strengthen resistance to replay attacks. When there is a
      very large number of nodes on the same link, or when a cache
      filling attack is in progress, it is possible that the cache
      holding the most recent timestamp per sender becomes full.  In
      this case the node MUST remove some entries from the cache or
      refuse some new requested entries.  The specific policy as to
      which entries are preferred over the others is left as an
      implementation decision. However, typical policies may prefer
      existing entries over new ones, CGAs with a large Sec value over
      smaller Sec values, and so on.  The issue is briefly discussed in
      Appendix B.

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


5.3.4.1 Processing solicited advertisements

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

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

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

5.3.4.2 Processing all other messages

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

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

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

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

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

   Receivers SHOULD then check the Timestamp field as follows:

   o  When a message is received from a new peer (i.e., one that is not
      stored in the cache) the received timestamp, TSnew, is checked and
      the packet is accepted if the timestamp is recent enough with
      respect to the reception time of the packet, RDnew:

        -Delta < (RDnew - TSnew) < +Delta

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

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      receiver, the receiver SHOULD respond to the message.  However, if
      it does respond to the message, it MUST NOT create a Neighbor
      Cache entry.  This allows nodes that have large differences in
      their clocks to still communicate 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 the cache, the time stamp is checked
      against the previously received SEND message:

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

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

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

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



























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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


6. Authorization Delegation Discovery

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

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

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

6.1 Authorization Model

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

   The authorization for routers in SEND is twofold:

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

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

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

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

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

6.2 Deployment Model

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

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




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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

6.3 Certificate Format

   The certification path of a router terminates in a Router
   Authorization Certificate that authorizes a specific IPv6 node to act
   as a router.  Because authorization paths are not a common practice
   in the Internet at the time this specification was written, the path
   MUST consist of standard Public Key Certificates (PKC, in the sense
   of [11]).  The certification path MUST start from the identity of a
   trust anchor that is shared by the host and the router.  This allows
   the host to anchor trust for the router's public key in the trust
   anchor.  Note that there MAY be multiple certificates issued by a
   single trust anchor.

6.3.1 Router Authorization Certificate Profile

   Router Authorization Certificates are X.509v3 certificates, as
   defined in RFC 3280 [10], and SHOULD contain at least one instance of
   the X.509 extension for IP addresses, as defined in [13]. The parent
   certificates in the certification path SHOULD contain one or more
   X.509 IP address extensions, back up to a trusted party (such as the
   user's ISP) that configured the original IP address block for the
   router in question, or delegated the right to do so. The certificates
   for the intermediate delegating authorities SHOULD contain X.509 IP
   address extension(s) for subdelegations. The router's certificate is
   signed by the delegating authority for the subnet prefixes the router
   is authorized to advertise.

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

   A node receiving a Router Authorization Certificate MUST first check



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   whether the certificate's signature was generated by the delegating
   authority.  Then the client SHOULD check whether all the
   addressPrefix or addressRange entries in the router's certificate are
   contained within the address ranges in the delegating authority's
   certificate, and whether the addressPrefix entries match any
   addressPrefix entries in the delegating authority's certificate. If
   an addressPrefix or addressRange is not contained within the
   delegating authority's subnet prefixes or ranges, the client MAY
   attempt to take an intersection of the ranges/subnet prefixes, and
   use that intersection. If the resulting intersection is empty, the
   client MUST NOT accept the certificate. If the addressPrefix in the
   certificate is missing or is the null prefix, ::/0, the parent prefix
   or range SHOULD be used. If there is no parent prefix or range, the
   subnet prefixes that the router advertises are said to be
   unconstrained (see Section 7.3). That is, the router is allowed to
   advertise any prefix.

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

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

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

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

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




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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

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

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

               ... other certificate parameters ...

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

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






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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


6.3.2 Suitability of Standard Identity Certificates

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

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

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

6.4 Certificate Transport

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

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

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

6.4.1 Certification Path Solicitation Message Format

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










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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      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      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |          Component            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address

         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

   ICMP Fields:

      Type

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

      Code

         0

      Checksum

         The ICMP checksum [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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


         cryptographically hard, since its purpose is only to avoid
         collisions.

      Component

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

   Valid Options:

      Trust Anchor

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

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

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


6.4.2 Certification Path Advertisement Message Format

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

      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      |     Code      |           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Identifier           |        All Components         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Component            |          Reserved             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-






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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   IP Fields:

      Source Address

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

      Destination Address

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

      Hop Limit

         255

   ICMP Fields:

      Type

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

      Code

         0

      Checksum

         The ICMP checksum [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 advertisements sent to the All-Nodes
         multicast address and MUST NOT be zero for others.

      All Components

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

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

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

      Component

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

         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 sending of path components SHOULD be ordered so that the
         certificate after the trust anchor is sent first. Each
         certificate sent after the first can be verified with the
         previously sent certificates. The certificate of the sender
         comes last. The trust anchor certificate SHOULD NOT be sent.

      Reserved

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

   Valid Options:

      Certificate

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

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

      Trust Anchor

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






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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

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


6.4.3 Trust Anchor Option

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

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Name Type    |  Pad  Length  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Name ...                                                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          ... Padding                                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

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

   Length

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

   Name Type

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

               1        DER Encoded X.501 Name
               2        FQDN

   Pad Length

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

   Name

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      DER encoded X.501 Name identifying the trust anchor. The value is
      encoded as defined in [15] and [10].

      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
      DNS wire format, as specified in RFC 1034 [1]. Additionally, the
      restrictions discussed in RFC 3280 [10] Section 4.2.1.7 apply.

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

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

   Padding

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


6.4.4 Certificate Option

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

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |    Length     |  Cert Type    |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Certificate ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 ...       Padding                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      TBD <To be assigned by IANA for Certificate>.

   Length

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




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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   Cert Type

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

               1        X.509v3 Certificate, as specified below

   Reserved

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

   Certificate

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

   Padding

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


6.4.5 Processing Rules for Routers

   A router MUST silently discard any received Certification Path
   Solicitation messages that do not conform to the message format
   defined in Section 6.4.1. The contents of the Reserved field, 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
   messages MUST be ignored and the packet processed in the normal
   manner.  The only defined option that may appear is the Trust Anchor
   option.  A solicitation that passes the validity checks is called a
   "valid solicitation".

   Routers SHOULD send advertisements in response to valid solicitations
   received on an advertising interface. If the source address in the
   solicitation was the unspecified address, the router MUST send the
   response to the link-scoped All-Nodes multicast address. If the
   source address was a unicast address, the router MUST send the
   response to the Solicited-Node multicast address corresponding to the



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

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

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

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

6.4.6 Processing Rules for Hosts

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

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

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

   The host has a need to retrieve a certification path when a Router
   Advertisement has been received with a public key that is not
   available from a certificate in the hosts' cache of certificates, or
   there is no certification path to the one of the host's trust
   anchors. In these situations, the host MAY send a Certification Path
   Solicitation message to retrieve the path.  If there is no response
   within CPS_RETRY seconds, the message should be retried. The wait
   interval for each subsequent retransmission MUST exponentially
   increase, doubling each time.  If there is no response after
   CPS_RETRY_MAX seconds, the host abandons the certification path
   retrieval process. If the host receives only a part of a
   certification path within CPS_RETRY_FRAGMENTS seconds of receiving
   the first part, it MAY in addition transmit a Certification Path
   Solicitation message with the Component field set to a value not
   equal to 65,535. This message can be retransmitted using the same
   process as in the initial message. If there are multiple missing
   certificates, additional such CPS messages can be sent after getting
   a response to first one. However, the complete retrieval process may
   last at most CPS_RETRY_MAX seconds.

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

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

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   specified above for routers.  However, the exact details are outside
   the scope of this specification.

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

6.5 Configuration

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

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

   o  A name as described in Section 6.4.3.

   o  An optional public key identifier.

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

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

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

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













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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


7. Addressing

7.1 CGAs

   By default, a SEND-enabled node SHOULD use only CGAs for its own
   addresses. Other types of addresses MAY be used in testing,
   diagnostics or for other purposes. However, this document does not
   describe how to choose between different types of addresses for
   different communications. A dynamic selection can be provided by an
   API, such as the one defined in [24].

7.2 Redirect Addresses

   If the Target Address and Destination Address fields in the ICMP
   Redirect message are equal, then this message is used to inform hosts
   that a destination is 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 treated as unsecured, as described in Section 7.3.

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

7.3 Advertised Subnet Prefixes

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

   Certified subnet prefixes fall into the following two categories:

   Constrained

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




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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   Unconstrained

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

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

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

7.4 Limitations

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

   It is outside the scope of this specification to describe the use of
   trust anchor authorization between nodes with dynamically changing
   addresses.  Such dynamically changing addresses may be the result of
   stateful or stateless address autoconfiguration, or through the use
   of RFC 3041 [20] addresses.  If the CGA method is not used, nodes are
   required to exchange certification paths that terminate in a
   certificate authorizing a node to use an IP address having a
   particular interface identifier.  This specification does not specify
   the format of such certificates, since there are currently only a few
   cases where such certificates are provided by the link layer and it
   is up to the link layer to provide certification for the interface
   identifier.  This may be the subject of a future specification.  It
   is also outside the scope of this specification to describe how
   stateful address autoconfiguration works with the CGA method.

   The Target Address in Neighbor Advertisement is required to be equal
   to the source address of the packet, except in the case of proxy
   Neighbor Discovery. Proxy Neighbor Discovery is not supported by this



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   specification.


















































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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


8. Transition Issues

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

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

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

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

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

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

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

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

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

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      tentative address is already in use, generate a new tentative CGA.
      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.

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

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

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

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

      Upper layer confirmations on unsecured neighbor cache entries
      SHOULD NOT update neighbor cache state from STALE to REACHABLE on
      a SEND node, if the neighbour cache entry has never previously
      been REACHABLE.  This ensures that if an entry spoofing a valid
      SEND host is created by a non-SEND attacker without being
      solicited, NUD will be done within 5 seconds of use of the entry
      for data transmission.

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




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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

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






























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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


9. Security Considerations

9.1 Threats to the Local Link Not Covered by SEND

   SEND does not provide confidentiality for NDP communications.

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

   There may be no cryptographic binding in SEND between the link layer
   frame address and the IPv6 address.  On an unsecured 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 with the link layer source address on the frame being
   the source address of a victim, a valid CGA address and a valid
   signature corresponding to itself, and a Target Link-layer Address
   extension corresponding to the victim.  The attacker could then
   proceed to cause a traffic stream to bombard the victim in a DoS
   attack. This attack cannot be prevented just by securing the link
   layer.

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

   Prior to participating in Neighbor Discovery and Duplicate Address
   Detection, nodes must subscribe to the link-scoped All-Nodes
   Multicast Group and the Solicited-Node Multicast Group for the
   address that they are claiming for their addresses; RFC 2461 [7].
   Subscribing to a multicast group requires that the nodes use MLD
   [19].  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 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.

9.2 How SEND Counters Threats to NDP

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



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   the protocol counter each threat.

9.2.1 Neighbor Solicitation/Advertisement Spoofing

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

   1.  Entries made as a side effect of a Neighbor Solicitation or
       Router Solicitation. A router receiving a Router Solicitation
       with a Target Link-Layer Address extension and the IPv6 source
       address not equal to the unspecified address inserts an entry for
       the IPv6 address into its Neighbor Cache. Also, a node performing
       Duplicate Address Detection (DAD) that receives a Neighbor
       Solicitation for the same address regards the situation as a
       collision and ceases to solicit for the address.

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

       SEND nodes can send Router Solicitation messages with a CGA
       source address and a CGA option, which the router can verify, so
       the Neighbor Cache binding is correct.  If a SEND node must send
       a Router Solicitation with the unspecified address, the router
       will not update its Neighbor Cache, as per base NDP.

   2.  Entries made as a result of a Neighbor Advertisement message.
       SEND counters this threat by requiring the RSA Signature and CGA
       options to be 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 Neighbor Solicitations
   sent as NUD probes to include an RSA Signature option 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.

9.2.3 Duplicate Address Detection DoS Attack

   This attack is described in Section 4.1.3 of [25].  SEND counters
   this attack by requiring the Neighbor Advertisements sent as
   responses to DAD to include an RSA Signature option and proof of
   authorization to use the interface identifier in the address being



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   tested.  If these prerequisites are not met, the node performing DAD
   discards the responses.

   When a SEND node is performing DAD, it may listen for address
   collisions from non-SEND nodes for the first address it generates,
   but not for new attempts.  This protects the SEND node from DAD DoS
   attacks by non-SEND nodes or attackers simulating non-SEND nodes, at
   the cost of a potential address collision between a SEND node and a
   non-SEND node.  The probability and effects of such an address
   collision are discussed in [14].

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 an RSA Signature option, and that the
   signature is calculated using the public key of a node that can prove
   its authorization to route the subnet 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 discarded.

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

9.2.5 Replay Attacks

   This attack is described in Section 4.3.1 of [25].  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. The following security issues are
   relevant only for unsolicited messages:

   o  A window of vulnerability for replay attacks exists until the
      timestamp expires.

      However, such vulnerabilities are only useful for attackers if the
      advertised parameters change during the window. While some
      parameters (such as the remaining lifetime of a prefix) change
      often, radical changes typically happen only in the context of



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


      some special case, such as switching to a new link layer address
      due to a broken interface adapter.

      SEND nodes are also 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.3.1, this may affect some
      nodes.

   o  Attacks against time synchronization protocols such as NTP [26]
      may cause SEND nodes to have an incorrect timestamp value. This
      can be used to launch replay attacks even outside the normal
      window of vulnerability.  To protect against such attacks, it is
      recommended that SEND nodes keep independently maintained clocks,
      or apply suitable security measures for the time synchronization
      protocols.


9.2.6 Neighbor 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 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
   cache management. These are all techniques involved in implementing
   Neighbor Discovery on the router.

9.3 Attacks against SEND Itself

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

   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.2.2. In this process,
   a simple hash verification of the CGA property of the address is



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   performed before performing the more expensive signature
   verification. However, even if the CGA verification succeeds, no
   claims about the validity of the message can be made, until the
   signature has been checked.

   When trust anchors and certificates are used for address validation
   in SEND, the defenses are not quite as effective. Implementations
   SHOULD track the resources devoted to the processing of packets
   received with the RSA Signature option, and start selectively
   discarding packets if too many resources are 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 certification paths 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 in which they
   engage.

   Attackers may also target hosts by sending a large number of
   unnecessary certification paths, 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
   certification paths and their verification.  Hosts SHOULD also
   prioritize advertisements sent as a response to solicitations the
   hosts have sent above unsolicited advertisements.
























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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


10. Protocol Values

10.1 Constants

   Host constants:

         CPS_RETRY                      1 second
         CPS_RETRY_FRAGMENTS            2 seconds
         CPS_RETRY_MAX                 15 seconds

   Router constants:

         MAX_CPA_RATE                  10 times per second


10.2 Variables

       TIMESTAMP_DELTA                   300 seconds (5 minutes)
       TIMESTAMP_FUZZ                      1 second
       TIMESTAMP_DRIFT                     1 % (0.01)































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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


11. 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 Certification Path Solicitation message, described in Section
      6.4.1.

   o  The Certification Path Advertisement message, described in Section
      6.4.2.

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

   o  The CGA option, described in Section 5.1.

   o  The RSA 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.4.3.

   o  The Certificate option, described in Section 6.4.4.

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

   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 [6]. The current values for this field are:

   1  DER Encoded X.501 Name

   2  FQDN

   Another new name space is allocated for the Cert Type field in the
   Certificate option. Future values of this field can be allocated
   using Standards Action [6]. The current values for this field are:

   1  X.509v3 Certificate







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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


Normative References

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

   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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

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

   [5]   Piper, D., "The Internet IP Security Domain of Interpretation
         for 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 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]  Farrell, S. and R. Housley, "An Internet Attribute Certificate
         Profile for Authorization", RFC 3281, April 2002.

   [12]  Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing
         Domain Names in Applications (IDNA)", RFC 3490, March 2003.

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

   [14]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-ietf-send-cga-06 (work in progress), April 2004.



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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   [15]  International Telecommunications Union, "Information Technology
         - ASN.1 encoding rules: Specification of Basic Encoding Rules
         (BER), Canonical Encoding Rules (CER) and Distinguished
         Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.

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

   [17]  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 (Editor), et al.    Expires January 15, 2005             [Page 57]

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


Informative References

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

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

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

   [21]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
         Carney, "Dynamic Host Configuration Protocol for IPv6
         (DHCPv6)", RFC 3315, July 2003.

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

   [23]  Arkko, J., "Manual SA Configuration for IPv6 Link Local
         Messages", draft-arkko-manual-icmpv6-sas-01 (work in progress),
         June 2002.

   [24]  Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API
         for Address Selection", draft-chakrabarti-ipv6-addrselect-02
         (work in progress), October 2003.

   [25]  Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
         Discovery trust models and threats", draft-ietf-send-psreq-04
         (work in progress), October 2003.

   [26]  Bishop, M., "A Security Analysis of the NTP Protocol", Sixth
         Annual Computer Security Conference Proceedings, December 1990.


Authors' Addresses

   Jari Arkko
   Ericsson

   Jorvas  02420
   Finland

   EMail: jari.arkko@ericsson.com







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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   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 (Editor), et al.    Expires January 15, 2005             [Page 59]

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


Appendix A. Contributors and Acknowledgments

   Tuomas Aura contributed the transition mechanism specification in
   Section 8. Jonathan Trostle contributed the certification path
   example in Section 6.3.1.

   The authors would also like to thank Tuomas Aura, Erik Nordmark,
   Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien
   Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri Niemi,
   Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for
   interesting discussions in this problem space and feedback regarding
   the SEND protocol.







































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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


Appendix B. 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 the dangers of
   mono-cultural 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 to 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, in spite of the
       attack.

   Since the intent is to limit the damage to existing, valid cache
   entries, it is clearly better to be very selective in how to throw
   out entries.  Reducing the timestamp Delta value is very
   discriminatory against those nodes that have a large clock
   difference, since an attacker can reduce its clock difference
   arbitrarily.  Throwing out old entries just because their clock
   difference is large therefore 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 can 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.  To counter
   this, the node can be more intelligent in keeping its cache entries,
   and not just have a black/white old/new boundary.

   Consideration of the Sec parameter from the CGA Parameters when
   forcing cache entries out - by keeping entries with larger Sec
   parameters preferentially - also appears to be a possible approach,
   since CGAs with higher Sec parameters are harder to spoof.









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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


Appendix C. Message Size When Carrying Certificates

   In one example scenario using SEND, an Authorization Delegation
   Discovery test run was made using a certification path length of
   four. Three certificates are sent using Certification Path
   Advertisement messages, since the trust anchor's certificate is
   already known by both parties. With a key length of 1024 bits, the
   certificate lengths in the test run ranged from 864 to 888 bytes; the
   variation is due to the differences in the certificate issuer names
   and address prefix extensions. The different certificates had between
   one to four address prefix extensions.

   The three Certification Path Advertisement messages ranged from 1050
   to 1066 bytes on an Ethernet link layer. The certificate itself
   accounts for the bulk of the packet. The rest is the trust anchor
   option, ICMP header, IPv6 header, and link layer header.



































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

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


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

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   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 (Editor), et al.    Expires January 15, 2005             [Page 63]

Internet-Draft      SEcure Neighbor Discovery (SEND)           July 2004


   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
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

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







































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


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/