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

Versions: (draft-muhanna-netlmm-grekey-option) 00 01 02 03 04 05 06 07 08 09 RFC 5845

Network Working Group                                         A. Muhanna
Internet-Draft                                                 M. Khalil
Intended status: Standards Track                                  Nortel
Expires: August 1, 2009                                    S. Gundavelli
                                                                K. Leung
                                                           Cisco Systems
                                                        January 28, 2009


                  GRE Key Option for Proxy Mobile IPv6
                 draft-ietf-netlmm-grekey-option-03.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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

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

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

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

   This Internet-Draft will expire on August 1, 2009.

Copyright Notice

   Copyright (c) 2009 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.





Muhanna, et al.          Expires August 1, 2009                 [Page 1]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


Abstract

   This document defines a new Mobility Option for allowing the mobile
   access gateway and the local mobility anchor to negotiate GRE
   encapsulation mode and exchange the downlink and uplink GRE keys
   which are used for marking the downlink and uplink traffic that
   belong to a specific mobile node session or a specific flow.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions & Terminology  . . . . . . . . . . . . . . . . . .  3
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  GRE Encapsulation and Key Exchange . . . . . . . . . . . . . .  4
     3.1.  GRE Encapsulation Overview . . . . . . . . . . . . . . . .  4
     3.2.  GRE Encapsulation Support  . . . . . . . . . . . . . . . .  6
     3.3.  GRE Key Exchange Mechanism . . . . . . . . . . . . . . . .  6
       3.3.1.  Initial GRE Key Exchange . . . . . . . . . . . . . . .  6
       3.3.2.  GRE Key Exchange During Binding Re-registration  . . .  6
   4.  Mobile Access Gateway Considerations . . . . . . . . . . . . .  7
     4.1.  Extensions to the Conceptual Data Structure  . . . . . . .  7
     4.2.  Operational Summary  . . . . . . . . . . . . . . . . . . .  8
   5.  Local Mobility Anchor Considerations . . . . . . . . . . . . .  9
     5.1.  Extensions to the Binding Cache Entry  . . . . . . . . . .  9
     5.2.  Operational Summary  . . . . . . . . . . . . . . . . . . . 10
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  Status Codes . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
















Muhanna, et al.          Expires August 1, 2009                 [Page 2]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


1.  Introduction

   The base Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile
   IPv6 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4
   encapsulation modes [RFC2473][RFC2003] for the tunneled traffic
   between the local mobility anchor and the mobile access gateway.
   There are scenarios where these encapsulation modes are not
   sufficient to uniquely identify the destination of packets of a
   specific flow.  Thus, there is a need for an encapsulation mode with
   richer semantics.  The Generic Routing Encapsulation [RFC2784] and
   the Key extension as defined in [RFC2890], has the required semantics
   to allow such distinction for use in Proxy Mobile IPv6.

   This document defines the GRE Key option to be used for the
   negotiation of GRE encapsulation mode and the exchange of the uplink
   and downlink GRE keys.  The negotiated downlink and uplink GRE keys
   can be used for marking the downlink and uplink traffic for a
   specific mobility session or a specific flow.


2.  Conventions & Terminology

2.1.  Conventions

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

2.2.  Terminology

   All the general mobility related terminology and abbreviations are to
   be interpreted as defined in Mobile IPv6 specification [RFC3775] and
   Proxy Mobile IPv6 specification [RFC5213].  The following terms are
   used in this document.

   Downlink Traffic

      The traffic in the tunnel between the local mobility anchor and
      the mobile access gateway, heading towards the mobile access
      gateway and tunneled at the local mobility anchor.  This traffic
      is also called forward direction traffic.

   Uplink Traffic

      The traffic in the tunnel between the mobile access gateway and
      the local mobility anchor, heading towards the local mobility
      anchor and tunneled at the mobile access gateway.  This traffic is
      also called reverse direction traffic.



Muhanna, et al.          Expires August 1, 2009                 [Page 3]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


   Downlink GRE Key

      The GRE key is assigned by the mobile access gateway and used by
      the local mobility anchor to mark the downlink traffic which
      belongs to a specific mobility session or flow as described in
      this document.

   Uplink GRE Key

      The GRE key is assigned by the local mobility anchor and used by
      the mobile access gateway to mark the uplink traffic which belongs
      to a specific mobility session or flow as described in this
      document.


