One document matched: draft-wu-l3vpn-ipsec-gre-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 20:20:58 |