idnits 2.17.1 draft-yu-vpn-criteria-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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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. ** The abstract seems to contain references ([1,2,3,4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2764 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jieyun (Jessica) Yu 2 INTERNET DRAFT Lianghwa Jou 3 Expires in January, 2001 Abbie Matthews 4 Vijay Srinivasan 5 CoSine Communications 6 July, 2000 8 Criteria for Evaluating VPN Implementation Mechanisms 9 draft-yu-vpn-criteria-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 27 Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 A variety of mechanisms for implementing Virtual Private Network 33 (VPN) utilizing public IP network infrastructure have been proposed 34 in [1,2,3,4] and more may be emerging. This document attempts to 35 identify a set of criteria for evaluating such mechanisms. The 36 criteria could be used by IETF for evaluating a VPN proposal before 37 advancing it to standard track or by VPN Service Providers or 38 enterprise network administrators for choosing which mechanism to use 39 in order to implement their desired VPN networks. The mechanisms this 40 criteria addresses are exclusively for implementing IP based VPNs, as 41 oppose to non-IP based ones, such as Frame Relay based VPNs, etc. 43 1. Introduction 44 A Virtual Private Network (VPN), in general, can be described as an 45 emulated private communication infrastructure utilizing shared 46 communication facilities. It is usually built by utilizing public 47 Internet infrastructure or ISP backbone network. VPN is a cost- 48 effective alternative for enterprises conducting internal private 49 communications involving geographically diverse sites. 51 A variety of mechanisms for implementing VPN utilizing public IP 52 network infrastructure have been proposed [1,2,3,4] and more may be 53 emerging. This document attempts to identify a set of criteria for 54 evaluating such mechanisms. The criteria could be used by IETF for 55 evaluating a VPN proposal before advancing it to standard track or by 56 VPN Service Providers or enterprise network administrators for 57 choosing which mechanism to use in order to implement their desired 58 VPN networks. 60 It is worthy noting that the mechanisms this set of criteria 61 addresses are exclusively for implementing IP based VPNs as oppose to 62 non-IP based ones, such as Frame Relay or ATM based VPNs. 64 2. Basic Criteria 66 The very basic criteria of VPN are virtual and private. By Virtual, 67 we mean, the network has no correspondent physical network, rather is 68 an emulated infrastructure utilizing underlying public network 69 infrastructure. By Private, we mean, access to such network is 70 restricted only to a defined set of entities and the data transmitted 71 across the VPN should not be read by outside of the network. 73 In order to be characterized as a VPN implementation mechanism, a 74 mechanism must provide a means of implementing VPNs with these two 75 basic characteristics. 77 3. Other Criteria for Evaluating VPN Implementation Mechanisms 79 The basic components of a VPN implementation mechanism should include 80 mechanisms for a) membership identification, verification and 81 dissemination; b) Intra-VPN routing and routing interaction between 82 VPN and its underlying network(s); and c) forwarding. With these 83 basic components in mind, a VPN implementation mechanism can be 84 evaluated, in general, with the following aspects: 86 o Security 87 o Architecture 88 o Manageability 89 o Scalability 90 o Feature support 92 It is worthy noting that with security criteria, different degree of 93 requirement may vary with respect to different VPNs. For example, 94 while it is an absolute requirement for some VPNs to encrypt data 95 transmitted over the VPN, it may not be top consideration for others. 96 Therefore, specific requirement of a particular VPN should be taken 97 into consideration when such evaluation is taking place. 99 3.1. Security 101 A VPN implementation mechanism should provide means for data security 102 and network security. 104 3.1.1. Data Security 106 Data security includes data integrity, data confidentiality and data 107 origin authentication. 109 o Data integrity 111 One of the security concerns is that data could be altered or 112 tampered while transmitted across the Internet. A VPN mechanism needs 113 to provide mechanisms to ensure the integrity of data exchanged 114 within the VPN. 116 o Data confidentiality 118 A VPN mechanism should provide means for ensuring that no 119 unauthorized party reading or copy the VPN private data while 120 transmitting across the underlying public network. An example of such 121 mechanism is data encryption. 123 o Data origin authentication 125 A VPN mechanism should provide ways for authenticate the origin of 126 data to ensure that the source of the data is what it claims to be. 128 3.1.2. VPN Network Security 130 VPN network security provides the ability to guarantee that only 131 approved recipients receive the VPN's routing information and data. 133 o Site authorization and authentication 135 A VPN will suffer from undesirable security consequences when an 136 unauthorized site becomes part of the VPN network. To ensure a secure 137 VPN network, a VPN implementation mechanism should provide means of 138 establishing connections only with the authorized entities (sites) in 139 the initial VPN construction process as well as in the 140 reconfiguration process. To achieve the goal, a form of site 141 authentication prior to establishment of the connection is required 142 and should be provided. 144 o Access control 146 Access control involves policy of who can access the VPN network. 147 Access control mechanism should be provided by a VPN implementation 148 mechanism to restrict access thus to protect the privacy of the VPN 149 network. 151 o Routing Security 153 The goal of achieving routing security in a VPN is to prevent routers 154 of a VPN from interaction with unauthorized entities, to prevent 155 routes to VPN destinations from leaking to undesired entities, and to 156 avoid introducing undesired routing information to taint the VPN 157 routing information base. 159 o VPN Isolation 161 Certain VPN implementation mechanism provides capability of 162 supporting multiple VPNs utilizing the same set of devices (e.g. Edge 163 routers of a provider network.) Mechanisms, such as separate 164 forwarding table for each VPN on the device, must be provided to 165 prevent unintended traffic from one VPN entering another to ensure 166 privacy and security of the VPNs. 168 3.2. Architecture 170 3.2.1. Flexible Topology 172 A set of virtual links between sites belong to a VPN constitutes the 173 topology of the VPN network. A virtual link can be realized via the 174 construction of a tunnel such as IPsec VPN mechanism [2] or via 175 establishing direct routes as with BGP4/MPLS VPN mechanism [1]. 177 Based on its requirement, an enterprise may desire the topology of 178 its VPN network as full-mesh, partial-mesh or hub-and-spoken. A VPN 179 implementation mechanism should be flexible to allow constructing VPN 180 topology based on the requirement accordingly. 182 3.2.2. Hierarchy 184 Different architecture may result in different scalability of its 185 correspondent VPN. For example, provider network-based VPN 186 architecture allows a provider edge router to connect many customer 187 premises equipment (CPE) routers in a region. The topology mesh will 188 be built among the Provider Edge routers. This architecture scales 189 better than CPE based VPN where the tunnel meshes are formed among 190 the CPE routers which has a lot more in numbers for large VPNs. In 191 addition, by introducing this hierarchy, configuration and management 192 complexity will be moved to a smaller set of Provider Edge routers 193 rather than large amount of CPE devices. 195 Therefore, it is desirable for a VPN implementation mechanism to 196 provide means for building VPN with hierarchy. 198 3.2.3. Independency 200 Although a VPN is a virtual infrastructure built on top of public 201 network infrastructure, maintaining as much independence from its 202 underlying network infrastructure as possible yields many advantages. 203 The advantages include fault isolation and operation transparency, 204 which would improve the stability of both VPN network as well as the 205 underlying network(s). 207 3.2.3.1. Backbone Technology Independence 209 An enterprise VPN network may span across multiple ISP network 210 domains. Two VPNs with different ISP network as underlying 211 infrastructure may need to merge into one VPN due to event such as 212 corporate merge. To facilitate the interconnection, it is desirable 213 that a VPN implementation mechanism be independent of underlying 214 network or backbone technology. It should avoid assuming or requiring 215 ISPs running certain protocols other than IP protocol. 217 For those VPNs that only cross one ISP network (which is the most 218 cases in today's implementation), this criterion is of less concern. 220 3.2.3.2. Addressing Independence 222 A VPN mechanism should not require the binding of IP address space of 223 the VPN to its underlying IP network. In another word, the IP 224 addresses assigned within a VPN network should be independent of that 225 assigned in its underlying IP network/backbone. 227 By assigning separate IP address space from its underlying network, a 228 VPN administrator is able to manage IP address within the VPN 229 independently since he/she is able to add, change and remove IP 230 addresses without coordinating with the administrator of the 231 underlying IP network. 233 By not tying VPN's IP address space with a particular underlying 234 network, the VPN can migrate to other underlying IP network without 235 changing the IP address, making such migration easier. 237 By using independent IP address space from its underlying network, a 238 VPN is able to use private IP address space. Using private IP address 239 space helps conserving scarce IPv4 address space. 241 It also makes it feasible for the use of overlapping IP address space 242 for VPNs that do not have common sites. This again will make the use 243 of private IP address space feasible. 245 3.2.3.3. Routing Independence 247 Overall, routing of a VPN can be viewed as composed of two parts: a) 248 obtaining routing knowledge to reach the private destinations 249 (prefixes reachable within the VPN.) and b) obtaining routing 250 information to VPN sites reachable via the underlying public network. 251 While for b), VPN routers have to participant the routing of the 252 underlying network, for a) they do not have to. That is, routing 253 technology used for reachability within a VPN can be completely 254 independent from that of the underlying network. 256 Having an independent routing system will enhance VPN network 257 security and minimize unnecessary outages due to routing instability 258 in the underlying network and vice versa. Routing associated outages 259 or instability in the VPN layer, caused by for example misbehaving 260 routing software or mis-configurations, will not impact the routing 261 and/or the stability in its underlying network. In addition, VPN 262 prefixes will not need to be advertised to the underlying public 263 network's routing table, which enhances the security of the VPN. Not 264 leaking VPN prefixes in the underlying network also reduces routes in 265 the underlying network, hence improving routing scalability of the 266 underlying provider network. 268 A VPN implementation mechanism should allow as much independent 269 routing of VPN from its underlying network as possible. Mechanism 270 should be provided to avoid the propagation of internal prefixes of a 271 VPN to its underlying network(s). 273 3.2.4. Extendibility 275 A VPN mechanism should allow easy extension of the VPNs while still 276 maintain the same level of privacy and security. 278 3.2.4.1. Extend to multiple provider's domains 280 Extending a VPN to different provider's domains requires that the VPN 281 mechanism assuming no uniform technology of the underlying network 282 infrastructure. The only common technology can be assumed is IP in 283 the underlying networks 285 3.2.4.2. Extend to Remote Dialup Users 287 Remote access or dialup is an essential part of enterprise networks 288 which usually adopting VPN solution for its Intranet. Therefore, a 289 VPN implementation mechanism should support this functionality. 291 3.2.4.3. Interconnection VPNs 293 There are many reasons why VPNs would need to be interconnected. For 294 example, the merge of two corporate would create a need for such 295 interconnection. A VPN implementation mechanism should make such 296 interconnection possible. It is also desirable that same mechanism 297 can be used for both inter-VPN and intra-VPN connection to avoid 298 introducing complexity in operation and management. 300 3.2.5. Redundancy 302 A VPN implementation mechanism should avoid relying on a central 303 system for operations such as routing or management. Such system will 304 introduce single point of failure, performance bottleneck and/or 305 capacity bottleneck such as routing table capacity. 307 3.2.6. Operation Transparency 309 Even though a VPN utilizes the underlying network for its 310 communication, logically, the two are separate networks. A VPN 311 implementation mechanism should help minimize the dependence and 312 interference between the two networks to optimize the performance. 313 Due to this reason, operation transparency of VPN from underlying 314 network is extremely desirable. Maximize the independency of a VPN 315 from its underlying network as described in section 3.2.3 is a key to 316 achieve operation transparency. 318 Operation transparency includes the following aspects: 320 o Technology change to either network will make the least impact on 321 the other 323 o VPN network administrators should be able to configure or 324 reconfigure the VPN without involving the administrators of the 325 underlying network 327 A category of VPN service model involves the administrator of the 328 underlying network also operate the VPN to which it provides service 329 due to service outsourcing arrangement. The above requirement may be 330 adjusted accordingly. 332 3.3. Manageability 333 The management of a VPN typically involves membership, policy and 334 security management. Reducing management complexity and manual 335 configuration will reduce network outages due to misconfiguration and 336 mismanagement. It is, therefore, desirable that VPN implementation 337 mechanisms facilitate the manageability of VPNs. We will exam the 338 management issues in the following aspects: 340 3.3.1. Membership Management 342 The key of building a VPN is to identify and disseminate members 343 belong to the VPN so connections can be established among the members 344 to form a virtual private communication network or reconstruction of 345 a VPN after its establishment. This information will have to be 346 configured or distributed to the VPN routers. It can be achieved by 347 manually configured all related information on the routers, install 348 all such information in a central repository and distributed to VPN 349 routers in a automated fashion, or propagate such information via 350 piggybacking in routing protocols as discussed in [2]. 352 Regardless of what method chosen, it should keep manual management of 353 such information to the minimum, both in terms of establishment of 354 VPN or maintenance of VPN in terms of adding or deleting sites in a 355 VPN. 357 3.3.2. Access Management 359 Due to the private nature of VPNs in general, access of the networks 360 needs to be restricted and controlled. Access policies need to be 361 configured to the routers and in addition, need to be properly 362 maintained. Again, it's desirable that a VPN implementation requires 363 minimum manual management of policy information. 365 3.3.3. Key Management 367 For those VPNs with strong requirement of security and privacy, 368 security keys are used for the purpose of authentication and 369 encryption. Therefore, key management becomes an essential part of 370 the VPN management. Key management involves creation, exchange and 371 maintenance of keys. VPN implementation should select mechanisms 372 which meets the security requirement but also manageable. 374 3.3.4. Management Boundaries 376 Being able to identify problem quickly will no doubt enhance the 377 availability of a network. It can be critical to enterprises rely on 378 VPN for mission critical tasks. It is desirable that administrative 379 and management boundaries can be clearly defined. Building a VPN as 380 much independent as possible to its underlying network(s) as 381 described in section 3.2.3. Will help achieving the goal. 383 3.4. Scalability 385 A VPN can grow as large as to include hundreds of sites. Thus VPN 386 implementation mechanism should be able to scalable to build such a 387 large VPN network. This requires that the complexity of setup, 388 operation and management associated with a VPN does not increase 389 dramatically with the size of the VPN (e.g. number of VPN sites) 390 built with the mechanism. 392 3.4.1. Architecture Scalability 394 Different architecture would have immense impact on the scalability 395 of the VPN networks. For example, provider network based VPN 396 architecture scales much better than CPE based VPN architecture due 397 to the introduction of hierarchy thus removing the complexity of 398 configuration and management on large number of routers involved as 399 pointed out in section 3.2.2. in this document. 401 Allowing same set of devices (such as provider's Edge routers) to 402 support multiple VPNs is a scalable means for a VPN Service Provider 403 to provider large number of VPNs in its network. 405 When evaluating a VPN implementation mechanism, one need to consider 406 if the mechanism allows the implementation of VPN with architectures 407 that are more scalable. 409 3.4.2. Management Scalability 411 The key to a scalable VPN management is to minimize the manual tasks 412 in terms of configuration and maintenance of membership information 413 and policy information. A VPN implementation mechanism should provide 414 means of reducing manual tasks to minimum. 416 3.4.3. Routing Scalability 418 A large VPN network would have the same routing complexity than that 419 of a regular non-virtual network. Therefore, routing scalability 420 issues facing non-virtual large networks as described in [5] also 421 applies to routing in large VPN networks. A VPN implementation 422 mechanism should not be an obstacle for implementing scalable routing 423 in the VPNs. 425 It is desirable that VPN prefixes do not propagate to the public 426 network infrastructure, not only for security reason but also for 427 scalable routing table management reason. A VPN implementation 428 mechanism must not rely on public network routing system to carry 429 private VPN prefixes. 431 3.5. Feature Support 433 A VPN mechanism should not restrict VPN from supporting features 434 desired by an enterprise network. Examples of such features 435 including: QoS, Multicast and Multi-protocol support. 437 4. Conclusion 439 Aside from privacy and security, independence of a VPN from its 440 underlying network infrastructure is also a key criterion for 441 evaluating VPN mechanisms. In fact, when such independency is 442 achieved, it will improve the manageability of the VPN, which is also 443 a very important criterion. 445 5. Security Considerations 447 Security is an essential part of VPN implementation mechanisms. 448 Sections in this document are devoted to discussion of security 449 considerations. 451 6. References 453 [1] Rosen, et al, "BGP/MPLS VPNs", May 2000, Work in progress 455 [2] Gleeson, et al, "A Framework for IP Based Virtual Private 456 Networks", February 2000, RFC2764 458 [3] H. Ould-Brahim, B. Gleeson, "Network based IP VPN Architecture 459 Using Virtual Routers", March 2000, Work in progress 461 [4] K. Muthukrishnan, A., Malis, "A Core MPLS IP VPN Architecture", 462 May 2000, Work in progress 464 [5] J. Yu. "Scalable Routing Design Principles", Mar 2000, Work in 465 progress 467 7. Author Information 469 Jieyun (Jessica) Yu 470 CoSine Communications 471 jyy@cosinecom.com 473 Lianghwa Jou 474 CoSine Communications 475 ljou@cosinecom.com 476 Abbie Matthews 477 CoSine Communications 478 amatthews@cosinecom.com 480 Vijay Srinivasan 481 CoSine Communications 482 vsrinivasan@cosinecom.com