Provider Provisioned VPN WG Elwin Eliazer (Corona) Internet Draft Brijesh Kumar (Corona) Benson Schliesser (SAVVIS) Category: Informational Expiration Date: August 2002 February 2002 PPVPN Architecture using L2TP draft-elwin-ppvpn-l2tp-arch-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026]. 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 This document discusses the use of L2TP for establishing PPVPNs. It proposes to use L2TP for VPN membership, topology discovery, and as a tunneling mechanism. The basic idea is based on leveraging the inherent strengths of L2TP for tunneling traffic, and extend the same advantages to PPVPNS. The mechanism is applicable for both Layer2 and Layer3 PPVPNs. ID Summary RELATED DOCUMENTS See References section below. Elwin, Brijesh, Benson [Page 1] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This ID fits the PPVPN box. WHY IS IT TARGETED AT THIS WG This ID describes a tunneling and discovery mechanism for PPVPNs, which comes under the charter of this WG. JUSTIFICATION This ID describes a tunneling and discovery mechanism for PPVPNs, which comes under the charter of this WG. Table of Contents 1.0 Introduction ................................................ 3 2.0 L2TP for PPVPN Tunneling .................................... 3 3.0 Merits and demerits with this approach ...................... 4 3.1 Merits ...................................................... 4 3.2 Demerits .................................................... 5 4.0 PPVPN Services Using L2TP ................................... 5 4.1 VPN Membership Discovery .................................... 5 4.2 VPN Topology ................................................ 5 4.3 Tunnel Setup ................................................ 6 4.4 Keepalive ................................................... 6 4.5 Tunnel Authentication ....................................... 6 4.6 Control Connection Topology ................................. 6 5.0 Applications ................................................ 7 5.1 OSPF/L2TP VPNs .............................................. 7 5.2 Ethernet/L2TP VPNs and other L2 VPNs ........................ 7 5.3 Remote Access L2TP/IPSec VPNs ............................... 7 5.4 IPv6/L2TP VPNs .............................................. 7 6.0 Comparison with other approaches ............................ 7 6.1 Other tunneling methods ..................................... 7 6.2 Other VPN discovery methods ................................. 8 7.0 Scalability Considerations .................................. 8 7.1 Control Connection -- Scalability ........................... 8 7.2 Per VPN Tunnels -- Scalability .............................. 8 8.0 Security Considerations ..................................... 9 9.0 References .................................................. 9 10.0 Acknowledgments ............................................. 10 11.0 Author's Addresses .......................................... 10 Elwin, Brijesh, Benson [Page 2] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 1.0 Introduction The establishment of a PPVPN require three basic mechanisms: VPN membership and topology discovery, tunnel signaling and establishment, and route distribution [PPVPN-FW]. Currently, three different approaches have been proposed for distributing VPN discovery information: (a) manual or SNMP based configurations at each PE (b) centralized directory or database servers (c) piggybacking onto a routing protocol such as BGP. In this document, we make two new proposals. The first proposal is to use L2TP as a PPVPN tunneling protocol so that the benefits of L2TP as a tunneling mechanism for a variety of traffic classes are available to PPVPNs too. Secondly, we propose the use of L2TP to carry VPN discovery information as with simple extensions to L2TP, it can fulfill this role very effectively. Unlike extending a complex routing protocol such as BGP, L2TP extensions add no complexity to routing protocols, and carriers aren't forced to use BGP based discovery mechanisms for all their VPNs. L2TP, a protocol originally meant to tunnel PPP, has decoupled itself from PPP, and currently can tunnel a variety of payload. The rich set of tunnel managment functions offered by L2TP is a valid candidate for PPVPN tunneling. The use of L2TP for VPN discovery and tunneling has a second benefit that any IGP can be used for VPN related route distribution between two PEs. One is not forced to use BGP for route distribution as is the case with some proposals such as BGP/MPLS VPNs in [RFC-2547]. 2.0 L2TP for PPVPN Tunneling PPVPNs inherently need a tunneling mechanism to tunnel over the public backbone. Signaling these tunnels reduces the amount of configuration needed in setting up and tearing down these tunnels. L2TP, a protocol originally meant to tunnel PPP, has decoupled itself from PPP, and currently can tunnel a variety of payload. The rich set of tunnel management functions offered by L2TP is a valid candidate for PPVPN tunneling. Here we discuss the merits and demerits in using L2TP, to provide both Layer2 and Layer3 VPNs. We also suggest some simple extensions that can be made to L2TP which can help in PPVPN solutions. Note: VFI = Virtual Forwarding Instance. Refers to Layer-3 Virtual Router. VSI = Virtual Switching Instance. Refers to a Layer-2 Virtual Bridge. This terminology is used in the PPVPN requirement and framework docs. Elwin, Brijesh, Benson [Page 3] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 PE PE +--------------+ +--------------+ +--------+ | +----------+ | L2TP | +----------+ | +--------+ | VPN-A | | | VPN-A | | Tunnel | | VPN-A | | | VPN-A | | Site |----| VFI/ |=================| VFI/ |---| site | +--------+ | | VSI | | | | VSI | | +--------+ | +----------+ | | +----------+ | | | | | +--------+ | +----------+ | L2TP | +----------+ | +--------+ | VPN-B | | | VPN-B | | Tunnel | | VPN-B | | | VPN-B | | Site |----| VFI/ |=================| VFI/ |---| site | +--------+ | | VSI | | | | VSI | | +--------+ | +----------+ | | +----------+ | | | | | +--------+ | +----------+ | L2TP | +----------+ | +--------+ | VPN-C | | | VPN-C | | Tunnel | | VPN-C | | | VPN-C | | Site |----| VFI/ |=================| VFI/ |---| site | +--------+ | | VSI | | | | VSI | | +--------+ | +----------+ | | +----------+ | +--------------+ +--------------+ Figure 1: Reference Model 3.0 Merits and demerits with this approach 3.1 Merits + L2TP provides a good tunneling mechanism with an associated signaling protocol. The payload can carry IPv4 or IPv6 for L3 VPNs, or any L2 for L2 VPNs. + The tunnel encapsulation header has a hierarchical demultiplexing capability. + Keepalive for the tunnels are available. + Tunnel authentication is also available. + Tunneling is over IP and hence can work in both IP and MPLS networks. + Can work with IPSec in transport mode when security is needed. Thus IPSec can be made optional, based on the need. + Tunnel virtual interfaces can emulate real interfaces. If needed, any routing protocol can be run over this dynamic interface. + Decouples tunneling and VPN discovery, from learning of VPN routes. Elwin, Brijesh, Benson [Page 4] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 + L2TP Tunnel Switching can help in arriving at complex topologies. + VPN discovery and setup of tunnels can be automatically signaled with simple extensions. + Because keepalives are available, remote tunnel endpoint liveness can be easily detected. This could be of significant benefit, for VFIs and VSIs that are configured with static routes/forward entries. 3.2 Demerits - L2TP, as it is widely deployed today is over UDP. This increases the PE processing, and also increases the encapsulation header size. There are means to bypass the UDP in L2TP, which is recommended for PPVPNs. - L2TP tunnels, are inherently point-to-point tunnels. There is a proposal in L2TPext WG to support multicast tunnels. This will have to be explored for multipoint tunnels. Refer [L2TP-MLT]. 4.0 PPVPN Services Using L2TP 4.1 VPN Membership Discovery The VPN-ID format as defined in [RFC-2685] is used to identify a VPN. All VFIs/VSIs that are members of a specific VPN share the same VPN-ID. L2TP control connection is made across each PE devices, in the case of fully mesh topology for control connections. Refer Section 3.6 for other control connection topologies. VPN AVP in the L2TP Hello messages are used to determine any new VFI or VSI for a VPN coming up. Thus each PE gets to know the other PEs that have VFIs or VSIs corresponding to the VPNs it supports. [L2TP-EXT] describe the L2TP extensions needed in detail. 4.2 VPN Topology The desired VPN topology information for each PPVPN VFI/VSI can be specified as part of the VFI/VSI configuration. Following topology values are defined: "Hub" -- Connects (tunnel) to all the spoke VFIs/VSIs "Spoke" -- connects only to the hub VFI/VSI "Mesh" -- connects to all the other member VFIs/VSIs Elwin, Brijesh, Benson [Page 5] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 Other topologies are to be handled in a similar way. The tunnel switching capability in L2TP also help in defining the topology. 4.3 Tunnel Setup Per VPN L2TP tunnel setup across each VFI (or VSI) pair is initiated by L2TP when it receives the membership and topology information. If the PEs decide to use the same tunnel IP address for multiple VFIs or VSIs, the tunnel/session ID in L2TP can be used for multiplexing. The tunnel endpoint IP addresses is learnt as part of the VPN membership discovery. If security is needed on these tunnels, IPSec in transport mode is used on these L2TP encapsulated packets. Refer [RFC-3193]. 4.4 Keepalive The Hello messages in L2TP can be used to determine the control connection as well as the per VPN tunnel status. 4.5 Tunnel Authentication The per VPN tunnels and the control connections can be authenticated with the L2TP tunnel authentication methods, when the tunnels are setup. 4.6 Control Connection Topology The control connection tunnels are different from the per VPN tunnels, and they can have different tunnel endpoints. To have control connections in a hub and spoke topology, a designated Tunnel Manager is chosen as the hub. This can be a PE or any device that is reachable to the PEs. All the spoke PEs are configured with the Tunnel Manager's IP address, as the control connection peer. The tunnel manager then resolves the perVPN tunnel endpoints, and lets the PEs setup the per VPN tunnels directly. This can be extended with L2TP tunnel switching [L2TP-TSW]to achieve more complex topologies. Elwin, Brijesh, Benson [Page 6] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 5.0 Applications This approach is useful, but is not limited to, the applications listed in the following subsections. 5.1 OSPF/L2TP VPNs OSPF running at the individual VPN sites, are connected together by the per-VPN tunnels provided by L2TP. 5.2 Ethernet/L2TP VPNs and other L2 VPNs. Ethernet coming from the CEs of the VPN sites, are connected together by the per-VPN tunnels provided by L2TP. Similar approach is used for other L2s: Frame-relay, ATM, etc. 5.3 Remote Access L2TP/IPSec VPNs Roaming or mobile remote access VPN clients, can access VPN nodes, by reaching a PE VFI using L2TP/IPSec tunnels. This can be directly handled in this model. 5.4 IPv6/L2TP VPNs Islands of IPv6 networks, can be transported over a L2TP tunnel transparently so as to have a connected IPv6 network. 6.0 Comparison with other approaches 6.1 Other tunneling methods IPIP tunnels: This provides a simple tunnel encapsulation method. The disadvantages are: - It has no associated signaling protocol. - It has no demultiplexing field. - There is no mechanism to determine the liveness of the tunnel enpoint, since there is no keepalive. GRE tunnels: Though this provides a demultiplexing field, this has no associated signaling protocol, and hence relies on external means to setup the tunnels. And no way to determine the liveness of a tunnel. Elwin, Brijesh, Benson [Page 7] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 IPSec tunnels: [PPVPN-SEC] With IPSec tunnels, either AH or ESP needs to be done and can not be made optional due to security reasons. These are operations involving scanning of the complete payload and hence expensive. The other disadvantage is with the associated signaling protocol, IKE. IKE is not flexible for new additions and is not a protocol meant for setting up generic tunnels. MPLS tunnels: [RFC-2547] The problem with using MPLS tunnels is that it needs MPLS networks. Another disadvantage is that there is no means to determine the liveness of a tunnel, due to lack of keepalive mechanism. 6.2 Other VPN discovery methods BGP-based Discovery: [BGP-AUTO] This method suggests extensions to BGP to enable VPN discovery. For cases where BGP is not involved, this is an unnecessary involvement of BGP. For example, a Ethernet L2 VPN, do not need BGP to do VPN discovery. Multicast-based Discovery: [RFC-2917] This discovery method is based on multicasting, and hence assumes multicast enabled backbone, which is most of the times inappropriate. 7.0 Scalability Considerations Both the Control Connection tunnels and Per VPN tunnels should be scalable to have a scalable PPVPN solution. The main scalability issue arises when a mesh topology is mandated for both the cases. The following sections describe how a mesh can be avoided. 7.1 Control Connection -- Scalability As described in Section 4.6, mesh topology can be avoided by having a Tunnel Manager. 7.2 Per VPN Tunnels -- Scalability L2TP Tunnel Switching [L2TP-TSW], helps in avoiding the need for a tunnel mesh. Elwin, Brijesh, Benson [Page 8] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 8.0 Security Considerations This approach suggests the use of L2TP alone for the cases where security is implicitly addressed for the cases like private backbones. For the cases where security is needed, we recommend the use of L2TP over IPSec, as described in [RFC-3193]. 9.0 References [BGP-AUTO] Ould-Brahim H., et al., "Using BGP as an Auto-Discovery Mechanism for Network Based VPNs", Work in progress, draft-ietf-ppvpn-bgpvpn-auto-02.txt [L2TP-BASE] Lau J., et al., "Layer Two Tunneling Protocol, L2TP", Work in progress, draft-ietf-l2tpext-l2tp-base-01.txt [L2TP-EXT] Stelzer E., Gowda N., "L2TP Extensions for PPVPN", Work in progress, draft-elwin-l2tpext-ppvpn-00.txt [L2TP-MLT] Bourdon G., "L2TP Multicast Extension", Work in progress, draft-ietf-l2tpext-mcast-01.txt [L2TP-TSW] Jain V., et al., "L2TP Tunnel Switching", Work in progress, draft-ietf-l2tpext-tunnel-switching-01.txt [PPVPN-FW] Callon R., et al., "A Framework for Provider Provisioned Virtual Private Networks", Work in progress, draft-ietf-ppvpn-framework-03.txt [PPVPN-L2] Rosen E., et al., "An Architecture for L2VPNs", Work in progress, draft-ietf-ppvpn-l2vpn-00.txt [PPVPN-RQ] Carugi M., et al., "Service Requirements for Provider Provisioned Virtual Private Networks", Work in progress, draft-ietf-ppvpn-requirements-03.txt [PPVPN-SEC] Gleeson B., "Uses of IPSec with Provider Provisioned VPNs", Work in progress, draft-gleeson-ipsec-ppvpn-01.txt [PPVPN-VR] Ould-Brahim H., et al., "Network based IP VPN Architecture using Virtual Routers", draft-ietf-ppvpn-vpn-vr-01.txt [RFC-2401] Kent S., Atkinson R., "Security Architecture for the Internet Protocol", RFC2401, November 1998. [RFC-2547] Rosen E., Rekhter Y., "BGP/MPLS VPNs", RFC2547, March 1999. Elwin, Brijesh, Benson [Page 9] draft-elwin-ppvpn-l2tp-arch-00 PPVPN Architecture Using L2TP Feb 2002 [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [RFC-2917] Muthukrishnan K., Malis A., "A Core MPLS IP VPN Architecture", RFC2917, September 2000. [RFC-3193] Patel B., et al., "Securing L2TP using IPSec", RFC3193, November 2001. 10.0 Acknowledgments To be added. 11.0 Author's Addresses Elwin Stelzer Eliazer Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 Email: elwinietf@yahoo.com Brijesh Kumar Corona Networks, Inc. 630 Alder Drive Milpitas, CA 95035 Email: brijesh@coronanetworks.com Benson Schliesser SAVVIS Communications 717 Office Parkway St. Louis, MO 63141 Email: bensons@savvis.net Elwin, Brijesh, Benson [Page 10]