GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc6496

Internet Engineering Task Force (IETF) S. Krishnan Request for Comments: 6496 Ericsson Category: Experimental J. Laganier ISSN: 2070-1721 Juniper Networks

                                                             M. Bonola
                                           Rome Tor Vergata University
                                                    A. Garcia-Martinez
                                                                  UC3M
                                                         February 2012
    Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)

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 an ND message is
 the owner of the address from which the message is sent and/or
 possesses a key that authorizes the node to act as a router, so that
 it is in possession of the private key or keys used to generate the
 digital signature on each message.  This means that the Proxy ND
 signaling performed by nodes that do not possess knowledge of the
 address owner's private key and/or knowledge of a router's key cannot
 be secured using SEND.  This document extends the current SEND
 specification in order to secure Proxy ND operation.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for examination, experimental implementation, and
 evaluation.
 This document defines an Experimental Protocol for the Internet
 community.  This document is a product of the Internet Engineering
 Task Force (IETF).  It represents the consensus of the IETF
 community.  It has received public review and has been approved for
 publication by the Internet Engineering Steering Group (IESG).  Not
 all documents approved by the IESG are a candidate for any level of
 Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6496.

Krishnan, et al. Experimental [Page 1] RFC 6496 Secure Proxy ND Support for SEND February 2012

Copyright Notice

 Copyright (c) 2012 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.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................2
 2. Requirements Notation ...........................................3
 3. Terminology .....................................................3
 4. Secure Proxy ND Overview ........................................4
 5. Secure Proxy ND Specification ...................................5
    5.1. Proxy Signature Option .....................................6
    5.2. Modified SEND Processing Rules .............................8
         5.2.1. Processing Rules for Senders ........................8
         5.2.2. Processing Rules for Receivers ......................9
    5.3. Proxying Link-Local Addresses .............................11
 6. Application Scenarios ..........................................11
    6.1. Scenario 1: Mobile IPv6 ...................................11
    6.2. Scenario 2: Proxy Mobile IPv6 .............................13
    6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy .............16
 7. Backward Compatibility with RFC 3971 Nodes and Non-SEND Nodes ..17
    7.1. Backward Compatibility with RFC 3971 Nodes ................17
    7.2. Backward Compatibility with Non-SEND Nodes ................18
 8. Security Considerations ........................................20
 9. IANA Considerations ............................................22
 10. Acknowledgements ..............................................22
 11. References ....................................................22
    11.1. Normative References .....................................22
    11.2. Informative References ...................................23

1. Introduction

 SEcure Neighbor Discovery (SEND) [RFC3971] specifies a method for
 securing Neighbor Discovery (ND) signaling [RFC4861] against specific
 threats [RFC3756].  As defined today, SEND assumes that the node
 sending an ND message is the owner of the address from which the
 message is sent and/or possesses a key that authorizes the node to

Krishnan, et al. Experimental [Page 2] RFC 6496 Secure Proxy ND Support for SEND February 2012

 act as a router, so that it is in possession of the private key or
 keys used to generate the digital signature on each message.  This
 means that the Proxy ND signaling performed by nodes that do not
 possess knowledge of the address owner's private key and/or knowledge
 of a router's 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 an extension as
 "Secure Proxy ND Support for SEND".

2. 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].

3. Terminology

 Secure ND Proxy
    A node acting on behalf of another node and authorized to secure a
    Neighbor Discovery Protocol (NDP) message without knowing the
    private key related to the source address of the other node or the
    key related to the router authorization.
 Proxied IPv6 address
    An IPv6 address that does not belong to the Secure ND Proxy and
    for which the Secure ND Proxy is performing advertisements.
 Non-SEND node
    An IPv6 node that does not implement the SEND [RFC3971]
    specification but uses the ND protocol defined in [RFC4861] and
    [RFC4862], without additional security.
 RFC 3971 node
    An IPv6 node that does not implement the specification defined in
    this document for Secure Proxy ND support but uses the SEND
    specification as defined in [RFC3971].
 Secure Proxy ND (SPND) node
    An IPv6 node that receives and validates messages according to the
    specification defined in this document for Secure Proxy ND
    support.

Krishnan, et al. Experimental [Page 3] RFC 6496 Secure Proxy ND Support for SEND February 2012

 Translated NDP message
    An NDP message issued by a Secure ND Proxy as a result of a
    received NDP message originated by the owner of the address or
    originated by another node acting on behalf of the owner of the
    address.
 Synthetic NDP message
    An NDP message issued by a Secure ND Proxy that is not the result
    of a received NDP message.

