Network
CGA & SEND maintenance Working Group                               S. Krishnan
Internet-Draft
Group                                                           Ericsson
Internet-Draft                                               J. Laganier
Intended status: Standards Track                             J. Laganier                           QUALCOMM Inc.
Expires: January 14, September 4, 2010                               DoCoMo Euro-Labs                                     M. Bonola
                                             Rome Tor Vergata University
                                                           July 13, 2009
                                                      A. Garcia-Martinez
                                                                    UC3M
                                                           March 3, 2010

                    Secure Proxy ND Support for SEND
                      draft-ietf-csi-proxy-send-01
                      draft-ietf-csi-proxy-send-02

Abstract

   Secure Neighbor Discovery (SEND) specifies a method for securing
   Neighbor Discovery (ND) signaling against specific threats.  As
   defined today, SEND assumes that the node sending a ND message is the
   owner of the address from which the message is send, so that it is in
   possession of the private key used to generate the digital signature
   on the message.  This means that the Proxy ND signaling performed by
   nodes that do not possess knowledge of the address owner's private
   key cannot be secured using SEND.  This document extends the current
   SEND specification in order to support Proxy ND operation.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on January 14, September 4, 2010.

Copyright Notice

   Copyright (c) 2009 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info). document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   Secure Neighbor Discovery (SEND) specifies a method for securing
   Neighbor Discovery (ND) signaling against specific threats.  As
   specified today, SEND assumes that the node advertising an address is
   the owner  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the address Trust Legal Provisions and is are provided without warranty as
   described in possession of the private key used
   to generate the digital signature on the message.  This means that
   the Proxy ND signaling initiated by nodes that do not possess
   knowledge of the address owner's private key cannot be secured using
   SEND.  This document extends the current SEND specification with
   support for Proxy ND, the Secure Proxy ND Support for SEND. BSD License.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6  5
   4.  Application Scenarios  .  Secure Proxy ND Overview . . . . . . . . . . . . . . . . . . .  7
     4.1.  Scenario 1: RFC 4389 Neighbor Discovery  6
   5.  Secure Proxy ND Specification  . . . . . . . . . .  7
     4.2.  Scenario 2: Mobile IPv6 . . . . . .  8
     5.1.  Proxy Signature Option . . . . . . . . . . . . . . . . . .  8
     4.3.  Scenario 3: Proxy Mobile IPv6
     5.2.  Modified SEND processing rules . . . . . . . . . . . . . . 10
   5.  Secure Proxy ND Overview
       5.2.1.  Processing rules for senders . . . . . . . . . . . . . 10
       5.2.2.  Processing rules for receivers . . . . . . . . . . . . 11
     5.3.  Proxying Link-Local Addresses  . . . . . . . . . . . . . . 12
   6.  Secure Proxy ND Specification  Application Scenarios  . . . . . . . . . . . . . . . . . . . 14
     6.1.  Proxy Signature Option . 13
     6.1.  Scenario 1: Mobile IPv6  . . . . . . . . . . . . . . . . . 14 13
     6.2.  Modified SEND processing rules  Scenario 2: Proxy Mobile IPv6  . . . . . . . . . . . . . . 16
       6.2.1.  Processing rules for senders 15
     6.3.  Scenario 3: RFC 4389 Neighbor Discovery Proxy  . . . . . . 17
   7.  Backward Compatibility with RFC3971 nodes and non-SEND
       nodes  . . . . . . . . . . 16
       6.2.2.  Processing rules for receivers . . . . . . . . . . . . 17
   7. . . . . . . 20
     7.1.  Backward Compatibility with legacy SEND RFC3971 nodes  . . . . . . . . 20
     7.2.  Backward Compatibility with non-SEND nodes . . . . . . . . 18 20
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19 23
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20 24
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
     10.2. Informative References . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . 22

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", . . . . . . . . . . . . . . . . 26

1.  Requirements notation

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

2.  Introduction

   Secure Neighbor Discovery (SEND) [RFC3971] specifies a method for
   securing
   neighbor discovery Neighbor Discovery (ND) signaling [RFC4861] against specific
   threats.  As
   specified defined today, SEND assumes that the node advertising an address sending a ND
   message is the owner of the address and from which the message is sent,
   so that it is in possession of the private key used to generate the
   digital signature on the message.  This means that the Proxy ND
   signaling initiated performed by nodes that do not possess knowledge of the
   address owner's private key cannot be secured using SEND.

   This document extends the current SEND specification with support for
   Proxy ND.  From this point on we refer to such extension as "Secure
   Proxy ND Support for SEND".

3.  Terminology

   Secure Proxy ND

      A node authorized to either modify or generate a SEND message
      without knowing the private key related to the source address of
      the ICMPv6 ND message.

   Proxied IPv6 address

      An IPv6 address that doesn't does not belong to the Secure Proxy ND and
      for which the Secure Proxy ND is advertising.

4.  Application Scenarios

   In performing advertisements.

   Non-SEND node

      An IPv6 node that does not implement the SEND [RFC3971]
      specification but uses only the ND protocol defined in [RFC4861]
      and [RFC4862], without security.

   RFC3971 node

      An IPv6 node that does not implement the specification defined in
      this section we provide three different application scenarios document for
   which Secure Proxy ND support, but uses only the ICMPv6 Neighbor Discovery signaling cannot be secured by
   using SEND
      specification as defined in [RFC3971].

   SPND node

      An IPv6 node that implements the current specification defined in this
      document for Secure Proxy ND support.

4.  Secure Proxy ND Overview

   The original SEND specification.

   Either specification [RFC3971] has implicitly assumed that
   only the node sending a ND message is the owner of the entities described in address from
   which the following three scenarios,
   (i.e.: message is sent.  This assumption does not allow proxying
   of ND Proxy, MIPv6 Home Agent, PMIPv6 Mobile Access Gateway) can
   be consider as messages since the advertiser is required to generate a valid
   RSA Signature option, which in turns requires possession of the
   public-private key pair that was used to generate a CGA, or that was
   associated to a router certificate.

   To be able to separate the roles of ownership and advertiser the
   following extensions to the SEND protocol are defined:

   o  A Secure Proxy ND.

