Network Working Group Jeremy De Clercq INTERNET DRAFT Alcatel Cliff Wang SmartPipes Dave McDysan Worldcom June 2002 Expires December, 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 December 2002 [Page 1] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 describes how provider provisioned CE-based approaches meet the key requirements that are outlined in the PPVPN Applicability Statements Guideline document [ASGUIDE]. Table of Contents De Clercq et al. Expires December 2002 [Page 2] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 0. Sub-IP Area Summary ........................................ 3 1. Introduction ............................................... 4 2. SP Provisioning Model ...................................... 6 3. Supported Topologies and Traffic Types ..................... 7 4. Isolated Exchange of Data and Routing Information .......... 8 4.1 Isolated forwarding of VPN data ............................ 8 4.2 Constrained Distribution of Reachability Information ....... 8 4.3 Hiding the Internal VPN Topology ........................... 9 5. Security ................................................... 9 5.1 Protection of User Data .................................... 9 5.2 SP Security Measures ....................................... 10 6. Addressing ................................................. 10 7. Interoperability and Interworking .......................... 10 8. Network Access ............................................. 11 8.1 Access types supported ..................................... 11 8.2 Access QoS support ......................................... 11 8.3 Access security support .................................... 11 9. Service Access ............................................. 11 9.1 Internet Access ............................................ 11 9.2 Hosting, ASP, Other Services ............................... 12 10. SP Routing ................................................. 12 11. Migration Impact ........................................... 12 11.1 Functions to be added to the customer's CE device .......... 12 11.2 Functions to be added by the Service Provider .............. 13 12. Scalability ................................................ 13 12.1 Number of supported VPNs ................................... 13 12.2 Number of sites per VPN .................................... 14 12.3 Number of tunnels per VPN .................................. 15 12.4 Number of tunnels per CE ................................... 15 12.5 Number of routes per VPN ................................... 16 12.6 Impact of configuration changes ............................ 16 12.7 Performance impact ......................................... 16 13. QoS, SLA ................................................... 17 14. Management ................................................. 17 14.1 Configuration/provisioning ................................. 17 14.2 Monitoring ................................................. 18 14.3 Customer management ........................................ 18 14.4 SLA monitoring ............................................. 18 14.5 Security ................................................... 18 14.6 Fault handling ............................................. 18 15. Security considerations .................................... 19 16. Acknowledgements ........................................... 19 17. References ................................................. 19 18. Authors' Addresses ......................................... 20 0. Sub-IP area summary De Clercq et al. Expires December 2002 [Page 3] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 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. 1. 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 (one or more of the following apply): - a SP wants to offer VPN services to its customers without implementing VPN specific functions in its edge (PE) or backbone (P) 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 or across multiple SPs; - 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 and of the VPN's key management; 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 trust agreements with other SPs to enable 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 De Clercq et al. Expires December 2002 [Page 4] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 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 backbone network'' that is owned by one SP and that may internally use private addressing, via a set of cooperating SPs' PE-based VPNs 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, for example for small-sized, 'static' VPNs. Under the latter scenario, dynamic routing protocol tunneling is not required. 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. Note that the tunnel termination points are always the CE devices. 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. In this document, that considers VPNs in the provider-provisioned scope, we consider the following scenarios : (a) 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 logical interfaces to CE devices at other VPN sites with a topology configured by the SP. (b) 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 which has most likely been provided to the customer by that SP. When dynamic routing is used, and the customers are responsible for De Clercq et al. Expires December 2002 [Page 5] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 the routing aspects on the CE devices (scenario (a)), 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 (b)), 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. 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. 2. SP Provisioning model In provider provisioned CE-based VPNs, the SP is responsible to provision the CE devices with the VPN-specific configuration information. The SP will install a secure management 'channel' towards every CE device, over which it can securely provision that CE device. This can for example be a specific IPsec tunnel, a secured Layer-4 channel, etc. The SP will provision every CE device with the IP addresses of the peer CE devices the considered CE has to maintain a VPN tunnel with. The number of these peer CE devices depends on the number of sites the VPN contains and on the topology of the VPN. In [CEVPN], the SP is responsible for provisioning the CE-devices with the necessary 'security information' that is needed to establish and maintain IPsec Security Associations with the peer CE devices: a set of transforms to use with IPsec, tunnel property information and IKE credentials. Indeed, the CE devices that will use IPsec to De Clercq et al. Expires December 2002 [Page 6] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 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. 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. If alternatively, the SP provides its VPNs with a Public Key Infrastructure, this adds extra complexity, but also supports the potential for multi-SP CE-based VPNs. For scalability purposes, the SP should use an 'automatic update' scheme such that the addition of a VPN site to an existing VPN requires the provisioning of only that new CE device (in contrast to the need to manually provision every existing CE device in the considered VPN). 3. 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. Configuring a specific required VPN topology is a matter for the SP of provisioning every member CE device with the IP addresses of the appropriate peer CE devices the considered CE device has to maintain a VPN tunnel with. 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 information, keep-alives, etc. Provider provisioned CE-based IPsec VPNs are not targeted 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. Multicast support in CE-based VPNs means for a basis scenario that CE devices need to be provisioned to be able to duplicate multicast packets over the different VPN tunnels it maintains. De Clercq et al. Expires December 2002 [Page 7] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 [note: whether the multicast functions are all performed at CE or PE, and managed by SP or customer is TBD]. 4. Isolated Exchange of Data and Routing Information 4.1 Isolated forwarding of VPN data 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 [TOUCH-VPN], 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 addressing realm (these might be private or non-unique addresses when the interconnectivity between CEs is offered by one 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 are usually 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 or intercept 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. 4.2 Constrained Distribution of Reachability Information The distribution of VPN IP reachability information among devices at the 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 : that is, the intra-site interfaces and the IPsec- protected interfaces that lead to the other sites that belong to the same VPN. De Clercq et al. Expires December 2002 [Page 8] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 As such, the reachability information of one VPN site will only be distributed to other sites that belong to the same VPN. This also ensures 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 explicitly 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.] 4.3 Hiding the Internal VPN Topology Note that in addition to the fact that the VPN reachability information distribution is isolated, the reachability information can also be carried in an encrypted form on the CE-to-CE part of the network (by sending the routing information messages through the provisioned CE-CE IPsec tunnels). This means that even when misconfiguration, misrouting or malicious snooping occurs, the global VPN topology and the internal topology of the VPN sites is not visible outside of the considered VPN. 5. 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.] CE-based VPNs using IPsec are specifically applicable in situations where security is a very important requirement. This type of VPNs allows the customer's data and control traffic to be secured (via encryption) on every shared part of the network, using the very secure and reliable IPsec protocol suite. The result of this is that the customer traffic is not only isolated (via tunnelling) from the other traffic that uses the same backbone, but that the customer traffic is also unreadable (because encrypted) and as such protected against e.g. malicious eavesdropping. IPsec encryption with optional authentication and replay attack prevention directly meet all of the security requirements in [REQS], as long as key distribution is not compromised. 5.1 Protection of User Data De Clercq et al. Expires December 2002 [Page 9] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 Customer data, both control plane data and user plane data are encapsulated by IPsec before sent to the shared SP backbone. The customer data is 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.] 5.2 SP Security Measures 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 (example: IPsec tunnel, SSH/TLS session). [Note: A more detailed analysis of the SP security measures will be documented in a next version of this draft (including the implications of a key management system).] 6. Addressing 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 tunneled packets that will be sent on the CE-PE link. Beyond use of this CE 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) in different VPNs. 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 VPN site must be unique. Network address translation for packets leaving/entering a VPN is possible, and is transparent to the VPN scheme. 7. Interoperability and Interworking Interoperability considerations will be detailed in a future version of this applicability statements document. De Clercq et al. Expires December 2002 [Page 10] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 As all the different types of Layer-3 VPNs are IP networks, they can of course interwork in the same way that any two IP networks can interwork. For example, a single site can contain a CE router that participates in one VPN scheme (e.g. a Provider Provisioned CE-based VPN solution) and a CE router of another VPN scheme (e.g. a CE that is attached to a 2547bis PE's VRF), and these CE routers could be IGP peers, or they might even be the same CE router. This would result in the redistribution of routes from one type of VPN to the other, providing the necessary interwoking. 8. Network Access 8.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 only needs one IP address that is routable in the shared backbone. This CE-PE IP connectivity may be provided over any Layer-1 and Layer-2 infrastructure (PPP, ATM, Frame Relay, etc.). 8.2 Access QoS support TBD. 8.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 and Denial of Service Attacks by invalid users. An intruder can still inject traffic on the access link, which will be forwarded by the PE device towards the destined CE device. 9. Service Access 9.1 Internet Access [Note : this section will be completed in future versions of this draft.] Internet access and VPN access are possible from the same site. Different ways to accomplish this service are possible. One restriction is that the VPN's internal addresses must be distinct De Clercq et al. Expires December 2002 [Page 11] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 from the IP addresses of the systems which must be reached via the Internet. The required NAT and firewall functions are implemented in one or more of the VPN's CE devices. When the CE-based VPN traffic shares the access (CE-PE part of the network) 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 when the access connection is not shared with the Internet. [note: incorrect statement? the site's CE address is at least known by the SP, and possibly by other VPNs or even the Internet ??] 9.2 Hosting, ASP, Other Services TBD. 10. SP Routing Routing through the backbone(s) is independent of the VPN scheme, and is unaffected by the presence or absence of VPNs. The only impact is that the backbone routing (or Internet routing) must carry the routes to the CE devices. The use of CE-CE IP tunnels is not impacted by (and is thus complementary with) any PE-PE tunneling that the Network Provider might deploy in its backbone network (e.g. PE-PE MPLS LSPs for Traffic Engineering reasons). 11. Migration Impact The migration impacts that are discussed here deal with : (i) a customer who migrates from a legacy (frame-relay type) IP over 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. 11.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 De Clercq et al. Expires December 2002 [Page 12] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 IKE. - the CE device needs to support a highly secure management channel from the SP's management system [note: example to be added]. - the CE device's routing protocol(s) needs to treat the different IPsec secured CE-to-CE tunnels as independent interfaces. - migration scenario (ii) TBD. [note: including the key/certificate management] 11.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 [note: such as?] are common. - The SP may need to have the capability of managing and monitoring the SLA of the cusomer's VPN. - The SP needs to be able to gather and create appropriate usage and accounting report for each VPN it manages. 12. Scalability This section discusses how certain specific VPN-metrics affect the scalability of the VPN-solution. 12.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 De Clercq et al. Expires December 2002 [Page 13] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 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. 12.2 Number of sites per VPN 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 one 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 IPsec 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 (n) 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 many 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 De Clercq et al. Expires December 2002 [Page 14] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 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. 12.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. 12.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 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 De Clercq et al. Expires December 2002 [Page 15] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 generate the necessary key material. This not only introduces control protocol message exchanges but also 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 (every tunnel is seen as an interface from the IGP point of view). 12.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). 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 (as the spoke CEs can be provisioned with a default route towards the hub CE). Independent of the VPN topology, the number of routes that a PE device needs to maintain is limited to one per CE interface. 12.6 Impact of configuration changes TBD: impact of eg adding a site (how does this increase control traffic; what is the convergence time ?); impact of the rate of configuration changes; possible rate of configuration changes? 12.7 Performance impact The deployment of a CE-based VPN will have a performance impact on the system. De Clercq et al. Expires December 2002 [Page 16] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 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 destination spoke's CE router. [Note : The scalability analysis of the SP's eventually provisioned PKI will be discussed in further versions of this draft.] 13. QoS, 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. The CE-CE tunneling applied in Provider Provisioned CE-based IPsec VPNs easily meets the DSCP transparency requirements of [REQS]. [Note: A more detailed discussion of QoS and SLAs will be provided in a next version of this draft.] 14. Management 14.1 Configuration/provisioning De Clercq et al. Expires December 2002 [Page 17] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 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. 14.2 Monitoring TBD. 14.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. 14.4 SLA monitoring TBD. 14.5 Security TBD. 14.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 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 De Clercq et al. Expires December 2002 [Page 18] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 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. 15. Security considerations This draft contains sections that discuss the security of provider provisioned CE-based IPsec VPNs. 16. 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. 17. 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-02.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 [TOUCH-VPN] Touch J., Eggert L., "Use of IPsec Transport Mode for Dynamic Routing", work in progress De Clercq et al. Expires December 2002 [Page 19] Internet Draft draft-declercq-ppvpn-ce-based-as-01.txt June 2002 [1918] Rekhter Y., et al., "Address Allocation for Private Internets," RFC 1918, February 1996. [2026] Bradner S., "The Internet Standards Process - Revision 3," RFC 2026, October 1996. 18. 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 December 2002 [Page 20]