idnits 2.17.1 draft-ietf-mpls-mpls-and-gmpls-security-framework-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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.) -- however, there's a paragraph with a matching beginning. Boilerplate error? -- The document date (July 13, 2009) is 5373 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 4869 (Obsoleted by RFC 6379) == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-05 Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 13, 2010 7 July 13, 2009 9 Security Framework for MPLS and GMPLS Networks 10 draft-ietf-mpls-mpls-and-gmpls-security-framework-06.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 8, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your 44 rights and restrictions with respect to this document. 46 This document may contain material from IETF Documents or IETF 47 Contributions published or made publicly available before November 48 10, 2008. The person(s) controlling the copyright in some of this 49 material may not have granted the IETF Trust the right to allow 50 MPLS/GMPLS Security framework 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages 57 other than English. 59 Abstract 61 This document provides a security framework for Multiprotocol Label 62 Switching (MPLS) and Generalized Multiprotocol Label Switching 63 (GMPLS) Networks. This document addresses the security aspects that 64 are relevant in the context of MPLS and GMPLS. It describes the 65 security threats, the related defensive techniques, and the 66 mechanisms for detection and reporting. This document emphasizes 67 RSVP-TE and LDP security considerations, as well as Inter-AS and 68 Inter-provider security considerations for building and maintaining 69 MPLS and GMPLS networks across different domains or different 70 Service Providers. 72 Table of Contents 74 1. Introduction..................................................3 75 Authors and Contributors.........................................4 76 2. Terminology...................................................5 77 2.1. Acronyms and Abbreviations.................................5 78 2.2. Terminology................................................6 79 3. Security Reference Models.....................................8 80 4. Security Threats.............................................10 81 4.1. Attacks on the Control Plane..............................11 82 4.2. Attacks on the Data Plane.................................14 83 4.3. Attacks on Operation and Management Plane.................17 84 5. Defensive Techniques for MPLS/GMPLS Networks.................18 85 5.1. Authentication............................................19 86 5.2. Cryptographic Techniques..................................21 87 5.3. Access Control Techniques.................................31 88 5.4. Use of Isolated Infrastructure............................35 89 5.5. Use of Aggregated Infrastructure..........................36 90 5.6. Service Provider Quality Control Processes................36 91 5.7. Deployment of Testable MPLS/GMPLS Service.................37 92 5.8. Verification of Connectivity..............................37 93 6. Monitoring, Detection, and Reporting of Security Attacks.....37 94 MPLS/GMPLS Security framework 95 7. Service Provider General Security Requirements...............38 96 7.1. Protection within the Core Network........................39 97 7.2. Protection on the User Access Link........................43 98 7.3. General User Requirements for MPLS/GMPLS Providers........44 99 8. Inter-provider Security Requirements.........................45 100 8.1. Control Plane Protection..................................45 101 8.2. Data Plane Protection.....................................49 102 9. Summary of MPLS and GMPLS Security...........................51 103 9.1. MPLS and GMPLS Specific Security Threats..................51 104 9.2. Defense Techniques........................................52 105 9.3. Service Provider MPLS and GMPLS Best Practice Outlines....53 106 10. Security Considerations....................................54 107 11. IANA Considerations........................................55 108 12. Normative References.......................................55 109 13. Informative References.....................................56 110 14. Author's Addresses.........................................58 111 15. Acknowledgements...........................................60 113 1. Introduction 115 Security is an important aspect of all networks, MPLS and GMPLS 116 networks being no exception. 118 MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Various 119 security considerations have been addressed in each of the many 120 RFCs on MPLS and GMPLS technologies, but no single document covers 121 general security considerations. The motivation for creating this 122 document is to provide a comprehensive and consistent security 123 framework for MPLS and GMPLS networks. Each individual document may 124 point to this document for general security considerations in 125 addition to providing security considerations specific to the 126 particular technologies the document is describing. 128 In this document, we first describe the security threats relevant 129 in the context of MPLS and GMPLS and the defensive techniques to 130 combat those threats. We consider security issues resulting both 131 from malicious or incorrect behavior of users and other parties and 132 from negligent or incorrect behavior of providers. An important 133 part of security defense is the detection and reporting of a 134 security attack, which is also addressed in this document. 136 We then discuss possible service provider security requirements in 137 a MPLS or GMPLS environment. Users have expectations for the 138 MPLS/GMPLS Security framework 139 security characteristics of MPLS or GMPLS networks. These include 140 security requirements for equipment supporting MPLS and GMPLS and 141 operational security requirements for providers. Service providers 142 must protect their network infrastructure and make it secure to the 143 level required to provide services over their MPLS or GMPLS 144 networks. 146 Inter-AS and Inter-provider security are discussed with special 147 emphasis, because the security risk factors are higher with inter- 148 provider connections. Note that Inter-carrier MPLS security is also 149 considered in [MFA MPLS ICI]. 151 Depending on different MPLS or GMPLS techniques used, the degree of 152 risk and the mitigation methodologies vary. This document discusses 153 the security aspects and requirements for certain basic MPLS and 154 GMPLS techniques and inter-connection models. This document does 155 not attempt to cover all current and future MPLS and GMPLS 156 technologies, as it is not within the scope of this document to 157 analyze the security properties of specific technologies. 159 It is important to clarify that, in this document, we limit 160 ourselves to describing the providers' security requirements that 161 pertain to MPLS and GMPLS networks. Readers may refer to the 162 "Security Best Practices Efforts and Documents" [opsec effort] and 163 "Security Mechanisms for the Internet" [RFC3631] for general 164 network operation security considerations. It is not our intention, 165 however, to formulate precise "requirements" for each specific 166 technology in terms of defining the mechanisms and techniques that 167 must be implemented to satisfy such security requirements. 169 This document has used relevant content from RFC 4111 "Security 170 Framework of Provider Provisioned VPN for Provider-Provisioned 171 Virtual Private Networks (PPVPNs)" [RFC4111]. We acknowledge the 172 authors of RFC 4111 for the valuable information and text. 174 Authors and Contributors 176 Authors: 177 Luyuan Fang, Ed., Cisco Systems, Inc. 178 Michael Behringer, Cisco Systems, Inc. 179 Ross Callon, Juniper Networks 180 Richard Graveman, RFG Security, LLC 181 J. L. Le Roux, France Telecom 182 Raymond Zhang, British Telecom 183 Paul Knight, Individual Contributor 184 Yaakov Stein, RAD Data Communications 185 Nabil Bitar, Verizon 186 MPLS/GMPLS Security framework 187 Monique Morrow, Cisco Systems, Inc. 188 Adrian Farrel, Old Dog Consulting 190 As a design team member for the MPLS Security Framework, Jerry Ash 191 also made significant contributions to this document. 193 2. Terminology 195 2.1. Acronyms and Abbreviations 197 AS Autonomous System 198 ASBR Autonomous System Border Router 199 ATM Asynchronous Transfer Mode 200 BGP Border Gateway Protocol 201 BFD Bidirectional Forwarding Detection 202 CE Customer-Edge device 203 CoS Class of Service 204 CPU Central Processing Unit 205 DNS Domain Name System 206 DoS Denial of Service 207 ESP Encapsulating Security Payload 208 FEC Forwarding Equivalence Class 209 GMPLS Generalized Multi-Protocol Label Switching 210 GCM Galois Counter Mode 211 GRE Generic Routing Encapsulation 212 ICI InterCarrier Interconnect 213 ICMP Internet Control Message Protocol 214 ICMPv6 ICMP in IP Version 6 215 IGP Interior Gateway Protocol 216 IKE Internet Key Exchange 217 IP Internet Protocol 218 IPsec IP Security 219 IPVPN IP-based VPN 220 LDP Label Distribution Protocol 221 L2TP Layer 2 Tunneling Protocol 222 LMP Link Management Protocol 223 LSP Label Switched Path 224 LSR Label Switching Router 225 MD5 Message Digest Algorithm 226 MPLS MultiProtocol Label Switching 227 MP-BGP Multi-Protocol BGP 228 NTP Network Time Protocol 229 OAM Operations, Administration, and Management 230 PCE Path Computation Element 231 PE Provider-Edge device 232 PPVPN Provider-Provisioned Virtual Private Network 233 PSN Packet-Switched Network 235 MPLS/GMPLS Security framework 236 PW Pseudowire 237 QoS Quality of Service 238 RR Route Reflector 239 RSVP Resource Reservation Protocol 240 RSVP-TE Resource Reservation Protocol with Traffic Engineering 241 Extensions 242 SLA Service Level Agreement 243 SNMP Simple Network Management Protocol 244 SP Service Provider 245 SSH Secure Shell 246 SSL Secure Sockets Layer 247 SYN Synchronize packet in TCP 248 TCP Transmission Control Protocol 249 TDM Time Division Multiplexing 250 TE Traffic Engineering 251 TLS Transport Layer Security 252 ToS Type of Service 253 TTL Time-To-Live 254 UDP User Datagram Protocol 255 VC Virtual Circuit 256 VPN Virtual Private Network 257 WG Working Group of IETF 258 WSS Web Services Security 260 2.2. Terminology 262 This document uses MPLS and GMPLS specific terminology. Definitions 263 and details about MPLS and GMPLS terminology can be found in 264 [RFC3031] and [RFC3945]. The most important definitions are 265 repeated in this section; for other definitions the reader is 266 referred to [RFC3031] and [RFC3945]. 268 Core network: A MPLS/GMPLS core network is defined as the central 269 network infrastructure which consists of P and PE routers. A 270 MPLS/GMPLS core network may consist of one or more networks 271 belonging to a single SP. 273 Customer Edge (CE) device: A Customer Edge device is a router or a 274 switch in the customer's network interfacing with the Service 275 Provider's network. 277 Forwarding Equivalence Class (FEC): A group of IP packets that are 278 forwarded in the same manner (e.g., over the same path, with the 279 same forwarding treatment). 281 Label: A short, fixed length, physically contiguous identifier, 282 usually of local significance. 284 MPLS/GMPLS Security framework 285 Label merging: the replacement of multiple incoming labels for a 286 particular FEC with a single outgoing label. 288 Label Switched Hop: A hop between two MPLS nodes, on which 289 forwarding is done using labels. 291 Label Switched Path (LSP): The path through one or more LSRs at one 292 level of the hierarchy followed by a packets in a particular FEC. 294 Label Switching Routers (LSRs): An MPLS/GMPLS node assumed to have 295 a forwarding plane that is capable of (a) recognizing either packet 296 or cell boundaries, and (b) being able to process either packet 297 headers or cell headers. 299 Loop Detection: A method of dealing with loops in which loops are 300 allowed to be set up, and data may be transmitted over the loop, 301 but the loop is later detected. 303 Loop Prevention: A method of dealing with loops in which data is 304 never transmitted over a loop. 306 Label Stack: An ordered set of labels. 308 Merge Point: A node at which label merging is done. 310 MPLS Domain: A contiguous set of nodes that perform MPLS routing 311 and forwarding and are also in one Routing or Administrative 312 Domain. 314 MPLS Edge Node: A MPLS node that connects a MPLS domain with a node 315 outside of the domain, either because it does not run MPLS, or 316 because it is in a different domain. Note that if a LSR has a 317 neighboring host not running MPLS, then that LSR is a MPLS edge 318 node. 320 MPLS Egress Node: A MPLS edge node in its role in handling traffic 321 as it leaves a MPLS domain. 323 MPLS Ingress Node: A MPLS edge node in its role in handling traffic 324 as it enters a MPLS domain. 326 MPLS Label: A label carried in a packet header, which represents 327 the packet's FEC. 329 MPLS Node: A node running MPLS. A MPLS node is aware of MPLS 330 control protocols, runs one or more routing protocols, and is 331 capable of forwarding packets based on labels. A MPLS node may 332 optionally be also capable of forwarding native IP packets. 334 MPLS/GMPLS Security framework 335 MultiProtocol Label Switching (MPLS): An IETF working group and the 336 effort associated with the working group. 338 P: Provider Router. A Provider Router is a router in the Service 339 Provider's core network that does not have interfaces directly 340 towards the customer. A P router is used to interconnect the PE 341 routers. 343 PE: Provider Edge device. A Provider Edge device is the equipment 344 in the Service Provider's network that interfaces with the 345 equipment in the customer's network. 347 VPN: Virtual Private Network, which restricts communication between 348 a set of sites, making use of an IP backbone shared by traffic not 349 going to or not coming from those sites ([RFC4110]). 351 3. Security Reference Models 352 This section defines a reference model for security in MPLS/GMPLS 353 networks. 355 This document defines each MPLS/GMPLS core in a single domain to be 356 a trusted zone. A primary concern is about security aspects that 357 relate to breaches of security from the "outside" of a trusted zone 358 to the "inside" of this zone. Figure 1 depicts the concept of 359 trusted zones within the MPLS/GMPLS framework. 361 /-------------\ 362 +------------+ / \ +------------+ 363 | MPLS/GMPLS +---/ \--------+ MPLS/GMPLS | 364 | user | MPLS/GMPLS Core | user | 365 | site +---\ /XXX-----+ site | 366 +------------+ \ / XXX +------------+ 367 \-------------/ | | 368 | | 369 | +------\ 370 +--------/ "Internet" 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 MPLS/GMPLS Security framework 380 The boundaries of a trust domain should be carefully defined when 381 analyzing the security properties of each individual network, e.g., 382 the boundaries can be at the link termination, remote peers, areas, 383 or quite commonly, ASes. 385 In principle, the trusted zones should be separate; however, 386 typically MPLS core networks also offer Internet access, in which 387 case a transit point (marked with "XXX" in Figure 1) is defined. In 388 the case of MPLS/GMPLS inter-provider connections, the trusted zone 389 of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for 390 Provider A and ASBR3 and ASBR4 for Provider B in Figure 2). 392 A key requirement of MPLS and GMPLS networks is that the security 393 of the trusted zone not be compromised by interconnecting the 394 MPLS/GMPLS core infrastructure with another provider's core 395 (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users. 397 In addition, neighbors may be trusted or untrusted. Neighbors may 398 be authorized or unauthorized. Even though a neighbor may be 399 authorized for communication, it may not be trusted. For example, 400 when connecting with another provider's ASBRs to set up inter-AS 401 LSPs, the other provider is considered an untrusted but authorized 402 neighbor. 404 +---------------+ +----------------+ 405 | | | | 406 | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS | 407 CE1--PE1 Network | | Network PE2--CE2 408 | Provider A ASBR2----ASBR4 Provider B | 409 | | | | 410 +---------------+ +----------------+ 412 For Provider A: 413 Trusted Zone: Provider A MPSL/GMPLS network 414 Trusted neighbors: PE1, ASBR1, ASBR2 415 Authorized but untrusted neighbor: provider B 416 Unauthorized neighbors: CE1, CE2 418 Figure 2. MPLS/GMPLS trusted zone and authorized neighbor. 420 All aspects of network security independent of whether a network is 421 a MPLS/GMPLS network are out of scope. For example, attacks from 422 the Internet to a user's web-server connected through the 423 MPLS/GMPLS network are not considered here, unless the way the 424 MPLS/GMPLS Security framework 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. RFC 4778 [RFC4778] provided the 434 best current operational security practices in Internet Service 435 Provider environments. 437 A successful attack on a particular MPLS/GMPLS network or on a SP's 438 MPLS/GMPLS infrastructure may cause one or more of the following 439 ill effects: 441 - Observation, modification, or deletion of a provider's or user's 442 data. 443 - Replay of a provider's or user's data. 444 - Injection of inauthentic data into a provider's or user's 445 traffic stream. 446 - Traffic pattern analysis on a provider's or user's traffic. 447 - Disruption of a provider's or user's connectivity. 448 - Degradation of a provider's service quality. 449 - Probing a provider's network to determine its configuration, 450 capacity, or usage. 452 It is useful to consider that threats, whether malicious or 453 accidental, may come from different categories of sources. For 454 example they may come from: 456 - Other users whose services are provided by the same MPLS/GMPLS 457 core. 458 - The MPLS/GMPLS SP or persons working for it. 459 - Other persons who obtain physical access to a MPLS/GMPLS SP's 460 site. 461 - Other persons who use social engineering methods to influence 462 the behavior of a SP's personnel. 463 - Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats. 464 (Such threats are beyond the scope of this document.) 465 - Others, e.g., attackers from the Internet at large. 466 - Other SPs in the case of MPLS/GMPLS Inter-provider connection. 467 The core of the other provider may or may not be using 468 MPLS/GMPLS. 469 - Those who create, deliver, install, and maintain software for 470 network equipment. 472 MPLS/GMPLS Security framework 474 Given that security is generally a tradeoff between expense and 475 risk, it is also useful to consider the likelihood of different 476 attacks occurring. There is at least a perceived difference in the 477 likelihood of most types of attacks being successfully mounted in 478 different environments, such as: 480 - A MPLS/GMPLS core inter-connecting with another provider's core 481 - A MPLS/GMPLS configuration transiting the public Internet 483 Most types of attacks become easier to mount and hence more likely 484 as the shared infrastructure via which service is provided expands 485 from a single SP to multiple cooperating SPs to the global 486 Internet. Attacks that may not be of sufficient likeliness to 487 warrant concern in a closely controlled environment often merit 488 defensive measures in broader, more open environments. In closed 489 communities, it is often practical to deal with misbehavior after 490 the fact: an employee can be disciplined, for example. 492 The following sections discuss specific types of exploits that 493 threaten MPLS/GMPLS networks. 495 4.1. Attacks on the Control Plane 497 This category encompasses attacks on the control structures 498 operated by the SP with MPLS/GMPLS cores. 500 It should be noted that while connectivity in the MPLS control plane 501 uses the same links and network resources as are used by the data 502 plane, the GMPLS control plane may be provided by separate resources 503 from those used in the data plane. That is, the GMPLS control plane 504 may be physically separate from the data plane. 506 The different cases of physically congruent and physically separate 507 control/data planes lead to slightly different possibilities of 508 attack, although most of the cases are the same. Note that, for 509 example, the data plane cannot be directly congested by an attack on 510 a physically separate control plane as it could be if the control 511 and data planes shared network resources. Note also that if the 512 control plane uses diverse resources from the data plane, no 513 assumptions should be made about the security of the control plane 514 based on the security of the data plane resources. 516 4.1.1. LSP creation by an unauthorized element 518 The unauthorized element can be a local CE or a router in another 519 domain. An unauthorized element can generate MPLS signaling 520 messages. At the least, this can result in extra control plane and 521 MPLS/GMPLS Security framework 522 forwarding state, and if successful, network bandwidth could be 523 reserved unnecessarily. This may also result in theft of service or 524 even compromise the entire network. 526 4.1.2. LSP message interception 528 This threat might be accomplished by monitoring network traffic, 529 for example, after a physical intrusion. Without physical 530 intrusion, it could be accomplished with an unauthorized software 531 modification. Also, many technologies such as terrestrial 532 microwave, satellite, or free-space optical could be intercepted 533 without physical intrusion. If successful, it could provide 534 information leading to label spoofing attacks. It also raises 535 confidentiality issues. 537 4.1.3. Attacks against RSVP-TE 539 RSVP-TE, described in [RFC3209], is the control protocol used to 540 set up GMPLS and traffic engineered MPLS tunnels. 542 There are two major types of Denial of Service (DoS) attacks 543 against a MPLS domain based on RSVP-TE. The attacker may set up 544 numerous unauthorized LSPs or may send a storm of RSVP messages. 545 It has been demonstrated that unprotected routers running RSVP can 546 be effectively disabled by both types of DoS attacks. 548 These attacks may even be combined, by using the unauthorized LSPs 549 to transport additional RSVP (or other) messages across routers 550 where they might otherwise be filtered out. RSVP attacks can be 551 launched against adjacent routers at the border with the attacker, 552 or against non-adjacent routers within the MPLS domain, if there is 553 no effective mechanism to filter them out. 555 4.1.4. Attacks against LDP 557 LDP, described in [RFC5036], is the control protocol used to set up 558 MPLS tunnels without TE. 560 There are two significant types of attack against LDP. An 561 unauthorized network element can establish a LDP session by sending 562 LDP Hello and LDP Init messages, leading to the potential setup of 563 a LSP, as well as accompanying LDP state table consumption. Even 564 without successfully establishing LSPs, an attacker can launch a 565 DoS attack in the form of a storm of LDP Hello messages or LDP TCP 566 SYN messages, leading to high CPU utilization or table space 567 exhaustion on the target router. 569 MPLS/GMPLS Security framework 570 4.1.5. Denial of Service Attacks on the Network 571 Infrastructure 573 DoS attacks could be accomplished through a MPLS signaling storm, 574 resulting in high CPU utilization and possibly leading to control 575 plane resource starvation. 577 Control plane DoS attacks can be mounted specifically against the 578 mechanisms the SP uses to provide various services, or against the 579 general infrastructure of the service provider, e.g., P routers or 580 shared aspects of PE routers. (An attack against the general 581 infrastructure is within the scope of this document only if the 582 attack can occur in relation with the MPLS/GMPLS infrastructure; 583 otherwise is not a MPLS/GMPLS-specific issue.) 585 The attacks described in the following sections may each have 586 denial of service as one of their effects. Other DoS attacks are 587 also possible. 589 4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via 590 Management Interfaces 592 This includes unauthorized access to a SP's infrastructure 593 equipment, for example to reconfigure the equipment or to extract 594 information (statistics, topology, etc.) pertaining to the network. 596 4.1.7. Social Engineering Attacks on the SP's 597 Infrastructure 599 Attacks in which the service provider's network is reconfigured or 600 damaged, or in which confidential information is improperly 601 disclosed, may be mounted by manipulation of a SP's personnel. 602 These types of attacks are MPLS/GMPLS-specific if they affect 603 MPLS/GMPLS-serving mechanisms. 605 4.1.8. Cross-Connection of Traffic between Users 607 This refers to the event in which expected isolation between 608 separate users (who may be VPN users) is breached. This includes 609 cases such as: 611 - A site being connected into the "wrong" VPN 612 - Traffic being replicated and sent to an unauthorized user 613 - Two or more VPNs being improperly merged together 614 - A point-to-point VPN connecting the wrong two points 615 - Any packet or frame being improperly delivered outside the VPN 616 to which it belongs 618 MPLS/GMPLS Security framework 620 Mis-connection or cross-connection of VPNs may be caused by service 621 provider or equipment vendor error, or by the malicious action of 622 an attacker. The breach may be physical (e.g., PE-CE links mis- 623 connected) or logical (e.g., improper device configuration). 625 Anecdotal evidence suggests that the cross-connection threat is one 626 of the largest security concerns of users (or would-be users). 628 4.1.9. Attacks against Routing Protocols 630 This encompasses attacks against underlying routing protocols that 631 are run by the SP and that directly support the MPLS/GMPLS core. 632 (Attacks against the use of routing protocols for the distribution 633 of backbone routes are beyond the scope of this document.) 634 Specific attacks against popular routing protocols have been widely 635 studied and described in [RFC4593]. 637 4.1.10. Other Attacks on Control Traffic 639 Besides routing and management protocols (covered separately in the 640 previous sections), a number of other control protocols may be 641 directly involved in delivering services by the MPLS/GMPLS core. 642 These include but may not be limited to: 644 - MPLS signaling (LDP, RSVP-TE) discussed above in subsections 645 4.1.4 and 4.1.3 646 - PCE signaling 647 - IPsec signaling (IKE and IKEv2) 648 - ICMP and ICMPv6 649 - L2TP 650 - BGP-based membership discovery 651 - Database-based membership discovery (e.g., RADIUS) 652 - Other protocols that may be important to the control 653 infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE. 655 Attacks might subvert or disrupt the activities of these protocols, 656 for example via impersonation or DoS. 658 Note that all of the data plane attacks can also be carried out 659 against the packets of the control and management planes: 660 insertion, spoofing, replay, deletion, pattern analysis, and other 661 attacks mentioned above. 663 4.2. Attacks on the Data Plane 665 This category encompasses attacks on the provider's or end user's 666 data. Note that from the MPLS/GMPLS network end user's point of 667 MPLS/GMPLS Security framework 668 view, some of this might be control plane traffic, e.g. routing 669 protocols running from user site A to user site B via IP or non-IP 670 connections, which may be some type of VPN. 672 4.2.1. Unauthorized Observation of Data Traffic 674 This refers to "sniffing" provider or end user packets and 675 examining their contents. This can result in exposure of 676 confidential information. It can also be a first step in other 677 attacks (described below) in which the recorded data is modified 678 and re-inserted, or simply replayed later. 680 4.2.2. Modification of Data Traffic 682 This refers to modifying the contents of packets as they traverse 683 the MPLS/GMPLS core. 685 4.2.3. Insertion of Inauthentic Data Traffic: Spoofing 686 and Replay 688 Spoofing refers to sending a user or inserting into a data stream 689 packets that do not belong, with the objective of having them 690 accepted by the recipient as legitimate. Also included in this 691 category is the insertion of copies of once-legitimate packets that 692 have been recorded and replayed. 694 4.2.4. Unauthorized Deletion of Data Traffic 696 This refers to causing packets to be discarded as they traverse the 697 MPLS/GMPLS networks. This is a specific type of Denial of Service 698 attack. 700 4.2.5. Unauthorized Traffic Pattern Analysis 702 This refers to "sniffing" provider or user packets and examining 703 aspects or meta-aspects of them that may be visible even when the 704 packets themselves are encrypted. An attacker might gain useful 705 information based on the amount and timing of traffic, packet 706 sizes, source and destination addresses, etc. For most users, this 707 type of attack is generally considered to be significantly less of 708 a concern than the other types discussed in this section. 710 4.2.6. Denial of Service Attacks 712 Denial of Service (DoS) attacks are those in which an attacker 713 attempts to disrupt or prevent the use of a service by its 714 legitimate users. Taking network devices out of service, modifying 715 MPLS/GMPLS Security framework 716 their configuration, or overwhelming them with requests for service 717 are several of the possible avenues for DoS attack. 719 Overwhelming the network with requests for service, otherwise known 720 as a "resource exhaustion" DoS attack, may target any resource in 721 the network, e.g., link bandwidth, packet forwarding capacity, 722 session capacity for various protocols, CPU power, table size, 723 storage overflows, and so on. 725 DoS attacks of the resource exhaustion type can be mounted against 726 the data plane of a particular provider or end user by attempting 727 to insert (spoofing) an overwhelming quantity of inauthentic data 728 into the provider or end user's network from the outside of the 729 trusted zone. Potential results might be to exhaust the bandwidth 730 available to that provider or end user or to overwhelm the 731 cryptographic authentication mechanisms of the provider or end 732 user. 734 Data plane resource exhaustion attacks can also be mounted by 735 overwhelming the service provider's general (MPLS/GMPLS- 736 independent) infrastructure with traffic. These attacks on the 737 general infrastructure are not usually a MPLS/GMPLS-specific issue, 738 unless the attack is mounted by another MPLS/GMPLS network user 739 from a privileged position. (E.g., a MPLS/GMPLS network user might 740 be able to monopolize network data plane resources and thus disrupt 741 other users.) 743 Many DoS attacks use amplification, whereby the attacker co-opts 744 otherwise innocent parties to increase the effect of the attack. 745 The attacker may, for example, send packets to a broadcast or 746 multicast address with the spoofed source address of the victim, 747 and all of the recipients may then respond to the victim. 749 4.2.7. Misconnection 751 Misconnection may arise through deliberate attack, or through 752 misconfiguration or misconnection of the network resources. The 753 result is likely to be delivery of data to the wrong destination or 754 black-holing of the data. 756 In GMPLS with physically diverse control and data planes, it may be 757 possible for data plane misconnection to go undetected by the 758 control plane. 760 In optical networks under GMPLS control, misconnection may give rise 761 to physical safety risks as unprotected lasers may be activated 762 without warning. 764 MPLS/GMPLS Security framework 765 4.3. Attacks on Operation and Management Plane 767 Attacks on OAM have been discussed extensively as general network 768 security issues over the last 20 years. RFC 4778 [RFC4778] may 769 serve as the best current operational security practices in Internet 770 Service Provider environments. RFC 4377 [RFC4377] provided OAM 771 Requirements for MPLS networks. See also the Security 772 Considerations of RFC 4377 and Section 7 of RFC 4378 [RFC4378]. 774 OAM Operations across the MPLS-ICI could also be the source of 775 security threats on the provider infrastructure as well as the 776 service offered over the MPLS-ICI. A large volume of OAM messages 777 could overwhelm the processing capabilities of an ASBR if the ASBR 778 is not properly protected. Maliciously generated OAM messages could 779 also be used to bring down an otherwise healthy service (e.g., MPLS 780 Pseudo Wire), and therefore affect service security. MPLS-ping does 781 not support authentication today, and that support should be 782 subject for future considerations. Bidirectional Forwarding 783 Detection (BFD), however, does have support for carrying an 784 authentication object. It also supports Time-To-Live (TTL) 785 processing as an anti-replay measure. Implementations conformant 786 with this MPLS-ICI should support BFD authentication and must 787 support the procedures for TTL processing. 789 Regarding GMPLS OAM consideration in optical interworking, there is 790 a good discussion on security for management interfaces to Network 791 Elements [OIF Sec Mag]. 793 Network elements typically have one or more (in some cases many) OAM 794 interfaces used for network management, billing and accounting, 795 configuration, maintenance, and other administrative activities. 797 Remote access to a network element through these OAM interfaces is 798 frequently a requirement. Securing the control protocols while 799 leaving these OAM interfaces unprotected opens up a huge security 800 vulnerability. Network elements are an attractive target for 801 intruders who want to disrupt or gain free access to 802 telecommunications facilities. Much has been written about this 803 subject since the 1980s. In the 1990s, telecommunications facilities 804 were identified in the U.S. and other countries as part of the 805 "critical infrastructure," and increased emphasis was placed on 806 thwarting such attacks from a wider range of potentially well-funded 807 and determined adversaries. 809 At one time, careful access controls and password management were a 810 sufficient defense, but no longer. Networks using the TCP/IP 811 protocol suite are vulnerable to forged source addresses, recording 812 MPLS/GMPLS Security framework 813 and later replay, packet sniffers picking up passwords, re-routing 814 of traffic to facilitate eavesdropping or tampering, active 815 hijacking attacks of TCP connections, and a variety of denial of 816 service attacks. The ease of forging TCP/IP packets is the main 817 reason network management protocols lacking strong security have not 818 been used to configure network elements (e.g., with the SNMP SET 819 command). 821 Readily available hacking tools exist that let an eavesdropper on a 822 LAN take over one end of any TCP connection, so that the legitimate 823 party is cut off. In addition, enterprises and Service Providers in 824 some jurisdictions need to safeguard data about their users and 825 network configurations from prying. An attacker could eavesdrop and 826 observe traffic to analyze usage patterns and map a network 827 configuration; an attacker could also gain access to systems and 828 manipulate configuration data or send malicious commands. 830 Therefore, in addition to authenticating the human user, more 831 sophisticated protocol security is needed for OAM interfaces, 832 especially when they are configured over TCP/IP stacks. Finally, 833 relying on a perimeter defense, such as firewalls, is insufficient 834 protection against "insider attacks," or penetrations that 835 compromise a system inside the firewall as a launching pad to attack 836 network elements. 838 5. Defensive Techniques for MPLS/GMPLS Networks 840 The defensive techniques discussed in this document are intended to 841 describe methods by which some security threats can be addressed. 842 They are not intended as requirements for all MPLS/GMPLS 843 implementations. The MPLS/GMPLS provider should determine the 844 applicability of these techniques to the provider's specific 845 service offerings, and the end user may wish to assess the value of 846 these techniques to the user's service requirements. The 847 operational environment determines the security requirements. 848 Therefore, protocol designers need to provide a full set of 849 security services, which can be used where appropriate. 851 The techniques discussed here include encryption, authentication, 852 filtering, firewalls, access control, isolation, aggregation, and 853 others. 855 Often, security is achieved by careful protocol design, rather than 856 by adding a security method. For example, one method of mitigating 857 DoS attacks is to make sure that innocent parties cannot be used to 858 amplify the attack. Security works better when it is "designed in" 859 rather than "added on." 860 MPLS/GMPLS Security framework 861 Nothing is ever 100% secure. Defense therefore involves protecting 862 against those attacks that are most likely to occur or that have 863 the most direct consequences if successful. For those attacks that 864 are protected against, absolute protection is seldom achievable; 865 more often it is sufficient just to make the cost of a successful 866 attack greater than what the adversary will be willing or able to 867 expend. 869 Successfully defending against an attack does not necessarily mean 870 the attack must be prevented from happening or from reaching its 871 target. In many cases the network can instead be designed to 872 withstand the attack. For example, the introduction of inauthentic 873 packets could be defended against by preventing their introduction 874 in the first place, or by making it possible to identify and 875 eliminate them before delivery to the MPLS/GMPLS user's system. 876 The latter is frequently a much easier task. 878 5.1. Authentication 880 To prevent security issues arising from some DoS attacks or from 881 malicious or accidental misconfiguration, it is critical that 882 devices in the MPLS/GMPLS should only accept connections or control 883 messages from valid sources. Authentication refers to methods to 884 ensure that message sources are properly identified by the 885 MPLS/GMPLS devices with which they communicate. This section 886 focuses on identifying the scenarios in which sender authentication 887 is required and recommends authentication mechanisms for these 888 scenarios. 890 Cryptographic techniques (authentication, integrity, and 891 encryption) do not protect against some types of denial of service 892 attacks, specifically resource exhaustion attacks based on CPU or 893 bandwidth exhaustion. In fact, the processing required to decrypt 894 or check authentication may, in the case of software-based 895 cryptographic processing, in some cases increase the effect of 896 these resource exhaustion attacks. With a hardware cryptographic 897 accelerator, attack packets can be dropped at line speed without a 898 cost of software cycles. Cryptographic techniques may, however, be 899 useful against resource exhaustion attacks based on exhaustion of 900 state information (e.g., TCP SYN attacks). 902 The MPLS data plane, as presently defined, is not amenable to 903 source authentication as there are no source identifiers in the 904 MPLS packet to authenticate. The MPLS label is only locally 905 MPLS/GMPLS Security framework 906 meaningful. It may be assigned by a downstream node or upstream 907 node for multicast support. 909 When the MPLS payload carries identifiers that may be authenticated 910 (e.g., IP packets), authentication may be carried out at the client 911 level, but this does not help the MPLS SP, as these client 912 identifiers belong to an external, untrusted network. 914 5.1.1. Management System Authentication 916 Management system authentication includes the authentication of a 917 PE to a centrally-managed network management or directory server 918 when directory-based "auto-discovery" is used. It also includes 919 authentication of a CE to the configuration server, when a 920 configuration server system is used. 922 Authentication should be bi-directional, including PE or CE to 923 configuration server authentication for PE or CE to be certain it 924 is communicating with the right server. 926 5.1.2. Peer-to-Peer Authentication 928 Peer-to-peer authentication includes peer authentication for 929 network control protocols (e.g., LDP, BGP, etc.), and other peer 930 authentication (i.e., authentication of one IPsec security gateway 931 by another). 933 Authentication should be bi-directional, including PE or CE to 934 configuration server authentication for PE or CE to be certain it 935 is communicating with the right server. 937 As indicated in Section 5.1.1, authentication should be bi- 938 directional. 940 5.1.3. Cryptographic Techniques for Authenticating Identity 942 Cryptographic techniques offer several mechanisms for 943 authenticating the identity of devices or individuals. These 944 include the use of shared secret keys, one-time keys generated by 945 accessory devices or software, user-ID and password pairs, and a 946 range of public-private key systems. Another approach is to use a 947 hierarchical Certification Authority system to provide digital 948 certificates. 950 MPLS/GMPLS Security framework 951 This section describes or provides references to the specific 952 cryptographic approaches for authenticating identity. These 953 approaches provide secure mechanisms for most of the authentication 954 scenarios required in securing a MPLS/GMPLS network. 956 5.2. Cryptographic Techniques 958 MPLS/GMPLS defenses against a wide variety of attacks can be 959 enhanced by the proper application of cryptographic techniques. 960 These same cryptographic techniques are applicable to general 961 network communications and can provide confidentiality (encryption) 962 of communication between devices, authenticate the identities of the 963 devices, and detect whether the data being communicated has been 964 changed during transit or replayed from previous messages. 966 Several aspects of authentication are addressed in some detail in a 967 separate "Authentication" section. 969 Cryptographic methods add complexity to a service and thus, for a 970 few reasons, may not be the most practical solution in every case. 971 Cryptography adds an additional computational burden to devices, 972 which may reduce the number of user connections that can be handled 973 on a device or otherwise reduce the capacity of the device, 974 potentially driving up the provider's costs. Typically, 975 configuring encryption services on devices adds to the complexity 976 of their configuration and adds labor cost. Some key management 977 system is usually needed. Packet sizes are typically increased when 978 the packets are encrypted or have integrity checks or replay 979 counters added, increasing the network traffic load and adding to 980 the likelihood of packet fragmentation with its increased overhead. 981 (This packet length increase can often be mitigated to some extent 982 by data compression techniques, but at the expense of additional 983 computational burden.) Finally, some providers may employ enough 984 other defensive techniques, such as physical isolation or filtering 985 and firewall techniques, that they may not perceive additional 986 benefit from encryption techniques. 988 Users may wish to provide confidentiality end to end. Generally, 989 encrypting for confidentiality must be accompanied with 990 cryptographic integrity checks to prevent certain active attacks 991 against the encrypted communications. On today's processors, 992 encryption and integrity checks run extremely quickly, but key 993 management may be more demanding in terms of both computational and 994 administrative overhead. 996 MPLS/GMPLS Security framework 997 The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider, 998 and other parts of the network is a major element in determining 999 the applicability of cryptographic protection for any specific 1000 MPLS/GMPLS implementation. In particular, it determines where 1001 cryptographic protection should be applied: 1003 - If the data path between the user's site and the 1004 provider's PE is not trusted, then it may be used on the 1005 PE-CE link. 1006 - If some part of the backbone network is not trusted, 1007 particularly in implementations where traffic may travel 1008 across the Internet or multiple providers' networks, then 1009 the PE-PE traffic may be cryptographically protected. One 1010 also should consider cases where L1 technology may be 1011 vulnerable to eavesdropping. 1012 - If the user does not trust any zone outside of its 1013 premises, it may require end-to-end or CE-CE cryptographic 1014 protection. This fits within the scope of this MPLS/GMPLS 1015 security framework when the CE is provisioned by the 1016 MPLS/GMPLS provider. 1017 - If the user requires remote access to its site from a 1018 system at a location that is not a customer location (for 1019 example, access by a traveler) there may be a requirement 1020 for cryptographically protecting the traffic between that 1021 system and an access point or a customer's site. If the 1022 MPLS/GMPLS provider supplies the access point, then the 1023 customer must cooperate with the provider to handle the 1024 access control services for the remote users. These access 1025 control services are usually protected cryptographically, 1026 as well. 1028 Access control usually starts with authentication of the 1029 entity. If cryptographic services are part of the scenario, 1030 then it is important to bind the authentication to the key 1031 management. Otherwise the protocol is vulnerable to being 1032 hijacked between the authentication and key management. 1034 Although CE-CE cryptographic protection can provide integrity and 1035 confidentiality against third parties, if the MPLS/GMPLS provider 1036 has complete management control over the CE (encryption) devices, 1037 then it may be possible for the provider to gain access to the 1038 user's traffic or internal network. Encryption devices could 1039 potentially be reconfigured to use null encryption, bypass 1040 cryptographic processing altogether, reveal internal configuration, 1041 or provide some means of sniffing or diverting unencrypted traffic. 1042 Thus an implementation using CE-CE encryption needs to consider the 1043 trust relationship between the MPLS/GMPLS user and provider. 1044 MPLS/GMPLS users and providers may wish to negotiate a service 1045 MPLS/GMPLS Security framework 1046 level agreement (SLA) for CE-CE encryption that provides an 1047 acceptable demarcation of responsibilities for management of 1048 cryptographic protection on the CE devices. The demarcation may 1049 also be affected by the capabilities of the CE devices. For 1050 example, the CE might support some partitioning of management, a 1051 configuration lock-down ability, or shared capability to verify the 1052 configuration. In general, the MPLS/GMPLS user needs to have a 1053 fairly high level of trust that the MPLS/GMPLS provider will 1054 properly provision and manage the CE devices, if the managed CE-CE 1055 model is used. 1057 5.2.1. IPsec in MPLS/GMPLS 1059 IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411] 1060 is the security protocol of choice for protection at the IP layer. 1061 IPsec provides robust security for IP traffic between pairs of 1062 devices. Non-IP traffic such as IS-IS routing must be converted to 1063 IP (e.g., by encapsulation) in order to use IPsec. When the MPLS is 1064 encapsulating IP traffic then IPsec covers the encryption of the IP 1065 client layer, while for non-IP client traffic see section 5.2.4 1066 (MPLS PWs). 1068 In the MPLS/GMPLS model, IPsec can be employed to protect IP 1069 traffic between PEs, between a PE and a CE, or from CE to CE. CE- 1070 to-CE IPsec may be employed in either a provider-provisioned or a 1071 user-provisioned model. Likewise, IPsec protection of data 1072 performed within the user's site is outside the scope of this 1073 document, because it is simply handled as user data by the 1074 MPLS/GMPLS core. However, if the SP performs compression, pre- 1075 encryption will have a major effect on that operation. 1077 IPsec does not itself specify cryptographic algorithms. It can use 1078 a variety of integrity or confidentiality algorithms (or even 1079 combined integrity and confidentiality algorithms), with various 1080 key lengths, such as AES encryption or AES message integrity 1081 checks. There are trade-offs between key length, computational 1082 burden, and the level of security of the encryption. A full 1083 discussion of these trade-offs is beyond the scope of this 1084 document. In practice, any currently recommended IPsec protection 1085 offers enough security to reduce the likelihood of its being 1086 directly targeted by an attacker substantially; other weaker links 1087 in the chain of security are likely to be attacked first. 1088 MPLS/GMPLS users may wish to use a Service Level Agreement (SLA) 1089 specifying the SP's responsibility for ensuring data integrity and 1090 confidentiality, rather than analyzing the specific encryption 1091 techniques used in the MPLS/GMPLS service. 1093 MPLS/GMPLS Security framework 1094 Encryption algorithms generally come with two parameters: mode such 1095 as Cipher Block Chaining and key length such as AES-192. (This 1096 should not be confused with two other senses in which the word 1097 "mode" is used: IPsec itself can be used in Tunnel Mode or 1098 Transport Mode, and IKE [version 1] uses Main Mode, Aggressive 1099 Mode, or Quick Mode). It should be stressed that IPsec encryption 1100 without an integrity check is a state of sin. 1102 For many of the MPLS/GMPLS provider's network control messages and 1103 some user requirements, cryptographic authentication of messages 1104 without encryption of the contents of the message may provide 1105 appropriate security. Using IPsec, authentication of messages is 1106 provided by the Authentication Header (AH) or through the use of 1107 the Encapsulating Security Protocol (ESP) with NULL encryption. 1108 Where control messages require integrity but do not use IPsec, 1109 other cryptographic authentication methods are often available. 1110 Message authentication methods currently considered to be secure 1111 are based on hashed message authentication codes (HMAC) [RFC2104] 1112 implemented with a secure hash algorithm such as Secure Hash 1113 Algorithm 1 (SHA-1) [RFC3174]. No attacks against HMAC SHA-1 are 1114 likely to play out in the near future, but it is possible that 1115 people will soon find SHA-1 collisions. Thus, it is important that 1116 mechanisms be designed to be flexible about the choice of hash 1117 functions and message integrity checks. Also, many of these 1118 mechanisms do not include a convenient way to manage and update 1119 keys. 1121 A mechanism to provide a combination of confidentiality, data 1122 origin authentication, and connectionless integrity is the use of 1123 AES in GCM (Counter with CBC-MAC) mode (RFC 4106) [RFC4106]. 1125 5.2.2. MPLS / GMPLS DiffServ and IPsec 1127 MPLS and GMPLS, which provide differentiated services based on 1128 traffic type, may encounter some conflicts with IPsec encryption of 1129 traffic. Because encryption hides the content of the packets, it 1130 may not be possible to differentiate the encrypted traffic in the 1131 same manner as unencrypted traffic. Although DiffServ markings are 1132 copied to the IPsec header and can provide some differentiation, 1133 not all traffic types can be accommodated by this mechanism. Using 1134 IPsec without IKE or IKEv2 (the better choice) is not advisable. 1135 IKEv2 provides IPsec Security Association creation and management, 1136 entity authentication, key agreement, and key update. It works with 1137 a variety of authentication methods including pre-shared keys, 1138 public key certificates, and EAP. If DoS attacks against IKEv2 are 1139 considered an important threat to mitigate, the cookie-based anti- 1140 spoofing feature of IKEv2 should be used. IKEv2 has its own set of 1141 MPLS/GMPLS Security framework 1142 cryptographic methods, but any of the default suites specified in 1143 [RFC4308] or [RFC4869] provides more than adequate security. 1145 5.2.3. Encryption for Device Configuration and Management 1147 For configuration and management of MPLS/GMPLS devices, encryption 1148 and authentication of the management connection at a level 1149 comparable to that provided by IPsec is desirable. 1151 Several methods of transporting MPLS/GMPLS device management 1152 traffic offer authentication, integrity, and confidentiality. 1154 - Secure Shell (SSH) offers protection for TELNET [STD-8] or 1155 terminal-like connections to allow device configuration. 1156 - SNMPv3 [STD62] provides encrypted and authenticated protection 1157 for SNMP-managed devices. 1158 - Transport Layer Security (TLS) [RFC5246] and the closely-related 1159 Secure Sockets Layer (SSL) are widely used for securing HTTP- 1160 based communication, and thus can provide support for most XML- 1161 and SOAP-based device management approaches. 1162 - Since 2004, there has been extensive work proceeding in several 1163 organizations (OASIS, W3C, WS-I, and others) on securing device 1164 management traffic within a "Web Services" framework, using a 1165 wide variety of security models, and providing support for 1166 multiple security token formats, multiple trust domains, 1167 multiple signature formats, and multiple encryption 1168 technologies. 1169 - IPsec provides security services including integrity and 1170 confidentiality at the network layer. With regards to device 1171 management, its current use is primarily focused on in-band 1172 management of user-managed IPsec gateway devices. 1173 - There are recent work in the ISMS WG (Integrated Security Model 1174 for SNMP Working Group) to define how to use SSH to secure SNMP, 1175 due to the limited deployment of SNMPv3; and the possibility of 1176 using Kerberos, particularly for interfaces like TELNET, where 1177 client code exists. 1179 5.2.4. Security Considerations for MPLS Pseudowires 1181 In addition to IP traffic, MPLS networks may be used to transport 1182 other services such as Ethernet, ATM, Frame Relay, and TDM. This is 1183 done by setting up pseudowires (PWs) that tunnel the native service 1184 through the MPLS core by encapsulating at the edges. The PWE 1185 architecture is defined in [RFC3985]. 1187 MPLS/GMPLS Security framework 1188 PW tunnels may be set up using the PWE control protocol based on 1189 LDP [RFC4447], and thus security considerations for LDP will most 1190 likely be applicable to the PWE3 control protocol as well. 1192 PW user packets contain at least one MPLS label (the PW label) and 1193 may contain one or more MPLS tunnel labels. After the label stack, 1194 there is a four-byte control word (which is optional for some PW 1195 types), followed by the native service payload. It must be 1196 stressed that encapsulation of MPLS PW packets in IP for the 1197 purpose of enabling use of IPsec mechanisms is not a valid option. 1199 The PW client traffic may be secured by use of mechanisms beyond 1200 the scope of this document. Security at the MPLS layer itself is 1201 for further study. 1203 5.2.5. End-to-End versus Hop-by-Hop Protection Tradeoffs 1204 in MPLS/GMPLS 1206 In MPLS/GMPLS, cryptographic protection could potentially be 1207 applied to the MPLS/GMPLS traffic at several different places. 1208 This section discusses some of the tradeoffs in implementing 1209 encryption in several different connection topologies among 1210 different devices within a MPLS/GMPLS network. 1212 Cryptographic protection typically involves a pair of devices that 1213 protect the traffic passing between them. The devices may be 1214 directly connected (over a single "hop"), or intervening devices 1215 may transport the protected traffic between the pair of devices. 1216 The extreme cases involve using protection between every adjacent 1217 pair of devices along a given path (hop-by-hop), or using 1218 protection only between the end devices along a given path (end-to- 1219 end). To keep this discussion within the scope of this document, 1220 the latter ("end-to-end") case considered here is CE-to-CE rather 1221 than fully end-to-end. 1223 Figure 3 depicts a simplified topology showing the Customer Edge 1224 (CE) devices, the Provider Edge (PE) devices, and a variable number 1225 (three are shown) of Provider core (P) devices, which might be 1226 present along the path between two sites in a single VPN operated 1227 by a single service provider (SP). 1229 Site_1---CE---PE---P---P---P---PE---CE---Site_2 1231 Figure 3: Simplified topology traversing through MPLS/GMPLS core. 1233 MPLS/GMPLS Security framework 1234 Within this simplified topology, and assuming that the P devices 1235 are not involved with cryptographic protection, four basic, 1236 feasible configurations exist for protecting connections among the 1237 devices: 1239 1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity 1240 services between the two CE devices, so that traffic will be 1241 protected throughout the SP's network. 1243 2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or 1244 integrity services between the two PE devices. Unprotected 1245 traffic is received at one PE from the customer's CE, then it is 1246 protected for transmission through the SP's network to the other 1247 PE, and finally it is decrypted or checked for integrity and 1248 sent to the other CE. 1250 3) Access link (CE-to-PE) - Apply confidentiality or integrity 1251 services between the CE and PE on each side or on only one side. 1253 4) Configurations 2 and 3 above can also be combined, with 1254 confidentiality or integrity running from CE to PE, then PE to 1255 PE, and then PE to CE. 1257 Among the four feasible configurations, key tradeoffs in 1258 considering encryption include: 1260 - Vulnerability to link eavesdropping or tampering - assuming an 1261 attacker can observe or modify data in transit on the links, 1262 would it be protected by encryption? 1264 - Vulnerability to device compromise - assuming an attacker can get 1265 access to a device (or freely alter its configuration), would the 1266 data be protected? 1268 - Complexity of device configuration and management - given the 1269 number of sites per VPN customer as Nce and the number of PEs 1270 participating in a given VPN as Npe, how many device 1271 configurations need to be created or maintained, and how do those 1272 configurations scale? 1274 - Processing load on devices - how many cryptographic operations 1275 must be performed given N packets? - This raises considerations 1276 of device capacity and perhaps end-to-end delay. 1278 MPLS/GMPLS Security framework 1280 - Ability of the SP to provide enhanced services (QoS, firewall, 1281 intrusion detection, etc.) - Can the SP inspect the data to 1282 provide these services? 1284 These tradeoffs are discussed for each configuration, below: 1286 1) Site-to-site (CE-to-CE) 1288 Link eavesdropping or tampering - protected on all links. 1289 Device compromise - vulnerable to CE compromise. 1291 Complexity - single administration, responsible for one device per 1292 site (Nce devices), but overall configuration per VPN scales as 1293 Nce**2. 1294 Though the complexity may be reduced: 1) In practice, as Nce 1295 grows, the number of VPNs falls off from being a full clique; 1296 2) If the CEs run an automated key management protocol, then 1297 they should be able to set up and tear down secured VPNs 1298 without any intervention. 1300 Processing load - on each of two CEs, each packet is 1301 cryptographically processed (2P), though the protection may be 1302 "integrity check only" or "integrity check plus encryption." 1304 Enhanced services - severely limited; typically only Diffserv 1305 markings are visible to the SP, allowing some QoS services. The 1306 CEs could also use the IPv6 Flow Label to identify traffic 1307 classes. 1309 2) Provider Edge-to-Edge (PE-to-PE) 1311 Link eavesdropping or tampering - vulnerable on CE-PE links; 1312 protected on SP's network links. 1314 Device compromise - vulnerable to CE or PE compromise. 1316 Complexity - single administration, Npe devices to configure. 1317 (Multiple sites may share a PE device so Npe is typically much 1318 smaller than Nce.) Scalability of the overall configuration 1319 depends on the PPVPN type: If the cryptographic protection is 1320 separate per VPN context, it scales as Npe**2 per customer VPN. 1321 If it is per-PE, it scales as Npe**2 for all customer VPNs 1322 combined. 1324 Processing load - on each of two PEs, each packet is 1325 cryptographically processed (2P). 1327 MPLS/GMPLS Security framework 1329 Enhanced services - full; SP can apply any enhancements based on 1330 detailed view of traffic. 1332 3) Access Link (CE-to-PE) 1334 Link eavesdropping or tampering - protected on CE-PE link; 1335 vulnerable on SP's network links 1336 Device compromise - vulnerable to CE or PE compromise 1337 Complexity - two administrations (customer and SP) with device 1338 configuration on each side (Nce + Npe devices to configure) but 1339 because there is no mesh the overall configuration scales as 1340 Nce. 1341 Processing load - on each of two CEs, each packet is 1342 cryptographically processed, plus on each of two PEs, each 1343 packet is cryptographically processed (4P) 1344 Enhanced services - full; SP can apply any enhancements based on 1345 detailed view of traffic 1347 4) Combined Access link and PE-to-PE (essentially hop-by-hop) 1349 Link eavesdropping or tampering - protected on all links 1350 Device compromise - vulnerable to CE or PE compromise 1351 Complexity - two administrations (customer and SP) with device 1352 configuration on each side (Nce + Npe devices to configure). 1353 Scalability of the overall configuration depends on the PPVPN 1354 type: If the cryptographic processing is separate per VPN 1355 context, it scales as Npe**2 per customer VPN. If it is per- 1356 PE, it scales as Npe**2 for all customer VPNs combined. 1357 Processing load - on each of two CEs, each packet is 1358 cryptographically processed, plus on each of two PEs, each 1359 packet is cryptographically processed twice (6P) 1360 Enhanced services - full; SP can apply any enhancements based on 1361 detailed view of traffic 1363 Given the tradeoffs discussed above, a few conclusions can be 1364 drawn: 1366 - Configurations 2 and 3 are subsets of 4 that may be appropriate 1367 alternatives to 4 under certain threat models; the remainder of 1368 these conclusions compare 1 (CE-to-CE) versus 4 (combined access 1369 links and PE-to-PE). 1371 - If protection from link eavesdropping or tampering is all that is 1372 important, then configurations 1 and 4 are equivalent. 1374 - If protection from device compromise is most important and the 1375 threat is to the CE devices, both cases are equivalent; if the 1376 threat is to the PE devices, configuration 1 is better. 1378 MPLS/GMPLS Security framework 1380 - If reducing complexity is most important, and the size of the 1381 network is small, configuration 1 is better. Otherwise 1382 configuration 4 is better because rather than a mesh of CE 1383 devices it requires a smaller mesh of PE devices. Also, under 1384 some PPVPN approaches the scaling of 4 is further improved by 1385 sharing the same PE-PE mesh across all VPN contexts. The scaling 1386 advantage of 4 may be increased or decreased in any given 1387 situation if the CE devices are simpler to configure than the PE 1388 devices, or vice-versa. 1390 - If the overall processing load is a key factor, then 1 is 1391 better, unless the PEs come with a hardware encryption 1392 accelerator and the CEs do not. 1394 - If the availability of enhanced services support from the 1395 SP is most important, then 4 is best. 1397 - If users are concerned with having their VPNs misconnected 1398 with other users' VPNs, then encryption with 1 can provide 1399 protection. 1401 As a quick overall conclusion, CE-to-CE protection is better 1402 against device compromise, but this comes at the cost of enhanced 1403 services and at the cost of operational complexity due to the 1404 Order(n**2) scaling of a larger mesh. 1406 This analysis of site-to-site vs. hop-by-hop tradeoffs does not 1407 explicitly include cases of multiple providers cooperating to 1408 provide a PPVPN service, public Internet VPN connectivity, or 1409 remote access VPN service, but many of the tradeoffs are similar. 1411 In addition to the simplified models, the following should also be 1412 considered: 1413 - There are reasons, perhaps, to protect a specific P-to-P or PE- 1414 to-P. 1415 - There may be reasons to do multiple encryptions over certain 1416 segments. One may be using an encrypted wireless link under our 1417 IPsec VPN to access a SSL-secured web site to download encrypted 1418 email attachments: four layers.) 1419 - It may be appropriate that, for example, cryptographic integrity 1420 checks are applied end to end, and confidentiality over a shorter 1421 span. 1422 - Different cryptographic protection may be required for control 1423 protocols and data traffic. 1424 - Attention needs to be given to how auxiliary traffic is 1425 protected, e.g., the ICMPv6 packets that flow back during PMTU 1426 discovery, among other examples. 1428 MPLS/GMPLS Security framework 1429 5.3. Access Control Techniques 1431 Access control techniques include packet-by-packet or packet-flow- 1432 by-packet-flow access control by means of filters and firewalls on 1433 IPv4/IPv6 packets, as well as by means of admitting a "session" for 1434 a control, signaling, or management protocol. Enforcement of access 1435 control by isolated infrastructure addresses is discussed in 1436 section 5.4 of this document. 1438 In this document, we distinguish between filtering and firewalls 1439 based primarily on the direction of traffic flow. We define 1440 filtering as being applicable to unidirectional traffic, while a 1441 firewall can analyze and control both sides of a conversation. 1443 The definition has two significant corollaries: 1444 - Routing or traffic flow symmetry: A firewall typically requires 1445 routing symmetry, which is usually enforced by locating a firewall 1446 where the network topology assures that both sides of a 1447 conversation will pass through the firewall. A filter can operate 1448 upon traffic flowing in one direction, without considering traffic 1449 in the reverse direction. Beware that this concept could result in 1450 a single point of failure. 1451 - Statefulness: Because it receives both sides of a conversation, a 1452 firewall may be able to interpret a significant amount of 1453 information concerning the state of that conversation and use this 1454 information to control access. A filter can maintain some limited 1455 state information on a unidirectional flow of packets, but cannot 1456 determine the state of the bi-directional conversation as precisely 1457 as a firewall. 1459 5.3.1. Filtering 1461 It is relatively common for routers to filter packets. That is, 1462 routers can look for particular values in certain fields of the IP 1463 or higher level (e.g., TCP or UDP) headers. Packets matching the 1464 criteria associated with a particular filter may either be 1465 discarded or given special treatment. Today, not only routers, most 1466 end hosts have filters, and every instance of IPsec is also a 1467 filter [RFC4301]. 1469 In discussing filters, it is useful to separate the Filter 1470 Characteristics that may be used to determine whether a packet 1471 matches a filter from the Packet Actions applied to those packets 1472 matching a particular filter. 1474 o Filter Characteristics 1475 MPLS/GMPLS Security framework 1476 Filter characteristics or rules are used to determine whether a 1477 particular packet or set of packets matches a particular filter. 1479 In many cases filter characteristics may be stateless. A stateless 1480 filter determines whether a particular packet matches a filter 1481 based solely on the filter definition, normal forwarding 1482 information (such as the next hop for a packet), the interface on 1483 which a packet arrived, and the contents of that individual packet. 1484 Typically, stateless filters may consider the incoming and outgoing 1485 logical or physical interface, information in the IP header, and 1486 information in higher layer headers such as the TCP or UDP header. 1487 Information in the IP header to be considered may for example 1488 include source and destination IP addresses; Protocol field, 1489 Fragment Offset, and TOS field in IPv4; or Next Header, Extension 1490 Headers, Flow label, etc. in IPv6. Filters also may consider fields 1491 in the TCP or UDP header such as the Port numbers, the SYN field in 1492 the TCP header, as well as ICMP and ICMPv6 type. 1494 Stateful filtering maintains packet-specific state information to 1495 aid in determining whether a filter rule has been met. For example, 1496 a device might apply stateless filtering to the first fragment of a 1497 fragmented IPv4 packet. If the filter matches, then the data unit 1498 ID may be remembered and other fragments of the same packet may 1499 then be considered to match the same filter. Stateful filtering is 1500 more commonly done in firewalls, although firewall technology may 1501 be added to routers. Data unit ID can also be Fragment Extension 1502 Header Identification field in IPv6. 1504 o Actions based on Filter Results 1506 If a packet, or a series of packets, matches a specific filter, 1507 then a variety of actions which may be taken based on that match. 1508 Examples of such actions include: 1510 - Discard 1512 In many cases, filters are set to catch certain undesirable 1513 packets. Examples may include packets with forged or invalid source 1514 addresses, packets that are part of a DoS or Distributed DoS (DDoS) 1515 attack, or packets trying to access unallowed resources (such as 1516 network management packets from an unauthorized source). Where such 1517 filters are activated, it is common to discard the packet or set of 1518 packets matching the filter silently. The discarded packets may of 1519 course also be counted or logged. 1521 - Set CoS 1523 MPLS/GMPLS Security framework 1525 A filter may be used to set the Class of Service associated with 1526 the packet. 1528 - Count packets or bytes 1530 - Rate Limit 1532 In some cases the set of packets matching a particular filter may 1533 be limited to a specified bandwidth. In this case, packets or bytes 1534 would be counted, and would be forwarded normally up to the 1535 specified limit. Excess packets may be discarded or may be marked 1536 (for example by setting a "discard eligible" bit in the IPv4 ToS 1537 field or the MPLS EXP field). 1539 - Forward and Copy 1541 It is useful in some cases to forward some set of packets normally, 1542 but also to send a copy to a specified other address or interface. 1543 For example, this may be used to implement a lawful intercept 1544 capability or to feed selected packets to an Intrusion Detection 1545 System. 1547 o Other Packet Filters Issues 1549 Filtering performance may vary widely according to implementation 1550 and the types and number of rules. Without acceptable performance, 1551 filtering is not useful. 1553 The precise definition of "acceptable" may vary from SP to SP, and 1554 may depend upon the intended use of the filters. For example, for 1555 some uses a filter may be turned on all the time to set CoS, to 1556 prevent an attack, or to mitigate the effect of a possible future 1557 attack. In this case it is likely that the SP will want the filter 1558 to have minimal or no impact on performance. In other cases, a 1559 filter may be turned on only in response to a major attack (such as 1560 a major DDoS attack). In this case a greater performance impact may 1561 be acceptable to some service providers. 1563 A key consideration with the use of packet filters is that they can 1564 provide few options for filtering packets carrying encrypted data. 1565 Because the data itself is not accessible, only packet header 1566 information or other unencrypted fields can be used for filtering. 1568 5.3.2. Firewalls 1570 Firewalls provide a mechanism for controlling traffic passing 1571 between different trusted zones in the MPLS/GMPLS model or between 1572 a trusted zone and an untrusted zone. Firewalls typically provide 1573 MPLS/GMPLS Security framework 1574 much more functionality than filters, because they may be able to 1575 apply detailed analysis and logical functions to flows, and not 1576 just to individual packets. They may offer a variety of complex 1577 services, such as threshold-driven DoS attack protection, virus 1578 scanning, acting as a TCP connection proxy, etc. 1580 As with other access control techniques, the value of firewalls 1581 depends on a clear understanding of the topologies of the 1582 MPLS/GMPLS core network, the user networks, and the threat model. 1583 Their effectiveness depends on a topology with a clearly defined 1584 inside (secure) and outside (not secure). 1586 Firewalls may be applied to help protect MPLS/GMPLS core network 1587 functions from attacks originating from the Internet or from 1588 MPLS/GMPLS user sites, but typically other defensive techniques 1589 will be used for this purpose. 1591 Where firewalls are employed as a service to protect user VPN sites 1592 from the Internet, different VPN users, and even different sites of 1593 a single VPN user, may have varying firewall requirements. The 1594 overall PPVPN logical and physical topology, along with the 1595 capabilities of the devices implementing the firewall services, has 1596 a significant effect on the feasibility and manageability of such 1597 varied firewall service offerings. 1599 Another consideration with the use of firewalls is that they can 1600 provide few options for handling packets carrying encrypted data. 1601 Because the data itself is not accessible, only packet header 1602 information, other unencrypted fields, or analysis of the flow of 1603 encrypted packets can be used for making decisions on accepting or 1604 rejecting encrypted traffic. 1606 Two approaches are to move the firewall outside of the encrypted 1607 part of the path or to register and pre-approve the encrypted 1608 session with the firewall. 1610 Handling DoS attacks has become increasingly important. Useful 1611 guidelines include the following: 1612 1. Perform ingress filtering everywhere. Upstream detection and 1613 prevention are better. 1614 2. Be able to filter DoS attack packets at line speed. 1615 3. Do not allow oneself to amplify attacks. 1616 4. Continue processing legitimate traffic. Over provide for heavy 1617 loads. Use diverse locations, technologies, etc. 1619 5.3.3. Access Control to Management Interfaces 1620 MPLS/GMPLS Security framework 1621 Most of the security issues related to management interfaces can be 1622 addressed through the use of authentication techniques as described 1623 in the section on authentication. However, additional security may 1624 be provided by controlling access to management interfaces in other 1625 ways. 1627 The Optical Internetworking Forum has done relevant work on 1628 protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, 1629 etc. See OIF-SMI-01.0 "Security for Management Interfaces to 1630 Network Elements" [OIF-SMI-01.0], and "Addendum to the Security for 1631 Management Interfaces to Network Elements" [OIF-SMI-02.1]. See also 1632 the work in the ISMS WG. 1634 Management interfaces, especially console ports on MPLS/GMPLS 1635 devices, may be configured so they are only accessible out-of-band, 1636 through a system which is physically or logically separated from 1637 the rest of the MPLS/GMPLS infrastructure. 1639 Where management interfaces are accessible in-band within the 1640 MPLS/GMPLS domain, filtering or firewalling techniques can be used 1641 to restrict unauthorized in-band traffic from having access to 1642 management interfaces. Depending on device capabilities, these 1643 filtering or firewalling techniques can be configured either on 1644 other devices through which the traffic might pass, or on the 1645 individual MPLS/GMPLS devices themselves. 1647 5.4. Use of Isolated Infrastructure 1649 One way to protect the infrastructure used for support of 1650 MPLS/GMPLS is to separate the resources for support of MPLS/GMPLS 1651 services from the resources used for other purposes (such as 1652 support of Internet services). In some cases this may involve using 1653 physically separate equipment for VPN services, or even a 1654 physically separate network. 1656 For example, PE-based IP VPNs may be run on a separate backbone not 1657 connected to the Internet, or may use separate edge routers from 1658 those supporting Internet service. Private IPv4 addresses (local to 1659 the provider and non-routable over the Internet) are sometimes used 1660 to provide additional separation. For a discussion of comparable 1661 techniques for IPv6, see "Local Network Protection for IPv6," RFC 1662 4864 [RFC4864]. 1664 In a GMPLS network it is possible to operate the control plane using 1665 physically separate resources from those used for the data plane. 1666 This means that the data plane resources can be physically protected 1667 and isolated from other equipment to protect users' data while the 1668 MPLS/GMPLS Security framework 1669 control and management traffic uses network resources that can be 1670 accessed by operators to configure the network. Conversely, the 1671 separation of control and data traffic may lead the operator to 1672 consider that the network is secure because the data plane resources 1673 are physically secure. However, this is not the case if the control 1674 plane can be attacked through a shared or open network, and control 1675 plane protection techniques must still be applied. 1677 5.5. Use of Aggregated Infrastructure 1679 In general, it is not feasible to use a completely separate set of 1680 resources for support of each service. In fact, one of the main 1681 reasons for MPLS/GMPLS enabled services is to allow sharing of 1682 resources between multiple services and multiple users. Thus, even 1683 if certain services use a separate network from Internet services, 1684 nonetheless there will still be multiple MPLS/GMPLS users sharing 1685 the same network resources. In some cases MPLS/GMPLS services will 1686 share network resources with Internet services or other services. 1688 It is therefore important for MPLS/GMPLS services to provide 1689 protection between resources used by different parties. Thus, a 1690 well-behaved MPLS/GMPLS user should be protected from possible 1691 misbehavior by other users. This requires several security 1692 measurements to be implemented. Resource limits can be placed on a 1693 per service and per user basis. Possibilities include, for example, 1694 using virtual router or logical router to define hardware or 1695 software resource limits per service or per individual user; using 1696 rate limiting per VPN or per Internet connection to provide 1697 bandwidth protection; or using resource reservation for control 1698 plane traffic. In addition to bandwidth protection, separate 1699 resource allocation can be used to limit security attacks only to 1700 directly impacted service(s) or customer(s). Strict, separate, and 1701 clearly defined engineering rules and provisioning procedures can 1702 reduce the risks of network-wide impact of a control plane attack, 1703 DoS attack, or mis-configuration. 1705 In general, the use of aggregated infrastructure allows the service 1706 provider to benefit from stochastic multiplexing of multiple bursty 1707 flows, and also may in some cases thwart traffic pattern analysis 1708 by combining the data from multiple users. However, service 1709 providers must minimize security risks introduced from any 1710 individual service or individual users. 1712 5.6. Service Provider Quality Control Processes 1714 Deployment of provider-provisioned VPN services in general requires 1715 a relatively large amount of configuration by the SP. For example, 1716 MPLS/GMPLS Security framework 1717 the SP needs to configure which VPN each site belongs to, as well 1718 as QoS and SLA guarantees. This large amount of required 1719 configuration leads to the possibility of misconfiguration. 1721 It is important for the SP to have operational processes in place 1722 to reduce the potential impact of misconfiguration. CE-to-CE 1723 authentication may also be used to detect misconfiguration when it 1724 occurs. CE-to-CE encryption may also limit the damage when it 1725 occurs. 1727 5.7. Deployment of Testable MPLS/GMPLS Service. 1729 This refers to solutions that can be readily tested to make sure 1730 they are configured correctly. For example, for a point-to-point 1731 connection, checking that the intended connectivity is working 1732 pretty much ensures that there is no unintended connectivity to 1733 some other site. 1735 5.8. Verification of Connectivity 1737 In order to protect against deliberate or accidental misconnection, 1738 mechanisms can be put in place to verify both end-to-end 1739 connectivity and hop-by-hop resources. These mechanisms can trace 1740 the routes of LSPs in both the control plane and the data plane. 1742 It should be noted that if there is an attack on the control plane, 1743 data plane connectivity test mechanisms that rely on the control 1744 plane can also be attacked. This may hide faults through false 1745 positives or to disrupt functioning services through false 1746 negatives. 1748 6. Monitoring, Detection, and Reporting of Security Attacks 1750 MPLS/GMPLS network and service may be subject to attacks from a 1751 variety of security threats. Many threats are described in Section 1752 4 of this document. Many of the defensive techniques described in 1753 this document and elsewhere provide significant levels of 1754 protection from a variety of threats. However, in addition to 1755 employing defensive techniques silently to protect against attacks, 1756 MPLS/GMPLS services can also add value for both providers and 1757 customers by implementing security monitoring systems to detect and 1758 report on any security attacks, regardless of whether the attacks 1759 are effective. 1761 Attackers often begin by probing and analyzing defenses, so systems 1762 that can detect and properly report these early stages of attacks 1763 can provide significant benefits. 1765 MPLS/GMPLS Security framework 1766 Information concerning attack incidents, especially if available 1767 quickly, can be useful in defending against further attacks. It 1768 can be used to help identify attackers or their specific targets at 1769 an early stage. This knowledge about attackers and targets can be 1770 used to strengthen defenses against specific attacks or attackers, 1771 or to improve the defenses for specific targets on an as-needed 1772 basis. Information collected on attacks may also be useful in 1773 identifying and developing defenses against novel attack types. 1775 Monitoring systems used to detect security attacks in MPLS/GMPLS 1776 typically operate by collecting information from the Provider Edge 1777 (PE), Customer Edge (CE), and/or Provider backbone (P) devices. 1778 Security monitoring systems should have the ability to actively 1779 retrieve information from devices (e.g., SNMP get) or to passively 1780 receive reports from devices (e.g., SNMP notifications). The 1781 Security monitoring systems may actively retrieve information from 1782 devices (e.g., SNMP get) or passively receive reports from devices 1783 (e.g., SNMP notifications). The specific information exchanged 1784 depends on the capabilities of the devices and on the type of VPN 1785 technology. Particular care should be given to securing the 1786 communications channel between the monitoring systems and the 1787 MPLS/GMPLS devices. Syslog WG is specifying "Logging Capabilities 1788 for IP Network Infrastructure". (The specific references will be 1789 made only if the draft(s) became RFC before this draft.) 1791 The CE, PE, and P devices should employ efficient methods to 1792 acquire and communicate the information needed by the security 1793 monitoring systems. It is important that the communication method 1794 between MPLS/GMPLS devices and security monitoring systems be 1795 designed so that it will not disrupt network operations. As an 1796 example, multiple attack events may be reported through a single 1797 message, rather than allowing each attack event to trigger a 1798 separate message, which might result in a flood of messages, 1799 essentially becoming a DoS attack against the monitoring system or 1800 the network. 1802 The mechanisms for reporting security attacks should be flexible 1803 enough to meet the needs of MPLS/GMPLS service providers, 1804 MPLS/GMPLS customers, and regulatory agencies, if applicable. The 1805 specific reports should depend on the capabilities of the devices, 1806 the security monitoring system, the type of VPN, and the service 1807 level agreements between the provider and customer. 1809 7. Service Provider General Security Requirements 1811 This section covers security requirements the provider may have for 1812 securing its MPLS/GMPLS network infrastructure including LDP and 1813 RSVP-TE specific requirements. 1815 MPLS/GMPLS Security framework 1816 The MPLS/GMPLS service provider's requirements defined here are for 1817 the MPLS/GMPLS core in the reference model. The core network can 1818 be implemented with different types of network technologies, and 1819 each core network may use different technologies to provide the 1820 various services to users with different levels of offered 1821 security. Therefore, a MPLS/GMPLS service provider may fulfill any 1822 number of the security requirements listed in this section. This 1823 document does not state that a MPLS/GMPLS network must fulfill all 1824 of these requirements to be secure. 1826 These requirements are focused on: 1) how to protect the MPLS/GMPLS 1827 core from various attacks originating outside the core including 1828 those from network users, both accidentally and maliciously, and 2) 1829 how to protect the end users. 1831 7.1. Protection within the Core Network 1833 7.1.1. Control Plane Protection - General 1835 - Protocol authentication within the core: 1837 The network infrastructure must support mechanisms for 1838 authentication of the control plane messages. If a MPLS/GMPLS core 1839 is used, LDP sessions may be authenticated with TCP MD5. In 1840 addition, IGP and BGP authentication should be considered. For a 1841 core providing various IP, VPN, or transport services, PE-to-PE 1842 authentication may also be performed via IPsec. See the above 1843 discussion of protocol security services: authentication, integrity 1844 (with replay detection), confidentiality. Protocols need to provide 1845 a complete set of security services from which the SP can choose. 1846 Also, the important but often harder part is key management. 1847 Considerations, guidelines, and strategies regarding key management 1848 are discussed in [RFC3562], [RFC4107], [RFC4808]. 1850 With today's processors, applying cryptograpgic authentication to 1851 the control plane may not increase the cost of deployment for 1852 providers significantly, and will help to improve the security of 1853 the core. If the core is dedicated to MPLS/GMPLS enabled services 1854 without any interconnects to third parties, then this may reduce 1855 the requirement for authentication of the core control plane. 1857 - Infrastructure Hiding 1859 Here we discuss means to hide the provider's infrastructure nodes. 1861 MPLS/GMPLS Security framework 1862 A MPLS/GMPLS provider may make its infrastructure routers (P and PE 1863 routers) unreachable from outside users and unauthorized internal 1864 users. For example, separate address space may be used for the 1865 infrastructure loopbacks. 1867 Normal TTL propagation may be altered to make the backbone look 1868 like one hop from the outside, but caution needs to be taken for 1869 loop prevention. This prevents the backbone addresses from being 1870 exposed through trace route; however this must also be assessed 1871 against operational requirements for end-to-end fault tracing. 1873 An Internet backbone core may be re-engineered to make Internet 1874 routing an edge function, for example, by using MPLS label 1875 switching for all traffic within the core and possibly making the 1876 Internet a VPN within the PPVPN core itself. This helps to detach 1877 Internet access from PPVPN services. 1879 Separating control plane, data plane, and management plane 1880 functionality in hardware and software may be implemented on the PE 1881 devices to improve security. This may help to limit the problems 1882 when attacked in one particular area, and may allow each plane to 1883 implement additional security measures separately. 1885 PEs are often more vulnerable to attack than P routers, because PEs 1886 cannot be made unreachable from outside users by their very nature. 1887 Access to core trunk resources can be controlled on a per user 1888 basis by using of inbound rate-limiting or traffic shaping; this 1889 can be further enhanced on a per Class of Service basis (see 1890 Section 8.2.3) 1892 In the PE, using separate routing processes for different services, 1893 for example, Internet and PPVPN service, may help to improve the 1894 PPVPN security and better protect VPN customers. Furthermore, if 1895 resources, such as CPU and memory, can be further separated based 1896 on applications, or even individual VPNs, it may help to provide 1897 improved security and reliability to individual VPN customers. 1899 7.1.2. Control Plane Protection with RSVP-TE 1901 - General RSVP Security Tools 1903 Isolation of the trusted domain is an important security mechanism 1904 for RSVP, to ensure that an untrusted element cannot access a 1905 router of the trusted domain. However, ASBR-ASBR communication for 1906 inter-AS LSPs needs to be secured specifically. Isolation 1907 mechanisms might also be bypassed by IPv4 Router Alert or IPv6 1908 using Next Header 0 packets. A solution could consists of disabling 1909 the processing of IP options. This drops or ignores all IP packets 1910 MPLS/GMPLS Security framework 1911 with IPv4 options, including the router alert option used by RSVP; 1912 however, this may have an impact on other protocols using IPv4 1913 options. An alternative is to configure access-lists on all 1914 incoming interfaces dropping IPv4 protocol or IPv6 next header 46 1915 (RSVP). 1917 RSVP security can be strengthened by deactivating RSVP on 1918 interfaces with neighbors who are not authorized to use RSVP, to 1919 protect against adjacent CE-PE attacks. However, this does not 1920 really protect against DoS attacks or attacks on non-adjacent 1921 routers. It has been demonstrated that substantial CPU resources 1922 are consumed simply by processing received RSVP packets, even if 1923 the RSVP process is deactivated for the specific interface on which 1924 the RSVP packets are received. 1926 RSVP neighbor filtering at the protocol level, to restrict the set 1927 of neighbors that can send RSVP messages to a given router, 1928 protects against non-adjacent attacks. However, this does not 1929 protect against DoS attacks and does not effectively protect 1930 against spoofing of the source address of RSVP packets, if the 1931 filter relies on the neighbor's address within the RSVP message. 1933 RSVP neighbor filtering at the data plane level, with an access 1934 list to accept IP packets with port 46 only for specific neighbors 1935 requires Router Alert mode to be deactivated and does not protect 1936 against spoofing. 1938 Another valuable tool is RSVP message pacing, to limit the number 1939 of RSVP messages sent to a given neighbor during a given period. 1940 This allows blocking DoS attack propagation. 1942 - Another approach is to limit the impact of an attack on control 1943 plane resources. 1945 To ensure continued effective operation of the MPLS router even in 1946 the case of an attack that bypasses packet filtering mechanisms 1947 such as Access Control Lists in the data plane, it is important 1948 that routers have some mechanisms to limit the impact of the 1949 attack. There should be a mechanism to rate limit the amount of 1950 control plane traffic addressed to the router, per interface. This 1951 should be configurable on a per-protocol basis, (and, ideally, on a 1952 per-sender basis) to avoid letting an attacked protocol or a given 1953 sender blocking all communications. This requires the ability to 1954 filter and limit the rate of incoming messages of particular 1955 protocols, such as RSVP (filtering at the IP protocol level), and 1956 particular senders. In addition, there should be a mechanism to 1957 limit CPU and memory capacity allocated to RSVP, so as to protect 1958 other control plane elements. To limit memory allocation, it will 1959 MPLS/GMPLS Security framework 1960 probably be necessary to limit the number of LSPs that can be set 1961 up. 1963 - Authentication for RSVP messages 1965 RSVP message authentication is described in RFC 2747 [RFC2747] and 1966 RFC 3097 [RFC3097]. It is one of the most powerful tools for 1967 protection against RSVP-based attacks. It applies cryptographic 1968 authentication to RSVP messages based on a secure message hash 1969 using a key shared by RSVP neighbors. This protects against LSP 1970 creation attacks, at the expense of consuming significant CPU 1971 resources for digest computation. In addition, if the neighboring 1972 RSVP speaker is compromised, it could be used to launch attacks 1973 using authenticated RSVP messages. These methods, and certain other 1974 aspects of RSVP security, are explained in detail in RFC 4230 1975 [RFC4230]. Key management must be implemented. Logging and auditing 1976 as well as multiple layers of cryptographic protection can help 1977 here. IPsec can also be used in some cases. See [RFC4230].. 1979 One challenge using RSVP message authentication arises in many 1980 cases where non-RSVP nodes are present in the network. In such 1981 cases the RSVP neighbor may not be known up front, thus neighbor 1982 based keying approaches fail, unless the same key is used 1983 everywhere, which is not recommended for security reasons. Group 1984 keying may help in such cases. The security properties of various 1985 keying approaches are discussed in detail in [RSVP-key]. 1987 7.1.3. Control Plane Protection with LDP 1989 The approaches to protect MPLS routers against LDP-based attacks 1990 are similar to those for RSVP, including isolation, protocol 1991 deactivation on specific interfaces, filtering of LDP neighbors at 1992 the protocol level, filtering of LDP neighbors at the data plane 1993 level (with an access list that filters the TCP and UDP LDP ports), 1994 authentication with a message digest, rate limiting of LDP messages 1995 per protocol per sender, and limiting all resources allocated to 1996 LDP-related tasks. 1998 7.1.4. Data Plane Protection 2000 IPsec can provide authentication, integrity, confidentiality, and 2001 replay detection for provider or user data. It also has an 2002 associated key management protocol. 2004 In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is 2005 not provided as a basic feature. Mechanisms described in section 5 2006 MPLS/GMPLS Security framework 2007 can be used to secure the MPLS data plane traffic carried over a 2008 MPLS core. Both the Frame Relay Forum and the ATM Forum 2009 standardized cryptographic security services in the late 1990s, but 2010 these standards are not widely implemented. 2012 7.2. Protection on the User Access Link 2014 Peer or neighbor protocol authentication may be used to enhance 2015 security. For example, BGP MD5 authentication may be used to 2016 enhance security on PE-CE links using eBGP. In the case of Inter- 2017 provider connections, cryptographic protection mechanisms, such as 2018 IPsec, may be used between ASes. 2020 If multiple services are provided on the same PE platform, 2021 different WAN address spaces may be used for different services 2022 (e.g., VPN and non-VPN) to enhance isolation. 2024 Firewall and Filtering: access control mechanisms can be used to 2025 filter any packets destined for the service provider's 2026 infrastructure prefix or eliminate routes identified as 2027 illegitimate. 2029 Rate limiting may be applied to the user interface/logical 2030 interfaces as a defense against DDoS bandwidth attack. This is 2031 helpful when the PE device is supporting both multiple services, 2032 especially VPN and Internet Services, on the same physical 2033 interfaces through different logical interfaces. 2035 7.2.1. Link Authentication 2037 Authentication can be used to validate site access to the network 2038 via fixed or logical connections, e.g., L2TP or IPsec, 2039 respectively. If the user wishes to hold the authentication 2040 credentials for access, then provider solutions require the 2041 flexibility for either direct authentication by the PE itself or 2042 interaction with a customer authentication server. Mechanisms are 2043 required in the latter case to ensure that the interaction between 2044 the PE and the customer authentication server is appropriately 2045 secured. 2047 7.2.2. Access Routing Control 2049 Choice of routing protocols, e.g., RIP, OSPF, or BGP, may be used 2050 to provide control access between a CE and a PE. Per neighbor and 2051 per VPN routing policies may be established to enhance security and 2052 reduce the impact of a malicious or non-malicious attack on the PE; 2053 the following mechanisms, in particular, should be considered: 2055 MPLS/GMPLS Security framework 2056 - Limiting the number of prefixes that may be advertised on 2057 a per access basis into the PE. Appropriate action may be 2058 taken should a limit be exceeded, e.g., the PE shutting 2059 down the peer session to the CE 2060 - Applying route dampening at the PE on received routing 2061 updates 2062 - Definition of a per VPN prefix limit after which 2063 additional prefixes will not be added to the VPN routing 2064 table. 2066 In the case of Inter-provider connection, access protection, link 2067 authentication, and routing policies as described above may be 2068 applied. Both inbound and outbound firewall or filtering mechanism 2069 between ASes may be applied. Proper security procedures must be 2070 implemented in Inter-provider interconnection to protect the 2071 providers' network infrastructure and their customers. This may be 2072 custom designed for each Inter-Provider peering connection, and 2073 must be agreed upon by both providers. 2075 7.2.3. Access QoS 2077 MPLS/GMPLS providers offering QoS-enabled services require 2078 mechanisms to ensure that individual accesses are validated against 2079 their subscribed QoS profile and as such gain access to core 2080 resources that match their service profile. Mechanisms such as per 2081 Class of Service rate limiting or traffic shaping on ingress to the 2082 MPLS/GMPLS core are two options for providing this level of 2083 control. Such mechanisms may require the per Class of Service 2084 profile to be enforced either by marking, or remarking, or 2085 discarding of traffic outside of the profile. 2087 7.2.4. Customer Service Monitoring Tools 2089 End users needing specific statistics on the core, e.g., routing 2090 table, interface status, or QoS statistics, place requirements on 2091 mechanisms at the PE both to validate the incoming user and limit 2092 the views available to that particular user. Mechanisms should 2093 also be considered to ensure that such access cannot be used as 2094 means to construct DoS attack (either maliciously or accidentally) 2095 on the PE itself. This could be accomplished either through 2096 separation of these resources within the PE itself or via the 2097 capability to rate-limit such traffic on a per physical or logical 2098 connection basis. 2100 7.3. General User Requirements for MPLS/GMPLS Providers 2101 MPLS/GMPLS Security framework 2102 MPLS/GMPLS providers must support end users' security requirements. 2103 Depending on the technologies used, these requirements may include: 2105 - User control plane separation through routing isolation 2106 when applicable, for example, in the case of MPLS VPNs. 2107 - Protection against intrusion, DoS attacks, and spoofing 2108 - Access Authentication 2109 - Techniques highlighted throughout this document that 2110 identify methodologies for the protection of resources and 2111 the MPLS/GMPLS infrastructure. 2113 Hardware or software errors in equipment leading to breaches in 2114 security are not within the scope of this document. 2116 8. Inter-provider Security Requirements 2118 This section discusses security capabilities that are important at 2119 the MPLS/GMPLS Inter-provider connections and at devices (including 2120 ASBR routers) supporting these connections. The security 2121 capabilities stated in this section should be considered as 2122 complementary to security considerations addressed in individual 2123 protocol specifications or security frameworks. 2125 Security vulnerabilities and exposures may be propagated across 2126 multiple networks because of security vulnerabilities arising in 2127 one peer's network. Threats to security originate from accidental, 2128 administrative, and intentional sources. Intentional threats 2129 include events such as spoofing and Denial of Service (DoS) 2130 attacks. 2132 The level and nature of threats, as well as security and 2133 availability requirements, may vary over time and from network to 2134 network. This section, therefore, discusses capabilities that need 2135 to be available in equipment deployed for support of the MPLS 2136 InterCarrier Interconnect (MPLS-ICI). Whether any particular 2137 capability is used in any one specific instance of the ICI is up to 2138 the service providers managing the PE equipment offering or using 2139 the ICI services. 2141 8.1. Control Plane Protection 2143 This section discusses capabilities for control plane protection, 2144 including protection of routing, signaling, and OAM capabilities. 2146 MPLS/GMPLS Security framework 2147 8.1.1. Authentication of Signaling Sessions 2149 Authentication may be needed for signaling sessions (i.e., BGP, 2150 LDP, and RSVP-TE) and routing sessions (e.g., BGP), as well as OAM 2151 sessions across domain boundaries. Equipment must be able to 2152 support the exchange of all protocol messages over IPsec ESP, with 2153 NULL encryption and authentication, between the peering ASBRs. 2154 Support for message authentication for LDP, BGP, and RSVP-TE 2155 authentication must also be provided. Manual keying of IPsec should 2156 not be used. IKEv2 with pre-shared secrets or public key methods 2157 should be used. Replay detection should be used. 2159 Mechanisms to authenticate and validate a dynamic setup request 2160 must be available. For instance, if dynamic signaling of a TE-LSP 2161 or PW is crossing a domain boundary, there must be a way to detect 2162 whether the LSP source is who it claims to be and that it is 2163 allowed to connect to the destination. 2165 Message authentication support for all TCP-based protocols within 2166 the scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and 2167 Message authentication with the RSVP-TE Integrity Object must be 2168 provided to interoperate with current practices. 2169 Equipment should be able to support exchange of all signaling and 2170 routing (LDP, RSVP-TE, and BGP) protocol messages over a single 2171 IPsec security association pair in tunnel or transport mode with 2172 authentication but with NULL encryption, between the peering ASBRs. 2173 IPsec, if supported, must be supported with HMAC-SHA-1 and 2174 alternatively with HMAC-SHA-2 and optionally SHA-1. It is expected 2175 that authentication algorithms will evolve over time and support 2176 can be updated as needed. 2178 OAM Operations across the MPLS-ICI could also be the source of 2179 security threats on the provider infrastructure as well as the 2180 service offered over the MPLS-ICI. A large volume of OAM messages 2181 could overwhelm the processing capabilities of an ASBR if the ASBR 2182 is not properly protected. Maliciously generated OAM messages could 2183 also be used to bring down an otherwise healthy service (e.g., MPLS 2184 Pseudo Wire), and therefore affect service security. MPLS-ping does 2185 not support authentication today, and that support should be 2186 subject for future considerations. Bidirectional Forwarding 2187 Detection (BFD), however, does have support for carrying an 2188 authentication object. It also supports Time-To-Live (TTL) 2189 processing as an anti-replay measure. Implementations conformant 2190 with this MPLS-ICI should support BFD authentication and must 2191 support the procedures for TTL processing. 2193 MPLS/GMPLS Security framework 2194 8.1.2. Protection Against DoS Attacks in the Control 2195 Plane 2197 Implementations must have the ability to prevent signaling and 2198 routing DoS attacks on the control plane per interface and 2199 provider. Such prevention may be provided by rate-limiting 2200 signaling and routing messages that can be sent by a peer provider 2201 according to a traffic profile and by guarding against malformed 2202 packets. 2204 Equipment must provide the ability to filter signaling, routing, 2205 and OAM packets destined for the device, and must provide the 2206 ability to rate limit such packets. Packet filters should be 2207 capable of being separately applied per interface, and should have 2208 minimal or no performance impact. For example, this allows an 2209 operator to filter or rate-limit signaling, routing, and OAM 2210 messages that can be sent by a peer provider and limit such traffic 2211 to a given profile. 2213 During a control plane DoS attack against an ASBR, the router 2214 should guarantee sufficient resources to allow network operators to 2215 execute network management commands to take corrective action, such 2216 as turning on additional filters or disconnecting an interface 2217 under attack. DoS attacks on the control plane should not adversely 2218 affect data plane performance. 2220 Equipment running BGP must support the ability to limit the number 2221 of BGP routes received from any particular peer. Furthermore, in 2222 the case of IPVPN, a router must be able to limit the number of 2223 routes learned from a BGP peer per IPVPN. In the case that a device 2224 has multiple BGP peers, it should be possible for the limit to vary 2225 between peers. 2227 8.1.3. Protection against Malformed Packets 2229 Equipment should be robust in the presence of malformed protocol 2230 packets. For example, malformed routing, signaling, and OAM packets 2231 should be treated in accordance with the relevant protocol 2232 specification. 2234 8.1.4. Ability to Enable/Disable Specific Protocols 2236 Equipment must have the ability to drop any signaling or routing 2237 protocol messages when these messages are to be processed by the 2238 ASBR but the corresponding protocol is not enabled on that 2239 interface. 2241 MPLS/GMPLS Security framework 2242 Equipment must allow an administrator to enable or disable a 2243 protocol (by default, the protocol is disabled unless 2244 administratively enabled) on an interface basis. 2246 Equipment must be able to drop any signaling or routing protocol 2247 messages when these messages are to be processed by the ASBR but 2248 the corresponding protocol is not enabled on that interface. This 2249 dropping should not adversely affect data plane or control plane 2250 performance. 2252 8.1.5. Protection Against Incorrect Cross Connection 2254 The capability of detecting and locating faults in a LSP cross- 2255 connect must be provided. Such faults may cause security violations 2256 as they result in directing traffic to the wrong destinations. This 2257 capability may rely on OAM functions. Equipment must support MPLS 2258 LSP ping [RFC4379]. This may be used to verify end-to-end 2259 connectivity for the LSP (e.g., PW, TE Tunnel, VPN LSP, etc.), and 2260 to verify PE-to-PE connectivity for IP VPN services. 2262 When routing information is advertised from one domain to the 2263 other, operators must be able to guard against situations that 2264 result in traffic hijacking, black-holing, resource stealing (e.g., 2265 number of routes), etc. For instance, in the IPVPN case, an 2266 operator must be able to block routes based on associated route 2267 target attributes. In addition, mechanisms must exist to verify 2268 whether a route advertised by a peer for a given VPN is actually a 2269 valid route and whether the VPN has a site attached to or reachable 2270 through that domain. 2272 Equipment (ASBRs and Route Reflectors (RRs)) supporting operation 2273 of BGP must be able to restrict which Route Target attributes are 2274 sent to and accepted from a BGP peer across an ICI. Equipment 2275 (ASBRs, RRs) should also be able to inform the peer regarding which 2276 Route Target attributes it will accept from a peer, because sending 2277 an incorrect Route Target can result in incorrect cross-connection 2278 of VPNs. Also, sending inappropriate route targets to a peer may 2279 disclose confidential information. 2281 8.1.6. Protection Against Spoofed Updates and Route 2282 Advertisements 2284 Equipment must support route filtering of routes received via a BGP 2285 peer session by applying policies that include one or more of the 2286 following: AS path, BGP next hop, standard community, or extended 2287 community. 2289 MPLS/GMPLS Security framework 2290 8.1.7. Protection of Confidential Information 2292 The ability to identify and block messages with confidential 2293 information from leaving the trusted domain that can reveal 2294 confidential information about network operation (e.g., performance 2295 OAM messages or MPLS-ping messages) is required. SPs must have the 2296 flexibility of handling these messages at the ASBR. 2298 Equipment should be able to identify and restrict where it sends 2299 messages that can reveal confidential information about network 2300 operation (e.g., performance OAM messages, LSP Traceroute 2301 messages). Service Providers must have the flexibility of handling 2302 these messages at the ASBR. For example, equipment supporting LSP 2303 Traceroute may limit to which addresses replies can be sent. 2304 Note: This capability should be used with care. For example, if a 2305 SP chooses to prohibit the exchange of LSP ping messages at the 2306 ICI, it may make it more difficult to debug incorrect cross- 2307 connection of LSPs or other problems. 2308 A SP may decide to progress these messages if they arrive from a 2309 trusted provider and are targeted to specific, agreed-on addresses. 2310 Another provider may decide to traffic police, reject, or apply 2311 other policies to these messages. Solutions must enable providers 2312 to control the information that is relayed to another provider 2313 about the path that a LSP takes. For example, when using the RSVP- 2314 TE record route object or MPLS-ping trace, a provider must be able 2315 to control the information contained in corresponding messages when 2316 sent to another provider. 2318 8.1.8. Protection Against Over-provisioned Number of 2319 RSVP-TE LSPs and Bandwidth Reservation 2321 In addition to the control plane protection mechanisms listed in 2322 the previous section on Control plane protection with RSVP-TE, the 2323 ASBR must be able both to limit the number of LSPs that can be set 2324 up by other domains and to limit the amount of bandwidth that can 2325 be reserved. A provider's ASBR may deny a LSP set up request or a 2326 bandwidth reservation request sent by another provider's whose the 2327 limits have been reached. 2329 8.2. Data Plane Protection 2331 8.2.1. Protection against DoS in the Data Plane 2333 This is described in Section 5 of this document. 2335 8.2.2. Protection Against Label Spoofing 2336 MPLS/GMPLS Security framework 2337 Equipment must be able to verify that a label received across an 2338 interconnect was actually assigned to a LSP arriving across that 2339 interconnect. If a label not assigned to a LSP arrives at this 2340 router from the correct neighboring provider, the packet must be 2341 dropped. This verification can be applied to the top label only. 2342 The top label is the received top label and every label that is 2343 exposed by label popping to be used for forwarding decisions. 2345 Equipment must provide the capability of dropping MPLS-labeled 2346 packets if all labels in the stack are not processed. This lets 2347 SPs guarantee that every label that enters its domain from another 2348 carrier was actually assigned to that carrier. 2350 The following requirements are not directly reflected in this 2351 document but must be used as guidance for addressing further work. 2353 Solutions must NOT force operators to reveal reachability 2354 information to routers within their domains. 2359 Mechanisms to authenticate and validate a dynamic setup request 2360 must be available. For instance, if dynamic signaling of a TE-LSP 2361 or PW is crossing a domain boundary, there must be a way to detect 2362 whether the LSP source is who it claims to be and that it is 2363 allowed to connect to the destination. 2365 8.2.3. Protection Using Ingress Traffic Policing and 2366 Enforcement 2368 The following simple diagram illustrates a potential security issue 2369 on the data plane across a MPLS interconnect: 2371 SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1 2372 | | | | 2373 |< AS2 >||< AS1 >| 2375 Traffic flow direction is from SP2 to SP1 2377 In the case of down stream label assignment, the transit label used 2378 by ASBR2 is allocated by ASBR1, which in turn advertises it to 2379 ASB2 (downstream unsolicited or on-demand), this label is used for 2380 a service context (VPN label, PW VC label, etc.), and this LSP is 2381 normally terminated at a forwarding table belonging to the service 2382 instance on PE (PE1) in SP1. 2384 MPLS/GMPLS Security framework 2385 In the example above, ASBR1 would not know whether the label of an 2386 incoming packet from ASBR2 over the interconnect is a VPN label or 2387 PSN label for AS1. So it is possible (though unlikely) that ASBR2 2388 can be accidentally or intentionally configured such that the 2389 incoming label could match a PSN label (e.g., LDP) in AS1. Then, 2390 this LSP would end up on the global plane of an infrastructure 2391 router (P or PE1), and this could invite a unidirectional attack on 2392 that P or PE1 where the LSP terminates. 2394 To mitigate this threat, implementations should be able to do a 2395 forwarding path look-up for the label on an incoming packet from an 2396 interconnect in a Label Forwarding Information Base (LFIB) space 2397 that is only intended for its own service context or provide a 2398 mechanism on the data plane that would ensure the incoming labels 2399 are what ASBR1 has allocated and advertised. 2401 A similar concept has been proposed in "Requirements for Multi- 2402 Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [RFC5254]. 2404 When using upstream label assignment, the upstream source must be 2405 identified and authenticated so the labels can be accepted as from a 2406 trusted source. 2408 9. Summary of MPLS and GMPLS Security 2410 The following summary provides a quick check list of MPLS and GMPLS 2411 security threats, defense techniques, and the best practice guide 2412 outlines for MPLS and GMPLS deployment. 2414 9.1. MPLS and GMPLS Specific Security Threats 2416 9.1.1. Control Plane Attacks 2418 Types of attacks on the control plane: 2419 - Unauthorized LSP creation 2420 - LSP message interception 2422 MPLS/GMPLS Security framework 2424 Attacks against RSVP-TE: DoS attack with setting up 2425 unauthorized LSP and/or LSP messages. 2427 Attacks against LDP: DoS attack with storms of LDP Hello 2428 messages or LDP TCP SYN messages. 2430 Attacks may be launched from external or internal sources, or 2431 through a SP's management systems. 2433 Attacks may be targeted at the SP's routing protocols or 2434 infrastructure elements. 2436 In general, control protocols may be attacked by: 2437 - MPLS signaling (LDP, RSVP-TE) 2438 - PCE signaling 2439 - IPsec signaling (IKE and IKEv2) 2440 - ICMP and ICMPv6 2441 - L2TP 2442 - BGP-based membership discovery 2443 - Database-based membership discovery (e.g., RADIUS) 2444 - OAM and diagnostic protocols such as MPLS-ping and LMP 2445 - Other protocols that may be important to the control 2446 infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE. 2448 9.1.2. Data Plane Attacks 2450 - Unauthorized observation of data traffic 2451 - Data traffic modification 2452 - Spoofing and replay 2453 - Unauthorized Deletion 2454 - Unauthorized Traffic Pattern Analysis 2455 - Denial of Service 2457 9.2. Defense Techniques 2459 1) Authentication: 2461 - Bi-directional authentication 2462 - Key management 2463 - Management System Authentication 2464 - Peer-to-peer authentication 2466 2) Cryptographic techniques 2467 3) Use of IPsec in MPLS/GMPLS networks 2468 4) Encryption for device configuration and management 2469 5) Cryptographic Techniques for MPLS Pseudowires 2471 MPLS/GMPLS Security framework 2472 6) End-to-End versus Hop-by-Hop Protection (CE-CE, PE-PE, PE-CE) 2473 7) Access Control techniques 2475 - Filtering 2476 - Firewalls 2477 - Access Control to management interfaces 2479 8) Infrastructure isolation 2480 9) Use of aggregated infrastructure 2481 10) Quality Control Processes 2482 11) Testable MPLS/GMPLS Service 2483 12) End-to-end connectivity verification 2484 13) Hop-by-hop resource configuration verification and discovery 2486 9.3. Service Provider MPLS and GMPLS Best Practice Outlines 2488 9.3.1. SP Infrastructure Protection 2490 1) General control plane protection 2491 - Protocol authentication within the core 2492 - Infrastructure hiding (e.g. disable TTL propagation) 2493 2) RSVP control plane protection 2494 - RSVP security tools 2495 - Isolation of the trusted domain 2496 - Deactivating RSVP on interfaces with neighbors who are not 2497 authorized to use RSVP 2498 - RSVP neighbor filtering at the protocol level and data plane 2499 level 2500 - Authentication for RSVP messages 2501 - RSVP message pacing 2502 3) LDP control plane protection (similar techniques as for RSVP) 2503 4) Data plane protection 2504 - User access link protection 2505 - Link authentication 2506 - Access routing control (e.g., prefix limits, route 2507 dampening, routing table limits (such as VRF limits) 2508 - Access QoS control 2509 - Customer service monitoring tools 2510 - Use of MPLS-ping (with its own control plane security) to 2511 verify end-to-end connectivity of MPLS LSPs 2512 - LMP (with its own security) to verify hop-by-hop 2513 connectivity. 2515 9.3.2. Inter-provider Security 2516 MPLS/GMPLS Security framework 2517 Inter-provider connections are high security risk areas. Similar 2518 techniques and procedures as described for SP's general core 2519 protection are listed below for Inter-provider connections. 2521 1) Control plane protection at Inter-provider connections 2522 - Authentication of signaling sessions 2523 - Protection against DoS attacks in the control plane 2524 - Protection against malformed packets 2525 - Ability to enable/disable specific protocols 2526 - Protection against incorrect cross connection 2527 - Protection against spoofed updates and route advertisements 2528 - Protection of confidential information 2529 - Protection against over-provisioned number of RSVP-TE LSPs 2530 and bandwidth reservation 2532 2) Data Plane Protection at the inter-provider connections 2533 - Protection against DoS in the data plane 2534 - Protection against label spoofing 2536 10. Security Considerations 2538 Security considerations constitute the sole subject of this memo 2539 and hence are discussed throughout. Here we recap what has been 2540 presented and explain at a high level the role of each type of 2541 consideration in an overall secure MPLS/GMPLS system. 2543 The document describes a number of potential security threats. 2544 Some of these threats have already been observed occurring in 2545 running networks; others are largely hypothetical at this time. 2547 DoS attacks and intrusion attacks from the Internet against SPs' 2548 infrastructure have been seen. DoS "attacks" (typically not 2549 malicious) have also been seen in which CE equipment overwhelms PE 2550 equipment with high quantities or rates of packet traffic or 2551 routing information. Operational or provisioning errors are cited 2552 by SPs as one of their prime concerns. 2554 The document describes a variety of defensive techniques that may 2555 be used to counter the suspected threats. All of the techniques 2556 presented involve mature and widely implemented technologies that 2557 are practical to implement. 2559 The document describes the importance of detecting, monitoring, and 2560 reporting attacks, both successful and unsuccessful. These 2561 activities are essential for "understanding one's enemy", 2562 mobilizing new defenses, and obtaining metrics about how secure the 2563 MPLS/GMPLS Security framework 2564 MPLS/GMPLS network is. As such, they are vital components of any 2565 complete PPVPN security system. 2567 The document evaluates MPLS/GMPLS security requirements from a 2568 customer's perspective as well as from a service provider's 2569 perspective. These sections re-evaluate the identified threats 2570 from the perspectives of the various stakeholders and are meant to 2571 assist equipment vendors and service providers, who must ultimately 2572 decide what threats to protect against in any given configuration 2573 or service offering. 2575 11. IANA Considerations 2577 This document contains no new IANA considerations. 2579 12. Normative References 2581 [RFC2747] F. Baker, et al., "RSVP Cryptographic Authentication", 2582 EFC 2741, January 2000. 2584 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 2585 Switching Architecture", RFC 3031, January 2001. 2587 [RFC3097] R. Braden and L. Zhang, "RSVP Cryptographic 2588 Authentication - Updated Message Type Value", RFC 3097, April 2001. 2590 [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 2591 Tunnels", December 2001. 2593 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 2594 (GMPLS) Architecture", RFC 3945, October 2004. 2596 [RFC4106] J. Viega, D. McGrew, "The Use of Galois/Counter Mode 2597 (GCM) in IPsec Encapsulating Security Payload (ESP)", June 2005. 2599 [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet 2600 Protocol," December 2005. 2602 [RFC4302] S. Kent, "IP Authentication Header," December 2005. 2604 [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) 2605 Protocol",December 2005. 2607 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) 2608 CCM Mode with IPsec Encapsulating Security Payload (ESP)", December 2609 2005. 2611 MPLS/GMPLS Security framework 2613 [RFC4379] K. Kompella and G. Swallow, "Detecting Multi-Protocol 2614 Label Switched (MPLS) Data Plane Failures", February 2006. 2616 [RFC4447] Martini, et al., "Pseudowire Setup and Maintenance Using 2617 the Label Distribution Protocol (LDP)", April 2006. 2619 [RFC4835] V. Manral, "Cryptographic Algorithm Implementation 2620 Requirements for Encapsulating Security Payload (ESP) and 2621 Authentication Header (AH)", April 2007. 2623 [RFC5246] T. Dierks and E. Rescorla, "The Transport Layer Security 2624 (TLS) Protocol, Version 1.2," August 2008. 2626 [RFC5036] Andersson, et al., "LDP Specification", October 2007. 2628 [STD62] "Simple Network Management Protocol, Version 3,", December 2629 2002. 2631 [STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification", 2632 STD 8, May 1983. 2634 13. Informative References 2636 [OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces 2637 to Network Elements", Optical Internetworking Forum, Sept. 2003. 2639 [OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for 2640 Management Interfaces to Network Elements", Optical Internetworking 2641 Forum, March 2006. 2643 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 2644 for Message Authentication," February 1997. 2646 [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 2647 Roadmap," November 1998. 2649 [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 2650 1 (SHA1)," September 2001. 2652 [RFC3562] M. Leech, "Key Management Considerations for the TCP MD5 2653 Signature Option", July 2003. 2655 [RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security 2656 Mechanisms for the Internet," December 2003. 2658 MPLS/GMPLS Security framework 2660 [RFC3985] S. Bryant and P. Pate, "Pseudo Wire Emulation Edge-to- 2661 Edge (PWE3) Architecture", March 2005. 2663 [RFC4107] S. Bellovin, R. Housley, "Guidelines for Cryptographic 2664 Key Management", June 2005. 2666 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 2667 Provider-Provisioned Virtual Private Networks (PPVPNs)", July 2005. 2669 [RFC4111] L. Fang, "Security Framework of Provider Provisioned 2670 VPN", July 2005. 2672 [RFC4230] H. Tschofenig and R. Graveman, "RSVP Security 2673 Properties", December 2005. 2675 [RFC4308] P. Hoffman, "Cryptographic Suites for IPsec", December 2676 2005. 2678 [RFC4377] T. Nadeau, M. Morrow, G. Swallow, D. Allan, S. 2679 Matsushima, "Operations and Management (OAM) Requirements for 2680 Multi-Protocol Label Switched (MPLS) Networks," February 2006. 2682 [RFC4378] D. Allan, T. Nadeau, "A Framework for Multi-Protocol Label 2683 Switching (MPLS)," February 2006 2685 [RFC4593] A. Barbir, S. Murphy, Y. Yang, "Generic Threats to Routing 2686 Protocols", October 2006. 2688 [RFC4778] M. Kaeo, "Current Operational Security Practices in 2689 Internet Service Provider Environments", January 2007. 2691 [RFC4808] S. Bellovin, "Key Change Strategies for TCP-MD5", March 2692 2007. 2694 [RFC4864] G. Van de Velde, T. Hain, R. Droms, "Local Network 2695 Protection for IPv6", May 2007. 2697 [RFC4869] L. Law and J. Solinas, "Suite B Cryptographic Suites for 2698 IPsec", April 2007. 2700 [RFC5254] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi- 2701 Segment Pseudowire Emulation Edge-to-Edge (PWE3)", October 2008. 2703 [MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical 2704 Specification", IP/MPLS Forum 19.0.0, April 2008. 2706 MPLS/GMPLS Security framework 2708 [OIF Sec Mag] R. Esposito, R. Graveman, and B. Hazzard, "Security 2709 for Management Interfaces to Network Elements", OIF-SMI-01.0, 2710 September 2003. 2712 [opsec efforts] C. Lonvick and D. Spak, "Security Best Practices 2713 Efforts and Documents", draft-ietf-opsec-efforts-08.txt, June 2008. 2715 [RSVP-key] M. Behringer, F. Le Faucheur, "Applicability of Keying 2716 Methods for RSVP Security", draft-ietf-tsvwg-rsvp-security- 2717 groupkeying-05.txt, June 2009. 2719 14. Author's Addresses 2721 Luyuan Fang 2722 Cisco Systems, Inc. 2723 300 Beaver Brook Road 2724 Boxborough, MA 01719 2725 USA 2727 Email: lufang@cisco.com 2729 Michael Behringer 2730 Cisco Systems, Inc. 2731 Village d'Entreprises Green Side 2732 400, Avenue Roumanille, Batiment T 3 2733 06410 Biot, Sophia Antipolis 2734 FRANCE 2736 Email: mbehring@cisco.com 2738 Ross Callon 2739 Juniper Networks 2740 10 Technology Park Drive 2741 Westford, MA 01886 2742 USA 2744 Email: rcallon@juniper.net 2746 Richard Graveman 2747 RFG Security 2748 15 Park Avenue 2749 Morristown, NJ 07960 2751 Email: rfg@acm.org 2752 MPLS/GMPLS Security framework 2753 Jean-Louis Le Roux 2754 France Telecom 2755 2, avenue Pierre-Marzin 2756 22307 Lannion Cedex 2757 FRANCE 2759 Email: jeanlouis.leroux@francetelecom.com 2761 Raymond Zhang 2762 British Telecom 2763 BT Center 2764 81 Newgate Street 2765 London, EC1A 7AJ 2766 United Kingdom 2768 Email: raymond.zhang@bt.com 2770 Paul Knight 2771 39 N. Hancock St. 2772 Lexington, MA 02420 2774 Email: paul.the.knight@gmail.com 2776 Yaakov (Jonathan) Stein 2777 RAD Data Communications 2778 24 Raoul Wallenberg St., Bldg C 2779 Tel Aviv 69719 2780 ISRAEL 2782 Email: yaakov_s@rad.com 2784 Nabil Bitar 2785 Verizon 2786 40 Sylvan Road 2787 Waltham, MA 02145 2788 Email: nabil.bitar@verizon.com 2790 Monique Morrow 2791 Glatt-com 2792 CH-8301 Glattzentrum 2793 Switzerland 2794 Email: mmorrow@cisco.com 2796 Adrian Farrel 2797 Old Dog Consulting 2798 Email: adrian@olddog.co.uk 2799 MPLS/GMPLS Security framework 2801 15. Acknowledgements 2803 Funding for the RFC Editor function is provided by the IETF 2804 Administrative Support Activity (IASA). 2806 The authors and contributors would also like to acknowledge the 2807 helpful comments and suggestions from Sam Hartman, Dimitri 2808 Papadimitriou, Kannan Varadhan, Stephen Farrell, and Scott Brim in 2809 particular for his comments and discussion through GEN-ART review.