3.  GRE Encapsulation and Key Exchange

3.1.  GRE Encapsulation Overview

   Using the GRE Key option defined in this specification, the mobile
   access gateway and the local mobility anchor can negotiate GRE
   encapsulation mode and exchange the GRE keys for marking the downlink
   and uplink traffic.

   Once the GRE keys have been exchanged between the mobile access
   gateway and the local mobility anchor, the mobile access gateway will
   use the uplink GRE key that is assigned by the local mobility anchor
   in the GRE encapsulation header of the uplink payload packet.
   Similarly, the local mobility anchor will use the downlink GRE key as
   negotiated with the mobile access gateway in the GRE encapsulation
   header of the downlink payload packet.

   The following illustration explains the use of GRE encapsulation mode
   and the GRE keys for supporting the usecase where overlapping IPv4
   private address [RFC1918] allocation is in use.
















Muhanna, et al.          Expires August 1, 2009                 [Page 4]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


                                                          +------------+
                                                          | Operator-A |
                                                          |            |
                                                          | 10.x.0.0/16|
                                                          +------------+
                                                                   /
        +------+                                      +------+    /
        |      |      ==========================      |      |   /
 MN-1---|      |    /                            \    |      |  / Key-1
        |  M   |   / ---Flows with GRE Key-1 ---- \   |  L   | / Traffic
 MN-2---|  A   |--|                                |--|  M   |-
        |  G   |   \ ---Flows with GRE Key-2 ---- /   |  A   | \ Key-2
 MN-3---|      |    \                            /    |      |  \Traffic
        |      |      ==========================      |      |   \
 MN-4---|      |       Proxy Mobile IPv6 Tunnel       |      |    \
        +------+                                      +------+     \
                                                                    \
                   Operator-C: Access Network             +------------+
                                                          | Operator-B |
                                                          |            |
                                                          | 10.x.0.0/16|
                                                          +------------+



             Figure 1: Overlapping IPv4 Private Address Space



   Figure 1 illustrates a local mobility anchor providing mobility
   service to mobile nodes that are from different operators and are
   assigned IPv4 addresses from overlapping private address space.  In
   this scenario, the mobile access gateway and the local mobility
   anchor must be able distinguish the flows belonging to a given
   operator from the flows belonging to some other operator.

   The mobile nodes, MN-1 and MN-2 are visiting from Operator-A, and
   mobile nodes, MN-3 and MN-4 are visiting from Operator-B.  The mobile
   access gateway and the local mobility anchor exchange a specific pair
   of downlink and uplink GRE keys and save them as part of the mobile
   node binding to be used for identifying the flows belonging to each
   mobile node.

   The LMA and the MAG will be able to distinguish each mobile node
   flow(s) based on the GRE key present in the GRE header of the
   tunneled payload packet, and route them accordingly.





Muhanna, et al.          Expires August 1, 2009                 [Page 5]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


3.2.  GRE Encapsulation Support

   To request GRE encapsulation support, the mobile access gateway MUST
   include the GRE Key option in the Proxy Binding Update message sent
   to the local mobility anchor.  In case, the mobile access gateway
   wants to use GRE encapsulation without the GRE keys, it MUST NOT
   include the GRE Key Identifier in the option.

   If the local mobility anchor supports GRE encapsulation and the Proxy
   Binding Update processing is successful, the LMA sends a Proxy
   Binding Acknowledgement with the GRE Key option.  If GRE
   encapsulation is being used without the GRE keys, the LMA MUST NOT
   include the GRE Key Identifier in the GRE option.

3.3.  GRE Key Exchange Mechanism

   The following subsections describe how the mobile access gateway and
   the local mobility anchor exchange downlink and uplink GRE keys using
   proxy mobile IPv6 registration procedure.

