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