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

Versions: 00 01 draft-arkko-send-ndopt

Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Expires: August 25, 2003                                        J. Kempf
                                          DoCoMo Communications Labs USA
                                                           B. Sommerfeld
                                                        SUN Microsystems
                                                                 B. Zill
                                                               Microsoft
                                                       February 24, 2003


                    SEcure Neighbor Discovery (SEND)
                      draft-ietf-send-ipsec-00.txt

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 August 25, 2003.

Copyright Notice

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

Abstract

   IPv6 nodes use the Neighbor Discovery (ND) protocol to discover other
   nodes on the link, to determine each other's link-layer addresses, to
   find routers and to maintain reachability information about the paths
   to active neighbors.  If not secured, ND protocol is vulnerable to
   various attacks.  This document specifies an extension to IPsec for
   securing ND.  Contrary to the original ND specifications that also



Arkko, et al.           Expires August 25, 2003                 [Page 1]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   called for use of IPsec, this extension does not require the creation
   of a large number of manually configured security associations.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.    Terms  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.    Neighbor and Router Discovery Overview . . . . . . . . . . .  6
   4.    Secure Neighbor Discovery Overview . . . . . . . . . . . . .  9
   5.    Cryptographically Generated Addresses  . . . . . . . . . . . 11
         5.1   Address Format . . . . . . . . . . . . . . . . . . . . 12
         5.2   Basic Interface Identifier Generation  . . . . . . . . 12
         5.3   Address Generation . . . . . . . . . . . . . . . . . . 13
         5.4   Duplicate Address Detection  . . . . . . . . . . . . . 14
   6.    Authorization Delegation Discovery . . . . . . . . . . . . . 15
         6.1   Delegation Chain Solicitation Message Format . . . . . 15
         6.2   Delegation Chain Advertisement Message Format  . . . . 17
         6.3   Trusted Root Option  . . . . . . . . . . . . . . . . . 19
         6.4   Certificate Option . . . . . . . . . . . . . . . . . . 20
         6.5   Processing Rules for Routers . . . . . . . . . . . . . 21
         6.6   Processing Rules for Hosts . . . . . . . . . . . . . . 22
   7.    IPsec Extensions . . . . . . . . . . . . . . . . . . . . . . 25
         7.1   The AH_RSA_Sig Transform . . . . . . . . . . . . . . . 25
               7.1.1 Reserved SPI Number  . . . . . . . . . . . . . . 25
               7.1.2 Authentication Data Format . . . . . . . . . . . 25
               7.1.3 AH_RSA_Sig Security Associations . . . . . . . . 27
               7.1.4 Replay Protection  . . . . . . . . . . . . . . . 28
               7.1.5 Processing Rules for Senders . . . . . . . . . . 28
               7.1.6 Processing Rules for Receivers . . . . . . . . . 29
         7.2   Other IPsec Extensions . . . . . . . . . . . . . . . . 30
               7.2.1 Destination Agnostic Security Associations . . . 30
               7.2.2 ICMP Type Specific Selectors . . . . . . . . . . 31
   8.    Securing Neighbor Discovery with SEND  . . . . . . . . . . . 32
         8.1   Using IPsec to Secure Neighbor Advertisement Messages  32
         8.2   Security Policy and SA Database Configuration  . . . . 32
   9.    Securing Router Discovery with SEND  . . . . . . . . . . . . 34
         9.1   Using IPsec to Secure Router Advertisement Messages  . 34
         9.2   Using IPsec to Secure Redirect Messages  . . . . . . . 34
         9.3   Security Policy and SA Database Configuration  . . . . 35
   10.   Operational Considerations . . . . . . . . . . . . . . . . . 37
   11.   Performance Considerations . . . . . . . . . . . . . . . . . 39
   12.   Security Considerations  . . . . . . . . . . . . . . . . . . 40
         12.1  Achieved Security Properties . . . . . . . . . . . . . 40
         12.2  Attacks against SEND Itself  . . . . . . . . . . . . . 40
   13.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 42
   14.   Conclusions and Remaining Work . . . . . . . . . . . . . . . 43
         Normative References . . . . . . . . . . . . . . . . . . . . 44
         Informative References . . . . . . . . . . . . . . . . . . . 45



Arkko, et al.           Expires August 25, 2003                 [Page 2]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46
   A.    Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47
   B.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48
   C.    IPR Considerations . . . . . . . . . . . . . . . . . . . . . 49
         Intellectual Property and Copyright Statements . . . . . . . 50














































Arkko, et al.           Expires August 25, 2003                 [Page 3]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


1. Introduction

   IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [6].
   Nodes on the same link use the ND protocol 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.  The ND protocol is used both by hosts and routers.
   Its functions include Router Discovery (RD), Address Auto-
   configuration, Address Resolution, Neighbor Unreachability Detection
   (NUD), Duplicate Address Detection (DAD), and Redirection.

   RFC 2461 called for the use of IPsec for protecting the ND messages.
   However, it turns out that in this particular application IPsec can
   only be used with a manual configuration of security associations due
   to chicken-and-egg problems [17] in using IKE [15] before ND is
   operational.  Furthermore, the number of security associations needed
   for protecting ND is impractically large [18].  Finally, RFC 2461 did
   not specify detailed instructions for using IPsec to secure ND.

   Section 4 describes our overall approach to securing ND.  This
   approach involves the use of IPsec AH [3] to secure all
   advertisements relating to Neighbor and Router Discovery.  A new
   transform for AH allows public keys to be used.  Routers are
   certified by a trusted root, and a zero-configuration mechanism for
   showing address ownership.

   Section 5 describes the mechanism for showing address ownership,
   based on the use of Cryptographically Generated Addresses (CGAs).
   Section 6 describes the mechanism for distributing certificate chains
   to establish authorization delegation chain to a common trusted root.
   Section 7 describes the necessary modifications to IPsec.  Finally,
   Section 8 show how to apply these components to securing Neighbor and
   Router Discovery.


















Arkko, et al.           Expires August 25, 2003                 [Page 4]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


2. Terms

   Cryptographically Generated Addresses (CGAs) A technique [22] where
      the address of the node is cryptographically generated from the
      public key of the node and some other parameters using a one-way
      hash function.

   Internet Control Message Protocol version 6 (ICMPv6) The IPv6 control
      signaling protocol.  Neighbor Discovery is a part of ICMPv6.

   Neighbor Discovery (ND) The IPv6 Neighbor Discovery protocol [6].

   Security Association (SA) A Security Association (SA) is a simplex
      "connection" that affords security services to the traffic carried
      by it.  Security services are afforded to an SA by the use of AH,
      or ESP, but not both.  A SA is uniquely identified by a triple
      consisting of a Security Parameter Index (SPI), an IP Destination
      Address, and a security protocol (AH or ESP) identifier [2].

   Security Association Database (SAD) A nominal database containing
      parameters that are associated with each (active) security
      association.  For inbound and outbound IPsec processing, these
      databases are separate.

   Security Parameters Index (SPI) An arbitrary 32-bit value.  Together
      with the destination IP address and security protocol (ESP or AH)
      identifier, the SPI uniquely identifies the Security Association.
      Values from 1 to 255 are reserved.

   Special SPI A Security Parameters Index from the reserved range 1 to
      255.

   Security Policy The Security Policy determines the security services
      afforded to an IPsec protected packet and the treatment of the
      packet in the network.

   Security Policy Database (SPD) A nominal database containing a list
      of policy entries.  Each policy entry is keyed by one or more
      selectors that define the set of IP traffic encompassed by this
      policy entry.  Separate entries for inbound and outbound traffic
      is required  [2].










