Network Working Group                                       Jari Arkko
INTERNET-DRAFT                                          Pekka Nikander
Category: Informational                             Vesa-Matti Mantyla
<draft-arkko-send-cga-00.txt>                                 Ericsson
                                                             June 2002




    Securing IPv6 Neighbor Discovery Using Cryptographically Generated
                            Addresses (CGAs)



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 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 inapproporiate 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/1id-abstracts.html

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


  The distribution of this memo is unlimited. It is filed as <draft-
  arkko-send-cga-00.txt>, and expires December 24, 2002. Please send
  comments to the authors.


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. The original ND specifications called for the
  use of IPsec for protecting the ND messages. However, in this
  particular application the use of IPsec may not always be feasible,
  mainly due to difficulties in key management. If not secured, ND
  protocol is vulnerable to various attacks. This document specifies a
  lightweight security solution for ND that does not rely on pre-
  configuration or trusted third parties. The presented solution uses
  Cryptographically Generated Addresses.

Conventions used in this document

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in this
  document are to be interpreted as described in [RFC 2119].

Arkko et al.                 Informational                     [Page 1]


Internet Draft            Secure ND with CGAs                June, 2002


Table of contents

  1.  Introduction...................................................2
  2.  Definitions....................................................3
  3.  Neighbor Discovery.............................................3
  4.  Approaches for Securing Neighbor Discovery.....................4
  5.  Cryptogaphically Generated Addresses...........................6
      5.1. Generation................................................6
      5.2. Signatures................................................7
      5.3. Verification .............................................7
      5.4. Algorithms................................................8
  6.  Securing Neighbor Discovery with CGA...........................8
      6.1. Duplicate Address Detection...............................8
      6.2. Address Resolution........................................9
      6.3. Neighbor Unreachability Detection.........................9
  7.  Securing Router Discovery with CGA.............................9
      7.1. Router Discovery..........................................9
      7.2. Redirect.................................................10
  8.  Option Formats................................................11
      8.1. Public Key Option........................................11
      8.2. Signature Option.........................................12
  9.  Security Considerations.......................................12
  10. Acknowledgments...............................................13
  11. References....................................................13
      11.1. Normative References....................................13
      11.2. Non-normative References................................13
  12. IPR Considerations............................................14
  13. Authors' Address..............................................14


1. Introduction

  IPv6 defines the Neighbor Discovery (ND) protocol in RFC 2461 [ND98].
  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.

  Section 4 gives a description of different approaches for securing
  the ND protocol. This shows that the specified IPsec method isn't
  always applicable. In Sections 6 to 8 we present a new, lightweight
  solution for ND security. Our approach is based on the use of
  Cryptographically Generated Addresses (CGAs) [CAM01].

  The CGA method provides a proof of address ownership, i.e., it
  provides assurance that the node we are talking to is indeed the one
  that came up with the very address. In our solution, there is no need
  for an external key management infrastructure. All the used keys can
  be self-generated, and can be presented without external credentials.
  Section 5 briefly introduces the CGA method.



Arkko et al.                  Informational                     [Page 2]


Internet Draft             Secure ND with CGAs                June, 2002

  Our requirements call for secure ND signaling to be possible both in
  private networks as well as in public access networks. In the public
  access networks we can't trust all parties to behave in an
  appropriate manner.

  At the moment this specification considers only the case of networks
  that are fully protected with our secure ND approach. That is, we do
  not yet deal with the problem of securing some ND messages with our
  approach while allow some other messages to be secured with the
  traditional IPsec approach or even be left unsecured.

2. Definitions

  Cryptographically Generated Addresses (CGAs) - A technique 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 [CAM01]. Also called SUCD Identities in [SUCV].

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