4. Secure Proxy ND Overview

 The original SEND specification [RFC3971] has implicitly assumed that
 only the node sending an ND message is the owner of the address from
 which the message is sent.  This assumption does not allow proxying
 of ND messages, since the advertiser is required to generate a valid
 RSA Signature option, which in turn requires possession of the
 public-private key pair that was used to generate a Cryptographically
 Generated Address (CGA), or that was associated to a router
 certificate.
 To be able to separate the roles of owner and advertiser, the
 following extensions to the SEND protocol are defined:
 o  A Secure Proxy ND certificate, which is a certificate authorizing
    an entity to act as an ND proxy.  It is an X.509v3 certificate in
    which the purpose for which the certificate is issued has been
    specified explicitly, as described in a companion document
    [RFC6494].  Briefly, Secure Proxy ND certificates include one or
    more KeyPurposeId values that can be used for authorizing proxies
    to sign Router Advertisement (RA) and Redirect messages, or to
    sign Neighbor Advertisement (NA), Neighbor Solicitation (NS), or
    Router Solicitation (RS) messages on behalf of other nodes.  The
    inclusion of this 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 through
    the Authorization Delegation Discovery process defined in
    [RFC3971].
 o  A new Neighbor Discovery option called the Proxy Signature (PS)
    option.  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

Krishnan, et al. Experimental [Page 4] RFC 6496 Secure Proxy ND Support for SEND February 2012

    Proxy ND certificate.  When an ND message contains a PS option, it
    MUST NOT contain CGA or RSA Signature options.  The PS option MUST
    be appended to any NDP message (NA, NS, RS, RA, and Redirect) to
    secure it.
 o  A modification of the SEND processing rules for all ND messages:
    NA, NS, RS, RA, and Redirect.  When any of these messages
    containing a PS option is validated, it is considered secure.
 These extensions are applied in the following way:
 o  A Secure ND Proxy that proxies ND messages on behalf of a node can
    use the PS option to protect the proxied messages.  This Secure ND
    Proxy becomes part of the trusted infrastructure just like a SEND
    router.
 o  The messages to be secured with the PS option are built according
    to [RFC4861] if they are synthesized by the Secure ND Proxy, or
    they result from the processing rules defined in [RFC4389] if they
    are translated ND messages.
 o  In order to allow nodes to successfully validate secured proxied
    messages, the nodes MUST be aware of the Secure Proxy ND
    certificate (in the format described in [RFC6494]) and MUST apply
    the modified processing rules specified in this document.  We call
    these 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] when they send ND messages.
 o  To allow SPND nodes to know the certification path required to
    validate the public key of the proxy, devices responding to CPS
    (Certification Path Solicitation) messages with CPA (Certification
    Path Advertisement) messages as defined in Section 6 of the SEND
    specification [RFC3971] are extended to support the certificate
    format specified in [RFC6494], and are configured with the
    appropriate certification path.

5. Secure Proxy ND Specification

 A Secure ND Proxy performs all the operations described in the SEND
 specification [RFC3971] with the addition of new processing rules to
 ensure that the receiving node can identify an authorized proxy
 generating a translated or synthetic SEND message for a proxied
 address.
 This is accomplished by signing the message with a private key of the
 authorized Secure ND Proxy.  The signature of the Secure ND Proxy is
 included in a new option called the PS option.  The signature is

Krishnan, et al. Experimental [Page 5] RFC 6496 Secure Proxy ND Support for SEND February 2012

 performed over all the Neighbor Discovery Protocol (NDP) options
 present in the message, and the PS option is appended as the last
 option in the message.

5.1. Proxy Signature Option

 The Proxy Signature option allows signatures based on public keys to
 be attached to NDP messages.  The format of the PS option is
 described in the following diagram:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |    Length     |          Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                          Key Hash                             |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       Digital Signature                       .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                           Padding                             .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      Figure 1: PS Option Layout
 Type
    32
 Length
    The length of the option (including the Type, Length, Reserved,
    Key Hash, Digital Signature, and Padding fields) in units of
    8 octets.