Arkko, et al.           Expires August 25, 2003                 [Page 5]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


3. Neighbor and Router Discovery Overview

   IPv6 Neighbor and Router Discovery have several functions.  Many of
   these functions are overloaded on a few central message types such as
   the ICMPv6 Neighbour Discovery message.  In this section we explain
   some of these tasks and their effects in order to understand better
   how the messages should be treated.  Where this section and the
   original Neighbor Discovery RFCs are in conflict, the original RFCs
   take precedence.

   In IPv6, many of the tasks traditionally done at lower layers such as
   ARP have been moved to the IP layer.  As a consequence, unified
   mechanisms can be applied across link layers, security mechanisms or
   other extensions can be adopted more easily, and a clear separation
   of the roles between the IP and link layer can be achieved.

   The main functions of IPv6 Neighbor Discovery are as follows:

   o  Neighbor Unreachability Detection (NUD) is used for tracking the
      reachability of neighbors, both hosts and routers.  NUD is defined
      in Section 7.3 of RFC 2461 [6].  No higher level traffic can
      proceed if this procedure flushes out neighbour cache entries
      after (perhaps incorrectly) determining that the peer is not
      reachable.

   o  Duplicate Address Detection (DAD) is used for preventing address
      collisions [7].  A node that intends to assign a new address to
      one of its interfaces runs first the DAD procedure to verify that
      other nodes are not using the same address.  Since the outlined
      rules forbid the use of an address until it has been found unique,
      no higher layer traffic is possible until this procedure has
      completed.

   o  Address Resolution is similar to IPv4 ARP [14].  The Address
      Resolution function resolves a node's IPv6 address to the
      corresponding link-layer address for nodes on the link.  Address
      Resolution is defined in Section 7.2 of RFC 2461 [6] and it is
      used for hosts and routers alike.  Again, no higher level traffic
      can proceed until the sender knows the hardware address of the
      destination node or the next hop router.  Note that like its
      predecessor in ARP, IPv6 Neighbor Discovery does not check the
      source link layer address against the information learned through
      Address Resolution.  This allows for an easier addition of network
      elements such as bridges and proxies, and eases the stack
      implementation requirements as less information needs to be passed
      from layer to another layer.

   o  Address Autoconfiguration is used for automatically assigning



Arkko, et al.           Expires August 25, 2003                 [Page 6]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


      addresses to a host [7].  This allows hosts to operate without
      configuration related to IP connectivity.  The Address
      Autoconfiguration mechanism is stateless, where the hosts use
      prefix information delivered to them during Router Discovery to
      create addresses, and then test these addresses for uniqueness
      using the DAD procedure.  A stateful mechanism, DHCPv6 [19],
      provides additional Autoconfiguration features.  Router and Prefix
      Discovery and Duplicate Address Detection have an effect to the
      Address Autoconfiguration tasks.

   o  The Redirect function is used for automatically redirecting hosts
      to an alternate router.  Redirect is specified in Section 8 of RFC
      2461 [6].  It is similar to the ICMPv4 Redirect message [13].

   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 [6].  The main purpose of Router
      Discovery is to find neighboring routers that are willing to
      forward packets on the behalf of hosts.  Prefix discovery involves
      determining which destinations are directly on a link; this
      information is necessary in order to know whether a packet should
      be sent to a router or to the destination node directly.
      Typically, address autoconfiguration and other tasks can't proceed
      until suitable routers and prefixes have been found.

   The Neighbor Discovery messages follow the ICMPv6 message format and
   ICMPv6 types from 133 to 137.  The IPv6 Next Header value for ICMPv6
   is 58.  The actual Neighbor Discovery message includes an ND message
   header consisting of ICMPv6 header and ND message-specific data, and
   zero or more ND options:

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

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

   All IPv6 ND protocol functions are realized using the following
   messages:








Arkko, et al.           Expires August 25, 2003                 [Page 7]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


            ICMPv6 Type      Message
            ------------------------------------
            133              Router Solicitation (RS)
            134              Router Advertisement (RA)
            135              Neighbor Solicitation (NS)
            136              Neighbor Advertisement (NA)
            137              Redirect

   The functions of the ND protocol are realized using these messages as
   follows:

   o  Router Discovery uses the RS and RA messages.

   o  Duplicate Address Detection uses the NS and NA messages.

   o  Address Autoconfiguration uses the NS, NA, RS, and RA messages.

   o  Address Resolution uses the NS and NA messages.

   o  Neighbor Unreachability Detection uses the NS and NA messages.

   o  Redirect uses the Redirect message.

   The addresses used in these messages are as follows:

   o  Neighbor Solicitation: The destination address is either the
      solicited node multicast address, unicast address, or an anycast
      address.

   o  Neighbour Advertisement: The destination address is either a
      unicast address or the All Nodes multicast address [1].

   o  Router Solicitation: The destination address is typically the All
      Routers multicast address [1].

   o  Router Advertisement: The destination address can be either a
      unicast or the All Nodes multicast address [1].  Like the
      solicitation message, the advertisement is also local to the link
      only.

   o  Redirect: This message is always sent from the router's link-local
      address to the source address of the packet that triggered the
      Redirect.  Hosts verify that the IP source address of the Redirect
      is the same as the current first-hop router for the specified ICMP
      Destination Address.  Rules in [1] dictate that unspecified,
      anycast, or multicast addresses may not be used as source
      addresses.  Therefore, the destination address will always be a
      unicast address.



Arkko, et al.           Expires August 25, 2003                 [Page 8]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


4. Secure Neighbor Discovery Overview

   IPsec AH is used in to protect Neighbor and Router Discovery
   messages.  This specification introduces the use of a new transform
   for IPsec AH, extensions to the current IPsec selectors, an
   authorization delegation discovery process, and an address ownership
   proof mechanism.

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

   o  IPsec AH is used to protect all advertisement messages relating to
      Neighbor and Router discovery.  Solicitation messages are not
      protected, as they do not carry any information.

   o  IPsec security policy database and security association database
      are configured to require the protection as indicated above.  Note
      that such configuration may take place manually or the operating
      system may perform it automatically upon enabling Secure Neighbor
      Discovery.

      This specification introduces extensions to the required selectors
      used in security policy database entries.  This is necessary in
      order to enable the protection of specific ICMP message types,
      while leaving other messages unprotected.

   o  A new transform for IPsec AH allows public keys to be used on a
      security association directly without the involvement of a key
      management protocol.  Symmetric session keys are not used, public
      key signatures are used instead.  The trust to the public key is
      established either with the authorization delegation process or
      the address ownership proof mechanism, depending on configuration
      and the type of the message protected.

      The new transform uses also a fixed, standardized SPI (Security
      Parameters Index) number.  This necessary again in order to avoid
      the involvement of a key management protocol.

      Given that Neighbor and Router Discovery messages are in some
      cases sent to multicast addresses, the new transform uses a
      timestamp mechanism as a replay mechanism instead of sequence
      numbers.

   o  Trusted roots are expected to certify the authority of routers.  A
      host and a router must have at least one common trusted root
      before the host can accept adopt the router as its default router.
      Delegation Chain Solicitation and Advertisement messages are used
      to discover a certificate chain to the trusted root without