3. Neighbor Discovery

  The main functions of IPv6 Neighbor Discovery are as follows:

  - Neighbor Unreachability Detection (NUD) is used for tracking the
    reachability of neighbors, both local destinations and routers
    [ND98, Section 7.3].

  - Duplicate Address Detection (DAD) is used for preventing address
    collisions [ND98, AUTOCONF98]. 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.

  - Address Resolution is similar to IPv4 ARP [ARP82]. The Address
    Resolution function resolves a node's IPv6 address to the
    corresponding link-layer address for nodes on the link [ND98,
    Section 7.2]. Address Resolution is used for hosts and routers
    alike.

  - Address Autoconfiguration is used for automatically assigning
    addresses to a host [AUTOCONF98]. 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, provides
    additional Autoconfiguration features.

  - The Redirection function is used for automatically redirecting
    hosts to an alternate router [ND98, Section 8]. It is similar to
    the ICMPv4 Redirect message [POS81].



Arkko et al.                  Informational                     [Page 3]


Internet Draft             Secure ND with CGAs                June, 2002

  - The Router Discovery function allows IPv6 hosts to discover the
    local routers on an attached link [ND98, Section 6].

  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:

         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:

  - Router Discovery uses the RS and RA messages.
  - Duplicate Address Detection uses the NS and NA messages.
  - Address Autoconfiguration uses the NS, NA, RS, and RA messages.
  - Address Resolution uses the NS and NA messages.
  - Neighbor Unreachability Detection uses the NS and NA messages.
  - Redirect uses the Redirect message.

  All functions but Address Auto-configuration are explained in RFC
  2461. The Address Auto-configuration is presented in RFC 2462.

  In Section 8 we define two new ND message options that are used in
  our security solution.

4. Approaches for Securing Neighbor Discovery

  When ND is not secured, attackers can cause, for instance, the
  following types of problems [Ark01, Ark02]:

  - Making hosts adopt bogus prefixes. This leads to Denial-of-
    Service.
  - Making hosts adopt bogus default routers. This leads to Denial-of-
    Service and can also be used in an attempt to place the attacker as
    a Man-in-the-Middle for all communications.


Arkko et al.                  Informational                     [Page 4]


Internet Draft             Secure ND with CGAs                June, 2002

  - Sending spoofed answers to DAD queries in an attempt to prevent a
    host from acquiring any address.
  - Sending spoofed Address Resolution messages in an attempt to cause
    Denial-of-Service or to place the attacker as a Man-in-the-Middle
    between the neighbors.
  - Sending spoofed NUD messages. This can be used to make the
    neighbor believe the node is reachable when it is not.
  - Sending spoofed Redirect messages, again in an attempt to cause
    Denial-of-Service or to place the attacker as a Man-in-the-Middle.

  The ND protocol ignores packets received from off-link nodes by
  verifying that the Hop Limit field contains the value 255. Since
  every forwarding router reduces this value by one, an ND packet
  containing the Hop Limit value of 255 must originate from a
  neighboring IPv6 node. However, this does not protect against
  malicious neighbors.

  It is possible to authenticate the ND protocol packet exchanges using
  the IPSec Authentication Header, if a suitable SA exists. This is the
  approach specified in the original specification [ND98]. However,
  three different types of problems exist with this approach:

  - Running an automatic keying protocol such as IKE would involve
    sending IP traffic, which may be impossible in the initial stages
    of some the ND procedures. For instance, we can't send IKE UDP
    packets before we have an address. Also, the node needs to discover
    the link layer address of the neighbor. This is a chicken-and-egg
    problem, since getting an address or finding the link layer address
    of the peer would require running ND, which in turn would require
    the security associations to be already in place.

  - Manual SAs can be configured, but as [Ark01] points out this may
    lead to a large number of SAs. The definition of IPsec requires a
    different SA for every IP address that is used as a destination.

  - According to RFC 2461 [ND98], the ND protocol "provides no
    mechanism to determine, which neighbors are authorized to send a
    particular type of message", e.g a Router Advertisement. The
    current set of IPsec policy selectors do not allow us to define
    which nodes are allowed to send which particular ND messages.

  - IPsec in general can prove that the peers are among the intended
    users of the link. However, we also need to authorize the contents
    of the messages. For instance, even if a particular node is
    authorized to send Neighbor Advertisements, it is usually
    authorized to send them only on its own behalf. Manually configured
    SAs with security policy entries that limit the use of source
    address can in some cases handle this, but it isn't expected that
    trusted third parties and certificate infrastructures can keep up
    with the right IP address identities of all users at all times.


Arkko et al.                  Informational                     [Page 5]