Krishnan, et al. Experimental [Page 6] RFC 6496 Secure Proxy ND Support for SEND February 2012

 Reserved
    A 16-bit field reserved for future use.  The value MUST be
    initialized to zero by the sender, and MUST be ignored by the
    receiver.
 Key Hash
    A 128-bit field containing the most significant (leftmost)
    128 bits of a SHA-1 [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
    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.

Krishnan, et al. Experimental [Page 7] RFC 6496 Secure Proxy ND Support for SEND February 2012

 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

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

5.2.1. Processing Rules for Senders

 A Secure ND Proxy MUST NOT use a key to sign NDP message types that
 do not correspond to the authorization granted to the considered key.
 NA, NS, and RS messages MUST be signed with a key corresponding to a
 Secure Proxy ND certificate with a KeyPurposeId value [RFC6494] of
 id-kp-sendProxiedOwner, and the source addresses of the messages MUST
 be encompassed in the prefix associated to the certificate.  RA and
 Redirect messages MUST be signed with a key corresponding to a Secure
 Proxy ND certificate with a KeyPurposeId value of
 id-kp-sendProxiedRouter.  The prefix included in the RA message for
 on-link determination and/or stateless address autoconfiguration, and
 the Target Address of the Redirect message, MUST be encompassed in
 the prefix associated to that certificate.
 A secured NDP message sent by a Secure ND Proxy for a proxied address
 MUST contain a PS option and MUST NOT contain either CGA or RSA
 Signature options.  Section 7 discusses in which cases an NDP message
 has to be secured in a scenario including non-SEND nodes.
 The input of this process is a message obtained in either of the
 following ways:
 a.  If the Secure ND Proxy generates synthetic SEND messages for a
     proxied address, the message MUST be constructed as described in
     the Neighbor Discovery for IP version 6 specification [RFC4861].
 b.  If the Secure ND Proxy translates secured messages, first the
     authenticity of the intercepted message MUST be verified.  If the
     intercepted message is a SEND message, it MUST be validated as
     specified in Section 5 of the SEND specification [RFC3971].  If
     the intercepted message contains a PS option, the authenticity of
     the message MUST be verified as detailed in Section 5.2.2 of this
     specification.  After validation, the CGA, RSA, or PS options of
     the original message MUST be removed.  Then, the message to be
     translated MUST be processed according to the ND Proxy
     specification [RFC4389].  In this way, it is determined whether

Krishnan, et al. Experimental [Page 8] RFC 6496 Secure Proxy ND Support for SEND February 2012

     the message received should be proxied or not; the proxy
     interface status is updated if needed, the outgoing interface is
     determined, the link-layer header and the link-layer address
     within the payload are modified if required, etc.
 A Secure ND Proxy then modifies the input message as follows:
 1.  Timestamp and Nonce options MUST be included according to the
     rules specified in SEND [RFC3971].  The value in the Timestamp
     option MUST be generated by the proxy.  If the proxy is
     translating a message that includes a nonce, the Nonce value in
     the proxied message MUST be the same as in the intercepted
     message.  If the proxy is synthesizing a solicitation message,
     the Nonce value MUST be generated by the proxy.  If the proxy is
     synthesizing an advertisement message, the Nonce value MUST
     correspond to the solicitation message to which the proxy is
     responding.
 2.  The Proxy Signature option MUST be added as the last option in
     the message.
 3.  The data MUST be 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 Signature option MUST be processed
 as specified below:
 1.  The receiver MUST ignore any RSA and CGA options, as well as any
     options that might come after the first PS option.  The options
     are ignored for both signature verification and NDP processing
     purposes.
 2.  The Key Hash field MUST indicate the use of a known public key.
     A valid certification path (see [RFC6494] Section 9) between the
     receiver's trust anchor and the sender's public key MUST be
     known.  The Secure Proxy ND X.509v3 certificate MUST contain an
     extended key usage extension including the appropriate
     KeyPurposeId value and prefix for the message to validate:
  • For RA messages, a KeyPurposeId value of

id-kp-sendProxiedRouter MUST exist for the certificate, and

        the prefix included in the RA message for on-link
        determination and/or stateless address autoconfiguration MUST
        be encompassed in the prefix associated to that certificate.

Krishnan, et al. Experimental [Page 9] RFC 6496 Secure Proxy ND Support for SEND February 2012

  • For Redirect messages, a KeyPurposeId value of

id-kp-sendProxiedRouter MUST exist for the certificate, and

        the prefix included in the Target Address of the Redirect
        message MUST be encompassed in the prefix associated to that
        certificate.
  • For NA, NS, and RS messages, a KeyPurposeId value of

id-kp-sendProxiedOwner MUST exist for the certificate, and the

        source addresses of the messages MUST be encompassed in the
        prefix associated to the certificate.
     If any of these tests fail, the verification fails.
 3.  The Digital Signature field MUST have correct encoding;
     otherwise, the verification of the message including the PS
     option fails.
 4.  The Digital Signature verification MUST show that the signature
     has been calculated as specified in Section 5.1; otherwise, the
     verification of the message including the PS option fails.
 5.  The Nonce option MUST be processed as specified in [RFC3971]
     Section 5.3.4, except for replacing 'RSA Signature option' with
     'PS option'; if these tests fail, the verification of the message
     including the PS option fails.
 6.  The Timestamp option MUST be processed as specified in [RFC3971]
     Section 5.3.4, except for replacing 'RSA Signature option' with
     'PS option'.  If these tests fail, the verification of the
     message including the PS option fails.  The receiver SHOULD store
     the peer-related timing information specified in [RFC3971]
     Sections 5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each
     different proxy (which could be identified by the different Key
     Hash values of the proxied message) and separately from the
     timing information associated to the IP address of a node for
     which the message is proxied.  In this way, a message received
     for the first time from a proxy (i.e., for which there is no
     information stored in the cache) for which the Timestamp option
     is checked SHOULD be checked as a message received from a new
     peer (as in [RFC3971] Section 5.3.4.2).
 7.  Messages with the Override bit [RFC4861] set MUST override an
     existing cache entry regardless of whether it was created as a
     result of an RSA Signature option or a PS option validation.
     When the Override bit is not set, the advertisement MUST NOT
     update a cached link-layer address created securely by means of
     RSA Signature option or PS option validation.

Krishnan, et al. Experimental [Page 10] RFC 6496 Secure Proxy ND Support for SEND February 2012

 Messages for which the verification fails MUST be silently discarded
 if the node has been configured to accept only secured ND messages.
 The messages MAY be accepted if the host has been configured to
 accept both secured and unsecured messages but MUST be treated as an
 unsecured message.

5.3. Proxying Link-Local Addresses

 SEND [RFC3971] relies on certificates to prove that routers are
 authorized to announce a certain prefix.  However, Neighbor Discovery
 [RFC4861] states that routers do not announce the link-local prefix
 (fe80::/64).  Hence, it is not required for a SEND certificate to
 hold an X.509 extension for IP addresses that authorizes the
 fe80::/64 prefix.  However, some Secure Proxy ND scenarios
 ([RFC4389], [RFC5213]) impose providing the proxying function for the
 link-local address of a node.  When Secure ND Proxy functionality for
 a link-local address is required, either a list of link-local
 addresses, or the fe80::/64 prefix MUST be explicitly authorized to
 be proxied in the corresponding certificate.

6. Application Scenarios

 In this section, we describe three different application scenarios
 for which Secure Proxy ND support for SEND can be applied.  Note that
 the particular way in which Secure Proxy ND support is applied (which
 ND messages are proxied, in which direction, how the interaction with
 non-SEND hosts and RFC 3971 hosts is handled, etc.) largely depends
 on the 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 translated from the
 messages received in other interfaces of the proxy.

6.1. Scenario 1: Mobile IPv6

 The description of the problems for deploying SEND in this scenario
 is presented in [RFC5909].
 The Mobile IPv6 (MIPv6) protocol [RFC6275] allows a 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).  When an MN
 attaches to a foreign network, all the packets sent to the MN's HoA
 by a Correspondent Node (CN) on the home link or a router are
 intercepted by the Home Agent (HA) on that home link, encapsulated,
 and tunneled to the MN's registered Care-of Address (CoA).
 To deploy Secure Proxy ND in this scenario, i.e., to secure the HA
 operation, a Secure Proxy ND certificate with a KeyPurposeId value of
 id-kp-sendProxiedOwner for the prefix of the home link is required.

