Network Working Group P. Yegani Internet-Draft G. Dommety Intended status: Standards Track Cisco Systems Expires:SeptemberDecember 3, 2007 A. Lior Bridgewater Systems K. Chowdhury J. Navali Starent NetworksMarch 2,June 2007 GRE Key Extension for Mobile IPv4draft-yegani-gre-key-extension-02draft-yegani-gre-key-extension-03 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 onSeptemberDecember 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. GRE-Key Extension . . . . . . . . . . . . . . . . . . . . . . . 3 4. Operation and Use of the GRE-Key Extension . . . . . . . . . . 3 4.1. Foreign Agent Requirements for GRE Tunneling Support . . . 3 4.2. Home Agent Requirements for GRE Tunneling Support . . . . . 4 4.3. Mobile Node Requirements for GRE Tunneling Support . . . . 5 5. GRE Key Extension and Tunneling Procedures . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 9. Normative references . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 9 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. 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 theGRE-KEYGRE 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 the 'G' bit set but without the GRE Key Extension, it SHALL send an RRP with code 'Poorly Formed Request (0xY2)'. 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. If the HA receives the GRE Key Extension in a Registration Request and recognizes the GRE Key Extension as well as supports GRE encapsulation,itthe 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. 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 ... 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 Cisco Systems Inc. California U.S.A Phone: +1 408-83-5729 Email: pyegani@cisco.com Gopal Dommety Cisco Systems Inc. 170 West Tasman Dr. San Jose, California 95134 U.S.A Phone: +1 408 525 1404 Email: gdommety@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 Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USA Phone: +1 214 550 1416 Email: kchowdhury@starentnetworks.com Jay Navali Starent Networks 30 International Place Tewksbury, MA 01876 USA Phone: +1 978 851 1141 Email: jnavali@starentnetworks.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).