Network Working Group Jeremy De Clercq INTERNET DRAFT Alcatel Cliff Wang SmartPipes Dave McDysan Worldcom February 2002 Expires August, 2002 Applicability Statement for Provider Provisioned CE-based Virtual Private Networks using IPsec Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 ([RFC-2026]). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is submitted to the IETF's Provider Provisioned Virtual Private Network (ppvpn) working group. Comments should be addressed to WG's mailing list at ppvpn@ppvpn.francetelecom.com. The charter may be found at http://www.ietf.org/html.charters/ppvpn-charter.html Copyright (C) The Internet Society (2000). All Rights Reserved. Distribution of this memo is unlimited. Abstract This document is an applicability statement for Provider Provisioned CE-based IPsec VPNs, as discribed in [CEVPN]. This document De Clercq et al. Expires May 2002 [Page 1] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 describes how provider provisioned CE-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document [ASGUIDE]. 1. Sub-IP area summary This document is an output of the design team formed to develop applicability statements for Layer 3 PPVPNs in the PPVPN working group. As such this work fits within the scope of the PPVPN working group. This document discusses the applicability of CE-based IPsec approaches for PPVPNs. 2. Introduction This document provides an Applicability Statement for the VPN solution described in [CEVPN]. We refer to these VPNs as "provider provisioned CE-based IPsec VPNs". A VPN service is provided by a Service Provider to a Customer. Provider provisioned CE-based IPsec VPNs are intended for the situation in which: - a SP wants to offer VPN services to its customers without implementing VPN specific functions in its edge or backbone routers; - the customer does not trust the access network and the backbone networks that are used to interconnect the customer's sites; - CE-to-CE VPN data might need to be forwarded through the Internet; - the customer does not want to configure and manage the VPN- specific functions of its edge equipment; - the customer trusts its SP to properly and securely configure and manage its CE devices, and trusts the SP to take care of the security of its VPN; There are different business scenarios wherein PP CE-based IPsec VPNs can be offered to a customer. The first case is where the different sites of a customer attach to the network of a particular SP, and where this SP is offering VPN services to its customers. In that case the SP is both the managed VPN provider and the network provider. This case can be extended to a multi-SP scenario, where the SP, offering the VPN service and the network service, has trusting agreements with other SPs to enable De Clercq et al. Expires May 2002 [Page 2] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 customer sites that are not attached to the former SP to belong to the same VPN. The second case is where the different sites of a customer have access to the Internet via the (I)SP of their choice and where a (VPN) SP ('the SP') manages the customer's CE devices for VPN purposes. The basic scenario is the following. Every CE device has IP connectivity with the other CE devices that will belong to the same VPN (this can be via a SP's 'private network' or via the Internet). The SP's management system provisions the site's CE devices with the necessary topology and security information. The CE devices establish IPsec protected tunnels to the appropriate peering CE devices (according to the VPN's topology). The VPN sites start exchanging reachability information by tunneling routing protocol messages through the IPsec protected tunnels. Alternatively, the SP may provision static routes or tunnel traffic policy to the CEs, especially for those small size VPNs. Under that scenario, dynamic routing protocol tunneling is not required. In CE-based VPNs, there are different aspects that need to be provisioned on the customers' CE devices: the tunnels, the (IPsec) security aspects, the intra- and inter-site routing aspects. Now, depending on what aspects are provisioned by the SP and what aspects are provisioned by the customer, different scenarios can be considered, and these scenarios may have a different applicability. We can consider the following scenarios : (a) the customer provisions all aspects : this scenario will not be considered here, as it does not belong to the provider provisioned scope. (b) the SP provisions the VPN tunnels and the security aspects. The routing aspects are under control of the VPN customer: the customer treats the provisioned tunnels as (virtual) direct interfaces towards the other CE devices. (c) the SP provisions the VPN tunnels, the security aspects and the routing aspects in the CE devices. This means that the SP has complete control of the CE device (that has most likely been provided to the customer by that SP). (d) the SP provisions the CE devices and the other routers in the customer's site. This applicability statements document will cover scenarios (b) and De Clercq et al. Expires May 2002 [Page 3] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 (c). When dynamic routing is used, and the customers are responsible for the routing aspects on the CE devices (scenario (b)), the customers are free to choose the routing protocol(s) they want to use to distribute the reachability information (as long as these can be tunneled over IP or GRE). Note that the CEs in different sites are direct routing peers. The Service Provider does not interact in the customer routing. In the case that the SP manages all aspects on the CE device (scenario (c)), the customers are limited in the choice of their IGP to the IGPs that the SP provides on the CE devices. For provider provisioned CE-based IPsec VPNs, the topology of the VPN has an important impact on the scalability and the performance of the solution. All kinds of VPN topologies are supported by PP CE-based IPsec VPNs: hub and spoke topology, partial mesh topology, full mesh topology. In [CEVPN], the SP is responsible for provisioning the CE-devices with the necessary security information. Indeed, the CE devices that will use IPsec to protect the inter-site traffic, need (long-term) secure credentials. These credentials will be used by a key exchange protocol (such as IKE) to generate the actual (short-term) keys that will be used to protect the data traffic. One option for the (long-term) credentials is for the SP to directly configure them in the CE devices in the form of pre-shared keys (PSK). Alternatively, the SP can provide a public key infrastructure (PKI) to its VPN customers. 3. Applicability based on requirements that are common to all PPVPN types 3.1 Isolated exchange of routing and data information 3.1.1 Isolated data forwarding With CE-based IPsec VPNs, tunnels are deployed between CE devices. These tunnels are either IP-in-IP (or GRE) tunnels that are protected via IPsec in transport mode, or IPsec tunnel mode tunnels. In both cases, the forwarding in the shared infrastructure (access network and SP network(s)) is based on the IP addresses in the packets' outer IP header. These IP addresses can be public IP addresses (e.g. when the Internet is used for the CE-to-CE forwarding), or more generally IP addresses that belong the SP's De Clercq et al. Expires May 2002 [Page 4] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 addressing realm (these might be private addresses when the interconnectivity between CEs is offered by a particular SP). Note that if IP unnumbered is used between CE and PE devices, this IP address actually belongs to the PE. Isolated exchange of data information is assured because : (i) IP routing and forwarding takes care of forwarding the encapsulated IP packets to the correct destination CEs in the shared infrastructure, using the destination address in the IPsec packets. (ii) the customer IP packets can, if necessary, be encrypted on every CE-to-CE part of the network; as such, no intermediate router or other device that does not belong to the same VPN can read the customer traffic, even if mis-routing occurs. This is particularly applicable in the case that the Internet is used for forwarding the CE-to-CE traffic, as the SP then doesn't have control on the actual path of the customer traffic. 3.1.2 Constrained distribution of reachability to only VPN sites The distribution of VPN IP reachability information among VPN sites is achieved by tunneling the reachability information (in the form of routing protocol messages) through the CE-to-CE VPN tunnels. CE devices must be configured to forward reachability information only to those interfaces that are associated with the particular VPN : the intra-site interfaces and the IPsec-protected interfaces that lead to the other sites that belong to the same VPN. As such, the reachability information of one VPN site will only be distributed to other sites that belong to the same VPN. This also makes sure that VPN routes will not be distributed into the Internet, and that Internet routes will not be distributed to VPN sites (unless this behavior is explicitely expected and provisioned). Of course, configuration errors by the SP can compromise the constrained distribution of reachability, and the overall security of the VPN. [Note: A more detailed analysis of the effect of mis-configuration (how much must be mis-configured and what is the result or damage ?) will be discussed in a next version of this applicability statements draft.] 3.1.3 Internal VPN topology not visible to shared public network Note that in addition to the fact that the VPN reachability De Clercq et al. Expires May 2002 [Page 5] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 information distribution is isolated, the reachability information can also be carried in an encrypted form on the CE-to-CE part of the network. This means that even when misconfiguration, misrouting or malicious snooping occurs, the internal topology of the VPN is not visible outside of the considered VPN. 3.2 Overlapping customer address space In CE-based IPsec VPNs, it is assumed that the CE devices have one IP address that is public or that belongs to the SP's routing realm. These are the IP addresses that will be used in the encapsulating (outer) IP headers of the packets that will be sent on the CE-PE link. Next to this IP address (that will never be used by the customer's IGP for intra-site routing and forwarding), there is no constraint on the IP addresses that are internally used within the VPN. Overlapping customer addresses are supported (meaning that different VPN customers that are provisioned by the same (or different) SP may use overlapping address spaces). There is no requirement that such addresses be in conformance with RFC 1918. There is no requirement that customer VPN addresses be distinct from addresses in the SP network. Any set of addresses used in the VPN can be supported, irrespective of how they are assigned, how well they aggregate, whether they are public or private. However, the set of addresses which are reachable from a given site must be unique. Network address translation for packets leaving/entering a VPN is possible, and is transparent to the VPN scheme. 3.3 Management [Note : this section will be completed in following versions of this draft.] 3.3.1 Configuration/provisioning 3.3.2 Monitoring 3.3.3 Customer management 3.3.4 SLA monitoring 3.3.5 Security 3.4 Migration impacts De Clercq et al. Expires May 2002 [Page 6] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 The migration impacts that are discussed here deal with : (i) a customer who migrates from a legacy (frame-relay type) Layer-2 VPN to a provider provisioned CE-based IPsec VPN, or (ii) a customer who migrates from a customer provisioned CE-based IPsec VPN to a provider provisioned CE-based IPsec VPN. 3.4.1 Functions to be added to the customer's CE device - migration scenario (i) Assuming that the customer CE router has IP connectivity with the PE router, the following functionality needs to be added on the customer equipment: - the customer's CE device needs to implement the IPsec protocol suite and an IPsec key exchange functionality, such as IKE. - the CE device needs to support a highly secure management channel from the SP's management system. - the CE device's routing protocol(s) need to treat the different IPsec secured CE-to-CE tunnels as independent interfaces. - migration scenario (ii) TBD. 3.4.2 functions to be added by the Service Provider - The SP needs to deploy a secure management system that is able to configure and manage a large amount of CE devices per VPN customer. - In the case that the SP is also the backbone network provider, the SP needs to provide IP connectivity between CE devices. - The SP needs to be able to define topology, security protection, and reach-ability attributes for each customer VPN it manages. - The SP needs to be able to configure each managed CE, based on the attributes of the VPN that the CE belongs to. - The SP needs to be able to update each VPN, based on customer needs from time to time. Changes such as adding or deleting VPN sites, upgrading VPN functions are common. De Clercq et al. Expires May 2002 [Page 7] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 - The SP needs to have the capability of managing and monitoring the SLA of its VPN. - The SP needs to be able to gather and creating appropriate usage and accounting report for each VPN it manages. 3.5 Supported topologies and traffic types Provider provisioned CE-based IPsec VPNs allow for all desired topologies: fully meshed VPNs, hub and spoke VPNs, partially meshed VPNs, etc. The customer VPN may carry both user data and control data. User data is the site-to-site traffic that carries user applications. The control data may contain site-to-site reachability, keep-alives, etc. Provider provisioned CE-based IPsec VPNs are not targetted at providing Layer-2 services. By (GRE- or IP-) encapsulating Layer-2 datagrams at the CE devices first, this traffic-type can be transported with CE-based IPsec VPNs. Carrying multicast traffic with CE-based IPsec VPNs will require the (GRE- or IP-) encapsulation of multicast-packets at the CE devices first. 4. Applicability based on requirements that are specific to Layer-3 PPVPNs Note that the use of the IPsec protocol suite is not a requirement per se with regards to provider provisioned CE-based VPNs. A SP could offer a VPN service that uses non-encrypted or authenticated site- to-site tunnels (using e.g. IP-in-IP, GRE, L2TP). Whether (IPsec) secured tunnels are used or not has a large impact on the applicability of the offered VPN service. This version of the applicability statements draft focusses on IPsec-secured CE-based VPNs. 4.1 Security [Note : A more detailed analysis of provider provisioned CE-based IPsec VPNs with regards to security will be documented in a next version of this applicability statements draft.] 4.1.1 Customer data security Customer data, both control plane data and user plane data are encapsulated by IPsec before sent to the shared SP backbone. The De Clercq et al. Expires May 2002 [Page 8] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 customer data remain to be protected until it reaches the peer CE. When the customer data is encrypted by IPsec, it is considered secure when it is being transferred through the shared IP backbone. [Note : A more detailed analysis of the customer data security will be documented in a next version of this draft.] 4.1.2 SP data security A management channel exists between SP and the managed CE. It is important for SP to build a secure management channel to prevent attacks from the adversary. [Note: A more detailed analysis of the SP data security will be documented in a next version of this draft.] 4.2 Tunneling 4.2.1 Supported tunneling techniques In provider provisioned CE-based IPsec VPNs, VPN tunnels are initiated and terminated at the CE devices, and it is assumed that the PE devices receive IP packets from the CE-PE links. This limits the supported tunneling techniques to IP-in-IP, L2TP, GRE and IPsec (tunnel mode). [CEVPN] uses IPsec (transport mode) protected IP-in-IP or GRE tunnels, or IPsec tunnel mode tunnels. 4.2.2 Tunnel termination points The tunnel termination points in CE-based IPsec VPNs are the CE devices. 4.3 QoS TBD. 4.4 Scalability See section 5.1 4.5 Internet Access from within a VPN [Note : this section will be completed in future versions of this draft.] When the CE-based VPN traffic shares the access with Internet- traffic, a denial of service attack from sites outside the VPN is possible, while such an attack can only come from other VPN sites De Clercq et al. Expires May 2002 [Page 9] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 when the access connection is not shared with the Internet. 5. Applicability based on requirements that are specific to CE-based PPVPNs using IPsec An important aspect of CE-based PPVPNs using IPsec is the presence of a key-distribution system. This is the system that provides the CE devices with the (long term) credentials. When this key distribution system provides the CE devices with pre- shared keys, then this key distribution can be done together with the configuration of the CE devices by the SP management system. Alternatively, the SP may provide its VPNs with a Public Key Infrastructure, with the cost of extra complexity. 5.1 Scalability This section discusses how certain specific VPN-metrics affect the scalability of the VPN-solution. 5.1.1 Number of supported VPNs It is assumed that a certain site is only part of one VPN. Architectures that allow sites to be a member of multiple VPNs will have impact on the CE devices and on the supported addressing schemes. When a site can be a member of only one VPN, the number of VPNs that a SP can support has an impact on the SP's management system. For every supported VPN, the SP's management system will need to be able to provision every site's CE device that belongs to that VPN. The management system will need to maintain information that is specific for every VPN site (IP addresses of the other peering sites in the considered VPN, security information, etc.). The number of VPNs that a SP can support is dependent on the number of sites per VPN and is limited by the number of management sessions the SP's VPN management system can support and the amount of VPN information the SP's VPN database can maintain. Note however that when the number of VPNs increases, the SP can deploy additional management systems with their own VPN databases : the SP can use multiple independent management systems as there is no interaction between different VPNs. 5.1.2 Number of sites per VPN De Clercq et al. Expires May 2002 [Page 10] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 In a fully-meshed VPN, the number of sites per VPN has an impact on the CE devices within that VPN and on the SP's management system. In a particular fully-meshed VPN, for every additional site, a certain CE router needs to maintain an additional VPN tunnel (in the form of an additional Security Association) and additional reachability information. For every VPN site, the SP's management system will need to maintain some information and will need to be able to establish a management connection to the site's CE device. The number of sites per VPN has an impact of O(n) on the CE devices, and has an impact of O(n^2) on the number of tunnels that the SP management system needs to provision (in a fully-meshed VPN). In VPNs that are not fully meshed (partial mesh or hub and spoke topology), the impact of the number of sites per VPN on the scalability of the system is reduced. In a hub and spoke VPN, the CE of the hub site still needs to maintain as much tunnels as there are other sites (n-1), and will still need to maintain the complete set of VPN routes. The CEs of the spoke sites on the other hand, need only to maintain one tunnel towards the hub CE. Moreover, in a hub and spoke topology, the spoke CEs may not need to maintain the other CE's routes: a default route towards the hub CE may suffice. The SP's management system needs to maintain O(n) tunnels in a hub and spoke VPN. 5.1.3 Number of tunnels per VPN The number of tunnels per VPN depends on the number of sites per VPN and on the VPN topology. The hub-and-spoke topology requires the least amount of tunnels to provide inter-connection among all participating sites (O(n)), while a fully meshed VPN requires the most tunnels (O(n^2)). Aside from the number of tunnels, the VPN security attributes also affect the scalability of a VPN. For example, when a VPN uses 3DES as the tunnel encryption scheme, the total number of tunnels that a hub may support may be smaller than the case when e.g. DES is selected. 5.1.4 Number of tunnels per CE The number of tunnels to be supported by a CE device has implications on the performance of that CE device : every supported tunnel represents a new interface; every tunnel is protected by a specific De Clercq et al. Expires May 2002 [Page 11] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 Security Association. The overall CE performace will decline when the number of tunnels increases as the memory consumption increases and the processing increases. The increase of the processing is manyfold: - packets that are sent over a specific tunnel will need to be authenticated and/or encrypted - every Security Association that protects a tunnel needs to be frequently re-negotiated. This (frequent) re-keying of existing (permanent) tunnels requires a certain amount of processing (key generation) and of control protocol message exchanges (via IKE or an alternative key exchange protocol). The number of tunnels a CE will need to support at a given time can be dependent on whether 'traffic-driven' tunnel set-up or 'traffic- independent' tunnel set-up is used. Note that the use of traffic-driven tunnel set-up has important implications. In traffic-driven tunnel establishment, if a certain tunnel does not carry traffic during a certain amount of time, the IPsec SA will be removed. When traffic starts flowing again, a new Security Association will need to be established first. The two tunnel endpoints will re-negotiate the necessary SAs, and will generate the necessary key material. This behavior does not only introduce control protocol message exchanges but also a considerable delay in the forwarding of the user packets. Note also that the inter-site reachability distribution interacts with traffic-driven tunnel establishment : routing protocols send routing updates and keep-alive messages, even when no actual user traffic is flowing. As such, traffic-driven tunnel set-up may be applicable in CE-based IPsec PPVPNs that use statically provisioned routing information. The use in an environment that dynamically distributes inter-site reachability is much more complicated and not advised. The impact of the number of tunnels per CE on the customer's IGP is TBD. 5.1.5 Number of routes per VPN The number of routes per VPN has only an impact on the CE devices. The SP network and management system are not affected by the number of routes per VPN (except when static routes are configured by the SP). De Clercq et al. Expires May 2002 [Page 12] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 In a fully-meshed VPN, the number of routes a VPN can support is limited by the maximum number of routes that the 'smallest' CE can maintain. In a VPN with a hub and spoke topology, the number of routes a VPN can support is limited by the maximum number of routes that the hub CE can maintain. 5.1.6 Rate of configuration changes TBD. 5.1.7 Impact of adding a new site : how does this increase control traffic; convergence time ? TBD. 5.1.8 Performance impact The deployment of a CE-based VPN will have a performance impact on the system. With regards to the control plane, the CE devices will need to negotiate Security Associations and generate cryptographic key material. The initial SA negotiations are triggered by SP provisioning or by traffic flowing (traffic-driven SA setup). Established SA's need to be frequently 'refreshed' : new key material needs to be generated and exchanged. As such, the maintenance of SA's introduces a constant load on the CE's control plane. In the data-plane, the use of IPsec protected CE-to-CE tunnels means that every IP packet that is sent from one CE to another needs to be encrypted and/or authenticated by IPsec. This affects the performance as it requires additional processing and introduces some delay. Note that in a hub and spoke topology, this impact is doubled: a packet that flows from one spoke site to an other spoke site will be encrypted at the first spoke's CE, decrypted at the hub CE, routed at the hub CE, encrypted at the hub CE and finally decrypted at the second spoke's CE router. [Note : The scalability analysis of the SP's eventually provisioned PKI will be discussed in further versions of this draft.] 5.2 Addressing See section 3.2 De Clercq et al. Expires May 2002 [Page 13] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 5.3 Management 5.3.1 Configuration/provisioning Configuration by the SP comes in at two levels: VPN level and CE level. At the VPN level, the topology and security requirements must be determined. Common topologies include hub and spoke and full mesh. For large VPNs, a combination of simple topologies may be used, such as a full mesh core that connects individual hub and spoke topologies. A given VPN must have a general security grade selected, since every link of the VPN is expected to meet this security grade. In addition to the topology and security information, at the VPN level, when no inter-site tunneled dynamic routing is required, the reachability information may also be determined. At the CE level, each CE must know all of its CE peers in the same VPN, the security parameters, the tunnel attributes, the device or tunnel authentication credentials, and any associated routing setups. 5.3.2 Monitoring TBD. 5.3.3 Customer management Since a customer outsources the VPN provisioning and management, it may not have the permission to change any of the VPN parameters in its CE devices. 5.3.4 SLA monitoring TBD. 5.3.5 Security TBD. 5.3.6 Fault handling The faults that occur in the network(s) that interconnect CEs have an impact on the CE-to-CE routing. If the timers used for the CE-to-CE routing peering are shorter than the timers used for the routing peering within the service provider(s) network, then a single failure within a service provider network may look like a collection of uncorrelated failures in the De Clercq et al. Expires May 2002 [Page 14] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 VPN. Moreover, since a CE doesn't really "know" what causes the failure, the CE may react to such a failure by re-routing along some other tunnel, while this other tunnel may be also affected by the same failure. As a result, this would slow down routing convergence within the VPN. To avoid the problems mentioned above one may consider making the timers used for the CE-to-CE peering longer than the timers used for the routing peering within the service provider network (so that failures within the service provider network would be "invisible" to the CE-CE tunnels). But that has its own set of problems. While this may be possible to accomplish within a single routing domain (one needs to appropriately set the IGP timers within the domain), doing this in a network that includes more than one routing domain may be fairly problematic (as timers include both IGP and BGP timers, and moreover, timers include IGP timers in several routing domains). Moreover, making the timers used for the CE-to-CE peering over the tunnels longer than the timers used for the routing peering within the service provider network would increase the amount of traffic that will be "black holed" in the case of CE failures. 5.4 QoS and SLA In addition to the VPN service (reachability and security) from the SP, the VPN customer may want to acquire QoS features for its VPN. Dependent on the business scenario, the SLA will be provided by the VPN SP or by the Network Provider. Note that the fact that customer IP packets are encapsulated (and possibly encrypted) at the CE devices has an impact on the QoS treatment of the IP packets: QoS-related information inside the customer IP packets may become invisible. An eventual translation of QoS-related fields (e.g. DSCP) in the inner IP header to QoS-related fields in the outer IP headers need to be done at the CE-level. [Note: A more detailed discussion of QoS and SLAs will be provided in a next version of this draft.] 5.5 Access Network requirements 5.5.1 Access types supported CE-based IPsec VPNs are applicable in every access scenario where the CE device has IP connectivity with the PE device. Every CE device De Clercq et al. Expires May 2002 [Page 15] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 only needs one IP address that is routable in the shared backbone. This CE-PE IP connectivity may be provided over any Layer-2 infrastructure (PPP, ATM, Frame Relay, etc.). 5.5.2 Access QoS support TBD. 5.5.3 Access security support CE-based IPsec VPNs have the additional advantage that the security of the VPN is not dependent on the security of the access network. Customer data packets may traverse the access network in an encrypted way. Note however that, as IP packets that are sent from CE to PE are not authenticated by the PE devices, the CE-based IPsec VPN model does not protect against resource spoofing by invalid users. An intruder can still inject traffic on the access link, which will be forwarded by the PE device. 6. Security considerations This draft contains sections that discuss the security of provider provisioned CE-based IPsec VPNs. 7. Acknowledgements The authors of this draft would like to thank Eric Rosen, Yakov Rekhter, Tom Nadeau and Marco Carugi for their valuable comments and suggestions. 8. References [ASGUIDE] Sumimoto J., et al., "Guidelines of Applicability State- ments for PPVPNs," work in progress. [CEVPN] De Clercq J., et al., "Provider Provisioned CE-based Vir- tual Private Networks using IPsec", draft-ietf-ppvpn-ce- based-01.txt, work in progress. [FRMWORK] Callon R., et al., "A Framework for Layer-3 Provider Pro- visioned Virtual Private Networks," work in progress. [REQS] Carugi M., McDysan D., et al., "Service Requirements for Layer-3 Provider Provisioned Virtual Private Networks," work in progress De Clercq et al. Expires May 2002 [Page 16] Internet Draft draft-declercq-ppvpn-ce-based-as-00.txt February 2002 [1918] Rekhter Y., et al., "Address Allocation for Private Inter- nets," RFC 1918, February 1996. [2026] Bradner S., "The Internet Standards Process - Revision 3," RFC 2026, October 1996. 9. Authors' Addresses Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: jeremy.de_clercq@alcatel.be Cliff Wang SmartPipes 565 Metro Place South Dublin, OH 43017, USA Phone: 1-614-923-6241 E-mail: cwang@smartpipes.com Dave McDysan WorldCom 22001 Loudoun County Parkway Ashburn VA 20147, USA E-mail: dave.mcdysan@wcom.com De Clercq et al. Expires May 2002 [Page 17]