idnits 2.17.1 draft-fang-mpls-tp-security-framework-02.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 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5654], [RFC5921], [FRC5920]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 12, 2010) is 5008 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FRC 5920' is mentioned on line 30, but not defined == Unused Reference: 'RFC 3871' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 876, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luyuan Fang 3 Internet Draft Cisco Systems 4 Intended status: Informational Ben Niven-Jenkins 5 Expires: January 12, 2011 Velocix 6 Raymond Zhang 7 BT 8 Nabil Bitar 9 Verizon 11 July 12, 2010 13 Security Framework for MPLS-TP 14 draft-fang-mpls-tp-security-framework-02.txt 16 Abstract 18 This document provides a security framework for Multiprotocol Label 19 Switching Transport Profile (MPLS-TP). MPLS-TP Requirements and 20 MPLS-TP Framework are defined in [RFC 5654] and [RFC 5921]. 21 Extended from MPLS technologies, MPLS-TP introduces new OAM 22 capabilities, transport oriented path protection mechanism, and 23 strong emphasis on static provisioning supported by network 24 management systems. This document addresses the security aspects 25 that are relevant in the context of MPLS-TP specifically. It 26 describes the security requirements for MPLS-TP; potential 27 securities threats and migration procedures for MPLS-TP networks 28 and MPLS-TP inter-connection to MPLS, GMPLS networks. The general 29 security analysis and guidelines for MPLS and GMPLS are addressed 30 in [FRC 5920], will not be covered in this document. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with 35 the provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other documents 44 at any time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 MPLS-TP Security framework 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on January 12, 2011. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents in effect on the date of 63 publication of this document (http://trustee.ietf.org/license-info). 64 Please review these documents carefully, as they describe your 65 rights and restrictions with respect to this document. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with 72 respect to this document. Code Components extracted from this 73 document must include Simplified BSD License text as described in 74 Section 4.e of the Trust Legal Provisions and are provided without 75 warranty as described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction..............................................3 80 1.1. Background and Motivation..............................3 81 1.2. Scope..................................................4 82 1.3. Terminology............................................5 83 1.4. Structure of the document..............................6 84 2. Security Reference Models.................................6 85 2.1. Security Reference Model 1.............................7 86 2.2. Security Reference Model 2.............................8 87 3. Security Requirements for MPLS-TP........................11 88 3.1. Protection within the MPLS-TP Network ................11 89 4. Security Threats.........................................13 90 4.1. Attacks on the Control Plane..........................15 91 MPLS-TP Security framework 92 4.2. Attacks on the Data Plane.............................15 93 5. Defensive Techniques for MPLS-TP Networks ...............16 94 5.1. Authentication .......................................16 95 5.2. Access Control Techniques.............................17 96 5.3. Use of Isolated Infrastructure........................18 97 5.4. Use of Aggregated Infrastructure......................18 98 5.5. Service Provider Quality Control Processes............18 99 5.6. Verification of Connectivity..........................18 100 6. Monitoring, Detection, and Reporting of Security Attacks.18 101 7. Security Considerations..................................19 102 8. IANA Considerations......................................19 103 9. Normative References.....................................19 104 10. Informative References.................................20 105 11. Author's Addresses.....................................20 107 Requirements Language 109 Although this document is not a protocol specification, the key 110 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 112 this document are to be interpreted as described in RFC 2119 [RFC 113 2119]. 115 1. Introduction 117 1.1. Background and Motivation 119 This document provides a security framework for Multiprotocol Label 120 Switching Transport Profile (MPLS-TP). 122 MPLS-TP Requirements and MPLS-TP Framework are defined in [RFC 123 5654] and [RFC 5921]. The intent of MPLS-TP development is to 124 address the needs for transport evolution, the fast growing 125 bandwidth demand accelerated by new packet based services and 126 multimedia applications, from Ethernet Services, Layer 2 and Layer 127 3 VPNS, triple play to Mobile Access Network (RAN) backhaul, etc. 128 MPLS-TP is based on MPLS technologies to take advantage of the 129 technology maturity, and it is required to maintain the transport 130 characteristics. 132 Focused on meeting the transport requirements, MPLS-TP uses a 133 subset of MPLS features, and introduces extensions to reflect the 134 transport technology characteristics. The added functionalities 135 MPLS-TP Security framework 136 include in-band OAM, transport oriented path protection and 137 recovery mechanisms, etc. There is strong emphasis on static 138 provisioning supported by Network Management System (NMS) or 139 Operation Support System (OSS). Of course, there are needs for 140 MPLS-TP and MPLS interworking. 142 The security aspects for the new extensions which are particularly 143 designed for MPLS-TP need to be addressed. The security models, 144 requirements, threat and defense techniques previously defined in 145 [RFC 5920] can be used for the re-use of the existing 146 functionalities in MPLS and GMPLS, but not sufficient to cover the 147 new extensions. 149 1.2. Scope 151 This document addresses the security aspects that are specific to 152 MPLS-TP. It intends to provide the security requirements for MPLS- 153 TP; defines security models which apply to various MPLS-TP 154 deployment scenarios; identifies the potential securities threats 155 and migration procedures for MPLS-TP networks and MPLS-TP inter- 156 connection to MPLS, GMPLS networks. Inter-AS and Inter-provider 157 security for MPLS-TP to MPLS-TP connections or MPLS-TP to MPLS 158 connections are discussed, where connections present higher 159 security risk factors than connections for Intra-AS MPLS-TP. 161 The general security analysis and guidelines for MPLS and GMPLS are 162 addressed in [RFC 5920], the content which has no new impact to 163 MPLS-TP will not be repeated in this document. Other general 164 security issues regarding transport networks but not specific to 165 MPLS-TP is out of scope as well. Readers may also refer to the 166 "Security Best Practices Efforts and Documents" [opsec effort] and 167 "Security Mechanisms for the Internet" [RFC3631] (if there are 168 linkage to internet in the applications) for general network 169 operation security considerations. This document does not intend to 170 define the specific mechanisms/methods which must be implemented to 171 satisfy the security requirements. 173 Issues/Areas to be addressed: 175 G-Ach (control plane attack, DoS attack, message intercept, etc.) 176 Spoofing ID 177 Loopback 178 NMS attack 179 NMS and CP interaction 180 MIP/MEP assignment and attacks 181 Topology discovery 182 Data plane authentication 184 MPLS-TP Security framework 185 Label authentication 186 DoS attack in Data Plane 187 Performance Monitoring 189 This draft is work in progress. 191 1.3. Terminology 193 This document uses MPLS, MPLS-TP, and Security specific 194 terminology. Detailed definitions and additional terminology for 195 MPLS-TP may be found in [RFC 5654], [RFC 5921], and MPLS/GMPLS 196 security related terminology in [RFC 5920]. 198 Term Definition 200 ---------------------------------------------------- 201 APS Automatic Protection Switching 202 ATM Asynchronous Transfer Mode 203 BFD Bidirectional Forwarding Detection 204 CE Customer-Edge device 205 CM Configuration Management 206 CoS Class of Service 207 CPU Central Processing Unit 208 DNS Domain Name System 209 DoS Denial of Service 210 EMF Equipment Management Function 211 ESP Encapsulating Security Payload 212 FEC Forwarding Equivalence Class 213 FM Fault Management 214 GAL Generic Alert Label 215 G-ACH Generic Associated Channel 216 GMPLS Generalized Multi-Protocol Label Switching 217 GCM Galois Counter Mode 218 IKE Internet Key Exchange 219 LDP Label Distribution Protocol 220 LMP Link Management Protocol 221 LSP Label Switched Path 222 MD5 Message Digest Algorithm 223 MEP Maintenance End Point 224 MIP Maintenance Intermediate Point 225 MPLS MultiProtocol Label Switching 226 NTP Network Time Protocol 227 OAM Operations, Administration, and Management 228 PE Provider-Edge device 229 PM Performance Management 230 PSN Packet-Switched Network 232 MPLS-TP Security framework 233 PW Pseudowire 234 QoS Quality of Service 235 RSVP Resource Reservation Protocol 236 RSVP-TE Resource Reservation Protocol with Traffic Engineering 237 Extensions 238 SCC Signaling Communication Channel 239 SDH Synchronous Digital Hierarchy 240 SLA Service Level Agreement 241 SNMP Simple Network Management Protocol 242 SONET Synchronous Optical Network 243 S-PE Switching Provider Edge 244 SRLG Shared Risk Link Group 245 SSH Secure Shell 246 SSL Secure Sockets Layer 247 SYN Synchronize packet in TCP 248 TCP Transmission Control Protocol 249 TDM Time Division Multiplexing 250 TE Traffic Engineering 251 TLS Transport Layer Security 252 TTL Time-To-Live 253 T-PE Terminating Provider Edge 254 UDP User Datagram Protocol 255 VPN Virtual Private Network 256 WG Working Group of IETF 257 WSS Web Services Security 259 1.4. Structure of the document 261 Section 1: Introduction 262 Section 2: MPLS-TP Security Reference Models 263 Section 3: Security Requirements 264 Section 4: Security threats 265 Section 5: Defensive/mitigation techniques/procedures 267 Note that this document is currently work in progress, not all 268 requirements and security discussions are included, and some 269 sections will be filled in later revision. 271 2. Security Reference Models 273 This section defines a reference model for security in MPLS-TP 274 networks. 276 The models are built on the architecture of MPLS-TP defined in [RFC 277 5921]. The SP boundaries play the important role to determine the 278 security models for any particular deployment. 280 MPLS-TP Security framework 281 This document defines the zone where the single SP has the total 282 operational control to be a trusted zone for that SP. A primary 283 concern is about security aspects that relate to breaches of 284 security from the "outside" of a trusted zone to the "inside" of 285 this zone. 287 2.1. Security Reference Model 1 289 In the reference model 1, a single SP has the total control of 290 PE/T-PE to PE/T-PE of the MPLS-TP network. 292 Security reference model 1(a): 294 MPLS-TP network with Single Segment Pseudowire (SS-PW) from PE to 295 PE. The trusted zone is PE1 to PE2 as illustrated in Figure 1. 297 |<-------------- Emulated Service ---------------->| 298 | | 299 | |<------- Pseudo Wire ------>| | 300 | | | | 301 | | |<-- PSN Tunnel -->| | | 302 | V V V V | 303 V AC +----+ +----+ AC V 304 +-----+ | | PE1|==================| PE2| | +-----+ 305 | |----------|............PW1.............|----------| | 306 | CE1 | | | | | | | | CE2 | 307 | |----------|............PW2.............|----------| | 308 +-----+ ^ | | |==================| | | ^ +-----+ 309 ^ | +----+ +----+ | | ^ 310 | | Provider Edge 1 Provider Edge 2 | | 311 | | | | 312 Customer | | Customer 313 Edge 1 | | Edge 2 314 | | 315 Native service Native service 317 ----Untrusted--- >|<------- Trusted Zone ----- >|<---Untrusted---- 319 Figure 1: MPLS-TP Security Model 1 (a) 321 Security reference model 1(b): 323 MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to 324 T-PE. The trusted zone is T-PE1 to T-PE2 in this model as 325 illustrated in Figure 2. 327 MPLS-TP Security framework 328 Native |<------------Pseudowire-------------->| Native 329 Service | PSN PSN | Service 330 (AC) | |<--cloud->| |<-cloud-->| | (AC) 331 | V V V V V V | 332 | +----+ +-----+ +----+ | 333 +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ 334 | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | 335 | CE1| | | | | | | | | |CE2 | 336 | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | 337 +----+ | | |===========| |==========| | | +----+ 338 ^ +----+ ^ +-----+ ^ +----+ ^ 339 | | | | 340 | TP LSP TP LSP | 341 | | 342 | | 343 |<---------------- Emulated Service ----------------->| 345 -Untrusted >|<----------- Trusted Zone ---------- >|< Untrusted- 347 Figure 2: MPLS-TP Security Model 2 (b) 349 2.2. Security Reference Model 2 351 In the reference model 2, a single SP does not have the total 352 control of PE/T-PE to PE/T-PE of the MPLS-TP network, S-PE and T-PE 353 may be owned by different SPs or SPs and their customers. The MPLS- 354 TP network is not contained in one trusted zone. 356 Security Reference Model 2(a) 358 MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from PE to 359 PE. The trusted zone is T-PE1 to S-PE, as illustrated in Figure 3. 361 Native |<------------Pseudowire-------------->| Native 362 Service | PSN PSN | Service 363 (AC) | || |<-cloud-->| | (AC) 364 | V V V V V V | 365 | +----+ +----+ +----+ | 366 +----+ | |TPE1|=========|SPE1|==========|TPE2| | +----+ 367 | |------|.....PW.Seg't1......PW.Seg't3.... .|-------| | 368 | CE1| | | | | | | | | |CE2 | 369 | |------|.....PW.Seg't2......PW.Seg't4..... |-------| | 370 +----+ | | |=========| |==========| | | +----+ 371 ^ +----+ ^ +----+ ^ +----+ ^ 372 | | | | 374 MPLS-TP Security framework 375 | TP LSP TP LSP | 376 | | 377 |<---------------- Emulated Service -------------->| 379 --Untrusted-- >|<-- Trusted Zone -->|< ------Untrusted-------- 381 Figure 3: MPLS-TP Security Model 2(a) 383 Security Reference Model 2(b) 385 MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from PE to 386 PE. The trusted zone is S-PE, as illustrated in Figure 3. 388 Native |<------------Pseudowire-------------->| Native 389 Service | PSN PSN | Service 390 (AC) | || |<-cloud-->| | (AC) 391 | V V V V V V | 392 | +----+ +----+ +----+ | 393 +----+ | |TPE1|=========|SPE1|==========|TPE2| | +----+ 394 | |------|.....PW.Seg't1......PW.Seg't3.... .|-------| | 395 | CE1| | | | | | | | | |CE2 | 396 | |------|.....PW.Seg't2......PW.Seg't4..... |-------| | 397 +----+ | | |=========| |==========| | | +----+ 398 ^ +----+ ^ +----+ ^ +----+ ^ 399 | | | | 400 | TP LSP TP LSP | 401 | | 402 |<---------------- Emulated Service -------------->| 404 --------Untrusted----------->|<--->|< ------Untrusted-------- 405 Trusted 406 Zone 408 Figure 4: MPLS-TP Security Model 2(b) 410 Security Reference Model 2(c): 412 MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from 413 different Service Providers with PW inter-provider connections. The 414 trusted zone is T-PE1 to S-PE3, as illustrated in Figure 5. 416 MPLS-TP Security framework 417 Native |<-------------------- PW15 --------------------->| Native 418 Layer | | Layer 419 Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service 420 (AC1) V V LSP V V LSP V V LSP V V (AC2) 421 +----+ +-+ +----+ +----+ +-+ +----+ 422 +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ 423 | | | |=========| |=========| |=========| | | | 424 |CE1|----|........PW1........|...PW3...|........PW5........|---|CE2| 425 | | | |=========| |=========| |=========| | | | 426 +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ 427 +----+ +-+ +----+ +----+ +-+ +----+ 429 |<- Subnetwork 123->| |<- Subnetwork XYZ->| 431 Untrusted->|<- Trusted Zone - >| <-------------Untrusted------------ 433 Figure 5: MPLS-TP Security Model 2(c) 435 The boundaries of a trust domain should be carefully defined when 436 analyzing the security properties of each individual network, as 437 illustrated from the above, the security boundaries determined 438 which model would be applied to the use case analysis. 440 A key requirement of MPLS-TP networks is that the security of the 441 trusted zone not be compromised by interconnecting the MPLS-TP, 442 MPLS core infrastructure with another provider's core or T-PE 443 devices, or end users. 445 In addition, neighbors may be trusted or untrusted. Neighbors may 446 be authorized or unauthorized. Even though a neighbor may be 447 authorized for communication, it may not be trusted. For example, 448 when connecting with another provider's S-PE to set up Inter-AS 449 LSPs, the other provider is considered an untrusted but may be 450 authorized neighbor. 452 +---------------+ +----------------+ 453 | | | | 454 | MPLS-TP S-PE1----S-PE3 MPLS-TP | 455 CE1---S-PE1 Network | | Network T-PE2--CE2 456 | Provider A S-PE2----S-PE4 Provider B | 457 | | | | 458 +---------------+ +----------------+ 460 MPLS-TP Security framework 462 For Provider A: 463 Trusted Zone: Provider A MPLS-TP network 464 Trusted neighbors: T-PE1, S-PE1, S-PE2 465 Authorized but untrusted neighbor: provider B 466 Unauthorized neighbors: CE2 468 Figure 5. MPLS-TP trusted zone and authorized neighbor. 470 3. Security Requirements for MPLS-TP 472 This section covers security requirements for securing MPLS-TP 473 network infrastructure. The MPLS-TP network can be operated without 474 control plane or via dynamic control planes protocols. The security 475 requirements related to new MPLS-TP OAM, recovery mechanisms, MPLS- 476 TP and MPLS interconnection, and MPLS-TP specific operational 477 requirements will be addressed in this section. 479 A service provider may choose the implementation options which are 480 best fit for his/her network operation. This document does not 481 state that a MPLS/GMPLS network must fulfill all security 482 requirements listed to be secure. 484 These requirements are focused on: 1) how to protect the MPLS-TP 485 network from various attacks originating outside the trusted zone 486 including those from network users, both accidentally and 487 maliciously; 2) prevention of operational errors resulted from 488 misconfiguration within the trusted zone. 490 3.1. Protection within the MPLS-TP Network 491 MPLS-TP Security framework 492 - MPLS-TP MUST support the physical and logical separation of 493 data plane from the control plane and management plane. That 494 is, if the control plane or/and management plane are attached 495 and cannot function normally, the data plane should continue 496 to forward packets without being impacted. 498 - MPLS-TP MUST support static provisioning of MPLS-TP LSP and PW 499 with or without NMS/OSS, without using control protocols. This 500 is particularly important in the case of security model 2(a) 501 and 2(b) where the some or all T-PEs are not in the trusted 502 zone, and in the inter-provider cases in security model 2(c) 503 when the connecting S-PE is in the untrusted zone. 505 - MPLS-TP MUST support non-IP path options in addition to IP 506 loopback option. Non-IP path option used in the model 2 may 507 help to lower the potential risk of the S-PE/T-PE in the 508 trusted zone to be attacked. 510 - MPLS-TP MUST support authentication of the any control 511 protocol used for MPLS-TP network, as well as MPLS-TP network 512 to dynamic MPLS network inter-connection. 514 - MPLS-TP MUST support mechanisms to prevent DOS attack through 515 in-band OAM G-ACh/GAL. 517 - MPLS-TP MUST support hiding of the Service Provider 518 infrastructure for all reference models regardless using 519 static configuration or dynamic control plane. 521 - Security management requirements [MPLS-TP NM REQ]: 523 o MPLS-TP must support management communication channel 524 security secure communication channels MUST be supported 525 for all network traffic and protocols used to support 526 management functions. This MUST include protocols used 527 for configuration, monitoring, configuration backup, 528 logging, time synchronization, authentication, and 529 routing. The MCC MUST support application protocols that 530 provide confidentiality and data integrity protection. 531 Support the use of open cryptographic algorithms [RFC 532 3871]; Authentication - allow management connectivity and 533 activity only from authenticated entities, and port 534 access control. 535 o Distributed Denial of Service: It is possible to lessen 536 the impact and potential for DoS and DDoS by using secure 537 protocols, turning off unnecessary processes, logging and 539 MPLS-TP Security framework 540 monitoring, and ingress filtering. [RFC 4732] provides 541 background on DOS in the context of the Internet. 543 (more to be added) 545 - Protection of Operational error 547 Due to the extensive use of static provisioning with or 548 without NMS and OSS, the prevention of configuration errors 549 should be addressed as major security requirements. 551 (to be added) 553 4. Security Threats 555 This section discusses the various network security threats that 556 may endanger MPLS-TP networks. The discussion is limited to those 557 threats that are unique to MPLS-TP networks or that affect MPLS-TP 558 network in unique ways. 560 A successful attack on a particular MPLS-TP network or on a SP's 561 MPLS-TP infrastructure may cause one or more of the following ill 562 effects: 564 1. Observation, modification, or deletion of a provider's or 565 user's data, as well as replay or insertion of inauthentic data 566 into a provider's or user's data stream, traffic pattern 567 analysis. 569 These types of attacks apply to MPLS-TP traffic in a similar way 570 of MPLS traffic regardless how the LSP is set up. 572 2. Attacks on GAL label, BFD messages: 573 1) GAL label or BFD label manipulation: including insertion of 574 false label or messages, or modification, or removal the GAL labels 575 or messages by attackers. 576 2) DOS attack through in-band OAM G-ACH/GAL, and BFD messages. 578 3. Disruption of a provider's and/or user's connectivity, or 579 degradation of a provider's service quality. 581 1) Provider connectivity attacks: 582 - In the case of NMS is used for LSP set-up, the attacks would 583 be through the attack of NMS. 585 MPLS-TP Security framework 586 - In the case of dynamic is used for dynamic provisioning, the 587 attack would be on dynamic control plane. Most aspects are 588 addressed in [RFC 5920]. 590 2) User connectivity attack. This would be similar as PE/CE 591 access attack in typical MPLS networks, addressed in [RFC 5920]. 593 4. Probing a provider's network to determine its configuration, 594 capacity, or usage. 596 These types of attack can happen through NMS attacks in the case 597 of static provisioning, or through control plane attacks as in 598 dynamic MPLS networks. It can also be combined attacks. 600 It is useful to consider that threats, whether malicious or 601 accidental, may come from different categories of sources. For 602 example they may come from: 604 - Other users whose services are provided by the same MPLS-TP 605 core. 606 - The MPLS-TP SP or persons working for it. 607 - Other persons who obtain physical access to a MPLS-TP SP's site. 608 - Other persons who use social engineering methods to influence 609 the behavior of a SP's personnel. 610 - Users of the MPLS-TP network itself. 611 - Others, e.g., attackers from the other sources, Internet if 612 connected. 613 - Other SPs in the case of MPLS-TP Inter-provider connection. The 614 provider may or may not be using MPLS-TP. 615 - Those who create, deliver, install, and maintain software for 616 network equipment. 618 Given that security is generally a tradeoff between expense and 619 risk, it is also useful to consider the likelihood of different 620 attacks occurring. There is at least a perceived difference in the 621 likelihood of most types of attacks being successfully mounted in 622 different environments, such as: 624 - A MPLS-TP network inter-connecting with another provider's core 625 - A MPLS-TP configuration transiting the public Internet 627 Most types of attacks become easier to mount and hence more likely 628 as the shared infrastructure via which service is provided expands 629 from a single SP to multiple cooperating SPs to the global 630 Internet. Attacks that may not be of sufficient likeliness to 631 warrant concern in a closely controlled environment often merit 632 defensive measures in broader, more open environments. In closed 633 MPLS-TP Security framework 634 communities, it is often practical to deal with misbehavior after 635 the fact: an employee can be disciplined, for example. 637 The following sections discuss specific types of exploits that 638 threaten MPLS-TP networks. 640 4.1. Attacks on the Control Plane 642 - MPLS-TP LSP creation by an unauthorized element 644 - LSP message interception 646 - Attacks on G-Ach 648 - Attacks against LDP 650 - Attacks against RSVP-TE 652 - Attacks against GMPLS 654 - Denial of Service Attacks on the Network Infrastructure 656 - Attacks on the SP's MPLS/GMPLS Equipment via Management 657 Interfaces 658 - Social Engineering Attacks on the SP's Infrastructure 659 - Cross-Connection of Traffic between Users 660 - Attacks against Routing Protocols 661 - Other Attacks on Control Traffic 663 4.2. Attacks on the Data Plane 665 This category encompasses attacks on the provider's or end user's 666 data. Note that from the MPLS-TP network end user's point of view, 667 some of this might be control plane traffic, e.g. routing protocols 668 running from user site A to user site B via IP or non-IP 669 connections, which may be some type of VPN. 671 - Unauthorized Observation of Data Traffic 673 - Modification of Data Traffic 675 - Insertion of Inauthentic Data Traffic: Spoofing and Replay 677 - Unauthorized Deletion of Data Traffic 678 MPLS-TP Security framework 679 - Unauthorized Traffic Pattern Analysis 681 - Denial of Service Attacks 683 - Misconnection 685 5. Defensive Techniques for MPLS-TP Networks 687 The defensive techniques discussed in this document are intended to 688 describe methods by which some security threats can be addressed. 689 They are not intended as requirements for all MPLS-TP 690 implementations. The MPLS-TP provider should determine the 691 applicability of these techniques to the provider's specific 692 service offerings, and the end user may wish to assess the value of 693 these techniques to the user's service requirements. The 694 operational environment determines the security requirements. 695 Therefore, protocol designers need to provide a full set of 696 security services, which can be used where appropriate. 698 The techniques discussed here include encryption, authentication, 699 filtering, firewalls, access control, isolation, aggregation, and 700 others. 702 5.1. Authentication 704 To prevent security issues arising from some DoS attacks or from 705 malicious or accidental misconfiguration, it is critical that 706 devices in the MPLS-TP should only accept connections or control 707 messages from valid sources. Authentication refers to methods to 708 ensure that message sources are properly identified by the MPLS-TP 709 devices with which they communicate. This section focuses on 710 identifying the scenarios in which sender authentication is 711 required and recommends authentication mechanisms for these 712 scenarios. 714 5.1.1. Management System Authentication 716 Management system authentication includes the authentication of a 717 PE to a centrally-managed network management or directory server 718 when directory-based "auto-discovery" is used. It also includes 719 authentication of a CE to the configuration server, when a 720 configuration server system is used. 722 Authentication should be bi-directional, including PE or CE to 723 configuration server authentication for PE or CE to be certain it 724 is communicating with the right server. 726 MPLS-TP Security framework 728 5.1.2. Peer-to-Peer Authentication 730 Peer-to-peer authentication includes peer authentication for 731 network control protocols and other peer authentication (i.e., 732 authentication of one IPsec security gateway by another). 734 Authentication should be bi-directional, including S-PE, T-PE, PE 735 or CE to configuration server authentication for PE or CE to be 736 certain it is communicating with the right server. 738 5.1.3. Cryptographic Techniques for Authenticating Identity 740 Cryptographic techniques offer several mechanisms for 741 authenticating the identity of devices or individuals. These 742 include the use of shared secret keys, one-time keys generated by 743 accessory devices or software, user-ID and password pairs, and a 744 range of public-private key systems. Another approach is to use a 745 hierarchical Certification Authority system to provide digital 746 certificates. 748 5.2. Access Control Techniques 750 - Access Control to Management Interfaces 752 Most of the security issues related to management interfaces can be 753 addressed through the use of authentication techniques as described 754 in the section on authentication. However, additional security may 755 be provided by controlling access to management interfaces in other 756 ways. 758 The Optical Internetworking Forum has done relevant work on 759 protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, 760 etc. See OIF-SMI-01.0 "Security for Management Interfaces to 761 Network Elements" [OIF-SMI-01.0], and "Addendum to the Security for 762 Management Interfaces to Network Elements" [OIF-SMI-02.1]. See also 763 the work in the ISMS WG. 765 Management interfaces, especially console ports on MPLS-TP devices, 766 may be configured so they are only accessible out-of-band, through 767 a system which is physically or logically separated from the rest 768 of the MPLS-TP infrastructure. 770 Where management interfaces are accessible in-band within the MPLS- 771 TP domain, filtering or firewalling techniques can be used to 772 restrict unauthorized in-band traffic from having access to 773 management interfaces. Depending on device capabilities, these 774 MPLS-TP Security framework 775 filtering or firewalling techniques can be configured either on 776 other devices through which the traffic might pass, or on the 777 individual MPLS-TP devices themselves. 779 5.3. Use of Isolated Infrastructure 781 One way to protect the infrastructure used for support of MPLS-TP 782 is to separate the resources for support of MPLS-TP services from 783 the resources used for other purposes 785 5.4. Use of Aggregated Infrastructure 787 In general, it is not feasible to use a completely separate set of 788 resources for support of each service. In fact, one of the main 789 reasons for MPLS-TP enabled services is to allow sharing of 790 resources between multiple services and multiple users. Thus, even 791 if certain services use a separate network from Internet services, 792 nonetheless there will still be multiple MPLS-TP users sharing the 793 same network resources. 795 In general, the use of aggregated infrastructure allows the service 796 provider to benefit from stochastic multiplexing of multiple bursty 797 flows, and also may in some cases thwart traffic pattern analysis 798 by combining the data from multiple users. However, service 799 providers must minimize security risks introduced from any 800 individual service or individual users. 802 5.5. Service Provider Quality Control Processes 804 5.6. Verification of Connectivity 806 In order to protect against deliberate or accidental misconnection, 807 mechanisms can be put in place to verify both end-to-end 808 connectivity and hop-by-hop resources. These mechanisms can trace 809 the routes of LSPs in both the control plane and the data plane. 811 6. Monitoring, Detection, and Reporting of Security Attacks 813 MPLS-TP network and service may be subject to attacks from a 814 variety of security threats. Many threats are described in Section 815 3 of this document. Many of the defensive techniques described in 816 this document and elsewhere provide significant levels of 817 protection from a variety of threats. However, in addition to 818 employing defensive techniques silently to protect against attacks, 819 MPLS-TP services can also add value for both providers and 820 MPLS-TP Security framework 821 customers by implementing security monitoring systems to detect and 822 report on any security attacks, regardless of whether the attacks 823 are effective. 825 Attackers often begin by probing and analyzing defenses, so systems 826 that can detect and properly report these early stages of attacks 827 can provide significant benefits. 829 Information concerning attack incidents, especially if available 830 quickly, can be useful in defending against further attacks. It 831 can be used to help identify attackers or their specific targets at 832 an early stage. This knowledge about attackers and targets can be 833 used to strengthen defenses against specific attacks or attackers, 834 or to improve the defenses for specific targets on an as-needed 835 basis. Information collected on attacks may also be useful in 836 identifying and developing defenses against novel attack types. 838 7. Security Considerations 840 Security considerations constitute the sole subject of this memo 841 and hence are discussed throughout. 843 The document describes a variety of defensive techniques that may 844 be used to counter the suspected threats. All of the techniques 845 presented involve mature and widely implemented technologies that 846 are practical to implement. 848 The document evaluates MPLS-TP security requirements from a 849 customer's perspective as well as from a service provider's 850 perspective. These sections re-evaluate the identified threats 851 from the perspectives of the various stakeholders and are meant to 852 assist equipment vendors and service providers, who must ultimately 853 decide what threats to protect against in any given configuration 854 or service offering. 856 8. IANA Considerations 858 This document contains no new IANA considerations. 860 9. Normative References 862 [RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements", RFC 863 5654, September 2009. 865 MPLS-TP Security framework 867 [RFC 3871] Jones, G., "Operational Security Requirements for Large 868 Internet Service Provider (ISP) IP Network Infrastructure", RFC 869 3871, September 2004. 871 [RFC 4732] Handley, M., et al, "Internet Denial-of-Service 872 Considerations", RFC 4732, November 2006. 874 10. Informative References 876 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, March 1997 879 [OIF-SMI-01.0] Renee Esposito, "Security for Management Interfaces 880 to Network Elements", Optical Internetworking Forum, Sept. 2003. 882 [OIF-SMI-02.1] Renee Esposito, "Addendum to the Security for 883 Management Interfaces to Network Elements", Optical Internetworking 884 Forum, March 2006. 886 [RFC3631] S. Bellovin, C. Kaufman, J. Schiller, "Security 887 Mechanisms for the Internet," December 2003. 889 [MFA MPLS ICI] N. Bitar, "MPLS InterCarrier Interconnect Technical 890 Specification", IP/MPLS Forum 19.0.0, April 2008. 892 [RFC 5921] Bocci, M., Bryant, et al., "A Framework for MPLS in 893 Transport Networks", July 2010. 895 [opsec efforts] C. Lonvick and D. Spak, "Security Best Practices 896 Efforts and Documents", draft-ietf-opsec-efforts-08.txt, June 2008. 898 [RFC 5920] L. Fang, et al, Security Framework for MPLS and GMPLS 899 Networks, July 2010. 901 [MPLS-TP NM REQ] Hing-Kam Lam, Scott Mansfield, Eric Gray, MPLS TP 902 Network Management Requirements, draft-ietf-mpls-tp-nm-req-06.txt, 903 October 2009. 905 11. Author's Addresses 907 Luyuan Fang 908 Cisco Systems, Inc. 909 300 Beaver Brook Road 910 Boxborough, MA 01719 911 USA 912 MPLS-TP Security framework 913 Email: lufang@cisco.com 915 Ben Niven-Jenkins 916 Velocix 917 326 Cambridge Science Park 918 Milton Road, 919 Cambridge 920 CB4 0WG, UK 922 Email: ben@niven-jenkins.co.uk 924 Raymond Zhang 925 British Telecom 926 BT Center 927 81 Newgate Street 928 London, EC1A 7AJ 929 United Kingdom 930 Email: raymond.zhang@bt.com 932 Nabil Bitar 933 Verizon 934 40 Sylvan Road 935 Waltham, MA 02145 936 USA 937 Email: nabil.bitar@verizon.com