C. Wang M. Beadles Internet Draft A. Khetan Document: draft-wang-cevpn-routing-00.txt SmartPipes Expires: April 2002 October 2001 Routing Support in CE-based 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 to provide VPN connection, it is important to support site-to-site customer network routing. This document describes the scenario, requirement, and several potential solutions to provide customer network (intranet) routing support for IPsec-based VPNs. Wang, Beadles, Khetan Expires August 2002 [Page 1] Routing Support in CE-based IPsec VPNs August, 2001 1.0 Introduction IPsec-based VPN has been one of the options for service providers to offer VPN services. IPsec based VPN can achieve a high level of data security and dramatically reduce cost in comparison with private leased lines. When IPsec tunnel is used to build a large-scale network, user data as well as network control data of the customer network are carried through the tunnels linking various sites. Although the VPN networks may vary from hub-and-spoke to a full mesh in topology, the basic requirement of providing and maintaining reliable site-to-site data connectivity remains the same. IPsec is a layer 3 tunneling protocol, which operates purely on IP layer. The IETF IPsec Working Group specifies the IPsec standards [RFC2401, RFC 2402, RFC2406, RFC2407, RFC2408, and RFC2409]. The interaction between IPsec and layer 3 routing has not been specified. Depending on individual implementation, difficulty may arise when an IPsec user wants to support robust routing across IPsec VPNs sites. This draft intends to identify and analyze the interactions between IPsec and IP routing, when IPsec tunneling is used to build CE-based IPsec VPN. Further, several potential solutions to support IPsec VPN routing are proposed using existing protocols. 1.1 Terminology used in this draft Customer Edge (CE) This is the customer premise equipment, which provides the connection between a customer network and a service provider network. In the case of CE- based VPN, a CE device also terminates VPN tunnels. CE based VPN The term "CE-based VPN" refers to an approach in which knowledge of the customer network is limited to customer premise equipment. The service provider takes on the task of managing and provisioning the Customer Edge equipment, on behalf of its customers. In CE-based VPNs, the customer network is connected by tunnels set up between CE devices. In the case of IPsec VPN, the VPN tunnels use IP encapsulations to sent traffic over the service provider IP networks. Customer IP Network Wang, Beadles, Khetan Expires August 2002 [Page 2] Routing Support in CE-based IPsec VPNs August, 2001 A customer network is a network, which a service provider customer manages itself. However, different parts of a customer network may be inter-connected through the service provider network via VPN services. Provider Edge (PE) This is the provider edge (PE) equipment, which is attached to the customer network, usually a CE device. For a layer 3 connection, the PE device is an IP router. Service Provider IP Network A service provider network is a network administered by a single service provider. A service provider network is the core network which links customer networks on its edge and provide Internet connections to its customer networks. VPN tunnel A VPN tunnel is a logical link by encapsulating packets and transmitting the encapsulated packets using the encapsulating header between two CE devices. In the case of IPsec VPN, the encapsulation carried out by using IPsec. 2.0 Scenarios of Running IPsec VPN An IPsec VPN consists of a number of sites securely inter-connected through IPsec tunnels. Each site consists of the CE router, the customer network behind the CE router, and the link to the PE router to connect to the service provider network. Through the service provider networkĘs IP infrastructure, CE routers are inter-connected via IPsec tunnels to reach each other. The CE router sits at the boundary between the service provider network and the customer networks. The CE router may have one or more public routable addresses and is linked to the PE router. An IPsec tunnel links two sites together through the service providerĘs IP network. The tunnel end points use the public address of the CE routers. User data of the customer network are encapsulated by the IPsec header and tunneled through the service provider network. These tunneled packets are routed normally through the service provider network as other IP packets between CE routers. Wang, Beadles, Khetan Expires August 2002 [Page 3] Routing Support in CE-based IPsec VPNs August, 2001 To link the various CE sites, different VPN connection topology can be used. For a small VPN with a few sites, simple topologies such as a hub-and-spoke or a full mesh can be used. For a large VPN, a layered, hierarchical approach may be taken. On the customer network side, a CE router connects to internal networks of an enterprise, where one or more subnets can reside. Many times, the CE router may interact with another internal router. The CE device could be an integrated device providing both routing and IPsec tunnel termination. Sometimes, a dedicated VPN terminator may be used. Implementations in which the VPN terminator resides on a firewall are also very common. For the sake of simplicity, we assume that the CE router is an integrated device and terminates tunnels. 3.0 Routing Requirement IPsec is a point-to-point tunneling protocol linking two sites across a Service ProviderĘs IP network. The VPN traffic between the CE routers is routed through the service provider network like normal IP packets. The traffic traversing the IPSec tunnels (tunneled traffic) runs in the customer network space. For the customer enterprise network (intranet) connected by VPN tunnels, route information needs to be updated and distributed dynamically among all sites (CE router plus networks behind it) participating in the VPN, in order to support network connectivity through theses IPsec tunnels. 3.1 Customer network routing ū Intranet In the intranet case all of the sites to be interconnected belong to the same administration (for example, the same company). The options for routing within a single customer network include: o A single IGP area (using OSPF, IS-IS, or RIP) o Multiple areas within a single IGP o A separate IGP within each site, with routes redistributed either statically or via BGP. The use of BGP is applicable in scenarios when the IPSec VPN is used to configure the backbone of a very large enterprise with each site running its own IGP. If a site consists of only a few LAN segments that are all attached to the CE router, then the CE router is aware of all the routes at that site. If a site consists of multiple networks that reside one or more hops away from that CE router, the CE router could Wang, Beadles, Khetan Expires August 2002 [Page 4] Routing Support in CE-based IPsec VPNs August, 2001 participate in a routing protocol with other routers at that site to learn about these other networks. In either case, the IPSec VPNs must be able to transport route advertisements learnt by the CE router to all other CE routers participating in that VPN. In a VPN network where a VPN site can come and go, the site-to-site routing also needs to responds to site changes, including site addition and deletion. 3.2 Customer network routing ū Extranet In the extranet case the sites to be interconnected belong to multiple different administrations. In this case IGPs (such as OSPF, IS-IS, or RIP) are normally not used across the sites between organizations. Either static routes or BGP may be used between sites to communicate reach-ability information. Since extranets are configured between communities of interests to share access to specific resources only, the reach-ability information shared between sites is limited to the advertisement of the shared resource only. The requirements for extranet customer network routing remain the same as those identified in Section 3.1. The differences are that under the extranet case, route distribution and update MUST be limited to the shared resources only. In other words, routing support must be designed carefully so that internal network reach- ability information will not be leaked to un-intended partners. In the extranet case, it is likely that a site may join different VPNs. A CE router needs to support separate routing for each VPN. This draft limits its scope to the intranet discussion. 4.0 Limitations of Routing Support through IPsec VPN Tunnels The current IPsec standards (RFC 2401, RFC 2402, RFC 2406, RFC 2407, RFC 2408, and RFC 2409) have not addressed the issue of providing routing support through IPsec tunneling. The IPsec tunnel merely provides a point-to-point connection. Each end of tunnel may attach to a single host or a complex network. Packets enter the tunnel by IPsec encapsulation and leave the tunnel by IPsec header de- capsulation. At both ends, tunnel access-list controls what can be sent into the tunnel and what can be received from the tunnel. In terms of how these packets are first routed to the IPsec gateway and then into the tunnel and how the de-capsulated packets are then routed to final destination are left to implementations. In other Wang, Beadles, Khetan Expires August 2002 [Page 5] Routing Support in CE-based IPsec VPNs August, 2001 words, IPsec tunneling is specified independently of any packet routing. In reality, from source to destination, packets need to be routed to the local IPsec device, tunneled to the remote IPsec device, and then routed again to final destination. Tunneling is only one segment that a packet is traversing. To deliver packets to their destination, VPN tunneling and routing need to work together. To support site-to-site connection through IPsec tunnels, routing information must be exchanged between sites. The current IPsec standards donĘt require IPsec tunnel to be on a logical interface that packets can be routed to. A non-interface IPsec tunnel end point canĘt participate in packet routing and forwarding. In that case, the IPsec tunnel end point may attach to a physical interface. The other practical limitation for running routing protocols through IPsec tunnel is that the existing IPsec standards donĘt support multi-cast and broadcast traffic. IPsec tunneling canĘt carry any routing protocols using multicast or broadcast natively. To support CE-based IPsec VPN, this draft addresses the gap between running tunneling and routing and discusses several potential solutions to support IPsec VPN routing. 5.0 Routing Supporting for Running IPsec VPNs Depending on how IPsec is implemented several options are available to support routing in IPsec-based VPN. 5.1 IPsec Implemented as a Virtual Interface IPsec tunnel end point can be implemented as a virtual interface. By doing that, the IPsec tunnel can participate in the CE routerĘs routing table. Having a virtual interface allows assigning of IP addresses separate from the physical interface. This allows establishment of IGP routing peer relationships across the tunnel to other CE routers. However, since IPSec doesnĘt support non-unicast traffic, routing protocols using multicast or broadcast will not be able to get tunneled. This could be circumvented by configuring CE router with routing peer information as opposed to having the peers learnt automatically via broadcast or multicast messages. When extra-net VPN is involved, establishment of BGP routing peer between CEs can be supported successfully, since BGP only uses uni-cast traffic. 5.2 IPsec not implemented as a Virtual Interface Wang, Beadles, Khetan Expires August 2002 [Page 6] Routing Support in CE-based IPsec VPNs August, 2001 When IPsec is not implemented as a virtual interface, it cannot participate in the site-to-site routing directly. To support routing across the tunnel, special treatments are needed. 5.2.1 Using Managed Route Update Managed route update can be used to distribute route update across VPN sites. This approach requires each CE device remain in contact with a centralized management center. With the managed route update scheme, each site may still run its local routing protocol to maintain a dynamic routed local network. The remote site reach-ability information is collected and distributed through a management solution. The management center is similar to a route server, which serves all the CE routers participating in a dedicated VPN. The management center monitors and maintains the active membership of a VPN. When a new VPN member joins the group, its reach-ability information is delivered to its VPN peers via management center, after all the corresponding IPsec tunnels have been established. When an active member has left the VPN group, the management center needs to update all affected CE routers so that the related route entries can be updated or deleted. In addition, the management center is also responsible to distribute route update of a connected site to all other connected sites. A CE router is required to inform the management center when a local route update has happened. The management center is then responsible for obtaining the new route update and injecting the new reach-ability information to the related sites. For example, when a CE router in a fully meshed VPN network has a new subnet route added, the CE routerĘs peers need to be updated with the new reach-ability information. Effectively, the management center manages each CE routerĘs site-to- site static routing. The route update happens when either the VPN membership changes or when a siteĘs local routing table has an update (due to local site routing changes). Since the management center usually has the capability of monitoring the status of site-to-site VPN tunnel status, it is able to respond quickly when a tunnel connection is lost. The management center can update reach-ability information and provide alternative routing path for those affected sites. The response time for this approach is usually much quicker than that a normal dynamic routing protocol can offer. It is worth pointing out that the managed route update may have a scalability issue. Managing a large VPN with many sites may require complex management software to manage these route updates. However, Wang, Beadles, Khetan Expires August 2002 [Page 7] Routing Support in CE-based IPsec VPNs August, 2001 as with the case of routing, a complex VPN may be designed using a layered approach. In that case, managing route with each sub-VPN networks is still feasible and with good scalability. 5.2.2 Using Encapsulation Protocols An alternative to managed route update is to run dynamic routing protocols across IPsec tunnels. The IPsec tunnel end needs to appear as some kind of virtual interface in order to run generic routing protocols. In addition multicast or broadcast routing messages need to be encapsulated to become uni-cast packets. To send routing traffic through an IPsec tunnel, an extra layer of encapsulation protocol can be used, when the encapsulation protocol is able to provide two services: 1) The encapsulation protocol can be implemented as a virtual interface; 2) The encapsulation protocol can tunnel multicast/broadcast packets. One choice is to use GRE encapsulation when it is implemented as a virtual interface. GRE is defined in an informational RFC 1701 initially and then later turned into a standard track RFC 2784. RFC 1702 Generic Routing Encapsulation over IPv4 networks describes the GRE usage for transporting an arbitrary network layer protocol over IPv4. GRE encapsulation adds a GRE header and an IP delivery header to the original packet. Using GRE encapsulation, multicast IP packets used by dynamic routing such as RIP can be sent across the IPsec VPN tunnel. The point-to-point IPsec VPN only sees the IP GRE packets in this case. Other encapsulation protocols include L2TP [RFC2661] and PPTP [RFC2637], when the tunnel end is implemented as a virtual interface. PPTP and L2TP have a built-in control channel, which is used to establish, manage, and terminate its corresponding data channel. The L2TP packets are carried by UDP protocol. The PPTP control channel is carried over TCP while a GRE tunnel is used to carry the PPTP data packets. Both L2TP and PPTP have a keep-alive mechanism in its control channel. This can provide valuable information about the status of both the L2TP or PPTP tunnel and the IPsec tunnel that carries the L2TP or PPTP tunnel. Compared with GRE encapsulation, L2TP or PPTP encapsulation runs a heavier protocol stack and is more complex. However, the keep-alive feature provided by L2TP or PPTP provides useful tunnel status feedback. Wang, Beadles, Khetan Expires August 2002 [Page 8] Routing Support in CE-based IPsec VPNs August, 2001 Using encapsulation, routing protocol messages can be tunneled across the IPsec tunnels. Site-to-site reach-ability information is distributed and updated using the native routing protocol exchange. The virtual interface provided by the encapsulation protocol participates directly in the local routing table. The virtual interface status reflects the underlying IPsec tunnel status. When the IPsec tunnel goes down, the virtual interface needs to report that change back to the routing engine. To be able to detect the tunnel failure, some kind of keep-alive message is needed. The routing protocol itself has a keep-alive mechanism, in the form of a hello message. When the CE discovers that it has lost connectivity to its neighbor, the routing table will be adjusted accordingly. Alternatively, the keep-alive mechanism provided by the encapsulation protocol (L2TP or PPTP) can be used to detect IPsec tunnel status. However, GRE doesnĘt have a keep-alive capability. 6.0 Interaction between IPsec Tunnel and Routing With CE-based IPsec VPN, IPsec tunneling interacts with two routing spaces. The IPsec packets are routed through the service provider network as normal IP packets. The CE router connects to the PE router to gain Internet access. The PE router is not directly involved in the IPsec VPN, other than forwarding the IPsec packets from the CE router. The IPsec packet payload carries the customer network IP packet. The customer network linked by site-to-site VPN connection runs its own routing. In that sense the IPsec tunneling interacts closely with the customer network space routing. IPsec tunneling does not provide a connection-oriented link. An IPsec tunnel consists of just two encasulation and decapsulation modules at each tunnel end. An IPsec tunnelĘs life is always determined by the life of the tunnel key. An IPsec tunnel never outlives its corresponding key. Although IPsec can be configured as a static tunnel with a static key, in practice few service providers will do that due to the security risk associated with the static key. Instead dynamic keyed IPsec tunnel using IKE is the preferred way. An IPsec tunnel should use time-based re-key so that it stays active and still gets key refreshed when there is no or little traffic crossing the tunnel. If the IPsec tunnels are implemented as packet driven and donĘt stay up all the time, dynamic routing may be affected. There is usually a latency between packet arrival and the time a tunnel has been established. If the latency is long enough, packet loss may happen. A lost route update message due to tunnel setup latency has to be Wang, Beadles, Khetan Expires August 2002 [Page 9] Routing Support in CE-based IPsec VPNs August, 2001 re-transmitted. As a comparison, permanent or semi-permanent tunnels with key refresh is more stable and provides a PVC type of connection. Existing IPsec standards lacks a keep-alive mechanism, making it difficult to determine the tunnel status. The routing table may not receive timely update even when the tunnel has gone down. To overcome this limitation until IPsec establish a keep-alive standard, some kind of tunnel status monitoring is required. When running a dynamic routing protocol across a tunnel, the routing protocolĘs keep-alive mechanism may be used indirectly to check for the tunnel status. For managed route update solution, some kind of tunnel keep-alive mechanism needs to be built into the tunnel management. 7.0 Interaction with NAT NAT provides address translation between two realms, such as between the private address space and the public address space. For site-to- site VPN, the user data remain in the same customer network address space. NAT is usually not required, unless two sites have overlapping address space. In that case, NAT can be used to solve the address-overlapping problem. The only scenario when NAT applies is when the CE router serves a split stack function and provides both VPN connection and direct Internet access. In this case, private address space traffic is separated into two streams, one part for site-to-site private traffic and one part for direct Internet traffic. In this case CE performs NAT function for the direct Internet traffic. 8.0 Security Issues One of the most important features of using IPsec-based VPN is security. To make sure that IPsec VPN is implemented securely, a careful analysis of security issues is required. 1) Encapsulation Section 5.2.2 discusses using an extra packet encapsulation. If site-to-site traffic is encapsulated (such as by GRE) before entering an IPsec tunnel, the IPsec tunnel traffic filtering loses its inspection capability. Thus unwanted traffic, which can be blocked by an IPsec tunnel filter, may be tunneled through under the cover of encapsulation. It is important to enforce the same set of IPsec traffic filters to the user traffic before it gets encapsulated and after it gets de-capsulated, when such encapsulation is used inside an IPsec tunnel. Wang, Beadles, Khetan Expires August 2002 [Page 10] Routing Support in CE-based IPsec VPNs August, 2001 2) Connection to the Management Center A CE device usually needs to connect to the management center in order to get provisioned, managed, and monitored. It is important to secure the communication so that an adversary canĘt use this management channel to compromise the security of the VPN network by gaining privileged access to the CE device. 3) Injection of Route For managed route update, site-to-site route information is injected from the management center. False route injection can severely disrupt network service. Therefore the route distribution and update to each CE must be securely protected. If the management channel used to make the update is secure, then no addition precaution may be needed. Otherwise, each route update must be at least authenticated at least. With dynamic routing, the route distribution is done by the routing protocols. The site-to-site VPN infrastructure can be used to protect the route messages. 9. Summary for Sub-IP Area 9.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 issue of supporting routing for CE-based IPsec VPN. 9.2. Where does it fit in the Picture of the Sub-IP Work This work fits squarely in the PPVPN box. 9.3. Why is it Targeted at this WG This draft describes the scenario, requirement, and several potential solutions to provide private space routing support for CE- based IPsec-based VPNs. 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 Wang, Beadles, Khetan Expires August 2002 [Page 11] Routing Support in CE-based IPsec VPNs August, 2001 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." 9.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. 10. Reference [FRAMEWORK] Callon, R. et al., A Framework for Provider Provisioned Virtual Private Networks, draft-ietf-ppvpn-framework-00.txt, Work in progress [CEFRAMEWORK] Jeremy De Clercq, Olivier Paridaens, Mahadevan Iyer, Andrew Krywaniuk , A Framework for Provider Provisioned CE-based Virtual Private Networks using IPsec, draft-ietf-ppvpn-ce-based-00.txt, Work in progress [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 Wang, Beadles, Khetan Expires August 2002 [Page 12] Routing Support in CE-based IPsec VPNs August, 2001 [RFC2637] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn, Point-to-Point Tunneling Protocol (PPTP), July 1999 [RFC2661] Townsley W., et al., "Layer Two Tunneling Layer Two Tunneling Protocol (L2TP)", August 1999. [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina Generic Routing Encapsulation (GRE), March 2000 Author's Addresses 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 Archana Khetan SmartPipes 555 Twin Dolphin Drive Suite 650 Phone: 1-650-232-172 Redwood city, CA 94065 USA Email: akhetan@smartpipes.com