Internet Draft Internet Engineering Task Force Jieyun (Jessica) Yu INTERNET DRAFT Lianghwa Jou Expires in January, 2001 Abbie Matthews Vijay Srinivasan CoSine Communications July, 2000 Criteria for Evaluating VPN Implementation Mechanisms draft-yu-vpn-criteria-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract A variety of mechanisms for implementing Virtual Private Network (VPN) utilizing public IP network infrastructure have been proposed in [1,2,3,4] and more may be emerging. This document attempts to identify a set of criteria for evaluating such mechanisms. The criteria could be used by IETF for evaluating a VPN proposal before advancing it to standard track or by VPN Service Providers or enterprise network administrators for choosing which mechanism to use in order to implement their desired VPN networks. The mechanisms this criteria addresses are exclusively for implementing IP based VPNs, as oppose to non-IP based ones, such as Frame Relay based VPNs, etc. 1. Introduction Yu, et al. [Page 1] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 A Virtual Private Network (VPN), in general, can be described as an emulated private communication infrastructure utilizing shared communication facilities. It is usually built by utilizing public Internet infrastructure or ISP backbone network. VPN is a cost- effective alternative for enterprises conducting internal private communications involving geographically diverse sites. A variety of mechanisms for implementing VPN utilizing public IP network infrastructure have been proposed [1,2,3,4] and more may be emerging. This document attempts to identify a set of criteria for evaluating such mechanisms. The criteria could be used by IETF for evaluating a VPN proposal before advancing it to standard track or by VPN Service Providers or enterprise network administrators for choosing which mechanism to use in order to implement their desired VPN networks. It is worthy noting that the mechanisms this set of criteria addresses are exclusively for implementing IP based VPNs as oppose to non-IP based ones, such as Frame Relay or ATM based VPNs. 2. Basic Criteria The very basic criteria of VPN are virtual and private. By Virtual, we mean, the network has no correspondent physical network, rather is an emulated infrastructure utilizing underlying public network infrastructure. By Private, we mean, access to such network is restricted only to a defined set of entities and the data transmitted across the VPN should not be read by outside of the network. In order to be characterized as a VPN implementation mechanism, a mechanism must provide a means of implementing VPNs with these two basic characteristics. 3. Other Criteria for Evaluating VPN Implementation Mechanisms The basic components of a VPN implementation mechanism should include mechanisms for a) membership identification, verification and dissemination; b) Intra-VPN routing and routing interaction between VPN and its underlying network(s); and c) forwarding. With these basic components in mind, a VPN implementation mechanism can be evaluated, in general, with the following aspects: o Security o Architecture o Manageability o Scalability o Feature support Yu, et al. [Page 2] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 It is worthy noting that with security criteria, different degree of requirement may vary with respect to different VPNs. For example, while it is an absolute requirement for some VPNs to encrypt data transmitted over the VPN, it may not be top consideration for others. Therefore, specific requirement of a particular VPN should be taken into consideration when such evaluation is taking place. 3.1. Security A VPN implementation mechanism should provide means for data security and network security. 3.1.1. Data Security Data security includes data integrity, data confidentiality and data origin authentication. o Data integrity One of the security concerns is that data could be altered or tampered while transmitted across the Internet. A VPN mechanism needs to provide mechanisms to ensure the integrity of data exchanged within the VPN. o Data confidentiality A VPN mechanism should provide means for ensuring that no unauthorized party reading or copy the VPN private data while transmitting across the underlying public network. An example of such mechanism is data encryption. o Data origin authentication A VPN mechanism should provide ways for authenticate the origin of data to ensure that the source of the data is what it claims to be. 3.1.2. VPN Network Security VPN network security provides the ability to guarantee that only approved recipients receive the VPN's routing information and data. o Site authorization and authentication A VPN will suffer from undesirable security consequences when an unauthorized site becomes part of the VPN network. To ensure a secure VPN network, a VPN implementation mechanism should provide means of establishing connections only with the authorized entities (sites) in the initial VPN construction process as well as in the Yu, et al. [Page 3] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 reconfiguration process. To achieve the goal, a form of site authentication prior to establishment of the connection is required and should be provided. o Access control Access control involves policy of who can access the VPN network. Access control mechanism should be provided by a VPN implementation mechanism to restrict access thus to protect the privacy of the VPN network. o Routing Security The goal of achieving routing security in a VPN is to prevent routers of a VPN from interaction with unauthorized entities, to prevent routes to VPN destinations from leaking to undesired entities, and to avoid introducing undesired routing information to taint the VPN routing information base. o VPN Isolation Certain VPN implementation mechanism provides capability of supporting multiple VPNs utilizing the same set of devices (e.g. Edge routers of a provider network.) Mechanisms, such as separate forwarding table for each VPN on the device, must be provided to prevent unintended traffic from one VPN entering another to ensure privacy and security of the VPNs. 3.2. Architecture 3.2.1. Flexible Topology A set of virtual links between sites belong to a VPN constitutes the topology of the VPN network. A virtual link can be realized via the construction of a tunnel such as IPsec VPN mechanism [2] or via establishing direct routes as with BGP4/MPLS VPN mechanism [1]. Based on its requirement, an enterprise may desire the topology of its VPN network as full-mesh, partial-mesh or hub-and-spoken. A VPN implementation mechanism should be flexible to allow constructing VPN topology based on the requirement accordingly. 3.2.2. Hierarchy Different architecture may result in different scalability of its correspondent VPN. For example, provider network-based VPN architecture allows a provider edge router to connect many customer premises equipment (CPE) routers in a region. The topology mesh will Yu, et al. [Page 4] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 be built among the Provider Edge routers. This architecture scales better than CPE based VPN where the tunnel meshes are formed among the CPE routers which has a lot more in numbers for large VPNs. In addition, by introducing this hierarchy, configuration and management complexity will be moved to a smaller set of Provider Edge routers rather than large amount of CPE devices. Therefore, it is desirable for a VPN implementation mechanism to provide means for building VPN with hierarchy. 3.2.3. Independency Although a VPN is a virtual infrastructure built on top of public network infrastructure, maintaining as much independence from its underlying network infrastructure as possible yields many advantages. The advantages include fault isolation and operation transparency, which would improve the stability of both VPN network as well as the underlying network(s). 3.2.3.1. Backbone Technology Independence An enterprise VPN network may span across multiple ISP network domains. Two VPNs with different ISP network as underlying infrastructure may need to merge into one VPN due to event such as corporate merge. To facilitate the interconnection, it is desirable that a VPN implementation mechanism be independent of underlying network or backbone technology. It should avoid assuming or requiring ISPs running certain protocols other than IP protocol. For those VPNs that only cross one ISP network (which is the most cases in today's implementation), this criterion is of less concern. 3.2.3.2. Addressing Independence A VPN mechanism should not require the binding of IP address space of the VPN to its underlying IP network. In another word, the IP addresses assigned within a VPN network should be independent of that assigned in its underlying IP network/backbone. By assigning separate IP address space from its underlying network, a VPN administrator is able to manage IP address within the VPN independently since he/she is able to add, change and remove IP addresses without coordinating with the administrator of the underlying IP network. By not tying VPN's IP address space with a particular underlying network, the VPN can migrate to other underlying IP network without changing the IP address, making such migration easier. Yu, et al. [Page 5] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 By using independent IP address space from its underlying network, a VPN is able to use private IP address space. Using private IP address space helps conserving scarce IPv4 address space. It also makes it feasible for the use of overlapping IP address space for VPNs that do not have common sites. This again will make the use of private IP address space feasible. 3.2.3.3. Routing Independence Overall, routing of a VPN can be viewed as composed of two parts: a) obtaining routing knowledge to reach the private destinations (prefixes reachable within the VPN.) and b) obtaining routing information to VPN sites reachable via the underlying public network. While for b), VPN routers have to participant the routing of the underlying network, for a) they do not have to. That is, routing technology used for reachability within a VPN can be completely independent from that of the underlying network. Having an independent routing system will enhance VPN network security and minimize unnecessary outages due to routing instability in the underlying network and vice versa. Routing associated outages or instability in the VPN layer, caused by for example misbehaving routing software or mis-configurations, will not impact the routing and/or the stability in its underlying network. In addition, VPN prefixes will not need to be advertised to the underlying public network's routing table, which enhances the security of the VPN. Not leaking VPN prefixes in the underlying network also reduces routes in the underlying network, hence improving routing scalability of the underlying provider network. A VPN implementation mechanism should allow as much independent routing of VPN from its underlying network as possible. Mechanism should be provided to avoid the propagation of internal prefixes of a VPN to its underlying network(s). 3.2.4. Extendibility A VPN mechanism should allow easy extension of the VPNs while still maintain the same level of privacy and security. 3.2.4.1. Extend to multiple provider's domains Extending a VPN to different provider's domains requires that the VPN mechanism assuming no uniform technology of the underlying network infrastructure. The only common technology can be assumed is IP in the underlying networks Yu, et al. [Page 6] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 3.2.4.2. Extend to Remote Dialup Users Remote access or dialup is an essential part of enterprise networks which usually adopting VPN solution for its Intranet. Therefore, a VPN implementation mechanism should support this functionality. 3.2.4.3. Interconnection VPNs There are many reasons why VPNs would need to be interconnected. For example, the merge of two corporate would create a need for such interconnection. A VPN implementation mechanism should make such interconnection possible. It is also desirable that same mechanism can be used for both inter-VPN and intra-VPN connection to avoid introducing complexity in operation and management. 3.2.5. Redundancy A VPN implementation mechanism should avoid relying on a central system for operations such as routing or management. Such system will introduce single point of failure, performance bottleneck and/or capacity bottleneck such as routing table capacity. 3.2.6. Operation Transparency Even though a VPN utilizes the underlying network for its communication, logically, the two are separate networks. A VPN implementation mechanism should help minimize the dependence and interference between the two networks to optimize the performance. Due to this reason, operation transparency of VPN from underlying network is extremely desirable. Maximize the independency of a VPN from its underlying network as described in section 3.2.3 is a key to achieve operation transparency. Operation transparency includes the following aspects: o Technology change to either network will make the least impact on the other o VPN network administrators should be able to configure or reconfigure the VPN without involving the administrators of the underlying network A category of VPN service model involves the administrator of the underlying network also operate the VPN to which it provides service due to service outsourcing arrangement. The above requirement may be adjusted accordingly. 3.3. Manageability Yu, et al. [Page 7] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 The management of a VPN typically involves membership, policy and security management. Reducing management complexity and manual configuration will reduce network outages due to misconfiguration and mismanagement. It is, therefore, desirable that VPN implementation mechanisms facilitate the manageability of VPNs. We will exam the management issues in the following aspects: 3.3.1. Membership Management The key of building a VPN is to identify and disseminate members belong to the VPN so connections can be established among the members to form a virtual private communication network or reconstruction of a VPN after its establishment. This information will have to be configured or distributed to the VPN routers. It can be achieved by manually configured all related information on the routers, install all such information in a central repository and distributed to VPN routers in a automated fashion, or propagate such information via piggybacking in routing protocols as discussed in [2]. Regardless of what method chosen, it should keep manual management of such information to the minimum, both in terms of establishment of VPN or maintenance of VPN in terms of adding or deleting sites in a VPN. 3.3.2. Access Management Due to the private nature of VPNs in general, access of the networks needs to be restricted and controlled. Access policies need to be configured to the routers and in addition, need to be properly maintained. Again, it's desirable that a VPN implementation requires minimum manual management of policy information. 3.3.3. Key Management For those VPNs with strong requirement of security and privacy, security keys are used for the purpose of authentication and encryption. Therefore, key management becomes an essential part of the VPN management. Key management involves creation, exchange and maintenance of keys. VPN implementation should select mechanisms which meets the security requirement but also manageable. 3.3.4. Management Boundaries Being able to identify problem quickly will no doubt enhance the availability of a network. It can be critical to enterprises rely on VPN for mission critical tasks. It is desirable that administrative and management boundaries can be clearly defined. Building a VPN as much independent as possible to its underlying network(s) as Yu, et al. [Page 8] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 described in section 3.2.3. Will help achieving the goal. 3.4. Scalability A VPN can grow as large as to include hundreds of sites. Thus VPN implementation mechanism should be able to scalable to build such a large VPN network. This requires that the complexity of setup, operation and management associated with a VPN does not increase dramatically with the size of the VPN (e.g. number of VPN sites) built with the mechanism. 3.4.1. Architecture Scalability Different architecture would have immense impact on the scalability of the VPN networks. For example, provider network based VPN architecture scales much better than CPE based VPN architecture due to the introduction of hierarchy thus removing the complexity of configuration and management on large number of routers involved as pointed out in section 3.2.2. in this document. Allowing same set of devices (such as provider's Edge routers) to support multiple VPNs is a scalable means for a VPN Service Provider to provider large number of VPNs in its network. When evaluating a VPN implementation mechanism, one need to consider if the mechanism allows the implementation of VPN with architectures that are more scalable. 3.4.2. Management Scalability The key to a scalable VPN management is to minimize the manual tasks in terms of configuration and maintenance of membership information and policy information. A VPN implementation mechanism should provide means of reducing manual tasks to minimum. 3.4.3. Routing Scalability A large VPN network would have the same routing complexity than that of a regular non-virtual network. Therefore, routing scalability issues facing non-virtual large networks as described in [5] also applies to routing in large VPN networks. A VPN implementation mechanism should not be an obstacle for implementing scalable routing in the VPNs. It is desirable that VPN prefixes do not propagate to the public network infrastructure, not only for security reason but also for scalable routing table management reason. A VPN implementation mechanism must not rely on public network routing system to carry Yu, et al. [Page 9] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 private VPN prefixes. 3.5. Feature Support A VPN mechanism should not restrict VPN from supporting features desired by an enterprise network. Examples of such features including: QoS, Multicast and Multi-protocol support. 4. Conclusion Aside from privacy and security, independence of a VPN from its underlying network infrastructure is also a key criterion for evaluating VPN mechanisms. In fact, when such independency is achieved, it will improve the manageability of the VPN, which is also a very important criterion. 5. Security Considerations Security is an essential part of VPN implementation mechanisms. Sections in this document are devoted to discussion of security considerations. 6. References [1] Rosen, et al, "BGP/MPLS VPNs", May 2000, Work in progress [2] Gleeson, et al, "A Framework for IP Based Virtual Private Networks", February 2000, RFC2764 [3] H. Ould-Brahim, B. Gleeson, "Network based IP VPN Architecture Using Virtual Routers", March 2000, Work in progress [4] K. Muthukrishnan, A., Malis, "A Core MPLS IP VPN Architecture", May 2000, Work in progress [5] J. Yu. "Scalable Routing Design Principles", Mar 2000, Work in progress 7. Author Information Jieyun (Jessica) Yu CoSine Communications jyy@cosinecom.com Lianghwa Jou CoSine Communications ljou@cosinecom.com Yu, et al. [Page 10] Internet Draft draft-yu-vpn-criteria-00.txt July, 2000 Abbie Matthews CoSine Communications amatthews@cosinecom.com Vijay Srinivasan CoSine Communications vsrinivasan@cosinecom.com Yu, et al. [Page 11]