Internet Draft             Secure ND with CGAs                June, 2002

  Due to the above, the use of IPsec in securing ND for public access
  networks is hard, and it isn't clear that attacks can be avoided even
  when IPsec is used.

  Various new approaches to securing ND have been designed. One of
  these approaches is the Address Based Keys method which is discussed
  in [ABK02].

5. Cryptographically Generated Addresses

  The purpose of the CGA method is to ensure that only the node that
  "owns" an address has the right to make statements about this
  address, e.g., for the purpose of address resolution.

  In the CGA method a node first generates a private-public key pair.
  The public key and some other parameters are used to generate the CGA
  address. The private key is used for signing signaling messages
  related to this address. The public key has to be distributed to the
  receiving node(s) for the signature verification to be possible. It
  isn't necessary to protect the transfer of the public key.

  The following text gives a more detailed description of the
  calculations the nodes have to perform when using the CGA.

5.1.     Generation

  An IPv6 address is composed of two parts:

     Address = Routing Prefix | Interface ID

  In the CGA scheme, the Route Prefix is derived in a usual manner,
  whereas the Interface ID of the node is created using the following
  procedure:

    1. Select the security parameter Sec = 0, 1 , 2, 3.

    2. Calculate

     Hash = HASH("CGA" | Sec | Routing Prefix | PK | Random),

  where

      HASH          A one-way hash algorithm.

      PK            The Public Key of the node.

      "CGA"         A three octet long string consisting of the ASCII
                    characters 'C', 'G', and 'A'.

      Sec           One octet security parameter that can be used to
                    tune the amount of work needed to create CGA
                    addresses. The rationale for Sec is discussed
                    more in depth in [Ark02].

      Routing Prefix
                    The 64 routing prefix.

      Random        A 64 bit long random number.

Arkko et al.                  Informational                     [Page 6]


Internet Draft             Secure ND with CGAs                June, 2002


    3. Select 64+20 x Sec rightmost bits of the hash output and compare
       the 20 x Sec leftmost bits to zero. If not zero, proceed to
       generate a new Random value and go back to Step 2.

    4. Concatenate the 64-bit Routing Prefix and the rightmost 64 bits
       of the Hash to obtain the Address.

    5. Set the group and the universal bits [ADD98] to 1 and the two
       rightmost bits to Sec.

    6. Perform Duplicate Address Detection. If collision is detected,
       proceed to generate a new Random value and return to Step 2.
       After three collisions, stop and report error.

  Note that the Sec parameter is included in both in the address and in
  the hash input. The indication to use CGA-based addresses is encoded
  by setting the group and universal bits to 1.

5.2.     Signatures

      SIG = SIGALG(HASH(Contents),SK),

  Where

      SIGALG       A public key signature algorithm.

    Contents     Some statement relating to the address in question.

      SK           Secret Key of the node.

  For ND messages, the Contents is formed from the following parts:

    1. The IPv6 header with the exception of the destination address
       field. (The purpose of omitting the destination address field is
       to avoid the CPU intensive signature generation when responding
       with the same message to different nodes.)
    2. The ICMPv6/ND message with the exception of the Signature ND
       option. (The rest of the IPv6 message, e.g. the IPv6 Payload
       length or the ICMPv6 Length field are not modified as a result
       of omitting this part.)

5.3.     Verification

  In order to verify that a given address has been formed using CGA,
  the receiver performs the following steps:

    1. Check that the group and the universal bits are 1. If not, the
       verification process fails.
    2. Retrieve the Routing Prefix from the highest 64 bits of the
       address, Sec from the lowest 2 bits of the address, and PK and
       Random from an option accompanying the ND message. If the
       necessary option is not present in the message, the verification
       process fails.
    3. Calculate the hash as defined in Section 5.1, set the group and
       universal bits, set the two lowest bits to Sec, and compare to
       the 64 lowest bits in the given address. If the values are not
       the same, the verification process fails.
    4. The process succeeds.

Arkko et al.                  Informational                     [Page 7]


