Internet Draft                                       A. Khetan
Document: draft-khetan-sp-greipsec-00.txt              C. Wang
Expires: July 2002                                  M. Beadles
January 2002                                         L. French
                                                   SmartPipes
                                                     E. Vyncke
                                                 Cisco Systems



Use of GRE for routing support in IPSec VPNs



Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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.


Abstract

When IPSec tunneling is used for VPN connections, transporting routing
protocols across the encrypted tunnels becomes challenging. This
document outlines the use of GRE encapsulation in conjunction with
IPSec transport mode to support transport of dynamic routing protocols
across an IPSec encrypted tunnel. Some usage scenarios are also
addressed in this document.


Status of this Memo     1
Abstract        1
1.0 Introduction        2
2 Requirements for IPSec VPNs   2
2.1 Routing requirements        2
2.2 Ease of adding a new IP network     3
3.0 Routing Support via GRE     3
3.1 GRE Encapsulation with IPSec        3
3.2 GRE Implementation - Tunnel Termination Point       4
4.1 Performance Impact  5
4.2 Fragmentation and Reassembly        5
4.3 IPSec VPN enhancements      5
4.3.1 Resilient VPN Design      5
4.3.2 Multi-protocol transport  5
4.3.3 Multicast 5
4.3.4 SPD and SAD scalability   6
5.0 Security Issues     6
6.0 Summary for Sub-IP Area     6
6.1 Summary     6
6.2 Where does it fit in the Picture of the Sub-IP Work?        6
6.3 Why is it targeted at this WG?      6
6.4 Justification       7
7.0 Reference   7
Author's Addresses      8


1.0 Introduction

IPSec based VPNs have become a common way for service providers to
offer VPN services. When IPSec tunneling is used for VPN connections,
transporting routing protocols across the encrypted tunnels becomes
challenging. Many routing protocols use multicast/broadcast packets
that cannot be encapsulated by IPSec.

In addition, IPSec specifications do not require that IPSec be
supported on a virtual interface, making it difficult to create
neighbor relationships between IPSec peers for routing information
exchange on most security gateways. An additional encapsulation
technology is therefore required to support transport of routing
protocols across IPSec based VPNs.

Another challenge is that IPSec mandates to specify in the SPD all
protected networks. This means that when a new IP network is added to
the VPN, the SPD of multiple security gateways must be updated.

The IETF IPSec Working group defines the IPSec standards. The core
specifications include [RFC 2401] Security Architecture for the
Internet Protocol, Internet Key Exchange (IKE) protocol [RFC 2407],
[RFC 2408], and [RFC 2409], IP Authentication Header (AH)[RFC 2402] and
IP Encapsulating Security Payload (ESP) [RFC 2406].

RFC 2784 defines a standard track encapsulation protocol called Generic
Routing Encapsulation (GRE).

This document outlines the use of GRE encapsulation in conjunction with
IPSec transport mode to support transport of dynamic routing protocols
across an IPSec encrypted tunnel.

2 Requirements for IPSec VPNs

2.1 Routing requirements

The ability to support dynamic routing protocols through IPSec tunnel
is an important requirement for running large networks using IPSec
based VPN. When building a VPN network using IPSec, user data as well
as network control data are carried through the IPSec encrypted tunnels
linking various sites. The network routing protocols traversing the
IPSec encrypted tunnel use broadcast and multicast IP packets to
discover neighboring routers and communicate reachability information
with peers. IPSec tunnel cannot carry broadcast and multicast IP
packets used by the routing protocols [WANG-ROUTING]. It may be
possible to allow dynamic routing transport via IP unicast by
specifying neighbor relationships manually in configuration or by
treating the links as point-point links. But there are additional
challenges with the use of IPSec.

The IPSec standard does not require that IPSec be implemented on a
virtual interface. Interior Gateway Protocols that use link state or
distance vector routing, require formation of neighbor relationships or
adjacencies between routers for exchange of routing information. These
adjacencies can only be formed between devices on the same subnet.
Therefore even if routing protocol packets are converted to unicast
packets, adjacencies between IPSec peers cannot be formed if they are
not implemented on a virtual interface.

The lack of support for transporting dynamic routing protocols across
IPSec encrypted tunnels, therefore limits IPSec's application to small
point-point VPNs only.  To overcome this limitation, an additional
tunneling protocol is needed that (a) can be implemented over a virtual
interface (b) can allow encapsulation of IP broadcasts and multicasts.

