idnits 2.17.1 draft-duffy-ppvpn-ipsec-vlink-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? == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2002) is 7865 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'LORDELLO' is mentioned on line 332, but not defined -- No information found for draft-ietf-ppvpn-ce-based - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) == Outdated reference: A later version (-03) exists of draft-knight-ppvpn-ipsec-dynroute-01 == Outdated reference: A later version (-07) exists of draft-touch-ipsec-vpn-04 -- No information found for draft-ietf-ppvpn-vpn-vr - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Duffy 2 Internet Draft Quarry Technologies 3 Expires: April 2003 October 2002 5 Framework for IPsec Protected Virtual Links for PPVPNs 7 draft-duffy-ppvpn-ipsec-vlink-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress/" 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This memo explores some choices that arise when IPsec is to be used 33 to implement secure "virtual links" interconnecting customer premises 34 VPN devices and/or network based virtual routers. The main focus is 35 on the network based cases. 37 Requirements are proposed and some relevant aspects of the IPsec 38 protocol suite are discussed. A number of different protocol 39 architectures for virtual links are then evaluated. 41 This memo is informational in nature; it is intended that it will 42 focus discussion toward a standard in this area. 44 Table of Contents 46 1. Introduction...................................................2 47 2. Terminology Used in This Document..............................3 48 3. Virtual Link Objectives........................................3 49 4. Protocol Functions Needed to Implement Virtual Links...........4 50 5. IPsec Considerations...........................................5 51 5.1 Tunnel Mode vs. Transport Mode.............................5 52 5.2 The Security Policy Database (SPD).........................5 53 5.3 VPN Context Correlation....................................7 54 6. Some Possible Protocol Architectures...........................8 55 6.1 Tunnel Mode SA as Virtual Link.............................8 56 6.2 Shared IP-in-IP Tunnel with Transport Mode IPsec...........9 57 6.3 Distinct IP-in-IP Tunnel with Transport Mode IPsec.........9 58 6.4 GRE Tunnel with Transport Mode IPsec......................10 59 6.5 MPLS Tunnel with Transport Mode IPsec.....................11 60 6.6 L2TP with Transport Mode IPsec............................11 61 7. Recommendation................................................12 62 8. Security Considerations.......................................12 63 9. References....................................................13 64 9.1 Normative References......................................13 65 9.2 Informative References....................................13 66 10. Summary for Sub-IP Related Internet Drafts...................14 67 Author's Addresses...............................................14 68 Full Copyright Statement.........................................14 70 1. Introduction 72 A number of different technologies have been identified for 73 implementing Provider Provisioned Virtual Private Networks (PPVPNs). 74 Among the options for providing VPN services at layer 3 are virtual 75 router based VPNs, CE-based IPsec VPNs, and BGP/MPLS VPNs. All three 76 types can capitalize on the creation of IPsec-protected virtual links 77 between VPN-aware nodes at the edge of the network (either PE or CE 78 based). Both the virtual router approach and the dynamically routed 79 flavor of CE-based IPsec approach require a virtual link mechanism, 80 while the reach of BGP/MPLS VPNs can be extended by using virtual 81 links to include remote sites. 83 Although all these VPN types can use virtual links that carry IP 84 packets across an IP network the VR-based L3 VPN overlay environment 85 [VR-VPN] is the most demanding in terms of a solution. This is 86 because the VR approach requires a virtual link solution that 87 simultaneously supports multiple links for multiple contexts, between 88 a given pair of devices. 90 A number of drafts have been published dealing with the CE-CE case 91 but there has not been much discussion of the VR (multi-context) 92 case. 94 This memo assumes some familiarity with the IPsec protocol suite 95 including [IPSEC] and [IKE]. 97 The principal content of this memo is organized as follows: Section 98 3 lists some desirable properties of a virtual link mechanism. 99 Section 4 describes protocol functions a virtual link system must 100 perform. Section 5 explains some aspects of IPsec that must be 101 considered in using IPsec as a component of a secure virtual link 102 solution. Section 6 presents and evaluates a number of potential 103 protocol architectures. 105 2. Terminology Used in This Document 107 CE: Customer Edge router 108 PE: Provider Edge router 109 Tunnel ingress node: A system or device that transmits packets 110 into a tunnel 111 Tunnel egress node: A system or device that receives packets from 112 a tunnel 113 Tunnel endpoint: Either a tunnel ingress node or a tunnel 114 egress node 116 3. Virtual Link Objectives 118 For purposes of this memo we define a virtual link as a construct 119 that provides a point-to-point link layer service implemented over an 120 IP network. Each end of a virtual link terminates as an IP interface 121 of a router or virtual router (VR), which may form routing 122 adjacencies and forward IP packets over the link. 124 The following are viewed as important properties for virtual links: 126 - Support multiple independent virtual links between a given pair 127 of systems (e.g. PE devices) serving different contexts (e.g. 128 different VR pairs). 130 - Provide IPsec security services for each virtual link including 131 integrity, data origin authentication, protection against replays, 132 and confidentiality. 134 - Provide a choice of using IPsec or not, with per-VPN-context and 135 per-remote-PE granularity. 137 - Support interoperation of network-based (PE-based) virtual 138 routers with Provider Provisioned CE based IPsec VPN devices. 140 - Operate in systems that simultaneously use IPsec for other 141 purposes. 143 - Require no new protocol development and minimum extensions to 144 existing protocols. 146 4. Protocol Functions Needed to Implement Virtual Links 148 Virtual links are implemented using tunneling technologies. A 149 tunnel, by means of encapsulation, provides isolation for packets 150 sent through it. It thus allows packets to traverse domains they 151 could perhaps not traverse natively, or to be delivered to 152 intermediate destinations not implied by their destination addresses. 154 Besides encapsulation, tunneling for virtual links requires: 156 - Multiplexing. The ability to support and distinguish multiple 157 logical streams of data within a tunnel and/or the ability to support 158 and distinguish multiple tunnels between a pair of tunnel endpoints. 159 In fact, the two abilities are logically equivalent and differ only 160 by which entity one applies the term "tunnel" to. In the remainder 161 of this document we shall use the word tunnel in the latter sense 162 i.e. a tunnel carries packets for one VPN context but there may be 163 multiple tunnels between a given pair of tunnel endpoints. 165 - Tunnel management (setup/maintenance/teardown) signalling. This 166 allows the tunnel endpoints to be explicitly aware of whether a 167 particular tunnel is present or not and perhaps whether it has 168 connectivity (liveliness). In cases where the tunnel mechanism 169 itself does not provide liveliness detection, dynamic routing 170 protocols, if used, can provide this function. 172 - VPN context correlation. The ability to determine, at the 173 tunnel egress node, what application and context each received packet 174 is intended for. The term "application" here refers to any one of 175 perhaps several functional areas in the node that use tunnels, e.g. 176 virtual link, IPsec security gateway, etc. The "context," for the 177 virtual link application, is a particular VPN i.e. as identified by a 178 [VPN-ID]. Correlation may be done packet by packet in a 179 connectionless manner, however this is likely to impose a high 180 overhead cost. An alternative, available with connection-oriented 181 tunneling technologies, is to establish the correlation on a per- 182 tunnel basis at tunnel setup time, binding the context identification 183 to a more compact multiplexing field that is transmitted on a per- 184 packet basis. 186 Support for Path MTU Discovery and for Quality of Service (QoS) on 187 virtual links are important but are not considered in this memo. 188 Reliable or in-order delivery are not required. 190 5. IPsec Considerations 192 This section explores a number of choices and issues that must be 193 addressed to use IPsec for virtual links. Although these are 194 separate issues they interrelate heavily with one another. 196 5.1 Tunnel Mode vs. Transport Mode 198 IPsec may be used in two different encapsulation modes: IPsec tunnel 199 mode provides in-IP tunneling as a package deal with the security 200 protocol. IPsec transport mode does not provide tunneling. In a 201 virtual link application, IPsec transport mode is of necessity used 202 in conjunction with some other in-IP tunneling protocol for an 203 overall solution. 205 At first glance tunnel mode seems attractive because it appears to be 206 a one stop shop providing encapsulation, multiplexing, and (via IKE) 207 explicit tunnel management. However, there are difficulties with the 208 semantics of the security policy and with VPN context correlation, as 209 described in the following subsections. 211 Decoupling tunneling and IPsec and providing them independently 212 yields greater modularity, generally recognized as a Good Thing. 213 Keeping tunneling and IPsec separate also allows for selective use of 214 IPsec since the needed virtual link functions of encapsulation, 215 multiplexing, tunnel management, and correlation are provided 216 separately and there is no reliance on IPsec for these services. 218 5.2 The Security Policy Database (SPD) 220 IPsec uses the IKE protocol to negotiate Security Associations (SAs) 221 and their keying. A fundamental aspect of this is the Quick Mode 222 negotiation, via Client IDs, of the access control policy (packet 223 selectors) for each IPsec SA. IPsec devices base this negotiation on 224 their provisioned Security Policy Databases (SPDs). A nominally 225 separate SPD exists for each interface on which IPsec is to run. 227 The access control policy is one of the basic security services 228 provided by IPsec. It is packet classification against this policy 229 that controls which packets are sent on, or must be received on, a 230 given SA. By contrast, when using virtual links, we generally want 231 to use a routing decision to determine which packets are sent on a 232 given virtual link, and we generally don't require validation that 233 packets were received from a "correct" link. In a sense, we want a 234 service that is like link-level encryption (, authentication, etc.) 235 for the virtual link. Thus, we have a mismatch between the way IPsec 236 works and the way we want virtual links to work. The nature and 237 extent of this mismatch depends in large part of the relationship 238 between IPsec SAs and virtual links: *Is* a tunnel mode SA the 239 virtual link, or does the virtual link have an existence of its own 240 to which transport mode IPsec may be applied? 242 5.2.1 Tunnel Mode IPsec and the SPD 244 If IPsec tunnel mode is used to implement a virtual link we would 245 expect the negotiated selectors to apply to the headers of the "inner 246 packets" e.g. the packets of the VPN. Generally, these packets will 247 be assigned to virtual links based on dynamic routing state and 248 therefore the set of packets to be sent over a particular virtual 249 link are not known a priori. From the point of view of IPsec policy, 250 this is essentially an arbitrary set of packets. What is needed then 251 is an SA that will carry any packets -- an SA whose selectors are all 252 wildcards. However, when multiple virtual links are required between 253 the same pair of tunnel endpoints (e.g. for multiple VPN contexts) 254 multiple SAs with the same wildcard client IDs must be negotiated. 255 Classic IPsec will not generally negotiate multiple SAs out of a 256 given SPD, those SAs having the same client IDs, since in the classic 257 case it has no way to determine which to use for a given outgoing 258 packet. Resolving this requires a slightly liberal interpretation of 259 IPsec, to have an SPD per virtual interface. Unfortunately, it then 260 becomes problematic for the IKE responder to determine which SPD to 261 evaluate an incoming proposal against; this is discussed in section 262 5.3. 264 5.2.2 Transport Mode IPsec and the SPD 266 If another protocol is used to implement the tunnels, with IPsec 267 applied in transport mode, we have essentially positioned the routing 268 and tunneling a layer above IPsec. In this case then the negotiated 269 IPsec selectors might reasonably be expected to apply to the packet 270 headers of the "outer packets" of the tunnel e.g. the GRE, L2TP, IP- 271 in-IP, etc. packets. The selectors match the endpoint addresses of 272 the tunnel and the tunnel protocol. There is no need to create 273 multiple SAs with the same client IDs, and no need for an SPD per 274 virtual interface. 276 This would seem to be a better match with the access control 277 functions of IPsec. However, if IPsec is controlled solely by 278 evaluating SPD policy against already-encapsulated packets, it cannot 279 provide much in the way of differentiated protection. In particular, 280 if the tunneling mechanism used is such that all tunnels between a 281 pair of systems have the same outer addresses, protocol, and ports, 282 then we cannot use the SPD to meet the goal of selecting IPsec on a 283 per-VPN basis. 285 5.2.3 A Hybrid Transport Mode Approach 287 Another possibility is to use a separate tunneling protocol with 288 transport mode IPsec, but negotiate and apply IPsec policy on the 289 "inner" packets. This opens the possibility for a richer range of 290 differentiated protection than the basic transport mode approach (in 291 which the selectors of packets in the tunnel are invariant). 292 However, this requires a very liberal interpretation of IPsec. As 293 such, it may be difficult to implement in some environments and it 294 may engender strong objections from the IPsec community. 296 5.3 VPN Context Correlation 298 For a system that is maintaining multiple contexts (e.g. multiple 299 virtual routers) and which may therefore maintain multiple virtual 300 links to a given remote system, it is essential that there be a way 301 to determine at the downstream end which links are for which 302 contexts. In the cases where IPsec SAs are used to multiplex the 303 virtual links this implies a need to determine which of potentially 304 multiple IPsec applications in the system (e.g. Security Gateway 305 service, IPsec-protected virtual links, etc.) a given SA is for. For 306 those SAs intended for virtual links, it is further necessary to 307 associate them with the correct VPN context. 309 Several recent Internet-Drafts ([CE-VPN], [TOUCH], [KNIGHT]) have 310 discussed this area but they are all focused on the CE-based VPN case 311 and do not address the multiplexing of multiple contexts between a 312 pair of PE devices. They do address the question of determining 313 whether an SA is for a virtual link or not. These drafts propose 314 adopting the following convention: an IKE proposal for transport 315 mode IPsec for protocol IP-in-IP and client IP addresses that match 316 the IKE endpoint addresses implies that the tunnel will be viewed as 317 a virtual link and routing adjacencies may be formed on it. This 318 convention is expedient, but it is implicit rather than explicit, and 319 it relies on an expectation that existing systems are not already 320 using such proposals under other circumstances. Also, it is not 321 extensible to cover other possible applications. 323 There are several ways that correlation info (e.g. a VPN-ID) could be 324 passed explicitly from the IKE initiator (which presumably knows it) 325 to the responder (which needs to know it) and bound to a particular 326 SA they negotiate. Vendor specific payloads could be defined to 327 carry the application identifier (e.g. virtual link) and the context 328 (e.g. VPN-ID) in IKE. However, vendor specific payloads are not a 329 good approach to standardization. New standardized IKE payloads 330 could be defined, but this is unlikely to happen for IKE given the 331 current focus of the IPsec working group on developing its successor. 332 The now-expired [LORDELLO] proposed defining such new payloads within 333 a new ISAKMP Domain of Interpretation (DOI). 335 It is also possible to pass the correlation info implicitly from 336 initiator to responder, by addressing the IKE proposal to different 337 IP addresses belonging to the responder and/or by presenting 338 different initiator addresses or IKE identities belonging to the 339 initiator. This approach has a number of disadvantages: it is crude, 340 and it requires the maintenance of a tunnel endpoint IP address per 341 VPN context. Even at that it does not convey a VPN identification in 342 absolute terms; rather, coordinated provisioning is still needed at 343 both ends to establish which IP address corresponds with which VPN- 344 ID, etc. Furthermore, the scalability is severely decreased because 345 this forces a separate (and computationally expensive) ISAKMP SA to 346 be needed for each context. 348 6. Some Possible Protocol Architectures 350 This section presents six different approaches to constructing 351 virtual links secured by IPsec. Each is evaluated against the 352 requirements and considerations described in the preceding sections. 354 6.1 Tunnel Mode SA as Virtual Link 356 This approach uses a tunnel mode IPsec SA to realize each virtual 357 link. Multiple virtual links between a pair of systems, serving 358 different contexts, may be negotiated under a single ISAKMP SA. The 359 client IDs are all-wildcarded. 361 Each IPsec SA is bound to a VPN-ID through a payload exchanged during 362 the Quick Mode negotiation. 364 Pros: 365 . This approach leverages the IKE Quick Mode as a tunnel management 366 protocol. 368 Cons: 369 . There is no IPsec-less (unsecured) operation available since it 370 relies on IPsec for tunneling. 372 . The current IKE standard does not define a payload to convey a 373 VPN-ID; this would require a vendor-specific payload, IKE 374 extension, etc. 375 . Requires the tunnel end points to support negotiating multiple 376 IPsec SAs with the same client IDs. 377 . Unlikely to interoperate with CE-based devices. 379 6.2 Shared IP-in-IP Tunnel with Transport Mode IPsec 381 This approach uses IP-in-IP tunneling [IP-IP] and a distinct 382 transport mode IPsec SA to realize each virtual link. Multiple 383 virtual links between a pair of systems use the same IP-in-IP tunnel 384 (i.e. the same endpoint addresses). A single ISAKMP SA between a 385 pair of systems is used. 387 Each virtual link uses a separate transport mode IPsec SA, but they 388 all have the same client IDs. It is the SA (i.e. the SPI field) that 389 distinguishes one virtual link from another. Each IPsec SA is bound 390 to a VPN-ID through a payload exchanged during the Quick Mode 391 negotiation. 393 Pros: 394 . This approach leverages the IKE Quick Mode as a tunnel management 395 protocol. 396 . Likely to interoperate with CE-based devices to form routing 397 adjacencies. 399 Cons: 400 . There is no IPsec-less (unsecured) operation available since it 401 relies on IPsec for multiplexing and for tunnel management 402 signaling. 403 . The current IKE standard does not define a payload to convey a 404 VPN-ID; this would require a vendor-specific payload, IKE 405 extension, etc. 406 . Requires the tunnel end points to support negotiating multiple 407 IPsec SAs with the same client IDs. 409 6.3 Distinct IP-in-IP Tunnel with Transport Mode IPsec 411 This approach uses a distinct IP-in-IP tunnel to realize each virtual 412 link. Multiple virtual links between a pair of systems use distinct 413 IP-in-IP tunnels (i.e. different endpoint addresses). Transport mode 414 IPsec is used to secure the tunnels, and the IKE also provides tunnel 415 management signaling. Each virtual link has its own distinct ISAKMP 416 and IPsec SAs. 418 Each virtual link terminates on a different tunnel endpoint (i.e. 419 "outer") IP address and it is this that distinguishes one virtual 420 link from another. The VPN context is bound to each tunnel endpoint 421 address through configuration, directory lookup, or VPN 422 autodiscovery. 424 Pros: 425 . This approach leverages the IKE Quick Mode as a tunnel management 426 protocol. 427 . Likely to interoperate with CE-based devices to form routing 428 adjacencies. This is the proposal of [KNIGHT] and [CE-VPN] 429 extended to multi-context systems. 431 Cons: 432 . There is no IPsec-less (unsecured) operation available since it 433 relies on IPsec for the tunnel management signaling. (Unless one 434 does not care about the tunnel management.) 435 . Requires recognizing, and terminating tunnels on, multiple IP 436 addresses (one per VPN context). 437 . Scales poorly because it requires an expensive ISAKMP SA per 438 virtual link. 439 . VPN context correlation requires an external means to associate 440 tunnel endpoint addresses to VPN-IDs and make the association 441 known at both tunnel endpoints. 443 6.4 GRE Tunnel with Transport Mode IPsec 445 This approach uses [GRE] to provide the tunneling. Using the Key 446 extension to GRE ([GRE-KEY]) multiple virtual links between a pair of 447 systems are multiplexed within one GRE tunnel. Transport mode IPsec 448 is used when desired to secure the GRE tunnel -- one ISAKMP and one 449 IPsec SA are used per PE pair. Application of IPsec is based on an 450 SPD rule matching the GRE (i.e. "outer") packet header. 452 A VPN context is bound to each Key value through configuration, 453 directory lookup, or VPN autodiscovery. 455 Pros: 456 . IPsec-less operation is available since the tunneling is provided 457 completely independently of IPsec. 458 . Requires neither extension nor liberal interpretation of IPsec. 460 Cons: 461 . Unlikely to interoperate with CE-based devices. 462 . No tunnel management protocol. 463 . VPN context correlation requires an external means to associate 464 GRE Key values to VPN-IDs and make the association known at both 465 tunnel endpoints. 466 . Controlling IPsec use on a per-VPN basis cannot be done within the 467 standard IPsec SPD model, since packets of different VPNs are not 468 discernible by the selectors available to IPsec (the outer GRE 469 packet). 471 6.5 MPLS Tunnel with Transport Mode IPsec 473 This approach uses MPLS-in-IP ([MPLS], [MPLS-IP]) to provide the 474 tunneling. Using an MPLS label in an IP encapsulation, multiple 475 virtual links between a pair of systems are multiplexed within one 476 MPLS-in-IP tunnel. Transport mode IPsec is used when desired to 477 secure the MPLS-in-IP tunnel -- one ISAKMP and one IPsec SA are used 478 per PE pair. Application of IPsec is based on an SPD rule matching 479 the MPLS-in-IP (i.e. "outer") packet header. 481 A VPN context is bound to each MPLS label value. MPLS labels might 482 be distributed by a label distribution protocol, or by configuration, 483 directory lookup, or piggybacked on autodiscovery. If a label 484 distribution protocol is used, that might serve as a tunnel 485 management protocol. 487 Pros: 488 . IPsec-less operation is available since the tunneling is provided 489 completely independently of IPsec. 490 . Requires neither extension nor liberal interpretation of IPsec. 492 Cons: 493 . Unlikely to interoperate with CE-based devices. 494 . VPN context correlation requires an external means to associate 495 MPLS labels to VPN-IDs and make the association known at both 496 tunnel endpoints. 497 . Controlling IPsec use on a per-VPN basis cannot be done within the 498 standard IPsec SPD model, since packets of different VPNs are not 499 discernible by the selectors available to IPsec (the outer MPLS- 500 in-IP packet). 502 6.6 L2TP with Transport Mode IPsec 504 This approach uses [L2TP] to provide the tunneling. Using L2TP 505 sessions carrying PPP sessions, multiple virtual links between a pair 506 of systems are multiplexed within one L2TP tunnel. Transport mode 507 IPsec is used when desired to secure the tunnel -- one ISAKMP and one 508 IPsec SA are used per PE pair. Application of IPsec is based on an 509 SPD rule matching the L2TP (i.e. "outer") packet header. 511 A VPN context is bound to each L2TP session via the exchange of L2TP 512 AVPs (e.g. the End Identifier AVP of L2TPv3 -- a similar AVP could be 513 defined for L2TPv2). 515 Pros: 517 . IPsec-less operation is available since the tunneling is provided 518 completely independently of IPsec. 519 . Requires neither extension nor liberal interpretation of IPsec. 520 . The L2TP control protocol serves as a tunnel management protocol. 521 . Other helpful PPP and L2TP features are available such as address 522 negotiation, keepalives, etc. 524 Cons: 525 . Unlikely to interoperate with CE-based devices. 526 . Controlling IPsec use on a per-VPN basis cannot be done within the 527 standard IPsec SPD model, since packets of different VPNs are not 528 discernible by the selectors available to IPsec (the outer L2TP 529 packet). 531 7. Recommendation 533 The PPVPN working group should develop a standard for IPsec-protected 534 virtual links for the PE-PE environment and one for the CE-CE 535 environment. If those standards can be one and the same or if the 536 CE-CE one can be a subset of the other it would be a plus. 538 Of the approaches advanced in this memo, the L2TP based approach 539 (section 6.6) appears to provide the nicest characteristics for the 540 PE-PE case. However, vendors of CPE equipment are unlikely to 541 embrace this approach for the CE-CE case. Also, it is arguably a bit 542 on the heavyweight side. 544 The distinct IP-in-IP tunnel approach (section 6.3) is also promising 545 as it is likely to interoperate with CE-CE VPN devices, and it does 546 not require extensions to IKE to signal the VPN-ID. 548 8. Security Considerations 550 This memo deals with ways in which IPsec may be used to secure 551 virtual links in virtual router based PPVPNs. As such security 552 issues are discussed throughout. 554 Because the virtual router approach exchanges routing messages in- 555 band with the VPN data on the virtual links, securing those links 556 simultaneously secures both the VPN data plane and control plane (or 557 more accurately, the reachability distribution part of the control 558 plane). 560 Security beyond the boundaries of the provider-provisioned network is 561 beyond the scope of this memo and indeed, beyond the scope of the 562 solutions described here. 564 9. References 566 9.1 Normative References 568 9.2 Informative References 570 [CE-VPN] De Clercq, Paridaens, Krywaniuk, and Wang, "An 571 Architecture for Provider Provisioned CE-based Virtual Private 572 Networks using IPsec," (Work in progress) draft-ietf-ppvpn-ce- 573 based-02.txt, June 2002. 575 [GRE] Farinacci, Li, Hanks, Meyer, and Traina, "Generic Routing 576 Encapsulation (GRE)," RFC 2784, March 2000. 578 [GRE-KEY] Dommety, G., "Key and Sequence Number Extensions to GRE," 579 RFC 2890, September 2000. 581 [IKE] Harkins, D. and Carrel, D., "The Internet Key Exchange 582 (IKE)," RFC 2409, November 1998. 584 [IP-IP] Perkins, C., "IP Encapsulation within IP," RFC 2003, 585 October 1996. 587 [IPSEC] Kent, S. and Atkinson, R., "Security Architecture for the 588 Internet Protocol," RFC 2401, November 1998. 590 [KNIGHT] Knight, P. and Gleeson, B., "A Method to Provide Dynamic 591 Routing in IPsec VPNs," (Work in progress) draft-knight-ppvpn- 592 ipsec-dynroute-01.txt, July 2002. 594 [L2TP] Townsley, Valencia, Rubens, Pall, Zorn, and Palter, "Layer 595 Two Tunneling Protocol L2TP," RFC 2661, August 1999. 597 [MPLS] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol 598 Label Switching Architecture," RFC 3031, January 2001. 600 [MPLS-IP] Wooster, T., Rekhter, Y., and Rosen, E., "Encapsulating 601 MPLS in IP or GRE," (Work in progress) draft-rosen-mpls-in-ip-or- 602 gre-00.txt, August 2002. 604 [TOUCH] Touch, J. and Eggert, L., "Use of IPsec Transport Mode for 605 Dynamic Routing,". (Work in progress) draft-touch-ipsec-vpn-04.txt, 606 June 2002. 608 [VPN-ID] Fox, B. and Gleeson, B., "Virtual Private Networks 609 Identifier," RFC 2685, September 1999. 611 [VR-VPN] Knight, P. et al, "Network based IP VPN Architecture using 612 Virtual Routers," (Work in progress) draft-ietf-ppvpn-vpn-vr- 613 03.txt, July 2002. 615 10. Summary for Sub-IP Related Internet Drafts 617 RELATED DOCUMENTS 619 The References section lists a number of related documents. [CE-VPN] 620 and [KNIGHT] in particular discuss IPsec-protected virtual links, 621 however the solution they propose is aimed at CE-based VPNs and is 622 inadequate for PE-based VPNs, serving multiple contexts. 624 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK? 626 This I-D is intended for the PPVPN Working Group. 628 WHY IS IT TARGETED AT THIS WG(s)? 630 This document addresses a component that is essential for Virtual 631 Router and CE-based provider provisioned VPNs, which are within the 632 purview of the PPVPN working group. 634 JUSTIFICATION 636 The PPVPN working group has the charter, among other things, to 637 develop virtual router based VPN standards and to provide for 638 security and privacy of user data in a VPN environment. 640 Author's Addresses 642 Mark Duffy 643 Quarry Technologies 644 8 New England Executive Park 645 Burlington MA 01803 USA 646 Email: mduffy@quarrytech.com 648 Full Copyright Statement 650 Copyright (C) The Internet Society (2002). All Rights Reserved. 652 This document and translations of it may be copied and furnished to 653 others, and derivative works that comment on or otherwise explain it 654 or assist in its implementation may be prepared, copied, published 655 and distributed, in whole or in part, without restriction of any 656 kind, provided that the above copyright notice and this paragraph are 657 included on all such copies and derivative works. However, this 658 document itself may not be modified in any way, such as by removing 659 the copyright notice or references to the Internet Society or other 660 Internet organizations, except as needed for the purpose of 661 developing Internet standards in which case the procedures for 662 copyrights defined in the Internet Standards process must be 663 followed, or as required to translate it into languages other than 664 English. 666 The limited permissions granted above are perpetual and will not be 667 revoked by the Internet Society or its successors or assigns. 669 This document and the information contained herein is provided on an 670 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 671 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 672 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 673 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 674 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.