4.1.  Scenario 1: RFC 4389 Neighbor Discovery Proxy

          Link 1                                               Link 2

          Host A ND Proxy (P)                Host B
            |                          |                          |
            | SRC = certificate, which is a certificate authorizing
      an entity to act as an ND proxy.  It is a X509v3 certificate in
      which the purpose for which the certificate is issued has been
      specified explicitly as described in a companion document
      [I-D.ietf-csi-send-cert].  Briefly, a KeyPurposeID value is
      defined for authorizing proxies.  The inclusion of the proxy
      authorization value allows the certificate owner to perform
      proxying of SEND messages for a range of addresses indicated in
      the same certificate.  This certificate can be exchanged as a
      result of the Authorization Delegation Discovery process defined
      in [RFC3971].

   o  A                  |                          |
            | DST = solicited_node(B)  |                          |
            | ICMPv6 NS                |                          |
            | TARGET = B               |                          |
            | SLLAO = B_LL             |                          |
            |------------------------->|                          |
            |                          | SRC = new Neighbor Discovery option called Proxy Signature option
      (PSO).  This option contains the hash value of the public key of
      the proxy, and the digital signature of the SEND message computed
      with the private key of the proxy.  The hash of the public key of
      the proxy is computed over the public key contained in the Secure
      Proxy ND's certificate.  When a ND message contains a PSO, it MUST
      NOT contain CGA and RSA Signature options.  This option can be
      appended to any ND message: NA, NS, RS, RA and Redirect.

   o  A modification of the SEND processing rules for all ND messages:
      NA, NS, RS, RA, and Redirect.  When any of these messages is
      received with a valid Proxy Signature option, it is considered as
      secure.

   These extensions are applied in the following way:

   o  A Secure Proxy ND which proxies ND messages on behalf of a node
      can use the PSO option to protect the proxied messages.  This
      Secure Proxy ND becomes part of the trusted infrastructure just
      like a SEND router.

   o  In order to allow nodes to successfully validate secured proxied
      messages, the nodes must know the Secure Proxy ND certificate (in
      the format described in [I-D.ietf-csi-send-cert]) and must apply
      the modified processing rules specified in this document.  We call
      this nodes 'SPND nodes'.  Note that the rules for generating ND
      messages in SPND nodes do not change, so these nodes behave as
      defined in [RFC3971] for sending ND messages.

   o  To allow SPND nodes to know the certificate path required to
      validate the public key of the proxy, devices responding to CPS
      (Certification Path Solicitation) messages with CPA (Certification
      Path Advertisements) as defined in Section 6 of SEND specification
      [RFC3971] must handle the certificate format specified in
      [I-D.ietf-csi-send-cert], and must be configured with the
      appropriate certification path.

   The proposed approach resolves the incompatibilities between the
   current SEND specification and the application scenarios described in
   Section 6.

5.  Secure Proxy ND Specification

   A Secure Proxy ND performs all the operation described in the SEND
   specification [RFC3971] with the addition of new processing rules to
   ensure that the receiving node can differentiate between an
   authorized proxy generating or forwarding a SEND message for a
   proxied address, and a malicious node doing the same.

   This is accomplished by signing the message with the public key of
   the authorized Secure Proxy ND.  The signature of the ND Proxy is
   included in a new option called Proxy Signature option (PSO).  The
   signature is performed over all the NDP options present in the
   message and the PSO is appended as the last option in the message.

