Network Working Group                                          P. Yegani
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                                K. Leung
Expires: December 3, 2010                                  Cisco Systems
                                                                 A. Lior
                                                     Bridgewater Systems
                                                            K. Chowdhury
                                                               J. Navali
                                                           Cisco Systems
                                                            June 1, 2010


                   GRE Key Extension for Mobile IPv4
                draft-ietf-mip4-gre-key-extension-00.txt

Abstract

   The GRE specification contains a Key field, which MAY contain a value
   that is used to identify a particular GRE data stream.  This
   specification defines a new Mobile IP extension that is used to
   exchange the value to be used in the GRE Key field.  This extension
   further allows the Mobility Agents to setup the necessary protocol
   interfaces prior to receiving the mobile's traffic.  The new
   extension option allows a foreign agent to request GRE tunneling
   without disturbing the Home Agent behavior specified for Mobile Ipv4.
   GRE tunneling provides an advantage that allows operator's private
   home networks to be overlaid and allows the HA to provide overlapping
   home addresses to different subscribers.  When the tuple < Care of
   Address, Home Address and Home Agent Address > is the same across
   multiple subscriber sessions, GRE tunneling will provide a means for
   the FA and HA to identify data streams for the individual sessions
   based on the GRE key.  In the absence of this key identifier, the
   data streams cannot be distinguished from each other, a significant
   drawback when using IP-in-IP tunneling.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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



Yegani, et al.          Expires December 3, 2010                [Page 1]


Internet-Draft            GRE Key Ext. for MIP4                June 2010


   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 3, 2010.

Copyright Notice

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

   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.





















Yegani, et al.          Expires December 3, 2010                [Page 2]


Internet-Draft            GRE Key Ext. for MIP4                June 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  GRE-Key Extension . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Operation and Use of the GRE-Key Extension  . . . . . . . . . . 4
     4.1.  Foreign Agent Requirements for GRE Tunneling Support  . . . 4
     4.2.  Home Agent Requirements for GRE Tunneling Support . . . . . 5
     4.3.  Mobile Node Requirements for GRE Tunneling Support  . . . . 6
   5.  GRE Key Extension and Tunneling Procedures  . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Normative references  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8




































Yegani, et al.          Expires December 3, 2010                [Page 3]


Internet-Draft            GRE Key Ext. for MIP4                June 2010


1.  Introduction

   This document specifies a new extension for use by Foreign Agents
   operating Mobile IP for IPv4.  The new extension option allows a
   foreign agent to request GRE tunneling without disturbing the Home
   Agent behavior specified for Mobile IPv4 [RFC3344].  This extension
   contains the GRE key and other necessary information required for
   establishing a GRE tunnel between the FA and the HA.

   GRE tunneling provides an advantage that allows operator's private
   home networks to be overlaid and it allows the HA to provide
   overlapping home addresses to different subscribers.  When the tuple
   < Care of Address, Home Address and Home Agent Address > is the same
   across multiple subscriber sessions, GRE tunneling will provide a
   means for the FA and the HA to identify data streams for the
   individual sessions based on the GRE key.  In the absence of this key
   identifier, the data streams cannot be distinguished from each other,
   a significant drawback when using IP-in-IP tunneling.


2.  Terminology

   The keywords "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].  Other
   terminology is used as already defined in [RFC3344].


3.  GRE-Key Extension

   The format of the GRE-Key Extension conforms to the Extension format
   specified for Mobile IPv4 [RFC3344].  This extension option is used
   by the Foreign Agent to supply GRE key and other necessary
   information to the Home Agent to establish a GRE tunnel between the
   FA and the HA.


4.  Operation and Use of the GRE-Key Extension

4.1.  Foreign Agent Requirements for GRE Tunneling Support

   The FA MUST support IP-in-IP tunneling of datagrams for Mobile IPv4
   [RFC3344].  The FA may support GRE tunneling that can be used, for
   example, to allow for overlapping private home IP addresses
   [X.S0011-D].  If the FA is capable of supporting GRE encapsulation,
   it should set the 'G' bit in the Flags field in the Agent
   Advertisement message sent to the MN during the Mobile IP session
   establishment.



Yegani, et al.          Expires December 3, 2010                [Page 4]


Internet-Draft            GRE Key Ext. for MIP4                June 2010


   If the MN does not set the 'G' bit, the FA MAY fall back to using IP-
   in-IP encapsulation for the session per [RFC3344].

   If the MN does not set the 'G' bit, and the local policy allows the
   FA to override the 'G' bit setting received from the MS, the FA MUST
   include the GRE-Key Extension as defined in this memo in the
   Registration Request message to request GRE encapsulation for the
   session.

   If the FA does not support GRE encapsulation, the FA MUST reset the
   'G' bit in the Agent Advertisement message.  In this case, if the MN
   sets the 'G' bit in the Registration Request message, the FA returns
   a Registration Reply message to the MN with code 'Requested
   Encapsulation Unavailable' (0x48) per [RFC3344].

   If the FA allows GRE encapsulation, and either the MN requested GRE
   encapsulation or local policy dictates using GRE encapsulation for
   the session, the FA MUST include the GRE Key in the GRE Key Extension
   in all Mobile IP Registration Requests (including initial, renewal
   and de-registration requests) before forwarding the request to the
   HA.  The FA may include a GRE key of value zero in the GRE Key
   Extension to signal that the HA assign GRE keys in both directions.
   The GRE key assignment in the FA and the HA is outside the scope of
   this memo.

   The GRE Key Extension SHALL follow the format defined in [RFC3344].
   This extension SHALL be added after the MN-HA and MN-FA Challenge and
   MN-AAA extensions (if any) and before the FA-HA Auth extension (if
   any).

