idnits 2.17.1 draft-berkowitz-vpn-tax-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 350 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 88 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1999) is 9020 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Rosen' is mentioned on line 41, but not defined == Missing Reference: 'Fox' is mentioned on line 83, but not defined == Unused Reference: 'RFC1001' is defined on line 320, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-gleeson-vpn-framework-00 ** Downref: Normative reference to an Informational draft: draft-gleeson-vpn-framework (ref. 'Gleeson') -- Possible downref: Normative reference to a draft: ref. 'Muthukrishnan' ** Downref: Normative reference to an Historic RFC: RFC 1234 ** Downref: Normative reference to an Informational RFC: RFC 1702 Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Howard C. Berkowitz 2 INTERNET-DRAFT Netarchitecture 3 Mentoring 4 5 Expires August 1999 7 Requirements Taxonomy for Virtual Private Networks 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress''. 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 27 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 29 Abstract 31 Proprietary definitions of virtual private networks proliferate in 32 the marketplace, to the confusion of end users. This memorandum 33 proposes a taxonomy which can describe a variety of VPN models. 34 It does not recommend any specific model, but suggests a consistent 35 way of describing specific VPNs. This document differs from some 36 other working papers that go more deeply into the VPN mechanisms. 37 In contrast, this document is focused on user requirments. 39 1. Introduction 41 Previous working papers [Gleeson, Muthukrishnan, Rosen] have dealt 42 with fairly specific models where specific underlying technologies are 43 considered at length. This document takes a different approach, trying 44 to focus on requirements rather than technology. It may very well be 45 appropriate to merge several of these proposals. 47 Any VPN will have a minimal set of core capabilities, which, alone, 48 are unlikely to satisfy any real-world user requirements. The taxonomy 49 here provides a systematic way for extending the core capabilities to 50 meet those requirements. It also provides a way of describing requirements 51 for the shared infrastructure over which the VPN runs. 53 A description of a specific VPN requirement will state the core capabilities 54 optional user services, and the administrative model. A response to this 55 requirement will state the infrastructure technologies and how the user 56 requirements will map to them. 58 The taxonomy consists of: 60 Core capabilities 61 Optional capabilities 62 Administrative model 63 Mapping of user services to different infrastructures 64 Infrastructures 66 For a VPN to work, it must be possible to map the user services to 67 corresponding capabilities in the infrastructure. Mechanisms for these 68 mappings are outside the scope of this taxonomy. A quality of service 69 user requirement, for example, could map to ATM QoS facilities, to RSVP 70 or differentiated services in an IP network, or to priorities in an 802.1p 71 LAN. 73 2. Core Capabilities 75 To define a VPN, it is necessary to be able to define an administrative 76 mechanism for designating membership in the VPN. A given host may belong 77 to one or more VPNs, as well as the global Internet. 79 If there are security requirements for the VPN, the owning enterprise 80 should define a security policy that states the allowable connectivity 81 over multiple VPNs and public networks. 83 The set of members of a VPN will have an identifier [Fox], although that 84 identifier might be null. 86 3. Optional Capabilities 88 VPNs of practical use will have one or more optional capabilities in 89 addition to the core set. Not all VPNs will need every capability. 91 3.1 Quality of Service 93 The VPN may provide quality of service support. It either may accept 94 QoS requests from end users signaled with RSVP, IP precedence bits, etc., 95 or may internally assign quality of service requirements to be mapped 96 to the transmission infrastructure. For quality of service to be effective, 97 the infrastructure either must support explicit quality of service requests, 98 or there must be a high level of confidence that the infrastructure 99 consistently provides adequate QoS. Assumptions about QoS need to be 100 stated as part of any VPN design. 102 3.2 Security 104 User connectivity may be defined to include security using a variety 105 of security mechanisms, including IPsec, L2TP, etc. Security may be 106 requested on a discretionary basis by end user hosts, or the VPN may 107 enforce a mandatory security policy. Cryptographic protections may 108 be under the control of the enterprise, using host-to-host or host-to- 109 security gateway methods, or the infrastructure may be trusted to provide 110 encryption. The responsibilities for encryption must be specified as 111 part of the design of any practical VPN. 113 3.3 Addressing and load sharing 115 The VPN may provide address assignment, presumably with DHCP. It also 116 may provide network address translation (NAT), network address and port 117 translation (NAPT), and load-shared network address translation (LSNAT). 119 DNS services may be associated with the VPN, and operated by the enterprise 120 or the service provider. 122 While VPNs can appear as a single IP prefix (i.e., a single user domain), 123 single prefixes will not scale to large size. The provider may set up 124 multiple prefixes to serve user connectivity requirements. If there are 125 multiple prefixes, it needs to be specified if routing among them is 126 an enterprise or provider responsibility. 128 3.4 Frame Sequencing and MTU Support 130 There may be requirements to deliver frames or packets in sequence. 131 In addition, there may be a requirement to support, efficiently, larger 132 MTUs that the provider might normally handle. 134 3.5 Non-IP Protocol Support 136 While the emphasis of this taxonomy is on VPNs that support IP, the VPN may 137 provide mechanisms for encapsulating non-IP protocols for transmission over 138 an IP infrastructure. Techniques for doing so include NetBIOS over TCP 139 [RFC1001/1002], IPX over IP [RFC1234], GRE [RFC1702], etc. 141 3.6 Multicast Support 143 The IP VPN, as seen by end users, may support broadcast or multicast 144 addressing. 146 3.7 Availability 148 The enterprise may specify availability requirements for the infrastructure 149 and for VPN gateway services. If redundancy of links or components is 150 needed to provide the desired level of redundancy, these redundant 151 components may either be visible to, or hidden from, the using enterprise. 153 3.8 Dynamic Provisioning 155 The enterprise may need to be able to signal to the provider that new 156 sites and/or users (especially dial users) have been added to the VPN. 157 While it should generally be transparent to the VPN if new users are 158 added to VPNs at existing sites, security requirements may make it necessary 159 to inform the VPN, securely, that a new user has been added or an old user 160 deleted. 162 4. Administrative Model 164 Several administrative issues apply in VPN deployment: whether the 165 enterprise 166 is responsible for any customer premises equipment (CPE) that intelligently 167 interoperates with components of the shared infrastructure, whether a 168 service 169 provider is contracted to operate the WAN infrastructure, and how any VPN 170 client software in user hosts is managed and operated. 172 A service provider may place service-provider operated equipment at a 173 customer site, and present a LAN or serial interface to the customer. 174 Anything beyond the provider device is contractually a provider 175 responsibility, but it cannot be directly controlled by the customer. 177 There are two basic models of the administration and management of VPNs, 178 although subcategories are perfectly viable. In the first category, the 179 end user organization designs and operates the VPN, often with end user 180 access through the public dial network. In the second, a service provider 181 has contractual responsibility for designing and operating the VPN in 182 response to specified user requirements. 184 Another aspect of the model is whether clients are aware of the VPN, and 185 if provider access components are aware of it. In principle, a client could 186 attach to a generic ISP, establish an encrypted tunnel to a destination 187 host, and operate transparently to the ISP. The VPN provider may be the 188 ISP. In such cases, the VPN provider responsibility is to provided logins 189 and connectivity. The login might specify a class of service to be used 190 in the provider network. 192 In an alternative model, the clients do not contain encryption software. 193 Clients connect natively to the provider's access device through an 194 administratively trusted link such as the dial telephone network. The 195 client authenticates with the access device, and the access device(s) 196 provide cryptographic services. 198 Yet another model is traffic driven. Routers at customer sites sense 199 when end user devices wish to send across the VPN, and either route 200 them to predefined tunnels over dedicated infrastructure, or create 201 appropriate dial calls to carry the traffic, encrypting if necessary. 203 5. Mapping to the Infrastructure 205 The specific means by which end user views of the VPN are mapped onto the 206 shared infrastructure generally involves tunneling, virtual circuit setup, 207 or the establishment of a set of labels. 209 When tunnels are used, they may provide no security (GRE), authentication 210 (L2TP, L2F, and PPTP), or a wide range of security services (IPsec). 211 Security services may also be provided by hosts, and a less secure tunnel 212 mechanism used to carry host-encrypted data. 214 Alternatively, the mapping of IP connectiviy may be to virtual circuits 215 using Frame Relay or ATM, or to real circuits with ISDN or analog dial. 217 When the VPN seen by the user appears to be multicast-capable, but the 218 infrastructure is connection-oriented, provisions need to be made for 219 supporting multicast. Techniques here might involve point-to-multipoint 220 circuits, or the use of multicast replication servers. 222 Details of these mappings will be in other, infrastructure-protocol-specific 223 documents. 225 Tunnel technologies need to be coordinated between the enterprise(s) and the 226 provider(s). There may be single tunnels between sites, or possibly 227 multiple 228 tunnels for loadsharing and increased availability (e.g., with multilink 229 PPP over IP). 231 6. Infrastructure Capabilities 233 When different kinds of infrastructure are proposed, the main requiremment 234 if for the infrastructure provider to take responsibility that all relevant 235 user capabilities have matching capabilities in the infrastructure. The 236 actual mappings are technology-specific and outside the scope of this 237 document. 239 This section does not attempt to define the specific infrastructure 240 technologies that can be used for VPNs. Rather, it examines the 241 capabilities that may be needed if a user capability is to be mapped 242 successfully into one or more infrastructures. 244 Specific VPNs may well be provisioned over one or more infrastructure 245 types. In such cases, the designer needs to ensure the user capabilities 246 map into each of the infrastructures. 248 6.1 Quality of Service 250 When the user or the enterprise can request explicit QoS, either the 251 infrastructure must be able to understand the explicit requests, or it 252 must consistently supply a QoS that meets the most stringent user 253 requirement. 255 6.2 Security 257 Users may be responsible for cryptographic security, transparently to 258 the provider. Alternatively, the VPN provider may offer encryption. 260 If the user operates firewalls, VPN tunnels typically will terminate 261 at the firewall. If the firewall is operated by the service provider, 262 or if the user has stringent security requirements requiring end-to-end 263 encryption, there may be compatibility issues of authenticated firewall 264 traversal. 266 6.3 Addressing 268 Providers can use registered or RFC1918 addresses internally in their 269 networks. These may or may not be visible to the enterprise. When they 270 are not, there should be a well-defined operational procedure that allows 271 the user to request traceroutes through IP infrastructures. 273 When the provider uses VPN identifiers to distinguish between routing 274 tables for different VPNs, the same addresses, especially from the 275 private address space, may be reused. Provider engineers should take 276 care that 278 6.4 Non-IP Protocol Support 280 Comnmonly, the enterprise will provide the tunneling necessary to carry 281 non-IP protocols over the enterprise. When the VPN is offered as a service, 282 however, the provider may offer appropriate encapsulation services. If 283 the infrastructure is layer 2 and supports a protocol type field, it may 284 be appropriate for the provider to encapsulate non-IP traffic with explicit 285 protocol identification. 287 6.5 Availability 289 When a specific availability requirement is defined for the enterprise VPN, 290 it is a provider responsibility to ensure the infrastructure has the 291 component reliability, diversity, etc., to meet these needs. It can be 292 useful to distinguish between availability in the access part of a VPN, 293 such as modem pools, and the backbone which carries the tunnels over the 294 long-haul shared infrastructure. 296 6.6 Interprovider Connectivity 298 It may be necessary to provision the VPN infrastructure through multiple 299 service providers. In such cases, the providers will need inter-provider 300 provisioning and VPN identification. 302 Much as a BGP confederation presents a single AS number to the outside 303 but contains multiple internal ASNs, a multiprovider VPN identifier may 304 map to a set of publicly visible ASNs. While BGP may be 305 used to convey VPN reachability information among providers, the actual 306 destinations may be prefixed with VPN IDs, and carried using the BGP-4 307 Multiprotocol Extensions. When VPN IDs are used in this manner, the 308 routes carried need not be visible on the global Internet, but simply 309 used to exchange information between ISPs with bilateral agreements. 311 References 313 [Gleeson] Gleeson, Heinanen, Lin, Armitage, "A Framework for IP Based 314 Virtual 315 Private Networks", draft-gleeson-vpn-framework-00.txt. 317 [Muthukrishnan] Muthukrishnan, Malis, "Core IP VPN Architecture", 318 draft-muthukrishnan-corevpn-arch-00.txt. 320 [RFC1001] 1001 Protocol standard for a NetBIOS service on a TCP/UDP 321 transport: 322 Concepts and methods. NetBIOS Working Group. Defense Advanced 323 Research Projects Agency, Internet Activities Board, End-to-End 324 Services Task Force. Mar-01-1987. 326 [RFC1234] Tunneling IPX traffic through IP networks. D. Provan. 327 Jun-01-1991 329 [RFC1702] Hanks, S., et al "Generic Routing Encapsulation over Ipv4 330 Networks", RFC 1702 332 Author Information 334 Howard C. Berkowitz 335 Netarchitecture Mentoring 336 PO Box 6897 337 Arlington VA 22206 338 phone: +1-703-998-5819 339 email: hcb@clark.net