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