3.3.1.  Initial GRE Key Exchange

   When the mobile access gateway determines, based on, e.g., private
   IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA
   peer agreement, that GRE encapsulation is needed and GRE keys are
   required, the mobile access gateway MUST include the GRE Key option
   in the initial Proxy Binding Update message sent to the local
   mobility anchor.  The mobile access gateway MUST include the downlink
   GRE key in the GRE Key Identifier field of the GRE Key option.

   After successfully processing the initial Proxy Binding Update and
   accepting the downlink GRE key, the LMA MUST include the GRE Key
   option with the uplink GRE key in the GRE Key Identifier field when
   sending a successful Proxy Binding Acknowledgement to the MAG.

3.3.2.  GRE Key Exchange During Binding Re-registration

   If the MAG has successfully negotiated and exchanged the initial GRE
   keys with the LMA for a specific binding, the MAG SHOULD NOT include
   the GRE Key option with the downlink GRE key in the Proxy Binding
   Update which is used for requesting a Binding Lifetime Extension.

   However, during inter-MAG handoff and if the new mobile access
   gateway determines, based on, e.g., private IPv4 address support, the
   MAG local policy, the MAG-LMA peer agreement, or an indication during
   the handoff process, that GRE encapsulation and GRE key exchange is
   required, the new mobile access gateway MUST include the GRE key
   option with the downlink GRE key in the Proxy Binding Update which is



Muhanna, et al.          Expires August 1, 2009                 [Page 6]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


   used for requesting an after handoff Binding Lifetime extension.  In
   this case, the new MAG may either pick a new downlink GRE key or use
   the downlink GRE key that was used by the previous MAG for the same
   binding.  For the new MAG to know the downlink GRE key used by the
   previous MAG, it may require transfer of context from the previous
   MAG to the new MAG during a handoff.  Such mechanisms are out-of-
   scope for this document.

   If the LMA successfully processes a handoff-triggered Binding
   Lifetime Extension Proxy Binding Update message which contains a GRE
   key option with a downlink GRE key included, the LMA MUST return the
   same uplink GRE key that was exchanged with the previous MAG and is
   saved in the respected Binding Cache Entry (BCE).

   If the LMA receives handoff-triggered Binding Lifetime Extension
   Proxy Binding Update message without the GRE key option for a BCE
   that is using GRE keys and GRE encapsulation, the LMA MUST reject the
   Proxy Binding Update by sending a Proxy Binding Acknowledgement
   message with the status field is set to <GRE KEY OPTION REQUIRED> as
   defined in Section 6.2.  If the LMA is preconfigured to use a
   different mechanism other than GRE encapsulation with the MAG which
   sent the handoff-triggered Binding Lifetime Extension Proxy Binding
   Update, the LMA MAY accept the PBU and if it is successfully
   processed, the LMA returns a successful PBA without the GRE Key
   option.  In this case, mapping between the current GRE keys and the
   other mechanism identifiers or labels is outside the scope of this
   specification.

   Typically, the MAG does not include the GRE Key Option in a Proxy
   Binding Update message sent to refresh an existing binding.  However,
   if the LMA receives a Proxy Binding Update from the current MAG to
   extend the existing binding, and the Proxy Binding Update messages
   contains the GRE Key option and the downlink GRE Key identifier, it
   MUST NOT reject the Proxy Binding Update message.  In this case, the
   LMA processes the Proxy Binding Update normally and if the included
   downlink GRE key is different than the one saved in the respected
   BCE, the LMA MUST update the BCE with the new downlink GRE key.


4.  Mobile Access Gateway Considerations

4.1.  Extensions to the Conceptual Data Structure

   Every mobile access gateway maintains a Binding Update List (BUL)
   entry for each currently attached mobile node, as explained in
   Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213].  To
   support this specification, the conceptual Binding Update List entry
   data structure must be extended with the following three new



Muhanna, et al.          Expires August 1, 2009                 [Page 7]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


   additional fields.

   o  A flag indicating whether GRE encapsulation is enabled for the
      mobile node's traffic flows.

   o  The downlink GRE key used in the GRE encapsulation header of the
      tunneled payload packet from the local mobility anchor to the
      mobile access gateway that is destined to the mobile node.  This
      GRE key is generated by the MAG and communicated to the LMA in the
      GRE Key option in the Proxy Binding Update message.

   o  The uplink GRE key used in the GRE encapsulation header of the
      tunneled payload packet from the mobile access gateway to the
      local mobility anchor that is originating from the mobile node.
      This GRE key is obtained from the GRE Key Identifier field of the
      GRE Key option present in the received Proxy Binding
      Acknowledgement message sent by the LMA as specified in this
      document.