Arkko, et al.           Expires August 25, 2003                 [Page 9]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


      requiring the actual Router Discovery messages to carry lengthy
      certificate chains.

   o  Cryptographically Generated Addresses are used to assure that the
      sender of a Neighbor or Router Advertisement is the owner of an
      the claimed address.  A public-private key pair needs to be
      generated by all nodes before they can claim an address.












































Arkko, et al.           Expires August 25, 2003                [Page 10]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


5. Cryptographically Generated Addresses

   Cryptographically Generated Addresses (CGAs) [22][23][20][25] are a
   technique whereby a node's IPv6 address can be unalterably tied to
   the node's public key.  Conceptually, CGAs allow a recipient of a
   message to determine whether the sender is authorized to use the
   public key and address claimed to be associated with the packet.
   Typically, this requires the sender to use the hash of the node's
   public key as the interface identifier in the bottom 64 bits of the
   IPv6 address.

   Authorization through CGAs and certificates are related, but separate
   mechanisms.  It is separate in that other techniques of authorization
   (i.e.  digital certificates) can be used instead of CGAs to achieve
   the same effect.  However, certificates require a means to create and
   distribute them, thereby imposing more overhead than CGA.  It is
   related in that a digital signature is required in addition to the
   CGA address and the signature must cover the address, in order that
   the recipient can have the confidence that the address was not
   altered in transit.  Furthermore, to properly authorize the address
   use, the issuer of the certificate must be considered as a valid
   source of authority for certifying address usage, and must be capable
   of making statements about an individual's use of IP addresses.
   Theoretically, proper use of certificates provides more assurance
   about address usage authorization than CGA.  However, it is often
   practically difficult to arrange the certificate authorities so that
   they can control which IP addresses can be used by which parties.
   The authorization provide by CGA is computational in nature, deriving
   its strength from the computational difficulty of creating duplicate
   CGA addresses.  It does not require any configuration tasks, and it
   does not impose any requirements on the infrastructure.
   Respectively, certificate based authorization is administrative in
   nature, and does not impose restrictions to the structure of the
   addresses.

   CGAs are particularly useful for Neighbor Discovery because they
   provide a low overhead way for the sender of a Neighbor Advertisement
   to indicate their authorization for claiming the address.  The
   recipient of a Neighbor Advertisement with a CGA Address, a public
   key, and a digital signature in the header can have confidence that:

   o  The packet was not modified in transit (due to the signature),

   o  The sender of the packet has a right to claim possession of the
      address (due to the authenticated CGA address).

   In this section, we describe how a sender generates CGA addresses and
   digital signatures for the AH header in Neighbor Advertisement



Arkko, et al.           Expires August 25, 2003                [Page 11]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   packets, and how the receiver of such a packet verifies it.  The
   description of CGA use for IPv6 Neighbor Discovery follows closely
   that described in [24].

5.1 Address Format

   The basic idea behind CGA addresses is to use some function of the
   host's public key as input to a hash function to generate the
   interface identifier (bottom 64 bits) in the IPv6 address.
   Variations on this basic theme provide additional security against
   denial of service attacks and futureproofing against increases in
   attacker processing power due to Moore's Law.  For purposes of secure
   Neighbor Discovery, CGA addresses are modified EUI-64 addresses [1]
   in which the "universal/local" bit (bit 6) is set to 1 (indicating
   global scope) and the "individual/group" bit (bit 7) is set to 1
   (indicating the CGA group).  Correct handling of these bits
   effectively reduces the size of the interface identifier to 62 bits.

5.2 Basic Interface Identifier Generation

   The basic hash algorithm for CGA addresses generates a 160 bit hash
   by concatenating the node's public key, a nonce, and routing prefix
   for the address in question.  This result is then hashed to obtain
   the actual interface identifier.  The input hash is generated as
   follows:

   Equation (1).
       H(N) = Hash-160(public_key |
                       nonce |
                       routing_prefix)
       H(i) = Hash-160(H(i+1))

   where Hash-160 is the 160 bits obtained from applying the SHA-1
   secure hashing algorithm [12], public_key is the node's public key in
   the format defined in Section 7.1.2, and nonce is a random octet
   string of 8 or more bytes.  The selection N is a local matter, but it
   MUST be at least 3.  N is used as a defense mechanism against
   denial-of-service attacks.

   The routing_prefix is the routing prefix for the address in question.
   Note that this value is used regardless of whether the scope of the
   address to be generated is link-local, site-local, or global.  If the
   scope is not global, it is possible that different networks will be
   using the same routing prefix, such as the FE80::/10 prefix for
   link-local addresses.  This is allowed, as the addresses are not used
   in the same network.  In any case, other components in Equation (1)
   typically provide sufficient randomness to avoid collisions and
   Duplicate Address Detection would avoid possibly remaining address



Arkko, et al.           Expires August 25, 2003                [Page 12]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   collisions.

   The host generates a series of these hash values.  The actual
   interface identifier is then generated by performing taking the
   rightmost 60 bits of the SHA-1 hash applied to the input value:

   Equation (2).
       interface_id = Hash-60(H(i))

   where Hash-60 is the rightmost 60 bits obtained from the application
   of the SHA-1 algorithm, i starts at 0 and increases depending on
   whether additional rounds of duplicate address detection must be
   negotiated (see Section 5.4).

   The routing_prefix term is included in the above in order to
   introduce a strong binding between the prefixes and interface
   identifiers, and to add some randomness in order to defeat brute
   force and birthday attacks.  If it is not included, an attacker can
   generate a lookup table of key pairs for each of the possible 2**60
   values of the interface identifier and use them to disrupt duplicate
   address detection.  Note, however, that including these in the
   address requires the host to perform duplicate address detection for
   each address configured on the interface, not just for the link local
   address, as is allowed by RFC 2462.

5.3 Address Generation

   Equation (2) in Section 4.1.1 only takes 60 bits of the SHA-1 hash,
   although 62 bits are theoretically available after the "u" and "g"
   bits are omitted.  This is because the right most 2 bits of the
   interface identifier are reserved for a security parameter.  The
   security parameter can have a value of 0 through 3, and is a way of
   future-proofing the CGA address against increases in processing power
   in attackers due to Moore's Law, since 62 bits is on the borderline
   of what is today computationally difficult to attack.  Conceptually,
   the security parameter is a way to increase the computational effort
   of both generating and attacking an address.  While this has the side
   effect of increasing the effort for the client, the client presumably
   only has to generate the address once, while an attacker may have to
   generate the address multiple times.

   The algorithm for generating the actual address is as follows, given
   the security parameter has value Sec:

   1.  Generate a key pair.

   2.  Generate a nonce value.




Arkko, et al.           Expires August 25, 2003                [Page 13]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   3.  Generate a table of hash values according to Equation (1).

   4.  Generate a target identifier according to Equation (2), but
       taking 20 x Sec + 60 bits instead of just 60 bits.

   5.  Compare the leftmost 20 x Sec to zero.  If not zero, go back to
       Step 2.

   6.  Set the universal and group bits to 1 and the rightmost two bits
       to Sec.

   7.  Use the result of Step 6 as the interface identifier for the
       address.

   If the security parameter is zero, this algorithm is the basic CGA
   algorithm.

   If the security parameter is greater than zero, the algorithm is not
   guaranteed to terminate after a certain number of iterations (though
   it will ultimately terminate).  For security parameter values 1, 2,
   and 3, the average number of iterations required to produce a
   matching hash output are 2**19, 2**39, and 2**59, i.e.  2**(20 x Sec
   -1) [24].  The additional amount of computational effort involved in
   increasing the security parameter allows the SEND algorithm to scale
   as Moore's law increases processing power.

