idnits 2.17.1 draft-ietf-mpls-tp-security-framework-09.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 (February 25, 2013) is 4077 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-DRAFT L. Fang, Ed. 3 Intended Status: Informational Cisco 4 Expires: August 25, 2013 B. Niven-Jenkins, Ed. 5 Velocix 6 S. Mansfield, Ed. 7 Ericsson 8 R. Graveman, Ed. 9 RFG Security 11 February 25, 2013 13 MPLS-TP Security Framework 14 draft-ietf-mpls-tp-security-framework-09 16 Abstract 18 This document provides a security framework for Multiprotocol Label 19 Switching Transport Profile (MPLS-TP). MPLS-TP extends MPLS 20 technologies and introduces new OAM capabilities, a transport- 21 oriented path protection mechanism, and strong emphasis on static 22 provisioning supported by network management systems. This document 23 addresses the security aspects relevant in the context of MPLS-TP 24 specifically. It describes potential security threats, security 25 requirements for MPLS-TP, and mitigation procedures for MPLS-TP 26 networks and MPLS-TP interconnection to other MPLS and GMPLS 27 networks. This document is built on RFC5920 "MPLS and GMPLS security 28 framework" by providing additional security considerations which are 29 applicable to the MPLS-TP extensions. All the security considerations 30 from RFC5920 are assumed to apply. 32 This document is a product of a joint Internet Engineering Task Force 33 (IETF) / International Telecommunication Union Telecommunication 34 Standardization Sector (ITU-T) effort to include an MPLS Transport 35 Profile within the IETF MPLS and PWE3 architectures to support the 36 capabilities and functionality of a packet transport network. 38 Status of this Memo 40 This Internet-Draft is submitted to IETF in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as 46 Internet-Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/1id-abstracts.html 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html 59 Copyright and License Notice 61 Copyright (c) 2013 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Security Reference Models . . . . . . . . . . . . . . . . . . . 4 79 2.1. Security Reference Model 1 . . . . . . . . . . . . . . . . 4 80 2.2. Security Reference Model 2 . . . . . . . . . . . . . . . . 6 81 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 8 82 4. Defensive Techniques . . . . . . . . . . . . . . . . . . . . . 9 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 90 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 This document provides a security framework for Multiprotocol Label 95 Switching Transport Profile (MPLS-TP). 97 As defined in MPLS-TP Requirements [RFC5654] and MPLS-TP Framework 98 [RFC5921], MPLS-TP uses a subset of MPLS features and introduces 99 extensions to reflect the characteristics of the transport 100 technology. The additional functionality include in-band OAM, 101 transport-oriented path protection and recovery mechanisms, and new 102 OAM capabilities developed for MPLS-TP but apply to general MPLS and 103 GMPLS. There is strong emphasis in MPLS-TP on static provisioning 104 support through network management systems (NMS) or Operation Support 105 Systems (OSS). 107 This document is built on RFC 5920 by providing additional security 108 considerations which are applicable to the MPLS-TP extensions. The 109 security models, threats, requirements, and defense techniques 110 previously defined in [RFC5920] are assumed to apply to general 111 aspect of MPLS-TP. 113 This document is a product of a joint Internet Engineering Task Force 114 (IETF) / International Telecommunication Union Telecommunication 115 Standardization Sector (ITU-T) effort to include an MPLS Transport 116 Profile within the IETF MPLS and PWE3 architectures to support the 117 capabilities and functionality of a packet transport network. 119 Readers can refer to [RFC5654] and [RFC5921] for MPLS-TP 120 terminologies, and [RFC5920] for security terminologies which are 121 relevant to MPLS and GMPLS. 123 1.1. Terminology 125 Term Definition 126 ------ ----------------------------------------------- 127 AC Attachment Circuit 128 BFD Bidirectional Forwarding Detection 129 CE Customer-Edge device 130 DoS Denial of Service 131 G-ACh Generic Associated Channel 132 GAL G-ACh Label 133 GMPLS Generalized Multi-Protocol Label Switching 134 IP Internet Protocol 135 LDP Label Distribution Protocol 136 LSP Label Switched Path 137 NMS Network Management System 138 MPLS MultiProtocol Label Switching 139 MPLS-TP MultiProtocol Label Switching Transport Profile 140 MS-PW Multi-Segment Pseudowire 141 OAM Operations, Administration, and Maintenance 142 PE Provider-Edge device 143 PSN Packet-Switched Network 144 PW Pseudowire 145 S-PE PW Switching Provider Edge 146 SP Service Provider 147 SS-PW Single-Segment Pseudowire 148 T-PE PW Terminating Provider Edge 150 2. Security Reference Models 152 This section defines reference models for security in MPLS-TP 153 networks. 155 The models are built on the architecture of MPLS-TP defined in 156 [RFC5921]. The placement of Service Provider (SP) boundaries plays 157 important role in determining the security models for any particular 158 deployment. 160 This document defines a trusted zone as being where a single SP has 161 total operational control over that part of the network. A primary 162 concern is about security aspects that relate to breaches of security 163 from the "outside" of a trusted zone to the "inside" of this zone. 165 2.1. Security Reference Model 1 167 In reference model 1, a single SP has total control of the PE/T-PE to 168 PE/T-PE part of the MPLS-TP network. 170 Security reference model 1(a) 172 An MPLS-TP network with Single Segment Pseudowire (SS-PW) from PE1 to 173 PE2. The trusted zone is PE1 to PE2 as illustrated in Figure 1. 175 |<-------------- Emulated Service ---------------->| 176 | | 177 | |<------- Pseudo Wire ------>| | 178 | | | | 179 | | |<-- PSN Tunnel -->| | | 180 | v v v v | 181 v AC +----+ +----+ AC v 182 +-----+ | | PE1|==================| PE2| | +-----+ 183 | |----------|............PW1.............|----------| | 184 | CE1 | | | | | | | | CE2 | 185 | |----------|............PW2.............|----------| | 186 +-----+ ^ | | |==================| | | ^ +-----+ 187 ^ | +----+ +----+ | | ^ 188 | | Provider Edge 1 Provider Edge 2 | | 189 | | | | 190 Customer | |Customer 191 Edge 1 | |Edge 2 192 | | 193 Native service Native service 195 ---Untrusted--- >|<------- Trusted Zone ----->|<---Untrusted---- 197 Figure 1. MPLS-TP Security Model 1(a) 199 Security reference model 1(b) 201 An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE1 202 to T-PE2. The trusted zone is T-PE1 to T-PE2 in Figure 2. 204 Native |<-------------Pseudowire------------>| Native 205 Service | | Service 206 (AC) | |<- PSN ->| |<- PSN ->| | (AC) 207 | v v v v v v | 208 | +-----+ +-----+ +-----+ | 209 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 210 | |------|......PW.Seg't1.......PW.Seg't3......|-------| | 211 | CE1| | | | | | | | | |CE2 | 212 | |------|......PW.Seg't2.......PW.Seg't4......|-------| | 213 +----+ | | |=========| |=========| | | +----+ 214 ^ +-----+ ^ +-----+ ^ +-----+ ^ 215 | | | | 216 | TP LSP TP LSP | 217 | | 218 |<----------------- Emulated Service ---------------->| 220 -Untrusted->|<---------- Trusted Zone ----------->|<-Untrusted-- 222 Figure 2. MPLS-TP Security Model 1(b) 224 2.2. Security Reference Model 2 226 In reference model 2, a single SP does not have the end-to-end 227 control of the segment from PE/T-PE to PE/T-PE. Some S-PE(s), T-PE(s) 228 may be under the control of other SPs, or the SP's customers, or its 229 partners. In this case, the MPLS-TP network is not contained within a 230 single trusted zone. 232 Security Reference Model 2(a) 234 An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE1 235 to T-PE2. The trusted zone is T-PE1 to S-PE1, as illustrated in 236 Figure 3. 238 Native |<-------------Pseudowire------------>| Native 239 Service | | Service 240 (AC) | |<--PSN-->| |<--PSN-->| | (AC) 241 | V V V V V V | 242 | +-----+ +-----+ +-----+ | 243 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 244 | |------|......PW.Seg't1.......PW.Seg't3......|------| | 245 | CE1| | | | | | | | | |CE2 | 246 | |------|......PW.Seg't2.......PW.Seg't4......|------| | 247 +----+ | | |=========| |=========| | | +----+ 248 ^ +-----+ ^ +-----+ ^ +-----+ ^ 249 | | | | 250 | TP LSP TP LSP | 251 | | 252 |<---------------- Emulated Service --------------->| 254 Untrusted-->|<-- Trusted Zone---->|<---------Untrusted-------- 256 Figure 3. MPLS-TP Security Model 2(a) 258 Security Reference Model 2(b) 260 An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from T-PE1 261 to T-PE2. The trusted zone is the S-PE1 only, as illustrated in 262 Figure 4. 264 Native |<-------------Pseudowire------------>| Native 265 Service | | Service 266 (AC) | |<--PSN-->| |<--PSN-->| | (AC) 267 | V V V V V V | 268 | +-----+ +-----+ +-----+ | 269 +----+ | |T-PE1|=========|S-PE1|=========|T-PE2| | +----+ 270 | |------|......PW.Seg't1.......PW.Seg't3......|------| | 271 | CE1| | | | | | | | | |CE2 | 272 | |------|......PW.Seg't2.......PW.Seg't4......|------| | 273 +----+ | | |=========| |=========| | | +----+ 274 ^ +-----+ ^ +-----+ ^ +-----+ ^ 275 | | | | 276 | TP LSP TP LSP | 277 | | 278 |<---------------- Emulated Service --------------->| 280 --------Untrusted---------->|<--->|<-------Untrusted---------- 281 Trusted 282 Zone 284 Figure 4. MPLS-TP Security Model 2(b) 286 Security Reference Model 2(c) 288 An MPLS-TP network with Multi-Segment Pseudowire (MS-PW) from 289 different Service Providers with inter-provider PW connections. The 290 trusted zone is T-PE1 to S-PE3, as illustrated in Figure 5. 292 Native |<--------------------- PW15 ------------------>| Native 293 Layer | | Layer 294 Service | || || || | Service 295 (AC1) V V LSP V V LSP V V LSP V V (AC2) 296 | +-----+ +-+ +-----+ +-----+ +-+ +-----+ | 297 +---+ | |T-PE1| | | |S-PE3| |S-PEX| | | |T-PEZ| | +---+ 298 | | | | |=======| |=======| |=======| | | | | 299 |CE1|----|........PW1........|..PW3..|........PW5........|---|CE2| 300 | | | | |=======| |=======| |=======| | | | | 301 +---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+ 302 +-----+ +-+ +-----+ +-----+ +-+ +-----+ 303 |<--Subnetwork 123->| |<--Subnetwork XYZ->| 305 Untrusted>|<-- Trusted Zone-->|<-------------Untrusted------------- 307 Figure 5. MPLS-TP Security Model 2(c) 309 In general, the boundaries of a trusted zone must be carefully 310 defined when analyzing the security properties of each individual 311 network. The security boundaries determine which reference model 312 should be applied to given network topology. 314 3. Security Threats 316 This section discusses various network security threats that are 317 unique to MPLS-TP and may endanger MPLS-TP networks. 319 Attacks to GAL or G-ACh may include: 321 - GAL or BFD label manipulation, which includes insertion of false 322 labels and modification, deletion, or replay of messages. 324 - DoS attack through in-band OAM by generating excessive G-ACh/GAL 325 and BFD messages which consume significant bandwidth and 326 potentially cause congestion. 328 These attacks can cause unauthorized protection switchover, inability 329 to restore, or loss of network connectivity. 331 When a NMS is used for LSP setup, the attacks to NMS can cause the 332 above effect as well. Although this is not unique to MPLS-TP, MPLS-TP 333 network can be particularly vulnerable to NMS attack due to the fact 334 that static provisioning through NMS is a commonly used model. In the 335 static provisioning model, a compromised NMS can potentially be 336 comparable to a comprised control plane plus a comprised management 337 plane in the dynamic controlled network model. 339 Attacks to NMS may come from external attackers, or insiders. Outside 340 attacks are initiated outside of the trusted zone by unauthorized 341 user of the MPLS-TP network management systems. Insider attack is 342 initiated from inside of the trusted zone by an entity with 343 authorized access to the management systems, but performs unapproved 344 harmful functions to the MPLS-TP networks. These attacks may be 345 directly targeted to the NMS, or via the compromised communication 346 channels between the NMS and the network devices that are being 347 provisioned, or through the access of the users to the provisioning 348 tools. The security threat may include disclosure of information, 349 generating false OAM messages, taking down MPLS-TP LSPs, connecting 350 to the wrong MPLS-TP tunnel end points, and DoS attacks to the MPLS- 351 TP networks. 353 There are other more generic security threat, such as: Unauthorized 354 observation of data traffic (including traffic pattern analysis), 355 modification, or deletion of a provider's or user's data, as well as 356 replay or insertion of inauthentic data into a provider's or user's 357 data stream. These types of attacks apply to MPLS-TP traffic 358 regardless of how the LSP or PW is set up in a similar way to how 359 they apply to MPLS traffic regardless how the LSP is set up. More 360 details on the above mentioned threat are documented in [RFC5920]. 362 The threats may be resulting from malicious behavior or accidental 363 errors. 365 Example 1: Attack from users: Users of the MPLS-TP network may attack 366 the network infrastructure or attack other users. 368 Example 2: Attack from insiders: Employees of the operators may 369 attack the MPLS-TP network, especially through NMS. 371 Example 3: Attack from inter-connecting SPs or other partners: Other 372 SPs may attack the MPLS-TP network, particularly through the inter- 373 provider connections. 375 Example 4: Attack as the result of operation errors: Operation staff 376 may fail to follow the operational procedures or make operational 377 mistakes. 379 4. Defensive Techniques 381 The defensive techniques presented in this document and in [RFC5920] 382 are intended to describe methods by which some security threats can 383 be addressed. They are not intended as requirements for all MPLS-TP 384 deployments. The specific operational environment determines the 385 security requirements for any instance of MPLS-TP. Therefore, 386 protocol designers should provide a full set of security 387 capabilities, which can be selected and used where appropriate. The 388 MPLS-TP provider should determine the applicability of these 389 techniques to the provider's specific service offerings, and the end 390 user may wish to assess the value of these techniques to the user's 391 service requirements. 393 Authentication is the primary defense technique to mitigate the risk 394 of the MPLS-TP security threat "GAL or BFD label manipulation", and 395 "DoS attack through in-band OAM" discussed in Section 3. 396 Authentication refers to methods to ensure that message sources are 397 properly identified by the MPLS-TP devices with which they 398 communicate. Authentication includes entity authentication for 399 identity verification, management system authentication, peer-to-peer 400 authentication, message integrity and replay detection to ensure the 401 validity of message streams, network-based access controls such as 402 packet filtering and firewalls, host-based access controls, 403 isolation, aggregation, protection against denial of service, and 404 event logging. Where these techniques apply to MPLS and GMPLS in 405 general, they are described in Section 5.2 of [RFC5920]. 407 In addition to authentication, the following defense should also be 408 considered to protect MPLS-TP networks. 410 - Use of Isolated Infrastructure for MPLS-TP 412 One way to protect the MPLS-TP infrastructure network is to use 413 dedicated network resources to provide MPLS-TP transport services. 414 For example, in security model 2 (Section 2.2), the potential risk of 415 attacks on the S-PE1 or T-PE1 in the trusted zone may be reduced by 416 using non-IP-based communication paths, so that the paths in the 417 trusted zone cannot be reached from the outside via IP. 419 - Verification of Connectivity 421 To protect against deliberate or accidental misconnection, mechanisms 422 can be put in place to verify both end-to-end connectivity and 423 segment-by-segment resources. These mechanisms can trace the routes 424 of LSPs in both the control plane and the data plane. Note that the 425 connectivity verification tools are now developed for general MPLS 426 networks as well. 428 The defense techniques are apply generally to MPLS/GMPLS are not 429 detailed here, for example: 431 1) Authentication: including Management System Authentication, 432 Peer-to-Peer Authentication, Cryptographic Techniques for 433 Authenticating Identity; 435 2) Access Control Techniques; 437 3) Use of Aggregated Infrastructure; 439 4) Mitigation of Denial of Service Attacks; 441 5) Monitoring, Detection, and Reporting of Security Attacks. 443 Readers can refer to [RFC5920] for details. 445 It is important to point out the following security defense 446 techniques which are particularly critical for NMS due to the strong 447 emphasis on static provisioning supported by NMS in MPLS-TP 448 deployment. These techniques include: Entity authentication for 449 identity verification, encryption for confidentiality, message 450 integrity and replay detection to ensure the validity of message 451 streams, as well as users access control and events logging which 452 must be applied for NMS and provisioning applications. 454 5. Security Considerations 455 Security considerations constitute the sole subject of this document 456 and hence are discussed throughout. 458 This document evaluates MPLS-TP specific security risks and 459 mitigation mechanisms which may be used to counter the potential 460 threats. All of the techniques presented involve mature and widely 461 implemented technologies that are practical to implement. It is meant 462 to assist equipment vendors and service providers, who must 463 ultimately decide what threats to protect against in any given 464 configuration or service offering from a customer's perspective as 465 well as from a service provider's perspective. 467 6. IANA Considerations 469 This document contains no new IANA considerations. 471 7. Acknowledgements 473 The authors wish to thank Joel Halpern and Gregory Mirsky for their 474 review comments and contributions to this document, thank Mach Chen 475 for his review and suggestions, thank Adrian Farrel for his Routing 476 AD review and detailed comments, thank Loa Andersson for his 477 continued support and guidance as the MPLS WG co-Chair, and thank Dan 478 Romascanu and Barry Leiba for their helpful comments during IESG 479 review. 481 8. References 483 8.1. Normative References 485 [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., 486 Sprecher, N., and S. Ueno, "Requirements of an MPLS 487 Transport Profile", RFC 5654, September 2009. 489 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 490 Networks", RFC 5920, July 2010. 492 8.2. Informative References 494 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 495 L., and L. Berger, "A Framework for MPLS in Transport 496 Networks", RFC 5921, July 2010. 498 Authors' Addresses 500 Luyuan Fang (editor) 501 Cisco Systems 502 111 Wood Ave. South 503 Iselin, NJ 08830, US 504 Email: lufang@cisco.com 506 Ben Niven-Jenkins (editor) 507 Velocix 508 326 Cambridge Science Park 509 Milton Road 510 Cambridge CB4 0WG, UK 511 Email: ben@niven-jenkins.co.uk 513 Scott Mansfield (editor) 514 Ericsson 515 300 Holger Way 516 San Jose, CA 95134, US 517 Email: scott.mansfield@ericsson.com 519 Richard F. Graveman (editor) 520 RFG Security, LLC 521 15 Park Avenue 522 Morristown, NJ 07960, US 523 Email: rfg@acm.org 525 Contributors' Addresses 527 Raymond Zhang 528 Alcatel-Lucent 529 750D Chai Chee Road 530 Singapore 469004 531 Email: raymond.zhang@alcatel-lucent.com 533 Nabil Bitar 534 Verizon 535 40 Sylvan Road 536 Waltham, MA 02145, US 537 Email: nabil.bitar@verizon.com 539 Masahiro Daikoku 540 KDDI Corporation 541 3-11-11 Iidabashi, Chiyodaku, Tokyo, Japan 542 Email: ms-daikoku@kddi.com 544 Lei Wang 545 Lime Networks 546 Strandveien 30, 1366 Lysaker, Norway 547 Email: lei.wang@limenetworks.no 549 Henry Yu 550 TW Telecom 551 10475 Park Meadow Drive 552 Littleton, CO 80124, US 553 Email: henry.yu@twtelecom.com