Krishnan, et al. Experimental [Page 11] RFC 6496 Secure Proxy ND Support for SEND February 2012

 The Secure ND Proxy is configured with the private key associated to
 this certificate.  When a NS is intercepted by the HA on the home
 link, the HA checks whether the Target Address within the NS matches
 with any of the MN's Home Addresses in the binding cache, and if so,
 it replies with a Neighbor Advertisement (NA) constructed as
 described in [RFC4861], containing its own link-layer address (HA_LL)
 as the Target Link-Layer Address Option (TLLAO).  Then, a timestamp
 (generated by the proxy) and nonce (if appropriate, according to
 [RFC3971]) MUST be included.  Finally, a PS option signing the
 message MUST be included as the last option of the message.
    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              |                          |
      | [CGA]                     |                          |
      | RSA signature             |                          |
      |-------------------------->|                          |
      |                           |                          |
      | SRC = HA                  |                          |
      | DST = N                   |                          |
      | ICMPv6 NA                 |                          |
      | TARGET = MN               |                          |
      | TLLAO = HA_LL             |                          |
      | PS signature              |                          |
      |<--------------------------|                          |
      |                           |                          |
      | traffic                   |                          |
      | dest = MN HoA             |                          |
      |-------------------------->|                          |
      |                           |                          |
      |                           | tunneled traffic         |
      |                           | dest = MN CoA            |
      |                           |------------------------->|
      |                           |                          |
          Figure 2: Proxy ND Role of the Home Agent in MIPv6
 A node receiving the NA containing the PS option (e.g., the CN in the
 home link, or a router) MUST apply the rules defined in
 Section 5.2.2.  Note that in this case the Override bit of the NA
 message is used to control which messages should prevail on each

Krishnan, et al. Experimental [Page 12] RFC 6496 Secure Proxy ND Support for SEND February 2012

 case: the message generated by the proxy when the MN moves from the
 home network, or the MN if it comes back to the home link, as defined
 in the MIPv6 specification [RFC6275].

