idnits 2.17.1 draft-elwin-ppvpn-l2tp-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8106 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-2026' is mentioned on line 16, but not defined == Unused Reference: 'L2TP-BASE' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'PPVPN-L2' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'PPVPN-RQ' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'PPVPN-VR' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC-2401' is defined on line 408, but no explicit reference was found in the text -- No information found for draft-ietf-ppvpn-bgpvpn-auto - is the name correct? == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-01 == Outdated reference: A later version (-05) exists of draft-ietf-l2tpext-mcast-01 == Outdated reference: A later version (-08) exists of draft-ietf-l2tpext-tunnel-switching-01 -- No information found for draft-ietf-ppvpn-framework - is the name correct? -- No information found for draft-ietf-ppvpn-requirements - is the name correct? -- Unexpected draft version: The latest known version of draft-gleeson-ipsec-ppvpn is -00, but you're referring to -01. (However, the state information for draft-ietf-ppvpn-requirements is not up-to-date. The last update was unsuccessful) -- No information found for draft-ietf-ppvpn-vpn-vr - is the name correct? ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Provider Provisioned VPN WG Elwin Eliazer (Corona) 2 Internet Draft Brijesh Kumar (Corona) 3 Benson Schliesser (SAVVIS) 4 Category: Informational 5 Expiration Date: August 2002 6 February 2002 8 PPVPN Architecture using L2TP 10 draft-elwin-ppvpn-l2tp-arch-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [RFC-2026]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document discusses the use of L2TP for establishing PPVPNs. It 34 proposes to use L2TP for VPN membership, topology discovery, and as a 35 tunneling mechanism. The basic idea is based on leveraging the inherent 36 strengths of L2TP for tunneling traffic, and extend the same advantages 37 to PPVPNS. The mechanism is applicable for both Layer2 and Layer3 38 PPVPNs. 40 ID Summary 42 RELATED DOCUMENTS 44 See References section below. 46 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 48 This ID fits the PPVPN box. 50 WHY IS IT TARGETED AT THIS WG 52 This ID describes a tunneling and discovery mechanism for PPVPNs, 53 which comes under the charter of this WG. 55 JUSTIFICATION 57 This ID describes a tunneling and discovery mechanism for PPVPNs, 58 which comes under the charter of this WG. 60 Table of Contents 62 1.0 Introduction ................................................ 3 63 2.0 L2TP for PPVPN Tunneling .................................... 3 64 3.0 Merits and demerits with this approach ...................... 4 65 3.1 Merits ...................................................... 4 66 3.2 Demerits .................................................... 5 67 4.0 PPVPN Services Using L2TP ................................... 5 68 4.1 VPN Membership Discovery .................................... 5 69 4.2 VPN Topology ................................................ 5 70 4.3 Tunnel Setup ................................................ 6 71 4.4 Keepalive ................................................... 6 72 4.5 Tunnel Authentication ....................................... 6 73 4.6 Control Connection Topology ................................. 6 74 5.0 Applications ................................................ 7 75 5.1 OSPF/L2TP VPNs .............................................. 7 76 5.2 Ethernet/L2TP VPNs and other L2 VPNs ........................ 7 77 5.3 Remote Access L2TP/IPSec VPNs ............................... 7 78 5.4 IPv6/L2TP VPNs .............................................. 7 79 6.0 Comparison with other approaches ............................ 7 80 6.1 Other tunneling methods ..................................... 7 81 6.2 Other VPN discovery methods ................................. 8 82 7.0 Scalability Considerations .................................. 8 83 7.1 Control Connection -- Scalability ........................... 8 84 7.2 Per VPN Tunnels -- Scalability .............................. 8 85 8.0 Security Considerations ..................................... 9 86 9.0 References .................................................. 9 87 10.0 Acknowledgments ............................................. 10 88 11.0 Author's Addresses .......................................... 10 89 1.0 Introduction 91 The establishment of a PPVPN require three basic mechanisms: VPN 92 membership and topology discovery, tunnel signaling and establishment, 93 and route distribution [PPVPN-FW]. Currently, three different 94 approaches have been proposed for distributing VPN discovery 95 information: 96 (a) manual or SNMP based configurations at each PE 97 (b) centralized directory or database servers 98 (c) piggybacking onto a routing protocol such as BGP. 100 In this document, we make two new proposals. The first proposal is to 101 use L2TP as a PPVPN tunneling protocol so that the benefits of L2TP as 102 a tunneling mechanism for a variety of traffic classes are available to 103 PPVPNs too. Secondly, we propose the use of L2TP to carry VPN discovery 104 information as with simple extensions to L2TP, it can fulfill this role 105 very effectively. Unlike extending a complex routing protocol such as 106 BGP, L2TP extensions add no complexity to routing protocols, and 107 carriers aren't forced to use BGP based discovery mechanisms for all 108 their VPNs. 110 L2TP, a protocol originally meant to tunnel PPP, has decoupled itself 111 from PPP, and currently can tunnel a variety of payload. The rich set 112 of tunnel managment functions offered by L2TP is a valid candidate for 113 PPVPN tunneling. 115 The use of L2TP for VPN discovery and tunneling has a second benefit 116 that any IGP can be used for VPN related route distribution between two 117 PEs. One is not forced to use BGP for route distribution as is the case 118 with some proposals such as BGP/MPLS VPNs in [RFC-2547]. 120 2.0 L2TP for PPVPN Tunneling 122 PPVPNs inherently need a tunneling mechanism to tunnel over the public 123 backbone. Signaling these tunnels reduces the amount of configuration 124 needed in setting up and tearing down these tunnels. L2TP, a protocol 125 originally meant to tunnel PPP, has decoupled itself from PPP, and 126 currently can tunnel a variety of payload. The rich set of tunnel 127 management functions offered by L2TP is a valid candidate for PPVPN 128 tunneling. 130 Here we discuss the merits and demerits in using L2TP, to provide both 131 Layer2 and Layer3 VPNs. We also suggest some simple extensions that 132 can be made to L2TP which can help in PPVPN solutions. 134 Note: 135 VFI = Virtual Forwarding Instance. Refers to Layer-3 Virtual Router. 136 VSI = Virtual Switching Instance. Refers to a Layer-2 Virtual Bridge. 137 This terminology is used in the PPVPN requirement and framework docs. 139 PE PE 140 +--------------+ +--------------+ 141 +--------+ | +----------+ | L2TP | +----------+ | +--------+ 142 | VPN-A | | | VPN-A | | Tunnel | | VPN-A | | | VPN-A | 143 | Site |----| VFI/ |=================| VFI/ |---| site | 144 +--------+ | | VSI | | | | VSI | | +--------+ 145 | +----------+ | | +----------+ | 146 | | | | 147 +--------+ | +----------+ | L2TP | +----------+ | +--------+ 148 | VPN-B | | | VPN-B | | Tunnel | | VPN-B | | | VPN-B | 149 | Site |----| VFI/ |=================| VFI/ |---| site | 150 +--------+ | | VSI | | | | VSI | | +--------+ 151 | +----------+ | | +----------+ | 152 | | | | 153 +--------+ | +----------+ | L2TP | +----------+ | +--------+ 154 | VPN-C | | | VPN-C | | Tunnel | | VPN-C | | | VPN-C | 155 | Site |----| VFI/ |=================| VFI/ |---| site | 156 +--------+ | | VSI | | | | VSI | | +--------+ 157 | +----------+ | | +----------+ | 158 +--------------+ +--------------+ 160 Figure 1: Reference Model 162 3.0 Merits and demerits with this approach 164 3.1 Merits 166 + L2TP provides a good tunneling mechanism with an associated signaling 167 protocol. The payload can carry IPv4 or IPv6 for L3 VPNs, or any L2 168 for L2 VPNs. 170 + The tunnel encapsulation header has a hierarchical demultiplexing 171 capability. 173 + Keepalive for the tunnels are available. 175 + Tunnel authentication is also available. 177 + Tunneling is over IP and hence can work in both IP and MPLS networks. 179 + Can work with IPSec in transport mode when security is needed. Thus 180 IPSec can be made optional, based on the need. 182 + Tunnel virtual interfaces can emulate real interfaces. If needed, any 183 routing protocol can be run over this dynamic interface. 185 + Decouples tunneling and VPN discovery, from learning of VPN routes. 187 + L2TP Tunnel Switching can help in arriving at complex topologies. 189 + VPN discovery and setup of tunnels can be automatically signaled with 190 simple extensions. 192 + Because keepalives are available, remote tunnel endpoint liveness can 193 be easily detected. This could be of significant benefit, for VFIs 194 and VSIs that are configured with static routes/forward entries. 196 3.2 Demerits 198 - L2TP, as it is widely deployed today is over UDP. This increases the 199 PE processing, and also increases the encapsulation header size. There 200 are means to bypass the UDP in L2TP, which is recommended for PPVPNs. 202 - L2TP tunnels, are inherently point-to-point tunnels. There is a 203 proposal in L2TPext WG to support multicast tunnels. This will have to 204 be explored for multipoint tunnels. Refer [L2TP-MLT]. 206 4.0 PPVPN Services Using L2TP 208 4.1 VPN Membership Discovery 210 The VPN-ID format as defined in [RFC-2685] is used to identify a VPN. 211 All VFIs/VSIs that are members of a specific VPN share the same VPN-ID. 213 L2TP control connection is made across each PE devices, in the case of 214 fully mesh topology for control connections. Refer Section 3.6 for other 215 control connection topologies. 217 VPN AVP in the L2TP Hello messages are used to determine any new VFI or 218 VSI for a VPN coming up. Thus each PE gets to know the other PEs that 219 have VFIs or VSIs corresponding to the VPNs it supports. 221 [L2TP-EXT] describe the L2TP extensions needed in detail. 223 4.2 VPN Topology 225 The desired VPN topology information for each PPVPN VFI/VSI can be 226 specified as part of the VFI/VSI configuration. 228 Following topology values are defined: 229 "Hub" -- Connects (tunnel) to all the spoke VFIs/VSIs 230 "Spoke" -- connects only to the hub VFI/VSI 231 "Mesh" -- connects to all the other member VFIs/VSIs 233 Other topologies are to be handled in a similar way. 235 The tunnel switching capability in L2TP also help in defining the 236 topology. 238 4.3 Tunnel Setup 240 Per VPN L2TP tunnel setup across each VFI (or VSI) pair is initiated by 241 L2TP when it receives the membership and topology information. 243 If the PEs decide to use the same tunnel IP address for multiple VFIs or 244 VSIs, the tunnel/session ID in L2TP can be used for multiplexing. 246 The tunnel endpoint IP addresses is learnt as part of the VPN membership 247 discovery. 249 If security is needed on these tunnels, IPSec in transport mode is used 250 on these L2TP encapsulated packets. Refer [RFC-3193]. 252 4.4 Keepalive 254 The Hello messages in L2TP can be used to determine the control 255 connection as well as the per VPN tunnel status. 257 4.5 Tunnel Authentication 259 The per VPN tunnels and the control connections can be authenticated 260 with the L2TP tunnel authentication methods, when the tunnels are setup. 262 4.6 Control Connection Topology 264 The control connection tunnels are different from the per VPN tunnels, 265 and they can have different tunnel endpoints. 267 To have control connections in a hub and spoke topology, a designated 268 Tunnel Manager is chosen as the hub. This can be a PE or any device that 269 is reachable to the PEs. All the spoke PEs are configured with the 270 Tunnel Manager's IP address, as the control connection peer. The tunnel 271 manager then resolves the perVPN tunnel endpoints, and lets the PEs 272 setup the per VPN tunnels directly. 274 This can be extended with L2TP tunnel switching [L2TP-TSW]to achieve 275 more complex topologies. 277 5.0 Applications 279 This approach is useful, but is not limited to, the applications listed 280 in the following subsections. 282 5.1 OSPF/L2TP VPNs 284 OSPF running at the individual VPN sites, are connected together by the 285 per-VPN tunnels provided by L2TP. 287 5.2 Ethernet/L2TP VPNs and other L2 VPNs. 289 Ethernet coming from the CEs of the VPN sites, are connected together by 290 the per-VPN tunnels provided by L2TP. Similar approach is used for other 291 L2s: Frame-relay, ATM, etc. 293 5.3 Remote Access L2TP/IPSec VPNs 295 Roaming or mobile remote access VPN clients, can access VPN nodes, by 296 reaching a PE VFI using L2TP/IPSec tunnels. This can be directly 297 handled in this model. 299 5.4 IPv6/L2TP VPNs 301 Islands of IPv6 networks, can be transported over a L2TP tunnel 302 transparently so as to have a connected IPv6 network. 304 6.0 Comparison with other approaches 306 6.1 Other tunneling methods 308 IPIP tunnels: 309 This provides a simple tunnel encapsulation method. The disadvantages 310 are: 311 - It has no associated signaling protocol. 312 - It has no demultiplexing field. 313 - There is no mechanism to determine the liveness of the tunnel 314 enpoint, since there is no keepalive. 316 GRE tunnels: 317 Though this provides a demultiplexing field, this has no associated 318 signaling protocol, and hence relies on external means to setup the 319 tunnels. And no way to determine the liveness of a tunnel. 321 IPSec tunnels: [PPVPN-SEC] 322 With IPSec tunnels, either AH or ESP needs to be done and can not be 323 made optional due to security reasons. These are operations involving 324 scanning of the complete payload and hence expensive. 325 The other disadvantage is with the associated signaling protocol, IKE. 326 IKE is not flexible for new additions and is not a protocol meant for 327 setting up generic tunnels. 329 MPLS tunnels: [RFC-2547] 330 The problem with using MPLS tunnels is that it needs MPLS networks. 331 Another disadvantage is that there is no means to determine the 332 liveness of a tunnel, due to lack of keepalive mechanism. 334 6.2 Other VPN discovery methods 336 BGP-based Discovery: [BGP-AUTO] 337 This method suggests extensions to BGP to enable VPN discovery. 338 For cases where BGP is not involved, this is an unnecessary 339 involvement of BGP. For example, a Ethernet L2 VPN, do not need BGP 340 to do VPN discovery. 342 Multicast-based Discovery: [RFC-2917] 343 This discovery method is based on multicasting, and hence assumes 344 multicast enabled backbone, which is most of the times inappropriate. 346 7.0 Scalability Considerations 348 Both the Control Connection tunnels and Per VPN tunnels should be 349 scalable to have a scalable PPVPN solution. The main scalability issue 350 arises when a mesh topology is mandated for both the cases. The 351 following sections describe how a mesh can be avoided. 353 7.1 Control Connection -- Scalability 355 As described in Section 4.6, mesh topology can be avoided by having a 356 Tunnel Manager. 358 360 7.2 Per VPN Tunnels -- Scalability 362 L2TP Tunnel Switching [L2TP-TSW], helps in avoiding the need for a 363 tunnel mesh. 365 366 8.0 Security Considerations 368 This approach suggests the use of L2TP alone for the cases where 369 security is implicitly addressed for the cases like private backbones. 370 For the cases where security is needed, we recommend the use of L2TP 371 over IPSec, as described in [RFC-3193]. 373 9.0 References 375 [BGP-AUTO] Ould-Brahim H., et al., "Using BGP as an Auto-Discovery 376 Mechanism for Network Based VPNs", Work in progress, 377 draft-ietf-ppvpn-bgpvpn-auto-02.txt 379 [L2TP-BASE] Lau J., et al., "Layer Two Tunneling Protocol, L2TP", 380 Work in progress, draft-ietf-l2tpext-l2tp-base-01.txt 382 [L2TP-EXT] Stelzer E., Gowda N., "L2TP Extensions for PPVPN", Work in 383 progress, draft-elwin-l2tpext-ppvpn-00.txt 385 [L2TP-MLT] Bourdon G., "L2TP Multicast Extension", Work in progress, 386 draft-ietf-l2tpext-mcast-01.txt 388 [L2TP-TSW] Jain V., et al., "L2TP Tunnel Switching", Work in progress, 389 draft-ietf-l2tpext-tunnel-switching-01.txt 391 [PPVPN-FW] Callon R., et al., "A Framework for Provider Provisioned 392 Virtual Private Networks", Work in progress, 393 draft-ietf-ppvpn-framework-03.txt 395 [PPVPN-L2] Rosen E., et al., "An Architecture for L2VPNs", Work in 396 progress, draft-ietf-ppvpn-l2vpn-00.txt 398 [PPVPN-RQ] Carugi M., et al., "Service Requirements for Provider 399 Provisioned Virtual Private Networks", Work in progress, 400 draft-ietf-ppvpn-requirements-03.txt 402 [PPVPN-SEC] Gleeson B., "Uses of IPSec with Provider Provisioned VPNs", 403 Work in progress, draft-gleeson-ipsec-ppvpn-01.txt 405 [PPVPN-VR] Ould-Brahim H., et al., "Network based IP VPN Architecture 406 using Virtual Routers", draft-ietf-ppvpn-vpn-vr-01.txt 408 [RFC-2401] Kent S., Atkinson R., "Security Architecture for the 409 Internet Protocol", RFC2401, November 1998. 411 [RFC-2547] Rosen E., Rekhter Y., "BGP/MPLS VPNs", RFC2547, March 1999. 413 [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 414 2685, September 1999. 416 [RFC-2917] Muthukrishnan K., Malis A., "A Core MPLS IP VPN 417 Architecture", RFC2917, September 2000. 419 [RFC-3193] Patel B., et al., "Securing L2TP using IPSec", RFC3193, 420 November 2001. 422 10.0 Acknowledgments 424 To be added. 426 11.0 Author's Addresses 428 Elwin Stelzer Eliazer 429 Corona Networks, Inc. 430 630 Alder Drive 431 Milpitas, CA 95035 432 Email: elwinietf@yahoo.com 434 Brijesh Kumar 435 Corona Networks, Inc. 436 630 Alder Drive 437 Milpitas, CA 95035 438 Email: brijesh@coronanetworks.com 440 Benson Schliesser 441 SAVVIS Communications 442 717 Office Parkway 443 St. Louis, MO 63141 444 Email: bensons@savvis.net