5.4 Duplicate Address Detection

   During Duplicate Address Detection, a node may encounter a clash with
   another node on the link.  One possible denial of service attack
   occurs when the attacker deliberately provokes an address clash, in
   order to prevent the victim from claiming the address.  RFC 2462 [7]
   inadvertently facilitates this attack, by requiring nodes to
   terminate Duplicate Address Detection when a clash is detected.

   For Secure Neighbor Discovery, a node performs Duplicate Address
   Detection a maximum of 3 times.  If an address clash is detected, the
   node restarts interface identifier generation at Step 2 of the
   algorithm described in Section 4.1.2, by selecting a different hash
   input for target identifier generation.  If clashes are detected
   after three tries, the node is probably under attack, so it should
   shut down and report the situation to an administrator.









Arkko, et al.           Expires August 25, 2003                [Page 14]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


6. Authorization Delegation Discovery

   Several protocols, including IPv6 Neighbor Discovery, allow a node to
   automatically configure itself based on information it learns shortly
   after connecting to a new link.  It is particularly easy for "rogue"
   routers to be configured, and it is particularly difficult for a
   network node to distinguish between valid and invalid sources of
   information when the node needs this information before to
   communicate off-link.

   Since the newly-connected node likely can't communicate off-link, it
   can't be responsible for searching information to help validate the
   router; however, given a chain of appropriately signed certificates,
   it can check someone else's search results and conclude that a
   particular message comes from an authorized source.  Similarly, the
   router, which is already connected to the network, can if necessary
   communicate off-link and construct the certificate chain.

   The Secure Neighbor Discovery protocol introduces two new ICMPv6
   messages that can be used between hosts and routers to allow the
   client to learn the certificate chain with the assistance of the
   router.  Where hosts have certificates from a trusted root, these
   messages may also optionally be used between hosts to acquire the
   peer's certificate chain.

   The Delegation Chain Solicitation message is sent by hosts when they
   wish to request the certificate chain between a router and the one of
   the hosts' trusted roots.  The Delegation Chain Advertisement message
   is sent as an answer to this message, or periodically to the All
   Nodes multicast address.  Due to the size of certificates and
   potentially long certificate chains, the advertisement message may be
   large.  The messages have been made separate from the rest of
   Neighbor Discovery in order to reduce their effect on the size of
   other messages.  Long certificate chains may also be broken to
   multiple messages.

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

6.1 Delegation Chain Solicitation Message Format

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






Arkko, et al.           Expires August 25, 2003                [Page 15]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


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

   IP Fields:

      Source Address

         An IP 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, or the address of
         the hosts' default router.

      Hop Limit

         255

   ICMP Fields:

      Type

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

      Code

         0

      Checksum

         The ICMP checksum [8]..

      Identifier

         This 16 bit unsigned integer field acts as an identifier to
         help match advertisements to solicitations.  The Identifier
         field MUST NOT be zero.





Arkko, et al.           Expires August 25, 2003                [Page 16]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


      Reserved

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

   Valid Options:

      Trusted Root

         One or more trusted roots that the client is willing to accept.

      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the message.


6.2 Delegation Chain Advertisement Message Format

   Routers send out Delegation Chain Advertisement messages
   periodically, or in response to a Delegation Chain 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           |M|        Component            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Reserved                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Options ...
     +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address

         MUST be the link-local address assigned to the interface from
         which this message is sent.

      Destination Address

         Typically the Source Address of a host invoking Delegation
         Chain Solicitation or the all-nodes multicast address.

      Hop Limit

         255



Arkko, et al.           Expires August 25, 2003                [Page 17]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   ICMP Fields:

      Type

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

      Code

         0

      Checksum

         The ICMP checksum [8]..

      Identifier

         This 16 bit unsigned integer field acts as an identifier to
         help match advertisements to solicitations.  The Identifier
         field MUST be zero for unsolicited advertisements and MUST NOT
         be zero for solicited advertisements.

      M

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

      Component

         This is a 15 bit unsigned integer field.  The first message in
         a multi-component advertisement has the Component field set to
         0, the second set to 1, and so on.

      Reserved

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







Arkko, et al.           Expires August 25, 2003                [Page 18]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   Valid Options:

      Certificate

         Zero or one certificates are provided in Certificate options,
         to establish a certificate chain to a trusted root.

      Trusted Root

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

      Future versions of this protocol may define new option types.
      Receivers MUST silently ignore any options they do not recognize
      and continue processing the message.


6.3 Trusted Root Option

   The format of the Trusted Root option is as described in the
   following:

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

   Where the fields are as follows:

   Type

      TBD <To be assigned by IANA> for Trusted Root.

   Length

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

   Name Type

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




Arkko, et al.           Expires August 25, 2003                [Page 19]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


               1        FQDN

   Name Length

      The length of the Name field, in bytes.  Octets beyond this length
      but within the length specified by the Length field are padding
      and 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 the
      Fully Qualified Domain Name of the trusted root, for example
      "trustroot.operator.com".


6.4 Certificate Option

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

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

   Where the fields are as follows:

   Type

      TBD <To be assigned by IANA> for Certificate.

   Length

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

   Cert Type

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

               1        X.509 Certificate






Arkko, et al.           Expires August 25, 2003                [Page 20]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   Pad Length

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

   Certificate

      When the Cert Type field is set to 1, the Certificate field
      contains an X.509 certificate [10].


6.5  Processing Rules for Routers

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

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

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

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

   o  ICMP Checksum is valid.

   o  ICMP Code is 0.

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

   o  Identifier field is non-zero.

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

   The contents of the Reserved field, and of any unrecognized options,
   MUST be ignored.  Future, backward-compatible changes to the protocol
   may specify the contents of the Reserved field or add new options;
   backward-incompatible changes may use different Code values.  The
   contents of any defined options that are not specified to be used
   with Router Solicitation messages MUST be ignored and the packet
   processed as normal.  The only defined option that may appear is the
   Trusted Root option.  A solicitation that passes the validity checks
   is called a "valid solicitation".

   Routers MAY send unsolicited Delegation Chain Advertisements for



Arkko, et al.           Expires August 25, 2003                [Page 21]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   their trusted root.  When such advertisements are sent, their timing
   MUST follow the rules given for Router Advertisements in RFC 2461
   [6].  The only defined option that may appear is the Certificate
   option.  At least one such option MUST be present.  Router SHOULD
   also include at least one Trusted Root option to indicate the trusted
   root on which the Certificate is based.

   In addition to sending periodic, unsolicited advertisements, a router
   sends advertisements in response to valid solicitations received on
   an advertising interface.  A router MAY choose to unicast the
   response directly to the soliciting host's address (if the
   solicitation's source address is not the unspecified address), but
   the usual case is to multicast the response to the all-nodes group.

   In a solicited advertisement, the router SHOULD include suitable
   Certificate options so that a delegation chain to the solicited root
   can be established.  The root is identified by the FQDN from the
   Trusted Root option being equal to an FQDN in the AltSubjectName
   field of the root's certificate.  The router SHOULD include the
   Trusted Root option(s) in the advertisement for which the delegation
   chain was found.

   If the router is unable to find a chain to the requested root, it
   SHOULD send an advertisement without any certificates.  In this case
   the router SHOULD include the Trusted Root options which were
   solicited.

   Rate limitation of Delegation Chain Advertisements is performed as
   specified for Router Advertisements in RFC 2461 [6].

