Network Working Group Y. Wu Internet-Draft ZTE USA Intended status: Standards Track H. Deng Expires: May 14, 2008 China Mobile November 11, 2007 A method of using IPsec to setup GRE tunnel draft-wu-l3vpn-ipsec-gre-00 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 May 14, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Wu & Deng Expires May 14, 2008 [Page 1] Internet-Draft IPsec GRE Tunnel November 2007 Abstract Provider-Provisioned Virtual Private Network (PPVPN)[RFC4110] uses some forms of IP tunneling schemes to tunnel VPN traffic. Possible candidates are GRE, IP-in-IP, IPsec and MPLS. The candidate tunneling scheme should provide multiplexing capability, as well as dynamic tunnel setup and maintenance capability. Additionally, security is required if the VPN traffic is traversing public Internet or across Service Provider domains. Each above candidate by itself is not sufficient to meet all these requirements. This document describes a method of using IPsec signaling (i.e, IKE) to setup a GRE tunnel. This IPsec GRE tunnel may be used as the candidate tunneling scheme in PPVPN network or remote access compulsory VPN. This document also defines a way how the Key field in GRE header is used in IPsec GRE tunnel setup. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Using the GRE Key field as IPsec PORT selector . . . . . . . . 4 3. IPsec GRE tunnel setup . . . . . . . . . . . . . . . . . . . . 6 4. IPsec GRE tunnel release . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Wu & Deng Expires May 14, 2008 [Page 2] Internet-Draft IPsec GRE Tunnel November 2007 1. Introduction PPVPN describes four possible candidates for IP tunneling schemes: GRE, IP-in-IP, IPsec and MPLS. Among these four candidates, GRE and IP-in-IP do not have their own signaling protocols and rely on some other mechanisms for tunnel setup and multiplexing value distribution. IPsec can be used in either tunnel mode or transport mode. The tunnel mode is essentially a IP-in-IP tunnel without multiplexing capability unless multiple IP tunnel endpoint addresses are used. The transport mode is usually used with other in-IP tunneling schemes to provide multiplexing capability. The examples of such in-IP tunneling schemes are GRE-in-IP and MPLS-in-IP. This document introduces a method of using IPsec signaling to setup a GRE tunnel. An IPsec GRE tunnel can be used for example, in PPVPN or remote access compulsory VPN, to provide support for multiplexing of different VPNs and support for differentiated security protection. This document only specifies the mechanism for IPsec GRE tunnel setup. The mechanisms for VPN autodiscovery, VPN context distribution and VPN context binding with the IPsec GRE tunnel are outside the scope of this document. Wu & Deng Expires May 14, 2008 [Page 3] Internet-Draft IPsec GRE Tunnel November 2007 2. Using the GRE Key field as IPsec PORT selector GRE is described in [RFC2784] and [RFC2890]. It allows an arbitrary protocol to be encapsulated in another arbitrary network layer protocol. It provides an optional multiplexing capability when multiple flows of user data traffic need to be encapsulated between the same tunnel endpoints. The multiplexing capability is provided by the GRE Key field. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GRE Key field contains a four octect number used to identify a particular flow. However, how the GRE Key is allocated and communicated to the other end of the tunnel is left unspecified. When used with IPsec for GRE tunnel establishment, this four octect Key field is partitioned into two parts, with the most significant two octects containing the source GRE half key and the least significant two octects containing the destination GRE helf key. Other bits are set as follow: 'C' = 0, to indicate there is no checksum 'K' = 1, to indicate there is Key field present 'S' = 0/1, to indicate the Sequence field is present or not The 'S' bit is set depending on the particular payload type the GRE is carrying. For example, if the payload is PPP frame, the 'S' bit may be set and Sequence Number field is included, such that the receiver can resequence the packets if they have been re-ordered by the IP transport network. Wu & Deng Expires May 14, 2008 [Page 4] Internet-Draft IPsec GRE Tunnel November 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| |1|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source GRE Half Key | Destination GRE Half Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This definition of the GRE Key field usage is analogous to the TCP/ UDP port definition. As such, the source GRE half key and destination GRE half key can be used in IKEv2 Traffic Selector negotiation. The source GRE half key is allocated by the sender while the destination GRE half key is allocated by the receiver. The combined source and destination half keys identify a unique GRE tunnel between two tunnel endpoints. How is the 16 bit GRE half key allocated within each node is undefined in this document. It is more of an implementation issue. The 16 bit GRE half key can be globally unique within the node, or unique within communications to a particular peer IP address or unique within communications to a particular peer IP address plus peer GRE half key. As long as the receiver of the GRE packet can unambiguously identify a particular GRE tunnel, any GRE half key allocation method can be used. There are various scenarios as to where the two GRE tunnel endpoints and IPsec endpoints are located, but this document only defines the behavior when GRE tunnel endpoints are identical to the IPsec endpoints and the IPsec is in transport mode. The behavior of other possible scenarios are undefined in this document. Wu & Deng Expires May 14, 2008 [Page 5] Internet-Draft IPsec GRE Tunnel November 2007 3. IPsec GRE tunnel setup During IPsec transport mode SA setup, the initiator SHALL allocate a 16 bit GRE half key, to be included in TSi as local "port" selector value. Both the start port and end port are set to this 16 bit GRE half key. The TSr SHALL use a value "ANY". Upon receiving the CHILD_SA request, the responder SHALL allocate its own 16 bit GRE half key, to be included in TSr as the "port" selector value. The TSi value is returned unchanged. After the successful CHILD_SA exchange and traffic selector negotiation, a GRE tunnel is effectively in place. When sending traffic, the sender includes its 16 bit GRE half key in the Source GRE Half Key field and the receiver's 16 bit GRE half key in the Destination GRE Half Key field. On the reverse direction, these two fields are swapped. Wu & Deng Expires May 14, 2008 [Page 6] Internet-Draft IPsec GRE Tunnel November 2007 4. IPsec GRE tunnel release The GRE tunnel release on one side is communicated to the other side by IPsec SA Delete payload. Wu & Deng Expires May 14, 2008 [Page 7] Internet-Draft IPsec GRE Tunnel November 2007 5. Security Considerations IPsec GRE tunnel inherits all the security features of IPsec, which includes mutual authentication, encrytion, integrity and anti-replay protection. Additionally, with the port selector capability on GRE Key, the IPsec GRE tunnel can provide better access control and differentiated security protection than an ordinary GRE tunnel protected by IPsec transport mode. Wu & Deng Expires May 14, 2008 [Page 8] Internet-Draft IPsec GRE Tunnel November 2007 6. Conclusion This document describes a method of using IPsec signaling (i.e, IKE) to setup a GRE tunnel. This IPsec GRE tunnel may be used as the candidate tunneling scheme in PPVPN or remote access compulsory VPN. This document also defines a way how the Key field in GRE header is used in IPsec GRE tunnel setup. Wu & Deng Expires May 14, 2008 [Page 9] Internet-Draft IPsec GRE Tunnel November 2007 7. Normative References [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. [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005. Wu & Deng Expires May 14, 2008 [Page 10] Internet-Draft IPsec GRE Tunnel November 2007 Authors' Addresses Yingzhe Wu ZTE USA 10105 Pacific Heights Blvd, Suite 250 San Diego, CA 92121 USA Email: yingzhe.wu@zteusa.com Hui Deng China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: denghui@chinamobile.com Wu & Deng Expires May 14, 2008 [Page 11] Internet-Draft IPsec GRE Tunnel November 2007 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). Wu & Deng Expires May 14, 2008 [Page 12]