tech-invite   World Map
3GPP     Specs     Glossaries     UICC       T+       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 3971

 Errata 
Proposed STD
Pages: 56
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SEND

SEcure Neighbor Discovery (SEND)

Part 1 of 2, p. 1 to 23
None       Next RFC Part

Updated by:    6494    6495    6980


Top       ToC       Page 1 
Network Working Group                                      J. Arkko, Ed.
Request for Comments: 3971                                      Ericsson
Category: Standards Track                                       J. Kempf
                                          DoCoMo Communications Labs USA
                                                                 B. Zill
                                                               Microsoft
                                                             P. Nikander
                                                                Ericsson
                                                              March 2005


                    SEcure Neighbor Discovery (SEND)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover
   other nodes on the link, to determine their link-layer addresses to
   find routers, and to maintain reachability information about the
   paths to active neighbors.  If not secured, NDP is vulnerable to
   various attacks.  This document specifies security mechanisms for
   NDP.  Unlike those in the original NDP specifications, these
   mechanisms do not use IPsec.

Top       Page 2 
Table of Contents

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

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

1.  Introduction

   IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [4]
   and 2462 [5].  Nodes on the same link use NDP to discover each
   other's presence and link-layer addresses, to find routers, and to
   maintain reachability information about the paths to active
   neighbors.  NDP is used by both hosts and routers.  Its functions
   include Neighbor Discovery (ND), Router Discovery (RD), Address
   Autoconfiguration, Address Resolution, Neighbor Unreachability
   Detection (NUD), Duplicate Address Detection (DAD), and Redirection.

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

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

   This document is organized as follows.  Sections 2 and 3 define some
   terminology and present a brief review of NDP, respectively.  Section
   4 describes the overall approach to securing NDP.  This approach
   involves the use of new NDP options to carry public key - based
   signatures.  A zero-configuration mechanism is used for showing

Top      ToC       Page 4 
   address ownership on individual nodes; routers are certified by a
   trust anchor [7].  The formats, procedures, and cryptographic
   mechanisms for the zero-configuration mechanism are described in a
   related specification [11].

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

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

   The use of identity certificates provisioned on end hosts for
   authorizing address use is out of the scope for this document, as is
   the security of NDP when the entity defending an address is not the
   same as the entity claiming that address (also known as "proxy ND").
   These are extensions of SEND that may be treated in separate
   documents, should the need arise.

1.1.  Specification of Requirements

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

2.  Terms

   Authorization Delegation Discovery (ADD)

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

   Certificate Revocation List (CRL)

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

   Certification Path Advertisement (CPA)

      The advertisement message used in the ADD process.

Top      ToC       Page 5 
   Certification Path Solicitation (CPS)

      The solicitation message used in the ADD process.

   Cryptographically Generated Address (CGA)

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

   Distinguished Encoding Rules (DER)

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

   Duplicate Address Detection (DAD)

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

   Fully Qualified Domain Name (FQDN)

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

   Internationalized Domain Name (IDN)

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

   Neighbor Discovery (ND)

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

   Neighbor Discovery Protocol (NDP)

      The IPv6 Neighbor Discovery Protocol [7, 8].

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

   Neighbor Unreachability Detection (NUD)

      A mechanism used for tracking the reachability of neighbors.

Top      ToC       Page 6 
   Non-SEND node

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

   Nonce

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

   Router Authorization Certificate

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

   SEND node

      An IPv6 node that implements this specification.

   Router Discovery (RD)

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

   Trust Anchor

      Hosts are configured with a set of trust anchors to protect Router
      Discovery.  A trust anchor is an entity that the host trusts to
      authorize routers to act as routers.  A trust anchor configuration
      consists of a public key and some associated parameters (see
      Section 6.5 for a detailed explanation of these parameters).

3.  Neighbor and Router Discovery Overview

   The Neighbor Discovery Protocol has several functions.  Many of these
   are overloaded on a few central message types, such as the ICMPv6
   Neighbor Advertisement message.  In this section, we review some of
   these tasks and their effects in order to better understand how the
   messages should be treated.  This section is not normative, and if
   this section and the original Neighbor Discovery RFCs are in
   conflict, the original RFCs, as updated, take precedence.