6.6  Processing Rules for Hosts

   Hosts SHOULD possess the certificate of at least one certificate
   authority, and MAY possess their own keypair and certificate from
   this authority.

   A host MUST silently discard any received Router Advertisement
   messages that do not satisfy all of the following validity checks:

   o  IP Source Address is a link-local address.  Routers must use their
      link-local address as the source for Router Advertisement and
      Redirect messages so that hosts can uniquely identify routers.

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

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



Arkko, et al.           Expires August 25, 2003                [Page 22]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   o  ICMP Checksum is valid.

   o  ICMP Code is 0.

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

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

   The contents of the Reserved field, and of any unrecognized options,
   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 Advertisement messages MUST be ignored and the packet
   processed as normal.  The only defined option that may appear is the
   Certificate option.  An advertisement that passes the validity checks
   is called a "valid advertisement".

   Hosts SHOULD store all certificates retrieved in Delegation Chain
   Advertisements for use in subsequent verification of Router (and
   optionally Neighbor) Advertisements.  Note that it may be useful to
   cache this information and implied verification results for use over
   multiple attachments to the network.

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

   o  The interface is initialized at system startup time.

   o  The interface is reinitialized after a temporary interface failure
      or after being temporarily disabled by system management.

   o  The system changes from being a router to being a host, by having
      its IP forwarding capability turned off by system management.

   o  The host attaches to a link for the first time.

   o  A movement has been indicated by lower layers or has been inferred
      from changed information in a Router Advertisement.

   o  The host re-attaches to a link after being detached for some time.

   o  A Router Advertisement has been received with a public key that is
      not stored in the hosts' cache of certificates, or there is no



Arkko, et al.           Expires August 25, 2003                [Page 23]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


      authorization delegation chain to the host's trusted root.

   Delegation Chain Solicitations MUST NOT be sent if a valid
   certificate chain exists in the host's cache from the desired router
   (or host) to the host's trusted root.

   A host MUST send Delegation Chain Solicitations either to the
   All-Routers multicast address, if it hasn't selected a default router
   yet, or to the default router's IP address if it has already been
   selected.  If two hosts communicate with the solicitations and
   advertisements, these MUST be unicast to the hosts's address.

   Delegation Chain Solicitations SHOULD be rate limited and timed
   similarly with Router Solicitations, as specified in RFC 2461 [6].

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































Arkko, et al.           Expires August 25, 2003                [Page 24]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


7. IPsec Extensions

   In order to use IPsec in securing Neighbor and Router Discovery some
   extensions have been specified in this document.  These include a new
   transform suitable for the use of public keys and/or CGAs, a
   timestamp mechanism suitable for replay protection in a multicast
   environment, and some extensions to security association and security
   policy databases.

7.1 The AH_RSA_Sig Transform

   The AH_RSA_Sig transform specifies how AH can be used without a
   symmetric key.  This transform introduces the use of a new reserved
   SPI number and a new format for the Authentication Data field in AH.

   AH_RSA_Sig MUST NOT be negotiated in IKE.  For consistency it has an
   IPsec DOI [4] Transform ID TBD <To Be Assigned by IANA>, however.

7.1.1 Reserved SPI Number

   The AH_RSA_Sig MUST be only be used with the reserved SPI number TBD
   <To Be Assigned by IANA>.

7.1.2 Authentication Data Format

   The format of the Authentication Data field in AH depends on the
   chosen transform.  For the AH_RSA_Sig transform, the format is as
   follows:























Arkko, et al.           Expires August 25, 2003                [Page 25]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            PK_Len             |          Nonce_Len            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                          Timestamp                            +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                          Public key                           .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       Nonce (optional)                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .              Digital Signature (remaining bytes)              .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meaning of the fields is described below:

   PK_Len

      This 16 bit unsigned integer field contains the length of the
      Public Key field in bytes.

   Nonce_Len

      This 16 bit unsigned integer field contains the length of the
      Nonce field in bytes.  The length is set to zero if that field is
      not present.

   Timestamp

      This 64 bit unsigned integer field contains a timestamp used for
      replay protection (the Sequence Number field in AH is not used for
      AH_RSA_Sig).  The use of this field is discussed in Section 7.1.4.

   Public key

      This variable length field contains the public key of the sender



Arkko, et al.           Expires August 25, 2003                [Page 26]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


      in X.509 format [10].

   Nonce

      This variable length field, if present, contains the nonce used in
      the construction of the CGA address.

   Digital Signatures

      This variable length field, if present, contains the signature
      made using the sender's private key, over the the whole packet as
      defined by the usual AH rules [3].  The signature is made using
      the RSA algorithm and MUST be encoded as private key encryption in
      PKCS #1 format [11].


7.1.3 AH_RSA_Sig Security Associations

   Security associations that specify the use of AH_RSA_Sig transform
   MUST record the following additional configuration information:

   o  A flag that indicates whether or not authorization delegation to a
      trusted root is used.

   o  A flag that indicates whether or not CGA addresses are used.

   Incoming security associations MUST also record the following
   additional information:

   o  The public key of the trusted root, if authorization delegation is
      in use.

   o  The minimum acceptable key length for peer public keys (and any
      intermediaries between the trusted root and the peer).  The
      default SHOULD be 768 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.

   o  The minimum acceptable Sec value, if CGA verification is required.

   Outgoing security associations MUST also record the following
   additional information:

   o  A public-private keypair.  If authorization delegation is in use,
      there must exist a delegation chain from a trusted root to this
      keypair.




Arkko, et al.           Expires August 25, 2003                [Page 27]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   o  Optionally any information required to construct CGA signatures,
      including the used Sec value and nonce, and the resulting CGA
      address.


7.1.4 Replay Protection

   For AH_RSA_Sig, the Sequence Number field in AH MUST be set to zero
   by the sender and ignored by receivers.

   If anti-replay has been enabled in the security association, senders
   MUST set the Timestamp field to the current time.  The format is 64
   bits, and the contents are the number of milliseconds since January
   1, 1970 00:00 UTC.

   If anti-replay has been enabled, receivers MUST be configured with an
   allowed Delta value and maintain a cache of messages received within
   this time period from each specific source address.  Receivers MUST
   then check the Timestamp field as follows:

   o  A packet with a Timestamp field value beyond the current time plus
      or minus the allowed Delta value MUST be silently discarded.

   o  A packet accepted according to the above rule MUST be checked for
      uniqueness within the cache of received messages from the given
      source address.  A packet that has already been seen from the same
      source with the same Timestamp field value MUST be silently
      discard.

   o  A packet that passes both of the above tests MUST be registered in
      the cache for the given source address.

   o  If the cache becomes full, the receiver SHOULD temporarily reduce
      the Delta value for that source address so that all messages
      within that value can still be stored.


7.1.5 Processing Rules for Senders

   A node sending a packet using the AH_RSA_Sig transform MUST construct
   the packet as follows:

   o  The Next Header, Payload Len, and Reserved fields are set as
      described in RFC 2402.

   o  The Security Parameters Index is set to the value specified in
      Section 7.1.1.




