idnits 2.17.1 draft-ietf-mpls-mpls-and-gmpls-security-framework-02.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 2807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2831. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3945], [RFC3031]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement == 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 (February 2008) is 5912 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3562' is defined on line 2625, but no explicit reference was found in the text == Unused Reference: 'RFC4107' is defined on line 2641, but no explicit reference was found in the text == Unused Reference: 'RFC4808' is defined on line 2659, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) -- Obsolete informational reference (is this intentional?): RFC 2411 (Obsoleted by RFC 6071) -- Obsolete informational reference (is this intentional?): RFC 4869 (Obsoleted by RFC 6379) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-ms-pw-requirements-06 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Fang, Ed. 3 Internet Draft Cisco Systems, Inc. 4 Category: Informational 5 Expires: August 2008 7 February 2008 9 Security Framework for MPLS and GMPLS Networks 10 draft-ietf-mpls-mpls-and-gmpls-security-framework-02.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 50 Fang, et al. Informational 1 51 MPLS/GMPLS Security framework 52 February 2008 54 MPLS and GMPLS networks across different domains or different 55 Service Providers. 57 Table of Contents 59 1. Introduction..................................................3 60 1.1. Structure of this Document.................................4 61 1.2. Authors and Contributors...................................4 62 2. Terminology...................................................5 63 2.1. Terminology................................................5 64 2.2. Acronyms and Abbreviations.................................7 65 3. Security Reference Models.....................................8 66 4. Security Threats.............................................10 67 4.1. Attacks on the Control Plane..............................11 68 4.2. Attacks on the Data Plane.................................15 69 5. Defensive Techniques for MPLS/GMPLS Networks.................16 70 5.1. Authentication............................................17 71 5.2. Cryptographic Techniques..................................19 72 5.3. Access Control Techniques.................................28 73 5.4. Use of Isolated Infrastructure............................33 74 5.5. Use of Aggregated Infrastructure..........................33 75 5.6. Service Provider Quality Control Processes................34 76 5.7. Deployment of Testable MPLS/GMPLS Service.................34 77 6. Monitoring, Detection, and Reporting of Security Attacks.....34 78 7. Service Provider General Security Requirements...............36 79 7.1. Protection within the Core Network........................36 80 7.2. Protection on the User Access Link........................39 81 7.3. General User Requirements for MPLS/GMPLS Providers........41 82 8. Inter-provider Security Requirements.........................42 83 8.1. Control Plane Protection..................................42 84 8.2. Data Plane Protection.....................................46 85 9. Summary of MPLS and GMPLS Security...........................48 86 9.1. MPLS and GMPLS Specific Security Threats..................48 87 9.2. Defense Techniques........................................48 88 9.3. Service Provider MPLS and GMPLS Best Practice Outlines....49 89 10. Security Considerations....................................50 90 11. IANA Considerations........................................51 91 12. Normative References.......................................51 92 13. Informational References...................................52 93 14. Author's Addresses.........................................53 94 15. Acknowledgements...........................................57 96 Fang, et al. Informational 2 97 MPLS/GMPLS Security framework 98 February 2008 100 Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 104 this document are to be interpreted as described in RFC2119 [RFC 105 2119]. 107 1. Introduction 109 Security is an important aspect of all networks, MPLS and GMPLS 110 networks being no exception. 112 MPLS and GMPLS are described in [RFC3031] and [RFC3945]. Various 113 security considerations have been addressed in each of the many 114 RFCs on MPLS and GMPLS technologies, but no single document covers 115 general security considerations. The motivation for creating this 116 document is to provide a comprehensive and consistent security 117 framework for MPLS and GMPLS networks. Each individual document may 118 point to this document for general security considerations in 119 addition to providing security considerations specific to the 120 particular technologies the document is describing. 122 In this document, we first describe the security threats relevant 123 in the context of MPLS and GMPLS and the defensive techniques to 124 combat those threats. We consider security issues deriving both 125 from malicious or incorrect behavior of users and other parties and 126 from negligent or incorrect behavior of providers. An important 127 part of security defense is the detection and reporting of a 128 security attack, which is also addressed in this document. 130 We then discuss possible service provider security requirements in 131 a MPLS or GMPLS environment. Users have expectations for the 132 security characteristics of MPLS or GMPLS networks. These include 133 security requirements for equipment supporting MPLS and GMPLS and 134 operational security requirements for providers. Service providers 135 must protect their network infrastructure and make it secure to the 136 level required to provide services over their MPLS or GMPLS 137 networks. 139 Inter-AS and Inter-provider security are discussed with special 140 emphasis, because the security risk factors are higher with inter- 141 provider connections. Depending on different MPLS or GMPLS 142 techniques used, the degree of risk and the mitigation 143 methodologies vary. This document discusses the security aspects 144 and requirements for certain basic MPLS and GMPLS techniques and 146 Fang, et al. Informational 3 147 MPLS/GMPLS Security framework 148 February 2008 150 inter-connection models. This document does not attempt to cover 151 all current and future MPLS and GMPLS technologies, as it is not 152 within the scope of this document to analyze the security 153 properties of specific technologies. 155 It is important to clarify that, in this document, we limit 156 ourselves to describing the providers' security requirements that 157 pertain to MPLS and GMPLS networks. Readers may refer to the 158 "Security Best Practices Efforts and Documents" [opsec effort] and 159 "Security Mechanisms for the Internet" [RFC3631] for general 160 network operation security considerations. It is not our intention, 161 however, to formulate precise "requirements" for each specific 162 technology in terms of defining the mechanisms and techniques that 163 must be implemented to satisfy such security requirements. 165 1.1. Structure of this Document 167 This document is organized as follows. In Section 2, we define the 168 terminology used. In Section 3, we define the security reference 169 models for security in MPLS/GMPLS networks, which we use in the 170 rest of the document. In Section 4, we describe the security 171 threats specific to MPLS and GMPLS. In Section 5, we review 172 defensive techniques that may be used against those threats. In 173 Section 6, we describe how attacks may be detected and reported. In 174 Section 7, we describe security requirements providers may have to 175 guarantee the security of the network infrastructure for MPLS/GMPLS 176 services. In section 8, we discuss Inter-provider security 177 requirements. Finally, in Section 9, we discuss security 178 considerations for this document. 180 This document has used relevant content from RFC 4111 "Security 181 Framework of Provider Provisioned VPN for Provider-Provisioned 182 Virtual Private Networks (PPVPNs)" [RFC4111], and "MPLS 183 InterCarrier Interconnect Technical Specification" [MFA MPLS ICI] 184 in the Inter-provider security discussion. We acknowledge the 185 authors of these documents for the valuable information and text. 187 1.2. Authors and Contributors 189 Authors: 190 Luyuan Fang, Ed., Cisco Systems, Inc. 191 Michael Behringer, Cisco Systems, Inc. 192 Ross Callon, Juniper Networks 193 J. L. Le Roux, France Telecom 194 Raymond Zhang, British Telecom 195 Paul Knight, Nortel 196 Yaakov Stein, RAD Data Communications 198 Fang, et al. Informational 4 199 MPLS/GMPLS Security framework 200 February 2008 202 Nabil Bitar, Verizon 203 Richard Graveman, RFC Security, LLC 204 Monique Morrow, Cisco Systems, Inc. 205 Adrian Farrel, Old Dog Consulting 206 As a design team member for the MPLS Security Framework, Jerry Ash 207 also made significant contributions to this document. 209 2. Terminology 211 2.1. Terminology 213 This document uses MPLS and GMPLS specific terminology. Definitions 214 and details about MPLS and GMPLS terminology can be found in 215 [RFC3031] and [RFC3945]. The most important definitions are 216 repeated in this section; for other definitions the reader is 217 referred to [RFC3031] and [RFC3945]. 219 Customer Edge (CE) device: A Customer Edge device is a router or a 220 switch in the customer's network interfacing with the Service 221 Provider's network. 223 Forwarding Equivalence Class (FEC): A group of IP packets that are 224 forwarded in the same manner (e.g., over the same path, with the 225 same forwarding treatment). 227 Label: A short, fixed length, physically contiguous identifier used 228 to identify a FEC, usually of local significance. 230 Label Switched Hop: A hop between two MPLS nodes, on which 231 forwarding is done using labels. 233 Label Switched Path (LSP): The path through one or more LSRs at one 234 level of the hierarchy followed by a packets in a particular FEC. 236 Label Switching Router (LSR): A MPLS node capable of forwarding 237 native L3 packets. 239 Layer 2: The protocol layer under layer 3 (which therefore offers 240 the services used by layer 3). Forwarding, when done by the 241 swapping of short fixed length labels, occurs at layer 2 regardless 242 of whether the label being examined is an ATM VPI/VCI, a frame 243 relay DLCI, or a MPLS label. 245 Layer 3: The protocol layer at which IP and its associated routing 246 protocols operate. 248 Fang, et al. Informational 5 249 MPLS/GMPLS Security framework 250 February 2008 252 Link Layer: Synonymous with layer 2. 254 Loop Detection: A method of dealing with loops in which loops are 255 allowed to be set up, and data may be transmitted over the loop, 256 but the loop is later detected. 258 Loop Prevention: A method of dealing with loops in which data is 259 never transmitted over a loop. 261 Label Stack: An ordered set of labels. 263 Merge Point: A node at which label merging is done. 265 MPLS Domain: A contiguous set of nodes that perform MPLS routing 266 and forwarding and are also in one Routing or Administrative 267 Domain. 269 MPLS Edge Node: A MPLS node that connects a MPLS domain with a node 270 outside of the domain, either because it does not run MPLS, or 271 because it is in a different domain. Note that if a LSR has a 272 neighboring host not running MPLS, then that LSR is a MPLS edge 273 node. 275 MPLS Egress Node: A MPLS edge node in its role in handling traffic 276 as it leaves a MPLS domain. 278 MPLS Ingress Node: A MPLS edge node in its role in handling traffic 279 as it enters a MPLS domain. 281 MPLS Label: A label carried in a packet header, which represents 282 the packet's FEC. 284 MPLS Node: A node running MPLS. A MPLS node is aware of MPLS 285 control protocols, runs one or more L3 routing protocols, and is 286 capable of forwarding packets based on labels. A MPLS node may 287 optionally be also capable of forwarding native L3 packets. 289 MultiProtocol Label Switching (MPLS): An IETF working group and the 290 effort associated with the working group. 292 P: Provider Router. A Provider Router is a router in the Service 293 Provider's core network that does not have interfaces directly 294 towards the customer. A P router is used to interconnect the PE 295 routers. 297 Fang, et al. Informational 6 298 MPLS/GMPLS Security framework 299 February 2008 301 PE: Provider Edge device. A Provider Edge device is the equipment 302 in the Service Provider's network that interfaces with the 303 equipment in the customer's network. 305 VPN: Virtual Private Network, which restricts communication between 306 a set of sites, making use of an IP backbone shared by traffic not 307 going to or not coming from those sites ([RFC4110]). 309 2.2. Acronyms and Abbreviations 311 AS Autonomous System 312 ASBR Autonomous System Border Router 313 ATM Asynchronous Transfer Mode 314 BGP Border Gateway Protocol 315 BFD Bidirectional Forwarding Detection 316 CE Customer-Edge device 317 CoS Class of Service 318 CPU Central Processor Unit 319 DNS Domain Name System 320 DoS Denial of Service 321 FEC Forwarding Equivalence Class 322 GMPLS Generalized Multi-Protocol Label Switching 323 GRE Generic Routing Encapsulation 324 ICI InterCarrier Interconnect 325 ICMP Internet Control Message Protocol 326 ICMPv6 ICMP in IP Version 6 327 IGP Interior Gateway Protocol 328 IKE Internet Key Exchange 329 IP Internet Protocol 330 IPsec IP Security 331 IPVPN IP-based VPN 332 LDP Label Distribution Protocol 333 L2 Layer 2 334 L2TP Layer 2 Tunneling Protocol 335 L3 Layer 3 336 LMP Link Management Protocol 337 LSP Label Switched Path 338 LSR Label Switching Router 339 MD5 Message Digest Algorithm 340 MPLS MultiProtocol Label Switching 341 MP-BGP Multi-Protocol BGP 342 NTP Network Time Protocol 343 OAM Operations, Administration, and Management 344 PCE Path Computation Element 345 PE Provider-Edge device 346 PPVPN Provider-Provisioned Virtual Private Network 348 Fang, et al. Informational 7 349 MPLS/GMPLS Security framework 350 February 2008 352 PSN Packet-Switched Network 353 PW Pseudowire 354 QoS Quality of Service 355 RR Route Reflector 356 RSVP Resource Reservation Protocol 357 RSVP-TE Resource Reservation Protocol with Traffic Engineering 358 Extensions 359 SLA Service Level Agreement 360 SNMP Simple Network Management Protocol 361 SP Service Provider 362 SSH Secure Shell 363 SSL Secure Sockets Layer 364 SYN Synchronize packet in TCP 365 TCP Transmission Control Protocol 366 TDM Time Division Multiplexing 367 TE Traffic Engineering 368 TLS Transport Layer Security 369 ToS Type of Service 370 TTL Time-To-Live 371 UDP User Datagram Protocol 372 VC Virtual Circuit 373 VPN Virtual Private Network 374 WG Working Group of IETF 375 WSS Web Services Security 377 3. Security Reference Models 378 This section defines a reference model for security in MPLS/GMPLS 379 networks. 381 A MPLS/GMPLS core network is defined here as the central network 382 infrastructure (P and PE routers). A MPLS/GMPLS core network 383 consists of one or more SP networks. All network elements in the 384 core are under the operational control of one or more MPLS/GMPLS 385 SPs. Even if the MPLS/GMPLS core is provided by several SPs, 386 towards the end users it appears as a single zone of trust. 387 However, when several SPs together provide a MPLS/GMPLS core, each 388 SP still needs to secure itself against the other SPs. 390 A MPLS/GMPLS end user is a company, institution, or residential 391 client of the SP. 393 This document defines each MPLS/GMPLS core in a single domain to be 394 a trusted zone. A primary concern is about security aspects that 395 relate to breaches of security from the "outside" of a trusted zone 396 to the "inside" of this zone. Figure 1 depicts the concept of 397 trusted zones within the MPLS/GMPLS framework. 399 Fang, et al. Informational 8 400 MPLS/GMPLS Security framework 401 February 2008 403 /-------------\ 404 +------------+ / \ +------------+ 405 | MPLS/GMPLS +---/ \--------+ MPLS | 406 | user | MPLS/GMPLS Core | user | 407 | site +---\ /XXX-----+ site | 408 +------------+ \ / XXX +------------+ 409 \-------------/ | | 410 | | 411 | +------\ 412 +--------/ "Internet" 414 MPLS/GMPLS Core with user connections and Internet connection 416 Figure 1: The MPLS/GMPLS trusted zone model. 418 The trusted zone is the MPLS/GMPLS core in a single AS within a 419 single Service Provider. 421 The boundaries of a trust domain should be carefully defined when 422 analyzing the security property of each individual network, e.g., 423 the boundaries can be at the link termination, remote peers, areas, 424 or quite commonly, ASes. 426 In principle, the trusted zones should be separate; however, 427 typically MPLS core networks also offer Internet access, in which 428 case a transit point (marked with "XXX" in Figure 1) is defined. In 429 the case of MPLS/GMPLS inter-provider connections, the trusted zone 430 of each provider ends at the respective ASBRs (ASBR1 and ASBR2 for 431 Provider A, ASBR3 and ASBR4 for Provider B). 433 A key requirement of MPLS and GMPLS networks is that the security 434 of the trusted zone not be compromised by interconnecting the 435 MPLS/GMPLS core infrastructure with another provider's core 436 (MPLS/GMPLS or non-MPLS/GMPLS), the Internet, or end users. 438 In addition, neighbors may be trusted or untrusted. Neighbors may 439 be authorized or unauthorized. Even though a neighbor may be 440 authorized for communication, it may not be trusted. For example, 441 when connecting with another provider's ASBRs to set up inter-AS 442 LSPs, the other provider is considered an untrusted but authorized 443 neighbor. 445 Fang, et al. Informational 9 446 MPLS/GMPLS Security framework 447 February 2008 449 +---------------+ +----------------+ 450 | | | | 451 | MPLS/GMPLS ASBR1----ASBR3 MPLS/GMPLS | 452 CE1--PE1 Network | | Network PE2--CE2 453 | Provider A ASBR2----ASBR4 Provider B | 454 | | | | 455 +---------------+ +----------------+ 457 For Provider A: 458 Trusted Zone: Provider A MPSL/GMPLS network 459 Trusted neighbors: PE1, ASBR1, ASBR2 460 Authorized but untrusted neighbor: provider B 461 Unauthorized neighbors: CE1, CE2 463 Figure 2. MPLS/GMPLS trusted zone and authorized neighbor. 465 All aspects of network security independent of whether a network is 466 a MPLS/GMPLS network are out of scope. For example, attacks from 467 the Internet to a user's web-server connected through the 468 MPLS/GMPLS network are not considered here, unless the way the 469 MPLS/GMPLS network is provisioned could make a difference to the 470 security of this user's server. 472 4. Security Threats 474 This section discusses the various network security threats that 475 may endanger MPLS/GMPLS networks. The discussion is limited to 476 those threats that are unique to MPLS/GMPLS networks or that affect 477 MPLS/GMPLS network in unique ways. 479 A successful attack on a particular MPLS/GMPLS network or on a SP's 480 MPLS/GMPLS infrastructure may cause one or more of the following 481 ill effects: 483 - Observation, modification, or deletion of a provider's or user's 484 data. 485 - Replay of a provider's or user's data. 486 - Injection of inauthentic data into a provider's or user's 487 traffic stream. 488 - Traffic pattern analysis on a provider's or user's traffic. 490 Fang, et al. Informational 10 491 MPLS/GMPLS Security framework 492 February 2008 494 - Disruption of a provider's or user's connectivity. 495 - Degradation of a provider's service quality. 497 It is useful to consider that threats, whether malicious or 498 accidental, may come from different categories of sources. For 499 example they may come from: 501 - Other users whose services are provided by the same MPLS/GMPLS 502 core. 503 - The MPLS/GMPLS SP or persons working for it. 504 - Other persons who obtain physical access to a MPLS/GMPLS SP's 505 site. 506 - Other persons who use social engineering methods to influence 507 the behavior of a SP's personnel. 508 - Users of the MPLS/GMPLS network itself, e.g., intra-VPN threats. 509 (Such threats are beyond the scope of this document.) 510 - Others, e.g., attackers from the Internet at large. 511 - Other SPs in the case of MPLS/GMPLS Inter- 512 provider connection. The core of the other provider may or may 513 not be using MPLS/GMPLS. 514 - Those who create, deliver, install, and maintain software for 515 network equipment. 517 Given that security is generally a tradeoff between expense and 518 risk, it is also useful to consider the likelihood of different 519 attacks occurring. There is at least a perceived difference in the 520 likelihood of most types of attacks being successfully mounted in 521 different environments, such as: 523 - A MPLS/GMPLS core inter-connecting with another provider's core 524 - A MPLS/GMPLS configuration transiting the public Internet 526 Most types of attacks become easier to mount and hence more likely 527 as the shared infrastructure via which service is provided expands 528 from a single SP to multiple cooperating SPs to the global 529 Internet. Attacks that may not be of sufficient likeliness to 530 warrant concern in a closely controlled environment often merit 531 defensive measures in broader, more open environments. In closed 532 communities, it is often practical to deal with misbehavior after 533 the fact: an employee can be disciplined, for example. 535 The following sections discuss specific types of exploits that 536 threaten MPLS/GMPLS networks. 538 4.1. Attacks on the Control Plane 540 Fang, et al. Informational 11 541 MPLS/GMPLS Security framework 542 February 2008 544 This category encompasses attacks on the control structures 545 operated by the SP with MPLS/GMPLS cores. 547 4.1.1. LSP creation by an unauthorized element 549 The unauthorized element can be a local CE or a router in another 550 domain. An unauthorized element can generate MPLS signaling 551 messages. At the least, this can result in extra control plane and 552 forwarding state, and if successful, network bandwidth could be 553 reserved unnecessarily. This may also result in theft of service 554 and loss of revenue. 556 4.1.2. LSP message interception 558 This threat might be accomplished by monitoring network traffic, 559 for example, after a physical intrusion. Without physical 560 intrusion, it could be accomplished with an unauthorized software 561 modification. Also many technologies such as terrestrial microwave, 562 satellite, or free-space optical could be intercepted without 563 physical intrusion. If successful, it could provide information 564 leading to label spoofing attacks. It also raises confidentiality 565 issues. 567 4.1.3. Attacks against RSVP-TE 569 RSVP-TE, described in [RFC3209], is the control protocol used to 570 set up GMPLS and traffic engineered MPLS tunnels. 572 There are two major types of Denial of Service (DoS) attacks 573 against a MPLS domain based on RSVP-TE. The attacker may set up 574 numerous unauthorized LSPs or may send a storm of RSVP messages. 575 It has been demonstrated that unprotected routers running RSVP can 576 be effectively disabled by both types of DoS attacks. 578 These attacks may even be combined, by using the unauthorized LSPs 579 to transport additional RSVP (or other) messages across routers 580 where they might otherwise be filtered out. RSVP attacks can be 581 launched against adjacent routers at the border with the attacker, 582 or against non-adjacent routers within the MPLS domain, if there is 583 no effective mechanism to filter them out. 585 4.1.4. Attacks against LDP 587 LDP, described in [RFC3036], is the control protocol used to set up 588 MPLS tunnels without TE. 590 There are two significant types of attack against LDP. An 591 unauthorized network element can establish a LDP session by sending 593 Fang, et al. Informational 12 594 MPLS/GMPLS Security framework 595 February 2008 597 LDP Hello and LDP Init messages, leading to the potential setup of 598 a LSP, as well as accompanying LDP state table consumption. Even 599 without successfully establishing LSPs, an attacker can launch a 600 DoS attack in the form of a storm of LDP Hello messages or LDP TCP 601 Syn messages, leading to high CPU utilization on the target router. 603 4.1.5. Denial of Service Attacks on the Network 604 Infrastructure 606 DoS attacks could be accomplished through a MPLS signaling storm, 607 resulting in high CPU utilization and possibly leading to control 608 plane resource starvation. 610 Control plane DoS attacks can be mounted specifically against the 611 mechanisms the SP uses to provide various services, or against the 612 general infrastructure of the service provider, e.g., P routers or 613 shared aspects of PE routers. (An attack against the general 614 infrastructure is within the scope of this document only if the 615 attack can occur in relation with the MPLS/GMPLS infrastructure; 616 otherwise is not a MPLS/GMPLS-specific issue.) 618 The attacks described in the following sections may each have 619 denial of service as one of their effects. Other DoS attacks are 620 also possible. 622 4.1.6. Attacks on the SP's MPLS/GMPLS Equipment via 623 Management Interfaces 625 This includes unauthorized access to a SP's infrastructure 626 equipment, for example to reconfigure the equipment or to extract 627 information (statistics, topology, etc.) pertaining to the network. 629 4.1.7. Social Engineering Attacks on the SP's 630 Infrastructure 632 Attacks in which the service provider network is reconfigured or 633 damaged, or in which confidential information is improperly 634 disclosed, may be mounted by manipulation of a SP's personnel. 635 These types of attacks are MPLS/GMPLS-specific if they affect 636 MPLS/GMPLS-serving mechanisms. 638 4.1.8. Cross-Connection of Traffic between Users 640 This refers to the event in which expected isolation between 641 separate users (who may be VPN users) is breached. This includes 642 cases such as: 644 Fang, et al. Informational 13 645 MPLS/GMPLS Security framework 646 February 2008 648 - A site being connected into the "wrong" VPN 649 - Traffic being replicated and sent to an unauthorized user 650 - Two or more VPNs being improperly merged together 651 - A point-to-point VPN connecting the wrong two points 652 - Any packet or frame being improperly delivered outside the VPN 653 to which it belongs 655 Mis-connection or cross-connection of VPNs may be caused by service 656 provider or equipment vendor error, or by the malicious action of 657 an attacker. The breach may be physical (e.g., PE-CE links mis- 658 connected) or logical (e.g., improper device configuration). 660 Anecdotal evidence suggests that the cross-connection threat is one 661 of the largest security concerns of users (or would-be users). 663 4.1.9. Attacks against Routing Protocols 665 This encompasses attacks against underlying routing protocols that 666 are run by the SP and that directly support the MPLS/GMPLS core. 667 (Attacks against the use of routing protocols for the distribution 668 of backbone routes are beyond the scope of this document.) 669 Specific attacks against popular routing protocols have been widely 670 studied and described in [RFC4593]. 672 4.1.10. Other Attacks on Control Traffic 674 Besides routing and management protocols (covered separately in the 675 previous sections), a number of other control protocols may be 676 directly involved in delivering services by the MPLS/GMPLS core. 677 These include but may not be limited to: 679 - MPLS signaling (LDP, RSVP-TE) discussed above in subsections 680 4.1.4 and 4.1.3 681 - PCE signaling 682 - IPsec signaling (IKE and IKEv2) 683 - ICMP and ICMPv6 684 - L2TP 685 - BGP-based membership discovery 686 - Database-based membership discovery (e.g., RADIUS) 687 - Other protocols that may be important to the control 688 infrastructure, e.g., DNS, LMP, NTP, SNMP, and GRE. 690 Attacks might subvert or disrupt the activities of these protocols, 691 for example via impersonation or DoS. 693 Fang, et al. Informational 14 694 MPLS/GMPLS Security framework 695 February 2008 697 4.2. Attacks on the Data Plane 699 This category encompasses attacks on the provider's or end user's 700 data. Note that from the MPLS/GMPLS network end user's point of 701 view, some of this might be control plane traffic, e.g. routing 702 protocols running from user site A to user site B via a L2 or L3 703 connection, which may be some type of VPN. 705 4.2.1. Unauthorized Observation of Data Traffic 707 This refers to "sniffing" provider or end user packets and 708 examining their contents. This can result in exposure of 709 confidential information. It can also be a first step in other 710 attacks (described below) in which the recorded data is modified 711 and re-inserted, or simply replayed later. 713 4.2.2. Modification of Data Traffic 715 This refers to modifying the contents of packets as they traverse 716 the MPLS/GMPLS core. 718 4.2.3. Insertion of Inauthentic Data Traffic: Spoofing 719 and Replay 721 Spoofing refers to sending a user or inserting into a data stream 722 packets that do not belong, with the objective of having them 723 accepted by the recipient as legitimate. Also included in this 724 category is the insertion of copies of once-legitimate packets that 725 have been recorded and replayed. 727 4.2.4. Unauthorized Deletion of Data Traffic 729 This refers to causing packets to be discarded as they traverse the 730 MPLS/GMPLS networks. This is a specific type of Denial of Service 731 attack. 733 4.2.5. Unauthorized Traffic Pattern Analysis 735 This refers to "sniffing" provider or user packets and examining 736 aspects or meta-aspects of them that may be visible even when the 737 packets themselves are encrypted. An attacker might gain useful 738 information based on the amount and timing of traffic, packet 739 sizes, source and destination addresses, etc. For most users, this 740 type of attack is generally considered to be significantly less of 741 a concern than the other types discussed in this section. 743 Fang, et al. Informational 15 744 MPLS/GMPLS Security framework 745 February 2008 747 4.2.6. Denial of Service Attacks 749 Denial of Service (DoS) attacks are those in which an attacker 750 attempts to disrupt or prevent the use of a service by its 751 legitimate users. Taking network devices out of service, modifying 752 their configuration, or overwhelming them with requests for service 753 are several of the possible avenues for DoS attack. 755 Overwhelming the network with requests for service, otherwise known 756 as a "resource exhaustion" DoS attack, may target any resource in 757 the network, e.g., link bandwidth, packet forwarding capacity, 758 session capacity for various protocols, CPU power, table size, 759 storage overflows, and so on. 761 DoS attacks of the resource exhaustion type can be mounted against 762 the data plane of a particular provider or end user by attempting 763 to insert (spoofing) an overwhelming quantity of inauthentic data 764 into the provider or end user network from the outside of the 765 trusted zone. Potential results might be to exhaust the bandwidth 766 available to that provider or end user or to overwhelm the 767 cryptographic authentication mechanisms of the provider or end 768 user. 770 Data plane resource exhaustion attacks can also be mounted by 771 overwhelming the service provider's general (MPLS/GMPLS- 772 independent) infrastructure with traffic. These attacks on the 773 general infrastructure are not usually a MPLS/GMPLS-specific issue, 774 unless the attack is mounted by another MPLS/GMPLS network user 775 from a privileged position. (E.g., a MPLS/GMPLS network user might 776 be able to monopolize network data plane resources and thus disrupt 777 other users.) 779 Many DoS attacks use amplification, whereby the attacker co-opts 780 otherwise innocent parties to increase the effect of the attack. 781 The attacker may, for example, send packets to a broadcast or 782 multicast address with the spoofed source address of the victim, 783 and all of the recipients may then respond to the victim. 785 5. Defensive Techniques for MPLS/GMPLS Networks 787 The defensive techniques discussed in this document are intended to 788 describe methods by which some security threats can be addressed. 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 795 Fang, et al. Informational 16 796 MPLS/GMPLS Security framework 797 February 2008 799 operational environment determines the security requirements. 800 Therefore, protocol designers need to provide a full set of 801 security services, which can be used where appropriate. 803 The techniques discussed here include encryption, authentication, 804 filtering, firewalls, access control, isolation, aggregation, and 805 other techniques. 807 Often, security is achieved by careful protocol design, rather than 808 by adding a security method. For example, one method of mitigating 809 DoS attacks is to make sure that innocent parties cannot be used to 810 amplify the attack. Security works better when it is "designed in" 811 rather than "added on." 813 Nothing is ever 100% secure. Defense therefore involves protecting 814 against those attacks that are most likely to occur or that have 815 the most direct consequences if successful. For those attacks that 816 are protected against, absolute protection is seldom achievable; 817 more often it is sufficient just to make the cost of a successful 818 attack greater than what the adversary will be willing or able to 819 expend. 821 Successfully defending against an attack does not necessarily mean 822 the attack must be prevented from happening or from reaching its 823 target. In many cases the network can instead be designed to 824 withstand the attack. For example, the introduction of inauthentic 825 packets could be defended against by preventing their introduction 826 in the first place, or by making it possible to identify and 827 eliminate them before delivery to the MPLS/GMPLS user's system. 828 The latter is frequently a much easier task. 830 5.1. Authentication 832 To prevent security issues arising from some Denial-of-Service 833 attacks or from malicious or accidental misconfiguration, it is 834 critical that devices in the MPLS/GMPLS should only accept 835 connections or control messages from valid sources. Authentication 836 refers to methods to ensure that message sources are properly 837 identified by the MPLS/GMPLS devices with which they communicate. 838 This section focuses on identifying the scenarios in which sender 839 authentication is required and recommends authentication mechanisms 840 for these scenarios. 842 Cryptographic techniques (authentication, integrity, and 843 encryption) do not protect against some types of denial of service 844 attacks, specifically resource exhaustion attacks based on CPU or 845 bandwidth exhaustion. In fact, the processing required to decrypt 847 Fang, et al. Informational 17 848 MPLS/GMPLS Security framework 849 February 2008 851 or check authentication may, in the case of software-based 852 cryptographic processing, in some cases increase the effect of 853 these resource exhaustion attacks. With a hardware cryptographic 854 accelerator, attack packets can be dropped at line speed without a 855 cost of software cycles. Cryptographic techniques may, however, be 856 useful against resource exhaustion attacks based on exhaustion of 857 state information (e.g., TCP SYN attacks). 859 The MPLS user plane, as presently defined, is not amenable to 860 source authentication as there are no source identifiers in the 861 MPLS packet to authenticate. The MPLS label is only locally 862 meaningful, and it identifies a downstream semantic rather than an 863 upstream source. 865 When the MPLS payload carries identifiers that may be authenticated 866 (e.g., IP packets), authentication may be carried out at the client 867 level, but this does not help the MPLS SP, as these client 868 identifiers belong to an external, untrusted network. 870 5.1.1. Management System Authentication 872 Management system authentication includes the authentication of a 873 PE to a centrally-managed network management or directory server 874 when directory-based "auto-discovery" is used. It also includes 875 authentication of a CE to the configuration server, when a 876 configuration server system is used. 878 5.1.2. Peer-to-Peer Authentication 880 Peer-to-peer authentication includes peer authentication for 881 network control protocols (e.g., LDP, BGP, etc.), and other peer 882 authentication (i.e., authentication of one IPsec security gateway 883 by another). 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 893 Fang, et al. Informational 18 894 MPLS/GMPLS Security framework 895 February 2008 897 hierarchical Certification Authority system to provide digital 898 certificates. 900 This section describes or provides references to the specific 901 cryptographic approaches for authenticating identity. These 902 approaches provide secure mechanisms for most of the authentication 903 scenarios required in securing a MPLS/GMPLS network. 905 5.2. Cryptographic Techniques 907 MPLS/GMPLS defenses against a wide variety of attacks can be 908 enhanced by the proper application of cryptographic techniques. 909 These are the same cryptographic techniques that are applicable to 910 general network communications. In general, these techniques can 911 provide confidentiality (encryption) of communication between 912 devices, can authenticate the identities of the devices, and can 913 ensure that it will be detected if the data being communicated is 914 changed during transit. 916 Several aspects of authentication are addressed in some detail in a 917 separate "Authentication" section. 919 Cryptographic methods add complexity to a service and thus, for a 920 few reasons, may not be the most practical solution in every case. 921 Cryptography adds an additional computational burden to devices, 922 which may reduce the number of user connections that can be handled 923 on a device or otherwise reduce the capacity of the device, 924 potentially driving up the provider's costs. Typically, 925 configuring encryption services on devices adds to the complexity 926 of their configuration and adds labor cost. Some key management 927 system is usually needed. Packet sizes are typically increased when 928 the packets are encrypted or have integrity checks or replay 929 counters added, increasing the network traffic load and adding to 930 the likelihood of packet fragmentation with its increased overhead. 931 (This packet length increase can often be mitigated to some extent 932 by data compression techniques, but at the expense of additional 933 computational burden.) Finally, some providers may employ enough 934 other defensive techniques, such as physical isolation or filtering 935 and firewall techniques, that they may not perceive additional 936 benefit from encryption techniques. 938 Users may wish to provide confidentiality end to end. Generally, 939 encrypting for confidentiality must be accompanied with 940 cryptographic integrity checks to prevent certain active attacks 941 against the encrypted communications. On today's processors, 942 encryption and integrity checks run extremely quickly, but key 944 Fang, et al. Informational 19 945 MPLS/GMPLS Security framework 946 February 2008 948 management may be more demanding in terms of both computational and 949 administrative overhead. 951 The trust model among the MPLS/GMPLS user, the MPLS/GMPLS provider, 952 and other parts of the network is a major element in determining 953 the applicability of cryptographic protection for any specific 954 MPLS/GMPLS implementation. In particular, it determines where 955 cryptographic protection should be applied: 956 - If the data path between the user's site and the 957 provider's PE is not trusted, then it may be used on the 958 PE-CE link. 959 - If some part of the backbone network is not trusted, 960 particularly in implementations where traffic may travel 961 across the Internet or multiple providers' networks, then 962 the PE-PE traffic may be cryptographically protected. One 963 also should consider cases where L1 technology may be 964 vulnerable to eavesdropping. 965 - If the user does not trust any zone outside of its 966 premises, it may require end-to-end or CE-CE cryptographic 967 protection. This fits within the scope of this MPLS/GMPLS 968 security framework when the CE is provisioned by the 969 MPLS/GMPLS provider. 970 - If the user requires remote access to its site from a 971 system at a location that is not a customer location (for 972 example, access by a traveler) there may be a requirement 973 for cryptographically protecting the traffic between that 974 system and an access point or a customer's site. If the 975 MPLS/GMPLS provider supplies the access point, then the 976 customer must cooperate with the provider to handle the 977 access control services for the remote users. These access 978 control services are usually protected cryptographically, 979 as well. 981 Access control usually starts with authentication of the 982 entity. If cryptographic services are part of the scenario, 983 then it is important to bind the authentication to the key 984 management. Otherwise the protocol is vulnerable to being 985 hijacked between the authentication and key management. 987 Although CE-CE cryptographic protection can provide integrity and 988 confidentiality against third parties, if the MPLS/GMPLS provider 989 has complete management control over the CE (encryption) devices, 990 then it may be possible for the provider to gain access to the 991 user's traffic or internal network. Encryption devices could 992 potentially be reconfigured to use null encryption, bypass 993 cryptographic processing altogether, reveal internal configuration, 994 or provide some means of sniffing or diverting unencrypted traffic. 995 Thus an implementation using CE-CE encryption needs to consider the 997 Fang, et al. Informational 20 998 MPLS/GMPLS Security framework 999 February 2008 1001 trust relationship between the MPLS/GMPLS user and provider. 1002 MPLS/GMPLS users and providers may wish to negotiate a service 1003 level agreement (SLA) for CE-CE encryption that provides an 1004 acceptable demarcation of responsibilities for management of 1005 cryptographic protection on the CE devices. The demarcation may 1006 also be affected by the capabilities of the CE devices. For 1007 example, the CE might support some partitioning of management, a 1008 configuration lock-down ability, or shared capability to verify the 1009 configuration. In general, the MPLS/GMPLS user needs to have a 1010 fairly high level of trust that the MPLS/GMPLS provider will 1011 properly provision and manage the CE devices, if the managed CE-CE 1012 model is used. 1014 5.2.1. IPsec in MPLS/GMPLS 1016 IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC2411] is the 1017 security protocol of choice for encryption at the IP layer (Layer 1018 3). IPsec provides robust security for IP traffic between pairs of 1019 devices. Non-IP traffic such as IS-IS routing must be converted to 1020 IP (e.g., by encapsulation) in order to use IPsec. 1022 In the MPLS/GMPLS model, IPsec can be employed to protect IP 1023 traffic between PEs, between a PE and a CE, or from CE to CE. CE- 1024 to-CE IPsec may be employed in either a provider-provisioned or a 1025 user-provisioned model. Likewise, IPsec protection of data 1026 performed within the user's site is outside the scope of this 1027 document, because it is simply handled as user data by the 1028 MPLS/GMPLS core. However, if the SP performs compression, pre- 1029 encryption will have a major effect on that operation. 1031 IPsec does not itself specify an encryption algorithm. It can use 1032 a variety of integrity or confidentiality algorithms (or even 1033 combined integrity and confidentiality algorithms), with various 1034 key lengths, such as AES encryption or AES message integrity 1035 checks. There are trade-offs between key length, computational 1036 burden, and the level of security of the encryption. A full 1037 discussion of these trade-offs is beyond the scope of this 1038 document. In practice, any currently recommended IPsec protection 1039 offers enough security to reduce the likelihood of its being 1040 directly targeted by an attacker substantially; other weaker links 1041 in the chain of security are likely to be attacked first. 1042 MPLS/GMPLS users may wish to use a Service Level Agreement (SLA) 1043 specifying the SP's responsibility for ensuring data integrity and 1044 confidentiality, rather than analyzing the specific encryption 1045 techniques used in the MPLS/GMPLS service. 1047 Fang, et al. Informational 21 1048 MPLS/GMPLS Security framework 1049 February 2008 1051 Encryption algorithms generally come with two parameters: mode such 1052 as Cipher Block Chaining and key length such as AES-192. (This 1053 should not be confused with two other senses in which the word 1054 "mode" is used: IPsec itself can be used in Tunnel Mode or 1055 Transport Mode, and IKE [version 1] uses Main Mode, Aggressive 1056 Mode, or Quick Mode). It should be stressed that IPsec encryption 1057 without an integrity check is a state of sin. 1059 For many of the MPLS/GMPLS provider's network control messages and 1060 some user requirements, cryptographic authentication of messages 1061 without encryption of the contents of the message may provide 1062 appropriate security. Using IPsec, authentication of messages is 1063 provided by the Authentication Header (AH) or through the use of 1064 the Encapsulating Security Protocol (ESP) with NULL encryption. 1065 Where control messages require integrity but do not use IPsec, 1066 other cryptographic authentication methods are often available. 1067 Message authentication methods currently considered to be secure 1068 are based on hashed message authentication codes (HMAC) [RFC2104] 1069 implemented with a secure hash algorithm such as Secure Hash 1070 Algorithm 1 (SHA-1) [RFC3174]. No attacks against HMAC SHA-1 are 1071 likely to play out in the near future, but it is possible that 1072 people will soon find SHA-1 collisions. Thus, it is important that 1073 mechanisms be designed to be flexible about the choice of hash 1074 functions and message integrity checks. Also, many of these 1075 mechanisms do not include a convenient way to manage and update 1076 keys. 1078 A mechanism to provide a combination of confidentiality, data 1079 origin authentication, and connectionless integrity is the use of 1080 AES in CCM (Counter with CBC-MAC) mode (RFC 4309) [RFC4309], with 1081 an explicit initialization vector (IV), as the IPsec ESP. Recently, 1082 GCM is rapidly replacing CCM as the preferred method: [RFC4103]. 1084 MPLS and GMPLS, which provide differentiated services based on 1085 traffic type, may encounter some conflicts with IPsec encryption of 1086 traffic. Because encryption hides the content of the packets, it 1087 may not be possible to differentiate the encrypted traffic in the 1088 same manner as unencrypted traffic. Although DiffServ markings are 1089 copied to the IPsec header and can provide some differentiation, 1090 not all traffic types can be accommodated by this mechanism. Using 1091 IPsec without IKE or IKEv2 (the better choice) is not advisable. 1092 IKEv2 provides IPsec Security Association creation and management, 1093 entity authentication, key agreement, and key update. It works with 1094 a variety of authentication methods including pre-shared keys, 1095 public key certificates, and EAP. If DoS attacks against IKEv2 are 1096 considered an important threat to mitigate, the cookie-based anti- 1097 spoofing feature of IKEv2 should be used. IKEv2 has its own set of 1099 Fang, et al. Informational 22 1100 MPLS/GMPLS Security framework 1101 February 2008 1103 cryptographic methods, but any of the default suites specified in 1104 [RFC4308] or [RFC4869] provides more than adequate security. 1106 5.2.2. Encryption for device configuration and management 1108 For configuration and management of MPLS/GMPLS devices, encryption 1109 and authentication of the management connection at a level 1110 comparable to that provided by IPsec is desirable. 1112 Several methods of transporting MPLS/GMPLS device management 1113 traffic offer security and confidentiality. 1114 - Secure Shell (SSH) offers protection for TELNET [STD-8] or 1115 terminal-like connections to allow device configuration. 1116 - SNMPv3 [STD62] provides encrypted and authenticated protection 1117 for SNMP-managed devices. 1118 - Transport Layer Security (TLS) [RFC4346] and the closely-related 1119 Secure Sockets Layer (SSL) are widely used for securing HTTP- 1120 based communication, and thus can provide support for most XML- 1121 and SOAP-based device management approaches. 1122 - Since 2004, there has been extensive work proceeding in several 1123 organizations (OASIS, W3C, WS-I, and others) on securing device 1124 management traffic within a "Web Services" framework, using a 1125 wide variety of security models, and providing support for 1126 multiple security token formats, multiple trust domains, 1127 multiple signature formats, and multiple encryption 1128 technologies. 1129 - IPsec provides the services with integrity and confidentiality 1130 at the network layer. With regards to device management, its 1131 current use is primarily focused on in-band management of user- 1132 managed IPsec gateway devices. 1133 - There are recent work in ISMS WG (Integrated Security Model for 1134 SNMP Working Group) to define how to use SSH to secure SNMP, due 1135 to the limited deployment of SNMPv3; and the possibility of 1136 using Kerberos, particularly for interfaces like TELNET, where 1137 client code exists. 1139 5.2.3. Security Considerations for MPLS Pseudowires 1141 In addition to IP traffic, MPLS networks may be used to transport 1142 other services such as Ethernet, ATM, Frame Relay, and TDM. This is 1143 done by setting up pseudowires (PWs) that tunnel the native service 1144 through the MPLS core by encapsulating at the edges. The PWE 1145 architecture is defined in [RFC3985]. 1147 Fang, et al. Informational 23 1148 MPLS/GMPLS Security framework 1149 February 2008 1151 PW tunnels may be set up using the PWE control protocol based on 1152 LDP [RFC4447], and thus security considerations for LDP will most 1153 likely be applicable to the PWE3 control protocol as well. 1155 PW user packets contain at least one MPLS label (the PW label) and 1156 may contain one or more MPLS tunnel labels. After the label stack 1157 there is a four-byte control word (which is optional for some PW 1158 types), followed by the native service payload. It must be 1159 stressed that encapsulation of MPLS PW packets in IP for the 1160 purpose of enabling use of IPsec mechanisms is not a valid option. 1162 The PW client traffic may be secured by use of mechanisms beyond 1163 the scope of this document. 1165 5.2.4. End-to-End versus Hop-by-Hop Protection Tradeoffs 1166 in MPLS/GMPLS 1168 In MPLS/GMPLS, cryptographic protection could potentially be 1169 applied to the MPLS/GMPLS traffic at several different places. 1170 This section discusses some of the tradeoffs in implementing 1171 encryption in several different connection topologies among 1172 different devices within a MPLS/GMPLS network. 1174 Cryptographic protection typically involves a pair of devices that 1175 protect the traffic passing between them. The devices may be 1176 directly connected (over a single "hop"), or intervening devices 1177 may transport the protected traffic between the pair of devices. 1178 The extreme cases involve using protection between every adjacent 1179 pair of devices along a given path (hop-by-hop), or using 1180 protection only between the end devices along a given path (end-to- 1181 end). To keep this discussion within the scope of this document, 1182 the latter ("end-to-end") case considered here is CE-to-CE rather 1183 than fully end-to-end. 1185 Figure 3 depicts a simplified topology showing the Customer Edge 1186 (CE) devices, the Provider Edge (PE) devices, and a variable number 1187 (three are shown) of Provider core (P) devices, which might be 1188 present along the path between two sites in a single VPN operated 1189 by a single service provider (SP). 1191 Site_1---CE---PE---P---P---P---PE---CE---Site_2 1193 Figure 3: Simplified topology traversing through MPLS/GMPLS core. 1195 Fang, et al. Informational 24 1196 MPLS/GMPLS Security framework 1197 February 2008 1199 Within this simplified topology, and assuming that the P devices 1200 are not involved with cryptographic protection, four basic, 1201 feasible configurations exist for protecting connections among the 1202 devices: 1204 1) Site-to-site (CE-to-CE) - Apply confidentiality or integrity 1205 services between the two CE devices, so that traffic will be 1206 protected throughout the SP's network. 1208 2) Provider edge-to-edge (PE-to-PE) - Apply confidentiality or 1209 integrity services between the two PE devices. Unprotected traffic 1210 is received at one PE from the customer's CE, then it is protected 1211 for transmission through the SP's network to the other PE, and 1212 finally it is decrypted or checked for integrity and sent to the 1213 other CE. 1215 3) Access link (CE-to-PE) - Apply confidentiality or integrity 1216 services between the CE and PE on each side or on only one side. 1218 4) Configurations 2 and 3 above can also be combined, with 1219 confidentiality or integrity running from CE to PE, then PE to PE, 1220 and then PE to CE. 1222 Among the four feasible configurations, key tradeoffs in 1223 considering encryption include: 1225 - Vulnerability to link eavesdropping or tampering - assuming an 1226 attacker can 1227 observe or modify data in transit on the links, would it be 1228 protected by encryption? 1230 - Vulnerability to device compromise - assuming an attacker can get 1231 access to a device (or freely alter its configuration), would the 1232 data be protected? 1234 - Complexity of device configuration and management - given the 1235 number of sites per VPN customer as Nce and the number of PEs 1236 participating in a given VPN as Npe, how many device configurations 1237 need to be created or maintained, and how do those configurations 1238 scale? 1240 - Processing load on devices - how many cryptographic operations 1241 must be performed given N packets? - This raises considerations of 1242 device capacity and perhaps end-to-end delay. 1244 Fang, et al. Informational 25 1245 MPLS/GMPLS Security framework 1246 February 2008 1248 - Ability of the SP to provide enhanced services (QoS, firewall, 1249 intrusion detection, etc.) - Can the SP inspect the data to provide 1250 these services? 1252 These tradeoffs are discussed for each configuration, below: 1254 1) Site-to-site (CE-to-CE) 1256 Link eavesdropping or tampering - protected on all links 1257 Device compromise - vulnerable to CE compromise 1258 Complexity - single administration, responsible for one device per 1259 site (Nce devices), but overall configuration per VPN scales as 1260 Nce**2. 1261 Though the complexity may be reduced: 1) In practice, as Nce 1262 grows, the number of VPNs falls off from being a full clique; 1263 2) If the CEs run an automated key management protocol, then 1264 they should be able to set up and tear down secured VPNs 1265 without any intervention 1266 Processing load - on each of two CEs, each packet is either 1267 cryptographically processed (2P), though the protection may be 1268 "integrity check only" or "integrity check plus encryption." 1269 Enhanced services - severely limited; typically only Diffserv 1270 markings are visible to the SP, allowing some QoS services 1272 2) Provider edge-to-edge (PE-to-PE) 1274 Link eavesdropping or tampering - vulnerable on CE-PE links; 1275 protected on SP's network links 1276 Device compromise - vulnerable to CE or PE compromise 1277 Complexity - single administration, Npe devices to configure. 1278 (Multiple sites may share a PE device so Npe is typically much 1279 less than Nce.) Scalability of the overall configuration 1280 depends on the PPVPN type: If the cryptographic protection is 1281 separate per VPN context, it scales as Npe**2 per customer VPN. 1282 If it is per-PE, it scales as Npe**2 for all customer VPNs 1283 combined. 1284 Processing load - on each of two PEs, each packet is 1285 cryptographically processed (2P). Note that this 2P is a 1286 different 2P from case (1), because only PEs are in 1287 consideration here. 1288 Enhanced services - full; SP can apply any enhancements based on 1289 detailed view of traffic 1291 3) Access link (CE-to-PE) 1293 Link eavesdropping or tampering - protected on CE-PE link; 1294 vulnerable on SP's network links 1295 Device compromise - vulnerable to CE or PE compromise 1297 Fang, et al. Informational 26 1298 MPLS/GMPLS Security framework 1299 February 2008 1301 Complexity - two administrations (customer and SP) with device 1302 configuration on each side (Nce + Npe devices to configure) but 1303 because there is no mesh the overall configuration scales as 1304 Nce. 1305 Processing load - on each of two CEs, each packet is 1306 cryptographically processed, plus on each of two PEs, each 1307 packet is cryptographically processed (4P) 1308 Enhanced services - full; SP can apply any enhancements based on 1309 detailed view of traffic 1311 4) Combined Access link and PE-to-PE (essentially hop-by-hop) 1313 Link eavesdropping or tampering - protected on all links 1314 Device compromise - vulnerable to CE or PE compromise 1315 Complexity - two administrations (customer and SP) with device 1316 configuration on each side (Nce + Npe devices to configure). 1317 Scalability of the overall configuration depends on the PPVPN 1318 type: If the cryptographic processing is separate per VPN 1319 context, it scales as Npe**2 per customer VPN. If it is per- 1320 PE, it scales as Npe**2 for all customer VPNs combined. 1321 Processing load - on each of two CEs, each packet is 1322 cryptographically processed, plus on each of two PEs, each 1323 packet is cryptographically processed twice (6P) 1324 Enhanced services - full; SP can apply any enhancements based on 1325 detailed view of traffic 1327 Given the tradeoffs discussed above, a few conclusions can be made: 1329 - Configurations 2 and 3 are subsets of 4 that may be appropriate 1330 alternatives to 4 under certain threat models; the remainder of 1331 these conclusions compare 1 (CE-to-CE) versus 4 (combined access 1332 links and PE-to-PE). 1334 - If protection from link eavesdropping or tampering is all that is 1335 important, then configurations 1 and 4 are equivalent. 1337 - If protection from device compromise is most important and the 1338 threat is to the CE devices, both cases are equivalent; if the 1339 threat is to the PE devices, configuration 1 is better. 1341 - If reducing complexity is most important, and the size of the 1342 network is small, configuration 1 is better. Otherwise 1343 configuration 4 is better because rather than a mesh of CE devices 1344 it requires a smaller mesh of PE devices. Also, under some PPVPN 1345 approaches the scaling of 4 is further improved by sharing the same 1346 PE-PE mesh across all VPN contexts. The scaling advantage of 4 may 1347 be increased or decreased in any given situation if the CE devices 1348 are simpler to configure than the PE devices, or vice-versa. 1350 Fang, et al. Informational 27 1351 MPLS/GMPLS Security framework 1352 February 2008 1354 - If the overall processing load is a key factor, then 1 is better, 1355 unless the PEs come with a hardware encryption accelerator and the 1356 CEs do not. 1358 - If the availability of enhanced services support from the SP is 1359 most important, then 4 is best. 1361 As a quick overall conclusion, CE-to-CE protection is better 1362 against device compromise, but this comes at the cost of enhanced 1363 services and at the cost of operational complexity due to the 1364 Order(n**2) scaling of a larger mesh. 1366 This analysis of site-to-site vs. hop-by-hop tradeoffs does not 1367 explicitly include cases of multiple providers cooperating to 1368 provide a PPVPN service, public Internet VPN connectivity, or 1369 remote access VPN service, but many of the tradeoffs will be 1370 similar. 1372 In addition to the simplified models, the following should also be 1373 considered: 1374 - There are reasons, perhaps, to protect a specific P-to-P or PE- 1375 to-P. 1376 - There may be reasons to do multiple encryptions over certain 1377 segments. One may be using an encrypted wireless link under our 1378 IPsec VPN to access a SSL-secured web site to download encrypted 1379 email attachments: four layers.) 1380 - It may be that, for example, cryptographic integrity checks are 1381 applied end to end, and confidentiality over a shorter span. 1382 - Different cryptographic protection may be required for control 1383 protocols and data traffic. 1384 - Attention needs to be given to how auxiliary traffic is 1385 protected, e.g., the ICMPv6 packets that flow back during PMTU 1386 discovery, among other examples. 1388 5.3. Access Control Techniques 1390 Access control techniques include packet-by-packet or packet-flow- 1391 by-packet-flow access control by means of filters and firewalls, as 1392 well as by means of admitting a "session" for a control, signaling, 1393 or management protocol. Enforcement of access control by isolated 1394 infrastructure addresses is discussed in another section of this 1395 document. 1397 In this document, we distinguish between filtering and firewalls 1398 based primarily on the direction of traffic flow. We define 1399 filtering as being applicable to unidirectional traffic, while a 1400 firewall can analyze and control both sides of a conversation. 1402 Fang, et al. Informational 28 1403 MPLS/GMPLS Security framework 1404 February 2008 1406 The definition has two significant corollaries: 1407 - Routing or traffic flow symmetry: A firewall typically requires 1408 routing symmetry, which is usually enforced by locating a firewall 1409 where the network topology assures that both sides of a 1410 conversation will pass through the firewall. A filter can operate 1411 upon traffic flowing in one direction, without considering traffic 1412 in the reverse direction. Beware that this concept could result in 1413 a single point of failure. 1414 - Statefulness: Because it receives both sides of a conversation, a 1415 firewall may be able to interpret a significant amount of 1416 information concerning the state of that conversation and use this 1417 information to control access. A filter can maintain some limited 1418 state information on a unidirectional flow of packets, but cannot 1419 determine the state of the bi-directional conversation as precisely 1420 as a firewall. 1422 5.3.1. Filtering 1424 It is relatively common for routers to filter data packets. That 1425 is, routers can look for particular values in certain fields of the 1426 IP or higher level (e.g., TCP or UDP) headers. Packets which 1427 matching the criteria associated with a particular filter may 1428 either be discarded or given special treatment. Today, not only 1429 routers, most end hosts today have filters and every instance of 1430 IPsec is also a filter [RFC4301]. 1432 In discussing filters, it is useful to separate the Filter 1433 Characteristics that may be used to determine whether a packet 1434 matches a filter from the Packet Actions applied to those packets 1435 which matching a particular filter. 1437 o Filter Characteristics 1439 Filter characteristics or rules are used to determine whether a 1440 particular packet or set of packets matches a particular filter. 1442 In many cases filter characteristics may be stateless. A stateless 1443 filter determines whether a particular packet matches a filter 1444 based solely on the filter definition, normal forwarding 1445 information (such as the next hop for a packet), and the contents 1446 of that individual packet. Typically stateless filters may consider 1447 the incoming and outgoing logical or physical interface, 1448 information in the IP header, and information in higher layer 1449 headers such as the TCP or UDP header. Information in the IP header 1450 to be considered may for example include source and destination IP 1451 addresses, Protocol field, Fragment Offset, and TOS field in IPv4, 1452 Next Header, Extension Headers, Flow label, etc. in IPv6. Filters 1454 Fang, et al. Informational 29 1455 MPLS/GMPLS Security framework 1456 February 2008 1458 also may consider fields in the TCP or UDP header such as the Port 1459 fields, the SYN field in the TCP header, as well as ICMP and ICMPv6 1460 type. 1462 Stateful filtering maintains packet-specific state information, to 1463 aid in determining whether a filter has been met. For example, a 1464 device might apply stateless filters to the first fragment of a 1465 fragmented IP packet. If the filter matches, then the data unit ID 1466 may be remembered and other fragments of the same packet may then 1467 be considered to match the same filter. Stateful filtering is more 1468 commonly done in firewalls, although firewall technology may be 1469 added to routers. Data unit ID can also be Fragmentation Extension 1470 Header in IPv6. 1472 o Actions based on Filter Results 1474 If a packet, or a series of packets, matches a specific filter, 1475 then a variety of actions which may be taken based on that match. 1476 Examples of such actions include: 1478 - Discard 1480 In many cases, filters are set to catch certain undesirable 1481 packets. Examples may include packets with forged or invalid source 1482 addresses, packets that are part of a DOS or Distributed DoS (DDOS) 1483 attack, or packets which are trying to access unallowed resources 1484 (such as network management packets from an unauthorized source). 1485 Where such filters are activated, it is common to discard the 1486 packet or set of packets matching the filter silently. The 1487 discarded packets may of course also be counted or logged. 1489 - Set CoS 1491 A filter may be used to set the Class of Service associated with 1492 the packet. 1494 - Count packets or bytes 1496 - Rate Limit 1498 In some cases the set of packets matching a particular filter may 1499 be limited to a specified bandwidth. In this case, packets or bytes 1500 would be counted, and would be forwarded normally up to the 1501 specified limit. Excess packets may be discarded or may be marked 1502 (for example by setting a "discard eligible" bit in the IP ToS 1503 field or the MPLS EXP field). 1505 - Forward and Copy 1507 Fang, et al. Informational 30 1508 MPLS/GMPLS Security framework 1509 February 2008 1511 It is useful in some cases to forward some set of packets normally, 1512 but also to send a copy to a specified other address or interface. 1513 For example, this may be used to implement a lawful intercept 1514 capability or to feed selected packets to an Intrusion Detection 1515 System. 1517 o Other Issues related to Use of Packet Filters 1519 Filtering performance may vary widely according to implementation 1520 and the types and number of rules. Without acceptable performance, 1521 filtering is not useful. 1523 The precise definition of "acceptable" may vary from SP to SP, and 1524 may depend upon the intended use of the filters. For example, for 1525 some uses a filter may be turned on all the time to set CoS, to 1526 prevent an attack, or to mitigate the effect of a possible future 1527 attack. In this case it is likely that the SP will want the filter 1528 to have minimal or no impact on performance. In other cases, a 1529 filter may be turned on only in response to a major attack (such as 1530 a major DDoS attack). In this case a greater performance impact may 1531 be acceptable to some service providers. 1533 A key consideration with the use of packet filters is that they can 1534 provide few options for filtering packets carrying encrypted data. 1535 Because the data itself is not accessible, only packet header 1536 information or other unencrypted fields can be used for filtering. 1538 5.3.2. Firewalls 1540 Firewalls provide a mechanism for control over traffic passing 1541 between different trusted zones in the MPLS/GMPLS model, or between 1542 a trusted zone and an untrusted zone. Firewalls typically provide 1543 much more functionality than filters, because they may be able to 1544 apply detailed analysis and logical functions to flows, and not 1545 just to individual packets. They may offer a variety of complex 1546 services, such as threshold-driven denial-of-service attack 1547 protection, virus scanning, acting as a TCP connection proxy, etc. 1549 As with other access control techniques, the value of firewalls 1550 depends on a clear understanding of the topologies of the 1551 MPLS/GMPLS core network, the user networks, and the threat model. 1552 Their effectiveness depends on a topology with a clearly defined 1553 inside (secure) and outside (not secure). 1555 Firewalls may be applied to help protect MPLS/GMPLS core network 1556 functions from attacks originating from the Internet or from 1558 Fang, et al. Informational 31 1559 MPLS/GMPLS Security framework 1560 February 2008 1562 MPLS/GMPLS user sites, but typically other defensive techniques 1563 will be used for this purpose. 1565 Where firewalls are employed as a service to protect user VPN sites 1566 from the Internet, different VPN users, and even different sites of 1567 a single VPN user, may have varying firewall requirements. The 1568 overall PPVPN logical and physical topology, along with the 1569 capabilities of the devices implementing the firewall services, has 1570 a significant effect on the feasibility and manageability of such 1571 varied firewall service offerings. 1573 Another consideration with the use of firewalls is that they can 1574 provide few options for handling packets carrying encrypted data. 1575 Because the data itself is not accessible, only packet header 1576 information, other unencrypted fields, or analysis of the flow of 1577 encrypted packets can be used for making decisions on accepting or 1578 rejecting encrypted traffic. 1580 Two approaches are to move the firewall outside of the encrypted 1581 part of the path or to register and pre-approve the encrypted 1582 session with the firewall. 1584 Handling DoS attacks has become increasingly important. Useful 1585 guidelines include the following: 1586 1. Perform ingress filtering everywhere. Upstream prevention is 1587 better. 1588 2. Be able to filter DoS attack packets at line speed. 1589 3. Do not allow oneself to amplify attacks. 1590 4. Continue processing legitimate traffic. Over provide for heavy 1591 loads. Use diverse locations, technologies, etc. 1593 5.3.3. Access Control to management interfaces 1595 Most of the security issues related to management interfaces can be 1596 addressed through the use of authentication techniques as described 1597 in the section on authentication. However, additional security may 1598 be provided by controlling access to management interfaces in other 1599 ways. 1601 The Optical Internetworking Forum has done good work on protecting 1602 such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. See OIF- 1603 SMI-01.0 "Security for Management Interfaces to Network Elements" 1604 [OIF-SMI-01.0], and "Addendum to the Security for Management 1605 Interfaces to Network Elements" [OIF-SMI-02.1]. See also the work 1606 in the ISMS WG. 1608 Fang, et al. Informational 32 1609 MPLS/GMPLS Security framework 1610 February 2008 1612 Management interfaces, especially console ports on MPLS/GMPLS 1613 devices, may be configured so they are only accessible out-of-band, 1614 through a system which is physically or logically separated from 1615 the rest of the MPLS/GMPLS infrastructure. 1617 Where management interfaces are accessible in-band within the 1618 MPLS/GMPLS domain, filtering or firewalling techniques can be used 1619 to restrict unauthorized in-band traffic from having access to 1620 management interfaces. Depending on device capabilities, these 1621 filtering or firewalling techniques can be configured either on 1622 other devices through which the traffic might pass, or on the 1623 individual MPLS/GMPLS devices themselves. 1625 5.4. Use of Isolated Infrastructure 1627 One way to protect the infrastructure used for support of 1628 MPLS/GMPLS is to separate the resources for support of MPLS/GMPLS 1629 services from the resources used for other purposes (such as 1630 support of Internet services). In some cases this may use 1631 physically separate equipment for VPN services, or even a 1632 physically separate network. 1634 For example, PE-based L3 VPNs may be run on a separate backbone not 1635 connected to the Internet, or may make use of separate edge routers 1636 from those used to support Internet service. Private IP addresses 1637 (local to the provider and non-routable over the Internet) are 1638 sometimes used to provide additional separation. 1640 5.5. Use of Aggregated Infrastructure 1642 In general, it is not feasible to use a completely separate set of 1643 resources for support of each service. In fact, one of the main 1644 reasons for MPLS/GMPLS enabled services is to allow sharing of 1645 resources between multiple users, including multiple VPNs, etc. 1646 Thus, even if certain services make use of a separate network from 1647 Internet services, nonetheless there will still be multiple 1648 MPLS/GMPLS users sharing the same network resources. In some cases 1649 MPLS/GMPLS services will share the use of network resources with 1650 Internet services or other services. 1652 It is therefore important for MPLS/GMPLS services to provide 1653 protection between resources used by different parties. Thus a 1654 well-behaved MPLS/GMPLS user should be protected from possible 1655 misbehavior by other users. This requires that limits are placed on 1656 the amount of resources used by any one VPN. For example, both 1657 control traffic and user data traffic may be rate limited. In some 1659 Fang, et al. Informational 33 1660 MPLS/GMPLS Security framework 1661 February 2008 1663 cases or in some parts of the network where a sufficiently large 1664 number of queues are available, each VPN (and optionally each VPN 1665 and CoS within the VPN) may make use of a separate queue. Control- 1666 plane resources such as link bandwidth as well as CPU and memory 1667 resources may be reserved on a per-VPN basis. 1669 The techniques used to provide resource protection between multiple 1670 users served by the same infrastructure can also be used to protect 1671 MPLS/GMPLS networks and services from Internet services. 1673 In general, the use of aggregated infrastructure allows the service 1674 provider to benefit from stochastic multiplexing of multiple bursty 1675 flows, and also may in some cases thwart traffic pattern analysis 1676 by combining the data from multiple users. 1678 5.6. Service Provider Quality Control Processes 1680 Deployment of provider-provisioned VPN services in general requires 1681 a relatively large amount of configuration by the SP. For example, 1682 the SP needs to configure which VPN each site belongs to, as well 1683 as QoS and SLA guarantees. This large amount of required 1684 configuration leads to the possibility of misconfiguration. 1686 It is important for the SP to have operational processes in place 1687 to reduce the potential impact of misconfiguration. CE-to-CE 1688 authentication may also be used to detect misconfiguration when it 1689 occurs. 1691 5.7. Deployment of Testable MPLS/GMPLS Service. 1693 This refers to solutions that can be readily tested to make sure 1694 they are configured correctly. For example, for a point-point 1695 connection, checking that the intended connectivity is working 1696 pretty much ensures that there is not connectivity to some 1697 unintended site. 1699 6. Monitoring, Detection, and Reporting of Security Attacks 1701 MPLS/GMPLS network and service may be subject to attacks from a 1702 variety of security threats. Many threats are described in another 1703 part of this document. Many of the defensive techniques described 1704 in this document and elsewhere provide significant levels of 1705 protection from a variety of threats. However, in addition to 1706 silently employing defensive techniques to protect against attacks, 1707 MPLS/GMPLS services can also add value for both providers and 1708 customers by implementing security monitoring systems to detect and 1710 Fang, et al. Informational 34 1711 MPLS/GMPLS Security framework 1712 February 2008 1714 report on any security attacks which occur, regardless of whether 1715 the attacks are effective. 1717 Attackers often begin by probing and analyzing defenses, so systems 1718 that can detect and properly report these early stages of attacks 1719 can provide significant benefits. 1721 Information concerning attack incidents, especially if available 1722 quickly, can be useful in defending against further attacks. It 1723 can be used to help identify attackers or their specific targets at 1724 an early stage. This knowledge about attackers and targets can be 1725 used to strengthen defenses against specific attacks or attackers, 1726 or improve the defensive services for specific targets on an as- 1727 needed basis. Information collected on attacks may also be useful 1728 in identifying and developing defenses against novel attack types. 1730 Monitoring systems used to detect security attacks in MPLS/GMPLS 1731 typically operate by collecting information from the Provider Edge 1732 (PE), Customer Edge (CE), and/or Provider backbone (P) devices. 1733 Security monitoring systems should have the ability to actively 1734 retrieve information from devices (e.g., SNMP get) or to passively 1735 receive reports from devices (e.g., SNMP notifications). The 1736 specific information exchanged depends on the capabilities of the 1737 devices and on the type of VPN technology. Particular care should 1738 be given to securing the communications channel between the 1739 monitoring systems and the MPLS/GMPLS devices. Syslog WG is 1740 specifying "Logging Capabilities for IP Network Infrastructure". 1741 (The specific references will be made only if the draft(s) became 1742 RFC before this draft.) 1744 The CE, PE, and P devices should employ efficient methods to 1745 acquire and communicate the information needed by the security 1746 monitoring systems. It is important that the communication method 1747 between MPLS/GMPLS devices and security monitoring systems be 1748 designed so that it will not disrupt network operations. As an 1749 example, multiple attack events may be reported through a single 1750 message, rather than allowing each attack event to trigger a 1751 separate message, which might result in a flood of messages, 1752 essentially becoming a denial-of-service attack against the 1753 monitoring system or the network. 1755 The mechanisms for reporting security attacks should be flexible 1756 enough to meet the needs of MPLS/GMPLS service providers, 1757 MPLS/GMPLS customers, and regulatory agencies, if applicable. The 1758 specific reports should depend on the capabilities of the devices, 1759 the security monitoring system, the type of VPN, and the service 1760 level agreements between the provider and customer. 1762 Fang, et al. Informational 35 1763 MPLS/GMPLS Security framework 1764 February 2008 1766 7. Service Provider General Security Requirements 1768 This section covers security requirements the provider may have for 1769 securing its MPLS/GMPLS network infrastructure including LDP and 1770 RSVP-TE specific requirements. 1772 The MPLS/GMPLS service provider's requirements defined here are for 1773 the MPLS/GMPLS core in the reference model. The core network can 1774 be implemented with different types of network technologies, and 1775 each core network may use different technologies to provide the 1776 various services to users with different levels of offered 1777 security. Therefore, a MPLS/GMPLS service provider may fulfill any 1778 number of the security requirements listed in this section. This 1779 document does not state that a MPLS/GMPLS network must fulfill all 1780 of these requirements to be secure. 1782 These requirements are focused on: 1) how to protect the MPLS/GMPLS 1783 core from various attacks outside the core including network users, 1784 both accidentally and maliciously, 2) how to protect the end users. 1786 7.1. Protection within the Core Network 1788 7.1.1. Control Plane Protection - General 1790 - Protocol authentication within the core: 1792 The network infrastructure must support mechanisms for 1793 authentication of the control plane. If MPLS/GMPLS core is used, 1794 LDP sessions may be authenticated by use TCP MD5, in addition, IGP 1795 and BGP authentication should also be considered. For a core 1796 providing Layer 2 services, PE-to-PE authentication may also be 1797 performed via IPsec. See the above discussion of protocol security 1798 services: authentication, integrity (with replay detection), 1799 confidentiality. Protocols need to provide a complete set of 1800 security services from which the SP can choose. Also, the hard part 1801 is key management. 1803 With the cost of authentication coming down rapidly, the 1804 application of control plane authentication may not increase the 1805 cost of implementation for providers significantly, and will help 1806 to improve the security of the core. If the core is dedicated to 1807 MPLS/GMPLS enabled services and without any interconnects to third 1808 parties then this may reduce the requirement for authentication of 1809 the core control plane. 1811 - Infrastructure Hiding 1813 Fang, et al. Informational 36 1814 MPLS/GMPLS Security framework 1815 February 2008 1817 Here we discuss means to hide the provider's infrastructure nodes. 1819 A MPLS/GMPLS provider may make its infrastructure routers (P and PE 1820 routers) unreachable from outside users and unauthorized internal 1821 users. For example, separate address space may be used for the 1822 infrastructure loopbacks. 1824 Normal TTL propagation may be altered to make the backbone look 1825 like one hop from the outside, but caution needs to be taken for 1826 loop prevention. This prevents the backbone addresses from being 1827 exposed through trace route; however this must also be assessed 1828 against operational requirements for end-to-end fault tracing. 1830 An Internet backbone core may be re-engineered to make Internet 1831 routing an edge function, for example, by using MPLS label 1832 switching for all traffic within the core and possibly make the 1833 Internet a VPN within the PPVPN core itself. This helps to detach 1834 Internet access from PPVPN services. 1836 Separating control plane, data plane, and management plane 1837 functionality in hardware and software may be implemented on the PE 1838 devices to improve security. This may help to limit the problems 1839 when attacked in one particular area, and may allow each plane to 1840 implement additional security measures separately. 1842 PEs are often more vulnerable to attack than P routers, because PEs 1843 cannot be made unreachable from outside users by their very nature. 1844 Access to core trunk resources can be controlled on a per user 1845 basis by using of inbound rate-limiting or traffic shaping; this 1846 can be further enhanced on a per Class of Service basis (see 1847 Section 8.2.3) 1849 In the PE, using separate routing processes for different services, 1850 for example, Internet and PPVPN service, may help to improve the 1851 PPVPN security and better protect VPN customers. Furthermore, if 1852 resources, such as CPU and Memory, can be further separated based 1853 on applications, or even individual VPNs, it may help to provide 1854 improved security and reliability to individual VPN customers. 1856 7.1.2. Control plane protection with RSVP-TE 1858 - RSVP Security Tools 1860 Isolation of the trusted domain is an important security mechanism 1861 for RSVP, to ensure that an untrusted element cannot access a 1862 router of the trusted domain. However, isolation is limited by the 1863 need to allow ASBR-ASBR communication for inter-AS LSPs. Isolation 1864 mechanisms might also be bypassed by Router Alert IP packets. A 1866 Fang, et al. Informational 37 1867 MPLS/GMPLS Security framework 1868 February 2008 1870 solution could consists of disabling the RSVP router alert mode and 1871 dropping all IP packets with the router alert option, or also to 1872 drop all incoming IP packets on an interface with port 46, which 1873 requires an access-list at the IP port level) or spoofed IP packets 1874 if anti-spoofing is not otherwise activated. 1876 RSVP security can be strengthened by deactivating RSVP on 1877 interfaces with neighbors who are not authorized to use RSVP, to 1878 protect against adjacent CE-PE attacks. However, this does not 1879 really protect against DoS attacks or attacks on non-adjacent 1880 routers. It has been demonstrated that substantial CPU resources 1881 are consumed simply by processing received RSVP packets, even if 1882 the RSVP process is deactivated for the specific interface on which 1883 the RSVP packets are received. 1885 RSVP neighbor filtering at the protocol level, to restrict the set 1886 of neighbors that can send RSVP messages to a given router, 1887 protects against non-adjacent attacks. However, this does not 1888 protect against DoS attacks and does not effectively protect 1889 against spoofing of the source address of RSVP packets, if the 1890 filter relies on the neighbor's address within the RSVP message. 1892 RSVP neighbor filtering at the data plane level (with an access 1893 list to accept IP packets with port 46, only for specific 1894 neighbors). This requires Router Alert mode to be deactivated and 1895 does not protect against spoofing. 1897 - Authentication for RSVP messages 1899 One of the most powerful tools for protection against RSVP-based 1900 attacks is the use of authentication for RSVP messages, based on a 1901 secure message hash using a key shared by RSVP neighbors. This 1902 protects against LSP creation attacks, at the expense of consuming 1903 significant CPU resources for digest computation. In addition, if 1904 the neighboring RSVP speaker is compromised, it could be used to 1905 launch attacks using authenticated RSVP messages. These methods, 1906 and certain other aspects of RSVP security, are explained in detail 1907 in RFC 4230 [RFC4230]. Key management must be implemented. Logging 1908 and auditing as well as multiple layers of crypto protection can 1909 help here. IPsec can also be used. 1911 Another valuable tool is RSVP message pacing, to limit the number 1912 of RSVP messages sent to a given neighbor during a given period. 1913 This allows blocking DoS attack propagation. 1915 The trick with DoS is to let the good packet through and keep 1916 operating. Rate limiting by itself needs to be selective do this. 1918 Fang, et al. Informational 38 1919 MPLS/GMPLS Security framework 1920 February 2008 1922 - limit the impact of an attack on control plane resources 1924 To ensure continued effective operation of the MPLS router even in 1925 the case of an attack that bypasses packet filtering mechanisms 1926 such as Access Control Lists in the data plane, it is important 1927 that routers have some mechanisms to limit the impact of the 1928 attack. There should be a mechanism to rate limit the amount of 1929 control plane traffic addressed to the router, per interface. This 1930 should be configurable on a per-protocol basis, (and, ideally, on a 1931 per-sender basis) to avoid letting an attacked protocol or a given 1932 sender blocking all communications. This requires the ability to 1933 filter and limit the rate of incoming messages of particular 1934 protocols, such as RSVP (filtering at the IP protocol level), and 1935 particular senders. In addition, there should be a mechanism to 1936 limit CPU and memory capacity allocated to RSVP, so as to protect 1937 other control plane elements. To limit the memory allocation, it 1938 will probably be necessary to limit the number of LSPs that can be 1939 set up. 1941 7.1.3. Control plane protection with LDP 1943 The approaches to protect MPLS routers against LDP-based attacks 1944 are similar to those for RSVP, including isolation, protocol 1945 deactivation on specific interfaces, filtering of LDP neighbors at 1946 the protocol level, filtering of LDP neighbors at the data plane 1947 level (access list that filter the TCP & UDP LDP ports), 1948 authentication with message digest, rate limiting of LDP messages 1949 per protocol per sender and limiting all resources allocated to 1950 LDP-related tasks. 1952 7.1.4. Data Plane Protection 1954 IPsec can provide authentication, integrity, confidentiality, and 1955 replay detection for provider or user data. It also has an 1956 associated key management protocol. 1958 In today's MPLS/GMPLS, ATM, or Frame Relay networks, encryption is 1959 not provided as a basic feature. Mechanisms described in section 5 1960 can be used to secure the MPLS data plane traffic carried over MPLS 1961 core. Both the Frame Relay Forum and the ATM Forum standardized 1962 cryptographic security services in the late 1990s, but these 1963 standards are not widely implemented. 1965 7.2. Protection on the User Access Link 1967 Fang, et al. Informational 39 1968 MPLS/GMPLS Security framework 1969 February 2008 1971 Peer or neighbor protocol authentication may be used to enhance 1972 security. For example, BGP MD5 authentication may be used to 1973 enhance security on PE-CE links using eBGP. In the case of Inter- 1974 provider connection, cryptographic protection mechanisms between 1975 ASes, such as IPsec, may be used. 1977 If multiple services are provided on the same PE platform, 1978 different WAN link layer address spaces may be used for different 1979 services (e.g., VPN and non-VPN) to enhance isolation. 1981 Firewall and Filtering: access control mechanisms can be used to 1982 filter any packets destined for the service provider's 1983 infrastructure prefix or eliminate routes identified as 1984 illegitimate. 1986 Rate limiting may be applied to the user interface/logical 1987 interfaces against DDoS bandwidth attack. This is helpful when the 1988 PE device is supporting both multi-services, especially VPN and 1989 Internet Services, on the same physical interfaces through 1990 different logical interfaces. 1992 7.2.1. Link Authentication 1994 Authentication can be used to validate site access to the network 1995 via fixed or logical connections, e.g. L2TP, IPsec, respectively. 1996 If the user wishes to hold the authentication credentials for 1997 access, then provider solutions require the flexibility for either 1998 direct authentication by the PE itself or interaction with a 1999 customer authentication server. Mechanisms are required in the 2000 latter case to ensure that the interaction between the PE and the 2001 customer authentication server is appropriately secured. 2003 7.2.2. Access Routing Control 2005 Routing protocol level e.g., RIP, OSPF, or BGP, may be used to 2006 provide control access between a CE and PE. Per neighbor and per 2007 VPN routing policies may be established to enhance security and 2008 reduce the impact of a malicious or non-malicious attack on the PE; 2009 the following mechanisms, in particular, should be considered: 2010 - Limiting the number of prefixes that may be advertised on 2011 a per access basis into the PE. Appropriate action may be 2012 taken should a limit be exceeded, e.g., the PE shutting 2013 down the peer session to the CE 2014 - Applying route dampening at the PE on received routing 2015 updates 2016 - Definition of a per VPN prefix limit after which 2017 additional prefixes will not be added to the VPN routing 2018 table. 2020 Fang, et al. Informational 40 2021 MPLS/GMPLS Security framework 2022 February 2008 2024 In the case of Inter-provider connection, access protection, link 2025 authentication, and routing policies as described above may be 2026 applied. Both inbound and outbound firewall or filtering mechanism 2027 between ASes may be applied. Proper security procedures must be 2028 implemented in Inter-provider interconnection to protect the 2029 providers' network infrastructure and their customers. This may be 2030 custom designed for each Inter-Provider peering connection, and 2031 must be agreed upon by both providers. 2033 7.2.3. Access QoS 2035 MPLS/GMPLS providers offering QoS-enabled services require 2036 mechanisms to ensure that individual accesses are validated against 2037 their subscribed QOS profile and as such gain access to core 2038 resources that match their service profile. Mechanisms such as per 2039 Class of Service rate limiting or traffic shaping on ingress to the 2040 MPLS/GMPLS core are one option for providing this level of control. 2041 Such mechanisms may require the per Class of Service profile to be 2042 enforced either by marking, or remarking or discard of traffic 2043 outside of the profile. 2045 7.2.4. Customer service monitoring tools 2047 End users requiring specific statistics on the core, e.g., routing 2048 table, interface status, or QoS statistics, requirements for 2049 mechanisms at the PE both to validate the incoming user and limit 2050 the views available to that particular user. Mechanisms should 2051 also be considered to ensure that such access cannot be used a 2052 means of a DoS attack (either malicious or accidental) on the PE 2053 itself. This could be accomplished through either separation of 2054 these resources within the PE itself or via the capability to rate- 2055 limit on a per physical or logical connection basis such traffic. 2057 7.3. General User Requirements for MPLS/GMPLS Providers 2059 MPLS/GMPLS providers must support end users' security requirements. 2060 Depending on the technologies used, these requirements may include: 2062 - User control plane separation - routing isolation when 2063 applicable, for example, in the case of MPLS VPNs. 2064 - Protection against intrusion, DoS attacks and spoofing 2065 - Access Authentication 2066 - Techniques highlighted through this document that identify 2067 methodologies for the protection of resources and the 2068 MPLS/GMPLS infrastructure. 2070 Fang, et al. Informational 41 2071 MPLS/GMPLS Security framework 2072 February 2008 2074 Hardware or software errors in equipment leading to breaches in 2075 security are not within the scope of this document. 2077 8. Inter-provider Security Requirements 2079 This section discusses security capabilities that are important at 2080 the MPLS/GMPLS Inter-provider connections and at devices (including 2081 ASBR routers) supporting these connections. The security 2082 capabilities stated in this section should be considered as 2083 complementary to security considerations addressed in individual 2084 protocol specifications or security frameworks. 2086 Security vulnerabilities and exposures may be propagated across 2087 multiple networks because of security vulnerabilities arising in 2088 one peer's network. Threats to security originate from accidental, 2089 administrative, and intentional sources. Intentional threats 2090 include events such as spoofing and Denial of Service (DoS) 2091 attacks. 2092 The level and nature of threats, as well as security and 2093 availability requirements, may vary over time and from network to 2094 network. This section therefore discusses capabilities that need to 2095 be available in equipment deployed for support of the MPLS 2096 InterCarrier Interconnect (MPLS-ICI). Whether any particular 2097 capability is used in any one specific instance of the ICI is up to 2098 the service providers managing the PE equipment offering/using the 2099 ICI services. 2101 8.1. Control Plane Protection 2103 This section discusses capabilities for control plane protection, 2104 including protection of routing, signaling, and OAM capabilities. 2106 8.1.1. Authentication of Signaling Sessions 2108 Authentication is needed for signaling sessions (i.e., BGP, LDP and 2109 RSVP-TE) and routing sessions (e.g., BGP) as well as OAM sessions 2110 across domain boundaries. Equipment must be able to support 2111 exchange of all protocol messages over a single IPsec tunnel, with 2112 NULL encryption and authentication, between the peering ASBRs. 2113 Support for TCP MD5 authentication for LDP and BGP and for RSVP-TE 2114 authentication must also be provided. Manual keying of IPsec should 2115 not be used. IKEv2 with pre-shared secrets or public key methods 2116 should be used. Replay detection should be used. 2118 Mechanisms to authenticate and validate a dynamic setup request 2119 MUST be available. For instance, if dynamic signaling of a TE-LSP 2120 or PW is crossing a domain boundary, there must be a way to detect 2122 Fang, et al. Informational 42 2123 MPLS/GMPLS Security framework 2124 February 2008 2126 whether the LSP source is who it claims to be and that he is 2127 allowed to connect to the destination. 2129 MD5 authentication support for all TCP-based protocols within the 2130 scope of the MPLS-ICI (i.e., LDP signaling and BGP routing) and MD5 2131 authentication for the RSVP-TE Integrity Object MUST be provided to 2132 interoperate with current practices. 2133 Equipment SHOULD be able to support exchange of all signaling and 2134 routing (LDP, RSVP-TE, and BGP) protocol messages over a single 2135 IPSec security association pair in tunnel or transport mode with 2136 authentication but with NULL encryption, between the peering ASBRs. 2137 IPSec, if supported, must be supported with HMAC-MD5 and optionally 2138 SHA-1. It is expected that authentication algorithms will evolve 2139 over time and support can be updated as needed. 2141 OAM Operations across the MPLS-ICI could also be the source of 2142 security threats on the provider infrastructure as well as the 2143 service offered over the MPLS-ICI. A large volume of OAM messages 2144 could overwhelm the processing capabilities of an ASBR if the ASBR 2145 is not properly protected. Maliciously generated OAM messages could 2146 also be used to bring down an otherwise healthy service (e.g., MPLS 2147 Pseudo Wire), and therefore affect service security. MPLS-ping does 2148 not support authentication today, and that support should be 2149 subject for future considerations. Bidirectional Forwarding 2150 Detection (BFD), however, does have support for carrying an 2151 authentication object. It also supports Time-To-Live (TTL) 2152 processing as an anti-replay measure. Implementations conformant 2153 with this MPLS-ICI should support BFD authentication using MD5 and 2154 must support the procedures for TTL processing. 2156 8.1.2. Protection against DoS attacks in the Control 2157 Plane 2159 Implementation must have the ability to prevent signaling and 2160 routing DoS attacks on the control plane per interface and 2161 provider. Such prevention may be provided by rate-limiting 2162 signaling and routing messages that can be sent by a peer provider 2163 according to a traffic profile and by guarding against malformed 2164 packets. 2166 Equipment MUST provide the ability to filter signaling, routing, 2167 and OAM packets destined for the device, and MUST provide the 2168 ability to rate limit such packets. Packet filters SHOULD be 2169 capable of being separately applied per interface, and SHOULD have 2170 minimal or no performance impact. For example, this allows an 2171 operator to filter or rate-limit signaling, routing, and OAM 2172 messages that can be sent by a peer provider and limit such traffic 2173 to a given profile. 2175 Fang, et al. Informational 43 2176 MPLS/GMPLS Security framework 2177 February 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 L3 VPN services. 2225 Fang, et al. Informational 44 2226 MPLS/GMPLS Security framework 2227 February 2008 2229 When routing information is advertised from one domain to the 2230 other, operators must be able to guard against situations that 2231 result in traffic hijacking, black-holing, resource stealing (e.g., 2232 number of routes), etc. For instance, in the IPVPN case, an 2233 operator must be able to block routes based on associated route 2234 target attributes. In addition, mechanisms must exist to verify 2235 whether a route advertised by a peer for a given VPN is actually a 2236 valid route and whether the VPN has a site attached or reachable 2237 through that domain. 2239 Equipment (ASBRs and Route Reflectors (RRs)) supporting operation 2240 of BGP MUST be able to restrict which Route Target attributes are 2241 sent to and accepted from a BGP peer across an ICI. Equipment 2242 (ASBRs, RRs) SHOULD also be able to inform the peer regarding which 2243 Route Target attributes it will accept from a peer, because sending 2244 an incorrect Route Target can result in incorrect cross-connection 2245 of VPNs. Also, sending inappropriate route targets to a peer may 2246 disclose confidential information. 2248 8.1.6. Protection Against Spoofed Updates and Route 2249 Advertisements 2251 Equipment MUST support route filtering of routes received via a BGP 2252 peer sessions by applying policies that include one or more the 2253 following: AS path, BGP next hop, standard community or extended 2254 community. 2256 8.1.7. Protection of Confidential Information 2258 Ability to identify and prohibit messages 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 reject, or apply policies to these messages. Solutions must enable 2278 Fang, et al. Informational 45 2279 MPLS/GMPLS Security framework 2280 February 2008 2282 providers to control the information that is relayed to another 2283 provider about the path that a LSP takes. For example, in RSVP-TE 2284 record route object or MPLS-ping trace, a provider must be able to 2285 control the information contained in corresponding messages when 2286 sent to another provider. 2288 8.1.8. Protection Against over-provisioned number of 2289 RSVP-TE LSPs and bandwidth reservation 2291 In addition to the control plane protection mechanisms listed in 2292 the previous section on Control plane protection with RSVP-TE, the 2293 ASBR must be able both to limit the number of LSPs that can be set 2294 up by other domains and to limit the amount of bandwidth that can 2295 be reserved. A provider's ASBR may deny a LSP set up request or a 2296 bandwidth reservation request sent by another provider's whose the 2297 limits have been reached. 2299 8.2. Data Plane Protection 2301 8.2.1. Protection against DoS in the Data Plane 2302 This is described earlier in this document. 2304 8.2.2. Protection against Label Spoofing 2306 Verification that a label received across an interconnect was 2307 actually assigned to the provider across the interconnect. If the 2308 label was not assigned to the provider, the packet MUST be dropped. 2310 Equipment MUST be able to verify that a label received across an 2311 interconnect was actually assigned to a LSP arriving from the 2312 provider across that interconnect. If the label was not assigned to 2313 a LSP which arrives at this router from the correct neighboring 2314 provider, the packet MUST be dropped. This verification can be 2315 applied to the top label only. The top label is the received top 2316 label and every label that is exposed by label popping to be used 2317 for forwarding decisions. 2319 Equipment MUST provide the capability of dropping MPLS-labeled 2320 packets if all labels in the stack are not processed. This lets 2321 carriers guarantee that every label that enters its domain from 2322 another carrier was actually assigned to that carrier. 2324 The following requirements are not directly reflected in this 2325 document but must be used as guidance for addressing further work. 2327 Solutions MUST NOT force operators to reveal reachability 2328 information to routers within their domains. 2338 Mechanisms to authenticate and validate a dynamic setup request 2339 MUST be available. For instance, if dynamic signaling of a TE-LSP 2340 or PW is crossing a domain boundary, there must be a way to detect 2341 whether the LSP source is who it claims to be and that he is 2342 allowed to connect to the destination. 2344 8.2.3. Protection using ingress traffic policing and 2345 enforcement 2347 The following simple diagram illustrates a potential security issue 2348 on the data plane issue across a MPLS interconnect: 2350 SP2 - ASBR2 - labeled path - ASBR1 - P1 - SP1's PSN - P2 - PE1 2351 | | | | 2352 |< AS2 >||< AS1 >| 2354 Traffic flow direction is from SP2 to SP1 2356 Usually, the transit label used by ASBR2 is allocated by ASBR1, 2357 which in turn advertises it to ASB2 (downstream unsolicited or on- 2358 demand), and this label is used for a service context (VPN label, 2359 PW VC label, etc.), and this LSP is normally terminated at a 2360 forwarding table belonging to the service instance on PE (PE1) in 2361 SP1. 2363 In the example above, ASBR1 would not know whether the label of an 2364 incoming packet from ASBR2 over the interconnect is a VPN label or 2365 PSN label for AS1. So it is possible (though rare) that ASBR2 can 2366 be accidentally or intentionally configured such that the incoming 2367 label could match a PSN label (e.g., LDP) in AS1. Then, this LSP 2368 would end up on the global plane of an infrastructure router (P or 2369 PE1), and this could invite a unidirectional attack on that P or 2370 PE1 where the LSP terminates. 2372 To mitigate this threat, implementations SHOULD be able to do a 2373 forwarding path look-up for the label on an incoming packet from an 2374 interconnect in a Label Forwarding Information Base (LFIB) space 2375 that is only intended for its own service context or provide a 2376 mechanism on the data plane that would ensure the incoming labels 2377 are what ASBR1 has allocated and advertised. 2379 A similar concept has been proposed in "Requirements for Multi- 2380 Segment Pseudowire Emulation Edge-to-Edge (PWE3)" [PW-REQ]. 2382 Fang, et al. Informational 47 2383 MPLS/GMPLS Security framework 2384 February 2008 2386 9. Summary of MPLS and GMPLS Security 2388 The following summary provides a quick check list of MPLS and GMPLS 2389 security threats, defense techniques, and the best practice guide 2390 outlines for MPLS and GMPLS deployment. 2392 9.1. MPLS and GMPLS Specific Security Threats 2394 9.1.1. Control plane attacks 2396 Types of attacks on the control plane: 2397 - Unauthorized LSP creation 2398 - LSP message interception 2400 Attacks against RSVP-TE: DoS attack with setting up 2401 unauthorized LSP and/or LSP messages. 2403 Attacks against LDP: DoS attack with storms of LDP Hello 2404 messages or LDP TCP Syn messages. 2406 Attacks may be launched from external or internal sources, or 2407 through SP management systems. 2409 Attacks may be targeted to the SP routing protocols or 2410 infrastructure elements. 2412 In general, control protocols may be attacked by: 2413 - MPLS signaling (LDP, RSVP-TE) 2414 - PCE signaling 2415 - IPsec signaling (IKE and IKEv2) 2416 - ICMP and ICMPv6 2417 - L2TP 2418 - BGP-based membership discovery 2419 - Database-based membership discovery (e.g., RADIUS) 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 2426 - Data traffic modification 2427 - Spoofing and replay 2428 - Unauthorized Deletion 2429 - Unauthorized Traffic Pattern Analysis 2430 - Denial of Service Attacks 2432 9.2. Defense Techniques 2434 Fang, et al. Informational 48 2435 MPLS/GMPLS Security framework 2436 February 2008 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 2460 9.3. Service Provider MPLS and GMPLS Best Practice Outlines 2462 9.3.1. SP infrastructure protection 2464 1) General control plane protection 2465 - Protocol authentication within the core 2466 - Infrastructure Hiding (e.g. disable TTL propagation) 2467 2) RSVP control plane protection 2468 - Using RSVP security tools 2469 - Isolation of the trusted domain 2470 - Deactivating RSVP on interfaces with neighbors who are not 2471 authorized to use RSVP 2472 - RSVP neighbor filtering at the protocol level and data plane 2473 level 2474 - Authentication for RSVP messages 2475 - RSVP message pacing 2476 3) LDP control plane protection (similar techniques as for RSVP) 2477 4) Data plane protection 2478 - User Access link protection 2479 - Link Authentication 2480 - Access routing control (e.g. prefix limits, route dampening, 2481 routing table limits (e.g. VRF limits) 2482 - Access QoS control 2483 - Using customer service monitoring tools 2485 Fang, et al. Informational 49 2486 MPLS/GMPLS Security framework 2487 February 2008 2489 9.3.2. Inter-provider Security 2491 Inter-provider connections are high security risk areas. Similar 2492 techniques and procedures as described in for SP general core 2493 protection are listed below for inter-provider connections. 2495 1) Control plane protection at the inter-provider connections 2496 - Authentication of Signaling Sessions 2497 - Protection against DoS attacks in the Control Plane 2498 - Protection against Malformed Packets 2499 - Ability to Enable/Disable Specific Protocols 2500 - Protection Against Incorrect Cross Connection 2501 - Protection Against Spoofed Updates and Route Advertisements 2502 - Protection of Confidential Information 2503 - Protection Against over-provisioned number of RSVP-TE LSPs 2504 and bandwidth reservation 2505 2) Data Plane Protection at the inter-provider connections 2506 - Protection against DoS in the Data Plane 2507 - Protection against Label Spoofing 2509 10. Security Considerations 2511 Security considerations constitute the sole subject of this memo 2512 and hence are discussed throughout. Here we recap what has been 2513 presented and explain at a high level the role of each type of 2514 consideration in an overall secure MPLS/GMPLS system. 2516 The document describes a number of potential security threats. 2517 Some of these threats have already been observed occurring in 2518 running networks; others are largely theoretical at this time. 2520 DoS attacks and intrusion attacks from the Internet against service 2521 providers' infrastructure have been seen. DoS "attacks" (typically 2522 not malicious) have also been seen in which CE equipment overwhelms 2523 PE equipment with high quantities or rates of packet traffic or 2524 routing information. Operational or provisioning errors are cited 2525 by service providers as one of their prime concerns. 2527 The document describes a variety of defensive techniques that may 2528 be used to counter the suspected threats. All of the techniques 2529 presented involve mature and widely implemented technologies that 2530 are practical to implement. 2532 The document describes the importance of detecting, monitoring, and 2533 reporting attacks, both successful and unsuccessful. These 2534 activities are essential for "understanding one's enemy", 2536 Fang, et al. Informational 50 2537 MPLS/GMPLS Security framework 2538 February 2008 2540 mobilizing new defenses, and obtaining metrics about how secure the 2541 MPLS/GMPLS network is. As such, they are vital components of any 2542 complete PPVPN security system. 2544 The document evaluates MPLS/GMPLS security requirements from a 2545 customer's perspective as well as from a service provider's 2546 perspective. These sections re-evaluate the identified threats 2547 from the perspectives of the various stakeholders and are meant to 2548 assist equipment vendors and service providers, who must ultimately 2549 decide what threats to protect against in any given configuration 2550 or service offering. 2552 11. IANA Considerations 2554 No new IANA considerations. 2556 12. Normative References 2558 [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label 2559 Switching Architecture", RFC 3031, January 2001. 2561 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 2562 (GMPLS) Architecture", RFC 3945, October 2004. 2564 [RFC3036] Andersson, et al., "LDP Specification", January 2001. 2566 [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP 2567 Tunnels", December 2001. 2569 [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet 2570 Protocol," December 2005. 2572 [RFC4302] S. Kent, "IP Authentication Header," December 2005. 2574 [RFC4835] V. Manral, "Cryptographic Algorithm Implementation 2575 Requirements for Encapsulating Security Payload (ESP) and 2576 Authentication Header (AH)", April 2007. 2578 [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) 2579 Protocol",December 2005. 2581 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) 2582 CCM Mode with IPsec Encapsulating Security Payload (ESP)", December 2583 2005. 2585 Fang, et al. Informational 51 2586 MPLS/GMPLS Security framework 2587 February 2008 2589 [RFC4346] T. Dierks and E. Rescorla, "The Transport Layer Security 2590 (TLS) Protocol, Version 1.1," April 2006. 2592 [RFC4379] K. Kompella and G. Swallow, "Detecting Multi-Protocol 2593 Label Switched (MPLS) Data Plane Failures", February 2006. 2595 [RFC4447] Martini, et al., "Pseudowire Setup and Maintenance Using 2596 the Label Distribution Protocol (LDP)", April 2006. 2598 [STD62] "Simple Network Management Protocol, Version 3,", December 2599 2002. 2601 [STD-8] J. Postel and J. Reynolds, "TELNET Protocol Specification", 2602 STD 8, May 1983. 2604 13. Informational References 2606 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 2607 Requirement Levels", BCP 14, RFC 2119, March 1997 2609 [OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces 2610 to Network Elements", Optical Internetworking Forum, Sept. 2003. 2612 [OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for 2613 Management Interfaces to Network Elements", Optical Internetworking 2614 Forum, March 2006. 2616 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 2617 for Message Authentication," February 1997. 2619 [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 2620 Roadmap," November 1998. 2622 [RFC3174] D. Eastlake, 3rd, and P. Jones, "US Secure Hash Algorithm 2623 1 (SHA1)," September 2001. 2625 [RFC3562] M. Leech, "Key Management Considerations for the TCP MD5 2626 Signature Option", July 2003. 2628 [RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security 2629 Mechanisms for the Internet," December 2003. 2631 [RFC3985] S. Bryant and P. Pate, "Pseudo Wire Emulation Edge-to- 2632 Edge (PWE3) Architecture", March 2005. 2634 Fang, et al. Informational 52 2635 MPLS/GMPLS Security framework 2636 February 2008 2638 [RFC4103] G. Hellstrom and P. Jones, "RTP Payload for Text 2639 Conversation", June 2005. 2641 [RFC4107] S. Bellovin, R. Housley, "Guidelines for Cryptographic 2642 Key Management", June 2005. 2644 [RFC4110] R. Callon and M. Suzuki, "A Framework for Layer 3 2645 Provider-Provisioned Virtual Private Networks (PPVPNs)", July 2005. 2647 [RFC4111] L. Fang, "Security Framework of Provider Provisioned 2648 VPN", RFC 4111, July 2005. 2650 [RFC4230] H. Tschofenig and R. Graveman, "RSVP Security 2651 Properties", December 2005. 2653 [RFC4308] P. Hoffman, "Cryptographic Suites for IPsec", December 2654 2005. 2656 [RFC4593] A. Barbir, S. Murphy, Y. Yang, "Generic Threats to Routing 2657 Protocols", October 2006. 2659 [RFC4808] S. Bellovin, "Key Change Strategies for TCP-MD5", March 2660 2007. 2662 [RFC4869] L. Law and J. Solinas, "Suite B Cryptographic Suites for 2663 IPsec", April 2007. 2665 [MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical 2666 Specification", mpls2007.017, August 2006. 2668 [opsec efforts] C. Lonvick and D. Spak, "Security Best Practices 2669 Efforts and Documents", draft-ietf-opsec-efforts-07.txt, December 2670 2007. 2672 [PW-REQ] N. Bitar, M. Bocci, L. Martini, "Requirements for Multi- 2673 Segment Pseudowire Emulation Edge-to-Edge", draft-ietf-pwe3-ms-pw- 2674 requirements-06.txt, November 2007. 2676 14. Author's Addresses 2678 Luyuan Fang 2679 Cisco Systems, Inc. 2680 300 Beaver Brook Road 2681 Boxborough, MA 01719 2682 USA 2684 Fang, et al. Informational 53 2685 MPLS/GMPLS Security framework 2686 February 2008 2688 Email: lufang@cisco.com 2690 Michael Behringer 2691 Cisco Systems, Inc. 2692 Village d'Entreprises Green Side 2693 400, Avenue Roumanille, Batiment T 3 2694 06410 Biot, Sophia Antipolis 2695 FRANCE 2697 Email: mbehring@cisco.com 2699 Ross Callon 2700 Juniper Networks 2701 10 Technology Park Drive 2702 Westford, MA 01886 2703 USA 2705 Email: rcallon@juniper.net 2707 Jean-Louis Le Roux 2708 France Telecom 2709 2, avenue Pierre-Marzin 2710 22307 Lannion Cedex 2711 FRANCE 2713 Email: jeanlouis.leroux@francetelecom.com 2715 Raymond Zhang 2716 British Telecom 2717 2160 E. Grand Ave. El Segundo, CA 90025 2718 USA 2720 Email: raymond.zhang@bt.com 2722 Paul Knight 2723 Nortel 2724 600 Technology Park Drive 2725 Billerica, MA 01821 2727 Email: paul.knight@nortel.com 2729 Yaakov (Jonathan) Stein 2730 RAD Data Communications 2731 24 Raoul Wallenberg St., Bldg C 2732 Tel Aviv 69719 2733 ISRAEL 2735 Email: yaakov_s@rad.com 2737 Fang, et al. Informational 54 2738 MPLS/GMPLS Security framework 2739 February 2008 2741 Nabil Bitar 2742 Verizon 2743 40 Sylvan Road 2744 Waltham, MA 02145 2745 Email: nabil.bitar@verizon.com 2747 Richard Graveman 2748 RFG Security 2749 15 Park Avenue 2750 Morristown, NJ 07960 2751 Email: rfg@acm.org 2753 Monique Morrow 2754 Glatt-com 2755 CH-8301 Glattzentrum 2756 Switzerland 2757 Email: mmorrow@cisco.com 2759 Adrian Farrel 2760 Old Dog Consulting 2761 EMail: adrian@olddog.co.uk 2763 Intellectual Property 2765 The IETF takes no position regarding the validity or scope of any 2766 Intellectual Property Rights or other rights that might be claimed 2767 to pertain to the implementation or use of the technology described 2768 in this document or the extent to which any license under such 2769 rights might or might not be available; nor does it represent that 2770 it has made any independent effort to identify any such rights. 2771 Information on the procedures with respect to rights in RFC 2772 documents can be found in BCP 78 and BCP 79. 2774 Copies of IPR disclosures made to the IETF Secretariat and any 2775 assurances of licenses to be made available, or the result of an 2776 attempt made to obtain a general license or permission for the use 2777 of such proprietary rights by implementers or users of this 2778 specification can be obtained from the IETF on-line IPR repository 2779 at http://www.ietf.org/ipr. 2781 The IETF invites any interested party to bring to its attention any 2782 copyrights, patents or patent applications, or other proprietary 2783 rights that may cover technology that may be required to implement 2785 Fang, et al. Informational 55 2786 MPLS/GMPLS Security framework 2787 February 2008 2789 this standard. Please address the information to the IETF at ietf- 2790 ipr@ietf.org. 2792 Full Copyright Statement 2794 Copyright (C) The IETF Trust (2008). 2796 This document is subject to the rights, licenses and restrictions 2797 contained in BCP 78, and except as set forth therein, the authors 2798 retain all their rights. 2800 This document and the information contained herein are provided on 2801 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2802 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2803 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2804 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2805 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2806 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2807 FOR A PARTICULAR PURPOSE. 2809 Intellectual Property 2811 The IETF takes no position regarding the validity or scope of any 2812 Intellectual Property Rights or other rights that might be claimed 2813 to pertain to the implementation or use of the technology described 2814 in this document or the extent to which any license under such 2815 rights might or might not be available; nor does it represent that 2816 it has made any independent effort to identify any such rights. 2817 Information on the procedures with respect to rights in RFC 2818 documents can be found in BCP 78 and BCP 79. 2820 Copies of IPR disclosures made to the IETF Secretariat and any 2821 assurances of licenses to be made available, or the result of an 2822 attempt made to obtain a general license or permission for the use 2823 of such proprietary rights by implementers or users of this 2824 specification can be obtained from the IETF on-line IPR repository 2825 at http://www.ietf.org/ipr. 2827 The IETF invites any interested party to bring to its attention any 2828 copyrights, patents or patent applications, or other proprietary 2829 rights that may cover technology that may be required to implement 2830 this standard. Please address the information to the IETF at ietf- 2831 ipr@ietf.org. 2833 Fang, et al. Informational 56 2834 MPLS/GMPLS Security framework 2835 February 2008 2837 15. Acknowledgements 2839 Funding for the RFC Editor function is provided by the IETF 2840 Administrative Support Activity (IASA). 2842 The authors and contributors would also like to acknowledge the 2843 helpful comments and suggestions from Sam Hartman and Dimitri 2844 Papadimitriou. 2846 Fang, et al. Informational 57