6.2. Scenario 2: Proxy Mobile IPv6

 Proxy Mobile IPv6 [RFC5213] is a network-based mobility management
 protocol that provides IP mobility management support for MNs without
 requiring that MNs be involved in the mobility-related signaling.
 The IP mobility management is totally hidden to the MN in a Proxy
 Mobile IPv6 domain, and it 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 sends a multicast
 Router Solicitation (RS).  The MAG on the new access link, upon
 detecting the MN's attachment, signals the LMA requesting an update
 of the binding state of the MN (by means of a Proxy Binding Update
 (PBU)).  Once the signaling is completed (it receives a Proxy Binding
 Ack (PBA)), the MAG replies to the MN with a Router Advertisement
 (RA) containing the home network prefix(es) that were assigned to
 that mobility session, making the MN believe it is still on the same
 link, so the IPv6 address reconfiguration procedure is not triggered
 (Figure 3).

Krishnan, et al. Experimental [Page 13] RFC 6496 Secure Proxy ND Support for SEND February 2012

           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  |                      |
            |            PS        |                      |
            |<---------------------|                      |
            |                      |                      |
            |                      |                      |
            |                      |                      |
              Figure 3: Mobile Node's Handover in PMIPv6
 To avoid potential link-local address collisions between the MAG and
 the MN after a handoff to a new link, the Proxy Mobile IPv6
 specification [RFC5213] requires that the MAG's link-local address on
 the link to which the MN is attached be generated by the LMA when the
 MN first attaches to a PMIPv6 domain, and 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 of
 that MN's session.

Krishnan, et al. Experimental [Page 14] RFC 6496 Secure Proxy ND Support for SEND February 2012

 The approach described above and the current SEND specification are
 incompatible, since sharing the same link-local address on different
 MAGs would require all MAGs of a PMIPv6 domain to construct the CGA
 and the RSA Signature option with the same public-private key pair,
 which is not an acceptable security policy.
 Using different public-private key pairs on different MAGs would mean
 that different MAGs use different CGAs as link-local addresses.
 Thus, the serving MAG's link-local address would change after each
 handoff of the MN, which is in contradiction with the way MAG link-
 local address assignment occurs in a PMIPv6 domain.
 To provide SEND protection, each MAG MUST be configured to act as a
 proxy by means of a certificate associated to the PMIPv6 domain,
 authorizing each MAG to securely proxy NA and RS messages by means of
 a KeyPurposeId value of id-kp-sendProxiedOwner.  In addition, the
 certificate MUST also authorize the MAG to advertise prefixes by
 associating to the same certificate a KeyPurposeId value of
 id-kp-sendProxiedRouter.  Note that the inclusion of multiple
 KeyPurposeId values is supported by [RFC6494].
 When a MAG replies to an RS with an RA, the source address MUST be
 equal to the MAG link-local address associated to the MN in this
 PMIPv6 domain, with its own link-layer address as the source link-
 layer address.  Then, a timestamp (generated by the proxy) and nonce
 (if appropriate, according to [RFC3971]) MUST be included.  Finally,
 a PS option signing the message MUST be included as the last option
 of the message.  This procedure is followed for any other ND message
 that could be generated by the MAG to the MN.
 A node receiving a message from the MAG containing the PS option MUST
 apply the processing rules defined in Section 5.2.2.  Note that
 unsolicited messages sent by the MAG should be validated by the host
 according to timestamp values specific to the MAG serving the link,
 not to any other MAG to which the host has been connected before in
 other links, according to processing step number 6 of Section 5.2.2.

Krishnan, et al. Experimental [Page 15] RFC 6496 Secure Proxy ND Support for SEND February 2012

6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy

 The problems for deploying SEND in this scenario are presented in
 [RFC5909].
       Link 1                                               Link 2
       Host A                   ND Proxy (P)                Host B
         |                          |                          |
         | SRC = A                  |                          |
         | DST = solicited_node (B) |                          |
         | ICMPv6 NS                |                          |
         | TARGET = B               |                          |
         | 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             |                          |
         |<-------------------------|                          |
         |                          |                          |
         Figure 4: RFC 4389 Neighbor Discovery Proxy Operation
 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 MUST parse any IPv6 packet it receives on a proxy
 interface to check whether it contains one of the following NDP
 messages: NS, NA, RS, RA, or Redirect.  The Secure ND Proxy MUST
 verify the authenticity of the received ND message, according to
 [RFC3971], or according to Section 5.2.2 if it contains a PS option.

