idnits 2.17.1 draft-fang-mpls-tp-security-framework-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (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 : ---------------------------------------------------------------------------- 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 date (November 10, 2010) is 4909 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Fang, Ed. 3 Internet-Draft Cisco Systems Inc. 4 Intended status: Informational B. Niven-Jenkins, Ed. 5 Expires: May 14, 2011 Velocix 6 S. Mansfield, Ed. 7 Ericsson 8 R. Zhang 9 British Telecom 10 N. Bitar 11 Verizon 12 M. Daikoku 13 KDDI Corporation 14 L. Wang 15 Telenor 16 November 10, 2010 18 MPLS-TP Security Framework 19 draft-fang-mpls-tp-security-framework-04 21 Abstract 23 This document provides a security framework for Multiprotocol Label 24 Switching Transport Profile (MPLS-TP). Extended from MPLS 25 technologies, MPLS-TP introduces new OAM capabilities, transport 26 oriented path protection mechanism, and strong emphasis on static 27 provisioning supported by network management systems. This document 28 addresses the security aspects that are relevant in the context of 29 MPLS-TP specifically. It describes the security requirements for 30 MPLS-TP; potential securities threats and migration procedures for 31 MPLS-TP networks and MPLS-TP inter-connection to MPLS and GMPLS 32 networks. 34 This document is a product of a joint Internet Engineering Task Force 35 (IETF) / International Telecommunication Union Telecommunication 36 Standardization Sector (ITU-T) effort to include an MPLS Transport 37 Profile within the IETF MPLS and PWE3 architectures to support the 38 capabilities and functionalities of a packet transport network. 40 This Informational Internet-Draft is aimed at achieving IETF 41 Consensus before publication as an RFC and will be subject to an IETF 42 Last Call. 44 [RFC Editor, please remove this note before publication as an RFC and 45 insert the correct Streams Boilerplate to indicate that the published 46 RFC has IETF Consensus.] 48 Status of this Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on May 14, 2011. 64 Copyright Notice 66 Copyright (c) 2010 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1. Background and Motivation . . . . . . . . . . . . . . . . 4 83 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.3. Requirement Language . . . . . . . . . . . . . . . . . . . 5 85 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 86 1.5. Structure of the document . . . . . . . . . . . . . . . . 7 87 2. Security Reference Models . . . . . . . . . . . . . . . . . . 7 88 2.1. Security Reference Model 1 . . . . . . . . . . . . . . . . 7 89 2.2. Security Reference Model 2 . . . . . . . . . . . . . . . . 9 90 2.3. Security Reference Model 3 . . . . . . . . . . . . . . . . 12 91 2.4. Trusted Zone Boundaries . . . . . . . . . . . . . . . . . 13 92 3. Security Requirements for MPLS-TP . . . . . . . . . . . . . . 14 93 4. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 16 94 4.1. Attacks on the Control Plane . . . . . . . . . . . . . . . 18 95 4.2. Attacks on the Data Plane . . . . . . . . . . . . . . . . 18 96 5. Defensive Techniques for MPLS-TP Networks . . . . . . . . . . 19 97 5.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 19 98 5.1.1. Management System Authentication . . . . . . . . . . . 19 99 5.1.2. Peer-to-Peer Authentication . . . . . . . . . . . . . 20 100 5.1.3. Cryptographic Techniques for Authenticating 101 Identity . . . . . . . . . . . . . . . . . . . . . . . 20 102 5.2. Access Control Techniques . . . . . . . . . . . . . . . . 20 103 5.3. Use of Isolated Infrastructure . . . . . . . . . . . . . . 21 104 5.4. Use of Aggregated Infrastructure . . . . . . . . . . . . . 21 105 5.5. Service Provider Quality Control Processes . . . . . . . . 21 106 5.6. Verification of Connectivity . . . . . . . . . . . . . . . 21 107 6. Monitoring, Detection, and Reporting of Security Attacks . . . 21 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 109 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 110 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 111 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 112 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 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 [RFC5654] 123 and [RFC5921] respectively. The intent of MPLS-TP development is to 124 address the needs for transport evolution, the fast growing bandwidth 125 demand accelerated by new packet based services and multimedia 126 applications, from Ethernet Services, Layer 2 and Layer 3 VPNS, 127 triple play to Mobile Access Network (RAN) backhaul, etc. MPLS-TP is 128 based on MPLS technologies to take advantage of the technology 129 maturity, and it is required to maintain the transport 130 characteristics. 132 Focused on meeting transport requirements, MPLS-TP uses a subset of 133 MPLS features, and introduces extensions to reflect the transport 134 technology characteristics. The added functionalities include in- 135 band OAM, transport oriented path protection and recovery mechanisms, 136 etc. There is strong emphasis on static provisioning supported by 137 Network Management System (NMS) or Operation Support System (OSS). 138 There are also needs for MPLS-TP and MPLS interworking. 140 The security aspects for the new extensions which are particularly 141 designed for MPLS-TP need to be addressed. The security models, 142 requirements, threat and defense techniques previously defined in 143 [RFC5921] can be used for the re-use of the existing functionalities 144 in MPLS and GMPLS, but not sufficient to cover the new extensions. 146 This document is a product of a joint Internet Engineering Task Force 147 (IETF) / International Telecommunication Union Telecommunication 148 Standardization Sector (ITU-T) effort to include an MPLS Transport 149 Profile within the IETF MPLS and PWE3 architectures to support the 150 capabilities and functionalities of a packet transport network. 152 1.2. Scope 154 This document addresses the security aspects that are specific to 155 MPLS-TP. It intends to provide the security requirements for 156 MPLS-TP; define security models which apply to various MPLS-TP 157 deployment scenarios; identify the potential security threats and 158 mitigation procedures for MPLS-TP networks and MPLS-TP inter- 159 connection to MPLS or GMPLS networks. Inter-AS and Inter-provider 160 security for MPLS-TP to MPLS-TP connections or MPLS-TP to MPLS 161 connections are discussed, where connections present higher security 162 risk factors than connections for Intra-AS MPLS-TP. 164 The general security analysis and guidelines for MPLS and GMPLS are 165 addressed in [RFC5920], the content which has no new impact to 166 MPLS-TP will not be repeated in this document. Other general 167 security issues regarding transport networks that are not specific to 168 MPLS-TP are also out of scope. Readers may also refer to the 169 "Security Best Practices Efforts and Documents" Opsec Effort 170 [opsec-efforts] and "Security Mechanisms for the Internet" [RFC3631] 171 (if there are linkages to the Internet in the applications) for 172 general network operation security considerations. This document 173 does not intend to define the specific mechanisms/methods that must 174 be implemented to satisfy the security requirements. 176 Issues/Areas to be addressed: 178 o G-Ach (control plane attack, DoS attack, message intercept, etc.) 180 o Spoofing ID 182 o Loopback 184 o NMS attack 186 o NMS and CP interaction 188 o MIP/MEP assignment and attacks 190 o Topology discovery 192 o Data plane authentication 194 o Label authentication 196 o DoS attack in Data Plane 198 o Performance Monitoring 200 1.3. Requirement Language 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. Although 205 this document is not a protocol specification, the use of this 206 language clarifies the instructions to protocol designers producing 207 solutions that satisfy the requirements set out in this document. 209 1.4. Terminology 211 This document uses MPLS, MPLS-TP, and Security specific terminology. 212 Detailed definitions and additional terminology for MPLS-TP may be 213 found in [RFC5654], [RFC5921], and MPLS/GMPLS security related 214 terminology in [RFC5920]. 216 o BFD: Bidirectional Forwarding Detection 218 o CE: Customer-Edge device 220 o DoS: Denial of Service 222 o DDoS: Distributed Denial of Service 224 o GAL: Generic Alert Label 226 o G-ACH: Generic Associated Channel 228 o GMPLS: Generalized Multi-Protocol Label Switching 230 o LDP: Label Distribution Protocol 232 o LSP: Label Switched Path 234 o MCC: Management Communication Channel 236 o MEP: Maintenance End Point 238 o MIP: Maintenance Intermediate Point 240 o MPLS: MultiProtocol Label Switching 242 o OAM: Operations, Administration, and Management 244 o PE: Provider-Edge device 246 o PSN: Packet-Switched Network 248 o PW: Pseudowire 250 o RSVP: Resource Reservation Protocol 252 o RSVP-TE: Resource Reservation Protocol with Traffic Engineering 253 Extensions 255 o S-PE: Switching Provider Edge 256 o SSH: Secure Shell 258 o TE: Traffic Engineering 260 o TLS: Transport Layer Security 262 o T-PE: Terminating Provider Edge 264 o VPN: Virtual Private Network 266 o WG: Working Group of IETF 268 o WSS: Web Services Security 270 1.5. Structure of the document 272 Section 1: Introduction 274 Section 2: MPLS-TP Security Reference Models 276 Section 3: Security Requirements 278 Section 4: Security Threats 280 Section 5: Defensive/Mitigation techniques/procedures 282 2. Security Reference Models 284 This section defines a reference model for security in MPLS-TP 285 networks. 287 The models are built on the architecture of MPLS-TP defined in 288 [RFC5921]. The Service Provider (SP) boundaries play an important 289 role in determining the security models for any particular 290 deployment. 292 This document defines a trusted zone as being where a single SP has 293 the total operational control over that part of the network. A 294 primary concern is about security aspects that relate to breaches of 295 security from the "outside" of a trusted zone to the "inside" of this 296 zone. 298 2.1. Security Reference Model 1 300 In the reference model 1, a single SP has total control of PE/T-PE to 301 PE/T-PE of the MPLS-TP network. 303 Security reference model 1(a) 305 An MPLS-TP network with Single Segment Pseudowire (SS-PW) from PE to 306 PE. The trusted zone is PE1 to PE2 as illustrated in MPLS-TP 307 Security Model 1 (a) (Figure 1). 309 |<-------------- Emulated Service ---------------->| 310 | | 311 | |<------- Pseudo Wire ------>| | 312 | | | | 313 | | |<-- PSN Tunnel -->| | | 314 | V V V V | 315 V AC +----+ +----+ AC V 316 +-----+ | | PE1|==================| PE2| | +-----+ 317 | |----------|............PW1.............|----------| | 318 | CE1 | | | | | | | | CE2 | 319 | |----------|............PW2.............|----------| | 320 +-----+ ^ | | |==================| | | ^ +-----+ 321 ^ | +----+ +----+ | | ^ 322 | | Provider Edge 1 Provider Edge 2 | | 323 | | | | 324 Customer | | Customer 325 Edge 1 | | Edge 2 326 | | 327 Native service Native service 329 ----Untrusted--- >|<------- Trusted Zone ----- >|<---Untrusted---- 331 MPLS-TP Security Model 1 (a) 333 Figure 1 335 Security reference model 1(b) 337 An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to 338 T-PE. The trusted zone is T-PE1 to T-PE2 in this model as 339 illustrated in MPLS-TP Security Model 1 (b) (Figure 2). 341 Native |<------------Pseudowire-------------->| Native 342 Service | PSN PSN | Service 343 (AC) | |<--cloud->| |<-cloud-->| | (AC) 344 | V V V V V V | 345 | +----+ +-----+ +----+ | 346 +----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+ 347 | |------|..... PW.Seg't1.........PW.Seg't3.....|-------| | 348 | CE1| | | | | | | | | |CE2 | 349 | |------|..... PW.Seg't2.........PW.Seg't4.....|-------| | 350 +----+ | | |===========| |==========| | | +----+ 351 ^ +----+ ^ +-----+ ^ +----+ ^ 352 | | | | 353 | TP LSP TP LSP | 354 | | 355 | | 356 |<---------------- Emulated Service ----------------->| 358 -Untrusted >|<----------- Trusted Zone ---------- >|< Untrusted- 360 MPLS-TP Security Model 1 (b) 362 Figure 2 364 2.2. Security Reference Model 2 366 In the reference model 2, a single SP does not have the total control 367 of PE/T-PE to PE/T-PE of the MPLS-TP network, S-PE and T-PE may be 368 under the control of different SPs or their customers or may not be 369 trusted for some other reason. The MPLS-TP network is not contained 370 within a single trusted zone. 372 Security Reference Model 2(a) 374 An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to 375 T-PE. The trusted zone is T-PE1 to S-PE, as illustrated in MPLS-TP 376 Security Model 2 (a) (Figure 3). 378 Native |<------------Pseudowire-------------->| Native 379 Service | PSN PSN | Service 380 (AC) | || |<-cloud-->| | (AC) 381 | V V V V V V | 382 | +----+ +----+ +----+ | 383 +----+ | |TPE1|=========|SPE1|==========|TPE2| | +----+ 384 | |------|.....PW.Seg't1......PW.Seg't3.... .|-------| | 385 | CE1| | | | | | | | | |CE2 | 386 | |------|.....PW.Seg't2......PW.Seg't4..... |-------| | 387 +----+ | | |=========| |==========| | | +----+ 388 ^ +----+ ^ +----+ ^ +----+ ^ 389 | | | | 390 | TP LSP TP LSP | 391 | | 392 |<---------------- Emulated Service -------------->| 394 --Untrusted-- >|<-- Trusted Zone -->|< ------Untrusted-------- 396 MPLS-TP Security Model 2 (a) 398 Figure 3 400 Security Reference Model 2(b) 402 An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE to 403 T-PE. The trusted zone is the S-PE, as illustrated in MPLS-TP 404 Security Model 2 (b) (Figure 4). 406 Native |<------------Pseudowire-------------->| Native 407 Service | PSN PSN | Service 408 (AC) | || |<-cloud-->| | (AC) 409 | V V V V V V | 410 | +----+ +----+ +----+ | 411 +----+ | |TPE1|=========|SPE1|==========|TPE2| | +----+ 412 | |------|.....PW.Seg't1......PW.Seg't3.... .|-------| | 413 | CE1| | | | | | | | | |CE2 | 414 | |------|.....PW.Seg't2......PW.Seg't4..... |-------| | 415 +----+ | | |=========| |==========| | | +----+ 416 ^ +----+ ^ +----+ ^ +----+ ^ 417 | | | | 418 | TP LSP TP LSP | 419 | | 420 |<---------------- Emulated Service -------------->| 422 --------Untrusted----------->|<--->|< ------Untrusted-------- 423 Trusted 424 Zone 426 MPLS-TP Security Model 2 (b) 428 Figure 4 430 Security Reference Model 2(c) 432 An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from 433 different Service Providers with inter-provider PW connections. The 434 trusted zone is T-PE1 to S-PE3, as illustrated in MPLS-TP Security 435 Model 2 (c) (Figure 5). 437 Native |<-------------------- PW15 --------------------->| Native 438 Layer | | Layer 439 Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service 440 (AC1) V V LSP V V LSP V V LSP V V (AC2) 441 +----+ +-+ +----+ +----+ +-+ +----+ 442 +---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+ 443 | | | |=========| |=========| |=========| | | | 444 |CE1|----|........PW1........|...PW3...|........PW5........|---|CE2| 445 | | | |=========| |=========| |=========| | | | 446 +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ 447 +----+ +-+ +----+ +----+ +-+ +----+ 449 |<- Subnetwork 123->| |<- Subnetwork XYZ->| 451 Untrusted->|<- Trusted Zone - >| <-------------Untrusted------------ 453 MPLS-TP Security Model 2 (c) 455 Figure 5 457 2.3. Security Reference Model 3 459 An MPLS-TP network with a Transport LSP from PE1 to PE2. The trusted 460 zone is PE1 to PE2 as illustrated in MPLS-TP Security Model 3 (a) 461 (Figure 6). 463 |<------------- Client Network Layer --------------->| 464 | | 465 | |<----------- Packet --------->| | 466 | | Transport Service | | 467 | | | | 468 | | | | 469 | | Transport | | 470 | | |<------ LSP ------->| | | 471 | V V V V | 472 V AC +----+ +-----+ +----+ AC V 473 +-----+ | | PE1|=======\ /========| PE2| | +-----+ 474 | |----------|..Svc LSP1.| \ / |............|----------| | 475 | CE1 | | | | | X | | | | | CE2 | 476 | |----------|..Svc LSP2.| / \ |............|----------| | 477 +-----+ ^ | | |=======/ \========| | | ^ +-----+ 478 ^ | +----+ ^ +-----+ +----+ | | ^ 479 | | Provider | ^ Provider | | 480 | | Edge 1 | | Edge 2 | | 481 Customer | | P Router | Customer 482 Edge 1 | TE LSP | Edge 2 483 | | 484 | | 485 Native service Native service 487 -----Untrusted---- >|< ----- Trusted Zone ----- >|<----Untrusted---- 489 MPLS-TP Security Model 3 (a) 491 Figure 6 493 2.4. Trusted Zone Boundaries 495 The boundaries of a trusted zone should be carefully defined when 496 analyzing the security properties of each individual network, as 497 illustrated from the above, the security boundaries determine which 498 reference model should be applied to the use case analysis. 500 A key requirement of MPLS-TP networks is that the security of the 501 trusted zone MUST NOT be compromised by interconnecting one SP's 502 MPLS-TP or MPLS infrastructure with another SP's core, T-PE devices, 503 or end users. 505 In addition, neighboring nodes in the network may be trusted or 506 untrusted. Neighbors may also be authorized or unauthorized. Even 507 though a neighbor may be authorized for communication, it may not be 508 trusted. For example, when connecting with another provider's S-PE 509 to set up Inter-AS LSPs, the other provider is considered to be 510 untrusted but may be authorized for communication. 512 +---------------+ +----------------+ 513 | | | | 514 | MPLS-TP S-PE1----S-PE3 MPLS-TP | 515 CE1--T-PE1 Network | | Network T-PE2--CE2 516 | Provider S-PE2----S-PE4 Provider | 517 | A | | B | 518 +---------------+ +----------------+ 520 For Provider A: 521 Trusted Zone: Provider A MPLS-TP network 522 Trusted neighbors: T-PE1, S-PE1, S-PE2 523 Authorized but untrusted neighbor: Provider B 524 Unauthorized neighbors: CE2 526 MPLS-TP trusted zone and authorized neighbor 528 Figure 7 530 3. Security Requirements for MPLS-TP 532 This section covers security requirements for securing MPLS-TP 533 network infrastructure. The MPLS-TP network can be operated without 534 a control plane or via dynamic control planes protocols. The 535 security requirements related to new MPLS-TP OAM, recovery 536 mechanisms, MPLS-TP and MPLS interconnection, and MPLS-TP specific 537 operational requirements will be addressed in this section. 539 A service provider may choose the implementation options which are 540 the best fit for his/her network operation. This document does not 541 state that a MPLS/GMPLS network must fulfill all security 542 requirements listed to be secure. 544 These requirements are focused on: 1) how to protect the MPLS-TP 545 network from various attacks originating outside the trusted zone 546 including those from network users, both accidental and malicious; 2) 547 prevention of operational errors resulting from misconfiguration 548 within the trusted zone. 550 o MPLS-TP MUST support the physical and logical separation of data 551 plane from the control plane and management plane. That is, if 552 the control plane or/and management plane are attacked and cannot 553 function normally, the data plane should continue to forward 554 packets without being impacted. 556 o MPLS-TP MUST support static provisioning of MPLS-TP LSP and PW 557 with or without NMS/OSS, without using control protocols. This is 558 particularly important in the case of security model 2(a) 559 (Figure 3) and security model 2(b) (Figure 4) where some or all 560 T-PEs are not in the trusted zone, and in the inter-provider cases 561 in security model 2(c) (Figure 5) when the connecting S-PE is in 562 the untrusted zone. 564 o MPLS-TP MUST support non-IP path options in addition to IP 565 loopback option. Non-IP path options when used in security model 566 2 (Section 2.2) may help to lower the potential risk of attack on 567 the S-PE/T-PE in the trusted zone. 569 o MPLS-TP MUST support authentication of any control protocol used 570 for an MPLS-TP network, as well as for MPLS-TP network to dynamic 571 MPLS network inter-connection. 573 o MPLS-TP MUST support mechanisms to prevent Denial of Service (DOS) 574 attacks via any in-band OAM or G-ACh/GAL. 576 o MPLS-TP MUST support hiding of the Service Provider infrastructure 577 for all reference models regardless of whether the network(s) are 578 using static configuration or a dynamic control plane. 580 o Security management requirements from [RFC5951]: 582 * MPLS-TP MUST support management communication channel (MCC) 583 security. 585 * Secure communication channels MUST be supported for all network 586 traffic and protocols used to support management functions. 587 This MUST include protocols used for configuration, monitoring, 588 configuration backup, logging, time synchronization, 589 authentication, and routing. 591 * The MCC MUST support application protocols that provide 592 confidentiality and data integrity protection. 594 * The MCC MUST support the use of open cryptographic algorithms 595 [RFC3871]. 597 * The MCC MUST support authentication to ensure that management 598 connectivity and activity is only from authenticated entities. 600 * The MCC MUST support port access control. 602 * Distributed Denial of Service: It is possible to lessen the 603 impact and potential for DoS and DDoS by using secure 604 protocols, turning off unnecessary processes, logging and 605 monitoring, and ingress filtering. [RFC4732] provides 606 background on DOS in the context of the Internet. 608 o MPLS-TP MUST provide protection from operational error. Due to 609 the extensive use of static provisioning with or without NMS and 610 OSS, the prevention of configuration errors should be addressed as 611 major security requirements. 613 4. Security Threats 615 This section discusses the various network security threats that may 616 endanger MPLS-TP networks. The discussion is limited to those 617 threats that are unique to MPLS-TP networks or that affect MPLS-TP 618 networks in unique ways. 620 A successful attack on a particular MPLS-TP network or on a SP's 621 MPLS-TP infrastructure may cause one or more of the following ill 622 effects: 624 1. Observation (including traffic pattern analysis), modification, 625 or deletion of a provider's or user's data, as well as replay or 626 insertion of non-authentic data into a provider's or user's data 627 stream. These types of attacks apply to MPLS-TP traffic 628 regardless of how the LSP or PW is set up in a similar way to how 629 they apply to MPLS traffic regardless how the LSP is set up. 631 2. Attacks on GAL label, BFD messages: 633 1. GAL label or BFD label manipulation: including insertion of 634 false label or messages, or modification, or removal the GAL 635 labels or messages by attackers. 637 2. DOS attack through in-band OAM G-ACH/GAL, and BFD messages. 639 3. Disruption of a provider's and/or user's connectivity, or 640 degradation of a provider's service quality. 642 1. Provider connectivity attacks: 644 + In the case of NMS is used for LSP set-up, the attacks 645 would be through the attack of NMS. 647 + In the case of dynamic is used for dynamic provisioning, 648 the attack would be on dynamic control plane. Most 649 aspects are addressed in [RFC5920]. 651 2. User connectivity attack. This would be similar as PE/CE 652 access attack in typical MPLS networks, addressed in 653 [RFC5920]. 655 4. Probing a provider's network to determine its configuration, 656 capacity, or usage. These types of attack can happen through NMS 657 attacks in the case of static provisioning, or through control 658 plane attacks as in dynamic MPLS networks. It can also be 659 combined attacks. 661 It is useful to consider that threats, whether malicious or 662 accidental, may come from different categories of sources. For 663 example they may come from: 665 o Other users whose services are provided by the same MPLS-TP core. 667 o The MPLS-TP SP or persons working for it. 669 o Other persons who obtain physical access to a MPLS-TP SP's site. 671 o Other persons who use social engineering methods to influence the 672 behavior of a SP's personnel. 674 o Users of the MPLS-TP network itself. 676 o Others, e.g., attackers from the other sources, Internet if 677 connected. 679 o Other SPs in the case of MPLS-TP Inter-provider connection. The 680 provider may or may not be using MPLS-TP. 682 o Those who create, deliver, install, and maintain software for 683 network equipment. 685 Given that security is generally a tradeoff between expense and risk, 686 it is also useful to consider the likelihood of different attacks 687 occurring. There is at least a perceived difference in the 688 likelihood of most types of attacks being successfully mounted in 689 different environments, such as: 691 o A MPLS-TP network inter-connecting with another provider's core 693 o A MPLS-TP configuration transiting the public Internet 695 Most types of attacks become easier to mount and hence more likely as 696 the shared infrastructure via which service is provided expands from 697 a single SP to multiple cooperating SPs to the global Internet. 698 Attacks that may not be of sufficient likeliness to warrant concern 699 in a closely controlled environment often merit defensive measures in 700 broader, more open environments. In closed communities, it is often 701 practical to deal with misbehavior after the fact: an employee can be 702 disciplined, for example. 704 The following sections discuss specific types of exploits that 705 threaten MPLS-TP networks. 707 4.1. Attacks on the Control Plane 709 o MPLS-TP LSP creation by an unauthorized element 711 o LSP message interception 713 o Attacks on G-Ach 715 o Attacks against LDP 717 o Attacks against RSVP-TE 719 o Attacks against GMPLS 721 o Denial of Service Attacks on the Network Infrastructure 723 o Attacks on the SP's MPLS/GMPLS Equipment via Management Interfaces 725 o Social Engineering Attacks on the SP's Infrastructure 727 o Cross-Connection of Traffic between Users 729 o Attacks against Routing Protocols 731 o Other Attacks on Control Traffic 733 4.2. Attacks on the Data Plane 735 This category encompasses attacks on the provider's or end user's 736 data. Note that from the MPLS-TP network end user's point of view, 737 some of this might be control plane traffic, e.g. routing protocols 738 running from user site A to user site B via IP or non-IP connections, 739 which may be some type of VPN. 741 o Unauthorized Observation of Data Traffic 743 o Modification of Data Traffic 745 o Insertion of Inauthentic Data Traffic: Spoofing and Replay 747 o Unauthorized Deletion of Data Traffic 749 o Unauthorized Traffic Pattern Analysis 750 o Denial of Service Attacks 752 o Misconnection 754 5. Defensive Techniques for MPLS-TP Networks 756 The defensive techniques discussed in this document are intended to 757 describe methods by which some security threats can be addressed. 758 They are not intended as requirements for all MPLS-TP 759 implementations. The MPLS-TP provider should determine the 760 applicability of these techniques to the provider's specific service 761 offerings, and the end user may wish to assess the value of these 762 techniques to the user's service requirements. The operational 763 environment determines the security requirements. Therefore, 764 protocol designers need to provide a full set of security services, 765 which can be used where appropriate. 767 The techniques discussed here include encryption, authentication, 768 filtering, firewalls, access control, isolation, aggregation, and 769 others. 771 5.1. Authentication 773 To prevent security issues arising from some DoS attacks or from 774 malicious or accidental misconfiguration, it is critical that devices 775 in the MPLS-TP should only accept connections or control messages 776 from valid sources. Authentication refers to methods to ensure that 777 message sources are properly identified by the MPLS-TP devices with 778 which they communicate. This section focuses on identifying the 779 scenarios in which sender authentication is required and recommends 780 authentication mechanisms for these scenarios. 782 5.1.1. Management System Authentication 784 Management system authentication includes the authentication of a PE 785 to a centrally-managed network management or directory server when 786 directory-based "auto-discovery" is used. It also includes 787 authentication of a CE to the configuration server, when a 788 configuration server system is used. 790 Authentication should be bi-directional, including PE or CE to 791 configuration server authentication for PE or CE to be certain it is 792 communicating with the right server. 794 5.1.2. Peer-to-Peer Authentication 796 Peer-to-peer authentication includes peer authentication for network 797 control protocols and other peer authentication (i.e., authentication 798 of one IPsec security gateway by another). 800 Authentication should be bi-directional, including S-PE, T-PE, PE or 801 CE to configuration server authentication for PE or CE to be certain 802 it is communicating with the right server. 804 5.1.3. Cryptographic Techniques for Authenticating Identity 806 Cryptographic techniques offer several mechanisms for authenticating 807 the identity of devices or individuals. These include the use of 808 shared secret keys, one-time keys generated by accessory devices or 809 software, user-ID and password pairs, and a range of public-private 810 key systems. Another approach is to use a hierarchical Certification 811 Authority system to provide digital certificates. 813 5.2. Access Control Techniques 815 Most of the security issues related to management interfaces can be 816 addressed through the use of authentication techniques as described 817 in the section on authentication. However, additional security may 818 be provided by controlling access to management interfaces in other 819 ways. 821 The Optical Internetworking Forum has done relevant work on 822 protecting such interfaces with TLS, SSH, Kerberos, IPsec, WSS, etc. 823 See Security for Management Interfaces to Network Elements 824 [OIF-SMI-01.0], and Addendum to the Security for Management 825 Interfaces to Network Elements [OIF-SMI-02.1]. See also the work in 826 the ISMS WG. 828 Management interfaces, especially console ports on MPLS-TP devices, 829 may be configured so they are only accessible out-of-band, through a 830 system which is physically or logically separated from the rest of 831 the MPLS-TP infrastructure. 833 Where management interfaces are accessible in-band within the MPLS-TP 834 domain, filtering or firewalling techniques can be used to restrict 835 unauthorized in-band traffic from having access to management 836 interfaces. Depending on device capabilities, these filtering or 837 firewalling techniques can be configured either on other devices 838 through which the traffic might pass, or on the individual MPLS-TP 839 devices themselves. 841 5.3. Use of Isolated Infrastructure 843 One way to protect the infrastructure used for support of MPLS-TP is 844 to separate the resources for support of MPLS-TP services from the 845 resources used for other purposes. 847 5.4. Use of Aggregated Infrastructure 849 In general, it is not feasible to use a completely separate set of 850 resources for support of each service. In fact, one of the main 851 reasons for MPLS-TP enabled services is to allow sharing of resources 852 between multiple services and multiple users. Thus, even if certain 853 services use a separate network from Internet services, nonetheless 854 there will still be multiple MPLS-TP users sharing the same network 855 resources. 857 In general, the use of aggregated infrastructure allows the service 858 provider to benefit from stochastic multiplexing of multiple bursty 859 flows, and also may in some cases thwart traffic pattern analysis by 860 combining the data from multiple users. However, service providers 861 must minimize security risks introduced from any individual service 862 or individual users. 864 5.5. Service Provider Quality Control Processes 866 5.6. Verification of Connectivity 868 In order to protect against deliberate or accidental misconnection, 869 mechanisms can be put in place to verify both end-to-end connectivity 870 and hop-by-hop resources. These mechanisms can trace the routes of 871 LSPs in both the control plane and the data plane. 873 6. Monitoring, Detection, and Reporting of Security Attacks 875 MPLS-TP network and service may be subject to attacks from a variety 876 of security threats. Many threats are described in the Security 877 Requirements (Section 3) Section of this document. Many of the 878 defensive techniques described in this document and elsewhere provide 879 significant levels of protection from a variety of threats. However, 880 in addition to employing defensive techniques silently to protect 881 against attacks, MPLS-TP services can also add value for both 882 providers and customers by implementing security monitoring systems 883 to detect and report on any security attacks, regardless of whether 884 the attacks are effective. 886 Attackers often begin by probing and analyzing defenses, so systems 887 that can detect and properly report these early stages of attacks can 888 provide significant benefits. 890 Information concerning attack incidents, especially if available 891 quickly, can be useful in defending against further attacks. It can 892 be used to help identify attackers or their specific targets at an 893 early stage. This knowledge about attackers and targets can be used 894 to strengthen defenses against specific attacks or attackers, or to 895 improve the defenses for specific targets on an as-needed basis. 896 Information collected on attacks may also be useful in identifying 897 and developing defenses against novel attack types. 899 7. Security Considerations 901 Security considerations constitute the sole subject of this memo and 902 hence are discussed throughout. 904 The document describes a variety of defensive techniques that may be 905 used to counter the suspected threats. All of the techniques 906 presented involve mature and widely implemented technologies that are 907 practical to implement. 909 The document evaluates MPLS-TP security requirements from a 910 customer's perspective as well as from a service provider's 911 perspective. These sections re-evaluate the identified threats from 912 the perspectives of the various stakeholders and are meant to assist 913 equipment vendors and service providers, who must ultimately decide 914 what threats to protect against in any given configuration or service 915 offering. 917 8. IANA Considerations 919 This document contains no new IANA considerations. 921 9. References 923 9.1. Normative References 925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 926 Requirement Levels", BCP 14, RFC 2119, March 1997. 928 [RFC3871] Jones, G., "Operational Security Requirements for Large 929 Internet Service Provider (ISP) IP Network 930 Infrastructure", RFC 3871, September 2004. 932 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 933 Service Considerations", RFC 4732, December 2006. 935 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 936 and S. Ueno, "Requirements of an MPLS Transport Profile", 937 RFC 5654, September 2009. 939 [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management 940 Requirements for MPLS-based Transport Networks", RFC 5951, 941 September 2010. 943 9.2. Informative References 945 [OIF-SMI-01.0] 946 Optical Internetworking Forum, "Security for Management 947 Interfaces to Network Elements", OIF OIF-SMI-01.0, 948 Sept 2003. 950 [OIF-SMI-02.1] 951 Optical Internetworking Forum, "Addendum to the Security 952 for Management Interfaces to Network Elements", OIF OIF- 953 SMI-02.1, March 2006. 955 [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security 956 Mechanisms for the Internet", RFC 3631, December 2003. 958 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 959 Networks", RFC 5920, July 2010. 961 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 962 Berger, "A Framework for MPLS in Transport Networks", 963 RFC 5921, July 2010. 965 [opsec-efforts] 966 "Security Best Practices Efforts and Documents", 967 IETF draft-ietf-opsec-efforts-08.txt, June 2008. 969 Authors' Addresses 971 Luyuan Fang (editor) 972 Cisco Systems Inc. 973 300 Beaver Brook Road 974 Boxborough, MA 01719 975 US 977 Email: lufang@cisco.com 978 Ben Niven-Jenkins (editor) 979 Velocix 980 326 Cambridge Science Park 981 Milton Road 982 Cambridge CB4 0WG 983 UK 985 Email: ben@niven-jenkins.co.uk 987 Scott Mansfield (editor) 988 Ericsson 989 300 Holger Way 990 San Jose, CA 95134 991 US 993 Email: scott.mansfield@ericsson.com 995 Raymond Zhang 996 British Telecom 997 BT Center 998 81 Newgate Street 999 London EC1A 7AJ 1000 Uk 1002 Email: raymond.zhang@bt.com 1004 Nabil Bitar 1005 Verizon 1006 40 Sylvan Road 1007 Waltham, MA 02145 1008 US 1010 Email: nabil.bitar@verizon.com 1012 Masahiro Daikoku 1013 KDDI Corporation 1014 3-11-11 Iidabashi, Chiyodaku 1015 Tokyo 1016 Japan 1018 Email: ms-daikoku@kddi.com 1019 Lai Wang 1020 Telenor 1021 Telenor Norway 1022 Office Snaroyveien 1023 1331 Fornedbu 1024 Norway 1026 Email: lai.wang@telenor.com