idnits 2.17.1 draft-fang-mpls-gmpls-security-framework-01.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 3978, Section 5.1 on line 29. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2556. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3945], [RFC3031]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (July 2007) is 6130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3562' is defined on line 2370, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 2382, but no explicit reference was found in the text == Unused Reference: 'RFC4808' is defined on line 2400, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 4869 (Obsoleted by RFC 6379) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-requirements-05 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Luyuan Fang (Ed) 2 Internet Draft Michael Behringer 3 Category: Informational Cisco Systems, Inc. 4 Expires: January 2008 Ross Callon 5 Juniper Networks 6 J. L. Le Roux 7 France Telecom 8 Raymond Zhang 9 British Telecom 10 Paul Knight 11 Nortel 12 Yaakov Stein 13 RAD Data Communications 14 Nabil Bitar 15 Verizon 16 Richard Graveman 17 RFC Security, LLC 19 July 2007 21 Security Framework for MPLS and GMPLS Networks 22 draft-fang-mpls-gmpls-security-framework-01.txt 24 Status of this Memo 26 By submitting this Internet-Draft, each author represents that any 27 applicable patent or other IPR claims of which he or she is aware 28 have been or will be disclosed, and any of which he or she becomes 29 aware will be disclosed, in accordance with Section 6 of BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other 38 documents at any time. It is inappropriate to use Internet-Drafts 39 as reference material or to cite them other than as "work in 40 progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Copyright Notice 49 Fang, et al. Informational 1 50 MPLS/GMPLS Security framework 51 Copyright (C) The IETF Trust (2007). 53 Abstract 55 This document provides a security framework for Multiprotocol Label 56 Switching (MPLS) and Generalized Multiprotocol Label Switching 57 (GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and 58 [RFC3945]). This document addresses the security aspects that are 59 relevant in the context of MPLS and GMPLS. It describes the 60 security threats, the related defensive techniques, and the 61 mechanisms for detection and reporting. This document emphasizes 62 RSVP-TE and LDP security considerations, as well as Inter-AS and 63 Inter-provider security considerations for building and maintaining 64 MPLS and GMPLS networks across different domains or different 65 Service Providers. 67 Table of Contents 69 1. Introduction.................................................3 70 1.1. Structure of this Document................................4 71 1.2. Contributors..............................................5 72 2. Terminology .................................................5 73 2.1. Terminology...............................................5 74 2.2. Acronyms and Abbreviations................................7 75 3. Security Reference Models....................................7 76 4. Security Threats.............................................9 77 4.1. Attacks on the Control Plane.............................11 78 4.2. Attacks on the Data Plane................................14 79 5. Defensive Techniques for MPLS/GMPLS Networks................15 80 5.1. Authentication ..........................................16 81 5.2. Cryptographic techniques.................................18 82 5.3. Access Control techniques................................27 83 5.4. Use of Isolated Infrastructure...........................32 84 5.5. Use of Aggregated Infrastructure.........................32 85 5.6. Service Provider Quality Control Processes...............33 86 5.7. Deployment of Testable MPLS/GMPLS Service................33 87 6. Monitoring, Detection, and Reporting of Security Attacks....33 88 7. Service Provider General Security Requirements..............35 89 7.1. Protection within the Core Network.......................35 90 7.2. Protection on the User Access Link.......................39 91 7.3. General Requirements for MPLS/GMPLS Providers ...........40 92 8. Inter-provider Security Requirements........................41 94 Fang, et al. Informational 2 95 MPLS/GMPLS Security framework 96 8.1. Control Plane Protection.................................41 97 8.2. Data Plane Protection....................................45 98 9. Security Considerations.....................................47 99 10. IANA Considerations.......................................47 100 11. Normative References .....................................48 101 12. Informational References..................................49 102 13. Author's Addresses........................................50 103 14. Acknowledgements..........................................53 105 Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 109 this document are to be interpreted as described in RFC2119 [RFC 110 2119]. 112 1. Introduction 114 Security is an important aspect of all networks, MPLS and GMPLS 115 networks being no exception. 117 MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Various 118 security considerations have been addressed in each of the many 119 RFCs on MPLS and GMPLS technologies, but no single document covers 120 general security considerations. The motivation for creating this 121 document is to provide a comprehensive and consistent security 122 framework for MPLS and GMPLS networks. Each individual document may 123 point to this document for general security considerations in 124 addition to providing security considerations specific to the 125 particular technologies the document is describing. 127 In this document, we first describe the security threats relevant 128 in the context of MPLS and GMPLS and the defensive techniques to 129 combat those threats. We consider security issues deriving both 130 from malicious or incorrect behavior of users and other parties and 131 from negligent or incorrect behavior of providers. An important 132 part of security defense is the detection and reporting of a 133 security attack, which is also addressed in this document. 135 We then discuss possible service provider security requirements in 136 a MPLS or GMPLS environment. Users have expectations for the 137 security characteristics of MPLS or GMPLS networks. These include 138 security requirements for equipment supporting MPLS and GMPLS and 139 operational security requirements for providers. Service providers 141 Fang, et al. Informational 3 142 MPLS/GMPLS Security framework 143 must protect their network infrastructure and make it secure to the 144 level required to provide services over their MPLS or GMPLS 145 networks. 147 Inter-AS and Inter-provider security are discussed with special 148 emphasis, because the security risk factors are higher with inter- 149 provider connections. Depending on different MPLS or GMPLS 150 techniques used, the degree of risk and the mitigation 151 methodologies vary. This document discusses the security aspects 152 and requirements for certain basic MPLS and GMPLS techniques and 153 inter-connection models. This document does not attempt to cover 154 all current and future MPLS and GMPLS technologies, as it is not 155 within the scope of this document to analyze the security 156 properties of specific technologies. 158 It is important to clarify that, in this document, we limit 159 ourselves to describing the providers' security requirements that 160 pertain to MPLS and GMPLS networks. Readers may refer to the 161 "Security Best Practices Efforts and Documents" [opsec effort] and 162 "Security Mechanisms for the Internet" [RFC3631] for general 163 network operation security considerations. It is not our intention, 164 however, to formulate precise "requirements" for each specific 165 technology in terms of defining the mechanisms and techniques that 166 must be implemented to satisfy such security requirements. 168 1.1. Structure of this Document 170 This document is organized as follows. In Section 2, we define the 171 terminology used. In Section 3, we define the security reference 172 models for security in MPLS/GMPLS networks, which we use in the 173 rest of the document. In Section 4, we describe the security 174 threats specific to MPLS and GMPLS. In Section 5, we review 175 defensive techniques that may be used against those threats. In 176 Section 6, we describe how attacks may be detected and reported. In 177 Section 7, we describe security requirements providers may have to 178 guarantee the security of the network infrastructure for MPLS/GMPLS 179 services. In section 8, we discuss Inter-provider security 180 requirements. Finally, in Section 9, we discuss security 181 considerations for this document. 183 This document has used relevant content from RFC 4111 "Security 184 Framework of Provider Provisioned VPN for Provider-Provisioned 185 Virtual Private Networks (PPVPNs)" [RFC4111], and "MPLS 186 InterCarrier Interconnect Technical Specification" [MFA MPLS ICI] 187 in the Inter-provider security discussion. We acknowledge the 188 authors of these documents for the valuable information and text. 190 Fang, et al. Informational 4 191 MPLS/GMPLS Security framework 192 1.2. Contributors 194 As the design team members for the MPLS Security Framework, the 195 following made significant contributions to this document. 197 Monique Morrow, Cisco systems, Inc. 198 Jerry Ash 200 2. Terminology 202 2.1. Terminology 204 This document uses MPLS and GMPLS specific terminology. Definitions 205 and details about MPLS and GMPLS terminology can be found in 206 [RFC3031] and [RFC3945]. The most important definitions are 207 repeated in this section; for other definitions the reader is 208 referred to [RFC3031] and [RFC3945]. 210 Customer Edge (CE) device: A Customer Edge device is a router or a 211 switch in the customer's network interfacing with the Service 212 Provider's network. 214 Forwarding Equivalence Class (FEC): A group of IP packets that are 215 forwarded in the same manner (e.g., over the same path, with the 216 same forwarding treatment). 218 Label: A short, fixed length, physically contiguous identifier used 219 to identify a FEC, usually of local significance. 221 Label Switched Hop: A hop between two MPLS nodes, on which 222 forwarding is done using labels. 224 Label Switched Path (LSP): The path through one or more LSRs at one 225 level of the hierarchy followed by a packets in a particular FEC. 227 Label Switching Router (LSR): A MPLS node capable of forwarding 228 native L3 packets. 230 Layer 2: The protocol layer under layer 3 (which therefore offers 231 the services used by layer 3). Forwarding, when done by the 232 swapping of short fixed length labels, occurs at layer 2 regardless 233 of whether the label being examined is an ATM VPI/VCI, a frame 234 relay DLCI, or a MPLS label. 236 Fang, et al. Informational 5 237 MPLS/GMPLS Security framework 238 Layer 3: The protocol layer at which IP and its associated routing 239 protocols operate. 241 Link Layer: Synonymous with layer 2. 243 Loop Detection: A method of dealing with loops in which loops are 244 allowed to be set up, and data may be transmitted over the loop, 245 but the loop is later detected. 247 Loop Prevention: A method of dealing with loops in which data is 248 never transmitted over a loop. 250 Label Stack: An ordered set of labels. 252 Merge Point: A node at which label merging is done. 254 MPLS Domain: A contiguous set of nodes that perform MPLS routing 255 and forwarding and are also in one Routing or Administrative 256 Domain. 258 MPLS Edge Node: A MPLS node that connects a MPLS domain with a node 259 outside of the domain, either because it does not run MPLS, or 260 because it is in a different domain. Note that if a LSR has a 261 neighboring host not running MPLS, then that LSR is a MPLS edge 262 node. 264 MPLS Egress Node: A MPLS edge node in its role in handling traffic 265 as it leaves a MPLS domain. 267 MPLS Ingress Node: A MPLS edge node in its role in handling traffic 268 as it enters a MPLS domain. 270 MPLS Label: A label carried in a packet header, which represents 271 the packet's FEC. 273 MPLS Node: A node running MPLS. A MPLS node is aware of MPLS 274 control protocols, runs one or more L3 routing protocols, and is 275 capable of forwarding packets based on labels. A MPLS node may 276 optionally be also capable of forwarding native L3 packets. 278 MultiProtocol Label Switching (MPLS): An IETF working group and the 279 effort associated with the working group. 281 P: Provider Router. A Provider Router is a router in the Service 282 Provider's core network that does not have interfaces directly 283 towards the customer. A P router is used to interconnect the PE 284 routers. 286 Fang, et al. Informational 6 287 MPLS/GMPLS Security framework 288 PE: Provider Edge device. A Provider Edge device is the equipment 289 in the Service Provider's network that interfaces with the 290 equipment in the customer's network. 292 VPN: Virtual Private Network, which restricts communication between 293 a set of sites, making use of an IP backbone shared by traffic not 294 going to or not coming from those sites ([RFC4110]). 296 2.2. Acronyms and Abbreviations 298 AS Autonomous System 299 ASBR Autonomous System Border Router 300 ATM Asynchronous Transfer Mode 301 BGP Border Gateway Protocol 302 DoS Denial of Service 303 FEC Forwarding Equivalence Class 304 GMPLS Generalized Multi-Protocol Label Switching 305 ICI InterCarrier Interconnect 306 IGP Interior Gateway Protocol 307 IP Internet Protocol 308 LDP Label Distribution Protocol 309 L2 Layer 2 310 L3 Layer 3 311 LSP Label Switched Path 312 LSR Label Switching Router 313 MPLS MultiProtocol Label Switching 314 MP-BGP Multi-Protocol BGP 315 PCE Path Computation Element 316 PPVPN Provider-Provisioned Vitual Private Network 317 PSN Packet-Switched Network 318 RR Route Reflector 319 RSVP-TE Resource Reservation Protocol with Traffic Engineering 320 Extensions 321 SP Service Provider 322 TTL Time-To-Live 323 VPN Virtual Private Network 325 3. Security Reference Models 326 This section defines a reference model for security in MPLS/GMPLS 327 networks. 329 A MPLS/GMPLS core network is defined here as the central network 330 infrastructure (P and PE routers). A MPLS/GMPLS core network 331 consists of one or more SP networks. All network elements in the 332 core are under the operational control of one or more MPLS/GMPLS 334 Fang, et al. Informational 7 335 MPLS/GMPLS Security framework 336 SPs. Even if the MPLS/GMPLS core is provided by several SPs, 337 towards the end users it appears as a single zone of trust. 338 However, when several SPs together provide a MPLS/GMPLS core, each 339 SP still needs to secure itself against the other SPs. 341 A MPLS/GMPLS end user is a company, institution, or residential 342 client of the SP. 344 This document defines each MPLS/GMPLS core in a single domain to be 345 a trusted zone. A primary concern is about security aspects that 346 relate to breaches of security from the "outside" of a trusted zone 347 to the "inside" of this zone. Figure 1 depicts the concept of 348 trusted zones within the MPLS/GMPLS framework. 350 /-------------\ 351 +------------+ / \ +------------+ 352 | MPLS/GMPLS +---/ \--------+ MPLS | 353 | user | MPLS/GMPLS Core | user | 354 | site +---\ /XXX-----+ site | 355 +------------+ \ / XXX +------------+ 356 \-------------/ | | 357 | | 358 | +------\ 359 +--------/ "Internet" 361 MPLS/GMPLS Core with user connections and Internet connection 363 Figure 1: The MPLS/GMPLS trusted zone model. 365 The trusted zone is the MPLS/GMPLS core in a single AS within a 366 single Service Provider. 368 The boundaries of a trust domain should be carefully defined when 369 analyzing the security property of each individual network, e.g., 370 the boundaries can be at the link termination, remote peers, areas, 371 or quite commonly, ASes. 373 In principle, the trusted zones should be separate; however, 374 typically MPLS core networks also offer Internet access, in which 375 case a transit point (marked with "XXX" in Figure 1) is defined. In 376 the case of MPLS/GMPLS inter-provider connections, the trusted zone 377 ends at the ASBR (marked with "B" in Figure 2) of the given AS or 378 provider. 380 Fang, et al. Informational 8 381 MPLS/GMPLS Security framework 382 A key requirement of MPLS and GMPLS networks is that the security 383 of the trusted zone not be compromised by interconnecting the 384 MPLS/GMPLS core infrastructure with another provider's core 385 (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users. 387 In addition, neighbors may be trusted or untrusted. Neighbors may 388 be authorized or unauthorized. Even though a neighbor may be 389 authorized for communication, it may not be trusted. For example, 390 when connecting with another provider's ASBRs to set up inter-AS 391 LSPs, the other provider is considered an untrusted but authorized 392 neighbor. 394 +---------------+ +----------------+ 395 | | | | 396 | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS | 397 CE1--PE1 Network | | Network PE2--CE2 398 | Provider A ASBR2----ASBR4 Provider B | 399 | | | | 400 +---------------+ +----------------+ 402 For Provider A: 403 Trusted Zone: Provider A MPSL/GMPLS network 404 Trusted neighbors: PE1, ASBR1, ASBR2 405 Authorized but untrusted neighbor: provider B 406 Unauthorized neighbors: CE1, CE2 408 Figure 2. MPLS/GMPLS trusted zone and authorized neighbor. 410 All aspects of network security independent of whether a network is 411 a MPLS/GMPLS network are out of scope. For example, attacks from 412 the Internet to a user's web-server connected through the 413 MPLS/GMPLS network are not considered here, unless the way the 414 MPLS/GMPLS network is provisioned could make a difference to the 415 security of this user's server. 417 4. Security Threats 419 This section discusses the various network security threats that 420 may endanger MPLS/GMPLS networks. The discussion is limited to 421 those threats that are unique to MPLS/GMPLS networks or that affect 422 MPLS/GMPLS network in unique ways. 424 A successful attack on a particular MPLS/GMPLS network or on a SP's 425 MPLS/GMPLS infrastructure may cause one or more of the following 426 ill effects: 428 Fang, et al. Informational 9 429 MPLS/GMPLS Security framework 430 - Observation, modification, or deletion of a provider's or user's 431 data. 432 - Replay of a provider's or user's data. 433 - Injection of inauthentic data into a provider's or user's 434 traffic stream. 435 - Traffic pattern analysis on a provider's or user's traffic. 436 - Disruption of a provider's or user's connectivity. 437 - Degradation of a provider's service quality. 439 It is useful to consider that threats, whether malicious or 440 accidental, may come from different categories of sources. For 441 example they may come from: 443 - Other users whose services are provided by the same MPLS/GMPLS 444 core. 445 - The MPLS/GMPLS SP or persons working for it. 446 - Other persons who obtain physical access to a MPLS/GMPLS SP's 447 site. 448 - Other persons who use social engineering methods to influence 449 the behavior of a SP's personnel. 450 - Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats. 451 (Such threats are beyond the scope of this document.) 452 - Others, e.g., attackers from the Internet at large. 453 - Other SPs in the case of MPLS/GMPLS Inter- 454 provider connection. The core of the other provider may or may 455 not be using MPLS/GMPLS. 456 - Those who create, deliver, install, and maintain software for 457 network equipment. 459 Given that security is generally a tradeoff between expense and 460 risk, it is also useful to consider the likelihood of different 461 attacks occurring. There is at least a perceived difference in the 462 likelihood of most types of attacks being successfully mounted in 463 different environments, such as: 465 - A MPLS/GMPLS core inter-connecting with another provider's core 466 - A MPLS/GMPLS configuration transiting the public Internet 468 Most types of attacks become easier to mount and hence more likely 469 as the shared infrastructure via which service is provided expands 470 from a single SP to multiple cooperating SPs to the global 471 Internet. Attacks that may not be of sufficient likeliness to 472 warrant concern in a closely controlled environment often merit 473 defensive measures in broader, more open environments. In closed 474 communities, it is often practical to deal with misbehavior after 475 the fact: an employee can be disciplined, for example. 477 Fang, et al. Informational 10 478 MPLS/GMPLS Security framework 479 The following sections discuss specific types of exploits that 480 threaten MPLS/GMPLS networks. 482 4.1. Attacks on the Control Plane 484 This category encompasses attacks on the control structures 485 operated by the SP with MPLS/GMPLS cores. 487 4.1.1. LSP creation by an unauthorized element 489 The unauthorized element can be a local CE or a router in another 490 domain. An unauthorized element can generate MPLS signaling 491 messages. At the least, this can result in extra control plane and 492 forwarding state, and if successful, network bandwidth could be 493 reserved unnecessarily. This may also result in theft of service 494 and loss of revenue. 496 4.1.2. LSP message interception 498 This threat might be accomplished by monitoring network traffic, 499 for example, after a physical intrusion. Without physical 500 intrusion, it could be accomplished with an unauthorized software 501 modification. Also many technologies such as terrestrail microwave, 502 satellite, or free-space optical could be intercepted without 503 physical intrusion. If successful, it could provide information 504 leading to label spoofing attacks. It also raises confidentiality 505 issues. 507 4.1.3. Attacks against RSVP-TE 509 RSVP-TE, described in [RFC3209], is the control protocol used to 510 set up GMPLS and traffic engineered MPLS tunnels. 512 There are two major types of Denial of Dervice (DoS) attacks 513 against a MPLS domain based on RSVP-TE. The attacker may set up 514 numerous unauthorized LSPs or may send a storm of RSVP messages. 515 It has been demonstrated that unprotected routers running RSVP can 516 be effectively disabled by both types of DoS attacks. 518 These attacks may even be combined, by using the unauthorized LSPs 519 to transport additional RSVP (or other) messages across routers 520 where they might otherwise be filtered out. RSVP attacks can be 521 launched against adjacent routers at the border with the attacker, 522 or against non-adjacent routers within the MPLS domain, if there is 523 no effective mechanism to filter them out. 525 Fang, et al. Informational 11 526 MPLS/GMPLS Security framework 527 4.1.4. Attacks against LDP 529 LDP, described in [RFC3036], is the control protocol used to set up 530 MPLS tunnels without TE. 532 There are two significant types of attack against LDP. An 533 unauthorized network element can establish a LDP session by sending 534 LDP Hello and LDP Init messages, leading to the potential setup of 535 a LSP, as well as accompanying LDP state table consumption. Even 536 without successfully establishing LSPs, an attacker can launch a 537 DoS attack in the form of a storm of LDP Hello messages or LDP TCP 538 Syn messages, leading to high CPU utilization on the target router. 540 4.1.5. Denial of Service Attacks on the Network Infrastructure 542 DoS attacks could be accomplished through a MPLS signaling storm, 543 resulting in high CPU utilization and possibly leading to control 544 plane resource starvation. 546 Control plane DoS attacks can be mounted specifically against the 547 mechanisms the SPuses to provide various services, or against the 548 general infrastructure of the service provider, e.g., P routers or 549 shared aspects of PE routers. (An attack against the general 550 infrastructure is within the scope of this document only if the 551 attack can occur in relation with the MPLS/GMPLS infrastructure; 552 otherwise is not a MPLS/GMPLS-specific issue.) 554 The attacks described in the following sections may each have 555 denial of service as one of their effects. Other DoS attacks are 556 also possible. 558 4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via Management 559 Interfaces 561 This includes unauthorized access to a SP's infrastructure 562 equipment, for example to reconfigure the equipment or to extract 563 information (statistics, topology, etc.) pertaining to the network. 565 4.1.7. Social Engineering Attacks on the SP's Infrastructure 567 Attacks in which the service provider network is reconfigured or 568 damaged, or in which confidential information is improperly 569 disclosed, may be mounted by manipulation of a SP's personnel. 570 These types of attacks are MPLS/GMPLS-specific if they affect 571 MPLS/GMPLS-serving mechanisms. 573 Fang, et al. Informational 12 574 MPLS/GMPLS Security framework 575 4.1.8. Cross-Connection of Traffic between Users 577 This refers to the event in which expected isolation between 578 separate users (who may be VPN users) is breached. This includes 579 cases such as: 581 - A site being connected into the "wrong" VPN 582 - Traffic being replicated and sent to an unauthorized user 583 - Two or more VPNs being improperly merged together 584 - A point-to-point VPN connecting the wrong two points 585 - Any packet or frame being improperly delivered outside the VPN 586 to which it belongs 588 Mis-connection or cross-connection of VPNs may be caused by service 589 provider or equipment vendor error, or by the malicious action of 590 an attacker. The breach may be physical (e.g., PE-CE links mis- 591 connected) or logical (e.g., improper device configuration). 593 Anecdotal evidence suggests that the cross-connection threat is one 594 of the largest security concerns of users (or would-be users). 596 4.1.9. Attacks against Routing Protocols 598 This encompasses attacks against underlying routing protocols that 599 are run by the SP and that directly support the MPLS/GMPLS core. 600 (Attacks against the use of routing protocols for the distribution 601 of backbone routes are beyond the scope of this document.) 602 Specific attacks against popular routing protocols have been widely 603 studied and described in [Beard]. 605 4.1.10. Other Attacks on Control Traffic 607 Besides routing and management protocols (covered separately in the 608 previous sections), a number of other control protocols may be 609 directly involved in delivering services by the MPLS/GMPLS core. 610 These include but may not be limited to: 612 - MPLS signaling (LDP, RSVP-TE) discussed above in subsections 613 4.1.4 and 4.1.3 614 - PCE signaling 615 - IPsec signaling (IKE and IKEv2) 616 - ICMP and ICMPv6 617 - L2TP 618 - BGP-based membership discovery 619 - Database-based membership discovery (e.g., RADIUS) 620 - Other protocols that may be important to the control 621 infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE. 623 Fang, et al. Informational 13 624 MPLS/GMPLS Security framework 625 Attacks might subvert or disrupt the activities of these protocols, 626 for example via impersonation or DoS. 628 4.2. Attacks on the Data Plane 630 This category encompasses attacks on the provider's or end user's 631 data. Note that from the MPLS/GMPLS network end user's point of 632 view, some of this might be control plane traffic, e.g. routing 633 protocols running from user site A to user site B via a L2 or L3 634 connection, which may be some type of VPN. 636 4.2.1. Unauthorized Observation of Data Traffic 638 This refers to "sniffing" provider or end user packets and 639 examining their contents. This can result in exposure of 640 confidential information. It can also be a first step in other 641 attacks (described below) in which the recorded data is modified 642 and re-inserted, or simply replayed later. 644 4.2.2. Modification of Data Traffic 646 This refers to modifying the contents of packets as they traverse 647 the MPLS/GMPLS core. 649 4.2.3. Insertion of Inauthentic Data Traffic: Spoofing and Replay 651 Spoofing refers to sending a user or inserting into a data stream 652 packets that do not belong, with the objective of having them 653 accepted by the recipient as legitimate. Also included in this 654 category is the insertion of copies of once-legitimate packets that 655 have been recorded and replayed. 657 4.2.4. Unauthorized Deletion of Data Traffic 659 This refers to causing packets to be discarded as they traverse the 660 MPLS/GMPLS networks. This is a specific type of Denial of Service 661 attack. 663 4.2.5. Unauthorized Traffic Pattern Analysis 665 This refers to "sniffing" provider or user packets and examining 666 aspects or meta-aspects of them that may be visible even when the 667 packets themselves are encrypted. An attacker might gain useful 668 information based on the amount and timing of traffic, packet 669 sizes, source and destination addresses, etc. For most users, this 671 Fang, et al. Informational 14 672 MPLS/GMPLS Security framework 673 type of attack is generally considered to be significantly less of 674 a concern than the other types discussed in this section. 676 4.2.6. Denial of Service Attacks 678 Denial of Service (DoS) attacks are those in which an attacker 679 attempts to disrupt or prevent the use of a service by its 680 legitimate users. Taking network devices out of service, modifying 681 their configuration, or overwhelming them with requests for service 682 are several of the possible avenues for DoS attack. 684 Overwhelming the network with requests for service, otherwise known 685 as a "resource exhaustion" DoS attack, may target any resource in 686 the network, e.g., link bandwidth, packet forwarding capacity, 687 session capacity for various protocols, CPU power, table size, 688 storage overflows, and so on. 690 DoS attacks of the resource exhaustion type can be mounted against 691 the data plane of a particular provider or end user by attempting 692 to insert (spoofing) an overwhelming quantity of inauthentic data 693 into the provider or end user network from the outside of the 694 trusted zone. Potential results might be to exhaust the bandwidth 695 available to that provider or end user or to overwhelm the 696 cryptographic authentication mechanisms of the provider or end 697 user. 699 Data plane resource exhaustion attacks can also be mounted by 700 overwhelming the service provider's general (MPLS/GMPLS- 701 independent) infrastructure with traffic. These attacks on the 702 general infrastructure are not usually a MPLS/GMPLS-specific issue, 703 unless the attack is mounted by another MPLS/GMPLS network user 704 from a privileged position. (E.g., a MPLS/GMPLS network user might 705 be able to monopolize network data plane resources and thus disrupt 706 other users.) 708 Many DoS attacks use amplification, whereby the attacker co-opts 709 otherwise innocent parties to increase the effect of the attack. 710 The attacker may, for example, send packets to a broadcast or 711 multicast address with the spoofed source address of the victim, 712 and all of the recipients may then respond to the victim. 714 5. Defensive Techniques for MPLS/GMPLS Networks 716 The defensive techniques discussed in this document are intended to 717 describe methods by which some security threats can be addressed. 718 They are not intended as requirements for all MPLS/GMPLS 719 implementations. The MPLS/GMPLS provider should determine the 721 Fang, et al. Informational 15 722 MPLS/GMPLS Security framework 723 applicability of these techniques to the provider's specific 724 service offerings, and the end user may wish to assess the value of 725 these techniques to the user's service requirements. The 726 operational environment determines the security requirements. 727 Therefore, protocol designers need to provide a full set of 728 security services, which can be used where appropriate. 730 The techniques discussed here include encryption, authentication, 731 filtering, firewalls, access control, isolation, aggregation, and 732 other techniques. 734 Often, security is achieved by careful protocol design, rather than 735 by adding a security method. For example, one method of mitigating 736 DoS attacks is to make sure that innocent parties cannot be used to 737 amplify the attack. Security works better when it is "designed in" 738 rather than "added on." 740 Nothing is ever 100% secure. Defense therefore involves protecting 741 against those attacks that are most likely to occur or that have 742 the most direct consequences if successful. For those attacks that 743 are protected against, absolute protection is seldom achievable; 744 more often it is sufficient just to make the cost of a successful 745 attack greater than what the adversary will be willing or able to 746 expend. 748 Successfully defending against an attack does not necessarily mean 749 the attack must be prevented from happening or from reaching its 750 target. In many cases the network can instead be designed to 751 withstand the attack. For example, the introduction of inauthentic 752 packets could be defended against by preventing their introduction 753 in the first place, or by making it possible to identify and 754 eliminate them before delivery to the MPLS/GMPLS user's system. 755 The latter is frequently a much easier task. 757 5.1. Authentication 759 To prevent security issues arising from some Denial-of-Service 760 attacks or from malicious or accidental misconfiguration, it is 761 critical that devices in the MPLS/GMPLS should only accept 762 connections or control messages from valid sources. Authentication 763 refers to methods to ensure that message sources are properly 764 identified by the MPLS/GMPLS devices with which they communicate. 765 This section focuses on identifying the scenarios in which sender 766 authentication is required and recommends authentication mechanisms 767 for these scenarios. 769 Fang, et al. Informational 16 770 MPLS/GMPLS Security framework 771 Cryptographic techniques (authentication, integrity, and 772 encryption) do not protect against some types of denial of service 773 attacks, specifically resource exhaustion attacks based on CPU or 774 bandwidth exhaustion. In fact, the processing required to decrypt 775 or check authentication may, in the case of software crypto, in 776 some cases increase the effect of these resource exhaustion 777 attacks. With a hardware crypto accelerator, attack packets can be 778 dropped at line speed without a cost of software cycles. 779 Cryptographic techniques may, however, be useful against resource 780 exhaustion attacks based on exhaustion of state information (e.g., 781 TCP SYN attacks). 783 The MPLS user plane, as presently defined, is not amenable to 784 source authentication as there are no source identifiers in the 785 MPLS packet to authenticate. The MPLS label is only locally 786 meaningful, and it identifies a downstream semantic rather than an 787 upstream source. 789 When the MPLS payload carries identifiers that may be authenticated 790 (e.g., IP packets), authentication may be carried out at the client 791 level, but this does not help the MPLS SP, as these client 792 identifiers belong to an external, untrusted network. 794 5.1.1. Management System Authentication 796 Management system authentication includes the authentication of a 797 PE to a centrally-managed network management or directory server 798 when directory-based "auto-discovery" is used. It also includes 799 authentication of a CE to the configuration server, when a 800 configuration server system is used. 802 5.1.2. Peer-to-Peer Authentication 804 Peer-to-peer authentication includes peer authentication for 805 network control protocols (e.g., LDP, BGP, etc.), and other peer 806 authentication (i.e., authentication of one IPsec security gateway 807 by another). 809 5.1.3. Cryptographic techniques for authenticating identity 811 Cryptographic techniques offer several mechanisms for 812 authenticating the identity of devices or individuals. These 814 Fang, et al. Informational 17 815 MPLS/GMPLS Security framework 816 include the use of shared secret keys, one-time keys generated by 817 accessory devices or software, user-ID and password pairs, and a 818 range of public-private key systems. Another approach is to use a 819 hierarchical Certification Authority system to provide digital 820 certificates. 822 This section describes or provides references to the specific 823 cryptographic approaches for authenticating identity. These 824 approaches provide secure mechanisms for most of the authentication 825 scenarios required in securing a MPLS/GMPLS network. 827 5.2. Cryptographic techniques 829 MPLS/GMPLS defenses against a wide variety of attacks can be 830 enhanced by the proper application of cryptographic techniques. 831 These are the same cryptographic techniques that are applicable to 832 general network communications. In general, these techniques can 833 provide confidentiality (encryption) of communication between 834 devices, can authenticate the identities of the devices, and can 835 ensure that it will be detected if the data being communicated is 836 changed during transit. 838 Several aspects of authentication are addressed in some detail in a 839 separate "Authentication" section. 841 Cryptographic methods add complexity to a service and thus, for a 842 few reasons, may not be the most practical soloution in every case. 843 Cryptography adds an additional computational burden to devices, 844 which may reduce the number of user connections that can be handled 845 on a device or otherwise reduce the capacity of the device, 846 potentially driving up the provider's costs. Typically, 847 configuring encryption services on devices adds to the complexity 848 of their configuration and adds labor cost. Some key management 849 system is usually needed. Packet sizes are typically increased when 850 the packets are encrypted or have integrity checks or replay 851 counters added, increasing the network traffic load and adding to 852 the likelihood of packet fragmentation with its increased overhead. 853 (This packet length increase can often be mitigated to some extent 854 by data compression techniques, but at the expense of additional 855 computational burden.) Finally, some providers may employ enough 856 other defensive techniques, such as physical isolation or filtering 857 and firewall techniques, that they may not perceive additional 858 benefit from encryption techniques. 860 Users may wish to provide confidentiality end to end. Generally, 861 encrypting for confidentiality must be accompanied with 862 cryptographic integrity checks to prevent certain active attacks 864 Fang, et al. Informational 18 865 MPLS/GMPLS Security framework 866 against the encrypted communications. On today's processors, 867 encryption and integrity checks run extremely quickly, but key 868 management may be more demanding in terms of both computational and 869 administrative overhead. 871 The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider, 872 and other parts of the network is a major element in determining 873 the applicability of cryptographic protection for any specific 874 MPLS/GMPLS implementation. In particular, it determines where 875 cryptographic protection should be applied: 876 - If the data path between the user's site and the 877 provider's PE is not trusted, then it may be used on the 878 PE-CE link. 879 - If some part of the backbone network is not trusted, 880 particularly in implementations where traffic may travel 881 across the Internet or multiple providers' networks, then 882 the PE-PE traffic may be cryptographically protected. One 883 also should consider cases where L1 technology may be 884 vulnerable to eavesdropping. 885 - If the user does not trust any zone outside of its 886 premises, it may require end-to-end or CE-CE 887 cryptotographic protection. This fits within the scope of 888 this MPLS/GMPLS security framework when the CE is 889 provisioned by the MPLS/GMPLS provider. 890 - If the user requires remote access to its site from a 891 system at a location that is not a customer location (for 892 example, access by a traveler) there may be a requirement 893 for cryptographically protecting the traffic between that 894 system and an access point or a customer's site. If the 895 MPLS/GMPLS provider supplies the access point, then the 896 customer must cooperate with the provider to handle the 897 access control services for the remote users. These access 898 control services are usually protected cryptographically, 899 as well. 901 Access control usually starts with authentication of the 902 entity. If cryptographic services are part of the scenario, 903 then it is important to bind the authentication to the key 904 management. Otherwise the protocol is vulnerable to being 905 hijacked between the authentication and key management. 907 Although CE-CE cryptographic protection can provide integrity and 908 confidentiality against third parties, if the MPLS/GMPLS provider 909 has complete management control over the CE (encryption) devices, 910 then it may be possible for the provider to gain access to the 911 user's traffic or internal network. Encryption devices could 912 potentially be reconfigured to use null encryption, bypass 914 Fang, et al. Informational 19 915 MPLS/GMPLS Security framework 916 cryptographic processing altogether, reveal internal congiguration, 917 or provide some means of sniffing or diverting unencrypted traffic. 918 Thus an implementation using CE-CE encryption needs to consider the 919 trust relationship between the MPLS/GMPLS user and provider. 920 MPLS/GMPLS users and providers may wish to negotiate a service 921 level agreement (SLA) for CE-CE encryption that provides an 922 acceptable demarcation of responsibilities for management of 923 cryptographic protection on the CE devices. The demarcation may 924 also be affected by the capabilities of the CE devices. For 925 example, the CE might support some partitioning of management, a 926 configuration lock-down ability, or shared capability to verify the 927 configuration. In general, the MPLS/GMPLS user needs to have a 928 fairly high level of trust that the MPLS/GMPLS provider will 929 properly provision and manage the CE devices, if the managed CE-CE 930 model is used. 932 5.2.1. IPsec in MPLS/GMPLS 934 IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC2411] is the 935 security protocol of choice for encryption at the IP layer (Layer 936 3). IPsec provides robust security for IP traffic between pairs of 937 devices. Non-IP traffic such as IS-IS routing must be converted to 938 IP (e.g., by encapsulation) in order to use IPsec. 940 In the MPLS/GMPLS model, IPsec can be employed to protect IP 941 traffic between PEs, between a PE and a CE, or from CE to CE. CE- 942 to-CE IPsec may be employed in either a provider-provisioned or a 943 user-provisioned model. Likewise, IPsec protection of data 944 performed within the user's site is outside the scope of this 945 document, because it is simply handled as user data by the 946 MPLS/GMPLS core. However, if the SP performs compression, pre- 947 encryption will have a major effect on that operation. 949 IPsec does not itself specify an encryption algorithm. It can use 950 a variety of integrity or confidentiality algorithms (or even 951 combined integrity and confidentiality algorithms), with various 952 key lengths, such as AES encryption or AES message integrity 953 checks. There are trade-offs between key length, computational 954 burden, and the level of security of the encryption. A full 955 discussion of these trade-offs is beyond the scope of this 956 document. In practice, any currently recommended IPsec protection 957 offers enough security to reduce the likelihood of its being 958 directly targeted by an attacker substantially; other weaker links 959 in the chain of security are likely to be attacked first. 960 MPLS/GMPLS users may wish to use a Service Level Agreement (SLA) 962 Fang, et al. Informational 20 963 MPLS/GMPLS Security framework 964 specifying the SP's responsibility for ensuring data integrity and 965 confidentiality, rather than analyzing the specific encryption 966 techniques used in the MPLS/GMPLS service. 968 Encryption algorithms generally come with two parameters: mode such 969 as Cipher Block Chaining and key length such as AES-192. (This 970 should not be confused with two other senses in which the word 971 "mode" is used: IPsec itself can be used in Tunnel Mode or 972 Transport Mode, and IKE [version 1] uses Main Mode, Aggressive 973 Mode, or Quick Mode). It should be stressed that IPsec encryption 974 without an integrity check is a state of sin. 976 For many of the MPLS/GMPLS provider's network control messages and 977 some user requirements, cryptographic authentication of messages 978 without encryption of the contents of the message may provide 979 appropriate security. Using IPsec, authentication of messages is 980 provided by the Authentication Header (AH) or through the use of 981 the Encapsulating Security Protocol (ESP) with NULL encryption. 982 Where control messages require integrity but do not use IPsec, 983 other cryptographic authentication methods are often available. 984 Message authentication methods currently considered to be secure 985 are based on hashed message authentication codes (HMAC) [RFC2104] 986 implemented with a secure hash algorithm such as Secure Hash 987 Algorithm 1 (SHA-1) [RFC3174]. No attacks against HMAC SHA-1 are 988 likely to play out in the near future, but it is possible that 989 people will soon find SHA-1 collisions. Thus, it is important that 990 mechanisms be designed to be flexible about the choice of hash 991 functions and message integrity checks. Also, many of these 992 mechanisms do not include a convenient way to manage and update 993 keys. 995 A mechanism to provide a combination of confidentiality, data 996 origin authentication, and connectionless integrity is the use of 997 AES in CCM (Counter with CBC-MAC) mode (RFC 4309) [RFC4309], with 998 an explicit initialization vector (IV), as the IPsec ESP. Recently, 999 GCM is rapidly replacing CCM as the preferred method: [RFC4103]. 1001 MPLS and GMPLS, which provide differentiated services based on 1002 traffic type, may encounter some conflicts with IPsec encryption of 1003 traffic. Because encryption hides the content of the packets, it 1004 may not be possible to differentiate the encrypted traffic in the 1005 same manner as unencrypted traffic. Although DiffServ markings are 1006 copied to the IPsec header and can provide some differentiation, 1007 not all traffic types can be accommodated by this mechanism. Using 1008 IPsec without IKE or IKEv2 (the better choice) is not advisable. 1009 IKEv2 provides IPsec Security Association creation and management, 1010 entity authentication, key agreement, and key update. It works with 1011 a variety of authentication methods including pre-shared keys, 1013 Fang, et al. Informational 21 1014 MPLS/GMPLS Security framework 1015 public key certificates, and EAP. If DoS attacks against IKEv2 are 1016 considered an important threat to mitigate, the cookie-based anti- 1017 spoofing feature of IKEv2 should be used. IKEv2 has its own set of 1018 cryptographic methods, but any of the default suites specified in 1019 [RFC4308] or [RFC4869] provides more than adequate security. 1021 5.2.2. Encryption for device configuration and management 1023 For configuration and management of MPLS/GMPLS devices, encryption 1024 and authentication of the management connection at a level 1025 comparable to that provided by IPsec is desirable. 1027 Several methods of transporting MPLS/GMPLS device management 1028 traffic offer security and confidentiality. 1029 - Secure Shell (SSH) offers protection for TELNET [STD-8] or 1030 terminal-like connections to allow device configuration. 1031 - SNMPv3 [STD62] provides encrypted and authenticated protection 1032 for SNMP-managed devices. 1033 - Transport Layer Security (TLS) [RFC4346] and the closely-related 1034 Secure Sockets Layer (SSL) are widely used for securing HTTP- 1035 based communication, and thus can provide support for most XML- 1036 and SOAP-based device management approaches. 1037 - Since 2004, there has been extensive work proceeding in several 1038 organizations (OASIS, W3C, WS-I, and others) on securing device 1039 management traffic within a "Web Services" framework, using a 1040 wide variety of security models, and providing support for 1041 multiple security token formats, multiple trust domains, 1042 multiple signature formats, and multiple encryption 1043 technologies. 1044 - IPsec provides the services with integrity and confidentiality 1045 at the network layer. With regards to device management, its 1046 current use is primarily focused on in-band management of user- 1047 managed IPsec gateway devices. 1048 - There are recent work in ISMS WG (Integrated Security Model for 1049 SNMP Working Group) to define how to use SSH to secure SNMP, due to 1050 the limited deployment of SNMPv3; and the possibility of using 1051 Kerberos, particularly for interfaces like TELNET, where client code 1052 exists. 1054 Cryptographic Techniques for MPLS Pseudowires 1056 5.2.3. 5.1.3 Security Considerations for MPLS Pseudowires 1058 In addition to IP traffic, MPLS networks may be used to transport 1059 other services such as Ethernet, ATM, Frame Relay, and TDM. This is 1061 Fang, et al. Informational 22 1062 MPLS/GMPLS Security framework 1063 done by setting up pseudowires (PWs) that tunnel the native service 1064 through the MPLS core by encapsulating at the edges. The PWE 1065 architecture is defined in [RFC3985]. 1067 PW tunnels may be set up using the PWE control protocol based on 1068 LDP [RFC4447], and thus security considerations for LDP will most 1069 likely be applicable to the PWE3 control protocol as well. 1071 PW user packets contain at least one MPLS label (the PW label) and 1072 may contain one or more MPLS tunnel labels. After the label stack 1073 there is a four-byte control word (which is optional for some PW 1074 types), followed by the native service payload. It must be 1075 stressed that encapsulation of MPLS PW packets in IP for the 1076 purpose of enabling use of IPsec mechanisms is not a valid option. 1078 The PW client traffic may be secured by use of mechanisms beyond 1079 the scope of this document. 1081 5.2.4. End-to-End versus Hop-by-Hop Protection Tradeoffs in 1082 MPLS/GMPLS 1084 In MPLS/GMPLS, cryptographic protection could potentially be 1085 applied to the MPLS/GMPLS traffic at several different places. 1086 This section discusses some of the tradeoffs in implementing 1087 encryption in several different connection topologies among 1088 different devices within a MPLS/GMPLS network. 1090 Cryptographic protection typically involves a pair of devices that 1091 protect the traffic passing between them. The devices may be 1092 directly connected (over a single "hop"), or intervening devices 1093 may transport the protected traffic between the pair of devices. 1094 The extreme cases involve using protection between every adjacent 1095 pair of devices along a given path (hop-by-hop), or using 1096 protection only between the end devices along a given path (end-to- 1097 end). To keep this discussion within the scope of this document, 1098 the latter ("end-to-end") case considered here is CE-to-CE rather 1099 than fully end-to-end. 1101 Figure 3 depicts a simplified topology showing the Customer Edge 1102 (CE) devices, the Provider Edge (PE) devices, and a variable number 1103 (three are shown) of Provider core (P) devices, which might be 1104 present along the path between two sites in a single VPN operated 1105 by a single service provider (SP). 1107 Fang, et al. Informational 23 1108 MPLS/GMPLS Security framework 1109 Site_1---CE---PE---P---P---P---PE---CE---Site_2 1111 Figure 3: Simplified topology traversing through MPLS/GMPLS core. 1113 Within this simplified topology, and assuming that the P devices 1114 are not involved with cryptographic protection, four basic, 1115 feasible configurations exist for protecting connections among the 1116 devices: 1118 1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity 1119 services between the two CE devices, so that traffic will be 1120 protected throughout the SP's network. 1122 2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or 1123 integrity services between the two PE devices. Unprotected traffic 1124 is received at one PE from the customer's CE, then it is protected 1125 for transmission through the SP's network to the other PE, and 1126 finally it is decrypted or checked for integrity and sent to the 1127 other CE. 1129 3) Access link (CE-to-PE) - Apply confidentiality or integrity 1130 services between the CE and PE on each side or on only one side. 1132 4) Configurations 2 and 3 above can also be combined, with 1133 confidentiality or integrity running from CE to PE, then PE to PE, 1134 and then PE to CE. 1136 Among the four feasible configurations, key tradeoffs in 1137 considering encryption include: 1139 - Vulnerability to link eavesdropping or tampering - assuming an 1140 attacker can 1141 observe or modify data in transit on the links, would it be 1142 protected by encryption? 1144 - Vulnerability to device compromise - assuming an attacker can get 1145 access to a device (or freely alter its configuration), would the 1146 data be protected? 1148 - Complexity of device configuration and management - given the 1149 number of sites per VPN customer as Nce and the number of PEs 1150 participating in a given VPN as Npe, how many device configurations 1151 need to be created or maintained, and how do those configurations 1152 scale? 1154 Fang, et al. Informational 24 1155 MPLS/GMPLS Security framework 1156 - Processing load on devices - how many cryptographic operations 1157 must be performed given N packets? - This raises considerations of 1158 device capacity and perhaps end-to-end delay. 1160 - Ability of the SP to provide enhanced services (QoS, firewall, 1161 intrusion detection, etc.) - Can the SP inspect the data to provide 1162 these services? 1164 These tradeoffs are discussed for each configuration, below: 1166 1) Site-to-site (CE-to-CE) 1168 Link eavesdropping or tampering - protected on all links 1169 Device compromise - vulnerable to CE compromise 1170 Complexity - single administration, responsible for one device per 1171 site (Nce devices), but overall configuration per VPN scales as 1172 Nce**2. 1173 Though the complexity may be reduced: 1) In practice, as Nce 1174 grows, the number of VPNs falls off from being a full clique; 1175 2) If the CEs run an automated key management protocol, then 1176 they should be able to set up and tear down secured VPNs 1177 without any intervention 1178 Processing load - on each of two CEs, each packet is either 1179 cryptographically processed (2P), though the protection may be 1180 "integrity check only" or "integrity check plus encryption." 1181 Enhanced services - severely limited; typically only Diffserv 1182 markings are visible to the SP, allowing some QoS services 1184 2) Provider edge-to-edge (PE-to-PE) 1186 Link eavesdropping or tampering - vulnerable on CE-PE links; 1187 protected on SP's network links 1188 Device compromise - vulnerable to CE or PE compromise 1189 Complexity - single administration, Npe devices to configure. 1190 (Multiple sites may share a PE device so Npe is typically much 1191 less than Nce.) Scalability of the overall configuration 1192 depends on the PPVPN type: If the cryptographic protection is 1193 separate per VPN context, it scales as Npe**2 per customer VPN. 1194 If it is per-PE, it scales as Npe**2 for all customer VPNs 1195 combined. 1196 Processing load - on each of two PEs, each packet is 1197 cryptographically processed (2P). Note that this 2P is a 1198 different 2P from case (1), because only PEs are in 1199 consideration here. 1200 Enhanced services - full; SP can apply any enhancements based on 1201 detailed view of traffic 1203 3) Access link (CE-to-PE) 1205 Fang, et al. Informational 25 1206 MPLS/GMPLS Security framework 1207 Link eavesdropping or tampering - protected on CE-PE link; 1208 vulnerable on SP's network links 1209 Device compromise - vulnerable to CE or PE compromise 1210 Complexity - two administrations (customer and SP) with device 1211 configuration on each side (Nce + Npe devices to configure) but 1212 because there is no mesh the overall configuration scales as 1213 Nce. 1214 Processing load - on each of two CEs, each packet is 1215 cryptographically processed, plus on each of two PEs, each 1216 packet is cryptographically processed (4P) 1217 Enhanced services - full; SP can apply any enhancements based on 1218 detailed view of traffic 1220 4) Combined Access link and PE-to-PE (essentially hop-by-hop) 1222 Link eavesdropping or tampering - protected on all links 1223 Device compromise - vulnerable to CE or PE compromise 1224 Complexity - two administrations (customer and SP) with device 1225 configuration on each side (Nce + Npe devices to configure). 1226 Scalability of the overall configuration depends on the PPVPN 1227 type: If the cryptographic processing is separate per VPN 1228 context, it scales as Npe**2 per customer VPN. If it is per- 1229 PE, it scales as Npe**2 for all customer VPNs combined. 1230 Processing load - on each of two CEs, each packet is 1231 cryptographically processed, plus on each of two PEs, each 1232 packet is cryptographically processed twice (6P) 1233 Enhanced services - full; SP can apply any enhancements based on 1234 detailed view of traffic 1236 Given the tradeoffs discussed above, a few conclusions can be made: 1238 - Configurations 2 and 3 are subsets of 4 that may be appropriate 1239 alternatives to 4 under certain threat models; the remainder of 1240 these conclusions compare 1 (CE-to-CE) versus 4 (combined access 1241 links and PE-to-PE). 1243 - If protection from link eavesdropping or tampering is all that is 1244 important, then configurations 1 and 4 are equivalent. 1246 - If protection from device compromise is most important and the 1247 threat is to the CE devices, both cases are equivalent; if the 1248 threat is to the PE devices, configuration 1 is better. 1250 - If reducing complexity is most important, and the size of the 1251 network is small, configuration 1 is better. Otherwise 1252 configuration 4 is better because rather than a mesh of CE devices 1253 it requires a smaller mesh of PE devices. Also, under some PPVPN 1255 Fang, et al. Informational 26 1256 MPLS/GMPLS Security framework 1257 approaches the scaling of 4 is further improved by sharing the same 1258 PE-PE mesh across all VPN contexts. The scaling advantage of 4 may 1259 be increased or decreased in any given situation if the CE devices 1260 are simpler to configure than the PE devices, or vice-versa. 1262 - If the overall processing load is a key factor, then 1 is better, 1263 unless the PEs come with a hardware encryption accelerator and the 1264 CEs do not. 1266 - If the availability of enhanced services support from the SP is 1267 most important, then 4 is best. 1269 As a quick overall conclusion, CE-to-CE protection is better 1270 against device compromise, but this comes at the cost of enhanced 1271 services and at the cost of operational complexity due to the 1272 Order(n**2) scaling of a larger mesh. 1274 This analysis of site-to-site vs. hop-by-hop tradeoffs does not 1275 explicitly include cases of multiple providers cooperating to 1276 provide a PPVPN service, public Internet VPN connectivity, or 1277 remote access VPN service, but many of the tradeoffs will be 1278 similar. 1280 In addition to the simplified models, the following should also be 1281 considered: 1282 - There are reasons, perhaps, to protect a specific P-to-P or PE- 1283 to-P. 1284 - There may be reasons to do multiple encryptions over certain 1285 segments. One may be using an encrypted wireless link under our 1286 IPsec VPN to access a SSL-secured web site to download encrypted 1287 email attachments: four layers.) 1288 - It may be that, for example, cryptographic integrity checks are 1289 applied end to end, and confidentiality over a shorter span. 1290 - Different cryptographic protection may be required for control 1291 protocols and data traffic. 1292 - Attention needs to be given to how auxiliary traffic is 1293 protected, e.g., the ICMPv6 packets that flow back during PMTU 1294 discovery, among other examples. 1296 5.3. Access Control techniques 1298 Access control techniques include packet-by-packet or packet-flow- 1299 by-packet-flow access control by means of filters and firewalls, as 1300 well as by means of admitting a "session" for a control, signaling, 1301 or management protocol. Enforcement of access control by isolated 1302 infrastructure addresses is discussed in another section of this 1303 document. 1305 Fang, et al. Informational 27 1306 MPLS/GMPLS Security framework 1307 In this document, we distinguish between filtering and firewalls 1308 based primarily on the direction of traffic flow. We define 1309 filtering as being applicable to unidirectional traffic, while a 1310 firewall can analyze and control both sides of a conversation. 1312 The definition has two significant corollaries: 1313 - Routing or traffic flow symmetry: A firewall typically requires 1314 routing symmetry, which is usually enforced by locating a firewall 1315 where the network topology assures that both sides of a 1316 conversation will pass through the firewall. A filter can operate 1317 upon traffic flowing in one direction, without considering traffic 1318 in the reverse direction. Beware that this concept could result in 1319 a single point of failure. 1320 - Statefulness: Because it receives both sides of a conversation, a 1321 firewall may be able to interpret a significant amount of 1322 information concerning the state of that conversation and use this 1323 information to control access. A filter can maintain some limited 1324 state information on a unidirectional flow of packets, but cannot 1325 determine the state of the bi-directional conversation as precisely 1326 as a firewall. 1328 5.3.1. Filtering 1330 It is relatively common for routers to filter data packets. That 1331 is, routers can look for particular values in certain fields of the 1332 IP or higher level (e.g., TCP or UDP) headers. Packets which 1333 matching the criteria associated with a particular filter may 1334 either be discarded or given special treatment. Today, not only 1335 routers, most end hosts today have filters and every instance of 1336 IPsec is also a filter [RFC4301]. 1338 In discussing filters, it is useful to separate the Filter 1339 Characteristics that may be used to determine whether a packet 1340 matches a filter from the Packet Actions applied to those packets 1341 which matching a particular filter. 1343 o Filter Characteristics 1345 Filter characteristics or rules are used to determine whether a 1346 particular packet or set of packets matches a particular filter. 1348 In many cases filter characteristics may be stateless. A stateless 1349 filter determines whether a particular packet matches a filter 1350 based solely on the filter definition, normal forwarding 1351 information (such as the next hop for a packet), and the contents 1352 of that individual packet. Typically stateless filters may consider 1353 the incoming and outgoing logical or physical interface, 1354 information in the IP header, and information in higher layer 1356 Fang, et al. Informational 28 1357 MPLS/GMPLS Security framework 1358 headers such as the TCP or UDP header. Information in the IP header 1359 to be considered may for example include source and destination IP 1360 addresses, Protocol field, Fragment Offset, and TOS field in IPv4, 1361 Next Header, Extension Headers, Flow label, etc. in IPv6. Filters 1362 also may consider fields in the TCP or UDP header such as the Port 1363 fields, the SYN field in the TCP header, as well as ICMP and ICMPv6 1364 type. 1366 Stateful filtering maintains packet-specific state information, to 1367 aid in determining whether a filter has been met. For example, a 1368 device might apply stateless filters to the first fragment of a 1369 fragmented IP packet. If the filter matches, then the data unit ID 1370 may be remembered and other fragments of the same packet may then 1371 be considered to match the same filter. Stateful filtering is more 1372 commonly done in firewalls, although firewall technology may be 1373 added to routers. Data unit ID can also be Fragmentation Extension 1374 Header in IPv6. 1376 o Actions based on Filter Results 1378 If a packet, or a series of packets, matches a specific filter, 1379 then a variety of actions which may be taken based on that match. 1380 Examples of such actions include: 1382 - Discard 1384 In many cases, filters are set to catch certain undesirable 1385 packets. Examples may include packets with forged or invalid source 1386 addresses, packets that are part of a DOS or Distributed DoS (DDOS) 1387 attack, or packets which are trying to access unallowed resources 1388 (such as network management packets from an unauthorized source). 1389 Where such filters are activated, it is common to discard the 1390 packet or set of packets matching the filter silently. The 1391 discarded packets may of course also be counted or logged. 1393 - Set CoS 1395 A filter may be used to set the Class of Service associated with 1396 the packet. 1398 - Count packets or bytes 1400 - Rate Limit 1402 In some cases the set of packets matching a particular filter may 1403 be limited to a specified bandwidth. In this case, packets or bytes 1404 would be counted, and would be forwarded normally up to the 1405 specified limit. Excess packets may be discarded or may be marked 1407 Fang, et al. Informational 29 1408 MPLS/GMPLS Security framework 1409 (for example by setting a "discard eligible" bit in the IP ToS 1410 field or the MPLS EXP field). 1412 - Forward and Copy 1414 It is useful in some cases to forward some set of packets normally, 1415 but also to send a copy to a specified other address or interface. 1416 For example, this may be used to implement a lawful intercept 1417 capability or to feed selected packets to an Intrusion Detection 1418 System. 1420 o Other Issues related to Use of Packet Filters 1422 Filtering performance may vary widely according to implementation 1423 and the types and number of rules. Without acceptable performance, 1424 filtering is not useful. 1426 The precise definition of "acceptable" may vary from SP to SP, and 1427 may depend upon the intended use of the filters. For example, for 1428 some uses a filter may be turned on all the time to set CoS, to 1429 prevent an attack, or to mitigate the effect of a possible future 1430 attack. In this case it is likely that the SP will want the filter 1431 to have minimal or no impact on performance. In other cases, a 1432 filter may be turned on only in response to a major attack (such as 1433 a major DDoS attack). In this case a greater performance impact may 1434 be acceptable to some service providers. 1436 A key consideration with the use of packet filters is that they can 1437 provide few options for filtering packets carrying encrypted data. 1438 Because the data itself is not accessible, only packet header 1439 information or other unencrypted fields can be used for filtering. 1441 5.3.2. Firewalls 1443 Firewalls provide a mechanism for control over traffic passing 1444 between different trusted zones in the MPLS/GMPLS model, or between 1445 a trusted zone and an untrusted zone. Firewalls typically provide 1446 much more functionality than filters, because they may be able to 1447 apply detailed analysis and logical functions to flows, and not 1448 just to individual packets. They may offer a variety of complex 1449 services, such as threshold-driven denial-of-service attack 1450 protection, virus scanning, acting as a TCP connection proxy, etc. 1452 As with other access control techniques, the value of firewalls 1453 depends on a clear understanding of the topologies of the 1454 MPLS/GMPLS core network, the user networks, and the threat model. 1455 Their effectiveness depends on a topology with a clearly defined 1456 inside (secure) and outside (not secure). 1458 Fang, et al. Informational 30 1459 MPLS/GMPLS Security framework 1460 Firewalls may be applied to help protect MPLS/GMPLS core network 1461 functions from attacks originating from the Internet or from 1462 MPLS/GMPLS user sites, but typically other defensive techniques 1463 will be used for this purpose. 1465 Where firewalls are employed as a service to protect user VPN sites 1466 from the Internet, different VPN users, and even different sites of 1467 a single VPN user, may have varying firewall requirements. The 1468 overall PPVPN logical and physical topology, along with the 1469 capabilities of the devices implementing the firewall services, has 1470 a significant effect on the feasibility and manageability of such 1471 varied firewall service offerings. 1473 Another consideration with the use of firewalls is that they can 1474 provide few options for handling packets carrying encrypted data. 1475 Because the data itself is not accessible, only packet header 1476 information, other unencrypted fields, or analysis of the flow of 1477 encrypted packets can be used for making decisions on accepting or 1478 rejecting encrypted traffic. 1480 Two approaches are to move the firewall outside of the encrypted 1481 part of the path or to register and pre-approve the encrypted 1482 session with the firewall. 1484 Handling DoS attacks has become increasingly important. Useful 1485 guidelines include the following: 1486 1. Perform ingress filtering everywhere. Upstream prevention is 1487 better. 1488 2. Be able to filter DoS attack packets at line speed. 1489 3. Do not allow oneself to amplify attacks. 1490 4. Continue processing legitimate traffic. Over provide for heavy 1491 loads. Use diverse locations, technologies, etc. 1493 5.3.3. Access Control to management interfaces 1495 Most of the security issues related to management interfaces can be 1496 addressed through the use of authentication techniques as described 1497 in the section on authentication. However, additional security may 1498 be provided by controlling access to management interfaces in other 1499 ways. 1501 The Optical Internetworking Forum has done good work on protecting 1502 such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. See OIF- 1503 SMI-01.0 "Security for Management Interfaces to Network Elements" 1504 [OIF-SMI-01.0], and "Addendum to the Security for Management 1505 Interfaces to Network Elements" [OIF-SMI-02.1]. See also the work 1506 in the ISMS WG. 1508 Fang, et al. Informational 31 1509 MPLS/GMPLS Security framework 1510 Management interfaces, especially console ports on MPLS/GMPLS 1511 devices, may be configured so they are only accessible out-of-band, 1512 through a system which is physically or logically separated from 1513 the rest of the MPLS/GMPLS infrastructure. 1515 Where management interfaces are accessible in-band within the 1516 MPLS/GMPLS domain, filtering or firewalling techniques can be used 1517 to restrict unauthorized in-band traffic from having access to 1518 management interfaces. Depending on device capabilities, these 1519 filtering or firewalling techniques can be configured either on 1520 other devices through which the traffic might pass, or on the 1521 individual MPLS/GMPLS devices themselves. 1523 5.4. Use of Isolated Infrastructure 1525 One way to protect the infrastructure used for support of 1526 MPLS/GMPLS is to separate the resources for support of MPLS/GMPLS 1527 services from the resources used for other purposes (such as 1528 support of Internet services). In some cases this may use 1529 physically separate equipment for VPN services, or even a 1530 physically separate network. 1532 For example, PE-based L3 VPNs may be run on a separate backbone not 1533 connected to the Internet, or may make use of separate edge routers 1534 from those used to support Internet service. Private IP addresses 1535 (local to the provider and non-routable over the Internet) are 1536 sometimes used to provide additional separation. 1538 5.5. Use of Aggregated Infrastructure 1540 In general, it is not feasible to use a completely separate set of 1541 resources for support of each service. In fact, one of the main 1542 reasons for MPLS/GMPLS enabled services is to allow sharing of 1543 resources between multiple users, including multiple VPNs, etc. 1544 Thus, even if certain services make use of a separate network from 1545 Internet services, nonetheless there will still be multiple 1546 MPLS/GMPLS users sharing the same network resources. In some cases 1547 MPLS/GMPLS services will share the use of network resources with 1548 Internet services or other services. 1550 It is therefore important for MPLS/GMPLS services to provide 1551 protection between resources used by different parties. Thus a 1552 well-behaved MPLS/GMPLS user should be protected from possible 1553 misbehavior by other users. This requires that limits are placed on 1555 Fang, et al. Informational 32 1556 MPLS/GMPLS Security framework 1557 the amount of resources used by any one VPN. For example, both 1558 control traffic and user data traffic may be rate limited. In some 1559 cases or in some parts of the network where a sufficiently large 1560 number of queues are available, each VPN (and optionally each VPN 1561 and CoS within the VPN) may make use of a separate queue. Control- 1562 plane resources such as link bandwidth as well as CPU and memory 1563 resources may be reserved on a per-VPN basis. 1565 The techniques used to provide resource protection between multiple 1566 users served by the same infrastructure can also be used to protect 1567 MPLS/GMPLS networks and services from Internet services. 1569 In general, the use of aggregated infrastructure allows the service 1570 provider to benefit from stochastic multiplexing of multiple bursty 1571 flows, and also may in some cases thwart traffic pattern analysis 1572 by combining the data from multiple users. 1574 5.6. Service Provider Quality Control Processes 1576 Deployment of provider-provisioned VPN services in general requires 1577 a relatively large amount of configuration by the SP. For example, 1578 the SP needs to configure which VPN each site belongs to, as well 1579 as QoS and SLA guarantees. This large amount of required 1580 configuration leads to the possibility of misconfiguration. 1582 It is important for the SP to have operational processes in place 1583 to reduce the potential impact of misconfiguration. CE-to-CE 1584 authentication may also be used to detect misconfiguration when it 1585 occurs. 1587 5.7. Deployment of Testable MPLS/GMPLS Service. 1589 This refers to solutions that can be readily tested to make sure 1590 they are configured correctly. For example, for a point-point 1591 connection, checking that the intended connectivity is working 1592 pretty much ensures that there is not connectivity to some 1593 unintended site. 1595 6. Monitoring, Detection, and Reporting of Security Attacks 1597 MPLS/GMPLS network and service may be subject to attacks from a 1598 variety of security threats. Many threats are described in another 1599 part of this document. Many of the defensive techniques described 1600 in this document and elsewhere provide significant levels of 1601 protection from a variety of threats. However, in addition to 1602 silently employing defensive techniques to protect against attacks, 1603 MPLS/GMPLS services can also add value for both providers and 1605 Fang, et al. Informational 33 1606 MPLS/GMPLS Security framework 1607 customers by implementing security monitoring systems to detect and 1608 report on any security attacks which occur, regardless of whether 1609 the attacks are effective. 1611 Attackers often begin by probing and analyzing defenses, so systems 1612 that can detect and properly report these early stages of attacks 1613 can provide significant benefits. 1615 Information concerning attack incidents, especially if available 1616 quickly, can be useful in defending against further attacks. It 1617 can be used to help identify attackers or their specific targets at 1618 an early stage. This knowledge about attackers and targets can be 1619 used to strengthen defenses against specific attacks or attackers, 1620 or improve the defensive services for specific targets on an as- 1621 needed basis. Information collected on attacks may also be useful 1622 in identifying and developing defenses against novel attack types. 1624 Monitoring systems used to detect security attacks in MPLS/GMPLS 1625 typically operate by collecting information from the Provider Edge 1626 (PE), Customer Edge (CE), and/or Provider backbone (P) devices. 1627 Security monitoring systems should have the ability to actively 1628 retrieve information from devices (e.g., SNMP get) or to passively 1629 receive reports from devices (e.g., SNMP notifications). The 1630 specific information exchanged depends on the capabilities of the 1631 devices and on the type of VPN technology. Particular care should 1632 be given to securing the communications channel between the 1633 monitoring systems and the MPLS/GMPLS devices. Syslog WG is 1634 specifying "Logging Capabilities for IP Network Infrastructure". 1635 (The specific references will be made only if the draft(s) became 1636 RFC before this draft.) 1638 The CE, PE, and P devices should employ efficient methods to 1639 acquire and communicate the information needed by the security 1640 monitoring systems. It is important that the communication method 1641 between MPLS/GMPLS devices and security monitoring systems be 1642 designed so that it will not disrupt network operations. As an 1643 example, multiple attack events may be reported through a single 1644 message, rather than allowing each attack event to trigger a 1645 separate message, which might result in a flood of messages, 1646 essentially becoming a denial-of-service attack against the 1647 monitoring system or the network. 1649 The mechanisms for reporting security attacks should be flexible 1650 enough to meet the needs of MPLS/GMPLS service providers, 1651 MPLS/GMPLS customers, and regulatory agencies, if applicable. The 1652 specific reports should depend on the capabilities of the devices, 1653 the security monitoring system, the type of VPN, and the service 1654 level agreements between the provider and customer. 1656 Fang, et al. Informational 34 1657 MPLS/GMPLS Security framework 1658 7. Service Provider General Security Requirements 1660 This section covers security requirements the provider may have for 1661 securing its MPLS/GMPLS network infrastructure including LDP and 1662 RSVP-TE specific requirements. 1664 The MPLS/GMPLS service provider's requirements defined here are for 1665 the MPLS/GMPLS core in the reference model. The core network can 1666 be implemented with different types of network technologies, and 1667 each core network may use different technologies to provide the 1668 various services to users with different levels of offered 1669 security. Therefore, a MPLS/GMPLS service provider may fulfill any 1670 number of the security requirements listed in this section. This 1671 document does not state that a MPLS/GMPLS network must fulfill all 1672 of these requirements to be secure. 1674 These requirements are focused on: 1) how to protect the MPLS/GMPLS 1675 core from various attacks outside the core including network users, 1676 both accidentally and maliciously, 2) how to protect the end users. 1678 7.1. Protection within the Core Network 1680 7.1.1. Control Plane Protection - General 1682 - Protocol authentication within the core: 1684 The network infrastructure must support mechanisms for 1685 authentication of the control plane. If MPLS/GMPLS core is used, 1686 LDP sessions may be authenticated by use TCP MD5, in addition, IGP 1687 and BGP authentication should also be considered. For a core 1688 providing Layer 2 services, PE-to-PE authentication may also be 1689 performed via IPsec. See the above discussion of protocol security 1690 services: authentication, integrity (with replay detection), 1691 confidentiality. Protocols need to provide a complete set of 1692 security services from which the SP can choose. Also, the hard part 1693 is key management. 1695 With the cost of authentication coming down rapidly, the 1696 application of control plane authentication may not increase the 1697 cost of implementation for providers significantly, and will help 1698 to improve the security of the core. If the core is dedicated to 1699 MPLS/GMPLS enabled services and without any interconnects to third 1700 parties then this may reduce the requirement for authentication of 1701 the core control plane. 1703 - Infrastructure Hiding 1705 Fang, et al. Informational 35 1706 MPLS/GMPLS Security framework 1707 Here we discuss means to hide the provider's infrastructure nodes. 1709 A MPLS/GMPLS provider may make its infrastructure routers (P and PE 1710 routers) unreachable from outside users and unauthorized internal 1711 users. For example, separate address space may be used for the 1712 infrastructure loopbacks. 1714 Normal TTL propagation may be altered to make the backbone look 1715 like one hop from the outside, but caution needs to be taken for 1716 loop prevention. This prevents the backbone addresses from being 1717 exposed through trace route; however this must also be assessed 1718 against operational requirements for end-to-end fault tracing. 1720 An Internet backbone core may be re-engineered to make Internet 1721 routing an edge function, for example, by using MPLS label 1722 switching for all traffic within the core and possibly make the 1723 Internet a VPN within the PPVPN core itself. This helps to detach 1724 Internet access from PPVPN services. 1726 Separating control plane, data plane, and management plane 1727 functionality in hardware and software may be implemented on the PE 1728 devices to improve security. This may help to limit the problems 1729 when attacked in one particular area, and may allow each plane to 1730 implement additional security measures separately. 1732 PEs are often more vulnerable to attack than P routers, because PEs 1733 cannot be made unreachable from outside users by their very nature. 1734 Access to core trunk resources can be controlled on a per user 1735 basis by using of inbound rate-limiting or traffic shaping; this 1736 can be further enhanced on a per Class of Service basis (see 1737 Section 8.2.3) 1739 In the PE, using separate routing processes for different services, 1740 for example, Internet and PPVPN service, may help to improve the 1741 PPVPN security and better protect VPN customers. Furthermore, if 1742 resources, such as CPU and Memory, can be further separated based 1743 on applications, or even individual VPNs, it may help to provide 1744 improved security and reliability to individual VPN customers. 1746 7.1.2. Control plane protection with RSVP-TE 1748 - RSVP Security Tools 1750 Isolation of the trusted domain is an important security mechanism 1751 for RSVP, to ensure that an untrusted element cannot access a 1752 router of the trusted domain. However, isolation is limited by the 1753 need to allow ASBR-ASBR communication for inter-AS LSPs. Isolation 1755 Fang, et al. Informational 36 1756 MPLS/GMPLS Security framework 1757 mechanisms might also be bypassed by Router Alert IP packets. A 1758 solution could consists of disabling the RSVP router alert mode and 1759 dropping all IP packets with the router alert option, or also to 1760 drop all incoming IP packets on an interface with port 46, which 1761 requires an access-list at the IP port level) or spoofed IP packets 1762 if anti-spoofing is not otherwise activated. 1764 RSVP security can be strengthened by deactivating RSVP on 1765 interfaces with neighbors who are not authorized to use RSVP, to 1766 protect against adjacent CE-PE attacks. However, this does not 1767 really protect against DoS attacks or attacks on non-adjacent 1768 routers. It has been demonstrated that substantial CPU resources 1769 are consumed simply by processing received RSVP packets, even if 1770 the RSVP process is deactivated for the specific interface on which 1771 the RSVP packets are received. 1773 RSVP neighbor filtering at the protocol level, to restrict the set 1774 of neighbors that can send RSVP messages to a given router, 1775 protects against non-adjacent attacks. However, this does not 1776 protect against DoS attacks and does not effectively protect 1777 against spoofing of the source address of RSVP packets, if the 1778 filter relies on the neighbor's address within the RSVP message. 1780 RSVP neighbor filtering at the data plane level (with an access 1781 list to accept IP packets with port 46, only for specific 1782 neighbors). This requires Router Alert mode to be deactivated and 1783 does not protect against spoofing. 1785 - Authentication for RSVP messages 1787 One of the most powerful tools for protection against RSVP-based 1788 attacks is the use of authentication for RSVP messages, based on a 1789 secure message hash using a key shared by RSVP neighbors. This 1790 protects against LSP creation attacks, at the expense of consuming 1791 significant CPU resources for digest computation. In addition, if 1792 the neighboring RSVP speaker is compromised, it could be used to 1793 launch attacks using authenticated RSVP messages. These methods, 1794 and certain other aspects of RSVP security, are explained in detail 1795 in RFC 4230 [RFC4230]. Key management must be implemented. Logging 1796 and auditing as well as multiple layers of crypto protection can 1797 help here. IPsec can also be used. 1799 Another valuable tool is RSVP message pacing, to limit the number 1800 of RSVP messages sent to a given neighbor during a given period. 1801 This allows blocking DoS attack propagation. 1803 The trick with DoS is to let the good packet through and keep 1804 operating. Rate limiting by itself needs to be selective do this. 1806 Fang, et al. Informational 37 1807 MPLS/GMPLS Security framework 1808 - limit the impact of an attack on control plane resources 1810 To ensure continued effective operation of the MPLS router even in 1811 the case of an attack that bypasses packet filtering mechanisms 1812 such as Access Control Lists in the data plane, it is important 1813 that routers have some mechanisms to limit the impact of the 1814 attack. There should be a mechanism to rate limit the amount of 1815 control plane traffic addressed to the router, per interface. This 1816 should be configurable on a per-protocol basis, (and, ideally, on a 1817 per-sender basis) to avoid letting an attacked protocol or a given 1818 sender blocking all communications. This requires the ability to 1819 filter and limit the rate of incoming messages of particular 1820 protocols, such as RSVP (filtering at the IP protocol level), and 1821 particular senders. In addition, there should be a mechanism to 1822 limit CPU and memory capacity allocated to RSVP, so as to protect 1823 other control plane elements. To limit the memory allocation, it 1824 will probably be necessary to limit the number of LSPs that can be 1825 set up. 1827 7.1.3. Control plane protection with LDP 1829 The approaches to protect MPLS routers against LDP-based attacks 1830 are similar to those for RSVP, including isolation, protocol 1831 deactivation on specific interfaces, filtering of LDP neighbors at 1832 the protocol level, filtering of LDP neighbors at the data plane 1833 level (access list that filter the TCP & UDP LDP ports), 1834 authentication with message digest, rate limiting of LDP messages 1835 per protocol per sender and limiting all resources allocated to 1836 LDP-related tasks. 1838 7.1.4. Data Plane Protection 1840 IPsec can provide authentication, integrity, confidentiality, and 1841 replay detection for provider or user data. It also has an 1842 associated key management protocol. 1844 In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is 1845 not provided as a basic feature. Mechanisms described in section 5 1846 can be used to secure the MPLS data plane traffic carried over MPLS 1847 core. Both the Frame Relay Forum and the ATM Forum standardized 1848 cryptographic security services in the late 1990s, but these 1849 standards are not widely implemented. 1851 Fang, et al. Informational 38 1852 MPLS/GMPLS Security framework 1853 7.2. Protection on the User Access Link 1855 Peer or neighbor protocol authentication may be used to enhance 1856 security. For example, BGP MD5 authentication may be used to 1857 enhance security on PE-CE links using eBGP. In the case of Inter- 1858 provider connection, cryptographic protection mechanisms between 1859 ASes, such as IPsec, may be used. 1861 If multiple services are provided on the same PE platform, 1862 different WAN link layer address spaces may be used for different 1863 services (e.g., VPN and non-VPN) to enhance isolation. 1865 Firewall and Filtering: access control mechanisms can be used to 1866 filter any packets destined for the service provider's 1867 infrastructure prefix or eliminate routes identified as 1868 illegitimate. 1870 Rate limiting may be applied to the user interface/logical 1871 interfaces against DDoS bandwidth attack. This is helpful when the 1872 PE device is supporting both multi-services, especially VPN and 1873 Internet Services, on the same physical interfaces through 1874 different logical interfaces. 1876 7.2.1. Link Authentication 1878 Authentication can be used to validate site access to the network 1879 via fixed or logical connections, e.g. L2TP, IPsec, respectively. 1880 If the user wishes to hold the authentication credentials for 1881 access to the VPN, then provider solutions require the flexibility 1882 for either direct authentication by the PE itself or interaction 1883 with a customer authentication server. Mechanisms are required in 1884 the latter case to ensure that the interaction between the PE and 1885 the customer authentication server is appropriately secured. 1887 7.2.2. Access Routing 1889 Routing protocol level e.g., RIP, OSPF, or BGP, may be used to 1890 provide control access between a CE and PE. Per neighbor and per 1891 VPN routing policies may be established to enhance security and 1892 reduce the impact of a malicious or non-malicious attack on the PE; 1893 the following mechanisms, in particular, should be considered: 1894 - Limiting the number of prefixes that may be advertised on 1895 a per access basis into the PE. Appropriate action may be 1896 taken should a limit be exceeded, e.g., the PE shutting 1897 down the peer session to the CE 1898 - Applying route dampening at the PE on received routing 1899 updates 1901 Fang, et al. Informational 39 1902 MPLS/GMPLS Security framework 1903 - Definition of a per VPN prefix limit after which 1904 additional prefixes will not be added to the VPN routing 1905 table. 1907 In the case of Inter-provider connection, access protection, link 1908 authentication, and routing policies as described above may be 1909 applied. Both inbound and outbound firewall or filtering mechanism 1910 between ASes may be applied. Proper security procedures must be 1911 implemented in Inter-provider VPN interconnection to protect the 1912 providers' network infrastructure and their customers' VPNs. This 1913 may be custom designed for each Inter-Provider VPN peering 1914 connection, and must be agreed upon by both providers. 1916 7.2.3. Access QoS 1918 MPLS/GMPLS providers offering QoS-enabled services require 1919 mechanisms to ensure that individual accesses are validated against 1920 their subscribed QOS profile and as such gain access to core 1921 resources that match their service profile. Mechanisms such as per 1922 Class of Service rate limiting or traffic shaping on ingress to the 1923 MPLS/GMPLS core are one option for providing this level of control. 1924 Such mechanisms may require the per Class of Service profile to be 1925 enforced either by marking, or remarking or discard of traffic 1926 outside of the profile. 1928 7.2.4. Customer service monitoring tools 1930 End users requiring specific statistics on the core, e.g., routing 1931 table, interface status, or QoS statistics, requirements for 1932 mechanisms at the PE both to validate the incoming user and limit 1933 the views available to that particular user. Mechanisms should 1934 also be considered to ensure that such access cannot be used a 1935 means of a DoS attack (either malicious or accidental) on the PE 1936 itself. This could be accomplished through either separation of 1937 these resources within the PE itself or via the capability to rate- 1938 limit on a per physical or logical connection basis such traffic. 1940 7.3. General Requirements for MPLS/GMPLS Providers 1942 MPLS/GMPLS providers must support users' security requirements as 1943 listed in Section 7. Depending on the technologies used, these 1944 requirements may include: 1946 - User control plane separation - routing isolation 1947 - Protection against intrusion, DoS attacks and spoofing 1948 - Access Authentication 1950 Fang, et al. Informational 40 1951 MPLS/GMPLS Security framework 1952 - Techniques highlighted through this document that identify 1953 methodologies for the protection of resources and the 1954 MPLS/GMPLS infrastructure. 1956 Hardware or software errors in equipment leading to breaches in 1957 security are not within the scope of this document. 1959 8. Inter-provider Security Requirements 1961 This section discusses security capabilities that are important at 1962 the MPLS/GMPLS Inter-provider connections and at devices (including 1963 ASBR routers) supporting these connections. The security 1964 capabilities stated in this section should be considered as 1965 complementary to security considerations addressed in individual 1966 protocol specifications or security frameworks. 1968 Security vulnerabilities and exposures may be propagated across 1969 multiple networks because of security vulnerabilities arising in 1970 one peer's network. Threats to security originate from accidental, 1971 administrative, and intentional sources. Intentional threats 1972 include events such as spoofing and Denial of Service (DoS) 1973 attacks. 1974 The level and nature of threats, as well as security and 1975 availability requirements, may vary over time and from network to 1976 network. This section therefore discusses capabilities that need to 1977 be available in equipment deployed for support of the MPLS 1978 InterCarrier Interconnect (MPLS-ICI). Whether any particular 1979 capability is used in any one specific instance of the ICI is up to 1980 the service providers managing the PE equipment offering/using the 1981 ICI services. 1983 8.1. Control Plane Protection 1985 This section discusses capabilities for control plane protection, 1986 including protection of routing, signaling, and OAM capabilities. 1988 8.1.1. Authentication of Signaling Sessions 1990 Authentication is needed for signaling sessions (i.e., BGP, LDP and 1991 RSVP-TE) and routing sessions (e.g., BGP) as well as OAM sessions 1992 across domain boundaries. Equipment must be able to support 1993 exchange of all protocol messages over a single IPsec tunnel, with 1994 NULL encryption and authentication, between the peering ASBRs. 1995 Support for TCP MD5 authentication for LDP and BGP and for RSVP-TE 1996 authentication must also be provided. Manual keying of IPsec should 1997 not be used. IKEv2 with pre-shared secrets or public key methods 1998 should be used. Replay detection should be used. 2000 Fang, et al. Informational 41 2001 MPLS/GMPLS Security framework 2002 Mechanisms to authenticate and validate a dynamic setup request 2003 MUST be available. For instance, if dynamic signaling of a TE-LSP 2004 or PW is crossing a domain boundary, there must be a way to detect 2005 whether the LSP source is who it claims to be and that he is 2006 allowed to connect to the destination. 2008 MD5 authentication support for all TCP-based protocols within the 2009 scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and MD5 2010 authentication for the RSVP-TE Integrity Object MUST be provided to 2011 interoperate with current practices. 2012 Equipment SHOULD be able to support exchange of all signaling and 2013 routing (LDP, RSVP-TE, and BGP) protocol messages over a single 2014 IPSec security association pair in tunnel or transport mode with 2015 authentication but with NULL encryption, between the peering ASBRs. 2016 IPSec, if supported, must be supported with HMAC-MD5 and optionally 2017 SHA-1. It is expected that authentication algorithms will evolve 2018 over time and support can be updated as needed. 2020 OAM Operations across the MPLS-ICI could also be the source of 2021 security threats on the provider infrastructure as well as the 2022 service offered over the MPLS-ICI. A large volume of OAM messages 2023 could overwhelm the processing capabilities of an ASBR if the ASBR 2024 is not properly protected. Maliciously generated OAM messages could 2025 also be used to bring down an otherwise healthy service (e.g., MPLS 2026 Pseudo Wire), and therefore affect service security. MPLS-ping does 2027 not support authentication today, and that support should be 2028 subject for future considerations. Bidirectional Forwarding 2029 Detection (BFD), however, does have support for carrying an 2030 authentication object. It also supports Time-To-Live (TTL) 2031 processing as an anti-replay measure. Implementations conformant 2032 with this MPLS-ICI should support BFD authentication using MD5 and 2033 must support the procedures for TTL processing. 2035 8.1.2. Protection against DoS attacks in the Control Plane 2037 Implementation must have the ability to prevent signaling and 2038 routing DoS attacks on the control plane per interface and 2039 provider. Such prevention may be provided by rate-limiting 2040 signaling and routing messages that can be sent by a peer provider 2041 according to a traffic profile and by guarding against malformed 2042 packets. 2044 Equipment MUST provide the ability to filter signaling, routing, 2045 and OAM packets destined for the device, and MUST provide the 2046 ability to rate limit such packets. Packet filters SHOULD be 2047 capable of being separately applied per interface, and SHOULD have 2048 minimal or no performance impact. For example, this allows an 2050 Fang, et al. Informational 42 2051 MPLS/GMPLS Security framework 2052 operator to filter or rate-limit signaling, routing, and OAM 2053 messages that can be sent by a peer provider and limit such traffic 2054 to a given profile. 2056 During a control plane DoS attack against an ASBR, the router 2057 SHOULD guarantee sufficient resources to allow network operators to 2058 execute network management commands to take corrective action, such 2059 as turning on additional filters or disconnecting an interface 2060 under attack. DoS attacks on the control plane SHOULD NOT adversely 2061 affect data plane performance. 2062 Equipment running BGP MUST support the ability to limit the number 2063 of BGP routes received from any particular peer. Furthermore, in 2064 the case of IPVPN, a router MUST be able to limit the number of 2065 routes learned from a BGP peer per IPVPN. In the case that a device 2066 has multiple BGP peers, it SHOULD be possible for the limit to vary 2067 between peers. 2069 8.1.3. Protection against Malformed Packets 2071 Equipment SHOULD be robust in the presence of malformed protocol 2072 packets. For example, malformed routing, signaling, and OAM packets 2073 should be treated in accordance to the relevant protocol 2074 specification. 2076 8.1.4. Ability to Enable/Disable Specific Protocols 2078 Ability to drop any signaling or routing protocol messages when 2079 these messages are to be processed by the ASBR but the 2080 corresponding protocol is not enabled on that interface. 2082 Equipment must allow an administrator to enable or disable a 2083 protocol (default protocol is disabled unless administratively 2084 enable) on an interface basis. 2086 Equipment MUST be able to drop any signaling or routing protocol 2087 messages when these messages are to be processed by the ASBR but 2088 the corresponding protocol is not enabled on that interface. This 2089 dropping SHOULD NOT adversely affect data plane or control plane 2090 performance. 2092 8.1.5. Protection Against Incorrect Cross Connection 2094 The capability of detecting and locating faults in a LSP cross- 2095 connect MUST be provided. Such faults may cause security violations 2096 as they result in directing traffic to the wrong destinations. This 2097 capability may rely on OAM functions. 2099 Fang, et al. Informational 43 2100 MPLS/GMPLS Security framework 2101 Equipment MUST support MPLS LSP Ping [RFC4379]. This MAY be used to 2102 verify end to end connectivity for the LSP (e.g., PW, TE Tunnel, 2103 VPN LSP, etc.), and to verify PE-to-PE connectivity for L3 VPN 2104 services. 2106 When routing information is advertised from one domain to the 2107 other, operators must be able to guard against situations that 2108 result in traffic hijacking, black-holing, resource stealing (e.g., 2109 number of routes), etc. For instance, in the IPVPN case, an 2110 operator must be able to block routes based on associated route 2111 target attributes. In addition, mechanisms must exist to verify 2112 whether a route advertised by a peer for a given VPN is actually a 2113 valid route and whether the VPN has a site attached or reachable 2114 through that domain. 2116 Equipment (ASBRs and Route Reflectors (RRs)) supporting operation 2117 of BGP MUST be able to restrict which Route Target attributes are 2118 sent to and accepted from a BGP peer across an ICI. Equipment 2119 (ASBRs, RRs) SHOULD also be able to inform the peer regarding which 2120 Route Target attributes it will accept from a peer, because sending 2121 an incorrect Route Target can result in incorrect cross-connection 2122 of VPNs. Also, sending inappropriate route targets to a peer may 2123 disclose confidential information. Further Security Consideration 2124 for inter-provider BGP/MPLS IPVPN operations are discussed in the 2125 IPVPN Annex. 2127 8.1.6. Protection Against Spoofed Updates and Route Advertisements 2129 Equipment MUST support route filtering of routes received via a BGP 2130 peer sessions by applying policies that include one or more the 2131 following: AS path, BGP next hop, standard community or extended 2132 community. 2134 8.1.7. Protection of Confidential Information 2136 Ability to identify and prohibit messages that can reveal 2137 confidential information about network operation (e.g., performance 2138 OAM messages or MPLS-ping messages) is required. Service Providers 2139 must have the flexibility of handling these messages at the ASBR. 2141 Equipment SHOULD provide the ability to identify and restrict where 2142 it sends messages or that can reveal confidential information about 2143 network operation (e.g., performance OAM messages, LSP Traceroute 2144 messages). Service Providers must have the flexibility of handling 2145 these messages at the ASBR. For example, equipment supporting LSP 2146 Traceroute MAY limit to which addresses replies can be sent. 2147 Note: This capability should be used with care. For example, if a 2148 service provider chooses to prohibit the exchange of LSP PING 2150 Fang, et al. Informational 44 2151 MPLS/GMPLS Security framework 2152 messages at the ICI, it may make it more difficult to debug 2153 incorrect cross-connection of LSPs or other problems. 2154 A provider may decide to progress these messages if they are 2155 incoming from a trusted provider and are targeted to specific 2156 agreed-on addresses. Another provider may decide to traffic police, 2157 reject, or apply policies to these messages. Solutions must enable 2158 providers to control the information that is relayed to another 2159 provider about the path that a LSP takes. For example, in RSVP-TE 2160 record route object or MPLS-ping trace, a provider must be able to 2161 control the information contained in corresponding messages when 2162 sent to another provider. 2164 8.1.8. Protection Against over-provisioned number of RSVP-TE LSPs 2165 and bandwidth reservation 2167 In addition to the control plane protection mechanisms listed in 2168 the previous section on Control plane protection with RSVP-TE, the 2169 ASBR must be able both to limit the number of LSPs that can be set 2170 up by other domains and to limit the amount of bandwidth that can 2171 be reserved. A provider's ASBR may deny a LSP set up request or a 2172 bandwidth reservation request sent by another provider's whose the 2173 limits have been reached. 2175 8.2. Data Plane Protection 2177 8.2.1. Protection against DoS in the Data Plane 2178 This is described earlier in this document. 2180 8.2.2. Protection against Label Spoofing 2182 Verification that a label received across an interconnect was 2183 actually assigned to the provider across the interconnect. If the 2184 label was not assigned to the provider, the packet MUST be dropped. 2186 Equipment MUST be able to verify that a label received across an 2187 interconnect was actually assigned to a LSP arriving from the 2188 provider across that interconnect. If the label was not assigned to 2189 a LSP which arrives at this router from the correct neighboring 2190 provider, the packet MUST be dropped. This verification can be 2191 applied to the top label only. The top label is the received top 2192 label and every label that is exposed by label popping to be used 2193 for forwarding decisions. 2195 Equipment MUST provide the capability of dropping MPLS-labeled 2196 packets if all labels in the stack are not processed. This lets 2197 carriers guarantee that every label that enters its domain from 2198 another carrier was actually assigned to that carrier. 2200 Fang, et al. Informational 45 2201 MPLS/GMPLS Security framework 2202 The following requirements are not directly reflected in this 2203 document but must be used as guidance for addressing further work. 2205 Solutions MUST NOT force operators to reveal reachability 2206 information to routers within their domains. ||< AS1 >| 2226 Traffic flow direction is from SP2 to SP1 2228 Usually, the transit label used by ASBR2 is allocated by ASBR1, 2229 which in turn advertises it to ASB2 (downstream unsolicited or on- 2230 demand), and this label is used for a service context (VPN label, 2231 PW VC label, etc.), and this LSP is normally terminated at a 2232 forwarding table belonging to the service instance on PE (PE1) in 2233 SP1. 2235 In the example above, ASBR1 would not know whether the label of an 2236 incoming packet from ASBR2 over the interconnect is a VPN label or 2237 PSN label for AS1. So it is possible (though rare) that ASBR2 can 2238 be tempered such that the incoming label could match a PSN label 2239 (e.g., LDP) in AS1. Then, this LSP would end up on the global plane 2240 of an infrastructure router (P or PE1), and this could invite a 2241 unidirectional attack on that P or PE1 where the LSP terminates. 2243 To mitigate this threat, implementations SHOULD be able to do a 2244 forwarding path look-up for the label on an incoming packet from an 2245 interconnect in a Label Forwarding Information Base (LFIB) space 2246 that is only intended for its own service context or provide a 2247 mechanism on the data plane that would ensure the incoming labels 2248 are what ASBR1 has allocated and advertised. 2250 Fang, et al. Informational 46 2251 MPLS/GMPLS Security framework 2252 A similar concept has been proposed in "Requirements for Multi- 2253 Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [PW-REQ]. 2255 9. Security Considerations 2257 Security considerations constitute the sole subject of this memo 2258 and hence are discussed throughout. Here we recap what has been 2259 presented and explain at a high level the role of each type of 2260 consideration in an overall secure MPLS/GMPLS system. 2262 The document describes a number of potential security threats. 2263 Some of these threats have already been observed occurring in 2264 running networks; others are largely theoretical at this time. 2266 DoS attacks and intrusion attacks from the Internet against service 2267 providers' infrastructure have been seen. DOS "attacks" (typically 2268 not malicious) have also been seen in which CE equipment overwhelms 2269 PE equipment with high quantities or rates of packet traffic or 2270 routing information. Operational or provisioning errors are cited 2271 by service providers as one of their prime concerns. 2273 The document describes a variety of defensive techniques that may 2274 be used to counter the suspected threats. All of the techniques 2275 presented involve mature and widely implemented technologies that 2276 are practical to implement. 2278 The document describes the importance of detecting, monitoring, and 2279 reporting attacks, both successful and unsuccessful. These 2280 activities are essential for "understanding one's enemy", 2281 mobilizing new defenses, and obtaining metrics about how secure the 2282 MPLS/GMPLS network is. As such, they are vital components of any 2283 complete PPVPN security system. 2285 The document evaluates MPLS/GMPLS security requirements from a 2286 customer's perspective as well as from a service provider's 2287 perspective. These sections re-evaluate the identified threats 2288 from the perspectives of the various stakeholders and are meant to 2289 assist equipment vendors and service providers, who must ultimately 2290 decide what threats to protect against in any given configuration 2291 or service offering. 2293 10. IANA Considerations 2294 TBD. 2296 Fang, et al. Informational 47 2297 MPLS/GMPLS Security framework 2298 11. Normative References 2300 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 2301 Switching Architecture", RFC 3031, January 2001. 2303 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 2304 (GMPLS) Architecture", RFC 3945, October 2004. 2306 [RFC3036] Andersson, et al., "LDP Specification", January 2001. 2308 [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 2309 Tunnels", December 2001. 2311 [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet 2312 Protocol," December 2005. 2314 [RFC4302] S. Kent, "IP Authentication Header," December 2005. 2316 [RFC4835] V. Manral, "Cryptographic Algorithm Implementation 2317 Requirements for Encapsulating Security Payload (ESP) and 2318 Authentication Header (AH)", April 2007. 2320 [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) 2321 Protocol",December 2005. 2323 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) 2324 CCM Mode with IPsec Encapsulating Security Payload (ESP)", December 2325 2005. 2327 [RFC4346] T. Dierks and E. Rescorla, "The Transport Layer Security 2328 (TLS) Protocol, Version 1.1," April 2006. 2330 [RFC4379] K. Kompella and G. Swallow, "Detecting Multi-Protocol 2331 Label Switched (MPLS) Data Plane Failures", February 2006. 2333 [RFC4447] Martini, et al., "Pseudowire Setup and Maintenance Using 2334 the Label Distribution Protocol (LDP)", April 2006. 2336 [STD62] "Simple Network Management Protocol, Version 3,", December 2337 2002. 2339 [STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification", 2340 STD 8, May 1983. 2342 Fang, et al. Informational 48 2343 MPLS/GMPLS Security framework 2344 12. Informational References 2346 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2347 Requirement Levels", BCP 14, RFC 2119, March 1997 2349 [Beard] D. Beard and Y. Yang, "Known Threats to Routing Protocols," 2350 draft-beard-rpsec-routing-threats-01.txt, Feb. 2003. (Note, this is 2351 now approved as RFC, no number yet, http://www.ietf.org/internet- 2352 drafts/draft-ietf-rpsec-routing-threats-06.txt. 2354 [OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces 2355 to Network Elements", Optical Internetworking Forum, Sept. 2003. 2357 [OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for 2358 Management Interfaces to Network Elements", Optical Internetworking 2359 Forum, March 2006. 2361 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 2362 for Message Authentication," February 1997. 2364 [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 2365 Roadmap," November 1998. 2367 [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 2368 1 (SHA1)," September 2001. 2370 [RFC3562] M. Leech, "Key Management Considerations for the TCP MD5 2371 Signature Option", July 2003. 2373 [RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security 2374 Mechanisms for the Internet," December 2003. 2376 [RFC3985] S. Bryant and P. Pate, "Pseudo Wire Emulation Edge-to- 2377 Edge (PWE3) Architecture", March 2005. 2379 [RFC4103] G. Hellstrom and P. Jones, "RTP Payload for Text 2380 Conversation", June 2005. 2382 [RFC4107] S. Bellovin, R. Housley, "Guidelines for Cryptographic 2383 Key Management", June 2005. 2385 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 2386 Provider-Provisioned Virtual Private Networks (PPVPNs)", July 2005. 2388 Fang, et al. Informational 49 2389 MPLS/GMPLS Security framework 2391 [RFC4111] L. Fang, "Security Framework of Provider Provisioned 2392 VPN", RFC 4111, July 2005. 2394 [RFC4230] H. Tschofenig and R. Graveman, "RSVP Security 2395 Properties", December 2005. 2397 [RFC4308] P. Hoffman, "Cryptographic Suites for IPsec", December 2398 2005. 2400 [RFC4808] S. Bellovin, "Key Change Strategies for TCP-MD5", March 2401 2007. 2403 [RFC4869] L. Law and J. Solinas, "Suite B Cryptographic Suites for 2404 IPsec", April 2007. 2406 [MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical 2407 Specification", MFA2006.109.01, August 2006. 2409 [opsec efforts] C. Lonvick and D. Spak, "Security Best Practices 2410 Efforts and Documents", draft-ietf-opsec-efforts-05.txt, December 2411 2006. 2413 [PW-REQ] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi- 2414 Segment Pseudowire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw- 2415 requirements-05.txt, March 2007. 2417 13. Author's Addresses 2419 Luyuan Fang 2420 Cisco Systems, Inc. 2421 300 Beaver Brook Road 2422 Boxborough, MA 01719 2423 USA 2425 Email: lufang@cisco.com 2427 Michael Behringer 2428 Cisco Systems, Inc. 2429 Village d'Entreprises Green Side 2430 400, Avenue Roumanille, Batiment T 3 2431 06410 Biot, Sophia Antipolis 2432 FRANCE 2434 Fang, et al. Informational 50 2435 MPLS/GMPLS Security framework 2436 Email: mbehring@cisco.com 2438 Ross Callon 2439 Juniper Networks 2440 10 Technology Park Drive 2441 Westford, MA 01886 2442 USA 2444 Email: rcallon@juniper.net 2446 Jean-Louis Le Roux 2447 France Telecom 2448 2, avenue Pierre-Marzin 2449 22307 Lannion Cedex 2450 FRANCE 2452 Email: jeanlouis.leroux@francetelecom.com 2454 Raymond Zhang 2455 British Telecom 2456 2160 E. Grand Ave. El Segundo, CA 90025 2457 USA 2459 Email: raymond.zhang@bt.com 2461 Paul Knight 2462 Nortel 2463 600 Technology Park Drive 2464 Billerica, MA 01821 2466 Email: paul.knight@nortel.com 2468 Yaakov (Jonathan) Stein 2469 RAD Data Communications 2470 24 Raoul Wallenberg St., Bldg C 2471 Tel Aviv 69719 2472 ISRAEL 2474 Email: yaakov_s@rad.com 2476 Nabil Bitar 2477 Verizon 2478 40 Sylvan Road 2479 Waltham, MA 02145 2480 Email: nabil.bitar@verizon.com 2482 Fang, et al. Informational 51 2483 MPLS/GMPLS Security framework 2484 Richard Graveman 2485 RFG Security 2486 15 Park Avenue 2487 Morristown, NJ 07960 2489 Email: rfg@acm.org 2491 Intellectual Property 2493 The IETF takes no position regarding the validity or scope of any 2494 Intellectual Property Rights or other rights that might be claimed 2495 to pertain to the implementation or use of the technology described 2496 in this document or the extent to which any license under such 2497 rights might or might not be available; nor does it represent that 2498 it has made any independent effort to identify any such rights. 2499 Information on the procedures with respect to rights in RFC 2500 documents can be found in BCP 78 and BCP 79. 2502 Copies of IPR disclosures made to the IETF Secretariat and any 2503 assurances of licenses to be made available, or the result of an 2504 attempt made to obtain a general license or permission for the use 2505 of such proprietary rights by implementers or users of this 2506 specification can be obtained from the IETF on-line IPR repository 2507 at http://www.ietf.org/ipr. 2509 The IETF invites any interested party to bring to its attention any 2510 copyrights, patents or patent applications, or other proprietary 2511 rights that may cover technology that may be required to implement 2512 this standard. Please address the information to the IETF at ietf- 2513 ipr@ietf.org. 2515 Full Copyright Statement 2517 Copyright (C) The IETF Trust (2007). 2519 This document is subject to the rights, licenses and restrictions 2520 contained in BCP 78, and except as set forth therein, the authors 2521 retain all their rights. 2523 Fang, et al. Informational 52 2524 MPLS/GMPLS Security framework 2525 This document and the information contained herein are provided on 2526 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2527 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2528 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2529 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2530 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2531 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2532 FOR A PARTICULAR PURPOSE. 2534 Intellectual Property 2536 The IETF takes no position regarding the validity or scope of any 2537 Intellectual Property Rights or other rights that might be claimed 2538 to pertain to the implementation or use of the technology described 2539 in this document or the extent to which any license under such 2540 rights might or might not be available; nor does it represent that 2541 it has made any independent effort to identify any such rights. 2542 Information on the procedures with respect to rights in RFC 2543 documents can be found in BCP 78 and BCP 79. 2545 Copies of IPR disclosures made to the IETF Secretariat and any 2546 assurances of licenses to be made available, or the result of an 2547 attempt made to obtain a general license or permission for the use 2548 of such proprietary rights by implementers or users of this 2549 specification can be obtained from the IETF on-line IPR repository 2550 at http://www.ietf.org/ipr. 2552 The IETF invites any interested party to bring to its attention any 2553 copyrights, patents or patent applications, or other proprietary 2554 rights that may cover technology that may be required to implement 2555 this standard. Please address the information to the IETF at ietf- 2556 ipr@ietf.org. 2558 14. Acknowledgements 2560 Funding for the RFC Editor function is provided by the IETF 2561 Administrative Support Activity (IASA). 2563 The author and contributors would also like to acknowledge the 2564 helpful comments and suggestions from Sam Hartman and Adrian Farrel. 2566 Fang, et al. Informational 53