Krishnan, et al. Experimental [Page 16] RFC 6496 Secure Proxy ND Support for SEND February 2012

 Then, after removing the CGA, RSA, or PS options, the message to be
 translated MUST be processed according to the ND Proxy specification
 [RFC4389].  This includes performing loop prevention checks,
 determining the outgoing interface for the proxied message, changing
 the source link-layer address to the address of the outgoing
 interface, changing source link-layer addresses contained in the
 payload (that is, in a Source Link-Layer Address Option (SLLAO) or a
 Target Link-Layer Address Option (TLLAO)), maintaining the
 destination link-layer address as the address in the neighbor entry
 corresponding to the destination IPv6 address, setting the P bit for
 proxied RA messages, etc.  Note that besides link-layer addresses and
 the P bit of a RA, no other field of the received message is changed
 when proxied by an [RFC4389] proxy.
 When any other IPv6 unicast packet is received on a proxy interface,
 if it is not locally destined, then it is forwarded unchanged (other
 than using a new link-layer header) to the proxy interface for which
 the next-hop address appears in the neighbor cache.  If no neighbor
 cache entry is present, the Secure ND Proxy SHOULD queue the packet
 and initiate a Neighbor Discovery signaling as if the NS message were
 locally generated.
 Note that to be able to sign any NS, NA, RS, RA, or Redirect message,
 the key used MUST correspond to a certificate with KeyPurposeId
 values of id-kp-sendProxiedOwner and id-kp-sendProxiedRouter.
 In order to deploy this scenario, nodes in proxied segments MUST know
 the certificate-authorizing proxy operation.  To do so, it could be
 required that at least one device per proxied segment (maybe the
 proxy itself) be configured to propagate the required certification
 path to authorize proxy operation by means of a CPS/CPA exchange.

7. Backward Compatibility with RFC 3971 Nodes and Non-SEND Nodes

 In this section, we discuss the interaction of Secure ND Proxies and
 SPND nodes with RFC 3971 nodes and non-SEND nodes.  As stated in
 [RFC3971], network operators may want to run a mixture of nodes
 accepting secured and unsecured NDP messages at the same time.
 Secure ND Proxies and SPND nodes SHOULD support the use of secured
 and unsecured NDP messages at the same time.

7.1. Backward Compatibility with RFC 3971 Nodes

 RFC 3971 nodes, i.e., SEND nodes not compliant with the modifications
 required in Section 5, cannot correctly interpret a PS option
 received in a proxied ND message.  These SEND nodes silently discard
 the PS option, as specified in [RFC4861] for any unknown option.  As

Krishnan, et al. Experimental [Page 17] RFC 6496 Secure Proxy ND Support for SEND February 2012

 a result, these messages will be treated as unsecured, as described
 in Section 8 ("Transitions Issues") of the SEND specification
 [RFC3971].
 When RFC 3971 nodes and SPND nodes exchange ND messages (without
 proxy intervention), in either direction, messages are generated
 according to the SEND specification [RFC3971], so these nodes
 interoperate seamlessly.
 In the scenarios in which the proxy translates ND messages, the
 messages to translate can either be originated in an RFC 3971 node or
 in an SPND node, without interoperability issues (note that the
 difference between RFC 3971 nodes and SPND nodes only affects the
 ability to process received NDP messages containing a PS option, not
 the way they generate messages secured by SEND).
 A configuration option MAY exist in a Secure ND Proxy to specify the
 RFC 3971 nodes to which it is connected, so that the proxied messages
 sent to these nodes are not processed according to the Secure Proxy
 ND specification, for performance reasons.