Arkko, et al.           Expires August 25, 2003                [Page 28]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   o  The Sequence Number field is set to 0.

   o  The PK_Len field in Authentication Data is set to the length of
      the public key used for signing this packet.  This public key is
      stored in the security association.  The key itself is put to the
      Public key field.

   o  If the security association has specified the use of the CGA
      method, the Nonce_len field is set to the length of the nonce used
      in the construction of the CGA address.  In this case the nonce is
      copied to the Nonce field.  Otherwise, the Nonce_Len field is set
      to zero and the Nonce field is omitted.

   o  The Timestamp field is set as described in Section 7.1.4.

   o  The packet, in the form defined for AH's coverage, is signed using
      the private key in the security association, and the resulting
      PCKS #1 signature is put to the Digital Signature field.

   o  Additionally, if the use of CGA has been specified for the
      security association we require that the source address of the
      packet has been constructed as specified in Section 5.  A sending
      node uses as inputs the sender's public key, nonce, the subnet
      prefix from the Target Address, and the Target Link Layer Address.
      The Target Address (including the subnet prefix) is put to the
      Source Address field in the IPv6 header, and the public key and
      the nonce are put to the Authentication Data field in the AH
      header.


7.1.6 Processing Rules for Receivers

   A packet received on a security association employing AH_RSA_Sig
   transform MUST be checked as follows:

   o  Next Header and Payload Len fields are valid as specified in RFC
      2402.

   o  The SPI field is equal to the value defined in Section 7.1.1.

   o  The sum of the PK_Len, Nonce_Len, and LLA_Len fields does not
      exceed the length of the Authentication Data field.

   o  The Nonce_Len field is non-zero if the use of CGA has been
      specified in the security association.

   o  The Timestamp field is verified as described in Section 7.1.4.




Arkko, et al.           Expires August 25, 2003                [Page 29]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   o  If the use of CGA has been specified in the security association,
      we additionally require that A node receiving an Neighbor or
      Router Advertisement message with CGA protection first checks the
      CGA address in the Target Address field by generating the address
      using the algorithm described in Section 5.3.  The inputs for the
      algorithm are the sender's public key and nonce, included in the
      AH packet as described in Section 7.1.2, the subnet prefix from
      the Target Address, the Target Link Layer Address, which MUST be
      included in a Target Link Layer Address option, and the security
      parameter from the rightmost two bits of the Target Address.  If
      the interface identifier checks, the recipient proceeds with the
      cryptographically more time consuming check of the AH signature.

      Note that a receiver which does not support CGA or has not
      specified its use in its security associations can still verify
      packets using trusted roots, even if CGA had been used on a
      packet.  The CGA property of the address is simply left untested.

   o  The Public key and Digital Signature fields can be correctly
      decoded, and the the Digital Signature verifies as specified in
      the previous section.

   o  If the use of a trusted root has been configured for the security
      association, a valid authorization delegation chain is known
      between the receiver's trusted root and the sender's public key.

      Note that the receiver may verify just the CGA property of a
      packet, even if the sender has used a trusted root as well.

   Packets that do not pass all the above tests MUST be silently
   discarded.

7.2 Other IPsec Extensions

7.2.1 Destination Agnostic Security Associations

   In order to allow the same security association to be used when the
   the node sends packets to different peers using the same addresses, a
   change must be provided to the RFC 2401 rules on how security
   associations are identified.  This change is particularly important,
   for instance, when routers use the same keys and security association
   to send Router Advertisements for up to number of prefixes x 2^64
   hosts on an interface.

   The change is mandatory for all nodes that support the AH_RSA_Sig
   transform.  Security associations that use the SPI value specified in
   Section 7.1.1 MUST be identified solely by the SPI and protocol
   numbers, not by the destination IP address.



Arkko, et al.           Expires August 25, 2003                [Page 30]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


7.2.2 ICMP Type Specific Selectors

   In order to allow finer granularity of protection for various ICMPv6
   messages, it is necessary to extend the security policy database and
   security association selectors with the capability to distinguish
   between different messages.

   All nodes that support the AH_RSA_Sig transform MUST be capable of
   using ICMP and ICMPv6 Type field as a selector.










































Arkko, et al.           Expires August 25, 2003                [Page 31]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


8. Securing Neighbor Discovery with SEND

   This section describes how to use IPsec and the mechanisms from
   Section 5, Section 6, Section 7 in order to provide security for
   Neighbor Discovery.

8.1 Using IPsec to Secure Neighbor Advertisement Messages

   All Neighbor Solicitation messages SHOULD be sent without protection.

   All Neighbor Advertisement messages MUST be protected with IPsec,
   using the AH_RSA_Sig transform.  The protection can be based on CGA
   addresses, node certificates and trusted roots, or both as specified
   in the security association.

   All nodes MUST have the necessary key pairs, and as applicable,
   certificates and CGA parameters associated with their relationship to
   trusted root or to an address.

   Hosts that use stateless address autoconfiguration MUST generate new
   CGA addresses as specified in Section 5 for each new
   autoconfiguration run.

   It is outside the scope of this specification to describe trusted
   roots and address autoconfiguration (stateful or stateless) with
   dynamically changing addresses works.  It is also outside the scope
   of this specification to describe how stateful address
   autoconfiguration works with the CGA method.

   Hosts MAY use Authorization Delegation Discovery to learn the
   certificate chain of their default router or peer host.

8.2 Security Policy and SA Database Configuration

   This section gives a description for the security policy and security
   associations database entries, under which the outbound and inbound
   Neighbor Advertisement messages can be protected.

   The following table summarizes the inbound security policy data base
   along with the inbound security associations:











Arkko, et al.           Expires August 25, 2003                [Page 32]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   Policy entries:

    *------------------------------------------------------------------*
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    *------------------------------------------------------------------*
    |    ICMPv6: NS    |       *      |         *        |     pass    |
    *------------------------------------------------------------------*
    |    ICMPv6: NA    |       *      |       own        |  SA = NA_In |
    *------------------------------------------------------------------*
    |    ICMPv6: NA    |       *      |   all-nodes MC   |  SA = NA_In |
    *------------------------------------------------------------------*

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    NA_In   |   Inbound   | TBD (fixed) |   AH  |    AH_RSA_Sig   |
    |            |             |             |       |   CGA = yes/no  |
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+


   The following table summarizes outbound security policy database:


   Policy entries:

    *------------------------------------------------------------------*
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    *------------------------------------------------------------------*
    |    ICMPv6: NS    |       *      |         *        |     pass    |
    *------------------------------------------------------------------*
    |    ICMPv6: NA    |      own     |         *        | SA = NA_Out |
    *------------------------------------------------------------------*

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    NA_Out  |  Outbound   | TBD (fixed) |   AH  |    AH_RSA_Sig   |
    |            |             |             |       | key pair = ...  |
    |            |             |             |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+




Arkko, et al.           Expires August 25, 2003                [Page 33]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


9. Securing Router Discovery with SEND

   This section describes how to use IPsec and the mechanisms from
   Section 5, Section 6, Section 7 in order to provide security for
   Router Discovery.

