Internet Engineering Task Force Howard C. Berkowitz INTERNET-DRAFT Netarchitecture Mentoring <draft-berkowitz-vpn-tax-00.txt> Expires August 1999 Requirements Taxonomy for Virtual Private Networks 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''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract Proprietary definitions of virtual private networks proliferate in the marketplace, to the confusion of end users. This memorandum proposes a taxonomy which can describe a variety of VPN models. It does not recommend any specific model, but suggests a consistent way of describing specific VPNs. This document differs from some other working papers that go more deeply into the VPN mechanisms. In contrast, this document is focused on user requirments. 1. Introduction Previous working papers [Gleeson, Muthukrishnan, Rosen] have dealt with fairly specific models where specific underlying technologies are considered at length. This document takes a different approach, trying to focus on requirements rather than technology. It may very well be appropriate to merge several of these proposals. Any VPN will have a minimal set of core capabilities, which, alone, are unlikely to satisfy any real-world user requirements. The taxonomy here provides a systematic way for extending the core capabilities to meet those requirements. It also provides a way of describing requirements for the shared infrastructure over which the VPN runs. A description of a specific VPN requirement will state the core capabilities optional user services, and the administrative model. A response to this requirement will state the infrastructure technologies and how the user requirements will map to them. The taxonomy consists of: Core capabilities Optional capabilities Administrative model Mapping of user services to different infrastructures Infrastructures For a VPN to work, it must be possible to map the user services to corresponding capabilities in the infrastructure. Mechanisms for these mappings are outside the scope of this taxonomy. A quality of service user requirement, for example, could map to ATM QoS facilities, to RSVP or differentiated services in an IP network, or to priorities in an 802.1p LAN. 2. Core Capabilities To define a VPN, it is necessary to be able to define an administrative mechanism for designating membership in the VPN. A given host may belong to one or more VPNs, as well as the global Internet. If there are security requirements for the VPN, the owning enterprise should define a security policy that states the allowable connectivity over multiple VPNs and public networks. The set of members of a VPN will have an identifier [Fox], although that identifier might be null. 3. Optional Capabilities VPNs of practical use will have one or more optional capabilities in addition to the core set. Not all VPNs will need every capability. 3.1 Quality of Service The VPN may provide quality of service support. It either may accept QoS requests from end users signaled with RSVP, IP precedence bits, etc., or may internally assign quality of service requirements to be mapped to the transmission infrastructure. For quality of service to be effective, the infrastructure either must support explicit quality of service requests, or there must be a high level of confidence that the infrastructure consistently provides adequate QoS. Assumptions about QoS need to be stated as part of any VPN design. 3.2 Security User connectivity may be defined to include security using a variety of security mechanisms, including IPsec, L2TP, etc. Security may be requested on a discretionary basis by end user hosts, or the VPN may enforce a mandatory security policy. Cryptographic protections may be under the control of the enterprise, using host-to-host or host-to- security gateway methods, or the infrastructure may be trusted to provide encryption. The responsibilities for encryption must be specified as part of the design of any practical VPN. 3.3 Addressing and load sharing The VPN may provide address assignment, presumably with DHCP. It also may provide network address translation (NAT), network address and port translation (NAPT), and load-shared network address translation (LSNAT). DNS services may be associated with the VPN, and operated by the enterprise or the service provider. While VPNs can appear as a single IP prefix (i.e., a single user domain), single prefixes will not scale to large size. The provider may set up multiple prefixes to serve user connectivity requirements. If there are multiple prefixes, it needs to be specified if routing among them is an enterprise or provider responsibility. 3.4 Frame Sequencing and MTU Support There may be requirements to deliver frames or packets in sequence. In addition, there may be a requirement to support, efficiently, larger MTUs that the provider might normally handle. 3.5 Non-IP Protocol Support While the emphasis of this taxonomy is on VPNs that support IP, the VPN may provide mechanisms for encapsulating non-IP protocols for transmission over an IP infrastructure. Techniques for doing so include NetBIOS over TCP [RFC1001/1002], IPX over IP [RFC1234], GRE [RFC1702], etc. 3.6 Multicast Support The IP VPN, as seen by end users, may support broadcast or multicast addressing. 3.7 Availability The enterprise may specify availability requirements for the infrastructure and for VPN gateway services. If redundancy of links or components is needed to provide the desired level of redundancy, these redundant components may either be visible to, or hidden from, the using enterprise. 3.8 Dynamic Provisioning The enterprise may need to be able to signal to the provider that new sites and/or users (especially dial users) have been added to the VPN. While it should generally be transparent to the VPN if new users are added to VPNs at existing sites, security requirements may make it necessary to inform the VPN, securely, that a new user has been added or an old user deleted. 4. Administrative Model Several administrative issues apply in VPN deployment: whether the enterprise is responsible for any customer premises equipment (CPE) that intelligently interoperates with components of the shared infrastructure, whether a service provider is contracted to operate the WAN infrastructure, and how any VPN client software in user hosts is managed and operated. A service provider may place service-provider operated equipment at a customer site, and present a LAN or serial interface to the customer. Anything beyond the provider device is contractually a provider responsibility, but it cannot be directly controlled by the customer. There are two basic models of the administration and management of VPNs, although subcategories are perfectly viable. In the first category, the end user organization designs and operates the VPN, often with end user access through the public dial network. In the second, a service provider has contractual responsibility for designing and operating the VPN in response to specified user requirements. Another aspect of the model is whether clients are aware of the VPN, and if provider access components are aware of it. In principle, a client could attach to a generic ISP, establish an encrypted tunnel to a destination host, and operate transparently to the ISP. The VPN provider may be the ISP. In such cases, the VPN provider responsibility is to provided logins and connectivity. The login might specify a class of service to be used in the provider network. In an alternative model, the clients do not contain encryption software. Clients connect natively to the provider's access device through an administratively trusted link such as the dial telephone network. The client authenticates with the access device, and the access device(s) provide cryptographic services. Yet another model is traffic driven. Routers at customer sites sense when end user devices wish to send across the VPN, and either route them to predefined tunnels over dedicated infrastructure, or create appropriate dial calls to carry the traffic, encrypting if necessary. 5. Mapping to the Infrastructure The specific means by which end user views of the VPN are mapped onto the shared infrastructure generally involves tunneling, virtual circuit setup, or the establishment of a set of labels. When tunnels are used, they may provide no security (GRE), authentication (L2TP, L2F, and PPTP), or a wide range of security services (IPsec). Security services may also be provided by hosts, and a less secure tunnel mechanism used to carry host-encrypted data. Alternatively, the mapping of IP connectiviy may be to virtual circuits using Frame Relay or ATM, or to real circuits with ISDN or analog dial. When the VPN seen by the user appears to be multicast-capable, but the infrastructure is connection-oriented, provisions need to be made for supporting multicast. Techniques here might involve point-to-multipoint circuits, or the use of multicast replication servers. Details of these mappings will be in other, infrastructure-protocol-specific documents. Tunnel technologies need to be coordinated between the enterprise(s) and the provider(s). There may be single tunnels between sites, or possibly multiple tunnels for loadsharing and increased availability (e.g., with multilink PPP over IP). 6. Infrastructure Capabilities When different kinds of infrastructure are proposed, the main requiremment if for the infrastructure provider to take responsibility that all relevant user capabilities have matching capabilities in the infrastructure. The actual mappings are technology-specific and outside the scope of this document. This section does not attempt to define the specific infrastructure technologies that can be used for VPNs. Rather, it examines the capabilities that may be needed if a user capability is to be mapped successfully into one or more infrastructures. Specific VPNs may well be provisioned over one or more infrastructure types. In such cases, the designer needs to ensure the user capabilities map into each of the infrastructures. 6.1 Quality of Service When the user or the enterprise can request explicit QoS, either the infrastructure must be able to understand the explicit requests, or it must consistently supply a QoS that meets the most stringent user requirement. 6.2 Security Users may be responsible for cryptographic security, transparently to the provider. Alternatively, the VPN provider may offer encryption. If the user operates firewalls, VPN tunnels typically will terminate at the firewall. If the firewall is operated by the service provider, or if the user has stringent security requirements requiring end-to-end encryption, there may be compatibility issues of authenticated firewall traversal. 6.3 Addressing Providers can use registered or RFC1918 addresses internally in their networks. These may or may not be visible to the enterprise. When they are not, there should be a well-defined operational procedure that allows the user to request traceroutes through IP infrastructures. When the provider uses VPN identifiers to distinguish between routing tables for different VPNs, the same addresses, especially from the private address space, may be reused. Provider engineers should take care that 6.4 Non-IP Protocol Support Comnmonly, the enterprise will provide the tunneling necessary to carry non-IP protocols over the enterprise. When the VPN is offered as a service, however, the provider may offer appropriate encapsulation services. If the infrastructure is layer 2 and supports a protocol type field, it may be appropriate for the provider to encapsulate non-IP traffic with explicit protocol identification. 6.5 Availability When a specific availability requirement is defined for the enterprise VPN, it is a provider responsibility to ensure the infrastructure has the component reliability, diversity, etc., to meet these needs. It can be useful to distinguish between availability in the access part of a VPN, such as modem pools, and the backbone which carries the tunnels over the long-haul shared infrastructure. 6.6 Interprovider Connectivity It may be necessary to provision the VPN infrastructure through multiple service providers. In such cases, the providers will need inter-provider provisioning and VPN identification. Much as a BGP confederation presents a single AS number to the outside but contains multiple internal ASNs, a multiprovider VPN identifier may map to a set of publicly visible ASNs. While BGP may be used to convey VPN reachability information among providers, the actual destinations may be prefixed with VPN IDs, and carried using the BGP-4 Multiprotocol Extensions. When VPN IDs are used in this manner, the routes carried need not be visible on the global Internet, but simply used to exchange information between ISPs with bilateral agreements. References [Gleeson] Gleeson, Heinanen, Lin, Armitage, "A Framework for IP Based Virtual Private Networks", draft-gleeson-vpn-framework-00.txt. [Muthukrishnan] Muthukrishnan, Malis, "Core IP VPN Architecture", draft-muthukrishnan-corevpn-arch-00.txt. [RFC1001] 1001 Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods. NetBIOS Working Group. Defense Advanced Research Projects Agency, Internet Activities Board, End-to-End Services Task Force. Mar-01-1987. [RFC1234] Tunneling IPX traffic through IP networks. D. Provan. Jun-01-1991 [RFC1702] Hanks, S., et al "Generic Routing Encapsulation over Ipv4 Networks", RFC 1702 Author Information Howard C. Berkowitz Netarchitecture Mentoring PO Box 6897 Arlington VA 22206 phone: +1-703-998-5819 email: hcb@clark.net