Internet Draft             Secure ND with CGAs                June, 2002


  In order to verify a given statement about a particular address, the
  following process is used:

    1. Check that the address in the source field of the message has
       been formed using CGA, as explained above. If this fails, the
       verification process fails.
    2. Construct a Contents string as described in Section 5.2.
    3. Verify that the signature found in the Signature ND option has
       been produced using the private key corresponding to the public
       key found from the Public Key ND option. If this fails, the
       verification process fails.
    4. The process succeeds.

5.4.     Algorithms

  In this specification, the one-way hash algorithm used in CGA
  generation and signature calculation is the SHA1 algorithm [SHA1]. As
  the public key algorithm we use the RSA algorithm [RSA78].

6. Securing Neighbor Discovery

  The following text describes the procedures involved in securing ND
  with CGA. The method affects the transmitting and reception of
  Neighbor Advertisement (NA) messages.

  All nodes MUST acquire a CGA-based address on all interfaces they
  communicate according to the procedure presented in Section 5.1.

  All nodes follow the rules defined below when transmitting NA
  messages:

    1. The node MUST use a CGA-based address as the source address in
       the IPv6 header that carries the ND message.
    2. The node MUST attach the Public Key ND option to the NA message
       with the same parameters that were used in the construction of
       address in the source address field.
    3. The node MUST attach the Signature ND option to the NA message,
       and calculates this signature as specified in Section 5.2.

  All nodes follow the rules defined below when receiving NA messages:

    1. The NA message MUST have a Public Key and Signature ND options.
       Messages that do not have these options MUST be silently
       discarded.
    2. The receiver MUST verify the signature as described in Section
       5.3. Messages that fail this verification MUST be silently
       discarded.

  In the following we discuss how the above procedures affect the
  security of ND functions. We will also describe function-specific
  rules for the treatment of the NA messages.

6.1.     Duplicate Address Detection

  To the extent that CGA is secure, only the owner of the address can
  reply with a verifiable signature to a DAD query. This prevents other
  parties from sending replies in an attempt to prevent the host from
  getting an address.

Arkko et al.                  Informational                     [Page 8]


Internet Draft            Secure ND with CGAs                 June, 2002


  After receiving an NS message, in this case the DAD query, and
  detecting an address collision, a node uses the above procedures for
  sending the NA message.

  A node that receives the DAD reply, i.e. the NA message, uses the
  above procedures for receiving the NA message. If no valid replies
  are received, the tentative address is set to the VALID state. If the
  verification succeeded, the tentative address of the host is set to
  the DISABLED state.

6.2.     Address Resolution

  Here, the CGA method is used to assure that only the real owner of
  the address can produce a valid response.

  The rules for sending and receiving the NA message have again been
  described earlier. Note that the link-layer address ND option is also
  protected with the signature, preventing a Man-in-the-Middle from
  replacing another link-layer address to a legitimate reply.

6.3.     Neighbor Unreachability Detection

  Here the CGA method makes sure that attackers cannot claim that a
  node is reachable when it is not.

  For the procedure to process NA messages, see the beginning of
  Section 6. After a successful verification of the NA message, the
  node is marked as REACHABLE by the host.

7. Securing Router Discovery

  For Router Discovery, we use CGA to ensure that a given message comes
  from the claimed IP address. However, this does not offer any
  information about the ability and willingness of the router to act as
  a router, or that the advertised network prefixes are correct. We use
  a heuristic process to verify these properties.

  All routers MUST acquire a CGA-based address on all interfaces they
  communicate according to the procedure presented in Section 5.1. The
  router MUST use the same CGA-based address for both Neighbor
  Discovery and Router Discovery purposes.

7.1.     Router Discovery

  All routers follow the rules defined below when transmitting RA
  messages:

    1. The router MUST use a CGA-based address as the source address in
       the IPv6 header that carries the RA message.
    2. The router MUST attach the Public Key ND option to the RA
       message with the same parameters that were used in the
       construction of address in the source address field.
    3. The router MUST attach the Signature ND option to the RA
       message, and calculates this signature as specified in Section
       5.2.

  All hosts follow the rules defined below when receiving RA messages:


Arkko et al.                  Informational                     [Page 9]


