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