9.1 Using IPsec to Secure Router Advertisement Messages

   All Router Solicitation messages SHOULD be sent without protection.

   All Router Advertisement messages MUST be protected with IPsec, using
   the AH_RSA_Sig transform.  The protection can be based on CGA
   addresses, node certificates and trusted roots, or both as specified
   in the security association.

   All routers MUST have the necessary key pairs, and as applicable,
   certificates and CGA parameters associated with their relationship to
   trusted root or to an address.  All hosts MUST have the certificate
   of a trusted root.

   Hosts SHOULD use Authorization Delegation Discovery to learn the
   certificate chain of their default router or peer host.

9.2 Using IPsec to Secure Redirect Messages

   All Redirect messages MUST be protected with IPsec, using the
   AH_RSA_Sig transform.  The protection can be based on CGA addresses,
   node certificates and trusted roots, or both as specified in the
   security association.

   If only CGA-based security associations are used, hosts MUST follow
   the rules defined below when receiving Redirect messages:

   1.  The Redirect message MUST be protected as discussed above.

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

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







Arkko, et al.           Expires August 25, 2003                [Page 34]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


9.3 Security Policy and SA Database Configuration

   This section gives a description for the security policy and security
   associations database entries, under which the outbound and inbound
   Router Advertisement and Redirect messages can be protected.

   The following table summarizes the inbound security policy data base
   along with the inbound security associations:


   Policy entries:

    *------------------------------------------------------------------*
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    *------------------------------------------------------------------*
    |    ICMPv6: RS    |       *      |         *        |     pass    |
    *------------------------------------------------------------------*
    |    ICMPv6: RA    |       *      |       own        |  SA = RA_In |
    *------------------------------------------------------------------*
    |    ICMPv6: RA    |       *      |   all-nodes MC   |  SA = RA_In |
    *------------------------------------------------------------------*
    | ICMPv6: REDIRECT |       *      |       own        |  SA = RE_In |
    *------------------------------------------------------------------*

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    RA_In   |   Inbound   | TBD (fixed) |   AH  |    AH_RSA_Sig   |
    |            |             |             |       |   CGA = yes/no  |
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RE_In   |   Inbound   | TBD (fixed) |   AH  |    AH_RSA_Sig   |
    |            |             |             |       |   CGA = yes/no  |
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+


   The following table summarizes outbound security policy database.
   The Router Advertisement and Redirect entries are only present in
   routers.









Arkko, et al.           Expires August 25, 2003                [Page 35]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   Policy entries:

    *------------------------------------------------------------------*
    |    Proto: Type   |    Source    |    Destination   |  Treatment  |
    *------------------------------------------------------------------*
    |    ICMPv6: RS    |       *      |         *        |     pass    |
    *------------------------------------------------------------------*
    |    ICMPv6: RA    |      own     |         *        | SA = RA_Out |
    *------------------------------------------------------------------*
    | ICMPv6: REDIRECT |      own     |         *        | SA = RE_Out |
    *------------------------------------------------------------------*

   Security associations:

    +------------------------------------------------------------------+
    |    Name    |  Direction  |     SPI     | Proto |    Transform    |
    +------------------------------------------------------------------+
    |    RA_Out  |  Outbound   | TBD (fixed) |   AH  |    AH_RSA_Sig   |
    |            |             |             |       | key pair = ...  |
    |            |             |             |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+
    |    RE_Out  |  Outbound   | TBD (fixed) |   AH  |    AH_RSA_Sig   |
    |            |             |             |       | key pair = ...  |
    |            |             |             |       | CGA = yes/no    |
    |            |             |             |       | CGA params = ...|
    |            |             |             |       | root = ... (opt)|
    +------------------------------------------------------------------+






















Arkko, et al.           Expires August 25, 2003                [Page 36]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


10. Operational Considerations

   During the transition to secure links or as a policy consideration,
   network operators may want to run a particular link with a mixture of
   secure and insecure nodes.  In such a case, the link is required to
   operate as two separate logical links, and packets between a secure
   and insecure node always go through the router.

   Routers configured for SEND advertise two sets of globally routable
   prefixes: one set for SEND nodes and one set for nodes that implement
   insecure Neighbor Discovery.  The insecure nodes will ignore the
   advertisements sent using SEND, as the original Neighbor Discovery
   specifications require silently discarding packets if they contain an
   AH header that they can not verify.

   The following considerations apply to hosts:

   o  Hosts configured for SEND MUST use SEND for all of their
      addresses, including link local addresses.

   o  Hosts configured for SEND MUST validate all Router Advertisements
      with the protocol described in Section 8.  Note that this includes
      discarding advertisements received without a valid IPsec AH header
      and CGA address, thus making insecure prefixes invisible to them.

   o  Hosts configured for SEND MUST secure and validate all Neighbor
      Advertisements with the protocol described in Section 8.  Note
      that this includes discarding advertisements received without a
      valid IPsec AH header and CGA address.

   The following considerations apply to routers:

   o  Routers MUST send two sets of Router Advertisements.  The
      advertisements containing the secure prefixes MUST be secured with
      the protocol described in Section 9.  The advertisements
      containing the insecure prefixes MUST be sent without security.

   o  Routers MUST assign different addresses for their secure and
      insecure communications, including their link-local addresses.
      Secure Router and Neighbor Advertisements MUST use a source
      address that satisfies the security properties outlined in Section
      9.  Unless this address is link-local, it MUST belong to one of
      the advertised secure prefixes.  Similarly, source addresses for
      insecure advertisements MUST belong to one of the advertised
      insecure prefixes, unless the address is link-local.

   o  Routers MUST refrain from sending Redirects to a SEND-secured node
      with the Destination Address field set to an address for an



Arkko, et al.           Expires August 25, 2003                [Page 37]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


      insecure node.  Similarly, routers MUST refrain from sending
      Redirects to a insecure node with the Destination Address field
      set to an address for a SEND-secured node

   The above rules require secure nodes to ignore all insecure Neighbor
   and Router Discovery messages, and all insecure nodes to ignore all
   SEND-secured messages.  This implies that the secure and insecure
   nodes will not be able to discover each other, or even realize that
   the other prefixes are on-link.  Thus, these hosts will request the
   router to route packets destined to the a host in the other group.
   The rules regarding Redirect messages above have been provided to
   ensure that the router performs its routing task and does not
   instruct the hosts to communicate directly.

   One effect of this is that secure hosts can not communicate with
   insecure hosts using link-local addresses, and vice versa.

   The security policy or security association database entries are
   needed for insecure nodes as far as Neighbor Discovery is concerned.
   SEND-secured nodes have the usual entries required by SEND.































Arkko, et al.           Expires August 25, 2003                [Page 38]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


11. Performance Considerations

   The computations related to AH_RSA_Sig transform are substantially
   more expensive than those with traditional symmetric transforms.
   While computational power is increasing, it appears still impractical
   to use asymmetric transforms for a significant amount packets.

   In the application for which AH_RSA_Sig has been designed, however,
   hosts typically have the need to perform only a few operations as
   they enter a link, and a few operations as they find a new on-link
   peer to communicate with.

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

   Signatures related to the use of the AH_RSA_Sig transform MAY be
   precomputed for Multicast Neighbor and Router Advertisements.
   Typically, solicited advertisements are sent to the unicast address
   from which the solicitation was sent.  Given that the IPv6 header is
   covered by the AH integrity protection, it is typically not possible
   to precompute solicited advertisements.
























Arkko, et al.           Expires August 25, 2003                [Page 39]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


12. Security Considerations

