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