2.2 Ease of adding a new IP network

In order to build an IPSec SA for a VPN, the SPD must specify the
protected IP networks (on both side of the IPSec SA). This has two
nasty effects:

1) for every pair of <local IP network, remote IP network> a SPD will
have to be configured on both security gateways. Hence, when adding
another IP network behind a security gateway, the SPD on both security
gateways must be updated. In the case of a large VPN, which could
potentially be fully meshed, this requires a huge amount of
configuration

2) for every pair of <local IP network, remote IP network> a pair of
IPSec SA bundles will have to be negotiated and installed in the SA
Database. This usually has an impact of the overall performance and
scalability of the security gateway (specially the security gateways
using a hardware acceleration chip for IPSec where the number of
session keys is limited).

3.0 Routing Support via GRE

GRE is defined in an informational RFC 1701 initially and then later
turned into a standard track RFC 2784.

By using GRE encapsulation, multicast/broadcast IP packets used by
dynamic routing protocols can be sent across the GRE tunnel.

As GRE packets are also an IP datagram, the security gateway has a SPD
entry, which specifies IPSec protection for those GRE packets. The
IPSec security gateways at both ends of the IPSec SA are responsible to
maintain the IPSec SA, including initial SA establishment, key
refreshment, and SA termination. In addition, both devices are expected
to maintain active access control over traffic flow across the tunnel
based on user VPN policy.

3.1 GRE Encapsulation with IPSec

GRE encapsulation adds a GRE header and an IP delivery header to the original packet.

GRE encapsulated packet:
   +---------------------+------------+---------------------------------------+
   |  delivery IP header | GRE header | original IP header | original payload |
   +---------------------+------------+--------------------+------------------+

When the GRE packet is sent to the IPSec security gateway, two choices
are possible: IPSec tunnel mode and IPSec transport mode. IPSec tunnel
mode adds another IP header to the GRE packet while IPSec transport
mode uses the existing GRE IP header.

GRE with IPSec in tunnel mode
+----------+---------+---------------+-------+-----------+------------+--------+
|New IP hdr|IPSec hdr|IP delivery hdr|GRE hdr|orig IP hdr|orig
payload|IPSec tr|
+----------+---------+---------------+-------+-----------+------------+--------+
                     <- ------------Encrypted---------------------------------->

GRE with IPSec in transport mode
+----------------+-----------+---------+-------------+--------------+----------+
|IP delivery hdr | IPSec hdr | GRE hdr | orig IP hdr | orig payload | IPSec tr |
+----------------+-----------+---------+-------------+--------------+----------+
                             <------------Encrypted---------------------------->


IPSec transport mode is the most efficient way to combine GRE and IPSec
together since GRE encapsulation has already put on a new IP header.

The use of IPSec transport mode however requires that the GRE
encapsulation use an IP address that is routable across the Service
Provider's IP network.

3.2 GRE Implementation - Tunnel Termination Point

When GRE is enabled, it creates a tunnel between two GRE tunnel end
points. When combined with IPSec, the GRE tunnel is actually 'riding'
inside the IPSec SA, creating a 'tunnel in tunnel' scenario. In
implementations, IPSec tunnel end point may or may not coincide with a
GRE tunnel end point. Three different possible scenarios are possible.

Case 1.  GRE tunnel and IPSec SA terminate on the same gateway at both ends.

                ===========IPSec SA=================
                |                                  |
                |                                  |
                |-----------GRE tunnel ------------|
                |                                  |
                |                                  |
     H1 ------ Gw1 ----------(IP Network )------- GW2 ------ H2


Case 2.  GRE tunnel terminates on a different device than IPSec at one end.

                 ===========IPSec SA================
                 |                                  |
                 |                                  |
     H1 ------ GW1 ----------(IP Network) -------- GW2----GWb---H2
                 |                                         |
                 |------------- GRE Tunnel ----------------|


Case 3.  GRE tunnel and IPSec SA terminate at different end points at both ends.

                 ===========IPSec SA=================
                 |                                  |
                 |                                  |
   H1 ----GWa-- GW1 -------(IP Network )---------- GW2----GWb---H2
           |                                                |
           |                                                |
           |----------------GRE tunnel ---------------------|


Typically the GRE tunnel and IPSec tunnel would terminate at the same
end point. In the case of an integrated router with IPSec capability,
both GRE and IPSec tunnel will terminate at the same point.

