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