4.2.  Operational Summary

   o  If the MAG determines that GRE encapsulation and GRE key is
      required, the MAG MUST include the GRE Key option with the
      downlink GRE key in the GRE Key Identifier field in the Proxy
      Binding Update message that is sent by the mobile access gateway
      to the local mobility anchor.

   o  After receiving a successful Proxy Binding Acknowledgment message
      with the GRE Key option which includes the uplink GRE key, the
      mobile access gateway MUST update the related three fields in the
      mobile node Binding Update List entry described in Section 4.1.
      Additionally, the MAG MUST use the assigned uplink GRE Key for
      tunneling all the traffic originating from the mobile node before
      forwarding the tunneled traffic to the LMA.

   o  If the mobile access gateway included the GRE Key option in the
      Proxy Binding Update for a specific mobile node and the local
      mobility anchor accepts the Proxy Binding Update by sending a
      Proxy Binding Acknowledgement with a success status code (less
      than 128) other than <GRE KEY OPTION NOT REQUIRED>, but without
      the GRE Key option, then the mobile access gateway MUST consider
      that the local mobility anchor does not support GRE Key option as
      per this specification.  The mobile access gateway SHOULD NOT
      include the GRE Key option in any subsequent Proxy Binding Update
      message that is sent to that LMA.






Muhanna, et al.          Expires August 1, 2009                 [Page 8]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


   o  If the mobile access gateway sent a Proxy Binding Update message
      without the GRE Key option, but the received Proxy Binding
      Acknowledgement has the Status Code <GRE KEY OPTION REQUIRED>,
      indicating that the GRE encapsulation and GRE key is required, the
      mobile access gateway SHOULD resend the Proxy Binding Update
      message with the GRE Key option.  If the MAG does not support the
      GRE Key option, the MAG MAY log the event and possibly raise an
      alarm to indicate a possible misconfiguration.

   o  If the mobile access gateway sent a Proxy Binding Update message
      with the GRE Key option and the downlink GRE key included and
      received a successful Proxy Binding Acknowledgement message with a
      status code <GRE KEY OPTION NOT REQUIRED>, the mobile access
      gateway MUST consider that GRE encapsulation and GRE keys is not
      required for this specific binding.  The MAG follows the Proxy
      Mobile IPv6 specification [RFC5213] for the handling of uplink and
      downlink traffic for this mobile node binding and MUST NOT include
      the GRE Key option in any subsequent Proxy Binding Update message
      for this specific mobile node that are sent to that LMA.

   o  If the MAG sent a re-registration Proxy Binding Update message
      without the GRE Key option, but received a successful Proxy
      Binding Acknowledgement which includes the GRE Key option with the
      uplink GRE key, the MAG MUST compare the received uplink GRE key
      with the one saved in the respected Binding Update List entry and
      update it if the received uplink GRE key is different.

   o  If the MAG has successfully negotiated and exchanged the initial
      GRE keys with the LMA for a specific binding, the MAG SHOULD NOT
      include the GRE Key option in the de-registration Proxy Binding
      Update.

   o  On receiving a packet from the tunnel with the GRE encapsulation
      header, the mobile access gateway MUST use the GRE Key to
      determine the necessary special processing for the data packet,
      e.g., lookup the mobile node's layer-2 address, determine any
      special processing or treatment for the data packet flow, then
      remove the encapsulation header before forwarding the packet.


5.  Local Mobility Anchor Considerations

5.1.  Extensions to the Binding Cache Entry

   When the local mobility anchor and the mobile access gateway
   successfully negotiates GRE encapsulation and exchange downlink and
   uplink GRE keys, the local mobility anchor MUST maintain the downlink
   and uplink GRE keys as part of the mobile node BCE.  This requires