7.2. Backward Compatibility with Non-SEND Nodes

 Non-SEND nodes receiving NDP packets silently discard PS options, as
 specified in [RFC4861] for any unknown option.  Therefore, these
 nodes interpret messages proxied by a Secure ND Proxy as any other ND
 message.
 When non-SEND nodes and SPND nodes exchange ND messages (without
 proxy intervention), in either direction, the rules specified in
 Section 8 of [RFC3971] apply.
 A Secure ND Proxy SHOULD support the use of secured and unsecured NDP
 messages at the same time, although it MAY have a configuration that
 causes proxying to not be performed for unsecured NDP messages.  A
 Secure ND Proxy MAY also have a configuration option whereby it
 disables secure ND proxying completely.  This configuration SHOULD be
 switched off by default; that is, security is provided by default.
 In the following paragraphs, we discuss the recommended behavior of
 the Secure ND Proxy regarding the protection level to provide to
 proxied messages in a mixed scenario involving SPND/RFC 3971 nodes
 and non-SEND nodes.  In particular, two different situations occur,
 depending on whether the proxied nodes are RFC 3971 or SPND nodes, or
 non-SEND nodes.
 As a rule of thumb, if the proxied nodes can return to the link in
 which the proxy operates, the Secure ND Proxy MUST only generate PS
 options on behalf of nodes with SEND capabilities (i.e., those nodes

Krishnan, et al. Experimental [Page 18] RFC 6496 Secure Proxy ND Support for SEND February 2012

 that could use SEND to defend their messages if present on the same
 link as the proxy -- in other words, either RFC 3971 nodes or SPND
 nodes).  This is relevant to allow nodes to prefer secured
 information over an unsecured one, and to properly execute the
 Duplicate Address Detection (DAD) procedure, as specified in
 [RFC3971].  Therefore, in this case, the Secure ND Proxy MUST
 synthesize/translate messages containing the PS option for SPND and
 RFC 3971 hosts, and MUST NOT synthesize/translate messages containing
 the PS option for non-SEND nodes.  Note that ND advertisements in
 response to solicitations generated by a Secure ND Proxy must either
 be secured or not secured, according to the previous considerations
 (i.e., according to the nature of the proxied node), and not
 according to the secure or unsecure nature of the solicitation
 message.
 In order to apply this rule, the Secure ND Proxy needs to know the
 security capabilities of the proxied node.  The way this information
 is acquired depends on the application scenario, and it is discussed
 next:
 o  For scenarios in which ND messages are translated for nodes that
    can arrive to the link in which the proxy operates, the rule can
    be easily applied: only for messages validated in the Secure ND
    Proxy according to the SEND specification [RFC3971], or according
    to Section 5.2.2 of this specification for messages containing a
    PS option (which means that another proxy previously checked that
    the original message was secured), the message MUST be proxied
    securely by the inclusion of a PS option.  Unsecured ND messages
    could be proxied if unsecured operation is enabled in the proxy,
    but the message generated by the Secure ND Proxy for the received
    message MUST NOT include a PS option.
 o  For scenarios in which ND messages are synthesized on behalf of
    remote nodes, different considerations should be made according to
    the particular application scenario.
  • For MIPv6, if the MN can return to the home link, it is

required that the proxy know whether the node could use SEND to

       defend its address or not.  A HA including the PS option for
       proxying a non-SEND MN would make ND messages sent by the proxy
       be more preferred than an ND message of the non-SEND MN when
       the MN returns to the home link (even if the proxied messages
       have the Override bit set to 1).  Not using the PS option for
       an RFC 3971 or SPND MN would make the address in the home link
       more vulnerable when the MN is away than when it is in the home
       link, defeating the purpose of the Secure Proxy ND mechanism.
       Therefore, in this case, the HA MUST know the SEND capabilities

Krishnan, et al. Experimental [Page 19] RFC 6496 Secure Proxy ND Support for SEND February 2012

       of the MN, MUST use the PS option if the MN is an SPND or
       RFC 3971 host, and MUST NOT use the PS option for non-SEND
       hosts.
  • For the Proxy Mobile IPv6 scenario, a node moving from a link

in which the PS option has been used to protect a link-layer

       address to a link in which ND messages are not protected by
       SEND would prevent the MN from acquiring the new information
       until the cached information expires.  However, in this case,
       it is reasonable to consider that all MAGs provide the same
       security for protecting ND messages, and that either all MAGs
       or no MAGs will behave as a Secure ND Proxy, so configuration
       is expected to be easier.
 A configuration option MAY exist in a Secure ND Proxy to specify the
 non-SEND nodes to which it is connected, so that the proxied messages
 sent to these nodes are not processed according to the Secure Proxy
 ND specification, for performance reasons.

8. Security Considerations

 The mechanism described in this document introduces a new PS option
 allowing a Secure ND Proxy to synthesize or translate a SEND message
 for a proxied address, to redirect traffic for given target
 addresses, or to advertise prefix information by means of RA
 messages.  An SPND node only accepts such a message if it includes a
 valid PS option generated by a properly authorized Secure ND Proxy
 (with a certificate containing a KeyPurposeId with value
 id-kp-sendProxiedOwner for protecting NA, NS, and RS messages, or
 containing a KeyPurposeId value of id-kp-sendProxiedRouter for
 protecting RA and Redirect messages).  Such a message has protection
 against the threats presented in Section 9 of [RFC3971] equivalent to
 a message signed with an RSA Signature option.
 The security of proxied ND messages not including a PS option is the
 same as an unsecured ND message.  The security of a proxied ND
 message received by a non-SEND host or RFC 3971 host is the same as
 an unsecured ND message.
 When a message including a PS option is received by an SPND node, any
 CGA or RSA options also included in the message are removed and the
 remaining message further processed.  Although properly formed
 proxied messages MUST NOT include PS and CGA/RSA options at the same
 time, discarding them if they appear does not affect security.  If
 the PS option is validated, then the information included in the
 message has been validly generated by a proxy, and should be honored
 (remember that anti-replay protection is provided by means of Nonce
 and Timestamp options).  If the PS option is not validated, then it