5.1.  Proxy Signature Option

   The Proxy Signature option allows public key-based signatures to be
   attached to NDP messages.  The format of the PSO 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     | DST = solicited_node(B)  |
            |          Reserved             | ICMPv6 NS
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       | TARGET = B                          Key Hash                             |
       |                                                               | SLLAO = P_LL
       |                                                               |                          |------------------------->|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                       Digital Signature                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | SRC = B                                                               |
       .                                                               .
       .                           Padding                             .
       .                                                               .
       |                                                               | DST =
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 1: PSO layout

   Type

      TBA

   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 11-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Key Hash

      A 128-bit field containing the most significant (leftmost) 128
      bits of a SHA-1 [SHA1] hash of the public key used for
      constructing the signature.  Its purpose is to associate the
      signature to a particular key known by the receiver.  Such a key
      MUST be the same one within the corresponding Secure Proxy ND's
      certificate.

   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 [RFC3972] value for Secure
          Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (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 Proxy Signature option.

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

      This field starts after the Key Hash field.  The length of the
      Digital Signature field is determined by the ASN.1 BER coding of
      the PKCS#1 v1.5 signature.

   Padding

      This variable-length field contains padding.  The length of the
      padding field is determined by the length of the Proxy Signature
      Option minus the length of the other fields.

5.2.  Modified SEND processing rules

   The modifications described in the following section applies when a
   SEND message contains the Proxy Signature option (PSO), i.e. the
   message was sent by a Secure Proxy ND.

   This specification modifies the sender and receiver processing rules
   for the CGA and RSA options defined in the SEND specification
   [RFC3971].

5.2.1.  Processing rules for senders

   A                  |
            |                          | ICMPv6 NA                |
            |                          | TARGET = B               |
            |                          | TLLAO = B_LL             |
            |                          |<-------------------------|
            | SRC = B                  |                          |
            | DST = message sent by a Secure Proxy ND for a proxied address MUST
   contain a Proxy Signature option (PSO) and MUST NOT contain CGA and
   RSA Signature options.

   A                  |                          |
            | ICMPv6 NA                |                          |
            | TARGET = B               |                          |
            | TLLAO = B_LL             |                          |
            |<-------------------------|                          |
            |                          |                          |

                       Figure 1: Secure Proxy ND operations sending a SEND message with the PSO Signature
   option MUST construct the message as follows:

   1.  The SEND message is constructed without the PSO as follows:

       A.  If the Secure Proxy ND is locally generating the SEND message
           for a proxied address, the message is constructed as
           described in Neighbor Discovery for IP version 6
           specification [RFC4861].

       B.  If the Secure Proxy ND is forwarding a SEND message, first
           the authenticity of the intercepted message is verified as
           specified in SEND specification [RFC3971], Section 5.  If the
           SEND message is valid, any CGA or RSA option MUST be removed
           from the message.  The Neighbor Discovery (ND) intercepted message is finally
           modified as described in Section 4 of the ND Proxy
           specification [RFC4389] provides [RFC4389].

       C.  If the Secure Proxy ND is forwarding a
   method by which multiple link layer segments are bridged into SEND message already
           containing a
   single segment and specifies PSO, first the authenticity of the intercepted
           message is verified as specified in Section 6.2.2 of this
           draft.  If the SEND message is valid, the original PSO MUST
           be removed from the message.  The intercepted message is
           finally modified as described in Section 4 of the IP-layer support that enables
   bridging under these circumstances.

   A ND Proxy shall parse any IPv6 packet it receives on a proxy
   interface
           specification[RFC4389].

   2.  Timestamp and Nonce options are included according to check whether it contains one of the following ICMPv6
   messages: Neighbor Solicitation (NS), Neighbor Advertisement (NA),
   Router Advertisement, or Redirect.  Since each of these messages
   contains rules
       specified in SEND [RFC3971].  The value in the Timestamp option
       MUST be generated by the Proxy.  If the proxy is forwarding a link-layer address which might not
       message, the Nonce value in the proxied message MUST be valid on another
   segment, the ND same
       as in the forwarded message.

   3.  The Proxy Signature option is added as the last option in the
       message.

   4.  The data is signed as explained in Section 5.1.

5.2.2.  Processing rules for receivers

   Any SEND message without a Proxy Signature option MUST be treated as
   specified in the SEND specification [RFC3971].

   A SEND message including a Proxy proxies these packets Signature option MUST be processed
   as follows, specified below:

   1.  The receiver MUST ignore any RSA and CGA options, as
   illustrated in Figure 1:

   1. well as any
       options that might come after the first PSO.  The source link layer address will be options are
       ignored for both signature verification and NDP processing
       purposes.

   2.  The Key Hash field MUST indicate the address use of a known public key.
       A valid certification path (see [RFC3971] Section 6.3) between
       the outgoing
       interface.

   2.  The destination link layer address will be receiver's trust anchor and the address in sender's public key MUST be
       known.  The Secure Proxy ND's X509v3 certificate MUST contain a
       extended key usage extension including the
       neighbor entry corresponding to KeyPurposeId value for
       the destination IPv6 address. proxy authorization.

   3.  A link layer address within  The Digital Signature field MUST have correct encoding.

   4.  The Digital Signature verification MUST show that the payload (that is, signature
       has been calculated as specified in Section 5.1.

   5.  Timestamp and Nonce options MUST be processed as specified in
       [RFC3971] Section 5.3.4, except for replacing 'RSA Signature
       option' by 'PSO option'.

   6.  Messages with the Override bit [RFC4861] set should override an
       existing cache entry regardless if it was created as a Source
       Local Link Address result of
       a RSA Signature option - SLLAO, or a Target Local Link Address PSO option - TLLAO) validation.  When it is substituted with
       not set the advertisement will not update a cached link-layer
       address created securily by means of RSA Signature option or PSO
       option validation.

   Messages that do not pass all the
       outgoing interface.

   Moreover, when any other IPv6 unicast packet is received above tests MUST be silently
   discarded if the host has been configured to accept only secured ND
   messages.

5.3.  Proxying Link-Local Addresses

   Secure Neighbor Discovery [RFC3971] relies on certificates to prove
   that routers are authorized to announce a proxy
   interface, if it is certain prefix.  However,
   Neighbor Discovery [RFC4861] states that router does not locally destined then announce the
   Link-Local prefix (fe80::/64).  Hence, it is forwarded
   unchanged (other than using not required for a new link-layer header) SEND
   certificate to the proxy
   interface for which the next hop hold a X.509 IP address appears in extensions that authorizes the neighbor
   cache.  If no neighbor cache entry is present,
   fe80::/64 prefix.  Some scenarios ([RFC4389], [RFC5213]) impose that
   the Secure ND proxy should
   queue provides proxying function for the packet and initiate Link-Local
   address of a Neighbor Discovery signalling as if
   the ICMPv6 NS message were locally generated.

   A node.  When Secure ND proxy cannot protect proxied ND messages since protection functionality on a Link-
   Local address is required, either a list of an
   ND message as per link-local addresses, or
   the current SEND specification requires knowledge
   of fe80::/64 prefix MUST be explicitly authorized to be proxied in
   the private key of each node corresponding certificate.

6.  Application Scenarios

   In this section we describe three different application scenarios for
   which it Secure Proxy ND Support for SEND can be applied.  Note that the
   particular way in which Secure Proxy ND support is generating or
   forwarding a applied (which ND message
   messages are proxied, in which directions, how the interaction with
   non-SEND hosts and RFC3971 hosts is handled, etc.) largely depends on
   the bridged link layer segments.

4.2. particular scenario considered.  In the first two scenarios
   presented below, ND messages are synthesized on behalf of off-link
   nodes.  In the third one, ND messages are generated in reaction to ND
   messages being received by other interfaces of the proxied node.

6.1.  Scenario 2: 1: Mobile IPv6

   The description of the problems for deploying SEND in this scenario
   can be found in [I-D.ietf-csi-sndp-prob].

   The Mobile IPv6 protocol (MIPv6) [RFC3775] allows a mobile node Mobile Node (MN)
   to move from one link to another while maintaining reachability at a
   stable address, the so-called MN's home address (HoA.) Home Address (HoA).  When a mobile node MN
   attaches to a foreign network, all the packets sent to the MN's HoA
   and forwarded on the home link
   by a correspondent node Correspondent Node (CN) on the home link, or a
   router router, are
   intercepted by the home agent Home Agent (HA) on that home link, encapsulated
   and tunneled to the mobile node's MN's registered care-of
   address (CoA.) Care-of Address (CoA).

   The HA intercepts these packets by being acting as a Neighbor Discovery ND proxy for this MN.
   Lets assume that the nodes in the home link use SEND.  When a Neighbor Solicitation (NS) secured
   NS is intercepted on the home link, the home agent HA checks the validity of the
   received message according to the rules stated in [RFC3971].  If the
   message is valid, it checks if the Target address within the NS
   matches with any of the MN's Home Address in the Binding Cache and if
   so, it replies with a Neighbor Advertisement (NA) containing constructed as
   described in [RFC4861], so it contains its own link layer address
   (HA_LL) as the Target Link Layer Address Option (TLLAO), as illustrated in Figure 2.

         Node (N)                Home Agent (HA)        Mobile Node (MN)
         on Home Link             on Home Link          on Foreign Link
           |                          |                          |
           | SRC = N                  |                          |
           | DST = solicited_node(MN) |                          |
           | ICMPv6 NS                |                          |
           | TARGET = MN              |                          |
           | SLLAO = N_LL             |                          |
           |------------------------->|                          |
           |                          |                          |
           | SRC = MN                 |                          |
           | DST = N                  |                          |
           | ICMPv6 NA                |                          |
           | TARGET = MN              |                          |
           | TLLAO = HA_LL            |                          |
           |<-------------------------|                          |
           |                          |                          |
           | traffic                  |                          |
           | dest= MN HoA             |                          |
           |------------------------->|                          |
           |                          |                          |
           |                          | tunnelled traffic        |
           |                          | dest= MN CoA             |
           |                          |------------------------->|
           |                          |                          |

            Figure 2: Proxy ND role of the Home agent in MIPv6

   It is not possible to apply the current SEND specification to protect
   the NA message issued by the HA.  To generate an ICMPv6 NA with a
   valid CGA PSO
   option and signing the corresponding RSA Signature option, message, added as the HA
   needs knowledge last option of the private key related to the MN's
   Cryptographically Generated Address (CGA.)  Any ICMPv6 NA without a
   valid CGA and RSA signature option is to be treated as insecure by a
   SEND receiver.

4.3.  Scenario 3: Proxy Mobile IPv6

             MN                   new MAG                  LMA
              |                      |                      |
          MN Attached message.

         Node (N)                Home Agent (HA)        Mobile Node (MN)
         on Home Link             on Home Link          on Foreign Link
           |                          |                          |
           | SRC = N                  |                          |       MN Attached Event from MN/Network
           | DST = solicited_node(MN) |                          |
           |
              |--- ICMPv6 RS ------->|                      |
              |                      |                      |
              |                      |--- PBU ------------->|
              |                      |                      |
              |                      |                  Accept PBU
              |                      |                      |
              |                      |<------------- PBA ---|
              |                      |                      | NS                |                 Accept PBA                          |
           | TARGET = MN              |                          |
           |                      |==== Bi-Dir Tunnel ===| SLLAO = N_LL             |                          |
           |
              |<------ ICMPv6 RA ----| [CGA]                    |                          |
           | RSA signature            |                          |
           |------------------------->|                          |
           |                          |                          |
           |

                Figure 3: Mobile node's handover in PMIPv6

   Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] is a network-based
   mobility management protocol that provides an IP mobility management
   support for MNs without requiring MNs being involved in the mobility
   related signaling.  The IP mobility management is totally hidden to
   the MN in a Proxy Mobile IPv6 domain and is performed by two
   functional entities: the Local Mobility Anchor (LMA) and the Mobile
   Access Gateway (MAG.)

   When the MN connects to a new access link it will send a multicast
   ICMPv6 Router Solicitation (RS.)  The MAG on the new access link,
   upon detecting the MN's attachment, will signal the LMA for updating
   the binding state of the MN (Proxy Binding Update - PBU) and once the
   signaling is complete (Proxy Binding Ack - PBA - received), it will
   reply to the MN with a ICMPv6 Router Advertisement (RA) containing
   its home network prefix(es) that were assigned to that mobility
   session, making the MN believe it is still on the same link and not
   triggering the IPv6 address reconfiguration (figure Figure 3.)
   To avoid potential link-local address collisions between the MAG and
   the SRC = HA                 |                          |
           | DST = N                  |                          |
           | ICMPv6 NA                |                          |
           | TARGET = MN after a handoff to a new link, the Proxy Mobile IPv6
   specification requires the MAG's link-local address configured on the
   link to which the              |                          |
           | TLLAO = HA_LL            |                          |
           | PSO signature            |                          |
           |<-------------------------|                          |
           |                          |                          |
           | traffic                  |                          |
           | dest= MN is attached to be generated once by the LMA when
   the HoA             |                          |
           |------------------------->|                          |
           |                          |                          |
           |                          | tunnelled traffic        |
           |                          | dest= MN first attach to a PMIPv6 domain, and to be provided to the new
   MN's serving MAG after each handoff.  Thus, from the MN's point of
   view, the MAG's link-local address remains constant for the duration CoA             |
           |                          |------------------------->|
           |                          |                          |

            Figure 2: Proxy ND role of that MN's session.

   The approach described above and the current SEND specification are
   incompatible since:

      Sharing Home agent in MIPv6

   A node receiving the same link-local address on different MAGs would
      require all MAGs of a PMIPv6 domain to construct NA containing the CGA and PSO (e.g.: the
      RSA Signature option with CN in the same public-private key pair, which
      is not acceptable from home
   link, or a security point router) must have a certificate of view.

      Using different public-private key pairs on different MAGs would
      mean different MAGs use different CGAs as link-local address.
      Thus the serving MAG's link-local address changes after each
      handoff public key of the MN which is contradiction with the way MAG link-
      local address assignment occurs in
   HA acting as a PMIPv6 domain.

