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