Krishnan, et al. Experimental [Page 20] RFC 6496 Secure Proxy ND Support for SEND February 2012

 is treated as an unsecured message.  In any case, there is no gain
 for an attacker from appending false or old CGA/RSA information to a
 message secured by a Secure ND Proxy.
 A compromised Secure ND Proxy provisioned with an authorization
 certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is
 able, like a compromised router, to siphon off traffic from the host,
 or mount a man-in-the-middle attack, for hosts communicating to off-
 link hosts.  A compromised Secure ND Proxy provisioned with an
 authorization certificate with a KeyPurposeId value of
 id-kp-sendProxiedOwner can siphon off traffic or mount a man-in-the-
 middle attack for communication between on-link hosts, even if the
 hosts use SEND.  Note that different application scenarios may
 require one type of authorization, the other, or both.  To minimize
 security risks, authorization capabilities MUST NOT exceed the ones
 strictly required by the application scenario to be deployed.
 The messages for which a Secure ND Proxy performs its function and
 the link for which this function is performed MUST be configured
 appropriately for each proxy and scenario.  This configuration is
 especially relevant if Secure Proxy ND is used for translating ND
 messages from one link to another.
 Section 7 discusses the security considerations resulting from the
 decision to append or omit the PS option, depending on the SEND-
 awareness of the proxied nodes.
 Protection against replay attacks from unsolicited messages such as
 NA, RA, and Redirects is provided by means of the Timestamp option.
 When Secure ND Proxy is used, each host, and each proxy acting on
 behalf of that host, are considered to be different peers in terms of
 timestamp verification.  Since the information provided by the host
 and a proxy, including different link-layer addresses, may be
 different, a replay attack could affect the operation of a third
 node: replaying messages issued by a host that is no longer in the
 link can prevent the use of a proxy, and replaying messages of a
 proxy when the host is back in the link can prevent communication
 with the host.  This kind of attack can be performed until the
 timestamp of the peer (either the host or a proxy) is no longer valid
 for the receiver.  The window of vulnerability is in general larger
 for the first message received from a new peer than for subsequent
 messages received from the same peer (see [RFC3971]).  A more
 detailed analysis of the possible attacks related to the Timestamp
 option is described in Section 6.3 of [RFC5909].

Krishnan, et al. Experimental [Page 21] RFC 6496 Secure Proxy ND Support for SEND February 2012

9. IANA Considerations

 IANA has allocated the following a new IPv6 Neighbor Discovery Option
 type for the PS option, as 32.  The value has been allocated from the
 namespace specified in the IANA "IPv6 Neighbor Discovery Option
 Formats" registry located at
 http://www.iana.org/assignments/icmpv6-parameters.
 IANA has also allocated the following new 128-bit value under the
 "Cryptographically Generated Addresses (CGA) Message Type Name Space"
 registry [RFC3972]:
    0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.

10. Acknowledgements

 The text has benefited from feedback provided by Jari Arkko, Jean-
 Michel Combes, Roque Gagliano, Tony Cheneau, Marcelo Bagnulo, Alexey
 Melnikov, Sandra Murphy, and Sean Turner.
 The work of Alberto Garcia-Martinez was supported in part by the T2C2
 project (TIN2008-06739-C04-01, granted by the Spanish Science and
 Innovation Ministry).

11. References

11.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3971]  Arkko, J., Ed., 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.

Krishnan, et al. Experimental [Page 22] RFC 6496 Secure Proxy ND Support for SEND February 2012

 [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
            Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
            RFC 5213, August 2008.
 [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
            Support in IPv6", RFC 6275, July 2011.
 [RFC6494]  Gagliano, R., Krishnan, S., and A. Kukec, "Certificate
            Profile and Certificate Management for SEcure Neighbor
            Discovery (SEND)", RFC 6494, February 2012.
 [RSA]      RSA Laboratories, "PKCS #1 v2.1: RSA Cryptography
            Standard", June 2002.
 [SHA1]     National Institute of Standards and Technology, "Secure
            Hash Standard", FIPS PUB 180-1 , April 1995.

11.2. Informative References

 [RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
            Neighbor Discovery (ND) Trust Models and Threats",
            RFC 3756, May 2004.
 [RFC5909]  Combes, J-M., Krishnan, S., and G. Daley, "Securing
            Neighbor Discovery Proxy: Problem Statement", RFC 5909,
            July 2010.

Krishnan, et al. Experimental [Page 23] RFC 6496 Secure Proxy ND Support for SEND February 2012

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
 Juniper Networks
 1094 North Mathilda Avenue
 Sunnyvale, CA  94089
 USA
 Phone: +1 408 936 0385
 EMail: julien.ietf@gmail.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/

Krishnan, et al. Experimental [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6496.txt · Last modified: 2012/02/04 00:51 (external edit)