It is also possible for one end or both ends of a GRE tunnel terminate
on a different device than the IPSec termination point. This scenario
may be applicable for instance when the IPSec tunnel is terminating on
a firewall or a dedicated VPN appliance that does not support routing.

4.0 Considerations for the use of GRE

4.1 Performance Impact

GRE adds 24 bytes of overhead to the original IP packet. GRE
encapsulation in conjunction with IPSec transport mode adds 4 bytes of
extra overhead in comparison to the 20 bytes of overhead added by IPSec
tunnel mode. The additional overhead and extra processing for GRE
encapsulation reduces the overall throughput and may impact latency of
the connection.

4.2 Fragmentation and Reassembly

Addition of the GRE overhead on top of IPSec overhead increases the
size of the packet. Packet fragmentation can be avoided by ensuring
that Path MTU discovery is enabled. To ensure that PMTUD works as
expected, ICMP code 3 type 4 messages must be allowed through the
network. If ICMP code 3 type 4 messages are not supported in the
service provider network, then to avoid fragmentation, a lower MTU can
be set on the tunnel interface. If the end hosts support PMTUD then
they will match the packet size to the configured MTU.

Both the IPSec and GRE specifications support Path MTU Discovery by
allowing the copy of the DF bit of the original IP header into the
newly built IP header. This is usually a configuration option of the
devices.

If the end host does not support PMTUD and DF bit is not set, the
packet will be fragmented and sent over the GRE encrypted tunnel.

4.3 IPSec VPN enhancements

In addition to routing support, use of GRE encapsulation with IPSec
provides additional enhancements to IPSec based VPNs.

4.3.1 Resilient VPN Design

IPSec is a stateless protocol and can neither detect tunnel failure nor
communicate status of the IPSec SA. Transporting routing protocols
across IPSec provides a mechanism to detect these failures.
Hello/Keepalive packets typically sent by routing protocols over the
GRE tunnel interface make it possible to detect GRE tunnel failure. By
implementing GRE on a virtual interface, the routing protocol can track
reachability of next hop and therefore availability of the GRE tunnel
riding inside of IPSec.


4.3.2 Multi-protocol transport

In many applications, VPNs may carry multi-protocol traffic. IPSec
cannot be used directly to tunnel any layer 2 PDUs or layer-3 PDUs of
non-IP protocols. By using GRE these other network packets can also be
tunnels inside of IPSec.

One notable use of this is to transport IS-IS routing protocol that is
not IP based and hence cannot be tunneled by IPSec.

4.3.3 Multicast

Multicast IP packets can be encapsulated into a GRE packet. This allows
the transport of multicast traffic over an IPSec protected GRE tunnel.
Furthermore, the multicast routing protocol (PIM, ...) can also run on
the GRE virtual interface.

4.3.4 SPD and SAD scalability

The SPD entry between two given IPSec peers is now a single entry:
<local IP address, remote IP address, GRE protocol type, *, *>. Where
the IP address are the 'physical' IP addresses of the IPSec peers,
i.e., the IP addresses connected to the SP network.

If an IP network is added/deleted/re-addressed behind a security
gateway, the SPD entry does not need to be changed.

Having a single SPD entry between two IPSec peers, means that only one
pair of SA bundle will be used between these two IPSec peers. This
greatly reduces the number of SA per security gateway.

5.0 Security Issues

When traffic is encapsulated using GRE, IPSec traffic filtering looses
the capability to inspect what was inside the packet.  Thus unwanted
traffic, which would be discarded by a security gateway, may be
tunneled through under the cover of GRE encapsulation.

Therefore it is important to enforce some kind of traffic filter for
the GRE tunnel so that the intended security policy is not bypassed.
This requirement is especially important when an extra-net IPSec VPN
tunnel is involved. This means that multiple SPD will have to be
configured - one on the physical interface for IPSec processing of GRE
packets. And one per GRE tunnel virtual interface requiring the discard
or forward of specific IP packets.

The VPN device MUST also ensure that no clear text GRE packets are
processed.

Additionally, the VPN device SHOULD apply a reverse path check on all
IP packets received through an IPSec protected GRE tunnel. This reverse
path check SHOULD be based on the forwarding information based derived
by the routing protocols. While the routing protocol helps in several
ways, it actually substitute itself to the static SPD. Hence, the
routing protocol SHOULD be authenticated and this routing protocol
instance MUST not accept and MUST not transmit routing information on
the physical interface that is receiving and transmitting IPSec
protected GRE packets.

