idnits 2.17.1 draft-ietf-l3vpn-security-framework-01.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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 2004) is 7375 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) -- Looks like a reference, but probably isn't: '1' on line 118 == Missing Reference: 'PPVPN-term' is mentioned on line 195, but not defined == Missing Reference: 'RFC1918' is mentioned on line 1365, but not defined == Unused Reference: 'GDOI' is defined on line 1883, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-beard-rpsec-routing-threats-00 -- Possible downref: Normative reference to a draft: ref. 'Beard' == Outdated reference: A later version (-08) exists of draft-ietf-msec-gdoi-07 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Downref: Normative reference to an Informational RFC: RFC 3174 == Outdated reference: A later version (-03) exists of draft-iab-secmech-02 ** Downref: Normative reference to an Informational draft: draft-iab-secmech (ref. 'SECMECH') -- Possible downref: Non-RFC (?) normative reference: ref. 'STD62' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD-8' -- Possible downref: Non-RFC (?) normative reference: ref. 'L3VPN-FW' -- Possible downref: Non-RFC (?) normative reference: ref. 'L3VPN-REQ' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Luyuan Fang (editor) 3 AT&T 5 Michael Behringer 6 Cisco 8 Ross Callon 9 Juniper 11 Fabio Chiussi 12 Lucent Technologies 14 Jeremy De Clercq 15 Alcatel 17 Mark Duffy 18 Quarry Technologies 20 L3VPN WG Paul Hitchen 21 BT 23 Internet Draft Paul Knight 24 Nortel Networks 25 Document: 26 draft-ietf-l3vpn-security-framework-01.txt 27 Expires: August 2004 February 2004 29 Security Framework for Provider Provisioned Virtual Private 30 Networks 32 Status of this Memo 34 This document is an Internet-Draft and is in full conformance with 35 all provisions of Section 10 of RFC2026. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other 44 documents at any time. It is inappropriate to use Internet-Drafts 45 as reference material or to cite them other than as "work in 46 progress." 48 Expires August 2004 1 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 Abstract 56 This draft addresses security aspects pertaining to Provider 57 Provisioned Virtual Private Networks (PPVPNs). We first describe 58 the security threats that are relevant in the context of PPVPNs, 59 and the defensive techniques that can be used to combat those 60 threats. We consider security issues deriving both from malicious 61 behavior of anyone and from negligent or incorrect behavior of the 62 providers. We also describe how these security attacks should be 63 detected and reported. We then discuss the possible user 64 requirements in terms of security in a PPVPN service. These user 65 requirements translate into corresponding requirements for the 66 providers. In addition, the provider may have additional 67 requirements to make its network infrastructure secure to a level 68 that can meet the PPVPN customer's expectations. Finally, we define 69 a template that may be used to analyze the security characteristics 70 of a specific PPVPN technology and describe them in a manner 71 consistent with this framework. 73 Table of Contents 75 Status of this Memo...............................................1 76 Abstract..........................................................2 77 Conventions used in this document.................................3 78 1. Introduction..................................................3 79 2. Terminology...................................................4 80 3. Security Reference Model......................................5 81 4. Security Threats..............................................7 82 4.1. Attacks on the Data Plane..................................8 83 4.2. Attacks on the Control Plane...............................9 84 5. Defensive Techniques for PPVPN Service Providers.............11 85 5.1. Cryptographic techniques..................................12 86 5.2. Authentication............................................19 87 5.3. Access Control techniques.................................21 88 5.4. Use of Isolated Infrastructure............................25 89 5.5. Use of Aggregated Infrastructure..........................25 90 5.6. Service Provider Quality Control Processes................26 91 5.7. Deployment of Testable PPVPN Service......................26 92 6. Monitoring, Detection, and Reporting of Security Attacks.....27 93 7. User Security Requirements...................................28 94 7.1. Isolation.................................................28 95 7.2. Protection................................................29 96 7.3. Confidentiality...........................................30 97 7.4. CE Authentication.........................................30 98 7.5. Integrity.................................................30 99 7.6. Anti-Replay...............................................30 100 8. Provider Security Requirements...............................30 101 8.1. Protection within the Core Network........................31 102 8.2. Protection on the User Access Link........................32 103 8.3. General Requirements for PPVPN Providers..................34 104 9. Security Evaluation of PPVPN Technologies....................34 105 9.1. Evaluating the Template...................................35 106 9.2. Template..................................................35 107 10. Security Considerations.....................................38 108 11. Acknowledgement.............................................38 109 References.......................................................39 110 Author's Addresses...............................................40 111 Full Copyright Statement.........................................41 113 Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 117 this document are to be interpreted as described in RFC-2119 [1]. 119 1. Introduction 121 Security is clearly an integral aspect of Provider Provisioned 122 Virtual Private Network (PPVPN) services. 124 The motivation and rationale for both Provider Provisioned Layer-2 125 VPN and Provider Provisioned Layer-3 VPN services are provided by 126 [L3VPN-FW] and [L3VPN-REQ]. 128 [L3VPN-FW] and [L3VPN-REQ] acknowledge that security is an 129 important and integral aspect of PPVPN services. Security is a 130 concern for both VPN customers and VPN Service Providers. Both will 131 benefit from a PPVPN Security Framework document that lists the 132 customer's and provider's security requirements related to PPVPN 133 services, and that can be used to assess how much a particular 134 technology protects against security threats and fulfills the 135 security requirements. 137 In this document, we first describe the security threats that are 138 relevant in the context of PPVPNs, and the defensive techniques 139 that can be used to combat those threats. We consider security 140 issues deriving both from malicious or incorrect behavior of users 141 and other parties and from negligent or incorrect behavior of the 142 providers. An important part of security defense is the detection 143 and report of a security attack, which is also addressed in this 144 document. 146 We then discuss the possible user and provider security 147 requirements in a PPVPN service. The users have expectations that 148 need to be met on the security characteristics of a VPN service. 149 These user requirements translate into corresponding requirements 150 for the providers in order to offer the service. Furthermore, 151 providers have security requirements to protect their network 152 infrastructure, and make it secure to the level required to provide 153 the PPVPN services, in addition to other services. 155 Finally, we define a template that may be used to describe the 156 security characteristics of a specific PPVPN technology in a manner 157 consistent with the security framework described in this document. 158 It is not within the scope of this document to analyze the security 159 properties of specific technologies; instead, our intention with 160 this template is to provide a common tool, in the form of a check 161 list, that may be used in other documents dedicated to an in-depth 162 security analysis of individual PPVPN technologies to describe 163 their security characteristics in a comprehensive and coherent way, 164 and to provide a common ground for comparison between different 165 technologies. 167 It is important to clarify that, in this document, we limit 168 ourselves to describing the users and providers' security 169 requirements that pertain to PPVPN services. It is not our 170 intention, however, to formulate precise "requirements" on each 171 specific technology in terms of defining the mechanisms and 172 techniques that must be implemented to satisfy such users and 173 providers' requirements. 175 This document is organized as follows. In Section 2, we 176 define the terminology used in the document. In section 3, we 177 define the security reference model for security in PPVPN networks, 178 which we use in the rest of the document. In Section 4, we describe 179 the security threats that are specific of PPVPNs. In Section 5, we 180 review defense techniques that may be used against those threats. 181 In Section 6, we describe how attacks may be detected and reported. 182 In Section 7, we discuss the user security requirements that apply 183 to PPVPN services. In Section 8, we describe additional security 184 requirements that the provider may have in order to guarantee the 185 security of the network infrastructure to provide PPVPN services. 186 In Section 9, we provide a template that may be used to describe 187 the security characteristics of specific PPVPN technologies. 188 Finally, in Section 10, we discuss security considerations. 190 2. Terminology 191 This document uses PPVPN-specific terminology. Definitions and 192 details about PPVPN-specific terminology can be found in [PPVPN- 193 term] and [L3VPN-FW]. The most important definitions are repeated 194 in this section, for other definitions the reader is referred to 195 [PPVPN-term] and [L3VPN-FW]. 197 CE: Customer Edge device. A Customer Edge device is a router or a 198 switch in the customer network interfacing with the Service 199 Provider�s network. 201 P: Provider Router. The Provider Router is a router in the Service 202 Provider�s core network that does not have interfaces directly 203 towards the customer. A P router is used to interconnect the PE 204 routers. A P router does not need to maintain VPN state, and is 205 thus VPN unaware. 207 PE: Provider Edge device. The Provider Edge device is the equipment 208 in the Service Provider�s network that interfaces with the 209 equipment in the customer�s network. 211 PPVPN: Provider Provisioned Virtual Private Network. A VPN that is 212 configured and managed by the Service Provider (and thus not by the 213 customer itself). 215 SP: Service Provider. 217 VPN: Restricted communication between a set of sites, making use of 218 an IP backbone which is shared by traffic that is not going to or 219 coming from those sites. 221 3. Security Reference Model 223 This section defines a reference model for security in PPVPN 224 networks. 226 A PPVPN core network is defined here as the central network 227 infrastructure (P and PE routers) over which PPVPN services are 228 delivered. A PPVPN core network consists of one or more SP 229 networks. All network elements in the core are under the 230 operational control of one or more PPVPN service providers. Even if 231 the PPVPN core is provided by several service providers, towards 232 the PPVPN users it appears as a single zone of trust. However, 233 several service providers providing together a PPVPN core still 234 need to secure themselves against the other providers. PPVPN 235 services can also be delivered over the Internet, in which case the 236 Internet forms a logical part of the PPVPN core. 238 A PPVPN user is a company, institution or residential client of the 239 PPVPN service provider. 241 A PPVPN service is a private network service made available by a 242 service provider to a PPVPN user. The service is implemented using 243 virtual constructs built on a shared PPVPN core network. A PPVPN 244 service interconnects sites of a PPVPN user. 246 Extranets are VPNs in which multiple sites are controlled by 247 different (legal) entities. Extranets are another example of PPVPN 248 deployment scenarios where restricted and controlled communication 249 is allowed between trusted zones, often via well-defined transit 250 points. 252 This document defines each PPVPN as a trusted zone, and the PPVPN 253 core as another trusted zone. A primary concern is about security 254 aspects that relate to breaches of security from the "outside" of a 255 trusted zone to the "inside" of this zone. Figure 1 depicts the 256 concept of trusted zones within the PPVPN framework. 258 +------------+ +------------+ 259 | PPVPN +-----------------------------+ PPVPN | 260 | user PPVPN user | 261 | site +---------------------XXX-----+ site | 262 +------------+ +------------------XXX--+ +------------+ 263 | PPVPN core | | | 264 +------------------| |--+ 265 | | 266 | +------\ 267 +--------/ Internet 269 Figure 1: The PPVPN trusted zone model 271 In principle the trusted zones should be separate, however, often 272 PPVPN core networks also offer Internet access, in which case a 273 transit point (marked with "XXX" in the figure) is defined. 275 The key requirement of a "virtual private" network (VPN) is that 276 the security of the trusted zone of the VPN is not compromised by 277 sharing the core infrastructure with other VPNs. 279 Security against threats that originate within the same trusted 280 zone as their targets (for example, attacks from a user in a PPVPN 281 to other users within the same PPVPN, or attacks entirely within 282 the core network) is outside the scope of this document. 284 Also outside the scope are all aspects of network security which 285 are independent of whether a network is a PPVPN network or a 286 private network (for example, attacks from the Internet to a web- 287 server inside a given PPVPN will not be considered here, unless the 288 way the PPVPN network is provisioned could make a difference to the 289 security of this server). 291 4. Security Threats 293 This section discusses the various network security threats that 294 may endanger PPVPNs. The discussion is limited to those threats 295 that are unique to PPVPNs, or that affect PPVPNs in unique ways. 297 A successful attack on a particular PPVPN or on a service 298 provider's PPVPN infrastructure may cause one or more of the 299 following ill effects: 301 - Observation, modification, or deletion of PPVPN user data. 302 - Replay of PPVPN user data. 303 - Injection of non-authentic data into a PPVPN. 304 - Traffic pattern analysis on PPVPN traffic. 305 - Disruption of PPVPN connectivity. 306 - Degradation of PPVPN service quality 308 It is useful to consider that threats, whether malicious or 309 accidental, to a PPVPN may come from different categories of 310 sources. For example they may come from: 312 - Users of other PPVPNs provided by the same PPVPN service 313 provider. 314 - The PPVPN service provider or persons working for it. 315 - Other persons who obtain physical access to a service provider 316 site. 317 - Other persons who use social engineering methods to influence 318 behavior of service provider personnel. 319 - Users of the PPVPN itself, i.e. intra-VPN threats. (Such threats 320 are beyond the scope of this document.) 321 - Others i.e. attackers from the Internet at large. 323 In the case of PPVPNs, some parties may be in more advantaged 324 positions that enable them to launch types of attacks not available 325 to others. For example users of different PPVPNs provided by the 326 same service provider may be able to launch attacks that those 327 completely outside the network cannot. 329 Given that security is generally a compromise between expense and 330 risk, it is also useful to consider the likelihood of different 331 attacks occurring. There is at least a perceived difference in the 332 likelihood of most types of attacks being successfully mounted in 333 different environments, such as: 335 - In a PPVPN contained within one service provider's network 336 - In a PPVPN transiting the public Internet 338 Most types of attacks become easier to mount and hence more likely 339 as the shared infrastructure via which VPN service is provided 340 expands from a single service provider to multiple cooperating 341 providers to the global Internet. Attacks that may not be of 342 sufficient likeliness to warrant concern in a closely controlled 343 environment often merit defensive measures in broader, more open 344 environments. 346 The following sections discuss specific types of exploits that 347 threaten PPVPNs. 349 4.1. Attacks on the Data Plane 351 This category encompasses attacks on the PPVPN user's data, as 352 viewed by the service provider. Note that from the PPVPN user's 353 point of view, some of this might be control plane traffic, e.g. 354 routing protocols running from PPVPN user site to PPVPN user site 355 via an L2 PPVPN. 357 4.1.1. Unauthorized Observation of Data Traffic 359 This refers to "sniffing" VPN packets and examining their contents. 360 This can result in exposure of confidential information. It can 361 also be a first step in other attacks (described below) in which 362 the recorded data is modified and re-inserted, or re-inserted as- 363 is. 365 4.1.2. Modification of Data Traffic 367 This refers to modifying the contents of packets as they traverse 368 the VPN. 370 4.1.3. Insertion of Non-Authentic Data Traffic: Spoofing and Replay 372 This refers to the insertion (or "spoofing") into the VPN of 373 packets that do not belong there, with the objective of having them 374 accepted by the recipient as legitimate. Also included in this 375 category is the insertion of copies of once-legitimate packets that 376 have been recorded and replayed. 378 4.1.4. Unauthorized Deletion of Data Traffic 380 This refers to causing packets to be discarded as they traverse the 381 VPN. This is a specific type of Denial of Service attack. 383 4.1.5. Unauthorized Traffic Pattern Analysis 385 This refers to "sniffing" VPN packets and examining aspects or 386 meta-aspects of them that may be visible even when the packets 387 themselves are encrypted. An attacker might gain useful 388 information based on the amount and timing of traffic, packet 389 sizes, source and destination addresses, etc. For most PPVPN 390 users, this type of attack is generally considered to be 391 significantly less of a concern than the other types discussed in 392 this section. 394 4.1.6. Denial of Service Attacks on the VPN 396 Denial of Service (DOS) attacks are those in which an attacker 397 attempts to disrupt or prevent the use of a service by its 398 legitimate users. Taking network devices out of service, modifying 399 their configuration, or overwhelming them with requests for service 400 are several of the possible avenues for DOS attack. 402 Overwhelming the network with requests for service, otherwise known 403 as a "resource exhaustion" DOS attack, may target any resource in 404 the network e.g. link bandwidth, packet forwarding capacity, 405 session capacity for various protocols, CPU power, and so on. 407 DOS attacks of the resource exhaustion type can be mounted against 408 the data plane of a particular PPVPN by inserting an overwhelming 409 quantity of non-authentic data into the VPN. 411 Data plane resource exhaustion attacks can also be mounted by 412 overwhelming the service provider's general (VPN-independent) 413 infrastructure with traffic. These attacks on the general 414 infrastructure are not usually a PPVPN-specific issue, unless the 415 attack is mounted by another PPVPN user from a privileged position. 416 (E.g. a PPVPN user might be able to monopolize network data plane 417 resources and thus disrupt other PPVPNs.) 419 4.2. Attacks on the Control Plane 421 This category encompasses attacks on the control structures 422 operated by the PPVPN service provider. 424 4.2.1. Denial of Service Attacks on the Network Infrastructure 426 Control plane DOS attacks can be mounted specifically against the 427 mechanisms the service provider uses to provide PPVPNs e.g. IPsec, 428 MPLS, etc., or against the general infrastructure of the service 429 provider e.g. P routers or shared aspects of PE routers. (Attacks 430 against the general infrastructure are within the scope of this 431 document only if the attack happens in relation with the VPN 432 service, otherwise is not a PPVPN-specific issue.) 434 Of special concern for PPVPNs is denial of service to one PPVPN 435 user caused by the activities of another PPVPN user. This can 436 occur for example if one PPVPN user's activities are allowed to 437 consume excessive network resources of any sort that are also 438 needed to serve other PPVPN users. 440 The attacks described in the following sections may each have 441 denial of service as one of their effects. Other DOS attacks are 442 also possible. 444 4.2.2. Attacks on the Service Provider Equipment Via Management 445 Interfaces 447 This includes unauthorized access to service provider 448 infrastructure equipment, which access can be used to reconfigure 449 the equipment, or to extract information (statistics, topology, 450 etc.) about one or more PPVPNs. 452 This can be accomplished through malicious entering of the systems, 453 or inadvertently as a consequence of inadequate inter-VPN isolation 454 in a PPVPN user self-management interface. (The former is not 455 necessarily a PPVPN-specific issue.) 457 4.2.3. Social Engineering Attacks on the Service Provider 458 Infrastructure 460 Attacks in which the service provider network is reconfigured or 461 damaged, or in which confidential information is improperly 462 disclosed, may be mounted through manipulation of service provider 463 personnel. These types of attacks are PPVPN-specific if they affect 464 PPVPN-serving mechanisms. It may be observed that the 465 organizational split (customer, service provider) that is inherent 466 in PPVPNs may make it easier to mount such attacks against 467 provider-provisioned VPNs than against VPNs that are customer self- 468 provisioned at the IP layer. 470 4.2.4. Cross-connection of Traffic Between PPVPNs 472 This refers to the event where expected isolation between separate 473 PPVPNs is breached. This includes cases such as: 475 - A site being connected into the "wrong" VPN 476 - Two or more VPNs being improperly merged together 477 - A point-to-point VPN connecting the wrong two points 478 - Any packet or frame being improperly delivered outside the VPN 479 it is sent in. 481 Mis-connection or cross-connection of VPNs may be caused by service 482 provider or equipment vendor error, or by the malicious action of 483 an attacker. 485 Anecdotal evidence suggests that the cross-connection threat is one 486 of the largest security concerns of PPVPN users (or would-be 487 users). 489 4.2.5. Attacks Against PPVPN Routing Protocols 490 This encompasses attacks against routing protocols that are run by 491 the service provider and that directly support the PPVPN service. 492 In layer 3 VPNs this typically relates to membership discovery or 493 to the distribution of per-VPN routes. In layer 2 VPNs this 494 typically relates to membership and endpoint discovery. (Attacks 495 against the use of routing protocols for the distribution of 496 backbone (non-VPN) routes are beyond the scope of this document.) 497 Specific attacks against popular routing protocols have been widely 498 studied and described in [Beard]. 500 4.2.6. Attacks on Route Separation 502 "Route separation" refers here to keeping the per-VPN topology and 503 reachability information for each PPVPN separate from, and 504 unavailable to, any other PPVPN (except as specifically intended by 505 the service provider). This concept is only a distinct security 506 concern for those layer 3 VPN types where the service provider is 507 involved with the routing within the VPN (i.e. VR, BGP-MPLS, routed 508 version of IPsec). A breach in the route separation can reveal 509 topology and addressing information about a PPVPN. It can also 510 cause black hole routing or unauthorized data plane cross- 511 connection between PPVPNs. 513 4.2.7. Attacks on Address Space Separation 515 In Layer 3 VPNs, the IP address spaces of different VPNs need to be 516 kept separate. In Layer 2 VPNs, the MAC address and VLAN spaces of 517 different VPNs need to be kept separate. A control plane breach in 518 this addressing separation may result in unauthorized data plane 519 cross-connection between VPNs. 521 4.2.8. Other Attacks on PPVPN Control Traffic 523 Besides routing and management protocols (covered separately in the 524 previous sections) a number of other control protocols may be 525 directly involved in delivering the PPVPN service (e.g. for 526 membership discovery and tunnel establishment in various PPVPN 527 approaches). These include but may not be limited to: 529 - MPLS signaling (LDP, RSVP-TE) 530 - IPsec signaling (IKE) 531 - L2TP 532 - BGP-based membership discovery 533 - Database-based membership discovery (e.g. RADIUS-based) 535 Attacks might subvert or disrupt the activities of these protocols, 536 for example via impersonation or DOS attacks. 538 5. Defensive Techniques for PPVPN Service Providers 539 The defensive techniques discussed in this document are intended to 540 describe methods by which some security threats can be addressed. 541 They are not intended as requirements for all PPVPN 542 implementations. The PPVPN provider should determine the 543 applicability of these techniques to the provider's specific 544 service offerings, and the PPVPN user may wish to assess the value 545 of these techniques to the user's VPN requirements. 547 The techniques discussed here include encryption, authentication, 548 filtering, firewalls, access control, isolation, aggregation, and 549 other techniques. 551 Nothing is ever 100% secure. Defense therefore involves protecting 552 against those attacks that are most likely to occur and/or that 553 have the most dire consequences if successful. For those attacks 554 that are protected against, absolute protection is seldom 555 achievable; more often it is sufficient just to make the cost of a 556 successful attack greater than what the adversary will be willing 557 to expend. 559 Successfully defending against an attack does not necessarily mean 560 the attack must be prevented from happening or from reaching its 561 target. In many cases the network can instead be designed to 562 withstand the attack. For example, the introduction of non- 563 authentic packets could be defended against by preventing their 564 introduction in the first place, or by making it possible to 565 identify and eliminate them before delivery to the PPVPN user's 566 system. The latter is frequently a much easier task. 568 5.1. Cryptographic techniques 570 PPVPN defenses against a wide variety of attacks can be enhanced by 571 the proper application of cryptographic techniques. These are the 572 same cryptographic techniques which are applicable to general 573 network communications. In general, these techniques can provide 574 privacy (encryption) of communication between devices, 575 authentication of the identities of the devices, and can ensure 576 that it will be detected if the data being communicated is changed 577 during transit. 579 Privacy is a key part (the middle name!) of any Virtual Private 580 Network. In a PPVPN, privacy can be provided by two mechanisms: 581 traffic separation and encryption. In this section we focus on 582 encryption, while traffic separation is addressed separately. 584 Several aspects of authentication are addressed in some detail in a 585 separate "Authentication" section. 587 Encryption adds complexity to a service, and thus it may not be a 588 standard offering within every PPVPN service. There are a few 589 reasons why encryption may not be a standard offering within every 590 PPVPN service. Encryption adds an additional computational burden 591 to the devices performing encryption and decryption. This may 592 reduce the number of user VPN connections which can be handled on a 593 device or otherwise reduce the capacity of the device, potentially 594 driving up the provider's costs. Typically, configuring encryption 595 services on devices adds to the complexity of the device 596 configuration and adds incremental labor cost. Packet lengths are 597 typically increased when the packets are encrypted, increasing the 598 network traffic load and adding to the likelihood of packet 599 fragmentation with its increased overhead. (This packet length 600 increase can often be mitigated to some extent by data compression 601 techniques, but at the expense of additional computational burden. 602 Finally, some PPVPN providers may employ enough other defensive 603 techniques, such as physical isolation or filtering/firewall 604 techniques, that they may not perceive additional benefit from 605 encryption techniques. 607 The trust model among the PPVPN user, the PPVPN provider, and other 608 parts of the network is a key element in determining the 609 applicability of encryption for any specific PPVPN implementation. 610 In particular, it determines where encryption should be applied: 611 - If the data path between the user's site and the provider's PE 612 is not trusted, then encryption may be used on the PE-CE link. 613 - If some part of the backbone network is not trusted, 614 particularly in implementations where traffic may travel across 615 the Internet or multiple provider networks, then the PE-PE 616 traffic may encrypted. 617 - If the PPVPN user does not trust any zone outside of its 618 premises, it may require end-to-end or CE-CE encryption service. 619 This service fits within the scope of this PPVPN security 620 framework when the CE is provisioned by the PPVPN provider. 621 - If the PPVPN user requires remote access to a PPVPN from a 622 system at a location which is not a PPVPN customer location (for 623 example, access by a traveler) there may be a requirement for 624 encrypting the traffic between that system and an access point 625 on the PPVPN or at a customer site. If the PPVPN provider 626 provides the access point, then the customer must cooperate with 627 the provider to handle the access control services for the 628 remote users. These access control services are usually 629 implemented using encryption, as well. 631 Although CE-CE encryption provides privacy against third-party 632 interception, if the PPVPN provider has complete management control 633 over the CE (encryption) devices, then it may be possible for the 634 provider to gain access to the user's VPN traffic or internal 635 network. Encryption devices can potentially be configured to use 636 null encryption, bypass encryption processing altogether, or 637 provide some means of sniffing or diverting unencrypted traffic. 638 Thus a PPVPN implementation using CE-CE encryption needs to 639 consider the trust relationship between the PPVPN user and 640 provider. PPVPN users and providers may wish to negotiate a service 641 level agreement (SLA) for CE-CE encryption which will provide an 642 acceptable demarcation of responsibilities for management of 643 encryption on the CE devices. The demarcation may also be affected 644 by the capabilities of the CE devices. For example, the CE might 645 support some partitioning of management, a configuration lock-down 646 ability, or allow both parties to verify the configuration. In 647 general, the PPVPN user needs to have a fairly high level of trust 648 that the PPVPN provider will properly provision and manage the CE 649 devices, if the managed CE-CE model is used. 651 5.1.1. IPsec in PPVPNs 653 IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the 654 security protocol of choice for encryption at the IP layer (Layer 655 3), as discussed in [SECMECH]. IPsec provides robust security for 656 IP traffic between pairs of devices. Non-IP traffic must be 657 converted to IP packets or it cannot be transported over IPsec. 658 Encapsulation is a common conversion method. 660 In the PPVPN model, IPsec can be employed to protect IP traffic 661 between PEs, between a PE and a CE, or from CE to CE. CE-to-CE 662 IPsec may be employed in either a provider-provisioned or a user- 663 provisioned model. The user-provisioned CE-CE IPsec model is 664 outside the scope of this document, and outside the scope of the 665 PPVPN Working Group. Likewise, encryption of data which is 666 performed within the user's site is outside the scope of this 667 document, since it is simply handled as user data by the PPVPN. 668 IPsec can also be used to protect IP traffic between a remote user 669 who is not located at a PPVPN site and the PPVPN. 671 IPsec does not itself specify an encryption algorithm. It can use 672 a variety of encryption algorithms, with various key lengths. 673 There are trade-offs between key length, computational burden, and 674 the level of security of the encryption. A full discussion of 675 these trade-offs is beyond the scope of this document. In order to 676 assess the level of security offered by a particular IPsec-based 677 PPVPN service, some PPVPN users may wish to know the specific 678 encryption algorithm and effective key length used by the PPVPN 679 provider. However, in practice, any currently recommended IPsec 680 encryption offers enough security to substantially reduce the 681 likelihood of being directly targeted by an attacker; other weaker 682 links in the chain of security are likely to be attacked first. 683 PPVPN users may wish to use a Service Level Agreement (SLA) 684 specifying the Service Provider's responsibility for ensuring data 685 privacy, rather than analyzing the specific encryption techniques 686 used in the PPVPN service. 688 For many of the PPVPN provider's network control messages and some 689 PPVPN user requirements, cryptographic authentication of messages 690 without encryption of the contents of the message may provide 691 acceptable security. Using IPsec, authentication of messages is 692 provided by the Authentication Header (AH) or through the use of 693 the Encapsulating Security Protocol (ESP) with authentication only. 694 Where control messages require authentication but do not use IPsec, 695 then other cryptographic authentication methods are available. 696 Message authentication methods currently considered to be secure 697 are based on hashed message authentication codes (HMAC) [RFC2104] 698 implemented with a secure hash algorithm such as Secure Hash 699 Algorithm 1 (SHA-1) [RFC3174]. 701 PPVPNs which provide differentiated services based on traffic type 702 may encounter some conflicts with IPsec encryption of traffic. 703 Since encryption hides the content of the packets, it may not be 704 possible to differentiate the encrypted traffic in the same manner 705 as unencrypted traffic. Although DiffServ markings are copied to 706 the IPsec header and can provide some differentiation, not all 707 traffic types can be accommodated by this mechanism. 709 5.1.2. Encryption for device configuration and management 711 For configuration and management of PPVPN devices, encryption and 712 authentication of the management connection at a level comparable 713 to that provided by IPsec is desirable. 715 Several methods of transporting PPVPN device management traffic 716 offer security and privacy. 717 - Secure Shell (SSH) offers protection for TELNET [STD-8] or 718 terminal-like connections to allow device configuration. 719 - SNMP v3 [STD62] provides encrypted and authenticated protection 720 for SNMP-managed devices. 721 - Transport Layer Security (TLS) (also known as Secure Sockets 722 Layer or SSL) [RFC-2246] is probably the emerging standard for 723 securing HTTP-based communication, and thus can provide support 724 for most XML- and SOAP-based device management approaches. 725 - IPsec provides security and privacy services at the network 726 layer. With regards to device management, its current use is 727 primarily focused on in-band management of user-managed IPsec 728 gateway devices. 730 5.1.3. Cryptographic techniques in Layer 2 PPVPNs 732 Layer 2 PPVPNs will generally not be able to use IPsec to provide 733 encryption throughout the entire network. They may be able to use 734 IPsec for PE-PE traffic where it is encapsulated in IP packets, but 735 IPsec will generally not be applicable for CE-PE traffic in Layer 2 736 PPVPNs. 738 Encryption techniques for Layer 2 links are widely available, but 739 are not within the scope of this document, nor of IETF documents in 740 general. Layer 2 encryption could be applied to the links from CE 741 to PE, or could be applied from CE to CE, as long as the encrypted 742 Layer 2 packets can be properly handled by the intervening PE 743 devices. In addition, the upper layer traffic transported by the 744 Layer 2 VPN can be encrypted by the user. In this case privacy 745 will be maintained; however, this is transparent to the PPVPN 746 provider and is outside the scope of this document. 748 5.1.4. End-to-end vs. hop-by-hop encryption tradeoffs in PPVPNs 750 In PPVPNs, encryption could potentially be applied to the VPN 751 traffic at several different places. This section discusses some 752 of the tradeoffs in implementing encryption in several different 753 connection topologies among different devices within a PPVPN. 755 Encryption typically involves a pair of devices which encrypt the 756 traffic passing between them. The devices may be directly 757 connected (over a single "hop"), or there may be intervening 758 devices which transport the encrypted traffic between the pair of 759 devices. The extreme cases involve using encryption between every 760 adjacent pair of devices along a given path (hop-by-hop), or using 761 encryption only between the end devices along a given path (end-to- 762 end). To keep this discussion within the scope of PPVPNs, the 763 latter ("end-to-end") case considered here is CE-to-CE rather than 764 fully end-to-end. 766 Figure 2 depicts a simplified PPVPN topology showing the Customer 767 Edge (CE) devices, the Provider Edge (PE) devices, and a variable 768 number (three are shown) of Provider core (P) devices which might 769 be present along the path between two sites in a single VPN, 770 operated by a single service provider (SP). 772 Site_1---CE---PE---P---P---P---PE---CE---Site_2 774 Figure 2: Simplified PPVPN topology 776 Within this simplified topology, and assuming that P devices are 777 not to be involved with encryption, there are four basic feasible 778 configurations for implementing encryption on connections among the 779 devices: 781 1) Site-to-site (CE-to-CE) - Encryption can be configured between 782 the two CE devices, so that traffic will be encrypted throughout 783 the SP's network. 785 2) Provider edge-to-edge (PE-to-PE) - Encryption can be configured 786 between the two PE devices. Unencrypted traffic is received at one 787 PE from the customer's CE, then it is encrypted for transmission 788 through the SP's network to the other PE, where it is decrypted and 789 sent to the other CE. 791 3) Access link (CE-to-PE) - Encryption can be configured between 792 the CE and PE, on each side (or on only one side). 794 4) Configurations 2 and 3 above can also be combined, with 795 encryption running from CE to PE, then PE to PE, then PE to CE. 797 Among the four feasible configurations, key tradeoffs in 798 considering encryption include: 800 - Vulnerability to wiretap - assuming an attacker can tap the data 801 in transit between devices, would it be protected by encryption? 803 - Vulnerability to device compromise - assuming an attacker can get 804 access to a device (or freely alter its configuration), would the 805 data be protected? 807 - Complexity of device configuration and management - given the 808 number of sites per VPN customer as Nce and the number of PEs 809 participating in a given VPN as Npe, how many device configurations 810 need to be created or maintained, and how do those configurations 811 scale? 813 - Processing load on devices - how many encryption or decryption 814 operations must be done given P packets? - This influences 815 considerations of device capacity and perhaps end-to-end delay. 817 - Ability of SP to provide enhanced services (QoS, firewall, 818 intrusion detection, etc.) - Can the SP inspect the data in order 819 to provide these services? 821 These tradeoffs are discussed for each configuration, below: 823 1) Site-to-site (CE-to-CE) 825 Wiretap - protected on all links 826 Device compromise - vulnerable to CE compromise 827 Complexity - single administration, responsible for one device per 828 site (Nce devices), but overall configuration per VPN scales as 829 Nce^^2 830 Processing load - on each of two CEs, each packet is either 831 encrypted or decrypted (2P) 833 Enhanced services � severely limited; typically only Diffserv 834 markings are visible to SP, allowing some QoS services 836 2) Provider edge-to-edge (PE-to-PE) 838 Wiretap - vulnerable on CE-PE links; protected on SP's network 839 links 840 Device compromise - vulnerable to CE or PE compromise 841 Complexity - single administration, Npe devices to configure. 842 (Multiple sites may share a PE device so Npe is typically much 843 less than Nce.) Scalability of the overall configuration 844 depends on the PPVPN type: If the encryption is separate per 845 VPN context, it scales as Npe^^2 per customer VPN. If the 846 encryption is per-PE, it scales as Npe^^2 for all customer VPNs 847 combined. 848 Processing load - on each of two PEs, each packet is either 849 encrypted or decrypted (2P) 850 Enhanced services - full; SP can apply any enhancements based on 851 detailed view of traffic 853 3) Access link (CE-to-PE) 855 Wiretap - protected on CE-PE link; vulnerable on SP's network links 856 Device compromise - vulnerable to CE or PE compromise 857 Complexity - two administrations (customer and SP) with device 858 configuration on each side (Nce + Npe devices to configure) but 859 since there is no mesh the overall configuration scales as Nce. 860 Processing load - on each of two CEs, each packet is either 861 encrypted or decrypted, plus on each of two PEs, each packet is 862 either encrypted or decrypted (4P) 863 Enhanced services - full; SP can apply any enhancements based on 864 detailed view of traffic 866 4) Combined Access link and PE-to-PE (essentially hop-by-hop) 868 Wiretap - protected on all links 869 Device compromise - vulnerable to CE or PE compromise 870 Complexity - two administrations (customer and SP) with device 871 configuration on each side (Nce + Npe devices to configure). 872 Scalability of the overall configuration depends on the PPVPN 873 type: If the encryption is separate per VPN context, it scales 874 as Npe^^2 per customer VPN. If the encryption is per-PE, it 875 scales as Npe^^2 for all customer VPNs combined. 876 Processing load - on each of two CEs, each packet is either 877 encrypted or decrypted, plus on each of two PEs, each packet is 878 both encrypted and decrypted (6P) 879 Enhanced services - full; SP can apply any enhancements based on 880 detailed view of traffic 882 Given the tradeoffs discussed above, a few conclusions can be made: 884 - Configurations 2 and 3 are subsets of 4 that may be appropriate 885 alternatives to 4 under certain threat models; the remainder of 886 these conclusions compare 1 (CE-to-CE) vs. 4 (combined access links 887 and PE-to-PE). 889 - If protection from wiretaps is most important, then 890 configurations 1 and 4 are equivalent. 892 - If protection from device compromise is most important and the 893 threat is to the CE devices, both cases are equivalent; if the 894 threat is to the PE devices, configuration 1 is best. 896 - If reducing complexity is most important, and the size of the 897 network is very small, configuration 1 is the best. Otherwise 898 configuration 4 is the best because rather than a mesh of CE 899 devices it requires a smaller mesh of PE devices. Also under some 900 PPVPN approaches the scaling of 4 is further improved by sharing 901 the same PE-PE mesh across all VPN contexts. 903 - If the overall processing load is a key factor, then 1 is best. 905 - If the availability of enhanced services support from the SP is 906 most important, then 4 is best. 908 As a quick overall conclusion, CE-to-CE encryption provides greater 909 protection against device compromise but this comes at the cost of 910 enhanced services and at the cost of operational complexity due to 911 the Order(n^^2) scaling of a larger mesh. 913 This analysis of site-to-site vs. hop-by-hop encryption tradeoffs 914 does not explicitly include cases of multiple providers cooperating 915 to provide a PPVPN service, public Internet VPN connectivity, or 916 remote access VPN service, but many of the tradeoffs will be 917 similar. 919 5.2. Authentication 921 In order to prevent security issues from some Denial-of-Service 922 attacks or from malicious misconfiguration, it is critical that 923 devices in the PPVPN should only accept connections or control 924 messages from valid sources. Authentication refers to methods to 925 ensure that message sources are properly identified by the PPVPN 926 devices with which they communicate. This section focuses on 927 identifying the scenarios in which sender authentication is 928 required, and recommends authentication mechanisms for these 929 scenarios. 931 Cryptographic techniques (authentication and encryption) do not 932 protect against some types of denial of service attacks, 933 specifically resource exhaustion attacks based on CPU or bandwidth 934 exhaustion. In fact, the processing required to decrypt and/or 935 check authentication may in some cases increase the effect of these 936 resource exhaustion attacks. Cryptographic techniques may however, 937 be useful against resource exhaustion attacks based on exhaustion 938 of state information (e.g., TCP SYN attacks). 940 5.2.1. VPN Member Authentication 942 This category includes techniques for the CEs to verify they are 943 connected to the expected VPN. It includes techniques for CE-PE 944 authentication, to verify that each specific CE and PE is actually 945 communicating with its expected peer. 947 5.2.2. Management System Authentication 949 Management system authentication includes the authentication of a 950 PE to a centrally-managed directory server, when directory-based 951 "auto-discovery" is used. It also includes authentication of a CE 952 to its PPVPN configuration server, when a configuration server 953 system is used. 955 5.2.3. Peer-to-peer Authentication 957 Peer-to-peer authentication includes peer authentication for 958 network control protocols (e.g. LDP, BGP, etc.), and other peer 959 authentication (i.e. authentication of one IPsec security gateway 960 by another). 962 5.2.4. Authenticating Remote Access VPN members 964 This section describes methods for authentication of remote access 965 users connecting to a VPN. 967 Effective authentication of individual connections is a key 968 requirement for enabling remote access to a PPVPN from an arbitrary 969 Internet address (for instance, by a traveler). 971 There are several widely used standards-based protocols to support 972 remote access authentication. These include RADIUS [ref] and 973 DIAMETER [ref]. Digital certificate systems also provide 974 authentication. In addition there has been extensive development 975 and deployment of mechanisms for securely transporting individual 976 remote access connections within tunneling protocols, including 977 L2TP [ref] and IPsec. 979 Remote access involves connection to a gateway device, which 980 provides access to the PPVPN. The gateway device may be managed by 981 the user at a user site, or by the PPVPN provider at several 982 possible locations in the network. The user-managed case is of 983 limited interest within the PPVPN security framework, and is not 984 considered at this time. 986 When a PPVPN provider manages authentication at the remote access 987 gateway, this implies that authentication databases, which are 988 usually extremely confidential user-managed systems, will need to 989 be referenced in a secure manner by the PPVPN provider. This can be 990 accomplished by the use of proxy authentication services, which 991 accept an encrypted authentication credential from the remote 992 access user, pass it to the PPVPN user's authentication system, and 993 receive a yes/no response as to whether the user has been 994 authenticated. Thus the PPVPN provider does not have access to the 995 actual authentication database, but can use it on behalf of the 996 PPVPN user to provide remote access authentication. 998 Specific cryptographic techniques for handling authentication are 999 described in the following sections. 1001 5.2.5. Cryptographic techniques for authenticating identity 1003 Cryptographic techniques offer several mechanisms for 1004 authenticating the identity of devices or individuals. These 1005 include the use of shared secret keys, one-time keys generated by 1006 accessory devices or software, user-ID and password pairs, and a 1007 range of public-private key systems. Another approach is to use a 1008 hierarchical Certificate Authority system to provide digital 1009 certificates. 1011 This section describes or provides references to the specific 1012 cryptographic approaches for authenticating identity. These 1013 approaches provide secure mechanisms for most of the authentication 1014 scenarios required in operating a PPVPN. 1016 5.3. Access Control techniques 1018 Access control techniques include packet-by-packet or packet-flow- 1019 by-packet-flow access control by means of filters and firewalls, as 1020 well as by means of admitting a "session" for a 1021 control/signaling/management protocol that is being used to 1022 implement PPVPNs. Enforcement of access control by isolated 1023 infrastructure addresses is discussed in another section of this 1024 document. 1026 In this document, we distinguish between filtering and firewalls 1027 based primarily on the direction of traffic flow. We define 1028 filtering as being applicable to unidirectional traffic, while a 1029 firewall can analyze and control both sides of a conversation. 1031 There are two significant corollaries of this definition: 1033 - Routing or traffic flow symmetry: A firewall typically requires 1034 routing symmetry, which is usually enforced by locating a firewall 1035 where the network topology assures that both sides of a 1036 conversation will pass through the firewall. A filter can operate 1037 upon traffic flowing in one direction, without considering traffic 1038 in the reverse direction. 1039 - Statefulness: Since it receives both sides of a conversation, a 1040 firewall may be able to interpret a significant amount of 1041 information concerning the state of that conversation, and use this 1042 information to control access. A filter can maintain some limited 1043 state information on a unidirectional flow of packets, but cannot 1044 determine the state of the bi-directional conversation as precisely 1045 as a firewall. 1047 5.3.1. Filtering 1049 It is relatively common for routers to filter data packets. That 1050 is, routers can look for particular values in certain fields of the 1051 IP or higher level (e.g., TCP or UDP) headers. Packets which match 1052 the criteria associated with a particular filter may either be 1053 discarded or given special treatment. 1055 In discussing filters, it is useful to separate the Filter 1056 Characteristics which may be used to determine whether a packet 1057 matches a filter from the Packet Actions which are applied to those 1058 packets which match a particular filter. 1060 o Filter Characteristics 1062 Filter characteristics are used to determine whether a particular 1063 packet or set of packets matches a particular filter. 1065 In many cases filter characteristics may be stateless. A stateless 1066 filter is one which determines whether a particular packet matches 1067 a filter based solely on the filter definition, normal forwarding 1068 information (such as the next hop for a packet), and the 1069 characteristics of that individual packet. Typically stateless 1070 filters may consider the incoming and outgoing logical or physical 1071 interface, information in the IP header, and information in higher 1072 layer headers such as the TCP or UDP header. Information in the IP 1073 header to be considered may for example include source and 1074 destination IP address, Protocol field, Fragment Offset, and TOS 1075 field. Filters also may consider fields in the TCP or UDP header 1076 such as the Port fields as well as the SYN field in the TCP header. 1078 Stateful filtering maintains packet-specific state information, to 1079 aid in determining whether a filter has been met. For example, a 1080 device might apply stateless filters to the first fragment of a 1081 fragmented IP packet. If the filter matches, then the data unit ID 1082 may be remembered and other fragments of the same packet may then 1083 be considered to match the same filter. Stateful filtering is more 1084 commonly done in firewalls, although firewall technology may be 1085 added to routers. 1087 o Actions based on Filter Results 1089 If a packet, or a series of packets, match a specific filter, then 1090 there are a variety of actions which may be taken based on that 1091 filter match. Examples of such actions include: 1093 - Discard 1095 In many cases filters may be set to catch certain undesirable 1096 packets. Examples may include packets with forged or invalid source 1097 addresses, packets which are part of a DOS or DDOS attack, or 1098 packets which are trying to access resources which are not 1099 permitted (such as network management packets from an unauthorized 1100 source). Where such filters are activated, it is common to silently 1101 discard the packet or set of packets matching the filter. The 1102 discarded packets may of course also be counted and/or logged. 1104 - Set CoS 1106 A filter may be used to set the Class of Service associated with 1107 the packet. 1109 - Count packets and/or bytes 1111 - Rate Limit 1113 In some cases the set of packets which match a particular filter 1114 may be limited to a specified bandwidth. In this case packets 1115 and/or bytes would be counted, and would be forwarded normally up 1116 to the specified limit. Excess packets may be discarded, or may be 1117 marked (for example by setting a "discard eligible" bit in the IP 1118 ToS field or the MPLS EXP field). 1120 - Forward and Copy 1122 It is useful in some cases to forward some set of packets normally, 1123 but to also send a copy to a specified other address or interface. 1124 For example, this may be used to implement a lawful intercept 1125 capability, or to feed selected packets to an Intrusion Detection 1126 System. 1128 o Other Issues related to Use of Packet Filters 1130 There may be a very wide variation in the performance impact of 1131 filtering. This may occur both due to differences between 1132 implementations, and also due to differences between types or 1133 numbers of filters deployed. For filtering to be useful, the 1134 performance of the equipment has to be acceptable in the presence 1135 of filters. 1137 The precise definition of "acceptable" may vary from service 1138 provider to service provider, and may depend upon the intended use 1139 of the filters. For example, for some uses a filter may be turned 1140 on all the time in order to set CoS, to prevent an attack, or to 1141 mitigate the effect of a possible future attack. In this case it is 1142 likely that the service provider will want the filter to have 1143 minimal or no impact on performance. In other cases, a filter may 1144 be turned on only in response to a major attack (such as a major 1145 DDOS attack). In this case a greater performance impact may be 1146 acceptable to some service providers. 1148 5.3.2. Firewalls 1150 Firewalls provide a mechanism for control over traffic passing 1151 between different trusted zones in the PPVPN model, or between a 1152 trusted zone and an untrusted zone. Firewalls typically provide 1153 much more functionality than filters, since they may be able to 1154 apply detailed analysis and logical functions to flows, and not 1155 just to individual packets. They may offer a variety of complex 1156 services, such as threshold-driven denial-of-service attack 1157 protection, virus scanning, acting as a TCP connection proxy, etc. 1159 As with other access control techniques, the value of firewalls 1160 depends on a clear understanding of the topologies of the PPVPN 1161 core network, the user networks, and the threat model. Their 1162 effectiveness depends on a topology with a clearly defined inside 1163 (secure) and outside (not secure). 1165 Within the PPVPN framework, traffic typically is not allowed to 1166 pass between the various user VPNs. This inter-VPN isolation is 1167 usually not performed by a firewall, but is a part of the basic VPN 1168 mechanism. An exception to the total isolation of VPNs is the case 1169 of "extranets", which allow specific external access to a user's 1170 VPN, potentially from another VPN. Firewalls can be used to 1171 provide the services required for secure extranet implementation. 1173 In a PPVPN, firewalls can be applied between the public Internet 1174 and user VPNs, in cases where Internet access services are offered 1175 by the provider to the VPN user sites. In addition, firewalls may 1176 be applied between VPN user sites and any shared network-based 1177 services offered by the PPVPN provider. 1179 Firewalls may be applied to help protect PPVPN core network 1180 functions from attacks originating from the Internet or from PPVPN 1181 user sites, but typically other defensive techniques will be used 1182 for this purpose. 1184 Where firewalls are employed as a service to protect user VPN sites 1185 from the Internet, different VPN users, and even different sites of 1186 a single VPN user, may have varying firewall requirements. The 1187 overall PPVPN logical and physical topology, along with the 1188 capabilities of the devices implementing the firewall services, 1189 will have a significant effect on the feasibility and manageability 1190 of such varied firewall service offerings. 1192 5.3.3. Access Control to management interfaces 1194 Most of the security issues related to management interfaces can be 1195 addressed through the use of authentication techniques as described 1196 in the section on authentication. However, additional security may 1197 be provided by controlling access to management interfaces in other 1198 ways. 1200 Management interfaces, especially console ports on PPVPN devices, 1201 may be configured so they are only accessible out-of-band, through 1202 a system which is physically and/or logically separated from the 1203 rest of the PPVPN infrastructure. 1205 Where management interfaces are accessible in-band within the PPVPN 1206 domain, filtering or firewalling techniques can be used to restrict 1207 unauthorized in-band traffic from having access to management 1208 interfaces. Depending on device capabilities, these filtering or 1209 firewalling techniques can be configured either on other devices 1210 through which the traffic might pass, or on the individual PPVPN 1211 devices themselves. 1213 5.4. Use of Isolated Infrastructure 1215 One way to protect the infrastructure used for support of VPNs is 1216 to separate the resources for support of VPNs from the resources 1217 used for other purposes (such as support of Internet services). In 1218 some cases this may make use of physically separate equipment for 1219 VPN services, or even a physically separate network. 1221 For example, PE-based L3 VPNs may be run on a separate backbone not 1222 connected to the Internet, or may make use of separate edge routers 1223 from those used to support Internet service. Private IP addresses 1224 (local to the provider and non-routable over the Internet) are 1225 sometimes used to provide additional separation. 1227 It is common for CE-based L3VPNs to make use of CE devices which 1228 are dedicated to one specific VPN. In many or most cases CE-based 1229 VPNs may make use of normal Internet services to interconnect CE 1230 devices. 1232 5.5. Use of Aggregated Infrastructure 1233 In general it is not feasible to use a completely separate set of 1234 resources for support of each VPN. In fact, one of the main reasons 1235 for VPN services is to allow sharing of resources between multiple 1236 users, including multiple VPNs. Thus even if VPN services make use 1237 of a separate network from Internet services, nonetheless there 1238 will still be multiple VPN users sharing the same network 1239 resources. In some cases VPN services will share the use of network 1240 resources with Internet services or other services. 1242 It is therefore important for VPN services to provide protection 1243 between resource utilization by different VPNs. Thus a well-behaved 1244 VPN user should be protected from possible misbehavior by other 1245 VPNs. This requires that limits are placed on the amount of 1246 resources which can be used by any one VPN. For example, both 1247 control traffic and user data traffic may be rate limited. In some 1248 cases or in some parts of the network where a sufficiently large 1249 number of queues are available each VPN (and optionally each VPN 1250 and CoS within the VPN) may make use of a separate queue. Control- 1251 plane resources such as link bandwidth as well as CPU and memory 1252 resources may be reserved on a per-VPN basis. 1254 The techniques which are used to provision resource protection 1255 between multiple VPNs served by the same infrastructure can also be 1256 used to protect VPN services from Internet services. 1258 In general the use of aggregated infrastructure allows the service 1259 provider to benefit from stochastic multiplexing of multiple bursty 1260 flows, and also may in some cases thwart traffic pattern analysis 1261 by combining the data from multiple VPNs. 1263 5.6. Service Provider Quality Control Processes 1265 Deployment of provider-provisioned VPN services in general requires 1266 a relatively large amount of configuration by the service provider. 1267 For example, the service provider needs to configure which VPN each 1268 site belongs to, as well as QoS and SLA guarantees. This large 1269 amount of required configuration leads to the possibility of 1270 misconfiguration. 1272 It is important for the service provider to have operational 1273 processes in place to reduce the potential impact of 1274 misconfiguration. CE to CE authentication may also be used to 1275 detect misconfiguration when it occurs. 1277 5.7. Deployment of Testable PPVPN Service. 1279 This refers to solutions that can be readily tested to make sure 1280 they are configured correctly. E.g. for a point-point VPN, 1281 checking that the intended connectivity is working pretty much 1282 ensures that there is not connectivity to some unintended site. 1284 6. Monitoring, Detection, and Reporting of Security Attacks 1286 A PPVPN service may be subject to attacks from a variety of 1287 security threats. Many threats are described in another part of 1288 this document. Many of the defensive techniques described in this 1289 document and elsewhere provide significant levels of protection 1290 from a variety of threats. However, in addition to silently 1291 employing defensive techniques to protect against attacks, PPVPN 1292 services can also add value for both providers and customers by 1293 implementing security monitoring systems which detect and report on 1294 any security attacks which occur, regardless of whether the attacks 1295 are effective. 1297 Attackers often begin by probing and analyzing defenses, so systems 1298 which can detect and properly report these early stages of attacks 1299 can provide significant benefits. 1301 Information concerning attack incidents, especially if available 1302 quickly, can be useful in defending against further attacks. It 1303 can be used to help identify attackers and/or their specific 1304 targets at an early stage. This knowledge about attackers and 1305 targets can be used to further strengthen defenses against specific 1306 attacks or attackers, or improve the defensive services for 1307 specific targets on an as-needed basis. Information collected on 1308 attacks may also be useful in identifying and developing defenses 1309 against novel attack types. 1311 Monitoring systems used to detect security attacks in PPVPNs will 1312 typically operate by collecting information from the Provider Edge 1313 (PE), Customer Edge (CE), and/or Provider backbone (P) devices. 1314 Security monitoring systems should have the ability to actively 1315 retrieve information from devices (e.g., SNMP get) or to passively 1316 receive reports from devices (e.g., SNMP traps). The specific 1317 information exchanged will depend on the capabilities of the 1318 devices and on the type of VPN technology. Particular care should 1319 be given to securing the communications channel between the 1320 monitoring systems and the PPVPN devices. 1322 The CE, PE, and P devices should employ efficient methods to 1323 acquire and communicate the information needed by the security 1324 monitoring systems. It is important that the communication method 1325 between PPVPN devices and security monitoring systems be designed 1326 so that it will not disrupt network operations. As an example, 1327 multiple attack events may be reported through a single message, 1328 rather than allowing each attack event to trigger a separate 1329 message, which might result in a flood of messages, essentially 1330 becoming a denial-of-service attack against the monitoring system 1331 or the network. 1333 The mechanisms for reporting security attacks should be flexible 1334 enough to meet the needs of VPN service providers, VPN customers, 1335 and regulatory agencies, if applicable. The specific reports will 1336 depend on the capabilities of the devices, the security monitoring 1337 system, the type of VPN, and the service level agreements between 1338 the provider and customer. 1340 7. User Security Requirements 1342 This section defines a list of security related requirements that 1343 the users of PPVPN services may have for their PPVPN service. 1344 Typically, these user requirements translate into requirement for 1345 the provider in offering the service. 1347 The following sections detail various requirements that ensure the 1348 security of a given trusted zone. Since in real life there are 1349 various levels of security, a PPVPN may fulfill any number or all 1350 of these security requirements. Specifically this document does not 1351 state that a PPVPN must fulfill all of these requirements to be 1352 secure. As mentioned in the Introduction, it is not within the 1353 scope of this document to define the specific requirements that 1354 each VPN technology must fulfill in order to be secure. 1356 7.1. Isolation 1358 A virtual private network usually defines the "private" as being 1359 isolated from other PPVPNs and the Internet. More specifically, 1360 isolation has several components: 1362 7.1.1. Address Separation 1364 Within a PPVPN service, a given PPVPN can use the full Internet 1365 address range, including private address ranges [RFC1918], without 1366 interfering with other PPVPNs that use the same PPVPN service. When 1367 using Internet access through the PPVPN core a NAT functionality 1368 can be implemented. 1370 In layer 2 VPNs the same requirement exists for the layer 2 1371 addressing schemes, such as MAC addresses. 1373 7.1.2. Routing Separation 1375 A PPVPN core must maintain routing separation between the trusted 1376 zones. This means that routing information must not leak from any 1377 trusted zone to any other trusted zone, unless this is specifically 1378 engineered this way, for example for Internet access. 1380 In layer 2 VPNs the switching information must be kept separate 1381 between the trusted zones, such that switching information of one 1382 PPVPN does not influence other PPVPNs or the PPVPN core. 1384 7.1.3. Traffic Separation 1386 Traffic from a given trusted zone must never leave this zone, and 1387 traffic from another zone must never enter this zone. Exceptions 1388 are where this is specifically engineered that way, for example for 1389 extranet purposes or Internet access. 1391 7.2. Protection 1393 The perception of a completely separated, "private" network is that 1394 it has defined entry points, and only over those is can be attacked 1395 or intruded. By sharing a common core a PPVPN appears to lose some 1396 of this clear interfaces to parts outside the trusted zone. Thus 1397 one of the key security requirements of PPVPN services is that they 1398 offer the same level of protection as private networks. 1400 7.2.1. Protection against intrusion 1402 An intrusion is defined here as the penetration of a trusted zone 1403 from outside this zone. This could be from the Internet, another 1404 PPVPN, or the core network itself. 1406 The fact that a network is "virtual" must not expose it to 1407 additional threats over private networks. Specifically, it must not 1408 add new interfaces to other parts outside the trusted zone. 1409 Intrusions from known interfaces such as Internet gateways are 1410 outside the scope of this document. 1412 7.2.2. Protection against Denial of Service attacks 1414 A denial of service attack aims at making services or devices un- 1415 available to legitimate users. In the framework of this document 1416 only those DoS attacks are considered which are a consequence of 1417 providing the network in a virtual way. DoS attacks over the 1418 standard interfaces into a trusted zone are not considered here. 1420 The requirement is that a PPVPN is not more vulnerable against DoS 1421 attacks than if the same network would be private. 1423 7.2.3. Protection against spoofing 1425 It is not possible to change the sender identification (source 1426 address, source label, etc) of traffic in transit, such that by 1427 this spoofing the integrity of a PPVPN gets violated. For example, 1428 if two CEs are connected to the same PE, it must not be possible 1429 for one CE to send crafted packets that make the PE believe those 1430 packets are coming from the other CE, thus inserting them into the 1431 wrong PPVPN. 1433 7.3. Confidentiality 1435 This requirement means that data must be cryptographically secured 1436 in transit over the PPVPN core network to avoid eavesdropping. 1438 7.4. CE Authentication 1440 Where CE authentication is provided it is not possible for an 1441 outsider to install a CE and pretend to belong to a specific PPVPN, 1442 to which this CE does not belong in reality. 1444 7.5. Integrity 1446 Data in transit must be secured in a manner such that it cannot be 1447 altered, or that any alteration may be detected at the receiver. 1449 7.6. Anti-Replay 1451 Anti-replay means that data in transit cannot be recorded and 1452 replayed later. To protect against anti-replay attacks the data 1453 must be cryptographically secured. 1455 Note: Even private networks do not necessarily meet the 1456 requirements of confidentiality, integrity and anti-reply. Thus 1457 when comparing private to "virtually private" PPVPN services these 1458 requirements are only applicable if the comparable private service 1459 also included these services. 1461 8. Provider Security Requirements 1463 In this section, we discuss additional security requirements that 1464 the provider may have in order to secure its network infrastructure 1465 as it provides PPVPN services. 1467 The PPVPN service provider requirements defined here are the 1468 requirements for the PPVPN core in the reference model. The core 1469 network can be implemented with different types of network 1470 technologies, and each core network may use different technologies 1471 to provide the PPVPN services to users with different levels of 1472 offered security. Therefore, a PPVPN service provider may fulfill 1473 any number of the security requirements listed in this section. 1474 This document does not state that a PPVPN must fulfill all of these 1475 requirements to be secure. 1477 These requirements are focused on: 1) how to protect the PPVPN core 1478 from various attacks outside the core including PPVPN users and 1479 non-PPVPN alike, both accidentally and maliciously, 2) how to 1480 protect the PPVPN user VPNs and sites themselves. Note that a PPVPN 1481 core is not more vulnerable against attacks than a core that does 1482 not provide PPVPNs. However providing PPVPN services over such a 1483 core may need lead to additional security requirements, for the 1484 mere fact that most users are expecting higher security standards 1485 in a core delivering PPVPN services. 1487 8.1. Protection within the Core Network 1489 8.1.1. Control Plane Protection 1491 - Protocol authentication within the core: 1493 PPVPN technologies and infrastructure must support mechanisms for 1494 authentication of the control plane. For an IP core, IGP and BGP 1495 sessions may be authenticated by using TCP MD5 or IPsec. If an MPLS 1496 core is used, LDP sessions may be authenticated by use TCP MD5, in 1497 addition, IGP and BGP authentication should also be considered. For 1498 a core providing Layer 2 services, PE to PE authentication may also 1499 be used via IPsec. 1501 With the cost of authentication coming down rapidly, the 1502 application of control plane authentication may not increase the 1503 cost of implementation for providers significantly, and will help 1504 to improve the security of the core. If the core is dedicated to 1505 VPN services and without any interconnects to third parties then 1506 this may reduce the requirement for authentication of the core 1507 control plane. 1509 - Elements protection 1511 Here we discuss means to hide the provider's infrastructure nodes. 1513 A PPVPN provider may make the infrastructure routers (P and PE 1514 routers) unreachable from outside users and unauthorized internal 1515 users. For example, separate address space may be used for the 1516 infrastructure loopbacks. 1518 Normal TTL propagation may be altered to make the backbone look 1519 like one hop from the outside, but caution needs to be taken for 1520 loop prevention. This prevents the backbone addresses to be exposed 1521 through trace route, however this must also be assessed against 1522 operational requirements for end to end fault tracing. 1524 An Internet backbone core may be re-engineered to make Internet 1525 routing an edge function, for example, using MPLS label switching 1526 for all traffic within the core and possibly make the Internet a 1527 VPN within the PPVPN core itself. This helps to detach Internet 1528 access from PPVPN services. 1530 Separating control plane, data plane, and management plane 1531 functionality in terms of hardware and software may be implemented 1532 on the PE devices to improve security. This may help to limit the 1533 problems when attacked in one particular area, and may allow each 1534 plane to implement additional security measurement separately. 1536 PEs are often more vulnerable to attack than P routers, since PEs 1537 cannot be made unreachable to outside users by their very nature. 1538 Access to core trunk resources can be controlled on a per user 1539 basis by the application of inbound rate-limiting/shaping, this can 1540 be further enhanced on a per Class of Service basis (see section 1541 7.2.3) 1543 In the PE, using separate routing processes for Internet and PPVPN 1544 service may help to improve the PPVPN security and better protect 1545 VPN customers. Furthermore, if the resources, such as CPU and 1546 Memory, may be further separated based on applications, or even 1547 individual VPNs, it may help to provide improved security and 1548 reliability to individual VPN customers. 1550 Many of these were not particular issues when an IP core was 1551 designed to support Internet services only. When providing PPVPN 1552 services, new requirements are introduced to satisfy the security 1553 needs for VPN services. Similar consideration apply to L2 VPN 1554 services. 1556 8.1.2. Data Plane Protection 1558 PPVPN using IPsec technologies provide VPN users with encryption of 1559 secure user data. 1561 In today's MPLS, ATM, or Frame Relay networks, encryption is not 1562 provided as a basic feature. Mechanisms can be used to secure the 1563 MPLS data plane to secure the data carried over MPLS core. 1564 Additionally, if the core is dedicated to VPN services and without 1565 any external interconnects to third party networks then there is no 1566 obvious need for encryption of the user data plane. 1568 IPsec / L3 PPVPN technologies inter-working, or IPsec /L2 PPVPN 1569 technologies inter-working may be used to provide PPVPN users end- 1570 to-end PPVPN services. 1572 8.2. Protection on the User Access Link 1574 Peer / Neighbor protocol authentication may be used to enhance 1575 security. For example, BGP MD5 authentication may be used to 1576 enhance security on PE-CE links using eBGP. In the case of Inter- 1577 provider connection, authentication / encryption mechanisms between 1578 ASes, such as IPsec, may be used. 1580 WAN link address space separation for VPN and non-VPN users may be 1581 implemented to improve security in order to protect VPN customers 1582 if multiple services are provided on the same PE platform. 1584 Firewall / Filtering: access control mechanisms can be used to 1585 filter out any packets destined for the service provider's 1586 infrastructure prefix or eliminate routes identified as 1587 illegitimate routes. 1589 Rate limiting may be applied to the user interface/logical 1590 interfaces against DDOS bandwidth attack. This is very helpful when 1591 the PE device is supporting both VPN services and Internet 1592 Services, especially when supporting VPN and Internet Services on 1593 the same physical interfaces through different logical interfaces. 1595 7.2.1 Link Authentication 1597 Authentication mechanisms can be employed to validate site access 1598 to the PPVPN network via fixed or logical (e.g. L2TP, IPsec) 1599 connections. Where the user wishes to hold the 'secret' associated 1600 to acceptance of the access and site into the VPN, then PPVPN based 1601 solutions require the flexibility for either direct authentication 1602 by the PE itself or interaction with a customer PPVPN 1603 authentication server. Mechanisms are required in the latter case 1604 to ensure that the interaction between the PE and the customer 1605 authentication server is controlled e.g. limiting it simply to an 1606 exchange in relation to the authentication phase and with other 1607 attributes e.g. RADIUS optionally being filtered. 1609 7.2.2 Access Routing 1611 Mechanisms may be used to provide control at a routing protocol 1612 level e.g. RIP, OSPF, BGP between the CE and PE. Per neighbor and 1613 per VPN routing policies may be established to enhance security and 1614 reduce the impact of a malicious or non-malicious attack on the PE, 1615 in particular the following mechanisms should be considered: 1616 - Limiting the number of prefixes that may be advertised on a per 1617 access basis into the PE. Appropriate action may be taken should 1618 a limit be exceeded e.g. the PE shutting down the peer session 1619 to the CE 1620 - Applying route dampening at the PE on received routing updates 1621 - Definition of a per VPN prefix limit after which additional 1622 prefixes will not be added to the VPN routing table. 1624 In the case of Inter-provider connection, access protection, link 1625 authentication, and routing policies as described above may be 1626 applied. Both inbound and outbound firewall/filtering mechanism 1627 between ASes may be applied. Proper security procedures must be 1628 implemented in Inter-provider VPN interconnection to protect the 1629 providers' network infrastructure and their customer VPNs. This may 1630 be custom designed for each Inter-Provider VPN peering connection, 1631 and must be agreed by both providers. 1633 7.2.3 Access QoS 1635 PPVPN providers offering QoS enabled services require mechanisms to 1636 ensure that individual accesses are validated against their 1637 subscribed QOS profile and as such gain access to core resources 1638 that match their service profile. Mechanisms such as per Class of 1639 service rate limiting/traffic shaping on ingress to the PPVPN core 1640 are one option in providing this level of control. Such mechanisms 1641 may require the per Class of Service profile to be enforced either 1642 by marking, remarking or discard of traffic outside of profile. 1644 7.2.4 Customer VPN monitoring tools 1646 End users requiring visibility of VPN specific statistics on the 1647 core e.g. routing table, interface status, QoS statistics, impose 1648 requirements for mechanisms at the PE to both validate the incoming 1649 user and limit the views available to that particular users VPN. 1650 Mechanisms should also be considered to ensure that such access 1651 cannot be used a means of a DOS attack (either malicious or 1652 accidental) on the PE itself. This could be accomplished through 1653 either separation of these resources within the PE itself or via 1654 the capability to rate-limit on a per VPN basis such traffic. 1656 8.3. General Requirements for PPVPN Providers 1658 The PPVPN providers must support the users security requirements as 1659 listed in Section 6. Depending on the technologies used, these 1660 requirements may include: 1662 - User control plane separation � routing isolation 1663 - User address space separation � supporting overlapping addresses 1664 from different VPNs 1665 - User data plane separation � one VPN traffic cannot be 1666 intercepted by other VPNs or any other users. 1667 - Protection against intrusion, DOS attacks and spoofing 1668 - Access Authentication 1669 - Techniques highlighted through this document identify 1670 methodologies for the protection of PPVPN resources and 1671 infrastructure. By following these approaches a secure VPN 1672 service can be delivered without the absolute need for 1673 cryptographic techniques 1675 Equipment hardware/software bugs leading to breaches in security 1676 are not within the scope of this document. 1678 9. Security Evaluation of PPVPN Technologies 1679 This section presents a brief template that may be used to evaluate 1680 and summarize how a given PPVPN approach (solution) measures up 1681 against the PPVPN Security Framework. An evaluation of a given 1682 PPVPN approach using this template should appear in the 1683 applicability statement for each PPVPN approach. 1685 9.1. Evaluating the Template 1687 The first part of the template is in the form of a list of security 1688 assertions. For each assertion the approach is assessed and one or 1689 more of the following ratings is assigned: 1691 - The requirement is not applicable to the VPN approach because ... 1692 (fill in reason) 1694 - The base VPN approach completely addresses the requirement by ... 1695 (fill in technique) 1697 - The base VPN approach partially addresses the requirement by ... 1698 (fill in technique and extent to which it addresses the 1699 requirement) 1701 - An optional extension to the VPN approach completely addresses 1702 the requirement by ... (fill in technique) 1704 - An optional extension to the VPN approach partially addresses the 1705 requirement by ... (fill in technique and extent to which it 1706 addresses the requirement) 1708 - In the VPN approach, the requirement is addressed in a way that 1709 is beyond the scope of the VPN approach. (Explain) (One 1710 example of this would be a VPN approach in which some aspect, 1711 say membership discovery, is done via configuration. The 1712 protection afforded to the configuration would be beyond the 1713 scope of the VPN approach.) 1715 - The VPN approach does not meet the requirement. 1717 9.2. Template 1719 The following assertions solicit responses of the types listed in 1720 the previous section. 1722 1. The approach provides complete IP address space separation for 1723 each L3 VPN. 1725 2. The approach provides complete L2 address space separation for 1726 each L2 VPN. 1728 3. The approach provides complete VLAN ID space separation for each 1729 L2 VPN. 1731 4. The approach provides complete IP route separation for each L3 1732 VPN. 1734 5. The approach provides complete L2 forwarding separation for each 1735 L2 VPN. 1737 6. The approach provides a means to prevent improper cross- 1738 connection of sites in separate VPNs. 1740 7. The approach provides a means to detect improper cross- 1741 connection of sites in separate VPNs. 1743 8. The approach protects against the introduction of unauthorized 1744 packets into each VPN. 1746 a. In the CE-PE link 1747 b. In a single- or multi- provider PPVPN backbone 1748 c. In the Internet used as PPVPN backbone 1750 9. The approach provides confidentiality (secrecy) protection for 1751 PPVPN user data. 1753 a. In the CE-PE link 1754 b. In a single- or multi- provider PPVPN backbone 1755 c. In the Internet used as PPVPN backbone 1757 10. The approach provides sender authentication for PPVPN user 1758 data. 1760 a. In the CE-PE link 1761 b. In a single- or multi- provider PPVPN backbone 1762 c. In the Internet used as PPVPN backbone 1764 11. The approach provides integrity protection for PPVPN user data. 1766 a. In the CE-PE link 1767 b. In a single- or multi- provider PPVPN backbone 1768 c. In the Internet used as PPVPN backbone 1770 12. The approach provides protection against replay attacks for 1771 PPVPN user data. 1773 a. In the CE-PE link 1774 b. In a single- or multi- provider PPVPN backbone 1775 c. In the Internet used as PPVPN backbone 1777 13. The approach provides protection against unauthorized traffic 1778 pattern analysis for PPVPN user data. 1780 a. In the CE-PE link 1781 b. In a single- or multi- provider PPVPN backbone 1782 c. In the Internet used as PPVPN backbone 1784 14. The control protocol(s) used for each of the following 1785 functions provide for message integrity and peer authentication: 1787 a. VPN membership discovery 1788 b. Tunnel establishment 1789 c. VPN topology and reachability advertisement 1790 i. PE-PE 1791 ii. PE-CE 1792 d. VPN provisioning and management 1793 e. VPN monitoring and attack detection and reporting 1794 f. Other VPN-specific control protocols, if any. (list) 1796 The following questions solicit free-form answers. 1798 15. Describe the protection, if any, the approach provides against 1799 PPVPN-specific DOS attacks (i.e. Inter-trusted-zone DOS 1800 attacks): 1802 a. Protection of the service provider infrastructure against 1803 Data Plane or Control Plane DOS attacks originated in a 1804 private (PPVPN user) network and aimed at PPVPN mechanisms. 1805 b. Protection of the service provider infrastructure against 1806 Data Plane or Control Plane DOS attacks originated in the 1807 Internet and aimed at PPVPN mechanisms. 1808 c. Protection of PPVPN users against Data Plane or Control Plane 1809 DOS attacks originated from the Internet or from other PPVPN 1810 users and aimed at PPVPN mechanisms. 1812 16. Describe the protection, if any, the approach provides against 1813 unstable or malicious operation of a PPVPN user network: 1815 a. Protection against high levels of, or malicious design of, 1816 routing traffic from PPVPN user networks to the service 1817 provider network. 1818 b. Protection against high levels of, or malicious design of, 1819 network management traffic from PPVPN user networks to the 1820 service provider network. 1821 c. Protection against worms and probes originated in the PPVPN 1822 user networks, sent towards the service provider network. 1824 17. Is the approach subject to any approach-specific 1825 vulnerabilities not specifically addressed by this template? If 1826 so describe the defense or mitigation, if any, the approach 1827 provides for each. 1829 10. Security Considerations 1831 Security considerations constitute the sole subject of this memo 1832 and hence are discussed throughout. Here we recap what has been 1833 presented and explain at a very high level the role of each type of 1834 consideration in an overall secure PPVPN system. 1836 The document describes a number of potential security threats. 1837 Some of these threats have already been observed occurring in 1838 running networks; others are largely theoretical at this time. DOS 1839 attacks and intrusion 1840 attacks from the Internet against service provider infrastructure 1841 have been seen to occur. DOS "attacks" (typically not malicious) 1842 have also been seen in which CE equipment overwhelms PE equipment 1843 with high quantities or rates of packet traffic or routing 1844 information. Operational/provisioning errors are cited by service 1845 providers as one of their prime concerns. 1847 The document describes a variety of defensive techniques that may 1848 be used to counter the suspected threats. All of the techniques 1849 presented involve mature and widely implemented technologies that 1850 are practical to implement. 1852 The document describes the importance of detecting, monitoring, and 1853 reporting attacks, both successful and unsuccessful. These 1854 activities are essential for "understanding one's enemy", 1855 mobilizing new defenses, and obtaining metrics about how secure the 1856 PPVPN service is. As such they are vital components of any 1857 complete PPVPN security system. 1859 The document evaluates PPVPN security requirements from a customer 1860 perspective as well as from a service provider perspective. These 1861 sections re-evaluate the identified threats from the perspectives 1862 of the various stakeholders and are meant to assist equipment 1863 vendors and service providers, who must ultimately decide what 1864 threats to protect against in any given equipment or service 1865 offering. 1867 Finally, the document includes a template for use by authors of 1868 PPVPN technical solutions for evaluating how those solutions 1869 measure up against the security considerations presented in this 1870 memo. 1872 11. Acknowledgement 1874 The authors would also like to acknowledge the helpful comments and 1875 suggestions from Paul Hoffman, Eric Gray, Ron Bonica, Chris Chase, 1876 Jerry Ash, Stewart Bryant, and the IETF Security Directorate. 1878 References 1880 [Beard] D. Beard and Y. Yang, "Known Threats to Routing Protocols," 1881 draft-beard-rpsec-routing-threats-00.txt, Oct. 2002. 1883 [GDOI] M. Baugher, T. Hardjono, H. Harney, B. Weis, "The Group 1884 Domain of Interpretation," draft-ietf-msec-gdoi-07.txt, December 1885 2002. 1887 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1888 for Message Authentication," February 1997. 1890 [RFC-2246] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", 1891 RFC 2246, January 1999. 1893 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 1894 Internet Protocol," November 1998. 1896 [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header," 1897 November 1898 1998. 1900 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 1901 (ESP)," November 1998. 1903 [RFC2407] D. Piper, "The Internet IP Security Domain of 1904 Interpretation for ISAKMP," November 1998. 1906 [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 1907 Roadmap," November 1998. 1909 [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 1910 1 (SHA1)," September 2001. 1912 [SECMECH] S. Bellovin, C. Kaufman, J. Schiller, "Security 1913 Mechanisms for the Internet," draft-iab-secmech-02.txt, January 1914 2003. 1916 [STD62] "Simple Network Management Protocol, Version 3," RFCs 3411- 1917 3418, December 2002. 1919 [STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification", 1920 STD 8, May 1983. 1922 [L3VPN-FW] R. Callon et al, "A Framework for Layer 3 Provider 1923 Provisioned Virtual Private Networks," Internet-draft , March 2003. 1926 [L3VPN-REQ] M. Carugi et al, "Service Requirements for Layer 3 1927 Provider Provisioned Virtual Private Networks," Internet-draft 1928 , April 2003. 1930 Author's Addresses 1932 Luyuan Fang 1933 AT&T 1934 200 Laurel Avenue, Room C2-3B35 Phone: 732-420-1921 1935 Middletown, NJ 07748 Email: luyuanfang@att.com 1937 Michael Behringer 1938 Cisco 1939 Avda de la Vega 15 Phone: 34-639-659-822 1940 28100 Alcobendas, Madrid Email: mbehring@cisco.com 1941 Spain 1943 Ross Callon 1944 Juniper Networks 1945 10 Technology Park Drive Phone: 978-692-6724 1946 Westford, MA 01886 Email: rcallon@juniper.net 1948 Fabio Chiussi 1949 Lucent Technologies 1950 101 Crawfords Corner Rd, Room 4G502 Phone: 732-949-2407 1951 Holmdel, NJ 07733 Email: fabio@lucent.com 1953 Jeremy De Clercq 1954 Alcatel 1955 Fr. Wellesplein 1, 2018 Antwerpen E-mail: 1956 Belgium jeremy.de_clercq@alcatel.be 1958 Mark Duffy 1959 Quarry Technologies 1960 8 New England Executive Park Phone: 781-359-5052 1961 Burlington, MA 01803 Email: mduffy@quarrytech.com 1963 Paul Hitchen 1964 BT 1965 BT Adastral Park 1966 Martlesham Heath Phone: 44-1473-606-344 1967 Ipswich IP53RE Email: paul.hitchen@bt.com 1968 UK 1970 Paul Knight 1971 Nortel Networks 1972 600 Technology Park Drive Phone: 978-288-6414 1973 Billerica, MA 01821 Email: paul.knight@nortelnetworks.com 1975 Full Copyright Statement 1977 "Copyright (C) The Internet Society (date). All Rights Reserved. 1978 This document and translations of it may be copied and furnished to 1979 others, and derivative works that comment on or otherwise explain 1980 it or assist in its implementation may be prepared, copied, 1981 published and distributed, in whole or in part, without restriction 1982 of any kind, provided that the above copyright notice and this 1983 paragraph are included on all such copies and derivative works. 1984 However, this document itself may not be modified in any way, such 1985 as by removing the copyright notice or references to the Internet 1986 Society or other Internet organizations, except as needed for the 1987 purpose of developing Internet standards in which case the 1988 procedures for copyrights defined in the Internet Standards process 1989 must be followed, or as required to translate it into languages 1990 other than English. 1992 The limited permissions granted above are perpetual and will not be 1993 revoked by the Internet Society or its successors or assigns. This 1994 document and the information contained herein is provided on an "AS 1995 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1996 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1997 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1998 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1999 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.