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