6.0 Summary for Sub-IP Area

6.1 Summary

The PPVPN WG currently supports three types of VPNs: Provider
Provisioned Network Based Layer 3 VPNs, Provider Provisioned Layer 2
VPNs and Provider Provisioned CE-based VPNs. This draft discusses the
use of GRE encapsulation to support routing for CE-based IPSec VPN.


6.2 Where does it fit in the Picture of the Sub-IP Work?

This work fits squarely in the PPVPN box.


6.3 Why is it targeted at this WG?

This document proposes using GRE encapsulation to carry certain types
of network traffic through IPSec VPN, since current IPSec standards
limits the tunneling of IP multicast and broadcast packets, as well as
non-IP layer 3 packets. In the absence of broadcast and multicast
support, IPSec VPN tunnels cannot support dynamic routing protocols
over the tunnel. GRE encapsulation may provide a solution to these
limitations.

Under the current PPVPN WG charter, Provider Provisioned CE-based VPNs
fits the scope of the WG, as stated from the following charter
extract:  "This working group is responsible for defining and
specifying a limited number of sets of solutions for supporting
provider-provisioned virtual private networks (PPVPNs). The work effort
will include the development of a framework document, a service
requirements document and several individual technical approach
documents that group technologies together to specify specific VPN
service offerings. The framework will define the common components and
pieces that are needed to build and deploy a PPVPN. Deployment
scenarios will include provider-managed VPN components located on
customer premises."


6.4 Justification

This draft is justified since it targets the routing issue of CE-based
VPNs, which are identified as a specific type of PPVPNs both in the WG
charter and the general framework I-D. CE-based VPN has its own
characteristics and operation requirements, among which routing support
is one.


7.0 Reference


[RFC1702]   S. Hanks, T. Li, D. Farinacci, P. Traina
            Generic Routing Encapsulation over IPv4 networks,
            October 1994

[RFC2401]   S. Kent, R. Atkinson Security Architecture for the
            Internet Protocol, November 1998

[RFC2402]   S. Kent, R. Atkinson, IP Authentication Header,
            November 1998

[RFC2406]   Kent, S., and R. Atkinson, "IP Encapsulating Security
            Payload (ESP)", RFC 2406, November 1998.

[RFC2407]   D. Piper, The Internet IP Security Domain of
            Interpretation for ISAKMP, November 1998

[RFC2408]   D. Maughan, M. Schertler, M. Schneider, J. Turner,
            Internet Security Association and Key Management
            Protocol (ISAKMP), November 1998

[RFC2409]   D. Harkins, D. Carrel, The Internet Key Exchange (IKE),
            November 1998

[RFC2784]   D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina
            Generic Routing Encapsulation (GRE), March 2000

[WANG-ROUTING] Wang, C., Beadles, M., Khetan, A., "Routing Support in CE-based IPSec VPNs", draft-wang-cevpn-routing-00.txt, November 2001,
Work in progress

[CE-framework]  De Clercq et al."A Framework for Provider Provisioned
CE-based Virtual Private Networks", draft-ietf-ppvpn-ce-based-01.txt,
November 2001, Work in progress


Author's Addresses

Archana Khetan
SmartPipes
555 Twin Dolphin Drive
Suite 650                         Phone:  1-650-232-172
Redwood city, CA 94065 USA        Email:  akhetan@smartpipes.com

Cliff Wang
SmartPipes
565 Metro Place South             Phone:  1-614-923-6241
Dublin, OH 43017, USA             Email:  cwang@smartpipes.com

Mark Beadles
SmartPipes
565 Metro Place South             Phone:  1-614-923-5657
Dublin, OH 43017 USA              Email:  mbeadles@smartpipes.com

Louis French
SmartPipes
565 Metro Place South             Phone:  1-614-923-6273
Dublin, OH 43017 USA              Email:  lfrench@smartpipes.com

Eric Vyncke
Cisco Systems
Av Marcel Thiry, 77               Phone: +32-2-778-4677
B-1200 Brussels, Belgium          Email: evyncke@cisco.com

















Khetan, et al.            Expires July 2002                   [Page 9 ]

INTERNET DRAFT  Use of GRE for routing support in IPsec VPNs Jan, 2002