5. Secure Proxy ND Overview

   The original SEND specification [RFC3971] has implicitly assumed that
   the owner of the address was ND.  To do so, a certificate for the one who was advertising HA
   could be made available through the prefix.
   This assumption does not allow proxying of a CGA based address as Authorization Delegation
   Discovery process [RFC3971] performed at the
   receiver requires home link, i.e. the advertiser
   devices responding to generate a valid CGA and RSA
   Signature option, which CPS messages should be configured to include in turns requires possession
   CPA messages information about the HA certificate.

   The Override bit of the public-
   private key pair that was NA message is used to generate the CGA.

   This specification explicitly separates control which messages
   should prevail each case: the roles of ownership and
   advertiser message generated by extending the SEND protocol as follows:

   o  A certificate authorizing an entity proxy once the
   MN moves from the home network, or the MN if it come back to act the home
   link, as an ND proxy is
      introduced.  This is achieved via specifying explicitly defined in the
      X509v3 certificate the purpose MIPv6 specification [RFC3775]

6.2.  Scenario 2: Proxy Mobile IPv6

   Proxy Mobile IPv6 [RFC5213] is a network-based mobility management
   protocol that provides an IP mobility management support for which MNs
   without requiring MNs being involved in the certificate mobility related
   signaling.  The IP mobility management is
      issued, as described totally hidden to the MN in
   a companion document
      [I-D.krishnan-cgaext-send-cert-eku].  Briefly, Proxy Mobile IPv6 domain and is performed by two KeyPurposeID
      values are defined: one for authorizing routers, functional
   entities: the Local Mobility Anchor (LMA) and one for
      authorizing proxies.  The inclusion of the proxy authorization
      value allows Mobile Access
   Gateway (MAG).

   When the certificate owner MN connects to perform proxying of SEND
      messages for a set of prefixes indicated in new access link it will send a multicast
   ICMPv6 Router Solicitation (RS).  The MAG on the same certificate.

   o  A new option called Proxy Signature option (PSO) is defined.  This
      option contains access link,
   upon detecting the MN's attachment, will signal the LMA for updating
   the key hash value binding state of the Secure Proxy ND's public
      key MN (Proxy Binding Update - PBU) and once the digital signature computed over
   signaling is complete (it receives a Proxy Binding Ack - PBA), it
   will reply to the SEND message.  The
      key has value MN with a ICMPv6 Router Advertisement (RA)
   containing the home network prefix(es) that were assigned to that
   mobility session, making the MN believe it is computed over still on the public key within same link
   and not triggering the Secure
      Proxy ND's certificate.

   o  The SEND processing rules are modified for all Neighbor Discovery
      messages: NA, NS, RS, RA, IPv6 address reconfiguration (figure
   Figure 3).

             MN                   new MAG                  LMA
              |                      |                      |
          MN Attached                |                      |
              |                      |                      |
              |       MN Attached Event from MN/Network     |
              |                      |                      |
              | SRC = MN             |                      |
              | DST = all-routers    |                      |
              | ICMPv6 RS            |                      |
              | [CGA]                |                      |
              | RSA signature        |                      |
              |--------------------->|                      |
              |                      |                      |
              |                      |--- PBU ------------->|
              |                      |                      |
              |                      |                  Accept PBU
              |                      |                      |
              |                      |<------------- PBA ---|
              |                      |                      |
              |                 Accept PBA                  |
              |                      |                      |
              |                      |==== Bi-Dir Tunnel ===|
              |                      |                      |
              |        SRC = MAG4MN  |                      |
              |            DST = MN  |                      |
              |           ICMPv6 RA  |                      |
              |        SLL = MAG_LL  |                      |
              |           PSO        |                      |
              |<---------------------|                      |
              |                      |                      |
              |                      |                      |
              |                      |                      |

                Figure 3: Mobile node's handover in PMIPv6

   To avoid potential link-local address collisions between the MAG and Redirect.  When any of these
      messages is received with
   the MN after a handoff to a valid new link, the Proxy Signature option, it Mobile IPv6
   specification requires the MAG's link-local address configured on the
   link to which the MN is
      considered as secure even if it doesn't contain attached to, to be generated once by the LMA
   when the MN first attach to a CGA option.

   The Secure Proxy ND becomes part PMIPv6 domain, and to be provided to
   the new MN's serving MAG after each handoff.  Thus, from the MN's
   point of view, the trusted infrastructure just
   like a SEND router.  The Secure Proxy ND is MAG's link-local address remains constant for the
   duration of that MN's session.

   Each MAG can be granted a certificate per each link-local address
   expected by any MN that specifies the range of addresses for which it is allowed could attach to
   perform proxying the link.  However, the use
   of SEND messages.  Hosts Secure Proxy ND can use greatly reduce the same process number of certificates
   needed.  In this case, each MAG is configured to
   discover the certification path between act as a proxy and one by
   means of the host's a certification path from a trust anchors as anchor associated to the one defined for routers in Section 6 of SEND
   specification [RFC3971].

   The proposed approach resolves
   PMIPv6 domain, authorizing each MAG to proxy securely ND messages.

   When a secured RS message is issued by the incompatibilities between MN, the
   current SEND specification and MAG checks its
   validity according to the application scenarios described rules stated in
   Section 4.  Since SEND messages containing [RFC3971].  If the message
   is valid, it replies with a Proxy Signature option
   are not required RA with source address equal to carry a CGA option, the IPv6 source MAG
   link-local address is no
   longer cryptographically bound associated to the signature, and MN in this PMIPv6 domain and its
   own link layer address as Source link-layer address, with the PSO
   option signing the message, added as the sender last option of the message.

   When the MN receives this message, it may issue a
   Neighbor Discovery CPS message is not required in
   order to be the owner of the
   claimed address.  Thus, obtain the Secure Proxy ND is able certification path associated to either forward
   and generate SEND messages for a proxied address within the set public key
   of
   prefixes for which it is authorized.

