NETLMM WG A. Muhanna Internet-Draft M. Khalil Intended status: Standards Track Nortel Expires: December 26, 2008 S. Gundavelli K. Leung Cisco Systems June 24, 2008 GRE Key Option for Proxy Mobile IPv6 draft-muhanna-netlmm-grekey-option-03.txt 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 on December 26, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Proxy Mobile IPv6 base specification defined in [1] allows the mobile node's IPv4 and IPv6 traffic between the local mobility anchor and the mobile access gateway to be tunneled using IPv6, IPv4 or IPv4-UDP encapsulation headers. These encapsulation modes do not offer semantics for the tunnel end-points to expose a service Muhanna, et al. Expires December 26, 2008 [Page 1] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 identifier that can be used to identify traffic for a certain classification, such as for supporting mobile nodes that are using overlapping private IPv4 addressing. The extensions defined in this document allow the mobile access gateway and the local mobility anchor to negotiate GRE encapsulation mode and along with the GRE symmetric key or asymmetric keys for marking the flows, so that differential processing can be applied by the tunnel peers over those flows. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 4. Local Mobility Anchor Considerations . . . . . . . . . . . . . 5 4.1. GRE Tunneling and Encapsulation Procedures . . . . . . . . 5 4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 6 5. Mobile Access Gateway Considerations . . . . . . . . . . . . . 6 5.1. Extensions to the Conceptual Data Structure . . . . . . . 7 5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 7 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. GRE Key Identifier Option . . . . . . . . . . . . . . . . 8 6.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Muhanna, et al. Expires December 26, 2008 [Page 2] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 1. Introduction The base Proxy Mobile IPv6 specification allows the use of IPv6, IPv4 or IPv4-UDP encapsulation modes for the tunneled traffic between the local mobility anchor and the mobile access gateway. There are scenarios where these encapsulation modes are not sufficient and there is a need for an encapsulation mode with richer semantics. The Generic Routing Encapsulation [2] and coupled with the Key and Sequence Number extension [3], has the required semantics for use in Proxy Mobile IPv6. This document defines extensions to the base Proxy Mobile IPv6 specification, for allowing the mobile access gateway and the local mobility anchor to negotiate GRE encapsulation mode and for exchanging the GRE asymmetric key(s) that can be used for marking the downlink and uplink traffics. 2. Conventions used in this document 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 [4]. All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 specification [5] and Proxy Mobile IPv6 specification [1]. 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 referenced as 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 referenced as reverse direction traffic. 3. Protocol Overview Using the extension defined in this specification, the mobile access Muhanna, et al. Expires December 26, 2008 [Page 3] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 gateway and the local mobility anchor can negotiate GRE encapsulation mode along with the GRE keys for marking the downlink and uplink traffics. Once the GRE keys have been negotiated 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 use of GRE keys for supporting the scenario where overlapping IPv4 private address allocation is in use. +------------+ | 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 Muhanna, et al. Expires December 26, 2008 [Page 4] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 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 agree upon downlink and uplink keys for identifying the flows belonging to each mobile node. The local mobility anchor and the mobile access gateway will be able to distinguish these flows based on the key present in the GRE header of the tunneled packet, and can route them accordingly. 4. Local Mobility Anchor Considerations 4.1. GRE Tunneling and Encapsulation Procedures As per the base Proxy Mobile IPv6 specification, the tunnel transport between the mobile access gateway and the local mobility anchor can be IPv6, IPv4 or IPv4-UDP. When GRE tunneling is negotiated as per this specification, the semantics related to the tunnel transport is not impacted, but an additional GRE header is added above the payload packet as indicated below. +---------------------------+ | Delivery Header | | | | IPv4, IPv4-UDP or IPv6 | +---------------------------+ | | | GRE Header with | | Key, Sequence Number Ext | +---------------------------+ +---------------------------+ | | | | | Payload Packet | ====> | Payload Packet | | (IPv4 or IPv6) | | | +---------------------------+ +---------------------------+ Figure 2: GRE Encapsulation Muhanna, et al. Expires December 26, 2008 [Page 5] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 4.2. Operational Summary o Upon receiving a Proxy Binding Update message with the GRE Key Identifier Option, the local mobility anchor, if it does not support GRE encapsulation mode, MUST send the Proxy Binding Acknowledgement message to the mobile access gateway with the status code TBA1, (GRE Encapsulation not supported). o If the received Proxy Binding Update message does not contain the GRE Key Identifier Option, and if the local mobility anchor determines that GRE encapsulation is required, e.g., overlapping IPv4 private addressing is in use, the local mobility anchor MUST reject the request, and MUST send the Proxy Binding Acknowledgement message to the mobile access gateway with the status code TBA2, indicating that GRE encapsulation is required. o Upon receiving a Proxy Binding Update message with the GRE Key Identifier Option, the local mobility anchor MUST include the GRE Key Identifier option as per this document when responding with a successful Proxy Binding Acknowledgement message to the mobile access gateway. o If the GRE tunneling is negotiated between the local mobility anchor and the mobile access gateway, every packet that is destined to the mobile node through the local mobility anchor MUST be encapsulated with a GRE header using the negotiated downlink GRE key and the chosen transport header such as IPv4, IPv4-UDP or IPv6, just as per the base Proxy Mobile IPv6 specification. 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 lookup the mobile node's home gateway address for forwarding the packet after removing the encapsulation headers. 5. Mobile Access Gateway Considerations For requesting the GRE Tunneling support, the mobile access gateway MUST include the GRE Key Identifier Option in the Proxy Binding Update message sent to the local mobility anchor. Additionally, the mobile access gateway MUST include the downlink key in the GRE key Identifier Option. In the successful Proxy Binding Update, the LMA must send two GRE keys in the GRE Key Identifier option, with the first key being the downlink key which was sent by the mobile access gateway and the second is the uplink key. In this case, the GRE Key Identifier option length MUST be set to 10. Muhanna, et al. Expires December 26, 2008 [Page 6] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 5.1. Extensions to the Conceptual Data Structure Every mobile access gateway maintains a Binding Update List entry for each currently attached mobile node, as explained in Section 6.1 of the base Proxy Mobile IPv6 specification [1]. The Binding Update List entry is a conceptual data structure, described in Section 11.1 of the Mobile IPv6 base specification [5]. For supporting this specification, the conceptual Binding Update List entry data structure must be extended with the following two new additional fields related to bi-directional GRE Key identifiers used for tagging the mobile node's tunneled traffic. o The Uplink GRE Key Identifier used in the GRE encapsulation header of the tunneled packet from the mobile access gateway to the local mobility anchor and that is originating from the mobile node. This GRE Key identifier is obtained from the GRE Key Identifier Option present in the received Proxy Binding Acknowledgement message sent by the local mobility anchor as specified in this document. o The Downlink GRE Key Identifier used in the GRE encapsulation header of the tunneled packet from the local mobility anchor to the mobile access gateway and that is destined to the mobile node. This GRE Key identifier is generated by the mobile access gateway and communicated to the local mobility anchor in the GRE key Identifier option in the proxy binding update message. 5.2. Operational Summary o If IPv4 Home Address support is enabled for the mobile node and if the IPv4 Home Address Option is included in the Proxy Binding Update message that is sent by the mobile access gateway to the mobile node's local mobility anchor, the GRE Key Identifier Option SHOULD be included in the Proxy Binding Update message. The MAG MUST include the downlink key in the GRE Key Identifier Option, the local mobility anchor must use this key to identify the mobile node's traffic encapsulated in a GRE header as specified in the GRE specification [2] and using the GRE Key and Sequence Number extension [3] with the assigned GRE key. o After receiving a Proxy Binding Acknowledgment message with the status code indicating the acceptance of the Proxy Binding Update message and with the GRE Key Identifier Option, the mobile access gateway MUST use GRE encapsulation and the assigned uplink GRE Key for tunneling all the traffic originating from the mobile node. Muhanna, et al. Expires December 26, 2008 [Page 7] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 o For a given mobile node, if the local mobility anchor rejects the Proxy Binding Update by sending the Proxy Binding Acknowledgement with the status code TBA1 (GRE Encapsulation not supported), the mobile access gateway MUST NOT include the GRE Key Identifier Option in the subsequent Proxy Binding Update messages that are sent to that Local Mobility Anchor. o If the mobile access gateway has sent a Proxy Binding Update message without the GRE Key Identifier Option, but the received Proxy Binding Acknowledgement has the Status Code TBA2, indicating that the GRE encapsulation is required, the mobile access gateway SHOULD resend the Proxy Binding Update message with the GRE Key Identifier Option. o If the mobile access gateway has sent a Proxy Binding Update message with the GRE Key Identifier Option, but the received Proxy Binding Acknowledgement has the Status Code success without the GRE Key Identifier option, indicating that the GRE encapsulation is not required for this mobile node, the mobile access gateway must not use GRE encapsulation for this Mobile node. o If the GRE tunneling is negotiated between the local mobility anchor and the mobile access gateway, every packet originating from the mobile node MUST be encapsulated with a GRE header using the uplink GRE key and the chosen transport header such as IPv4, IPv4-UDP or IPv6, just as per the base Proxy Mobile IPv6 specification. o One receiving a packet from the tunnel with the GRE encapsulation header, the mobile access gateway MUST use the GRE Key to lookup the mobile node's layer-2 address and use it for forwarding the packet after removing the encapsulation headers. 6. Message Formats This section defines extensions to the Mobile IPv6 [5] protocol messages for supporting this specification. 6.1. GRE Key Identifier Option A new option, the GRE Key Identifier Option, is defined for use in the Proxy Binding Update and Acknowledgment messages exchanged between the mobile access gateway and the local mobility anchor. This option can be used for exchanging the GRE key(s) to be applied by the peer on all GRE encapsulated packets over either IPv4 or IPv6 transport. Muhanna, et al. Expires December 26, 2008 [Page 8] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: GRE Key Identifier Option Type Length Eight-bit unsigned integer indicating the length in octets of the option, excluding the type and length fields. This field is set to a value of 6 or 10. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. GRE Key Identifier four-byte field containing the Downlink GRE Key Identifier. or eight-byte field containing the Downlink and Uplink GRE keys, respectively. 6.2. Status Codes Proxy Binding Acknowledgment Status Values The following status code values are defined for using them in the Binding Acknowledgment message when using Proxy Mobile IPv6 protocol. The value allocation for this usage needs to be approved by the IANA and must be updated in the IANA registry. TBA1: GRE Encapsulation not required. Muhanna, et al. Expires December 26, 2008 [Page 9] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 TBA2: GRE Encapsulation and GRE Key Identifier option required. Status values less than 128 indicate that the Binding Update was processed successfully by the receiving nodes. Values greater than 128 indicate that the Binding Update was rejected by the Home Agent. 7. IANA Considerations This document defines a new Option, the GRE Key Option, described in Section 3. 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 [5]. This document also defines two new Binding Acknowledgement status codes TBA1 and TBA2 as described in Section 6.2. This document requests that these two codes be allocated from the "Status Codes" registry of the Mobility IPv6 Parameters located at http://www.iana.org/assignments/mobility-parameters and that the numeric value of these codes be greater than 128. 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 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. 9. Acknowledgements The authors would like to thank Allesio Casati, Barney Barownsky, Mark Grayson and Parviz Yegani for their input on the need for this option. The authors would like to thank Curtis Provost, Irfan Ali, Julien Langanier, Jouni Korhonen, Suresh Krishnan, Kuntal Chowdhury, and Vijay Devarapalli for their review and comments. 10. References Muhanna, et al. Expires December 26, 2008 [Page 10] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 10.1. Normative References [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-18 (work in progress), May 2008. [2] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [3] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [7] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [8] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03 (work in progress), May 2008. 10.2. Informative References [9] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [11] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [12] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Muhanna, et al. Expires December 26, 2008 [Page 11] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 Authors' Addresses Ahmad Muhanna Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Mohamed Khalil Nortel Networks 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 December 26, 2008 [Page 12] Internet-Draft GRE Key Option for Proxy Mobile IPv6 June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Muhanna, et al. Expires December 26, 2008 [Page 13]