Internet Draft             Secure ND with CGAs                June, 2002

    1. The RA message MUST have a Public Key and Signature ND options.
       Messages that do not have these options MUST be silently
       discarded.
    2. The receiver MUST verify the signature as described in Section
       5.3. Messages that fail this verification MUST be silently
       discarded.

  Still, even if the signature is verified correctly the host MUST
  check that the node claiming to be a router acts as a real router. We
  propose the following heuristic method:

  - Each entry in the default router list of the host is marked either
    as an UNTESTED, TESTED, or FAILED router. All new entries start
    from the UNTESTED state.

  - All communications from a host SHOULD use a router in the TESTED
    state, unless there are only UNTESTED ones available. FAILED
    routers SHOULD NOT be used for communications.

  - When communicating to a non-local destination through the
    designated router, the host SHOULD keep track of the upper layer
    forward progress, in the same manner as is used in avoiding NUD
    [ND98, Section 7.3]. If such forward progress is being made, the
    router in question SHOULD be marked as TESTED.

  - If no forward progress is being made, the host MAY attempt to send
    an ICMPv6 Echo request to verify that the router is working. Such
    requests MUST be addressed to a non-local destination known to the
    host, and MUST be rate-limited in the usual manner. A reply moves
    the router to the TESTED state.

  - If no forward progress is being made, and no replies have been
    seen, the router SHOULD be marked as FAILED.

  - Routers that have not been used by the host for a period of 120
    seconds SHOULD be marked as UNTESTED.

  - Routers in the FAILED state may be periodically tested with the
    ICMPv6 Echo request.

  A similar process SHOULD be applied to test the prefixes advertised
  by the router.

  Note that this heuristic process is inherently weak in the sense that
  a smart attacker could spoof response messages to unprotected
  communications or to the Echo requests. For this purpose it is
  strongly recommended that the hosts use only IPsec or TLS-protected
  communications as an indication of forward progress. This requires,
  however, that the hosts share a security association with another
  node in the Internet. Public web servers with TLS support and a
  certificate from a trusted root server are one possibility for
  arranging this security association in an easy manner.

7.2.     Redirect

  Routers use CGA to prove that the Redirect message comes from the
  right router.

  All routers follow the rules defined below when transmitting Redirect
  messages:

    1. The router MUST use a CGA-based address as the source address in
       the IPv6 header that carries the Redirect message.


Arkko et al.                  Informational                    [Page 10]


Internet Draft             Secure ND with CGAs                June, 2002

    2. The router MUST attach the Public Key ND option to the Redirect
       message with the same parameters that were used in the
       construction of address in the source address field.
    3. The router MUST attach the Signature ND option to the Redirect
       message, and calculates this signature as specified in Section
       5.2.

  All hosts follow the rules defined below when receiving Redirect
  messages:

    1. The Redirect message MUST have a Public Key and Signature ND
       options. Messages that do not have these options MUST be
       silently discarded.
    2. The receiver MUST verify the signature as described in Section
       5.3. Messages that fail this verification MUST be silently
       discarded.
    3. 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.

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

8. Option Formats

8.1.     Public Key Option

  The Public Key Option carries a public key of the node. This option
  follows the format presented in [ND98]:

   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    |         Algorithm ID1         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                            Random                             +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Algorithm ID2          |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  |                                                               |
  +                       Public Key (N bits)                     +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  where,

    Type                 An IANA assigned 8 bit identifier TBD for
                         the option type.

    Length               An 8 bit unsigned integer indicating
                         the option length (type + length fields)
                         in units of 8 octets.

    Algorithm ID1        An IANA assigned 16 bit identifier for

Arkko et al.                  Informational                    [Page 11]


Internet Draft             Secure ND with CGAs                June, 2002

                         the signature algorithm. The currently
                         defined values are:

                           1   RSA

    Random               A 64 bit random number used in the
                         creation of the address from the public
                         key.

   Algorithm ID2         An IANA assigned 16 bit identifier for
                         the hash algorithm. The currently
                         defined values are:

                           1   SHA1

   Public Key            An N bit field carrying the public key,
                         zero-padded to nearest 8 byte units.
                         The public key is in the format implied
                         by Algorithm ID1.

