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