idnits 2.17.1 draft-ietf-l3vpn-security-framework-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2041. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2047. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 400 has weird spacing: '...PVPN by attem...' == Line 756 has weird spacing: '...tiality will ...' == Line 1426 has weird spacing: '...is that a com...' == 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 (November 2004) is 7073 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'L3VPN-REQ' is mentioned on line 118, but not defined == Missing Reference: 'PPVPN-term' is mentioned on line 187, but not defined == Missing Reference: 'SECMECH' is mentioned on line 653, but not defined == Missing Reference: 'RFC-3602' is mentioned on line 702, but not defined == Missing Reference: 'STD-8' is mentioned on line 720, but not defined == Missing Reference: 'RFC-2246' is mentioned on line 724, but not defined ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346) == Missing Reference: 'RFC1918' is mentioned on line 1397, but not defined == Unused Reference: 'RFC2246' is defined on line 1916, but no explicit reference was found in the text == Unused Reference: 'RFC3602' is defined on line 1942, but no explicit reference was found in the text == Unused Reference: 'STD8' is defined on line 1948, but no explicit reference was found in the text == Unused Reference: 'RFC8631' is defined on line 1965, but no explicit reference was found in the text ** 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 3588 (Obsoleted by RFC 6733) -- Possible downref: Non-RFC (?) normative reference: ref. 'STD62' -- Possible downref: Non-RFC (?) normative reference: ref. 'STD8' -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Luyuan Fang (editor) 3 AT&T 5 L3VPN WG 6 Internet Draft 7 Document: 8 draft-ietf-l3vpn-security-framework-03.txt 9 Expires: May 2005 November 2004 11 Security Framework for Provider Provisioned Virtual Private 12 Networks 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance 19 with RFC 3668. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet-Drafts 32 as reference material or to cite them other than as "work in 33 progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This draft addresses security aspects pertaining to Provider 43 Provisioned Virtual Private Networks (PPVPNs). We first describe 45 Expires May 2005 1 46 the security threats that are relevant in the context of PPVPNs, 47 and the defensive techniques that can be used to combat those 48 threats. We consider security issues deriving both from malicious 49 behavior of anyone and from negligent or incorrect behavior of the 50 providers. We also describe how these security attacks should be 51 detected and reported. We then discuss the possible user 52 requirements in terms of security in a PPVPN service. These user 53 requirements translate into corresponding requirements for the 54 providers. In addition, the provider may have additional 55 requirements to make its network infrastructure secure to a level 56 that can meet the PPVPN customer's expectations. Finally, we define 57 a template that may be used to analyze the security characteristics 58 of a specific PPVPN technology and describe them in a manner 59 consistent with this framework. 61 Table of Contents 63 Status of this Memo...............................................1 64 Abstract..........................................................1 65 Conventions used in this document.................................3 66 1. Introduction...................................................3 67 2. Terminology....................................................4 68 3. Security Reference Model.......................................5 69 4. Security Threats...............................................6 70 4.1. Attacks on the Data Plane...................................8 71 4.2. Attacks on the Control Plane................................9 72 5. Defensive Techniques for PPVPN Service Providers..............11 73 5.1. Cryptographic techniques...................................12 74 5.2. Authentication.............................................20 75 5.3. Access Control techniques..................................22 76 5.4. Use of Isolated Infrastructure.............................26 77 5.5. Use of Aggregated Infrastructure...........................26 78 5.6. Service Provider Quality Control Processes.................27 79 5.7. Deployment of Testable PPVPN Service.......................27 80 6. Monitoring, Detection, and Reporting of Security Attacks......27 81 7. User Security Requirements....................................28 82 7.1. Isolation..................................................29 83 7.2. Protection.................................................29 84 7.3. Confidentiality............................................30 85 7.4. CE Authentication..........................................30 86 7.5. Integrity..................................................30 87 7.6. Anti-Replay................................................31 88 8. Provider Security Requirements................................31 89 8.1. Protection within the Core Network.........................31 90 8.2. Protection on the User Access Link.........................33 91 8.3. General Requirements for PPVPN Providers...................35 92 9. Security Evaluation of PPVPN Technologies.....................35 93 9.1. Evaluating the Template....................................35 94 9.2. Template...................................................36 95 10. Security Considerations.....................................38 96 11. IANA Considerations.........................................39 97 12. Acknowledgement.............................................39 98 13. Normative References........................................39 99 14. Informational References....................................40 100 Author's Addresses...............................................41 101 Notices..........................................................42 103 Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 107 this document are to be interpreted as described in RFC2119 [RFC 108 2119]. 110 1. Introduction 112 Security is clearly an integral aspect of Provider Provisioned 113 Virtual Private Network (PPVPN) services. 115 The motivation and rationale for both Provider Provisioned Layer-2 116 VPN and Provider Provisioned Layer-3 VPN services are provided by 117 [L3VPN-FW] and [L3VPN-REQ]. 118 [L3VPN-FW] and [L3VPN-REQ] acknowledge that security is an 119 important and integral aspect of PPVPN services. Security is a 120 concern for both VPN customers and VPN Service Providers. Both will 121 benefit from a PPVPN Security Framework document that lists the 122 customer's and provider's security requirements related to PPVPN 123 services, and that can be used to assess how much a particular 124 technology protects against security threats and fulfills the 125 security requirements. 127 In this document, we first describe the security threats that are 128 relevant in the context of PPVPNs, and the defensive techniques 129 that can be used to combat those threats. We consider security 130 issues deriving both from malicious or incorrect behavior of users 131 and other parties and from negligent or incorrect behavior of the 132 providers. An important part of security defense is the detection 133 and report of a security attack, which is also addressed in this 134 document. Any special considerations engendered by IP mobility 135 within PPVPNs are not in the scope of this document. 137 We then discuss the possible user and provider security 138 requirements in a PPVPN service. The users have expectations that 139 need to be met on the security characteristics of a VPN service. 140 These user requirements translate into corresponding requirements 141 for the providers in order to offer the service. Furthermore, 142 providers have security requirements to protect their network 143 infrastructure, and make it secure to the level required to provide 144 the PPVPN services, in addition to other services. 146 Finally, we define a template that may be used to describe the 147 security characteristics of a specific PPVPN technology in a manner 148 consistent with the security framework described in this document. 149 It is not within the scope of this document to analyze the security 150 properties of specific technologies; instead, our intention with 151 this template is to provide a common tool, in the form of a check 152 list, that may be used in other documents dedicated to an in-depth 153 security analysis of individual PPVPN technologies to describe 154 their security characteristics in a comprehensive and coherent way, 155 and to provide a common ground for comparison between different 156 technologies. 158 It is important to clarify that, in this document, we limit 159 ourselves to describing the users and providers' security 160 requirements that pertain to PPVPN services. It is not our 161 intention, however, to formulate precise "requirements" on each 162 specific technology in terms of defining the mechanisms and 163 techniques that must be implemented to satisfy such users and 164 providers' requirements. 166 This document is organized as follows. In Section 2, we 167 define the terminology used in the document. In section 3, we 168 define the security reference model for security in PPVPN networks, 169 which we use in the rest of the document. In Section 4, we describe 170 the security threats that are specific of PPVPNs. In Section 5, we 171 review defense techniques that may be used against those threats. 172 In Section 6, we describe how attacks may be detected and reported. 173 In Section 7, we discuss the user security requirements that apply 174 to PPVPN services. In Section 8, we describe additional security 175 requirements that the provider may have in order to guarantee the 176 security of the network infrastructure to provide PPVPN services. 177 In Section 9, we provide a template that may be used to describe 178 the security characteristics of specific PPVPN technologies. 179 Finally, in Section 10, we discuss security considerations. 181 2. Terminology 183 This document uses PPVPN-specific terminology. Definitions and 184 details about PPVPN-specific terminology can be found in [PPVPN- 185 term] and [L3VPN-FW]. The most important definitions are repeated 186 in this section, for other definitions the reader is referred to 187 [PPVPN-term] and [L3VPN-FW]. 189 CE: Customer Edge device. A Customer Edge device is a router or a 190 switch in the customer network interfacing with the Service 191 Provider's network. 193 P: Provider Router. The Provider Router is a router in the Service 194 Provider's core network that does not have interfaces directly 195 towards the customer. A P router is used to interconnect the PE 196 routers. A P router does not need to maintain VPN state, and is 197 thus VPN unaware. 199 PE: Provider Edge device. The Provider Edge device is the equipment 200 in the Service Provider's network that interfaces with the 201 equipment in the customer's network. 203 PPVPN: Provider Provisioned Virtual Private Network. A VPN that is 204 configured and managed by the Service Provider (and thus not by the 205 customer itself). 207 SP: Service Provider. 209 VPN: Restricted communication between a set of sites, making use of 210 an IP backbone which is shared by traffic that is not going to or 211 coming from those sites. 213 3. Security Reference Model 215 This section defines a reference model for security in PPVPN 216 networks. 218 A PPVPN core network is defined here as the central network 219 infrastructure (P and PE routers) over which PPVPN services are 220 delivered. A PPVPN core network consists of one or more SP 221 networks. All network elements in the core are under the 222 operational control of one or more PPVPN service providers. Even if 223 the PPVPN core is provided by several service providers, towards 224 the PPVPN users it appears as a single zone of trust. However, 225 several service providers providing together a PPVPN core still 226 need to secure themselves against the other providers. PPVPN 227 services can also be delivered over the Internet, in which case the 228 Internet forms a logical part of the PPVPN core. 230 A PPVPN user is a company, institution or residential client of the 231 PPVPN service provider. 233 A PPVPN service is a private network service made available by a 234 service provider to a PPVPN user. The service is implemented using 235 virtual constructs built on a shared PPVPN core network. A PPVPN 236 service interconnects sites of a PPVPN user. 238 Extranets are VPNs in which multiple sites are controlled by 239 different (legal) entities. Extranets are another example of PPVPN 240 deployment scenarios where restricted and controlled communication 241 is allowed between trusted zones, often via well-defined transit 242 points. 244 This document defines each PPVPN as a trusted zone, and the PPVPN 245 core as another trusted zone. A primary concern is about security 246 aspects that relate to breaches of security from the "outside" of a 247 trusted zone to the "inside" of this zone. Figure 1 depicts the 248 concept of trusted zones within the PPVPN framework. 250 +------------+ +------------+ 251 | PPVPN +-----------------------------+ PPVPN | 252 | user PPVPN user | 253 | site +---------------------XXX-----+ site | 254 +------------+ +------------------XXX--+ +------------+ 255 | PPVPN core | | | 256 +------------------| |--+ 257 | | 258 | +------\ 259 +--------/ Internet 261 Figure 1: The PPVPN trusted zone model 263 In principle the trusted zones should be separate, however, often 264 PPVPN core networks also offer Internet access, in which case a 265 transit point (marked with "XXX" in the figure) is defined. 267 The key requirement of a "virtual private" network (VPN) is that 268 the security of the trusted zone of the VPN is not compromised by 269 sharing the core infrastructure with other VPNs. 271 Security against threats that originate within the same trusted 272 zone as their targets (for example, attacks from a user in a PPVPN 273 to other users within the same PPVPN, or attacks entirely within 274 the core network) is outside the scope of this document. 276 Also outside the scope are all aspects of network security which 277 are independent of whether a network is a PPVPN network or a 278 private network (for example, attacks from the Internet to a web- 279 server inside a given PPVPN will not be considered here, unless the 280 way the PPVPN network is provisioned could make a difference to the 281 security of this server). 283 4. Security Threats 285 This section discusses the various network security threats that 286 may endanger PPVPNs. The discussion is limited to those threats 287 that are unique to PPVPNs, or that affect PPVPNs in unique ways. 289 A successful attack on a particular PPVPN or on a service 290 provider's PPVPN infrastructure may cause one or more of the 291 following ill effects: 293 - Observation, modification, or deletion of PPVPN user data. 294 - Replay of PPVPN user data. 295 - Injection of non-authentic data into a PPVPN. 296 - Traffic pattern analysis on PPVPN traffic. 297 - Disruption of PPVPN connectivity. 298 - Degradation of PPVPN service quality 300 It is useful to consider that threats, whether malicious or 301 accidental, to a PPVPN may come from different categories of 302 sources. For example they may come from: 304 - Users of other PPVPNs provided by the same PPVPN service 305 provider. 306 - The PPVPN service provider or persons working for it. 307 - Other persons who obtain physical access to a service provider 308 site. 309 - Other persons who use social engineering methods to influence 310 behavior of service provider personnel. 311 - Users of the PPVPN itself, i.e. intra-VPN threats. (Such threats 312 are beyond the scope of this document.) 313 - Others i.e. attackers from the Internet at large. 315 In the case of PPVPNs, some parties may be in more advantaged 316 positions that enable them to launch types of attacks not available 317 to others. For example users of different PPVPNs provided by the 318 same service provider may be able to launch attacks that those 319 completely outside the network cannot. 321 Given that security is generally a compromise between expense and 322 risk, it is also useful to consider the likelihood of different 323 attacks occurring. There is at least a perceived difference in the 324 likelihood of most types of attacks being successfully mounted in 325 different environments, such as: 327 - In a PPVPN contained within one service provider's network 328 - In a PPVPN transiting the public Internet 330 Most types of attacks become easier to mount and hence more likely 331 as the shared infrastructure via which VPN service is provided 332 expands from a single service provider to multiple cooperating 333 providers to the global Internet. Attacks that may not be of 334 sufficient likeliness to warrant concern in a closely controlled 335 environment often merit defensive measures in broader, more open 336 environments. 338 The following sections discuss specific types of exploits that 339 threaten PPVPNs. 341 4.1. Attacks on the Data Plane 343 This category encompasses attacks on the PPVPN user's data, as 344 viewed by the service provider. Note that from the PPVPN user's 345 point of view, some of this might be control plane traffic, e.g. 346 routing protocols running from PPVPN user site to PPVPN user site 347 via an L2 PPVPN. 349 4.1.1. Unauthorized Observation of Data Traffic 351 This refers to "sniffing" VPN packets and examining their contents. 352 This can result in exposure of confidential information. It can 353 also be a first step in other attacks (described below) in which 354 the recorded data is modified and re-inserted, or re-inserted as- 355 is. 357 4.1.2. Modification of Data Traffic 359 This refers to modifying the contents of packets as they traverse 360 the VPN. 362 4.1.3. Insertion of Non-Authentic Data Traffic: Spoofing and Replay 364 This refers to the insertion (or "spoofing") into the VPN of 365 packets that do not belong there, with the objective of having them 366 accepted by the recipient as legitimate. Also included in this 367 category is the insertion of copies of once-legitimate packets that 368 have been recorded and replayed. 370 4.1.4. Unauthorized Deletion of Data Traffic 372 This refers to causing packets to be discarded as they traverse the 373 VPN. This is a specific type of Denial of Service attack. 375 4.1.5. Unauthorized Traffic Pattern Analysis 377 This refers to "sniffing" VPN packets and examining aspects or 378 meta-aspects of them that may be visible even when the packets 379 themselves are encrypted. An attacker might gain useful 380 information based on the amount and timing of traffic, packet 381 sizes, source and destination addresses, etc. For most PPVPN 382 users, this type of attack is generally considered to be 383 significantly less of a concern than the other types discussed in 384 this section. 386 4.1.6. Denial of Service Attacks on the VPN 388 Denial of Service (DOS) attacks are those in which an attacker 389 attempts to disrupt or prevent the use of a service by its 390 legitimate users. Taking network devices out of service, modifying 391 their configuration, or overwhelming them with requests for service 392 are several of the possible avenues for DOS attack. 394 Overwhelming the network with requests for service, otherwise known 395 as a "resource exhaustion" DOS attack, may target any resource in 396 the network e.g. link bandwidth, packet forwarding capacity, 397 session capacity for various protocols, CPU power, and so on. 399 DOS attacks of the resource exhaustion type can be mounted against 400 the data plane of a particular PPVPN by attempting to 401 insert(spoofing) an overwhelming quantity of non-authentic data 402 into the VPN from the outside of that VPN. Potential results might 403 be to exhaust the bandwidth available to that VPN or to overwhelm 404 the cryptographic authentication mechanisms of the VPN. 406 Data plane resource exhaustion attacks can also be mounted by 407 overwhelming the service provider's general (VPN-independent) 408 infrastructure with traffic. These attacks on the general 409 infrastructure are not usually a PPVPN-specific issue, unless the 410 attack is mounted by another PPVPN user from a privileged position. 411 (E.g. a PPVPN user might be able to monopolize network data plane 412 resources and thus disrupt other PPVPNs.) 414 4.2. Attacks on the Control Plane 416 This category encompasses attacks on the control structures 417 operated by the PPVPN service provider. 419 4.2.1. Denial of Service Attacks on the Network Infrastructure 421 Control plane DOS attacks can be mounted specifically against the 422 mechanisms the service provider uses to provide PPVPNs e.g. IPsec, 423 MPLS, etc., or against the general infrastructure of the service 424 provider e.g. P routers or shared aspects of PE routers. (Attacks 425 against the general infrastructure are within the scope of this 426 document only if the attack happens in relation with the VPN 427 service, otherwise is not a PPVPN-specific issue.) 429 Of special concern for PPVPNs is denial of service to one PPVPN 430 user caused by the activities of another PPVPN user. This can 431 occur for example if one PPVPN user's activities are allowed to 432 consume excessive network resources of any sort that are also 433 needed to serve other PPVPN users. 435 The attacks described in the following sections may each have 436 denial of service as one of their effects. Other DOS attacks are 437 also possible. 439 4.2.2. Attacks on the Service Provider Equipment Via Management 440 Interfaces 442 This includes unauthorized access to service provider 443 infrastructure equipment, for example to reconfigure the equipment 444 or to extract information (statistics, topology, etc.) about one or 445 more PPVPNs. 447 This can be accomplished through malicious entering of the systems, 448 or inadvertently as a consequence of inadequate inter-VPN isolation 449 in a PPVPN user self-management interface. (The former is not 450 necessarily a PPVPN-specific issue.) 452 4.2.3. Social Engineering Attacks on the Service Provider 453 Infrastructure 455 Attacks in which the service provider network is reconfigured or 456 damaged, or in which confidential information is improperly 457 disclosed, may be mounted through manipulation of service provider 458 personnel. These types of attacks are PPVPN-specific if they affect 459 PPVPN-serving mechanisms. It may be observed that the 460 organizational split (customer, service provider) that is inherent 461 in PPVPNs may make it easier to mount such attacks against 462 provider-provisioned VPNs than against VPNs that are customer self- 463 provisioned at the IP layer. 465 4.2.4. Cross-connection of Traffic Between PPVPNs 467 This refers to the event where expected isolation between separate 468 PPVPNs is breached. This includes cases such as: 470 - A site being connected into the "wrong" VPN 471 - Two or more VPNs being improperly merged together 472 - A point-to-point VPN connecting the wrong two points 473 - Any packet or frame being improperly delivered outside the VPN 474 it is sent in. 476 Mis-connection or cross-connection of VPNs may be caused by service 477 provider or equipment vendor error, or by the malicious action of 478 an attacker. The breach may be physical (e.g. PE-CE links mis-con 479 nected) or logical (improper device configuration). 481 Anecdotal evidence suggests that the cross-connection threat is one 482 of the largest security concerns of PPVPN users (or would-be 483 users). 485 4.2.5. Attacks Against PPVPN Routing Protocols 487 This encompasses attacks against routing protocols that are run by 488 the service provider and that directly support the PPVPN service. 489 In layer 3 VPNs this typically relates to membership discovery or 490 to the distribution of per-VPN routes. In layer 2 VPNs this 491 typically relates to membership and endpoint discovery. (Attacks 492 against the use of routing protocols for the distribution of 493 backbone (non-VPN) routes are beyond the scope of this document.) 494 Specific attacks against popular routing protocols have been widely 495 studied and described in [RPSEC]. 497 4.2.6. Attacks on Route Separation 499 "Route separation" refers here to keeping the per-VPN topology and 500 reachability information for each PPVPN separate from, and 501 unavailable to, any other PPVPN (except as specifically intended by 502 the service provider). This concept is only a distinct security 503 concern for those layer 3 VPN types where the service provider is 504 involved with the routing within the VPN (i.e. VR, BGP-MPLS, routed 505 version of IPsec). A breach in the route separation can reveal 506 topology and addressing information about a PPVPN. It can also 507 cause black hole routing or unauthorized data plane cross- 508 connection between PPVPNs. 510 4.2.7. Attacks on Address Space Separation 512 In Layer 3 VPNs, the IP address spaces of different VPNs need to be 513 kept separate. In Layer 2 VPNs, the MAC address and VLAN spaces of 514 different VPNs need to be kept separate. A control plane breach in 515 this addressing separation may result in unauthorized data plane 516 cross-connection between VPNs. 518 4.2.8. Other Attacks on PPVPN Control Traffic 520 Besides routing and management protocols (covered separately in the 521 previous sections) a number of other control protocols may be 522 directly involved in delivering the PPVPN service (e.g. for 523 membership discovery and tunnel establishment in various PPVPN 524 approaches). These include but may not be limited to: 526 - MPLS signaling (LDP, RSVP-TE) 527 - IPsec signaling (IKE) 528 - L2TP 529 - BGP-based membership discovery 530 - Database-based membership discovery (e.g. RADIUS-based) 532 Attacks might subvert or disrupt the activities of these protocols, 533 for example via impersonation or DOS attacks. 535 5. Defensive Techniques for PPVPN Service Providers 537 The defensive techniques discussed in this document are intended to 538 describe methods by which some security threats can be addressed. 539 They are not intended as requirements for all PPVPN 540 implementations. The PPVPN provider should determine the 541 applicability of these techniques to the provider's specific 542 service offerings, and the PPVPN user may wish to assess the value 543 of these techniques to the user's VPN requirements. 545 The techniques discussed here include encryption, authentication, 546 filtering, firewalls, access control, isolation, aggregation, and 547 other techniques. 549 Nothing is ever 100% secure. Defense therefore involves protecting 550 against those attacks that are most likely to occur and/or that 551 have the most dire consequences if successful. For those attacks 552 that are protected against, absolute protection is seldom 553 achievable; more often it is sufficient just to make the cost of a 554 successful attack greater than what the adversary will be willing 555 to expend. 557 Successfully defending against an attack does not necessarily mean 558 the attack must be prevented from happening or from reaching its 559 target. In many cases the network can instead be designed to 560 withstand the attack. For example, the introduction of non- 561 authentic packets could be defended against by preventing their 562 introduction in the first place, or by making it possible to 563 identify and eliminate them before delivery to the PPVPN user's 564 system. The latter is frequently a much easier task. 566 5.1. Cryptographic techniques 568 PPVPN defenses against a wide variety of attacks can be enhanced by 569 the proper application of cryptographic techniques. These are the 570 same cryptographic techniques which are applicable to general 571 network communications. In general, these techniques can provide 572 confidentiality(encryption) of communication between devices, 573 authentication of the identities of the devices, and can ensure 574 that it will be detected if the data being communicated is changed 575 during transit. 577 Privacy is a key part (the middle name!) of any Virtual Private 578 Network. In a PPVPN, privacy can be provided by two mechanisms: 579 traffic separation and encryption. In this section we focus on 580 encryption, while traffic separation is addressed separately. 582 Several aspects of authentication are addressed in some detail in a 583 separate "Authentication" section. 585 Encryption adds complexity to a service, and thus it may not be a 586 standard offering within every PPVPN service. There are a few 587 reasons why encryption may not be a standard offering within every 588 PPVPN service. Encryption adds an additional computational burden 589 to the devices performing encryption and decryption. This may 590 reduce the number of user VPN connections which can be handled on a 591 device or otherwise reduce the capacity of the device, potentially 592 driving up the provider's costs. Typically, configuring encryption 593 services on devices adds to the complexity of the device 594 configuration and adds incremental labor cost. Packet lengths are 595 typically increased when the packets are encrypted, increasing the 596 network traffic load and adding to the likelihood of packet 597 fragmentation with its increased overhead. (This packet length 598 increase can often be mitigated to some extent by data compression 599 techniques, but at the expense of additional computational burden.) 600 Finally, some PPVPN providers may employ enough other defensive 601 techniques, such as physical isolation or filtering/firewall 602 techniques, that they may not perceive additional benefit from 603 encryption techniques. 605 The trust model among the PPVPN user, the PPVPN provider, and other 606 parts of the network is a key element in determining the 607 applicability of encryption for any specific PPVPN implementation. 608 In particular, it determines where encryption should be applied: 609 - If the data path between the user's site and the provider's PE 610 is not trusted, then encryption may be used on the PE-CE link. 611 - If some part of the backbone network is not trusted, 612 particularly in implementations where traffic may travel across 613 the Internet or multiple provider networks, then the PE-PE 614 traffic may be encrypted. 615 - If the PPVPN user does not trust any zone outside of its 616 premises, it may require end-to-end or CE-CE encryption service. 617 This service fits within the scope of this PPVPN security 618 framework when the CE is provisioned by the PPVPN provider. 619 - If the PPVPN user requires remote access to a PPVPN from a 620 system at a location which is not a PPVPN customer location (for 621 example, access by a traveler) there may be a requirement for 622 encrypting the traffic between that system and an access point 623 on the PPVPN or at a customer site. If the PPVPN provider 624 provides the access point, then the customer must cooperate with 625 the provider to handle the access control services for the 626 remote users. These access control services are usually 627 implemented using encryption, as well. 629 Although CE-CE encryption provides confidentiality against third- 630 party interception, if the PPVPN provider has complete management 631 control over the CE (encryption) devices, then it may be possible 632 for the provider to gain access to the user's VPN traffic or 633 internal network. Encryption devices can potentially be configured 634 to use null encryption, bypass encryption processing altogether, or 635 provide some means of sniffing or diverting unencrypted traffic. 636 Thus a PPVPN implementation using CE-CE encryption needs to 637 consider the trust relationship between the PPVPN user and 638 provider. PPVPN users and providers may wish to negotiate a service 639 level agreement (SLA) for CE-CE encryption which will provide an 640 acceptable demarcation of responsibilities for management of 641 encryption on the CE devices. The demarcation may also be affected 642 by the capabilities of the CE devices. For example, the CE might 643 support some partitioning of management, a configuration lock-down 644 ability, or allow both parties to verify the configuration. In 645 general, the PPVPN user needs to have a fairly high level of trust 646 that the PPVPN provider will properly provision and manage the CE 647 devices, if the managed CE-CE model is used. 649 5.1.1. IPsec in PPVPNs 651 IPsec [RFC2401] [RFC2402] [RFC2406] [RFC2407] [RFC2411] is the 652 security protocol of choice for encryption at the IP layer (Layer 653 3), as discussed in [SECMECH]. IPsec provides robust security for 654 IP traffic between pairs of devices. Non-IP traffic must be 655 converted to IP packets or it cannot be transported over IPsec. 656 Encapsulation is a common conversion method. 658 In the PPVPN model, IPsec can be employed to protect IP traffic 659 between PEs, between a PE and a CE, or from CE to CE. CE-to-CE 660 IPsec may be employed in either a provider-provisioned or a user- 661 provisioned model. The user-provisioned CE-CE IPsec model is 662 outside the scope of this document, and outside the scope of the 663 PPVPN Working Group. Likewise, encryption of data which is 664 performed within the user's site is outside the scope of this 665 document, since it is simply handled as user data by the PPVPN. 666 IPsec can also be used to protect IP traffic between a remote user 667 who is not located at a PPVPN site and the PPVPN. 669 IPsec does not itself specify an encryption algorithm. It can use 670 a variety of encryption algorithms, with various key lengths, such 671 as AES encryption. There are trade-offs between key length, 672 computational burden, and the level of security of the encryption. 673 A full discussion of these trade-offs is beyond the scope of this 674 document. In order to assess the level of security offered by a 675 particular IPsec-based PPVPN service, some PPVPN users may wish to 676 know the specific encryption algorithm and effective key length 677 used by the PPVPN provider. However, in practice, any currently 678 recommended IPsec encryption offers enough security to 679 substantially reduce the likelihood of being directly targeted by 680 an attacker; other weaker links in the chain of security are likely 681 to be attacked first. PPVPN users may wish to use a Service Level 682 Agreement (SLA) specifying the Service Provider's responsibility 683 for ensuring data confidentiality, rather than analyzing the 684 specific encryption techniques used in the PPVPN service. 686 For many of the PPVPN provider's network control messages and some 687 PPVPN user requirements, cryptographic authentication of messages 688 without encryption of the contents of the message may provide 689 acceptable security. Using IPsec, authentication of messages is 690 provided by the Authentication Header (AH) or through the use of 691 the Encapsulating Security Protocol (ESP) with authentication only. 692 Where control messages require authentication but do not use IPsec, 693 then other cryptographic authentication methods are available. 694 Message authentication methods currently considered to be secure 695 are based on hashed message authentication codes (HMAC) [RFC2104] 696 implemented with a secure hash algorithm such as Secure Hash 697 Algorithm 1 (SHA-1) [RFC3174]. 699 One recommended mechanism to provide a combination confidentiality, 700 data origin authentication, and connectionless integrity is the use 701 of AES in Cipher Block Chaining (CBC) Mode, with an explicit 702 Initialization Vector (IV) [RFC-3602], as the IPsec ESP. 704 PPVPNs which provide differentiated services based on traffic type 705 may encounter some conflicts with IPsec encryption of traffic. 706 Since encryption hides the content of the packets, it may not be 707 possible to differentiate the encrypted traffic in the same manner 708 as unencrypted traffic. Although DiffServ markings are copied to 709 the IPsec header and can provide some differentiation, not all 710 traffic types can be accommodated by this mechanism. 712 5.1.2. Encryption for device configuration and management 714 For configuration and management of PPVPN devices, encryption and 715 authentication of the management connection at a level comparable 716 to that provided by IPsec is desirable. 718 Several methods of transporting PPVPN device management traffic 719 offer security and confidentiality. 720 - Secure Shell (SSH) offers protection for TELNET [STD-8] or 721 terminal-like connections to allow device configuration. 722 - SNMP v3 [STD62] provides encrypted and authenticated protection 723 for SNMP-managed devices. 724 - Transport Layer Security (TLS) [RFC-2246] and the closely- 725 related Secure Sockets Layer (SSL) are widely used for securing 726 HTTP-based communication, and thus can provide support for most 727 XML- and SOAP-based device management approaches. 728 - As of 2004, there is extensive work proceeding in several 729 organizations (OASIS, W3C, WS-I, and others) on securing device 730 management traffic within a "Web Services" framework, using a 731 wide variety of security models, and providing support for 732 multiple security token formats, multiple trust domains, 733 multiple signature formats, and multiple encryption 734 technologies. 736 - IPsec provides the services with security and confidentiality at 737 the network layer. With regards to device management, its 738 current use is primarily focused on in-band management of user- 739 managed IPsec gateway devices. 741 5.1.3. Cryptographic techniques in Layer 2 PPVPNs 743 Layer 2 PPVPNs will generally not be able to use IPsec to provide 744 encryption throughout the entire network. They may be able to use 745 IPsec for PE-PE traffic where it is encapsulated in IP packets, but 746 IPsec will generally not be applicable for CE-PE traffic in Layer 2 747 PPVPNs. 749 Encryption techniques for Layer 2 links are widely available, but 750 are not within the scope of this document, nor of IETF documents in 751 general. Layer 2 encryption could be applied to the links from CE 752 to PE, or could be applied from CE to CE, as long as the encrypted 753 Layer 2 packets can be properly handled by the intervening PE 754 devices. In addition, the upper layer traffic transported by the 755 Layer 2 VPN can be encrypted by the user. In this case 756 confidentiality will be maintained; however, this is transparent 757 to the PPVPN provider and is outside the scope of this document. 759 5.1.4. End-to-end vs. hop-by-hop encryption tradeoffs in PPVPNs 761 In PPVPNs, encryption could potentially be applied to the VPN 762 traffic at several different places. This section discusses some 763 of the tradeoffs in implementing encryption in several different 764 connection topologies among different devices within a PPVPN. 766 Encryption typically involves a pair of devices which encrypt the 767 traffic passing between them. The devices may be directly 768 connected (over a single "hop"), or there may be intervening 769 devices which transport the encrypted traffic between the pair of 770 devices. The extreme cases involve using encryption between every 771 adjacent pair of devices along a given path (hop-by-hop), or using 772 encryption only between the end devices along a given path (end-to- 773 end). To keep this discussion within the scope of PPVPNs, the 774 latter ("end-to-end") case considered here is CE-to-CE rather than 775 fully end-to-end. 777 Figure 2 depicts a simplified PPVPN topology showing the Customer 778 Edge (CE) devices, the Provider Edge (PE) devices, and a variable 779 number (three are shown) of Provider core (P) devices which might 780 be present along the path between two sites in a single VPN, 781 operated by a single service provider (SP). 783 Site_1---CE---PE---P---P---P---PE---CE---Site_2 785 Figure 2: Simplified PPVPN topology 787 Within this simplified topology, and assuming that P devices are 788 not to be involved with encryption, there are four basic feasible 789 configurations for implementing encryption on connections among the 790 devices: 792 1) Site-to-site (CE-to-CE) - Encryption can be configured between 793 the two CE devices, so that traffic will be encrypted throughout 794 the SP's network. 796 2) Provider edge-to-edge (PE-to-PE) - Encryption can be configured 797 between the two PE devices. Unencrypted traffic is received at one 798 PE from the customer's CE, then it is encrypted for transmission 799 through the SP's network to the other PE, where it is decrypted and 800 sent to the other CE. 802 3) Access link (CE-to-PE) - Encryption can be configured between 803 the CE and PE, on each side (or on only one side). 805 4) Configurations 2 and 3 above can also be combined, with 806 encryption running from CE to PE, then PE to PE, then PE to CE. 808 Among the four feasible configurations, key tradeoffs in 809 considering encryption include: 811 - Vulnerability to link eavesdropping - assuming an attacker can 812 observe the data in transit on the links, would it be protected 813 by encryption? 815 - Vulnerability to device compromise - assuming an attacker can get 816 access to a device (or freely alter its configuration), would the 817 data be protected? 819 - Complexity of device configuration and management - given the 820 number of sites per VPN customer as Nce and the number of PEs 821 participating in a given VPN as Npe, how many device configurations 822 need to be created or maintained, and how do those configurations 823 scale? 825 - Processing load on devices - how many encryption or decryption 826 operations must be done given P packets? - This influences 827 considerations of device capacity and perhaps end-to-end delay. 829 - Ability of SP to provide enhanced services (QoS, firewall, 830 intrusion detection, etc.) - Can the SP inspect the data in order 831 to provide these services? 832 These tradeoffs are discussed for each configuration, below: 834 1) Site-to-site (CE-to-CE) 836 Link eavesdropping - protected on all links 837 Device compromise - vulnerable to CE compromise 838 Complexity - single administration, responsible for one device per 839 site (Nce devices), but overall configuration per VPN scales as 840 Nce**2 841 Processing load - on each of two CEs, each packet is either 842 encrypted or decrypted (2P) 843 Enhanced services - severely limited; typically only Diffserv 844 markings are visible to SP, allowing some QoS services 846 2) Provider edge-to-edge (PE-to-PE) 848 Link eavesdropping - vulnerable on CE-PE links; protected on SP's 849 network links 850 Device compromise - vulnerable to CE or PE compromise 851 Complexity - single administration, Npe devices to configure. 852 (Multiple sites may share a PE device so Npe is typically much 853 less than Nce.) Scalability of the overall configuration 854 depends on the PPVPN type: If the encryption is separate per 855 VPN context, it scales as Npe**2 per customer VPN. If the 856 encryption is per-PE, it scales as Npe**2 for all customer VPNs 857 combined. 858 Processing load - on each of two PEs, each packet is either 859 encrypted or decrypted (2P) 860 Enhanced services - full; SP can apply any enhancements based on 861 detailed view of traffic 863 3) Access link (CE-to-PE) 865 Link eavesdropping - protected on CE-PE link; vulnerable on SP's 866 network links 867 Device compromise - vulnerable to CE or PE compromise 868 Complexity - two administrations (customer and SP) with device 869 configuration on each side (Nce + Npe devices to configure) but 870 since there is no mesh the overall configuration scales as Nce. 871 Processing load - on each of two CEs, each packet is either 872 encrypted or decrypted, plus on each of two PEs, each packet is 873 either encrypted or decrypted (4P) 874 Enhanced services - full; SP can apply any enhancements based on 875 detailed view of traffic 877 4) Combined Access link and PE-to-PE (essentially hop-by-hop) 879 Link eavesdropping - protected on all links 880 Device compromise - vulnerable to CE or PE compromise 881 Complexity - two administrations (customer and SP) with device 882 configuration on each side (Nce + Npe devices to configure). 884 Scalability of the overall configuration depends on the PPVPN 885 type: If the encryption is separate per VPN context, it scales 886 as Npe**2 per customer VPN. If the encryption is per-PE, it 887 scales as Npe**2 for all customer VPNs combined. 888 Processing load - on each of two CEs, each packet is either 889 encrypted or decrypted, plus on each of two PEs, each packet is 890 both encrypted and decrypted (6P) 891 Enhanced services - full; SP can apply any enhancements based on 892 detailed view of traffic 894 Given the tradeoffs discussed above, a few conclusions can be made: 896 - Configurations 2 and 3 are subsets of 4 that may be appropriate 897 alternatives to 4 under certain threat models; the remainder of 898 these conclusions compare 1 (CE-to-CE) vs. 4 (combined access links 899 and PE-to-PE). 901 - If protection from link eavesdropping is most important, then 902 configurations 1 and 4 are equivalent. 904 - If protection from device compromise is most important and the 905 threat is to the CE devices, both cases are equivalent; if the 906 threat is to the PE devices, configuration 1 is best. 908 - If reducing complexity is most important, and the size of the 909 network is very small, configuration 1 is the best. Otherwise the 910 comparison between option 1 and option 4 is relatively complex 911 based on a number of issues such as: How close the CE to CE 912 communication is to a full mesh; and what tools are used for key 913 management. Option 1 requires configuring keys for each CE-CE pair 914 that is directly communicating. Option 4 requires configuring keys 915 on both CE and PE devices, but may benefit from the fact that the 916 number of PEs is generally much smaller than the number of 917 CEs. Also under some PPVPN approaches the scaling of 4 is further 918 improved by sharing the same PE-PE mesh across all VPN contexts. 919 The scaling characteristics of 4 may be increased or decreased in 920 any given situation if the CE devices are simpler to configure than 921 the PE devices, or vice- versa. Furthermore, with option 4, the 922 impact of operational error may be significantly increased. 924 - If the overall processing load is a key factor, then 1 is best. 926 - If the availability of enhanced services support from the SP is 927 most important, then 4 is best. 929 As a quick overall conclusion, CE-to-CE encryption provides greater 930 protection against device compromise but this comes at the cost of 931 enhanced services and at the cost of operational complexity due to 932 the Order(n**2) scaling of a larger mesh. 934 This analysis of site-to-site vs. hop-by-hop encryption tradeoffs 935 does not explicitly include cases of multiple providers cooperating 936 to provide a PPVPN service, public Internet VPN connectivity, or 937 remote access VPN service, but many of the tradeoffs will be 938 similar. 940 5.2. Authentication 942 In order to prevent security issues from some Denial-of-Service 943 attacks or from malicious misconfiguration, it is critical that 944 devices in the PPVPN should only accept connections or control 945 messages from valid sources. Authentication refers to methods to 946 ensure that message sources are properly identified by the PPVPN 947 devices with which they communicate. This section focuses on 948 identifying the scenarios in which sender authentication is 949 required, and recommends authentication mechanisms for these 950 scenarios. 952 Cryptographic techniques (authentication and encryption) do not 953 protect against some types of denial of service attacks, 954 specifically resource exhaustion attacks based on CPU or bandwidth 955 exhaustion. In fact, the processing required to decrypt and/or 956 check authentication may in some cases increase the effect of these 957 resource exhaustion attacks. Cryptographic techniques may however, 958 be useful against resource exhaustion attacks based on exhaustion 959 of state information (e.g., TCP SYN attacks). 961 5.2.1. VPN Member Authentication 963 This category includes techniques for the CEs to verify they are 964 connected to the expected VPN. It includes techniques for CE-PE 965 authentication, to verify that each specific CE and PE is actually 966 communicating with its expected peer. 968 5.2.2. Management System Authentication 970 Management system authentication includes the authentication of a 971 PE to a centrally-managed directory server, when directory-based 972 "auto-discovery" is used. It also includes authentication of a CE 973 to its PPVPN configuration server, when a configuration server 974 system is used. 976 5.2.3. Peer-to-peer Authentication 978 Peer-to-peer authentication includes peer authentication for 979 network control protocols (e.g. LDP, BGP, etc.), and other peer 980 authentication (i.e. authentication of one IPsec security gateway 981 by another). 983 5.2.4. Authenticating Remote Access VPN members 985 This section describes methods for authentication of remote access 986 users connecting to a VPN. 988 Effective authentication of individual connections is a key 989 requirement for enabling remote access to a PPVPN from an arbitrary 990 Internet address (for instance, by a traveler). 992 There are several widely used standards-based protocols to support 993 remote access authentication. These include RADIUS [RFC2865] and 994 DIAMETER [RFC3588]. Digital certificate systems also provide 995 authentication. In addition there has been extensive development 996 and deployment of mechanisms for securely transporting individual 997 remote access connections within tunneling protocols, including 998 L2TP [RFC2661] and IPsec. 1000 Remote access involves connection to a gateway device, which 1001 provides access to the PPVPN. The gateway device may be managed by 1002 the user at a user site, or by the PPVPN provider at several 1003 possible locations in the network. The user-managed case is of 1004 limited interest within the PPVPN security framework, and is not 1005 considered at this time. 1007 When a PPVPN provider manages authentication at the remote access 1008 gateway, this implies that authentication databases, which are 1009 usually extremely confidential user-managed systems, will need to 1010 be referenced in a secure manner by the PPVPN provider. This can be 1011 accomplished by the use of proxy authentication services, which 1012 accept an encrypted authentication credential from the remote 1013 access user, pass it to the PPVPN user's authentication system, and 1014 receive a yes/no response as to whether the user has been 1015 authenticated. Thus the PPVPN provider does not have access to the 1016 actual authentication database, but can use it on behalf of the 1017 PPVPN user to provide remote access authentication. 1019 Specific cryptographic techniques for handling authentication are 1020 described in the following sections. 1022 5.2.5. Cryptographic techniques for authenticating identity 1024 Cryptographic techniques offer several mechanisms for 1025 authenticating the identity of devices or individuals. These 1026 include the use of shared secret keys, one-time keys generated by 1027 accessory devices or software, user-ID and password pairs, and a 1028 range of public-private key systems. Another approach is to use a 1029 hierarchical Certificate Authority system to provide digital 1030 certificates. 1032 This section describes or provides references to the specific 1033 cryptographic approaches for authenticating identity. These 1034 approaches provide secure mechanisms for most of the authentication 1035 scenarios required in operating a PPVPN. 1037 5.3. Access Control techniques 1039 Access control techniques include packet-by-packet or packet-flow- 1040 by-packet-flow access control by means of filters and firewalls, as 1041 well as by means of admitting a "session" for a 1042 control/signaling/management protocol that is being used to 1043 implement PPVPNs. Enforcement of access control by isolated 1044 infrastructure addresses is discussed in another section of this 1045 document. 1047 In this document, we distinguish between filtering and firewalls 1048 based primarily on the direction of traffic flow. We define 1049 filtering as being applicable to unidirectional traffic, while a 1050 firewall can analyze and control both sides of a conversation. 1052 There are two significant corollaries of this definition: 1053 - Routing or traffic flow symmetry: A firewall typically requires 1054 routing symmetry, which is usually enforced by locating a firewall 1055 where the network topology assures that both sides of a 1056 conversation will pass through the firewall. A filter can operate 1057 upon traffic flowing in one direction, without considering traffic 1058 in the reverse direction. 1059 - Statefulness: Since it receives both sides of a conversation, a 1060 firewall may be able to interpret a significant amount of 1061 information concerning the state of that conversation, and use this 1062 information to control access. A filter can maintain some limited 1063 state information on a unidirectional flow of packets, but cannot 1064 determine the state of the bi-directional conversation as precisely 1065 as a firewall. 1067 5.3.1. Filtering 1069 It is relatively common for routers to filter data packets. That 1070 is, routers can look for particular values in certain fields of the 1071 IP or higher level (e.g., TCP or UDP) headers. Packets which match 1072 the criteria associated with a particular filter may either be 1073 discarded or given special treatment. 1075 In discussing filters, it is useful to separate the Filter 1076 Characteristics which may be used to determine whether a packet 1077 matches a filter from the Packet Actions which are applied to those 1078 packets which match a particular filter. 1080 o Filter Characteristics 1081 Filter characteristics are used to determine whether a particular 1082 packet or set of packets matches a particular filter. 1084 In many cases filter characteristics may be stateless. A stateless 1085 filter is one which determines whether a particular packet matches 1086 a filter based solely on the filter definition, normal forwarding 1087 information (such as the next hop for a packet), and the 1088 characteristics of that individual packet. Typically stateless 1089 filters may consider the incoming and outgoing logical or physical 1090 interface, information in the IP header, and information in higher 1091 layer headers such as the TCP or UDP header. Information in the IP 1092 header to be considered may for example include source and 1093 destination IP address, Protocol field, Fragment Offset, and TOS 1094 field. Filters also may consider fields in the TCP or UDP header 1095 such as the Port fields as well as the SYN field in the TCP header. 1097 Stateful filtering maintains packet-specific state information, to 1098 aid in determining whether a filter has been met. For example, a 1099 device might apply stateless filters to the first fragment of a 1100 fragmented IP packet. If the filter matches, then the data unit ID 1101 may be remembered and other fragments of the same packet may then 1102 be considered to match the same filter. Stateful filtering is more 1103 commonly done in firewalls, although firewall technology may be 1104 added to routers. 1106 o Actions based on Filter Results 1108 If a packet, or a series of packets, match a specific filter, then 1109 there are a variety of actions which may be taken based on that 1110 filter match. Examples of such actions include: 1112 - Discard 1114 In many cases filters may be set to catch certain undesirable 1115 packets. Examples may include packets with forged or invalid source 1116 addresses, packets which are part of a DOS or DDOS attack, or 1117 packets which are trying to access resources which are not 1118 permitted (such as network management packets from an unauthorized 1119 source). Where such filters are activated, it is common to silently 1120 discard the packet or set of packets matching the filter. The 1121 discarded packets may of course also be counted and/or logged. 1123 - Set CoS 1125 A filter may be used to set the Class of Service associated with 1126 the packet. 1128 - Count packets and/or bytes 1130 - Rate Limit 1132 In some cases the set of packets which match a particular filter 1133 may be limited to a specified bandwidth. In this case packets 1134 and/or bytes would be counted, and would be forwarded normally up 1135 to the specified limit. Excess packets may be discarded, or may be 1136 marked (for example by setting a "discard eligible" bit in the IP 1137 ToS field or the MPLS EXP field). 1139 - Forward and Copy 1141 It is useful in some cases to forward some set of packets normally, 1142 but to also send a copy to a specified other address or interface. 1143 For example, this may be used to implement a lawful intercept 1144 capability, or to feed selected packets to an Intrusion Detection 1145 System. 1147 o Other Issues related to Use of Packet Filters 1149 There may be a very wide variation in the performance impact of 1150 filtering. This may occur both due to differences between 1151 implementations, and also due to differences between types or 1152 numbers of filters deployed. For filtering to be useful, the 1153 performance of the equipment has to be acceptable in the presence 1154 of filters. 1156 The precise definition of "acceptable" may vary from service 1157 provider to service provider, and may depend upon the intended use 1158 of the filters. For example, for some uses a filter may be turned 1159 on all the time in order to set CoS, to prevent an attack, or to 1160 mitigate the effect of a possible future attack. In this case it is 1161 likely that the service provider will want the filter to have 1162 minimal or no impact on performance. In other cases, a filter may 1163 be turned on only in response to a major attack (such as a major 1164 DDOS attack). In this case a greater performance impact may be 1165 acceptable to some service providers. 1167 A key consideration with the use of packet filters is that they can 1168 provide few options for filtering packets carrying encrypted data. 1169 Since the data itself is not accessible, only packet header 1170 information or other unencrypted fields can be used for filtering. 1172 5.3.2. Firewalls 1174 Firewalls provide a mechanism for control over traffic passing 1175 between different trusted zones in the PPVPN model, or between a 1176 trusted zone and an untrusted zone. Firewalls typically provide 1177 much more functionality than filters, since they may be able to 1178 apply detailed analysis and logical functions to flows, and not 1179 just to individual packets. They may offer a variety of complex 1180 services, such as threshold-driven denial-of-service attack 1181 protection, virus scanning, acting as a TCP connection proxy, etc. 1183 As with other access control techniques, the value of firewalls 1184 depends on a clear understanding of the topologies of the PPVPN 1185 core network, the user networks, and the threat model. Their 1186 effectiveness depends on a topology with a clearly defined inside 1187 (secure) and outside (not secure). 1189 Within the PPVPN framework, traffic typically is not allowed to 1190 pass between the various user VPNs. This inter-VPN isolation is 1191 usually not performed by a firewall, but is a part of the basic VPN 1192 mechanism. An exception to the total isolation of VPNs is the case 1193 of "extranets", which allow specific external access to a user's 1194 VPN, potentially from another VPN. Firewalls can be used to 1195 provide the services required for secure extranet implementation. 1197 In a PPVPN, firewalls can be applied between the public Internet 1198 and user VPNs, in cases where Internet access services are offered 1199 by the provider to the VPN user sites. In addition, firewalls may 1200 be applied between VPN user sites and any shared network-based 1201 services offered by the PPVPN provider. 1203 Firewalls may be applied to help protect PPVPN core network 1204 functions from attacks originating from the Internet or from PPVPN 1205 user sites, but typically other defensive techniques will be used 1206 for this purpose. 1208 Where firewalls are employed as a service to protect user VPN sites 1209 from the Internet, different VPN users, and even different sites of 1210 a single VPN user, may have varying firewall requirements. The 1211 overall PPVPN logical and physical topology, along with the 1212 capabilities of the devices implementing the firewall services, 1213 will have a significant effect on the feasibility and manageability 1214 of such varied firewall service offerings. 1216 Another consideration with the use of firewalls is that they can 1217 provide few options for handling packets carrying encrypted data. 1218 Since the data itself is not accessible, only packet header 1219 information, other unencrypted fields, or analysis of the flow of 1220 encrypted packets can be used for making decisions on accepting or 1221 rejecting encrypted traffic. 1223 5.3.3. Access Control to management interfaces 1225 Most of the security issues related to management interfaces can be 1226 addressed through the use of authentication techniques as described 1227 in the section on authentication. However, additional security may 1228 be provided by controlling access to management interfaces in other 1229 ways. 1231 Management interfaces, especially console ports on PPVPN devices, 1232 may be configured so they are only accessible out-of-band, through 1233 a system which is physically and/or logically separated from the 1234 rest of the PPVPN infrastructure. 1236 Where management interfaces are accessible in-band within the PPVPN 1237 domain, filtering or firewalling techniques can be used to restrict 1238 unauthorized in-band traffic from having access to management 1239 interfaces. Depending on device capabilities, these filtering or 1240 firewalling techniques can be configured either on other devices 1241 through which the traffic might pass, or on the individual PPVPN 1242 devices themselves. 1244 5.4. Use of Isolated Infrastructure 1246 One way to protect the infrastructure used for support of VPNs is 1247 to separate the resources for support of VPNs from the resources 1248 used for other purposes (such as support of Internet services). In 1249 some cases this may make use of physically separate equipment for 1250 VPN services, or even a physically separate network. 1252 For example, PE-based L3 VPNs may be run on a separate backbone not 1253 connected to the Internet, or may make use of separate edge routers 1254 from those used to support Internet service. Private IP addresses 1255 (local to the provider and non-routable over the Internet) are 1256 sometimes used to provide additional separation. 1258 It is common for CE-based L3VPNs to make use of CE devices which 1259 are dedicated to one specific VPN. In many or most cases CE-based 1260 VPNs may make use of normal Internet services to interconnect CE 1261 devices. 1263 5.5. Use of Aggregated Infrastructure 1265 In general it is not feasible to use a completely separate set of 1266 resources for support of each VPN. In fact, one of the main reasons 1267 for VPN services is to allow sharing of resources between multiple 1268 users, including multiple VPNs. Thus even if VPN services make use 1269 of a separate network from Internet services, nonetheless there 1270 will still be multiple VPN users sharing the same network 1271 resources. In some cases VPN services will share the use of network 1272 resources with Internet services or other services. 1274 It is therefore important for VPN services to provide protection 1275 between resource utilization by different VPNs. Thus a well-behaved 1276 VPN user should be protected from possible misbehavior by other 1277 VPNs. This requires that limits are placed on the amount of 1278 resources which can be used by any one VPN. For example, both 1279 control traffic and user data traffic may be rate limited. In some 1280 cases or in some parts of the network where a sufficiently large 1281 number of queues are available each VPN (and optionally each VPN 1282 and CoS within the VPN) may make use of a separate queue. Control- 1283 plane resources such as link bandwidth as well as CPU and memory 1284 resources may be reserved on a per-VPN basis. 1286 The techniques which are used to provision resource protection 1287 between multiple VPNs served by the same infrastructure can also be 1288 used to protect VPN services from Internet services. 1290 In general the use of aggregated infrastructure allows the service 1291 provider to benefit from stochastic multiplexing of multiple bursty 1292 flows, and also may in some cases thwart traffic pattern analysis 1293 by combining the data from multiple VPNs. 1295 5.6. Service Provider Quality Control Processes 1297 Deployment of provider-provisioned VPN services in general requires 1298 a relatively large amount of configuration by the service provider. 1299 For example, the service provider needs to configure which VPN each 1300 site belongs to, as well as QoS and SLA guarantees. This large 1301 amount of required configuration leads to the possibility of 1302 misconfiguration. 1304 It is important for the service provider to have operational 1305 processes in place to reduce the potential impact of 1306 misconfiguration. CE to CE authentication may also be used to 1307 detect misconfiguration when it occurs. 1309 5.7. Deployment of Testable PPVPN Service. 1311 This refers to solutions that can be readily tested to make sure 1312 they are configured correctly. E.g. for a point-point VPN, 1313 checking that the intended connectivity is working pretty much 1314 ensures that there is not connectivity to some unintended site. 1316 6. Monitoring, Detection, and Reporting of Security Attacks 1318 A PPVPN service may be subject to attacks from a variety of 1319 security threats. Many threats are described in another part of 1320 this document. Many of the defensive techniques described in this 1321 document and elsewhere provide significant levels of protection 1322 from a variety of threats. However, in addition to silently 1323 employing defensive techniques to protect against attacks, PPVPN 1324 services can also add value for both providers and customers by 1325 implementing security monitoring systems which detect and report on 1326 any security attacks which occur, regardless of whether the attacks 1327 are effective. 1329 Attackers often begin by probing and analyzing defenses, so systems 1330 which can detect and properly report these early stages of attacks 1331 can provide significant benefits. 1333 Information concerning attack incidents, especially if available 1334 quickly, can be useful in defending against further attacks. It 1335 can be used to help identify attackers and/or their specific 1336 targets at an early stage. This knowledge about attackers and 1337 targets can be used to further strengthen defenses against specific 1338 attacks or attackers, or improve the defensive services for 1339 specific targets on an as-needed basis. Information collected on 1340 attacks may also be useful in identifying and developing defenses 1341 against novel attack types. 1343 Monitoring systems used to detect security attacks in PPVPNs will 1344 typically operate by collecting information from the Provider Edge 1345 (PE), Customer Edge (CE), and/or Provider backbone (P) devices. 1346 Security monitoring systems should have the ability to actively 1347 retrieve information from devices (e.g., SNMP get) or to passively 1348 receive reports from devices (e.g., SNMP notifications). The 1349 specific information exchanged will depend on the capabilities of 1350 the devices and on the type of VPN technology. Particular care 1351 should be given to securing the communications channel between the 1352 monitoring systems and the PPVPN devices. 1354 The CE, PE, and P devices should employ efficient methods to 1355 acquire and communicate the information needed by the security 1356 monitoring systems. It is important that the communication method 1357 between PPVPN devices and security monitoring systems be designed 1358 so that it will not disrupt network operations. As an example, 1359 multiple attack events may be reported through a single message, 1360 rather than allowing each attack event to trigger a separate 1361 message, which might result in a flood of messages, essentially 1362 becoming a denial-of-service attack against the monitoring system 1363 or the network. 1365 The mechanisms for reporting security attacks should be flexible 1366 enough to meet the needs of VPN service providers, VPN customers, 1367 and regulatory agencies, if applicable. The specific reports will 1368 depend on the capabilities of the devices, the security monitoring 1369 system, the type of VPN, and the service level agreements between 1370 the provider and customer. 1372 7. User Security Requirements 1374 This section defines a list of security related requirements that 1375 the users of PPVPN services may have for their PPVPN service. 1376 Typically, these user requirements translate into requirement for 1377 the provider in offering the service. 1379 The following sections detail various requirements that ensure the 1380 security of a given trusted zone. Since in real life there are 1381 various levels of security, a PPVPN may fulfill any number or all 1382 of these security requirements. Specifically this document does not 1383 state that a PPVPN must fulfill all of these requirements to be 1384 secure. As mentioned in the Introduction, it is not within the 1385 scope of this document to define the specific requirements that 1386 each VPN technology must fulfill in order to be secure. 1388 7.1. Isolation 1390 A virtual private network usually defines the "private" as being 1391 isolated from other PPVPNs and the Internet. More specifically, 1392 isolation has several components: 1394 7.1.1. Address Separation 1396 A given PPVPN can use the full Internet address range, 1397 including private address ranges [RFC1918], without 1398 interfering with other PPVPNs that use PPVPN services from 1399 the same service provider(s). When Internet access is 1400 provided, e.g. by the same service provider that is offering 1401 PPVPN service, a NAT functionality may be needed. 1403 In layer 2 VPNs the same requirement exists for the layer 2 1404 addressing schemes, such as MAC addresses. 1406 7.1.2. Routing Separation 1408 A PPVPN core must maintain routing separation between the trusted 1409 zones. This means that routing information must not leak from any 1410 trusted zone to any other trusted zone, unless this is specifically 1411 engineered this way, for example for Internet access. 1413 In layer 2 VPNs the switching information must be kept separate 1414 between the trusted zones, such that switching information of one 1415 PPVPN does not influence other PPVPNs or the PPVPN core. 1417 7.1.3. Traffic Separation 1419 Traffic from a given trusted zone must never leave this zone, and 1420 traffic from another zone must never enter this zone. Exceptions 1421 are where this is specifically engineered that way, for example for 1422 extranet purposes or Internet access. 1424 7.2. Protection 1426 The perception is that a completely separated "private" network 1427 has defined entry points, and is only subject to attack or 1428 intrusion over those entry points. By sharing a common core a PPVPN 1429 appears to lose some of this clear interfaces to parts outside the 1430 trusted zone. Thus one of the key security requirements of PPVPN 1431 services is that they offer the same level of protection as private 1432 networks. 1434 7.2.1. Protection against intrusion 1436 An intrusion is defined here as the penetration of a trusted zone 1437 from outside this zone. This could be from the Internet, another 1438 PPVPN, or the core network itself. 1440 The fact that a network is "virtual" must not expose it to 1441 additional threats over private networks. Specifically, it must not 1442 add new interfaces to other parts outside the trusted zone. 1443 Intrusions from known interfaces such as Internet gateways are 1444 outside the scope of this document. 1446 7.2.2. Protection against Denial of Service attacks 1448 A denial of service attack aims at making services or devices un- 1449 available to legitimate users. In the framework of this document 1450 only those DoS attacks are considered which are a consequence of 1451 providing the network in a virtual way. DoS attacks over the 1452 standard interfaces into a trusted zone are not considered here. 1454 The requirement is that a PPVPN is not more vulnerable against DoS 1455 attacks than if the same network would be private. 1457 7.2.3. Protection against spoofing 1459 It is not possible to change the sender identification (source 1460 address, source label, etc) of traffic in transit, such that by 1461 this spoofing the integrity of a PPVPN gets violated. For example, 1462 if two CEs are connected to the same PE, it must not be possible 1463 for one CE to send crafted packets that make the PE believe those 1464 packets are coming from the other CE, thus inserting them into the 1465 wrong PPVPN. 1467 7.3. Confidentiality 1469 This requirement means that data must be cryptographically secured 1470 in transit over the PPVPN core network to avoid eavesdropping. 1472 7.4. CE Authentication 1474 Where CE authentication is provided it is not possible for an 1475 outsider to install a CE and pretend to belong to a specific PPVPN, 1476 to which this CE does not belong in reality. 1478 7.5. Integrity 1479 Data in transit must be secured in a manner such that it cannot be 1480 altered, or that any alteration may be detected at the receiver. 1482 7.6. Anti-Replay 1484 Anti-replay means that data in transit cannot be recorded and 1485 replayed later. To protect against anti-replay attacks the data 1486 must be cryptographically secured. 1488 Note: Even private networks do not necessarily meet the 1489 requirements of confidentiality, integrity and anti-reply. Thus 1490 when comparing private to "virtually private" PPVPN services these 1491 requirements are only applicable if the comparable private service 1492 also included these services. However, the fact that VPNs operate 1493 over a shared infrastructure may make some of these requirements 1494 more important in a VPN environment when compared with a private 1495 network environment. 1497 8. Provider Security Requirements 1499 In this section, we discuss additional security requirements that 1500 the provider may have in order to secure its network infrastructure 1501 as it provides PPVPN services. 1503 The PPVPN service provider requirements defined here are the 1504 requirements for the PPVPN core in the reference model. The core 1505 network can be implemented with different types of network 1506 technologies, and each core network may use different technologies 1507 to provide the PPVPN services to users with different levels of 1508 offered security. Therefore, a PPVPN service provider may fulfill 1509 any number of the security requirements listed in this section. 1510 This document does not state that a PPVPN must fulfill all of these 1511 requirements to be secure. 1513 These requirements are focused on: 1) how to protect the PPVPN core 1514 from various attacks outside the core including PPVPN users and 1515 non-PPVPN alike, both accidentally and maliciously, 2) how to 1516 protect the PPVPN user VPNs and sites themselves. Note that a PPVPN 1517 core is not more vulnerable against attacks than a core that does 1518 not provide PPVPNs. However providing PPVPN services over such a 1519 core may need lead to additional security requirements, for the 1520 mere fact that most users are expecting higher security standards 1521 in a core delivering PPVPN services. 1523 8.1. Protection within the Core Network 1525 8.1.1. Control Plane Protection 1527 - Protocol authentication within the core: 1529 PPVPN technologies and infrastructure must support mechanisms for 1530 authentication of the control plane. For an IP core, IGP and BGP 1531 sessions may be authenticated by using TCP MD5 or IPsec. If an MPLS 1532 core is used, LDP sessions may be authenticated by use TCP MD5, in 1533 addition, IGP and BGP authentication should also be considered. For 1534 a core providing Layer 2 services, PE to PE authentication may also 1535 be used via IPsec. 1537 With the cost of authentication coming down rapidly, the 1538 application of control plane authentication may not increase the 1539 cost of implementation for providers significantly, and will help 1540 to improve the security of the core. If the core is dedicated to 1541 VPN services and without any interconnects to third parties then 1542 this may reduce the requirement for authentication of the core 1543 control plane. 1545 - Elements protection 1547 Here we discuss means to hide the provider's infrastructure nodes. 1549 A PPVPN provider may make the infrastructure routers (P and PE 1550 routers) unreachable from outside users and unauthorized internal 1551 users. For example, separate address space may be used for the 1552 infrastructure loopbacks. 1554 Normal TTL propagation may be altered to make the backbone look 1555 like one hop from the outside, but caution needs to be taken for 1556 loop prevention. This prevents the backbone addresses from being 1557 exposed through trace route, however this must also be assessed 1558 against operational requirements for end to end fault tracing. 1560 An Internet backbone core may be re-engineered to make Internet 1561 routing an edge function, for example, using MPLS label switching 1562 for all traffic within the core and possibly make the Internet a 1563 VPN within the PPVPN core itself. This helps to detach Internet 1564 access from PPVPN services. 1566 Separating control plane, data plane, and management plane 1567 functionality in terms of hardware and software may be implemented 1568 on the PE devices to improve security. This may help to limit the 1569 problems when attacked in one particular area, and may allow each 1570 plane to implement additional security measurement separately. 1572 PEs are often more vulnerable to attack than P routers, since PEs 1573 cannot be made unreachable to outside users by their very nature. 1574 Access to core trunk resources can be controlled on a per user 1575 basis by the application of inbound rate-limiting/shaping, this can 1576 be further enhanced on a per Class of Service basis (see section 1577 8.2.3) 1578 In the PE, using separate routing processes for Internet and PPVPN 1579 service may help to improve the PPVPN security and better protect 1580 VPN customers. Furthermore, if the resources, such as CPU and 1581 Memory, may be further separated based on applications, or even 1582 individual VPNs, it may help to provide improved security and 1583 reliability to individual VPN customers. 1585 Many of these were not particular issues when an IP core was 1586 designed to support Internet services only. When providing PPVPN 1587 services, new requirements are introduced to satisfy the security 1588 needs for VPN services. Similar consideration apply to L2 VPN 1589 services. 1591 8.1.2. Data Plane Protection 1593 PPVPN using IPsec technologies provide VPN users with encryption of 1594 secure user data. 1596 In today's MPLS, ATM, or Frame Relay networks, encryption is not 1597 provided as a basic feature. Mechanisms can be used to secure the 1598 MPLS data plane to secure the data carried over MPLS core. 1599 Additionally, if the core is dedicated to VPN services and without 1600 any external interconnects to third party networks then there is no 1601 obvious need for encryption of the user data plane. 1603 IPsec / L3 PPVPN technologies inter-working, or IPsec /L2 PPVPN 1604 technologies inter-working may be used to provide PPVPN users end- 1605 to-end PPVPN services. 1607 8.2. Protection on the User Access Link 1609 Peer / Neighbor protocol authentication may be used to enhance 1610 security. For example, BGP MD5 authentication may be used to 1611 enhance security on PE-CE links using eBGP. In the case of Inter- 1612 provider connection, authentication / encryption mechanisms between 1613 ASes, such as IPsec, may be used. 1615 WAN link address space separation for VPN and non-VPN users may be 1616 implemented to improve security in order to protect VPN customers 1617 if multiple services are provided on the same PE platform. 1619 Firewall / Filtering: access control mechanisms can be used to 1620 filter out any packets destined for the service provider's 1621 infrastructure prefix or eliminate routes identified as 1622 illegitimate routes. 1624 Rate limiting may be applied to the user interface/logical 1625 interfaces against DDOS bandwidth attack. This is very helpful when 1626 the PE device is supporting both VPN services and Internet 1627 Services, especially when supporting VPN and Internet Services on 1628 the same physical interfaces through different logical interfaces. 1630 8.2.1 Link Authentication 1632 Authentication mechanisms can be employed to validate site access 1633 to the PPVPN network via fixed or logical (e.g. L2TP, IPsec) 1634 connections. Where the user wishes to hold the 'secret' associated 1635 to acceptance of the access and site into the VPN, then PPVPN based 1636 solutions require the flexibility for either direct authentication 1637 by the PE itself or interaction with a customer PPVPN 1638 authentication server. Mechanisms are required in the latter case 1639 to ensure that the interaction between the PE and the customer 1640 authentication server is controlled e.g. limiting it simply to an 1641 exchange in relation to the authentication phase and with other 1642 attributes e.g. RADIUS optionally being filtered. 1644 8.2.2 Access Routing 1646 Mechanisms may be used to provide control at a routing protocol 1647 level e.g. RIP, OSPF, BGP between the CE and PE. Per neighbor and 1648 per VPN routing policies may be established to enhance security and 1649 reduce the impact of a malicious or non-malicious attack on the PE, 1650 in particular the following mechanisms should be considered: 1651 - Limiting the number of prefixes that may be advertised on a per 1652 access basis into the PE. Appropriate action may be taken should 1653 a limit be exceeded e.g. the PE shutting down the peer session 1654 to the CE 1655 - Applying route dampening at the PE on received routing updates 1656 - Definition of a per VPN prefix limit after which additional 1657 prefixes will not be added to the VPN routing table. 1659 In the case of Inter-provider connection, access protection, link 1660 authentication, and routing policies as described above may be 1661 applied. Both inbound and outbound firewall/filtering mechanism 1662 between ASes may be applied. Proper security procedures must be 1663 implemented in Inter-provider VPN interconnection to protect the 1664 providers' network infrastructure and their customer VPNs. This may 1665 be custom designed for each Inter-Provider VPN peering connection, 1666 and must be agreed by both providers. 1668 8.2.3 Access QoS 1670 PPVPN providers offering QoS enabled services require mechanisms to 1671 ensure that individual accesses are validated against their 1672 subscribed QOS profile and as such gain access to core resources 1673 that match their service profile. Mechanisms such as per Class of 1674 service rate limiting/traffic shaping on ingress to the PPVPN core 1675 are one option in providing this level of control. Such mechanisms 1676 may require the per Class of Service profile to be enforced either 1677 by marking, remarking or discard of traffic outside of profile. 1679 8.2.4 Customer VPN monitoring tools 1681 End users requiring visibility of VPN specific statistics on the 1682 core e.g. routing table, interface status, QoS statistics, impose 1683 requirements for mechanisms at the PE to both validate the incoming 1684 user and limit the views available to that particular users VPN. 1685 Mechanisms should also be considered to ensure that such access 1686 cannot be used a means of a DOS attack (either malicious or 1687 accidental) on the PE itself. This could be accomplished through 1688 either separation of these resources within the PE itself or via 1689 the capability to rate-limit on a per VPN basis such traffic. 1691 8.3. General Requirements for PPVPN Providers 1693 The PPVPN providers must support the users' security requirements 1694 as listed in Section 7. Depending on the technologies used, these 1695 requirements may include: 1697 - User control plane separation - routing isolation 1698 - User address space separation - supporting overlapping addresses 1699 from different VPNs 1700 - User data plane separation - one VPN traffic cannot be 1701 intercepted by other VPNs or any other users. 1702 - Protection against intrusion, DOS attacks and spoofing 1703 - Access Authentication 1704 - Techniques highlighted through this document identify 1705 methodologies for the protection of PPVPN resources and 1706 infrastructure. 1708 Equipment hardware/software bugs leading to breaches in security 1709 are not within the scope of this document. 1711 9. Security Evaluation of PPVPN Technologies 1713 This section presents a brief template that may be used to evaluate 1714 and summarize how a given PPVPN approach (solution) measures up 1715 against the PPVPN Security Framework. An evaluation of a given 1716 PPVPN approach using this template should appear in the 1717 applicability statement for each PPVPN approach. 1719 9.1. Evaluating the Template 1720 The first part of the template is in the form of a list of security 1721 assertions. For each assertion the approach is assessed and one or 1722 more of the following ratings is assigned: 1724 - The requirement is not applicable to the VPN approach because ... 1725 (fill in reason) 1727 - The base VPN approach completely addresses the requirement by ... 1728 (fill in technique) 1730 - The base VPN approach partially addresses the requirement by ... 1731 (fill in technique and extent to which it addresses the 1732 requirement) 1734 - An optional extension to the VPN approach completely addresses 1735 the requirement by ... (fill in technique) 1737 - An optional extension to the VPN approach partially addresses the 1738 requirement by ... (fill in technique and extent to which it 1739 addresses the requirement) 1741 - In the VPN approach, the requirement is addressed in a way that 1742 is beyond the scope of the VPN approach. (Explain) (One 1743 example of this would be a VPN approach in which some aspect, 1744 say membership discovery, is done via configuration. The 1745 protection afforded to the configuration would be beyond the 1746 scope of the VPN approach.) 1748 - The VPN approach does not meet the requirement. 1750 9.2. Template 1752 The following assertions solicit responses of the types listed in 1753 the previous section. 1755 1. The approach provides complete IP address space separation for 1756 each L3 VPN. 1758 2. The approach provides complete L2 address space separation for 1759 each L2 VPN. 1761 3. The approach provides complete VLAN ID space separation for each 1762 L2 VPN. 1764 4. The approach provides complete IP route separation for each L3 1765 VPN. 1767 5. The approach provides complete L2 forwarding separation for each 1768 L2 VPN. 1770 6. The approach provides a means to prevent improper cross- 1771 connection of sites in separate VPNs. 1773 7. The approach provides a means to detect improper cross- 1774 connection of sites in separate VPNs. 1776 8. The approach protects against the introduction of unauthorized 1777 packets into each VPN. 1779 a. In the CE-PE link 1780 b. In a single- or multi- provider PPVPN backbone 1781 c. In the Internet used as PPVPN backbone 1783 9. The approach provides confidentiality (secrecy) protection for 1784 PPVPN user data. 1786 a. In the CE-PE link 1787 b. In a single- or multi- provider PPVPN backbone 1788 c. In the Internet used as PPVPN backbone 1790 10. The approach provides sender authentication for PPVPN user 1791 data. 1793 a. In the CE-PE link 1794 b. In a single- or multi- provider PPVPN backbone 1795 c. In the Internet used as PPVPN backbone 1797 11. The approach provides integrity protection for PPVPN user data. 1799 a. In the CE-PE link 1800 b. In a single- or multi- provider PPVPN backbone 1801 c. In the Internet used as PPVPN backbone 1803 12. The approach provides protection against replay attacks for 1804 PPVPN user data. 1806 a. In the CE-PE link 1807 b. In a single- or multi- provider PPVPN backbone 1808 c. In the Internet used as PPVPN backbone 1810 13. The approach provides protection against unauthorized traffic 1811 pattern analysis for PPVPN user data. 1813 a. In the CE-PE link 1814 b. In a single- or multi- provider PPVPN backbone 1815 c. In the Internet used as PPVPN backbone 1817 14. The control protocol(s) used for each of the following 1818 functions provide for message integrity and peer authentication: 1820 a. VPN membership discovery 1821 b. Tunnel establishment 1822 c. VPN topology and reachability advertisement 1823 i. PE-PE 1824 ii. PE-CE 1825 d. VPN provisioning and management 1826 e. VPN monitoring and attack detection and reporting 1827 f. Other VPN-specific control protocols, if any. (list) 1829 The following questions solicit free-form answers. 1831 15. Describe the protection, if any, the approach provides against 1832 PPVPN-specific DOS attacks (i.e. Inter-trusted-zone DOS 1833 attacks): 1835 a. Protection of the service provider infrastructure against 1836 Data Plane or Control Plane DOS attacks originated in a 1837 private (PPVPN user) network and aimed at PPVPN mechanisms. 1838 b. Protection of the service provider infrastructure against 1839 Data Plane or Control Plane DOS attacks originated in the 1840 Internet and aimed at PPVPN mechanisms. 1841 c. Protection of PPVPN users against Data Plane or Control Plane 1842 DOS attacks originated from the Internet or from other PPVPN 1843 users and aimed at PPVPN mechanisms. 1845 16. Describe the protection, if any, the approach provides against 1846 unstable or malicious operation of a PPVPN user network: 1848 a. Protection against high levels of, or malicious design of, 1849 routing traffic from PPVPN user networks to the service 1850 provider network. 1851 b. Protection against high levels of, or malicious design of, 1852 network management traffic from PPVPN user networks to the 1853 service provider network. 1854 c. Protection against worms and probes originated in the PPVPN 1855 user networks, sent towards the service provider network. 1857 17. Is the approach subject to any approach-specific 1858 vulnerabilities not specifically addressed by this template? If 1859 so describe the defense or mitigation, if any, the approach 1860 provides for each. 1862 10. Security Considerations 1864 Security considerations constitute the sole subject of this memo 1865 and hence are discussed throughout. Here we recap what has been 1866 presented and explain at a very high level the role of each type of 1867 consideration in an overall secure PPVPN system. 1869 The document describes a number of potential security threats. 1870 Some of these threats have already been observed occurring in 1871 running networks; others are largely theoretical at this time. DOS 1872 attacks and intrusion 1873 attacks from the Internet against service provider infrastructure 1874 have been seen to occur. DOS "attacks" (typically not malicious) 1875 have also been seen in which CE equipment overwhelms PE equipment 1876 with high quantities or rates of packet traffic or routing 1877 information. Operational/provisioning errors are cited by service 1878 providers as one of their prime concerns. 1880 The document describes a variety of defensive techniques that may 1881 be used to counter the suspected threats. All of the techniques 1882 presented involve mature and widely implemented technologies that 1883 are practical to implement. 1885 The document describes the importance of detecting, monitoring, and 1886 reporting attacks, both successful and unsuccessful. These 1887 activities are essential for "understanding one's enemy", 1888 mobilizing new defenses, and obtaining metrics about how secure the 1889 PPVPN service is. As such they are vital components of any 1890 complete PPVPN security system. 1892 The document evaluates PPVPN security requirements from a customer 1893 perspective as well as from a service provider perspective. These 1894 sections re-evaluate the identified threats from the perspectives 1895 of the various stakeholders and are meant to assist equipment 1896 vendors and service providers, who must ultimately decide what 1897 threats to protect against in any given equipment or service 1898 offering. 1900 Finally, the document includes a template for use by authors of 1901 PPVPN technical solutions for evaluating how those solutions 1902 measure up against the security considerations presented in this 1903 memo. 1905 11. IANA Considerations 1906 This document has no actions for IANA. 1908 12. Acknowledgement 1910 The authors would also like to acknowledge the helpful comments and 1911 suggestions from Paul Hoffman, Eric Gray, Ron Bonica, Chris Chase, 1912 Jerry Ash, Stewart Bryant. 1914 13. Normative References 1916 [RFC2246] T. Dierks and C. Allen, "The TLS Protocol Version 1.0", 1917 RFC 2246, January 1999. 1919 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the 1920 Internet Protocol," November 1998. 1922 [RFC2402] S. Kent, R. Atkinson, "IP Authentication Header," 1923 November 1924 1998. 1926 [RFC2406] S. Kent, R. Atkinson, "IP Encapsulating Security Payload 1927 (ESP)," November 1998. 1929 [RFC2407] D. Piper, "The Internet IP Security Domain of 1930 Interpretation for ISAKMP," November 1998. 1932 [RFC2661] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer 1933 Two Tunneling Protocol", RFC 2661, June 1999. 1935 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1936 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, 1937 June 2000. 1939 [RFC3588] P. Calhoun, J. Loughney, J. Arkko, E. Guttman, G. Zorn. 1940 "Diameter Base Protocol", RFC 3588, September 2003. 1942 [RFC3602] S. Frankel, R. Glenn, S. Kelley, "The AES-CBC Cipher 1943 Algorithm and its Use with IPsec," RFC 3602, September 2003. 1945 [STD62] "Simple Network Management Protocol, Version 3," RFCs 3411- 1946 3418, December 2002. 1948 [STD8] J. Postel and J. Reynolds, "TELNET Protocol Specification", 1949 STD 8, May 1983. 1951 14. Informational References 1953 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 1954 Requirement Levels", BCP 14, RFC 2119, March 1997 1956 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1957 for Message Authentication," February 1997. 1959 [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 1960 Roadmap," November 1998. 1962 [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 1963 1 (SHA1)," September 2001. 1965 [RFC8631] S. Bellovin, C. Kaufman, J. Schiller, "Security 1966 Mechanisms for the Internet," December 2003. 1968 [L3VPN-FW] R. Callon and M. Suzuki, "A Framework for Layer 3 1969 Provider Provisioned Virtual Private Networks", draft-ietf-l3vpn- 1970 framework-00.txt, March 2003. 1972 [L3VPN-REQ]M. Carugi and D. McDysan, "Service requirements for 1973 Layer 3 Virtual Private Networks�, draft-ietf-l3vpn-requirements- 1974 01.txt, June 2004. 1976 [RPSEC] A. Barbir, S. Murphy, and Y. Yang, "Generic Threats to 1977 Routing Protocols," draft-ietf-rpsec-routing-threats-07.txt, 1978 October 2004. 1980 15. Author's Addresses 1982 Luyuan Fang 1983 AT&T 1984 200 Laurel Avenue, Room C2-3B35 Phone: 732-420-1921 1985 Middletown, NJ 07748 Email: luyuanfang@att.com 1987 Michael Behringer 1988 Cisco 1989 Village d'Entreprises Green Side, Phone: +33.49723-2652 1990 400, Avenue Roumanille, Bat. T 3 Email: mbehring@cisco.com 1991 06410 Biot, Sophia Antipolis 1992 France 1994 Ross Callon 1995 Juniper Networks 1996 10 Technology Park Drive Phone: 978-692-6724 1997 Westford, MA 01886 Email: rcallon@juniper.net 1999 Fabio Chiussi Phone: 508-624-0000 x203 2000 Invento Networks Email: fabio@inventonetworks.com 2001 377 Simarano Drive 2002 Marlborough, Massachusetts 01752 2004 Jeremy De Clercq 2005 Alcatel 2006 Fr. Wellesplein 1, 2018 Antwerpen E-mail: 2007 Belgium jeremy.de_clercq@alcatel.be 2008 Mark Duffy 2009 Quarry Technologies 2010 8 New England Executive Park Phone: 781-359-5052 2011 Burlington, MA 01803 Email: mduffy@quarrytech.com 2013 Paul Hitchen 2014 BT 2015 BT Adastral Park 2016 Martlesham Heath Phone: 44-1473-606-344 2017 Ipswich IP53RE Email: paul.hitchen@bt.com 2018 UK 2020 Paul Knight 2021 Nortel Networks 2022 600 Technology Park Drive Phone: 978-288-6414 2023 Billerica, MA 01821 Email: paul.knight@nortelnetworks.com 2025 Notices 2027 The IETF takes no position regarding the validity or scope of any 2028 Intellectual Property Rights or other rights that might be claimed 2029 to pertain to the implementation or use of the technology described 2030 in this document or the extent to which any license under such 2031 rights might or might not be available; nor does it represent that 2032 it has made any independent effort to identify any such rights. 2033 Information on the procedures with respect to rights in RFC 2034 documents can be found in BCP 78 and BCP 79. 2036 Copies of IPR disclosures made to the IETF Secretariat and any 2037 assurances of licenses to be made available, or the result of an 2038 attempt made to obtain a general license or permission for the use 2039 of such proprietary rights by implementers or users of this 2040 specification can be obtained from the IETF on-line IPR repository 2041 at http://www.ietf.org/ipr. 2043 The IETF invites any interested party to bring to its attention any 2044 copyrights, patents or patent applications, or other proprietary 2045 rights that may cover technology that may be required to implement 2046 this standard. Please address the information to the IETF at ietf- 2047 ipr@ietf.org. 2049 Copyright (C) The Internet Society (2004). This document is 2050 subject to the rights, licenses and restrictions contained in BCP 2051 78, and except as set forth therein, the authors retain all their 2052 rights. 2054 This document and the information contained herein are provided on 2055 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2056 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 2057 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 2058 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 2059 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 2060 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 2061 PARTICULAR PURPOSE.