12.1 Achieved Security Properties

   The CGA method assures that the received messages are coming from the
   owner of the address.  However, this method does not eliminate all
   security vulnerabilities related to the ND functions.  CGA prevents
   spoofed answers to DAD queries.  An attacker may still be able to
   prevent valid responses or requests from reaching the intended
   recipient.  As a result both participants are forced to believe that
   no address collision exists, when there in fact is.

   Within Address Resolution and NUD functions CGA can be used to
   prevent spoofed responses.  However, it is still possible to prevent
   the Address Resolution and NUD from completing for a given address.
   For the NUD, this means that a node is claimed to be unreachable,
   when it really is not.

   Hosts can use CGA to show that the Redirect messages come from their
   current router.  Still, we cannot say anything about the other router
   mentioned in the Redirect message.  When trusted roots are used to
   certify routers, this is, however, not an issue.

   Within the Router Discovery functionality the CGA method ensures that
   we are communicating with the same router all the time, and prevents
   spoofing of the link-layer address of the router.  But it does not
   help to verify that the router is connected to the Internet or that
   it is authorized to advertise a specific route prefix.  A proper
   verification of these properties will not be possible without
   involving a trusted root.

   Protection of Router (or Neighbor) Discovery with trusted roots
   ensures that the given router (or neighbor) belongs to the set of
   trusted entities.  It does not provide assurance that the given
   router is not spoofing another legitimate router (but see Section
   14).

12.2 Attacks against SEND Itself

   The CGA addresses have a 60-bit hash.  This length is in within the
   range of an feasible attack in the future.  The following mechanisms
   have been built in this draft to counteract such attacks:

      The inclusion of the routing prefix prevents precomputation
      attacks.

      The Sec parameter helps the SEND algorithm to scale as Moore's law
      increases processing power.  Additional amount of computational



Arkko, et al.           Expires August 25, 2003                [Page 40]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


      effort is involved in for both attackers and owners of an address;
      verifiers of a message still need to spend the same amount of
      effort.

   Some Denial-of-Service attacks against ND 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 the SEND in-operational.

   Security associations based on the use of asymmetric cryptography can
   be vulnerable to Denial-of-Service attacks, particularly when the
   attacker can guess the SPIs and destination addresses used in the
   security associations.  In SEND this is easy, as both the SPIs and
   the addresses (such as all nodes multicast address) are standardized.
   Due to the use of multicast, one packet sent by the attacker will be
   processed by multiple receivers.

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

   When trusted roots and certificates are used in SEND, the defenses
   are not quite as effective.  Implementations SHOULD track how much
   resources are being devoted to the processing of packets received
   with the AH_RSA_Sig transform, and start selectively dropping packets
   if too much resources are spent.  Implementations MAY also start
   first dropping packets that which 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
   request a large number of delegation chains to be discovered for
   different roots.  Routers SHOULD defend against such attacks by
   caching discovered information (including negative responses) and by
   limiting the number of different discovery processes they engage in.

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






Arkko, et al.           Expires August 25, 2003                [Page 41]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


13. IANA Considerations

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

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

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

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

   o  The Trusted Root option, described in Section 6.3.

   o  The Certificate option, described in Section 6.4.

   This document defines a new reserved SPI number in the Reserved SPI
   range 1-255 [3].

   This document defines a new IPSEC AH Transform Identifier for the
   IPsec DOI [4].  This identifier represents the AH_RSA_Sig transform
   from Section 7.1.

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

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

















Arkko, et al.           Expires August 25, 2003                [Page 42]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


14. Conclusions and Remaining Work

   This draft documents ongoing work.  The following areas are still
   being studied:

   o  Protection of solicitations.  There are no provisions yet for the
      protection of Address Resolution which takes place as a
      side-effect of Neighbor Solicitations.  Similarly, the effects of
      Duplicate Address Detection probes on other nodes currently doing
      DAD have not been covered, as they too are carried by
      solicitations.

   o  CGA detailed format and calculation formulas: The CGA formulas
      used in this document are from an early approach to the control of
      the security level in an environment with a constrained number of
      output bits.  An advanced version of this approach will be
      published soon and appears interesting [21].

   o  Transition issues: Security policy and security association
      database entry examples are needed before the correctness of the
      approach outlined in Section 10 can be estimated.  Also, the
      ability of hosts to simultaneously use SEND and insecure ND
      without a router.  The ability of a non-SEND router to participate
      on a link with SEND-capable hosts and other routers.

   o  The security considerations, achieved security properties, and the
      treatment of Denial-of-Service attacks on the SEND mechanisms
      themselves need further work.

   o  The formats used to carry trusted root references, certificates,
      and public keys may change.

   o  It is unclear at this time how, and if, router and neighbor
      protection based on trusted roots relates to addresses and
      prefixes.  Is a router only certified to use a particular IP
      address, or to provide a particular prefix to the link?

   o  It is unclear whether MLD [16] protection is needed or not.













Arkko, et al.           Expires August 25, 2003                [Page 43]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


Normative References

   [1]   Hinden, R. and S. Deering, "IP Version 6 Addressing
         Architecture", RFC 2373, July 1998.

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

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

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

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

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

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

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

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

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

   [11]  RSA Laboratories, "RSA Encryption Standard, Version 1.5", PKCS
         1, November 1993.

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











Arkko, et al.           Expires August 25, 2003                [Page 44]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


Informative References

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

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

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

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

   [17]  Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies",
         draft-arkko-icmpv6-ike-effects-01 (work in progress), June
         2002.

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

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

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

   [21]  Aura, T., "Cryptographically Generated Addresses (CGA)",
         draft-aura-cga-00.txt (work in progress), February 2003.

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

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

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

   [25]  Montenegro, G. and C. Castelluccia, "Statistically Unique and
         Cryptographically Verifiable (SUCV) Identifiers and Addresses",



Arkko, et al.           Expires August 25, 2003                [Page 45]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


         NDSS, February 2002.


Authors' Addresses

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   EMail: jari.arkko@ericsson.com


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

   EMail: kempf@docomolabs-usa.com


   Bill Sommerfeld
   SUN Microsystems
   USA

   EMail: sommerfeld@east.sun.com


   Brian Zill
   Microsoft
   USA

   EMail: bzill@microsoft.com

















Arkko, et al.           Expires August 25, 2003                [Page 46]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


Appendix A. Contributors

   Steven Bellovin was the first to suggest the use of IPsec in this
   manner for the protection of Neighbor Discovery.  Pekka Nikander and
   Vesa-Matti Mantyla were co-authors of an unpublished draft from which
   many of the details of this document have been inherited.  The
   theoretical foundations of protecting Neighbor Discovery were laid
   out in a paper [24] where Tuomas Aura, Vesa-Matti Mantyla, Pekka
   Nikander, and Mike Roe were co-authors.










































Arkko, et al.           Expires August 25, 2003                [Page 47]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


Appendix B. Acknowledgements

   The authors would like to thank Erik Nordmark and Gabriel Montenegro
   for interesting discussions in this problem space.















































Arkko, et al.           Expires August 25, 2003                [Page 48]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


Appendix C. IPR Considerations

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














































Arkko, et al.           Expires August 25, 2003                [Page 49]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


Intellectual Property Statement

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

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


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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.

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



Arkko, et al.           Expires August 25, 2003                [Page 50]


Internet-Draft      SEcure Neighbor Discovery (SEND)       February 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

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











































Arkko, et al.           Expires August 25, 2003                [Page 51]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/