8.2.     Signature Option

  The Signature Option carries a digital signature calculated using the
  private key of the node. This option follows the format presented in
  [ND98]:

   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     |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
  |                                                               |
  +                   Digital Signature (N bits)                  +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  where,

    Type                 An IANA assigned 8 bit identifier TBD for
                         the option type.

    Length               An 8 bit unsigned integer indicating the
                         option length (type + length fields) in
                         units of 8 octets.

    Digital Signature    An N bit field carrying the digital
                         signature, zero-padded to nearest 8 byte
                         units. The signature is calculated using
                         the algorithm implied by Algorithm ID1 in
                         the public key option, and is also in the
                         format implied by this Algorithm ID1.

9. Security Considerations

  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.


Arkko et al.                  Informational                    [Page 12]


Internet Draft             Secure ND with CGAs                June, 2002

  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. It is not clear if this is
  necessary, however. (If necessary, we could cross-certify routers
  without involving hosts.)

  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 third party. However, we propose a heuristic
  method to test these properties in Section 7.1.

10. Acknowledgments

  The authors would like to thank James Kempf, Gabriel Montenegro, Erik
  Nordmark, Tuomas Aura and Mike Roe for interesting discussions in
  this problem space.

11. References

11.1.    Normative References

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

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

  [ADD98] Hinden, R., Deering, S., "IP Version 6 Addressing
  Architecture", RFC 2372, July 1998.

  [RSA78] Rivest, R., Shamir, A., Adleman, L. "A Method for Obtaining
  Digital Signatures and Public-Key Cryptosystems", Communications of
  the ACM, 21 (2), pp. 120-126, February 1978.

  [SHA1] Eastlake, D., Jones, P., "US Secure Hash Algorithm 1
  (SHA1)", RFC 3174, September 2001.

11.2.    Non-Normative References

  [ABK02] Kempf, J., Gentry, G., Silverberg, A., "Securing IPv6
  Neighbor Discovery Using Address Based Keys (ABKs)", Internet
  Draft (work in progress), February 2002.

  [Ark01] Arkko, J., Nikander, P., Kivinen, T., Rossi, M., "Manual SA
  Configuration for IPv6 link Local Messages", Internet Draft (work
  in progress), January 2001.


Arkko et al.                  Informational                    [Page 13]


Internet Draft             Secure ND with CGAs                June, 2002

  [Ark02] Arkko, J., Aura, T., Kempf, T., Mantyla, V.-M., Nikander,
  P., Roe, M. "Securing IPv6 Neighbor Discovery". Submitted for
  publication, 2002.

  [ARP82] Plummer, D. C., "An Ethernet Address Resolution Protocol --
  or -- Converting Network Protocol Addresses to 48.bit Ethernet
  Address for Transmission on Ethernet Hardware", RFC 826, November
  1982.

  [CAM01] O'Shea, G., Roe, M., "Child-proof Authentication for MIPv6
  (CAM), Computer Communications Review", April 2001.

  [POS81] Postel, J., "Internet Control Message Protocol", RFC 792,
  September 1981.

  [SUCV] Montenegro, G., Castelluccia, C., "SUCV Identifiers and
  Addresses", Internet Draft (work in progress), November 2001.

12. IPR Considerations

  The presented protocol uses public keys and hashes to prove address
  ownership. Ericsson's IPR may apply on such methods. The Ericsson
  policy on IPR issues can be checked from the Ericsson General IPR
  statement for IETF, http://www.ietf.org/ietf/IPR/ERICSSON-General.

13. Authors' Addresses

   Jari Arkko
   Oy LM Ericsson Ab
   02420 Jorvas
   Finland

   EMail: jari.arkko@ericsson.com

   Pekka Nikander
   Oy LM Ericsson Ab
   02420 Jorvas
   Finland

   EMail: pekka.nikander@nomadiclab.com

   Vesa-Matti Mantyla
   Oy LM Ericsson Ab
   Tutkijantie 2C
   90570 Oulu
   Finland

   EMail: vesa-matti.mantyla@ericsson.fi


Full Copyright Statement

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

Arkko et al.                  Informational                    [Page 14]


Internet Draft             Secure ND with CGAs                June, 2002

  and distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this paragraph
  areincluded 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 assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.






































Arkko et al.                  Informational                    [Page 15]