Muhanna, et al.          Expires August 1, 2009                 [Page 9]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


   that the BCE described in section 5.1 of the Proxy Mobile IPv6 base
   specification [RFC5213] to be extended.  To support this
   specification, the BCE must be extended with the following three
   additional fields.

   o  A flag indicating whether GRE encapsulation is enabled for the
      mobile node's traffic flows.

   o  The downlink GRE Key, assigned by the MAG and used in the GRE
      encapsulation header of the tunneled payload packet from the local
      mobility anchor to the mobile access gateway.

   o  The Uplink GRE Key, assigned by the LMA and used in the GRE
      encapsulation header of the tunneled payload packet from the
      mobile access gateway to the local mobility anchor.

5.2.  Operational Summary

   o  After successfully processing a Proxy Binding Update message with
      the GRE Key option which includes a downlink GRE key in the GRE
      Key Identifier field for Initial GRE Key exchange as in
      Section 3.3.1, the local mobility anchor MUST include the GRE Key
      option with the uplink GRE key in the GRE Key Identifier field
      when responding with a successful Proxy Binding Acknowledgement
      message.

   o  If the GRE tunneling is negotiated and the downlink and uplink GRE
      keys have been exchanged between the mobile access gateway and the
      local mobility anchor for a specific binding, the local mobility
      anchor MUST use the negotiated downlink GRE key in the GRE header
      of every packet that is destined to the mobile node of this
      specific binding over the GRE tunnel to the mobile access gateway.

   o  If the received Proxy Binding Update message does not contain the
      GRE Key option, and if the local mobility anchor determines that
      GRE encapsulation and GRE key is required, e.g., overlapping IPv4
      private addressing is in use, LMA local policy or LMA-MAG peer
      policy, the local mobility anchor MUST reject the request and send
      the Proxy Binding Acknowledgement message to the mobile access
      gateway with the status code <GRE KEY OPTION REQUIRED> as defined
      in Section 6.2, indicating that GRE encapsulation and GRE key is
      required.

   o  If after receiving Proxy Binding Update message with the GRE Key
      option and successfully processes the Proxy Binding Update, the
      local mobility anchor determines that GRE encapsulation and key
      exchange is not required for this specific binding, e.g., private
      IPv4 addressing is not in use, the LMA MUST send a Proxy Binding



Muhanna, et al.          Expires August 1, 2009                [Page 10]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


      Acknowledgement message to the MAG with the status code <GRE KEY
      OPTION NOT REQUIRED>.  The local mobility anchor MUST NOT include
      the GRE Key option in that Proxy Binding Acknowledgement.

   o  If the local mobility anchor successfully processes a de-
      registration Proxy Binding Update message which contains a GRE Key
      option with a downlink GRE key included, the LMA follows the same
      de-registration process as per the base Proxy Mobile IPv6
      specification [RFC5213] to clean the binding cache entry and all
      associated resources including the downlink and uplink GRE keys.

   o  On receiving a packet from the tunnel with the GRE encapsulation
      header, the local mobility anchor MUST use the GRE Key present in
      the GRE extension header to determine the necessary special
      processing for the data packet, e.g., lookup the mobile node's
      home gateway address, determine any special processing or
      treatment for the data packet flow, then remove the encapsulation
      header before forwarding the packet.


6.  Message Formats

   This section defines an extension to the Mobile IPv6 [RFC3775]
   protocol messages.  The use of GRE Key option for supporting GRE
   tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in
   this document.

6.1.  GRE Key Option

   A new mobility option, the GRE Key option, is defined for use in the
   Proxy Binding Update and Proxy Binding Acknowledgment messages
   exchanged between the mobile access gateway and the local mobility
   anchor.  This option can be used for negotiating GRE encapsulation
   mode and exchanging the downlink and uplink GRE keys that can be used
   by the peers in all GRE encapsulated packets for marking that
   specific mobile node's data flow.

   The alignment requirement for this option is 4n.


       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      GRE Key Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Muhanna, et al.          Expires August 1, 2009                [Page 11]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


                         Figure 2: GRE Key Option

   Type

      <IANA>

   Length

      8-bit unsigned integer indicating the length in octets of the
      option, excluding the type and length fields.  If the Length field
      is set to 2, it indicates that the GRE key is not being carried in
      the option.  If the length field is set to a value of 6, it means
      that either the downlink or the uplink GRE key is carried.

   Reserved

      These fields are unused.  They MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   GRE Key Identifier

      32-bit field containing the downlink or the uplink GRE key.  This
      field is present in the GRE Key option only if the GRE keys are
      being exchanged using the Proxy Binding Update and Proxy Binding
      Acknowledgement messages.