6.  Secure Proxy ND Specification

   A Secure ND Proxy performs all the operation described in the SEND
   specification [RFC3971] PSO (or may have this certification path already available).
   The MN node must be configured with a trust anchor related with the addition of new processing rules
   MAG's certificate.  The MAG (or other device) could be configured to
   ensure that the receiving node can differentiate between an
   authorized proxy generating or forwarding
   provide its certification path in a SEND CPS message for as a
   proxied address, and response to a malicious node doing the same.

   This is accomplished by signing the
   CPA message with issued by the public key of MN.  With this information, the authorized Secure Proxy ND.  The signature of MN can
   validate the neighbor
   discovery proxy is included in a new option called Proxy Signature
   option (PSO.)  The signature is performed over all RS information, and use the NDP options
   present in same link-local address to
   access to the message MAG.

   The MAG will intercept secured NS messages and reply with NA messages
   containing its own link layer address as the Target Link Layer
   Address Option (TLLAO), with a PSO is appended option signing the message, added
   as the last option in of the message.

6.1.  Proxy Signature Option  The Proxy Signature option allows public key-based signatures to be
   attached to NDP same applies for Redirect
   messages.

6.3.  Scenario 3: RFC 4389 Neighbor Discovery Proxy

   The format description of the PSO is described problems for deploying SEND in this scenario
   can be found 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 [I-D.ietf-csi-sndp-prob].

          Link 1                                               Link 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Host A                   ND Proxy (P)                Host B
            |     Type                          |    Length                          |           Reserved
            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRC = A                  |                          |
            |                          Key Hash DST = solicited_node(B)  |                          |
            | ICMPv6 NS                |                          |
            | TARGET = B               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                          |
            |
       .                                                               .
       .                       Digital Signature                       .
       .                                                               . SLLAO = A_LL             |                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |------------------------->|                          |
            |                          | SRC = A                  |
            |                          | DST = solicited_node(B)  |
            |                          | ICMPv6 NS                |
            |                          | TARGET = B               |
            |                          | SLLAO = P_LL             |
            |                          |------------------------->|
            |                          |                          |
            |                          | SRC = B                  |
            |                          | DST = A                  |
            |                          | ICMPv6 NA                |
            |                          | TARGET = B               |
            |                          | TLLAO = B_LL             |
            |                          |<-------------------------|
            | SRC = B                  |                          |
            | DST = A                  |                          |
            | ICMPv6 NA                |                          |
            | TARGET = B               |                          |
            | TLLAO = P_LL             |                          |
            |<-------------------------|                          |
            |
       .                                                               .
       .                           Padding                             .
       .                                                               .                          |                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4: PSO layout

   Type

      TBA

   Length Proxy ND operations

   The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
   method by which multiple link layer segments are bridged into a
   single segment and specifies the IP-layer support that enables
   bridging under these circumstances.

   A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy
   interface to check whether it contains one of the following secured
   ICMPv6 messages: NS, NA, RA, or Redirect.  The length Secure ND Proxy MUST
   verify the authenticity of the option (including received ND message, according to
   [RFC3971].  If 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. SEND message is valid, then it proxied the
   original message with the following changes:

   1.  The value MUST be
      initialized message is processed according to zero by [RFC4389].  This includes
       changing the sender, and MUST source link layer address will be ignored by the
      receiver.

   Key Hash

      A 128-bit field containing the most significant (leftmost) 128
      bits of a SHA-1 [SHA1] hash address of the public key used for
      constructing
       outgoing interface, maintaining the signature.  Its purpose is to associate destination link layer
       address as the
      signature to a particular key known by address in the receiver.  Such a key
      MUST be neighbor entry corresponding to the same one
       destination IPv6 address, etc.  In particular any link layer
       address within the Secure Proxy ND's certificate.

   Digital Signature

      A variable-length field containing payload (that is, in a PKCS#1 v1.5 signature,
      constructed by using the sender's private key over Source Local Link
       Address option - SLLAO, or a Target Local Link Address option -
       TLLAO) is substituted with the following
      sequence link-layer address of octets:

      1.  The 128-bit CGA Message Type tag [RFC3972] value for Secure
          Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804 (The tag
          value has been generated randomly by the editor of this
          specification.) outgoing
       interface.

   2.  The 128-bit Source Address field from the IP header.  Any CGA or RSA option is removed.

   3.  If a Nonce option existed in the original message, its value is
       preserved in the proxied message.  The 128-bit Destination Address field from Timestamp is generated by
       the IP header. proxy.

   4.  The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from PSO option is added as the ICMP header.

      5.  The NDP message header, starting from last option in the octet after message,
       signing all the ICMP
          Checksum field and continuing up to but information contained so far in the message.

   Moreover, when any other IPv6 unicast packet is received on a proxy
   interface, if it is not including NDP
          options.

      6.  All NDP options preceding locally destined then it is forwarded
   unchanged (other than using a new link-layer header) to the Proxy Signature option.

      The signature value proxy
   interface for which the next hop address appears in the neighbor
   cache.  If no neighbor cache entry is computed with present, the RSASSA-PKCS1-v1_5
      algorithm ND proxy should
   queue the packet and SHA-1 hash, initiate a Neighbor Discovery signalling as defined if
   the ICMPv6 NS message were locally generated.

   In order to deploy this scenario, nodes in [RSA].

      This field starts after proxied segments MUST know
   the Key Hash field.  The length of certificate authorizing proxy operation.  To do so it could be
   required to configure at least one device per each proxied segment
   (may be the
      Digital Signature field is determined by proxy itself) to propagate the length required certification
   path to authorize proxy operation by means of a CPS/CPA exchange.

   While more robust mechanisms could be developed for securing the RSA
      Signature option minus
   scenario described in [RFC4389], if hosts have been upgraded to apply
   the length rules stated in Section 5.2.2, for example, to benefit from
   secure support for other scenarios, the application of this mechanism
   is straighforward.

7.  Backward Compatibility with RFC3971 nodes and non-SEND nodes

   In this section we discuss the interaction of Secure Proxy ND nodes
   and SPND nodes with RFC3971 nodes and non-SEND nodes.

7.1.  Backward Compatibility with RFC3971 nodes

   RFC3971 nodes, i.e.  SEND nodes not compliant with the other fields (including modifications
   required in Section 5 cannot interpret correctly a PSO option
   received in a proxied ND message.  These SEND nodes silently discard
   the variable length Pad field.)

   Padding

      This variable-length field contains padding, PSO option, as specified in [RFC4861] for any unknown option.  As
   a result, these messages will be treated as many bytes long unsecured as
      remain after the end described in
   Section 8 "Transitions Issues" of the signature.

6.2.  Modified SEND processing rules

   The modifications described specification [RFC3971].

   When RFC3971 nodes and SPND nodes exchange ND messages (without proxy
   intervention), in either direction, messages are generated according
   to the following section applies when a SEND message contains specification [RFC3971], so these nodes interoperate
   seamlessly.

   In the Proxy Signature option (PSO), i.e. scenarios in which the
   message was sent proxy translates ND messages, the
   messages to translate can either be originated in a RFC3971 node or
   in an SPND node, without interoperability issues.

7.2.  Backward Compatibility with non-SEND nodes

   Plain ND nodes receiving NDP packets silently discard PSO options, as
   specified in [RFC4861] for any unknown option.  Therefore, these node
   interpret messages proxied by a Secure Proxy ND.

   This specification modifies the sender ND as any other ND
   message.

   When non-SEND nodes and receiver processing rules
   for the following options defined SPND nodes exchange ND messages (without
   proxy intervention), in either direction, the SEND specification
   [RFC3971]: CGA option, RSA option.

6.2.1.  Processing rules specified in
   section 8 of [RFC3971] apply.

   A secure Proxy ND SHOULD support the use of secured and unsecured NDP
   messages at the same time, although it MAY have a configuration that
   causes not to perform proxing for senders unsecured NDP messages.  A ICMPv6 message sent secure
   Proxy ND MAY also have a configuration option whereby it disables
   secure ND proxying completely.  This configuration SHOULD be switched
   off by default, that is SEND is used.  In the next paragraphs we
   discuss the recommended behavior of the Secure Proxy ND regarding to
   which protection level provide to proxied messages in a mixed
   scenario involving SPND/RFC3971 nodes and non-SEND nodes.  In
   particular, two different situations occur depending on if the
   proxied nodes are RFC3971 or SPND, or if they are non-SEND nodes.

   As a rule of thumb, the Secure Proxy ND should only generate PSO
   options for a proxied address MUST
   contain a Proxy Signature option (PSO) and MUST NOT contain CGA and
   RSA Signature options.

   A Secure Proxy ND sending a nodes which have SEND message with capabilities (i.e. that they could
   use SEND to defend their messages if being in the PSO Signature
   option MUST construct same link than the message as follows:

   1.  The SEND message
   proxy, either RFC3971 nodes or SPND nodes).  This is constructed without relevant to
   allow nodes preferring secured information over unsecured one, and
   for executing the PSO DAD procedure, as follow:

       A.  If specified in [RFC3971].
   Therefore, the Secure Proxy ND is locally generating SHOULD generate messages containing
   the SEND message PSO option for a proxied address, SPND and RFC3971 hosts, and SHOULD NOT generate
   messages containing the message is constructed as
           described in Neighbor Discovery PSO option for IP version 6
           specification [RFC4861].

       B.  If the non-SEND nodes.  Note that ND
   advertisements in response to solicitations generated by a Secure
   Proxy ND is forwarding a SEND message, first must be secured or not according to the authenticity previous
   considerations (i.e. to the nature of the intercepted message is verified as
           specified in SEND specification [RFC3971] Section 5.  If proxied node), and not
   according to the
           SEND message is valid, any CGA secure or RSA option MUST be removed
           from unsecure nature of the solicitation
   message.  The intercepted message is finally
           modified as described in Section 4 of

   To apply this rule, we have to consider that depending on the
   application scenario the proxy may translate ND Proxy
           specification [RFC4389].

   2.  The Proxy Signature option is added as messages generated by
   a node or synthetise ND messages on behalf of a node.

   o  For ND translated messages, the last option rule can be easily applied: only
      messages validated in the
       message.

   3.  The data is signed as explained in Section 6.1.

6.2.2.  Processing rules for receivers

   Any SEND message without a Secure Proxy Signature option ND according to the SEND
      specification [RFC3971] MUST be treated as
   specified proxied securely by the inclusion
      of a PSO option.  Unsecured ND messages could be proxied if
      unsecured operation is enabled in the SEND specification [RFC3971].

   A SEND proxy, but the message including a
      generated by the Secure Proxy Signature option ND for the received message MUST NOT
      include a PSO option.

   o  For ND messages synthesised on behalf of remote nodes, different
      considerations should be processed
   as specified below:

   1.  The receiver MUST ignore any RSA and CGA options, as well as any
       options that might come after made according to the first PSO.  The options are
       ignored particular
      application scenario.

      *  For MIPv6, if the MN can return to the home link, it is
         required for both signature verification and NDP processing
       purposes.

   2.  The Key Hash field MUST indicate the proxy to know if the node could use of a known public key. SEND to
         defend its address or not.  A valid certification path (see [RFC3971] Section 6.3) mismatch between the receiver's trust anchor proxy and the sender's public key MUST be
       known.  The Secure Proxy ND's X509v3 certificate MUST contain a
       extended key usage extension
         proxied node behavior regarding to SEND operation would result
         in unaproppriate operation.  A HA including the KeyPurposeId value PSO option for
         proxying a non-SEND MN would make ND messages sent by the proxy authorization.

   3.  The Digital Signature field MUST
         to be more preferred than ND message of the non-SEND MN if the
         MN returns to the home link (even if the proxied messages have correct encoding and MUST
       NOT exceed
         the length of Override bit set to 1).  Not using the PSO option for a
         RFC3971 or SPND MN would make more vulnerable the address in
         the home link when the MN is away than when it is in the home
         link (and would defeat the purpose of the Secure Proxy ND
         mechanism).  Therefore, in this case the HA must know the SEND
         capabilities of the MN.

      *  We can state the same for the Proxy Signature option minus Mobile IPv6 scenario as for
         the
       Padding.

   4.  The Digital Signature verification MUST show MIPv6 scenario.  Note that the signature a node moving from a link in
         which PSO has been calculated as specified used to protect a link-layer address to a
         link in Section 6.1.

   Messages that do which ND messages are not pass all SEND-enabled would prevent
         the above tests MUST be silently
   discarded if node from adquiring the host has been configured new information until the
         corresponding cache expires.  However, in this case it is
         reasonable to accept only secured consider that all MAGs provide the same security
         for protecting ND
   messages.

7.  Backward Compatibility with legacy SEND nodes messages, and that either all MAGs will
         behave as Secure Proxy ND, or none, so configuration could be
         easier.

8.  Security Considerations

   The PSO added by mechanism described in this document introduces a new Proxy
   Signature Option (PSO) allowing a Secure Proxy ND will be ignored by nodes
   implementing the original to generate or
   modify a SEND specification and hence message for a proxied address.  An SPND node will not cause
   any interoperability problems.  Since the only
   accept such a message if it includes a valid PSO generated by an
   authorized Secure Proxy ND also
   removes ND.  Such a message has equivalent protection
   to the original threats presented in section 9 of [RFC3971] as a message
   signed with a RSA option, these Signature option.

   The security of proxied ND messages will be treated as
   "unsecured" not including a PSO option is the
   same of an unsecured ND message.  The security of a proxied ND
   message as described in Section 8 "Transitions Issues" received by a non-SEND host or RFC3971 host is the same of an
   unsecured ND message.

   Thanks to the SEND specification [RFC3971].  Thus, this specification does not
   introduce any new transition issue compared authorization certificate it is provisioned with, a
   proxy ND is authorized to issue ND signaling on behalf of nodes on
   the original SEND
   specification.

8.  Security Considerations

   The mechanism described in this document introduce subnet.  Thus, a new Proxy
   Signature Option (PSO) allowing compromised proxy is able, like a Secure Proxy ND compromised
   router, to generate siphon off traffic from the host, or
   modify a SEND message for mount a proxied address.  A node will only accept
   such man-in-the-
   middle attack.  However, when two on-link hosts communicate using
   their respective link-local addresses, the threats involved with a message if it includes
   compromised router and a valid PSO generated by an authorized
   Secure Proxy ND.

   If, on compromised proxy ND differs because the other hand, a message does
   router is not include able to siphon off traffic exchanged between the hosts
   or mount a PSO, then man-in-the-middle attack, while the proxy ND can, even if
   the hosts use SEND.

   The messages for which a Secure Proxy ND support doens't introduce any further security issues
   since this specification does not modify perform its function, and
   the SEND processing rules link for which this function is performed MUST be configured
   appropriately for each proxy and scenario.  This configuration is
   specially relevant if
   an ICMPv6 Secure Proxy ND message does is used for translating ND
   messages from one link to another.

   Proper configuration of when the PSO option must or must not contain a PSO.  Thus, be
   included, depending on the same security
   considerations than that of proxied node being SEND applies (cf. or non-SEND may
   result in security considerations, as discussed in Section 9 7.

   Attacks to the timestamp of the SEND
   specification [RFC3971].) secured ND message can be performed
   as describe in section 7.3 of [I-D.ietf-csi-sndp-prob].

9.  IANA Considerations

   IANA is requested to allocate:

      A new IPv6 Neighbor Discovery Option types type for the PSO, as TBA.
      The value need to be allocated from the namespace specified in the
      IANA registry IPv6 NEIGHBOR DISCOVERY OPTION FORMATS located at
      http://www.iana.org/assignments/icmpv6-parameters.

      A new 128-bit value under the CGA Message Type [RFC3972]
      namespace, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.

10.  References

10.1.  Normative References

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-18 (work in progress),
              May 2008.

   [I-D.krishnan-cgaext-send-cert-eku]

   [I-D.ietf-csi-send-cert]
              Gagliano, R., Krishnan, S., Kukec, A., and K. Ahmed, A. Kukec, "Certificate
              profile and certificate management for SEND",
              draft-krishnan-cgaext-send-cert-eku-03
              draft-ietf-csi-send-cert-02 (work in progress),
              March 2009.
              February 2010.

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", RFC 4389, April 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

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

   [SHA1]     National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS PUB 180-1 , April 1995.

10.2.  Informative References

   [I-D.ietf-csi-sndp-prob]
              Combes, J., Krishnan, S., and G. Daley, "Securing Neighbor
              Discovery Proxy: Problem Statement",
              draft-ietf-csi-sndp-prob-04 (work in progress),
              January 2010.

Authors' Addresses

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Email: suresh.krishnan@ericsson.com

   Julien Laganier
   DoCoMo Communications Laboratories Europe GmbH
   Landsberger Strasse 312
   Munich  D-80687
   Germany
   QUALCOMM Incorporated
   5775 Morehouse Dr
   San Diego, CA  92121
   USA

   Phone: +49 89 56824 231 +1 858 658 3538
   Email: julien.ietf@laposte.net
   URI:   http://www.docomolab-euro.com/ julienl@qualcomm.com

   Marco Bonola
   Rome Tor Vergata University
   Via del Politecnico, 1
   Rome  I-00133
   Italy

   Phone:
   Email: marco.bonola@gmail.com

   Alberto Garcia-Martinez
   U. Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91 6248782
   Email: alberto@it.uc3m.es
   URI:   http://www.it.uc3m.es/