idnits 2.17.1 draft-declercq-l3vpn-ce-based-as-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: ---------------------------------------------------------------------------- == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([SEC-FW], [ASGUIDE], [CEVPN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 784 has weird spacing: '...r other user ...' -- 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 (January 2004) is 7378 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: 'RFC-2026' is mentioned on line 21, but not defined == Unused Reference: 'FRMWORK' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: '1918' is defined on line 1404, but no explicit reference was found in the text == Unused Reference: '2026' is defined on line 1407, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ASGUIDE' ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-ce-based (ref. 'CEVPN') -- Possible downref: Non-RFC (?) normative reference: ref. 'FRMWORK' -- Possible downref: Non-RFC (?) normative reference: ref. 'REQS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC-FW' -- Possible downref: Non-RFC (?) normative reference: ref. 'TOUCH-VPN' Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jeremy De Clercq 3 INTERNET DRAFT Alcatel 4 Dave McDysan 5 Worldcom 6 Cliff Wang 8 January 2004 9 Expires July, 2004 11 Applicability Statement for 12 Provider Provisioned CE-based Virtual Private Networks 13 using IPsec 15 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC 2026 ([RFC-2026]). 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright (C) The Internet Society (2000). All Rights Reserved. 38 Distribution of this memo is unlimited. 40 Abstract 42 This document is an applicability statement for Provider Provisioned 43 CE-based IPsec VPNs, as discribed in [CEVPN]. This document 44 describes how provider provisioned CE-based approaches meet the key 45 requirements that are outlined in the PPVPN Applicability Statements 46 Guideline document [ASGUIDE] and the key security requirements 47 according to the template in section 8 of the VPN security framework 48 document [SEC-FW]. 50 Table of Contents 52 1. Introduction ............................................... 2 53 2. SP Provisioning Model ...................................... 5 54 3. Supported Topologies and Traffic Types ..................... 6 55 4. Isolated Exchange of Data and Routing Information .......... 7 56 4.1 Isolated forwarding of VPN data ............................ 7 57 4.2 Constrained Distribution of Reachability Information ....... 8 58 4.3 Hiding the Internal VPN Topology ........................... 8 59 5. Security ................................................... 9 60 5.1 Protection of User Data .................................... 9 61 5.2 SP Security Measures ....................................... 10 62 5.3 Security Framework Template ................................ 10 63 6. Addressing ................................................. 17 64 7. Interoperability and Interworking .......................... 18 65 8. Network Access ............................................. 18 66 8.1 Access types supported ..................................... 18 67 8.2 Access QoS support ......................................... 18 68 8.3 Access security support .................................... 18 69 9. Service Access ............................................. 19 70 9.1 Internet Access ............................................ 19 71 9.2 Hosting, ASP, Other Services ............................... 20 72 10. SP Routing ................................................. 20 73 11. Migration Impact ........................................... 20 74 11.1 Functions to be added to the customer's CE device .......... 20 75 11.2 Functions to be added by the Service Provider .............. 21 76 12. Scalability ................................................ 22 77 12.1 Number of supported VPNs ................................... 22 78 12.2 Number of sites per VPN .................................... 23 79 12.3 Number of tunnels per VPN .................................. 23 80 12.4 Number of tunnels per CE ................................... 24 81 12.5 Number of routes per VPN ................................... 25 82 12.6 Impact of configuration changes ............................ 25 83 12.7 Performance impact ......................................... 25 84 12.8 Scalability of key distribution infrastructure ............. 26 85 13. QoS, SLA ................................................... 27 86 14. Management ................................................. 27 87 14.1 Configuration/provisioning ................................. 27 88 14.2 Customer management ........................................ 27 89 14.3 SLA monitoring ............................................. 28 90 14.4 Security ................................................... 28 91 14.5 Fault handling ............................................. 28 92 15. Security considerations .................................... 29 93 16. Acknowledgements ........................................... 29 94 17. References ................................................. 29 95 18. Authors' Addresses ......................................... 30 97 1. Introduction 98 This document provides an Applicability Statement for the VPN 99 solution described in [CEVPN]. We refer to these VPNs as "provider 100 provisioned CE-based IPsec VPNs". 102 A VPN service is provided by a Service Provider to a Customer. 103 Provider provisioned CE-based IPsec VPNs are intended for the 104 situation in which (one or more of the following apply): 106 - a SP wants to offer VPN services to its customers without 107 implementing VPN specific functions in its edge (PE) or backbone 108 (P) routers; 110 - the customer does not trust the access network and the backbone 111 networks that are used to interconnect the customer's sites; 113 - CE-to-CE VPN data might need to be forwarded through the 114 Internet or across multiple SPs; 116 - the customer does not want to configure and manage the VPN- 117 specific functions of its edge equipment; 119 - the customer trusts its SP to properly and securely configure 120 and manage its CE devices, and trusts the SP to take care of the 121 security of its VPN and of the VPN's key management; the customer 122 is not concerned with hiding the data from the SP; 124 There are different business scenarios wherein PP CE-based IPsec VPNs 125 can be offered to a customer. 127 The first case is where the different sites of a customer attach to 128 the network of a particular SP, and where this SP is offering VPN 129 services to its customers. In that case the SP is both the managed 130 VPN provider and the network provider. 132 This case can be extended to a multi-SP scenario, where the SP, 133 offering the VPN service and the network service, has trust 134 agreements with other SPs to enable customer sites that are not 135 attached to the former SP to belong to the same VPN. In this last 136 scenario, the 'other SP' will make sure that the CE device that is 137 attached to its backbone will be reachable by the original (primary) 138 VPN Service Provider. This means that the VPN Service Provider will 139 end up managing CE devices that are attached to its backbone, and CE 140 devices that are not direclty attached to its backbone. 142 The second case is where the different sites of a customer have 143 access to the Internet via the (I)SP of their choice and where a 144 (VPN) SP ('the SP') manages the customer's CE devices for VPN 145 purposes. 147 The basic scenario is the following. Every CE device has IP 148 connectivity with the other CE devices that will belong to the same 149 VPN (this can be via a ''SP's backbone network'' that is owned by one 150 SP and that may internally use private addressing, via a set of 151 cooperating SPs' PE-based VPNs or via the Internet). The SP's 152 management system provisions the site's CE devices with the necessary 153 topology and security information. The CE devices establish IPsec 154 protected tunnels to the appropriate peering CE devices (according to 155 the VPN's topology). The VPN sites start exchanging reachability 156 information by tunneling routing protocol messages through the IPsec 157 protected tunnels. Alternatively, the SP may provision static routes 158 or tunnel traffic policy to the CEs, for example for small-sized, 159 'static' VPNs. Under the latter scenario, dynamic routing protocol 160 tunneling is not required. 162 In provider provisioned CE-based IPsec VPNs, VPN tunnels are 163 initiated and terminated at the CE devices, and it is assumed that 164 the PE devices receive IP packets from the CE-PE links. This limits 165 the supported tunneling techniques to IP-in-IP, L2TP, GRE and IPsec 166 (tunnel mode). [CEVPN] uses IPsec (transport mode) protected IP-in-IP 167 or GRE tunnels, or IPsec tunnel mode tunnels. 169 Note that the tunnel termination points are always the CE devices. 171 In CE-based VPNs, there are different aspects that need to be 172 provisioned on the customers' CE devices: the VPN tunnels, the 173 (IPsec) security policies and parameters, the intra- and inter-site 174 routing aspects. Now, depending on what aspects are provisioned by 175 the SP and what aspects are provisioned by the customer, different 176 scenarios can be considered, and these scenarios may have a different 177 applicability. 179 In this document, that considers VPNs in the provider-provisioned 180 scope, we consider the following scenarios : 182 (a) the SP provisions the VPN tunnels and the security aspects. 183 The intra-VPN routing aspects are under control of the VPN 184 customer: the customer treats the provisioned tunnels as logical 185 interfaces to CE devices at other VPN sites with a topology 186 configured by the SP. It is clear that in this scenario, a very 187 clear separation of management responsibilities between the 188 customer and the service provider must be agreed upon (by 189 specifying who gets to manage which specific parameters). 191 (b) the SP provisions the VPN tunnels, the security aspects and 192 the routing aspects in the CE devices. This means that the SP has 193 complete control of the CE device which has most likely been 194 provided to the customer by that SP. 196 When dynamic routing is used, and the customers are responsible for 197 the routing aspects on the CE devices (scenario (a)), the customers 198 are free to choose the routing protocol(s) they want to use to 199 distribute the reachability information (as long as these can be 200 tunneled over IP or GRE, and as long as the peering CE devices 201 support the subject routing protocols). Note that the CEs in 202 different sites are direct routing peers. The Service Provider's PE 203 (and P) devices do not interact with the CE devices (or any other 204 devices in the customer network) for the purpose of distributing the 205 routes of the customer's VPN. 207 In the case that the SP manages all aspects on the CE device 208 (scenario (b)), the customers are limited in the choice of their IGP 209 to the IGPs that the SP provides on the CE devices. 211 For provider provisioned CE-based IPsec VPNs, the topology of the VPN 212 has an important impact on the scalability and the performance of the 213 solution. All kinds of VPN topologies are supported by PP CE-based 214 IPsec VPNs: hub and spoke topology, partial mesh topology, full mesh 215 topology. 217 Note that the use of the IPsec protocol suite is not a requirement 218 per se with regards to provider provisioned CE-based VPNs. A SP could 219 offer a VPN service that uses non-encrypted or authenticated site- 220 to-site tunnels (using e.g. IP-in-IP, GRE, L2TP). This use of non- 221 secured CE-to-CE tunnels is not recommended for security reasons 222 though, and is not discussed in [CEVPN]. 224 2. SP Provisioning model 226 In provider provisioned CE-based VPNs, the SP is responsible for 227 provisioning the CE devices with the VPN-specific configuration 228 information. 230 The SP will install a secure management 'channel' towards every CE 231 device, over which it can securely provision that CE device. This can 232 for example be a specific IPsec tunnel, a secured Layer-4 channel, 233 etc. 235 Note that [CEVPN] does not impose the use of a specific management 236 protocol, as such allowing the described tunnel establishment, VPN 237 routing distribution and data-plane security aspects to be de-coupled 238 from the remote management and auto-discovery aspects. This allows 239 different SPs to choose from their preferred remote management and 240 auto-discovery solution, and for example to start with a manually 241 (CLI-based) configured approach and finally migrate to a more 242 scalable automatic approach. A complete 'vertical' solution would 243 require the description of one (or some) remote management 244 architectures: set of protocols, security of the management channel, 245 definition of the transported object models, protocol dynamics and 246 interaction with for example the tunneling establishment to 247 accomplish complete auto-discovery. 249 The SP will provision every CE device with the IP addresses of the 250 peer CE devices the considered CE has to maintain a VPN tunnel with. 251 The number of these peer CE devices depends on the number of sites 252 the VPN contains and on the topology of the VPN. 254 In [CEVPN], the SP is responsible for provisioning the CE-devices 255 with the necessary 'security information' that is needed to establish 256 and maintain IPsec Security Associations with the peer CE devices: a 257 set of transforms to use with IPsec, tunnel property information and 258 IKE credentials. Indeed, the CE devices that will use IPsec to 259 protect the inter-site traffic, need (long-term) secure credentials. 260 These credentials will be used by a key exchange protocol (such as 261 IKE(v2)) to generate the actual (short-term) keys that will be used 262 to protect the data traffic. 264 One option for the (long-term) credentials is for the SP to directly 265 configure them in the CE devices in the form of pre-shared keys 266 (PSK). Alternatively, the SP can provide a public key infrastructure 267 (PKI) to its VPN customers. 269 When this key distribution system provides the CE devices with pre- 270 shared keys, then this key distribution can be done together with the 271 configuration of the CE devices by the SP management system. If 272 alternatively, the SP provides its VPNs with a Public Key 273 Infrastructure, this adds extra complexity, but also supports the 274 potential for multi-SP CE-based VPNs. Both the pre-shared key 275 approach and the PKI approach have their scalability implications 276 (see section 12.8). 278 For scalability purposes, the SP should use an 'automatic update' 279 scheme such that the addition of a VPN site to an existing VPN 280 requires the provisioning of only that new CE device (in contrast to 281 the need to manually provision every existing CE device in the 282 considered VPN). [CEVPN] does not describe such an 'automatic update' 283 scheme, but the use of the mechanisms described in [CEVPN] is 284 compatible with the use of any specific auto-discovery scheme. There 285 currently is no IETF document describing a remote management protocol 286 for CE-based IPsec VPNs, and describing a mechanism for CE-based 287 IPsec VPN auto-discovery, but SPs commonly use remote management 288 protocols such as for example CLI/Telnet/SSH or SOAP/XML/HTTP/SSH. 290 3. Supported Topologies and Traffic Types 291 Provider provisioned CE-based IPsec VPNs allow for all desired 292 topologies: fully meshed VPNs, hub and spoke VPNs, partially meshed 293 VPNs, etc. Configuring a specific required VPN topology is a matter 294 for the SP of provisioning every member CE device with the IP 295 addresses of the appropriate peer CE devices the considered CE device 296 has to maintain a VPN tunnel with. 298 The customer VPN may carry both user data and control data. User data 299 is the site-to-site traffic that carries user applications. The 300 control data may contain site-to-site reachability information, 301 keep-alives, etc. 303 Provider provisioned CE-based IPsec VPNs are not targeted at 304 providing Layer-2 services. By (GRE- or IP-) encapsulating Layer-2 305 datagrams at the CE devices first, this traffic-type can be 306 transported with CE-based IPsec VPNs. 308 Carrying multicast traffic with CE-based IPsec VPNs will require the 309 (GRE- or IP-) encapsulation of multicast-packets at the CE devices 310 first. Multicast support in CE-based VPNs means for a basic scenario 311 that CE devices need to be provisioned as to be able to duplicate 312 multicast packets over the different VPN tunnels it maintains (which 313 makes CE-based VPNs less resource efficient for Multicast traffic 314 than e.g. PE-based VPNs). 316 4. Isolated Exchange of Data and Routing Information 318 4.1 Isolated forwarding of VPN data 320 With CE-based IPsec VPNs, tunnels are deployed between CE devices. 321 These tunnels are either IP-in-IP (or GRE) tunnels that are protected 322 via IPsec in transport mode [TOUCH-VPN], or IPsec tunnel mode 323 tunnels. 325 In both cases, the forwarding in the shared infrastructure (access 326 network and SP network(s)) is based on the IP addresses in the 327 packets' outer IP header. These IP addresses can be public IP 328 addresses (e.g. when the Internet is used for the CE-to-CE 329 forwarding), or more generally IP addresses that belong the SP's 330 addressing realm (these might be private or non-unique addresses when 331 the interconnectivity between CEs is offered by one particular SP). 333 Isolated exchange of data information is assured because IP routing 334 and forwarding in the shared infrastructure takes care of forwarding 335 the encapsulated IP packets to the correct destination CEs, using the 336 destination address in the IPsec packets' outer headers. Indeed, the 337 IP addresses in the outer headers are always IP addresses that belong 338 to the CE devices and that are unique and routable in the SP backbone 339 network(s). 341 In addition, the customer IP packets are encrypted on every CE-to-CE 342 part of the network; as such, no intermediate router or other device 343 that does not belong to the same VPN can read the customer traffic, 344 even if mis-routing or intercept occurs. This is particularly 345 applicable in the case that the Internet is used for forwarding the 346 CE-to-CE traffic, as the SP then doesn't have control on the actual 347 path of the customer traffic. 349 Encrypting the data packets also makes sure that packets that would 350 arrive at a wrong destination CE, would not be visible by the 351 receiving device: a CE device that receives a packet that it cannot 352 decrypt using its existing Security Associations, will drop that 353 packet. This makes sure that packets that don't belong to the 354 considered VPN cannot (un)intentionally enter that VPN. 356 4.2 Constrained Distribution of Reachability Information 358 The distribution of VPN IP reachability information among devices at 359 the VPN sites is achieved by tunneling the reachability information 360 (in the form of routing protocol messages) through the CE-to-CE VPN 361 tunnels. CE devices must be configured to forward VPN reachability 362 information only to those interfaces that are associated with the 363 particular VPN : that is, the intra-site interfaces and the IPsec- 364 protected interfaces (tunnels) that lead to the other sites that 365 belong to the same VPN. 367 As a CE only maintains VPN tunnels with CE devices that belong to the 368 same VPN, the reachability information of one VPN site will only be 369 distributed to other sites that belong to the same VPN. This also 370 ensures that VPN routes will not be distributed into the Internet, 371 and that Internet routes will not be distributed to VPN sites. 373 One special case and exception to the above is when a CE device also 374 provides Internet Access to the VPN. In this case, a firewall should 375 take care of the Internet Gateway function. 377 Of course, configuration errors by the SP can compromise the 378 constrained distribution of reachability, and the overall security of 379 the VPN (as discussed in section 5.2). 381 4.3 Hiding the Internal VPN Topology 383 Note that in addition to the fact that the VPN reachability 384 information distribution is isolated, the reachability information is 385 also carried in an encrypted form on the CE-to-CE part of the network 386 (by sending the routing information messages through the provisioned 387 CE-CE IPsec tunnels). This means that even when misrouting or 388 malicious snooping occurs, the global VPN topology and the internal 389 topology of the VPN sites is not visible outside of the considered 390 VPN. 392 The SP should take care not to configure a CE device such that it 393 distributes its VPN routes directly to the PE device (instead of to 394 the peer CE devices through the tunnels). Unless this is required for 395 specific Internet Access scenarios. 397 5. Security 399 CE-based VPNs using IPsec are specifically applicable in situations 400 where security is an important requirement and where the outsourcing 401 of the complexity that comes with it is an important requirement. 402 This type of VPNs allows the customer's data and control traffic to 403 be secured (via encryption) on every shared part of the network, 404 using the very secure and reliable IPsec protocol suite. The result 405 of this is that the customer traffic is not only isolated (via 406 tunnelling) from the other traffic that uses the same backbone, but 407 that the customer traffic is also unreadable (because encrypted) and 408 as such protected against e.g. malicious eavesdropping. 410 IPsec encryption with optional authentication and replay attack 411 prevention directly meet all of the security requirements in [REQS], 412 as long as key distribution is not compromised. 414 Note that the provider provisioned CE-based VPNs using IPsec do not 415 protect against accidental or malicious mis-configuration by the 416 service provider, as the SP manages the CE device, which in the most 417 common operation sends and receives VPN traffic in the clear with 418 other customer-premise equipment. 420 5.1 Protection of User Data 422 Customer data, both control plane data and user plane data are 423 encapsulated by IPsec before sent to the shared SP backbone. The 424 customer data is protected until it reaches the peer CE. When the 425 customer data is encrypted by IPsec, it is considered secure when it 426 is being transferred through the shared IP backbone. 428 As such, VPN user data traffic that is intercepted by an entity that 429 was not meant to receive it (e.g. a CE device from an other VPN), 430 will not be visible by that entity because it is encrypted. And 431 traffic that doesn't belong to a particular VPN will not be able to 432 enter that VPN because the traffic will not be recognized as 433 belonging to one of the Security Associations the CE device 434 maintains, and as such will be dropped by IPsec. 436 5.2 SP Security Measures 438 The SP is responsible for preventing illegitimate traffic from 439 entering a VPN. Preventing illegitimate traffic is a matter of 440 ensuring that the CE devices are provisioned with the correct set of 441 peer CE device IP addresses and with the correct security policies 442 and parameters. An intentional or unintential misconfiguration by the 443 SP whereby two CE devices that do not belong to the same VPN are 444 configured as tunnel and IPsec peers, would make communication 445 between two different VPNs possible in an undesired manner. 447 The CE device should be secured against break-in, both from someone 448 having physical access to the CE device as from the Internet. As the 449 CE device is physically located at the customer's premises, securing 450 the CE from compromise by someone physically present is a customer 451 responsibility. Securing the CE device from breakins via the Internet 452 is accomplished at the CE device by configuring it (by the SP) to 453 limit the types of traffic that are accepted. Indeed, CE devices that 454 do not provide Internet Access to the VPN over the CE-PE link must 455 only accept traffic that is authenticated by this CE device as being 456 either SP management traffic (carried by a secure and authenticated 457 management channel) or intra-VPN traffic (carried by an IPsec secured 458 tunnel). All other traffic must be dropped. CE devices that do 459 provide Internet Access to the VPN over the CE-PE link should accept 460 traffic that is authenticated by this CE device as being either SP 461 management traffic or intra-VPN traffic; all other traffic should be 462 sent to a firewall before accepting it into the VPN. 464 A management channel exists between SP and the managed CE. It is 465 important for SP to build a secure (authenticated and encrypted) 466 management channel to prevent attacks from the adversary. 468 The SP must make sure that breaking in into it's VPN management 469 system is prohibited (both from someone physically present in the 470 provider's premises, as via the Internet) in order not to compromise 471 the secrecy of e.g. the VPN tunnel security parameters that the SP 472 maintains. 474 The SP must ensure the security of its key management infrastructure. 476 5.3 Security Framework Template 478 Section 8 of [SEC-FW] provides ''a brief template that may be used to 479 evaluate and summarize how a given PPVPN approach (solution) measures 480 up against the PPVPN Security Framework.'' It further states ''an 481 evaluation of a given PPVPN approach using this template should 482 appear in the applicability statement for each PPVPN approach.'' The 483 purpose of this subsection is to provide the information in the form 484 required by this template. 486 1. The approach provides complete IP address space separation for 487 each L3 VPN. 489 The base VPN approach completely addresses the requirement by 490 maintaining and handling the VPN IP address prefixes only in the 491 routing tables of devices that are specific to the particular VPN. 492 They are distributed through encrypted tunnels between devices 493 that are specific to the particular VPN. 495 2. The approach provides complete L2 address space separation for 496 each L2 VPN. 498 The requirement is not applicable to the VPN approach because it 499 is applicable only for L2VPN approaches while the discussed VPN 500 approach is a L3VPN approach. 502 3. The approach provides complete VLAN ID space separation for each 503 L2 VPN. 505 The requirement is not applicable to the VPN approach because it 506 is applicable only for L2VPN approaches while the discussed VPN 507 approach is a L3VPN approach. 509 4. The approach provides complete IP route separation for each L3 510 VPN. 512 The base VPN approach completely addresses the requirement by 513 having the CE devices distribute the VPN routes through CE-to-CE 514 secure tunnels only. 516 5. The approach provides complete L2 forwarding separation for each 517 L2 VPN. 519 The requirement is not applicable to the VPN approach because it 520 is applicable only for L2VPN approaches while the discussed VPN 521 approach is a L3VPN approach. 523 6. The approach provides a means to prevent improper cross- 524 connection of sites in separate VPNs. 526 In the VPN approach, the requirement is addressed in a way that is 527 beyond the scope of the VPN mechanisms. In PP CE-based IPsec VPNs, 528 a site is made part of a particular VPN by configuring the CE 529 device with the correct peer CE IP addresses, security policies 530 and IPsec parameters. It's the SP's management function that is 531 responsible not to provision certain CE devices as being part of 532 the wrong VPN. 534 7. The approach provides a means to detect improper cross- 535 connection of sites in separate VPNs. 537 If a routing algorithm is run on a particular CE-to-CE (tunnel) 538 interface, any security procedures which the routing algorithm 539 provides (e.g. MD5 authentication) can be used; this is outside of 540 the scope of the VPN scheme. This does not help however if it is 541 the SP who manages the routing aspects on both CE devices and 542 misconfigures the routing aspects too. 544 8. The approach protects against the introduction of unauthorized 545 packets into each VPN. 547 The base VPN approach completely addresses the requirement by 548 authenticating all packets that are received at the CE device from 549 a PE-CE link. Packets will only be accepted by the CE device if 550 any the following conditions apply: 552 - the packet is authenticated as an IPsec protected packet that 553 comes from a peer CE device that belongs to the same VPN; 555 - the packet is authenticated as belonging to the SP's 556 management traffic manageing the considered CE device. 558 - the CE device is configured to provide Internet Access to the 559 VPN over the considered CE-PE link, and is configured to direct 560 all packets to a firewall if they don't fullfil one of the two 561 previous conditions; 563 The described protection applies for unauthorized packets 564 introduced in any of the following scenarios: 566 a. In the CE-PE link 567 b. In a single- or multi- provider PPVPN backbone 568 c. In the Internet used as PPVPN backbone 570 9. The approach provides confidentiality (secrecy) protection for 571 PPVPN user data. 573 The base VPN approach partially addresses the requirement by 574 encrypting any PPVPN user data that leaves a particular site (at a 575 CE device) and by only decrypting the PPVPN user data when it 576 enters a particular site (at a CE device). This means that the 577 user data secrecy is assured by encryption in every part of the 578 network that is not in the customer's premises. The only reason 579 why the requirement is only partially addressed is because the SP 580 has access to the CE devices where the PPVPN user data appears in 581 an unencrypted form. 583 Confidentiality protection of user data within the customer 584 premises is outside of the scope of PPVPN approaches. 586 The described protection applies for PPVPN user data travelling in 587 any of the following conditions: 589 a. In the CE-PE link 590 b. In a single- or multi- provider PPVPN backbone 591 c. In the Internet used as PPVPN backbone 593 10. The approach provides sender authentication for PPVPN user 594 data. 596 The base VPN approach partially addresses the requirement by IPsec 597 processing any PPVPN user data that leaves and enters a particular 598 site (at the CE device). The requirement is only partially 599 addressed as the PPVPN user data is not authenticated as coming 600 from a specific sender, but only as coming from a specific VPN 601 site. 603 The discussed protection applies for PPVPN user data travelling in 604 any of the following conditions: 606 a. In the CE-PE link 607 b. In a single- or multi- provider PPVPN backbone 608 c. In the Internet used as PPVPN backbone 610 11. The approach provides integrity protection for PPVPN user data. 612 The base VPN approach partially addresses the requirement by 613 encrypting any PPVPN user data that leaves a particular site (at a 614 CE device) and by only decrypting the PPVPN user data when it 615 enters a particular site (at a CE device). This means that the 616 user data integrity is assured by encryption in every part of the 617 network that is not in the customer's premises. The only reason 618 why the requirement is only partially addressed is because the SP 619 has access to the CE devices where the PPVPN user data appears in 620 an unencrypted form so that nothing prevents the SP from touching 621 the PPVPN user data. 623 Integrity protection of user data within the customer premises is 624 outside of the scope of PPVPN approaches. 626 The described protection applies for PPVPN user data travelling in 627 any of the following conditions: 629 a. In the CE-PE link 630 b. In a single- or multi- provider PPVPN backbone 631 c. In the Internet used as PPVPN backbone 633 12. The approach provides protection against replay attacks for 634 PPVPN user data. 636 The base VPN approach completely addresses the requirement by 637 IPsec processing any PPVPN user data that leaves and enters a 638 particular site (at the CE device). 640 The described protection applies for PPVPN user data travelling in 641 any of the following conditions: 643 a. In the CE-PE link 644 b. In a single- or multi- provider PPVPN backbone 645 c. In the Internet used as PPVPN backbone 647 13. The approach provides protection against unauthorized traffic 648 pattern analysis for PPVPN user data. 650 The VPN approach does not meet the requirement. Even though the 651 PPVPN user data is encrypted over every public or SP's network 652 part, nothing prevents a third party from examining the outer IP 653 header's IP addresses (the CE WAN addresses), the traffic timing, 654 volume etc. Preventing against this threat is outside of the scope 655 of the discussed VPN approach. 657 14. The control protocol(s) used for each of the following 658 functions provide for message integrity and peer authentication: 660 a. VPN membership discovery 662 The [CEVPN] approach requires any VPN membership discovery 663 scheme to fulfil the above requirements, though [CEVPN] 664 currently does not specify a membership discovery mechanism. 666 b. Tunnel establishment 668 The base VPN approach completely addresses the requirement by 669 using the IKE(v2) protocol for the tunnel establishment. 671 c. VPN topology and reachability advertisement 673 The base VPN approach partially addresses the requirement 674 because the advertisement of VPN topology and reachability is 675 done through the IPsec protected CE-to-CE tunnels. The only 676 reason why the requirement is only partially addressed is 677 because the Service Provider has access to the CE device and as 678 such could influence topology advertisements. 680 i. PE-PE 682 The requirement is not applicable to the VPN approach 683 because the PE devices are not participating in the VPN 684 topology and reachability advertisement. 686 ii. PE-CE 688 The requirement is not applicable to the VPN approach 689 because the PE devices are not participating in the VPN 690 topology and reachability advertisement. 692 d. VPN provisioning and management 694 The [CEVPN] approach requires the VPN provisioning and 695 management function to fulfil the above requirements, though 696 [CEVPN] currently does not specify a provisioning and 697 management approach. 699 e. VPN monitoring and attack detection and reporting 701 The VPN approach itself does not meet the requirement: the 702 protocols and procedures for monitoring the VPNs are outside 703 the scope of the VPN scheme. 705 15. Describe the protection, if any, the approach provides against 706 PPVPN-specific DOS attacks (i.e. Inter-trusted-zone DOS 707 attacks): 709 a. Protection of the service provider infrastructure against Data 710 Plane or Control Plane DOS attacks originated in a private 711 (PPVPN user) network and aimed at PPVPN mechanisms. 713 For the SP's network infrastructure (PE and P routers), there 714 is no difference between a DOS attack originated in a PPVPN 715 user network using CE-based IPsec VPNs as compared to a DOS 716 attack originated in any other user network. 718 The matter in which the SP's network is protected against DOS 719 attacks originated in a user network is outside of the scope of 720 the CE-based IPsec VPN architecture. 722 b. Protection of the service provider infrastructure against Data 723 Plane or Control Plane DOS attacks originated in the Internet 724 and aimed at PPVPN mechanisms. 726 The protection of the SP's VPN management infrastructure 727 against DOS attacks originating from the Internet is not 728 different than the protection of any other SP's management 729 infrastructure against DOS attacks originating from the 730 Internet. 732 c. Protection of PPVPN users against Data Plane or Control Plane 733 DOS attacks originated from the Internet or from other PPVPN 734 users and aimed at PPVPN mechanisms. 736 As the CE device's WAN IP address is routable in the SP's 737 backbone network (and possibly in the Internet), nothing 738 prevents other PPVPN users (and possibly Internet users) to 739 send excessive amounts of traffic to a particular CE device. 740 The effect of such an attack would be the same as the effect of 741 a DOS attack on any device that uses IPsec secured connections. 743 Extra protection against such DOS attacks could be achieved by 744 having the PE devices implement VPN-specific access control 745 lists. At first glance this appears to be in contradiction with 746 one of the CE-based VPN characteristics that PE devices be VPN 747 unaware. However, in this case the knowlege required at PE 748 devices would be limited to knowledge of which other devices in 749 the Internet are permitted to send traffic to the CE. This does 750 not, for example, require any PE knowledge of the private 751 network address space nor of the private network routing. 753 16. Describe the protection, if any, the approach provides against 754 unstable or malicious operation of a PPVPN user network: 756 a. Protection against high levels of, or malicious design of, 757 routing traffic from PPVPN user networks to the service 758 provider network. 760 Intra-VPN reachability information is never distributed to SP's 761 P or PE devices. Dynamic routing between CE and PE devices may 762 however be used in the SP's routing space for the purpose of 763 distributing the CE's WAN IP address into the SP's backbone 764 network. This is not different however from any non-VPN 765 (customer) access router peering with a SP's edge router, and 766 the same protection mechanisms may be used (such as limiting 767 the amount of PE resources dedicated for the considered routing 768 peer). 770 b. Protection against high levels of, or malicious design of, 771 network management traffic from PPVPN user networks to the 772 service provider network. 774 The discussed CE-based IPsec VPN approach partially protects 775 the service provider network from excessive or malicious 776 network management traffic originated in the PPVPN user 777 networks. Indeed, except for the CE devices, no other devices 778 in the customer's private network have the ability to send 779 traffic to service provider devices. However, for attacks from 780 the CE device itself, the situation is no different from 781 attacks from devices with normal Internet access. In addition, 782 for attacks originated by other devices in the customer network 783 that have Internet access via some CE device, the situation is 784 no different than for other user devices (not belonging to a 785 CE-based IPsec VPN) that have Internet access. Protection 786 against such attacks is out of the scope of CE-based IPsec 787 VPNs. 789 c. Protection against worms and probes originated in the PPVPN 790 user networks, sent towards the service provider network. 792 With CE-based VPNs, the same protection mechanisms against 793 worms and probes originated in the PPVPN user networks apply as 794 against worms and probes originated from e.g. the Internet; 795 these mechanisms are outside of the scope of the considered VPN 796 approach. 798 6. Addressing 800 In CE-based IPsec VPNs, it is assumed that the CE devices have one IP 801 address (their 'WAN' IP address) that is public or that belongs to 802 the SP's routing realm. These are the IP addresses that will be used 803 in the encapsulating (outer) IP headers of the tunneled packets that 804 will be sent on the CE-PE link. Beyond use of this CE IP address 805 (that will never be used by the customer's IGP for intra-site routing 806 and forwarding), there is no constraint on the IP addresses that are 807 internally used within the VPN. In summary, every CE device has to 808 have one WAN IP address that is routable in the SP's IGP and that 809 doesn't need to be routable in the customer's IGP. In order to 810 achieve this, the CE devices will operate in two distinct routing 811 spaces (that they need to keep separate in the CE): the VPN routing 812 space, and the SP's routing space. 814 Overlapping customer addresses are supported in different VPNs 815 (meaning that different VPN customers that are provisioned by the 816 same (or different) SP may use overlapping address spaces). There is 817 no requirement that such addresses be in conformance with RFC 1918. 818 There is no requirement that customer VPN-internal addresses be 819 distinct from addresses in the SP network. 821 Any set of addresses used in the VPN can be supported, irrespective 822 of how they are assigned, how well they aggregate, whether they are 823 public or private. However, the set of addresses which are reachable 824 from a given VPN site must be unique. 826 Network address translation for packets leaving/entering a VPN is 827 possible, and is transparent to the VPN scheme. 829 7. Interoperability and Interworking 831 As all the different types of Layer-3 VPNs are IP networks, they can 832 of course interwork in the same way that any two IP networks can 833 interwork. For example, a single site can contain a CE router that 834 participates in one VPN scheme (e.g. a Provider Provisioned CE-based 835 VPN solution) and a CE router of another VPN scheme (e.g. a CE that 836 is attached to a 2547bis PE's VRF), and these CE routers could be IGP 837 peers, or they might even be the same CE router. This would result in 838 the redistribution of routes from one type of VPN to the other, 839 providing the necessary interwoking. 841 8. Network Access 843 8.1 Access types supported 845 CE-based IPsec VPNs are applicable in every access scenario where the 846 CE device has IP connectivity with the PE device. Every CE device 847 only needs one IP address that is routable in the shared backbone. 848 This CE-PE IP connectivity may be provided over any Layer-1 and 849 Layer-2 infrastructure (PPP, Ethernet, ATM, Frame Relay, etc.). 851 8.2 Access QoS support 853 Providing QoS in the access network is a non VPN-specific feature. 854 Any existing layer-2 QoS mechanism could for example be used for this 855 purpose. General QoS aspects are discussed in section 13. 857 8.3 Access security support 859 CE-based IPsec VPNs have the additional advantage that the security 860 of the VPN is not dependent on the security of the access network. 861 Customer data packets traverse the access network in an encrypted 862 way. 864 Note however that, as IP packets that are sent from CE to PE are not 865 authenticated by the PE devices, the CE-based IPsec VPN model does 866 not protect against resource spoofing and Denial of Service Attacks 867 by invalid users. An intruder can still inject traffic on the access 868 link, which will be forwarded by the PE device towards the destined 869 CE device. 871 When a CE device that is configured for a certain VPN would be moved 872 and placed in a different location (e.g. in a different VPN's 873 premises), the following scenarios are possible: 875 - the CE device would receive a new WAN IP address, and as the other 876 CE devices belonging to the original VPN will not recognise this new 877 IP address, this would prevent the establishment of VPN tunnels from 878 this new location; in addition, the SP's management system would 879 detect this connectivity loss from the old IP address; 881 - the CE device would keep its own WAN IP address but without 882 distributing this outside of its new location via a routing protocol; 883 this would make the CE device unreachable and would prevent the 884 establishment of VPN tunnels from this new location; 886 - the CE device would keep its own WAN IP address and distribute it 887 via a routing protocol via its new location into the SP's backbone; 888 in this situation, the CE device will be able to access the other VPN 889 from within its new location. This situation should not be allowed by 890 prohibiting the movement of the CE devices outside of the VPN 891 customer's premises. 893 When the configuration of a CE device, located at the VPN customer's 894 premises, is deliberately or unintentionally changed without prior 895 agreement of the SP, access to the VPN from the Internet or from 896 sites belonging to different VPNs may become possible, and VPN data 897 may leak out of the VPN. As such, the customer must make sure that 898 access to the CE device is restricted to the VPN SP, or to authorized 899 and knowledgeable people from the customer's IT department. 901 Note that it is not possible for a particular customer to 902 intentionally misconfigure its CE device in an attempt to access some 903 other VPN. Indeed, there is no way for this particular customer to 904 know the necessary keys and authentication credentials that are 905 specific to every VPN tunnel. 907 9. Service Access 909 9.1 Internet Access 911 Internet access and VPN access are possible from the same site. 912 Different ways to accomplish this service are possible. One 913 restriction is that the VPN's internal addresses must be distinct 914 from the IP addresses of the systems which must be reached via the 915 Internet. The required NAT and firewall functions are implemented in 916 one or more of the VPN's CE devices or dedicated gateways. 918 A typical scenario is that the CE would have to direct all non-IPsec 919 traffic to a firewall. 921 When the CE-based VPN traffic shares the access (CE-PE part of the 922 network) with Internet-traffic, a denial of service attack from sites 923 outside the VPN is possible. 925 9.2 Hosting, ASP, Other Services 927 Externally provided services can be accessed from the VPN through a 928 firewall located at a VPN site, provided that it can be addressed 929 with an IP address that is not otherwise in use within the VPN. If 930 the considered service is offered by the same server for a number of 931 VPNs, and a certain client with a non-unique IP address is accessing 932 the server, NAT has to be performed at the client's CE device. 934 10. SP Routing 936 Routing through the backbone(s) is independent of the VPN scheme, and 937 is unaffected by the presence or absence of VPNs. The only impact is 938 that the backbone routing (or Internet routing) must carry the routes 939 to the CE devices. 941 The use of CE-CE IP tunnels is not impacted by (and is thus 942 complementary with) any PE-PE tunneling that the Network Provider 943 might deploy in its backbone network (e.g. PE-PE MPLS LSPs for 944 Traffic Engineering reasons). 946 11. Migration Impact 948 The migration impacts that are discussed here deal with : 950 (i) a customer who migrates from a legacy (frame-relay type) IP 951 over Layer-2 VPN to a provider provisioned CE-based IPsec VPN, or 953 (ii) a customer who migrates from a customer provisioned CE-based 954 IPsec VPN to a provider provisioned CE-based IPsec VPN. 956 11.1 Functions to be added to the customer's CE device 958 - migration scenario (i) 960 Assuming that the customer CE router has IP connectivity with the 961 PE router, the following functionality needs to be added on the 962 customer equipment: 964 - the customer's CE device needs to implement the IPsec 965 protocol suite and an IPsec key exchange functionality, such as 966 IKE. 968 - the CE device needs to support the secure management protocol 969 that is used by the SP's management system. 971 - the CE device's routing protocol(s) needs to treat the 972 different IPsec secured CE-to-CE tunnels as independent 973 interfaces. 975 - in the scenario where both the customer and the Service 976 Provider have management responsibilities on the CE device, the 977 CE device must support a management security infrastructure 978 that allows for the separation of management responsibilities 979 according to specified rules 981 - the CE device must have its frame relay port replaced with 982 whatever is needed to access the SP's network (unless this is 983 FR) 985 - the customer's virtual topology may need to be redesigned, 986 including a study of the impact of this design on the 987 customer's IGP. Note that it is not necessarily the case that 988 the FR DLCI's should be replaced one by one with IPsec SAs. 990 - migration scenario (ii) 992 - the customer's CE device needs to implement the IPsec key 993 exchange functionality (IKE(v2)) 995 - the CE device needs to support the secure management protocol 996 that is used by the SP's management system. 998 - if a public key infrastructure is provided by the SP, the CE 999 device needs to support this infrastructure 1001 - in the scenario where both the customer and the Service Provider 1002 have management responsibilities on the CE device, the CE device 1003 must support a management security infrastructure that allows for 1004 the separation of management responsibilities according to 1005 specified rules 1007 11.2 functions to be added by the Service Provider 1009 - The SP needs to deploy a secure management system that is able to 1010 configure and manage a large amount of CE devices per VPN customer. 1012 - In the case that the SP is also the backbone network provider, the 1013 SP needs to provide IP connectivity between CE devices. 1015 - The SP needs to be able to define topology, security protection, 1016 and reachability attributes for each customer VPN it manages. 1018 - The SP needs to be able to configure each managed CE, based on the 1019 attributes of the VPN that the CE belongs to. 1021 - The SP needs to be able to update each VPN, based on customer needs 1022 from time to time. Changes such as adding or deleting VPN sites, 1023 upgrading VPN functions are common. 1025 - The SP may need to have the capability of managing and monitoring 1026 the SLA of the cusomer's VPN. 1028 - The SP needs to be able to gather and create appropriate usage and 1029 accounting report for each VPN it manages. 1031 12. Scalability 1033 This section discusses how certain specific VPN-metrics affect the 1034 scalability of the VPN-solution. 1036 12.1 Number of supported VPNs 1038 It is assumed that a certain site is only part of one VPN. 1039 Architectures that allow sites to be a member of multiple VPNs will 1040 have impact on the CE devices and on the supported addressing 1041 schemes. 1043 When a site can be a member of only one VPN, the number of VPNs that 1044 a SP can support has an impact on the SP's management system. 1046 For every supported VPN, the SP's management system will need to be 1047 able to provision every site's CE device that belongs to that VPN. 1048 The management system will need to maintain information that is 1049 specific for every VPN site (IP addresses of the other peering sites 1050 in the considered VPN, security information, etc.). 1052 The number of VPNs that a SP can support is dependent on the number 1053 of sites per VPN and is limited by the number of management sessions 1054 the SP's VPN management system can support and the amount of VPN 1055 information the SP's VPN database can maintain. 1057 Note however that when the number of VPNs increases, the SP can 1058 deploy additional management systems with their own VPN databases : 1059 the SP can use multiple independent management systems as there is no 1060 interaction between different VPNs. 1062 12.2 Number of sites per VPN 1064 In a fully-meshed VPN, the number of sites per VPN has an impact on 1065 the CE devices within that VPN, on the SP's management system and on 1066 the SP's key distribution system. 1068 In one particular fully-meshed VPN, for every additional site, a 1069 certain CE router needs to maintain an additional VPN tunnel (in the 1070 form of an additional IPsec Security Association) and additional 1071 reachability information. 1073 For every VPN site, the SP's management system will need to maintain 1074 some information and will need to be able to establish a management 1075 connection to the site's CE device. 1077 The number of sites per VPN (n) has an impact of O(n) on the CE 1078 devices, and has an impact of O(n^2) on the number of tunnels that 1079 the SP management system needs to provision (in a fully-meshed VPN). 1081 In VPNs that are not fully meshed (partial mesh or hub and spoke 1082 topology), the impact of the number of sites per VPN on the 1083 scalability of the system is reduced. 1085 In a hub and spoke VPN, the CE of the hub site still needs to 1086 maintain as many tunnels as there are other sites (n-1), and will 1087 still need to maintain the complete set of VPN routes. The CEs of the 1088 spoke sites on the other hand, need only to maintain one tunnel 1089 towards the hub CE. Moreover, in a hub and spoke topology, the spoke 1090 CEs may not need to maintain the other CE's routes: a default route 1091 towards the hub CE may suffice. The SP's management system needs to 1092 maintain O(n) tunnels in a hub and spoke VPN. 1094 Note that the total number of CE devices to support may prove to be 1095 the most critical scalability factor for the SP's management system, 1096 especially in terms of automatically updating the CE devices' 1097 configuration upon a certain change. The reliability mechanism 1098 involved may have a per-CE scaling component. 1100 12.3 Number of tunnels per VPN 1102 The number of tunnels per VPN depends on the number of sites per VPN 1103 and on the VPN topology. 1105 The hub-and-spoke topology requires the least amount of tunnels to 1106 provide inter-connection among all participating sites (O(n)), while 1107 a fully meshed VPN requires the most tunnels (O(n^2)). 1109 Aside from the number of tunnels, the VPN security attributes also 1110 affect the scalability of a VPN. For example, when a VPN uses 3DES as 1111 the tunnel encryption scheme, the total number of tunnels that a hub 1112 may support may be smaller than the case when e.g. DES is selected. 1114 The number of tunnels that are required specifies the number of SAs 1115 that need to be maintained, and this has an impact on the number of 1116 keys to be supported and thus on the SP's key distribution system. 1118 12.4 Number of tunnels per CE 1120 The number of tunnels to be supported by a CE device has implications 1121 on the performance of that CE device : every supported tunnel 1122 represents a new interface; every tunnel is protected by a specific 1123 Security Association. 1125 The overall CE performace will decline when the number of tunnels 1126 increases as the memory consumption increases and the processing 1127 increases: every Security Association that protects a tunnel needs to 1128 be frequently re-negotiated. This (frequent) re-keying of existing 1129 (permanent) tunnels requires a certain amount of processing (key 1130 generation) and of control protocol message exchanges (via IKE or an 1131 alternative key exchange protocol). 1133 The number of tunnels a CE will need to support at a given time can 1134 be dependent on whether 'traffic-driven' tunnel set-up or 'traffic- 1135 independent' tunnel set-up is used. 1137 Note that the use of traffic-driven tunnel set-up has important 1138 implications. In traffic-driven tunnel establishment, if a certain 1139 tunnel does not carry traffic during a certain amount of time, the 1140 IPsec SA will be removed. When traffic starts flowing again, a new 1141 Security Association will need to be established first. The two 1142 tunnel endpoints will re-negotiate the necessary SAs, and will 1143 generate the necessary key material. This not only introduces control 1144 protocol message exchanges but also delay in the forwarding of the 1145 user packets. 1147 Note also that the inter-site reachability distribution interacts 1148 with traffic-driven tunnel establishment : routing protocols send 1149 routing updates and keep-alive messages, even when no actual user 1150 traffic is flowing. 1152 As such, traffic-driven tunnel set-up may be applicable in CE-based 1153 IPsec PPVPNs that use statically provisioned routing information. The 1154 use in an environment that dynamically distributes inter-site 1155 reachability is much more complicated and not advised. 1157 Note that the number of tunnels per CE has a scalability impact on 1158 the customer's IGP, as every tunnel is seen as an interface from the 1159 IGP point of view. 1161 12.5 Number of routes per VPN 1163 The number of routes per VPN has only an impact on the CE devices. 1164 The SP network and management system are not affected by the number 1165 of routes per VPN (except when static routes are configured by the 1166 SP). 1168 In a fully-meshed VPN, the number of routes a VPN can support is 1169 limited by the maximum number of routes that the 'smallest' CE can 1170 maintain. 1172 In a VPN with a hub and spoke topology, the number of routes a VPN 1173 can support is limited by the maximum number of routes that the hub 1174 CE can maintain (as the spoke CEs can be provisioned with a default 1175 route towards the hub CE). 1177 Independent of the VPN topology, the number of routes that a PE 1178 device needs to maintain is limited to one per CE interface. 1180 12.6 Impact of configuration changes 1182 The impact of configuration changes (e.g. the addition of a new site 1183 to an existing VPN) highly depends on the 'auto-discovery' mechanism 1184 used by the SP. The specifics of the autodiscovery mechanism used 1185 (reliability etc.) may have an impact on: 1187 - the number of devices to separately provision, 1189 - the increase of control traffic, 1191 - the convergence time, etc. 1193 Note that [CEVPN] does not specify an auto-discovery mechanism. 1195 Note also that other factors such as the rate of configuration 1196 changes may have an impact on the scalability of the VPN service. 1198 12.7 Performance impact 1200 The deployment of a CE-based VPN will have a performance impact on 1201 the system. 1203 With regards to the control plane, the CE devices will need to 1204 negotiate Security Associations and generate cryptographic key 1205 material. The initial SA negotiations are triggered by SP 1206 provisioning or by traffic flowing (traffic-driven SA setup). 1207 Established SA's need to be frequently 'refreshed' : new key material 1208 needs to be generated and exchanged. As such, the maintenance of SA's 1209 introduces a constant load on the CE's control plane. 1211 In the data-plane, the use of IPsec protected CE-to-CE tunnels means 1212 that every IP packet that is sent from one CE to another needs to be 1213 encrypted and/or authenticated by IPsec. This affects the performance 1214 as it requires additional processing and introduces some delay. 1216 Note that in a hub and spoke topology, this impact is doubled: a 1217 packet that flows from one spoke site to an other spoke site will be 1218 encrypted at the first spoke's CE, decrypted at the hub CE, routed at 1219 the hub CE, encrypted at the hub CE and finally decrypted at the 1220 destination spoke's CE router. 1222 12.8 Scalability of Key Distribution Infrastructure 1224 In the case where pre-shared keys are used by IPsec for the CE-to-CE 1225 SA, the Service Provider needs to maintain pre-shared keys for every 1226 CE-CE pair of the same VPN that need to protect a VPN tunnel. 1227 Securely storing these pre-shared keys, and more or less frequently 1228 generating and distributing fresh pre-shared keys for all established 1229 SAs may become a scalability concern when the number of SAs grows and 1230 when the rate of site addition/deletion grows. 1232 In the case where private/public keys are used in combination with 1233 digital certificates, the Service Provider must install/use a public 1234 key infrastructure (PKI). This has a number of implications for the 1235 SP. The SP needs to maintain a database that contains the digitally 1236 signed public keys of every participating CE device. The SP also 1237 needs to maintain a revocation database that contains the digitally 1238 signed public keys that are no longer valid (e.g. for removed VPN 1239 sites). The SP needs for every CE device to verify the integrity of 1240 the association. The SP must make sure that 1241 the CE device's private keys are (more or less frequently) re- 1242 generated, and must as a result of this re-keying generate a new 1243 certificate and distribute this. The SP must (more or less 1244 frequently) refresh its own private and public key that it uses to 1245 sign the necessary certificates, and as a result of this sign all 1246 existing certificates with its new keying material. 1248 These procedures are not different from any other PKI, and the 1249 scalability is dependent of the number of end-nodes (CE devices), of 1250 the number of secure connections to maintain and on the dynamicity of 1251 end node creation/deletion (VPN join and leave operations.) 1253 13. QoS, SLA 1255 In addition to the VPN service (reachability and security) from the 1256 SP, the VPN customer may want to acquire QoS features for its VPN. 1257 Dependent on the business scenario, the SLA will be provided by the 1258 VPN SP or by the Network Provider. 1260 Note that the fact that customer IP packets are encapsulated (and 1261 possibly encrypted) at the CE devices has an impact on the QoS 1262 treatment of the IP packets: QoS-related information inside the 1263 customer IP packets may become invisible. 1265 An eventual translation of QoS-related fields (e.g. DSCP) in the 1266 inner IP header to QoS-related fields in the outer IP headers need to 1267 be done at the CE-level and configured as such by the SP. Also the 1268 'policing' rules (e.g. certain customers not being allowed to use 1269 certain QoS values, etc.) need to be configured by the SP in the CE 1270 devices. The security infrastructure of the CE device must prevent 1271 the customer from messing with this provider-controlled 1272 configuration. 1274 The CE-CE tunneling applied in Provider Provisioned CE-based IPsec 1275 VPNs easily meets the DSCP transparency requirements of [REQS]. 1277 14. Management 1279 14.1 Configuration/provisioning 1281 Configuration by the SP comes in at two levels: VPN level and CE 1282 level. 1284 At the VPN level, the topology and security requirements must be 1285 determined. Common topologies include hub and spoke and full mesh. 1286 For large VPNs, a combination of simple topologies may be used, such 1287 as a full mesh core that connects individual hub and spoke 1288 topologies. A given VPN must have a general security grade selected, 1289 since every link of the VPN is expected to meet this security grade. 1290 In addition to the topology and security information, at the VPN 1291 level, when no inter-site tunneled dynamic routing is required, the 1292 reachability information may also be determined. 1294 At the CE level, each CE must know all of its CE peers in the same 1295 VPN, the security parameters, the tunnel attributes, the device or 1296 tunnel authentication credentials, and any associated routing setups. 1298 14.2 Customer management 1299 Since a customer outsources the VPN provisioning and management, it 1300 may not have the permission to change any of the VPN parameters in 1301 its CE devices. 1303 In a scenario where both the customer and the provider have VPN 1304 management responsabilities, the provider's management protocol will 1305 need to specify which parameters can be customer managed and which 1306 parameters cannot. An agreement between the customer and the service 1307 provider will need to specify which of the parameters that can be 1308 managed by the customer will be managed by the customer. 1310 It must be possible for the SP to retrieve the CE's actual 1311 configuration state, in order to verify whether the customer has not 1312 violated the agreement (e.g. an unintentional misconfiguration, or an 1313 intentional theft of QoS service). 1315 14.3 SLA monitoring 1317 It must be possible for the SP to retrieve the CE's actual 1318 configuration state, in order to verify whether the customer has not 1319 violated the agreement (e.g. an unintentional misconfiguration, or an 1320 intentional theft of QoS service). In addition to this, the SP may 1321 want to collect statistics by retrieving specific files from the CE 1322 devices. 1324 14.4 Security 1326 The security aspects of the VPN management system are extremely 1327 important. 1329 De SP's management system itself needs to be secured against 1330 misconfiguration, intrusion and denial-of-service attacks. 1332 De management protocol that is used to remotely provision the CE 1333 devices needs to provide for mutual authentication, encryption of the 1334 transported data, etc. 1336 The CE device must support the necessary security architecture, 1337 allowing for eventual dual-management, firewall support etc. 1339 14.5 Fault handling 1341 The faults that occur in the network(s) that interconnect CEs have an 1342 impact on the CE-to-CE routing. 1344 If the timers used for the CE-to-CE routing peering are shorter than 1345 the timers used for the routing peering within the service 1346 provider(s) network, then a single failure within a service provider 1347 network may look like a collection of uncorrelated failures in the 1348 VPN. 1350 Moreover, since a CE doesn't really "know" what causes the failure, 1351 the CE may react to such a failure by re-routing along some other 1352 tunnel, while this other tunnel may be also affected by the same 1353 failure. As a result, this would slow down routing convergence within 1354 the VPN. 1356 To avoid the problems mentioned above one may consider making the 1357 timers used for the CE-to-CE peering longer than the timers used for 1358 the routing peering within the service provider network (so that 1359 failures within the service provider network would be "invisible" to 1360 the CE-CE tunnels). But that has its own set of problems. While this 1361 may be possible to accomplish within a single routing domain (one 1362 needs to appropriately set the IGP timers within the domain), doing 1363 this in a network that includes more than one routing domain may be 1364 fairly problematic (as timers include both IGP and BGP timers, and 1365 moreover, timers include IGP timers in several routing domains). 1366 Moreover, making the timers used for the CE-to-CE peering over the 1367 tunnels longer than the timers used for the routing peering within 1368 the service provider network would increase the amount of traffic 1369 that will be "black holed" in the case of CE failures. 1371 15. Security considerations 1373 This draft contains sections that discuss in detail the security of 1374 provider provisioned CE-based IPsec VPNs. 1376 16. Acknowledgements 1378 The authors of this draft would like to thank Eric Rosen, Yakov 1379 Rekhter, Tom Nadeau, Marco Carugi and Ross Callon for their valuable 1380 comments and suggestions. 1382 17. References 1384 [ASGUIDE] Sumimoto J., et al., "Guidelines of Applicability State- 1385 ments for PPVPNs," work in progress. 1387 [CEVPN] De Clercq J., et al., "Provider Provisioned CE-based Vir- 1388 tual Private Networks using IPsec", draft-ietf-l3vpn-ce- 1389 based, work in progress. 1391 [FRMWORK] Callon R., et al., "A Framework for Layer-3 Provider Pro- 1392 visioned Virtual Private Networks," work in progress. 1394 [REQS] Carugi M., McDysan D., et al., "Service Requirements for 1395 Layer-3 Provider Provisioned Virtual Private Networks," 1396 work in progress 1398 [SEC-FW] Fang L., et al., "PPVPN Security Framework", work in pro- 1399 gress 1401 [TOUCH-VPN] Touch J., Eggert L., "Use of IPsec Transport Mode for 1402 Dynamic Routing", work in progress 1404 [1918] Rekhter Y., et al., "Address Allocation for Private 1405 Internets," RFC 1918, February 1996. 1407 [2026] Bradner S., "The Internet Standards Process - Revision 1408 3," RFC 2026, October 1996. 1410 18. Authors' Addresses 1412 Jeremy De Clercq 1413 Alcatel 1414 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 1415 E-mail: jeremy.de_clercq@alcatel.be 1417 Cliff Wang 1418 E-mail: cliff.wang@us.army.mil 1420 Dave McDysan 1421 WorldCom 1422 22001 Loudoun County Parkway 1423 Ashburn VA 20147, USA 1424 E-mail: dave.mcdysan@wcom.com