6.2.  Status Codes

   The following status code values are defined for use in the Binding
   Acknowledgment message when using Proxy Mobile IPv6.

   GRE KEY OPTION NOT REQUIRED (TBD less than 128)

      When the local mobility anchor receives a Proxy Binding Update
      with the GRE Key option while the GRE encapsulation is not
      required for this specific mobile node, the LMA uses this code to
      indicate to the mobile access gateway that the Proxy Binding
      Update has been processed successfully but GRE Encapsulation and
      GRE Key is not required.

   GRE KEY OPTION REQUIRED (TBD more than 128)

      When the local mobility anchor receives a Proxy Binding Update
      without the GRE Key option while the GRE encapsulation is required
      for this specific mobile node, the local mobility anchor uses this
      code to reject the Proxy Binding Update and indicate to the mobile
      access gateway that GRE Encapsulation and Keys is required.



Muhanna, et al.          Expires August 1, 2009                [Page 12]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


7.  IANA Considerations

   This document defines a new Mobility Option, the GRE Key Option,
   described in Section 6.1.  This option is carried in the Mobility
   Header.  The type value for this option needs to be assigned from the
   same numbering space as allocated for the other mobility options
   defined in the Mobile IPv6 specification [RFC3775].

   This document also defines two new Binding Acknowledgement status
   codes as described in Section 6.2 and requests that these two codes
   be allocated with numeric values as specified in Section 6.2 from the
   "Status Codes" registry of the Mobility IPv6 Parameters located at
   http://www.iana.org/assignments/mobility-parameters.


8.  Security Considerations

   The GRE Key Option, defined in this document, that can be carried in
   Proxy Binding Update and Proxy Binding Acknowledgement messages,
   reveals the group affiliation of a mobile node identified by its NAI
   or an IP address.  It may help an attacker in targeting flows
   belonging to a specific group.  This vulnerability can be prevented,
   by enabling confidentiality protection on the Proxy Binding Update
   and Proxy Binding Acknowledgement messages where the presence of the
   NAI and GRE Key Options establish a mobile node's relation to a
   specific group.  This vulnerability can also be avoided by enabling
   confidentiality protection on all the tunneled data packets between
   the mobile access gateway and the local mobility anchor, for hiding
   all the markings.

   In Proxy Mobile IPv6 [RFC5213], the use of IPsec for protecting a
   mobile node's data traffic is optional.  However, if IPsec ESP is
   used to protect the mobile node's tunneled data traffic where GRE
   encapsulation is used, GRE over IPsec is RECOMMENDED.


9.  Acknowledgements

   The authors would like to thank Alessio Casati, Barney Barnowski,
   Mark Grayson and Parviz Yegani for their input on the need for this
   option.  The authors would like to thank Charlie Perkins, Curtis
   Provost, Irfan Ali, Jouni Korhonen, Julien Langanier, Kuntal
   Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review
   and comments.







Muhanna, et al.          Expires August 1, 2009                [Page 13]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


10.  Normative References

   [ID-PMIP6-IPv4]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
              (work in progress), January 2009.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.

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

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.

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

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



Authors' Addresses

   Ahmad Muhanna
   Nortel
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Email: amuhanna@nortel.com







Muhanna, et al.          Expires August 1, 2009                [Page 14]

Internet-Draft       GRE Key Option for Proxy MIPv6         January 2009


   Mohamed Khalil
   Nortel
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Email: mkhalil@nortel.com


   Sri Gundavelli
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com


   Kent Leung
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: kleung@cisco.com


























Muhanna, et al.          Expires August 1, 2009                [Page 15]


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