Top      ToC       Page 7 
   The main functions of NDP are as follows:

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

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

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

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

   o  The Address Resolution function allows a node on the link to
      resolve another node's IPv6 address to the corresponding link-
      layer address.  Address Resolution is defined in Section 7.2 of
      RFC 2461 [4], and it is used for hosts and routers alike.  Again,
      no higher level traffic can proceed until the sender knows the
      link layer address of the destination node or the next hop router.
      Note that the source link layer address on link layer frames is
      not checked against the information learned through Address
      Resolution.  This allows for an easier addition of network
      elements such as bridges and proxies and eases the stack
      implementation requirements, as less information has to be passed
      from layer to layer.

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

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

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

4.  Secure Neighbor Discovery Overview

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

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

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

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

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

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

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

      Note: RSA is mandated because having multiple signature algorithms
      would break compatibility between implementations or increase
      implementation complexity by forcing the implementation of
      multiple algorithms and the mechanism to select among them.  A
      second signature algorithm is only necessary as a recovery
      mechanism, in case a flaw is found in RSA.  If this happens, a
      stronger signature algorithm can be selected, and SEND can be
      revised.  The relationship between the new algorithm and the RSA-
      based SEND described in this document would be similar to that
      between the RSA-based SEND and Neighbor Discovery without SEND.
      Information signed with the stronger algorithm has precedence over
      that signed with RSA, in the same way that RSA-signed information
      now takes precedence over unsigned information.  Implementations
      of the current and revised specs would still be compatible.

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

5.  Neighbor Discovery Protocol Options

   The options described in this section MUST be supported.

Top      ToC       Page 10 
5.1.  CGA Option

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

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

   Type

      11

   Length

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

   Pad Length

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

   Reserved

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

Top      ToC       Page 11 
   CGA Parameters

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

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

   Padding

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

5.1.1.  Processing Rules for Senders

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

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

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

   Redirect

      The address MUST be the source address of the message.

   Neighbor Solicitation

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

Top      ToC       Page 12 
   Neighbor Advertisement

      The address MUST be the source address of the message.

   Router Solicitation

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

   Router Advertisement

      The address MUST be the source address of the message.

5.1.2.  Processing Rules for Receivers

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

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

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

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

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

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

Top      ToC       Page 13 
5.1.3.  Configuration

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

   minbits

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

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

   CGA parameters

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

Top      ToC       Page 14 
5.2.  RSA Signature Option

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

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

   Type

      12

   Length

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

   Reserved

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

Top      ToC       Page 15 
   Key Hash

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

   Digital Signature

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

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

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

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

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

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

      6. All NDP options preceding the RSA Signature option.

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

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

   Padding

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

Top      ToC       Page 16 
5.2.1.  Processing Rules for Senders

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

   A node sending a message with the RSA Signature option MUST construct
   the message as follows:

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

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

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

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

5.2.2.  Processing Rules for Receivers

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

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

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

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

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

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

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

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

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

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

5.2.3.  Configuration

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

   authorization method

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

         trust anchor

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

         CGA

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

Top      ToC       Page 18 
         trust anchor and CGA

            Both the trust anchor and the CGA verification is required.

         trust anchor or CGA

            Either the trust anchor or the CGA verification is required.

   anchor

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

   All nodes that support sending RSA Signature options MUST record the
   following configuration information:

      keypair

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

      CGA flag

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

5.2.4.  Performance Considerations

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

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

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

5.3.  Timestamp and Nonce Options

5.3.1.  Timestamp Option

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                          Timestamp                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      13

   Length

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

   Reserved

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

Top      ToC       Page 20 
   Timestamp

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

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

5.3.2.  Nonce Option

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

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

   Type

      14

   Length

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

   Nonce

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

Top      ToC       Page 21 
5.3.3.  Processing Rules for Senders

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

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

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

5.3.4.  Processing Rules for Receivers

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

   In addition, the following rules apply in all cases:

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

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

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

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

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

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

5.3.4.1.  Processing Solicited Advertisements

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

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

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

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

5.3.4.2.  Processing All Other Messages

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

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

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

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

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

   Receivers SHOULD then check the Timestamp field as follows:

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

         -Delta < (RDnew - TSnew) < +Delta

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

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

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

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

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

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

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


Next RFC Part