4.2.  Home Agent Requirements for GRE Tunneling Support

   The HA MUST follow the procedures specified in RFC 3344 in processing
   this extension in Registration Request messages.  If the HA receives
   the GRE Key Extension in a Registration Request and does not
   recognize GRE Key Extension, it MUST send an RRP with code 'Unknown
   Extension (0xY1)' per [RFC3344].

   If the HA receives the GRE Key Extension in a Registration Request
   and recognizes the GRE Key Extension but is not configured to support
   GRE encapsulation, it MUST send an RRP with code 'Requested
   Encapsulati on Unavailable (0xYY)'.

   If the HA receives a Registration Request with a GRE Key Extension
   but without the 'G' bit set, the HA SHOULD treat this as if 'G' bit
   is set in the Registration Request i.e., the presence of GRE Key
   Extension indicates a request for GRE encapsulation.




Yegani, et al.          Expires December 3, 2010                [Page 5]


Internet-Draft            GRE Key Ext. for MIP4                June 2010


   If the HA receives the GRE Key Extension in a Registration Request
   and recognizes the GRE Key Extension as well as supports GRE
   encapsulation, the following procedures should apply:

   The HA SHOULD accept the RRQ and send a RRP with code 'Accepted (0)'.
   The HA MUST assign a GRE key and include the GRE Key Extension in the
   RRP before sending it to the FA.  The HA MUST include the GRE Key
   Extension in all RRPs in response to any RRQ that included GRE Key
   Extension, when a GRE key is available for the registration.

   If the HA receives the GRE Key Extension in the initial Registration
   Request and recognizes the GRE Key Extension carrying a GRE key value
   of zero, it SHOULD accept the RRQ and send a RRP with code 'Accepted
   (0)'.  The HA MUST assign GRE keys for both directions and include
   these keys in the GRE Key Extension in the RRP before sending it to
   the FA.  The HA MUST include the GRE Key Extension in the RRP in
   response to the initial RRQ that included GRE Key Extension, when a
   GRE key is available for the registration.

4.3.  Mobile Node Requirements for GRE Tunneling Support

   If the MN is capable of supporting GRE encapsulation, it SHOULD set
   the 'G' bit in the Flags field in the Registration Request per
   [RFC3344].


5.  GRE Key Extension and Tunneling Procedures

   GRE tunneling support for Mobile IP will permit asymmetric GRE keying
   i.e., the FA assigns a GRE key for use in encapsulated traffic and
   the HA can assign its own GRE key.  Once the GRE keys have been
   exchanged, the FA uses the HA-assigned key in the encapsulating GRE
   header for reverse tunneling and the HA uses the FA-assigned key in
   the encapsulating GRE header.

   The format of the GRE Key Extension is as shown below.

   The GRE Key extension MAY be included in Registration Requests
   [RFC3344], whose 'G' bit is enabled.  The GRE Key extension is used
   to inform the recipient of the Mobile IP request of the value to be
   used in GRE's Key field.










Yegani, et al.          Expires December 3, 2010                [Page 6]


Internet-Draft            GRE Key Ext. for MIP4                June 2010


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

       Type

          TBD (non-skippable) [2]

       Length

          6

       Reserved

          This field MUST be set to zero (0).

       Key Identifier

          This is a four octet value assigned in the Registration and
          inserted in every GRE frame.


                        Figure 1: GRE Key Extension


6.  IANA Considerations

   The GRE Key extension defined in this memo is as defined in
   [RFC3344].  IANA should assign a value for this Extension.


7.  Security Considerations

   This specification does not introduce any new security
   considerations, beyond those described in [RFC3344]


8.  Acknowledgements

   Thanks to Jun Wang, Gopal Dommety and Sri Gundavelli for their
   helpful comments, offline discussions and reviewing the initial
   draft.





Yegani, et al.          Expires December 3, 2010                [Page 7]


Internet-Draft            GRE Key Ext. for MIP4                June 2010


9.  Normative references

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

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

   [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
              August 2002.


Authors' Addresses

   Parviz Yegani
   Juniper Netowrks
   1194 North Mathilda Ave.
   Sunnyvale, California  94089
   U.S.A

   Phone: +1 408-759-1973
   Email: pyegani@juniper.net


   Kent Leung
   Cisco Systems Incorporated
   170 West Tasman Drive
   San Jose, California  95134
   U.S.A

   Phone: +1 408 526 5030
   Email: kleung@cisco.com


   Avi Lior
   Bridgewater Systems Corporation
   303 Terry Fox Drive
   Ottawa, Ontario  K2K 3J1
   Canada

   Phone: +1 613-591-6655
   Email: avi@bridgewatersystems.com









Yegani, et al.          Expires December 3, 2010                [Page 8]


Internet-Draft            GRE Key Ext. for MIP4                June 2010


   Kuntal Chowdhury
   Cisco Systems Incorporated
   170 West Tasman Drive
   San Jose, California  95134
   U.S.A

   Email: kchowdhu@cisco.com


   Jay Navali
   Cisco Systems Incorporated
   170 West Tasman Drive
   San Jose, California  95134
   U.S.A

   Email: jnavali@cisco.com



































Yegani, et al.          Expires December 3, 2010                [Page 9]