idnits 2.17.1 draft-mahesh-bgp-ldp-msdp-analysis-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 189: '... algorithms that MUST be supported. T...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 15, 2011) is 4723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3547' is defined on line 479, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 482, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Working Group M. Jethanandani 3 Internet-Draft K. Patel 4 Intended status: Informational Cisco Systems, Inc 5 Expires: November 16, 2011 L. Zheng 6 Huawei 7 May 15, 2011 9 Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design 10 Guide 11 draft-mahesh-bgp-ldp-msdp-analysis-01.txt 13 Abstract 15 This document analyzes BGP, LDP, PCEP and MSDP according to 16 guidelines set forth in section 4.2 of 17 [draft-ietf-karp-design-guide]. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 16, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 55 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Current State of BGP, LDP, PCEP and MSDP . . . . . . . . . . . 5 57 2.1. Transport level . . . . . . . . . . . . . . . . . . . . . 5 58 2.2. Keying mechanisms . . . . . . . . . . . . . . . . . . . . 6 59 2.3. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 6 61 2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 7 62 2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 7 63 2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 9 66 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 10 68 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 In March 2006 the Internet Architecture Board (IAB) in its "Unwanted 80 Internet Traffic" workshop described an attack on core routing 81 infrastructure as an ideal attack with the most amount of damage. It 82 called for the tightening the security of the core routing 83 infrastructure. 85 This document performs the initial analysis of the current state of 86 BGP, LDP, PCEP and MSDP according to the requirements of 87 [draft-ietf-karp-design-guide]. This draft builds on several 88 previous analysis efforts into routing security. The OPSEC working 89 group put together Issues with existing Cryptographic Protection 90 Methods for Routing Protocols 91 [draft-ietf-opsec-routing-protocols-crypto-issues] an analysis of 92 cryptographic issues with routing protocols and 93 draft-hartman-ospf-analysis-01 which has a analysis for OSPF. 95 Section 2 looks at the current state of the four routing protocols. 96 Section 3 goes into what the optimal state would be for the three 97 routing protocols according to KARP Design Guidelines 98 [draft-ietf-karp-design-guide] and Section 4 does a analysis of the 99 gap between the existing state and the optimal state of the protocols 100 and suggest some areas where we need to improve. 102 1.1. Contributing Authors 104 Anantha Ramaiah, Mach Chen 106 1.2. Abbreviations 108 BGP - Border Gateway Protocol 110 DoS - Denial of Service 112 KARP - Key and Authentication for Routing Protocols 114 KDF - Key Derivation Function 116 KEK - Key Encrypting Key 118 KMP - Key Management Protocol 120 LDP - Label Distribution Protocol 122 LSR - Label Switch Routers 124 MAC - Message Authentication Code 125 MKT - Master Key Tuple 127 MSDP - Multicast Source Distribution Protocol 129 MD5 - Message Digest algorithm 5 131 OSPF - OPen Shortest Path First 133 PCEP - Path Computation Element Protocol 135 TCP - Transmission Control Protocol 137 UDP - User Datagram Protocol 139 2. Current State of BGP, LDP, PCEP and MSDP 141 This section looks at the underlying transport protocol and key 142 mechanisms built for the protocol. It describes the security 143 mechanisms built into BGP, LDP, PCEP and MSDP. 145 2.1. Transport level 147 At a transport level, routing protocols are subject to a variety of 148 DoS attacks. Such attacks can cause the routing protocol to become 149 congested with the result that routing updates are supplied too 150 slowly to be useful or in extreme case prevent route convergence 151 after a change. 153 Routing protocols use several methods to protect themselves. Those 154 that run on TCP use access list to permit packets only from know 155 sources. These access lists also help edge routers from attacks 156 originating from outside the protected cloud. In addition for edge 157 routers running eBGP, TCP LISTEN is run only on interfaces on which 158 its peers have been discovered or that are configured to expect 159 sessions on. 161 GTSM [RFC5082] describes a generalized Time to Live (TTL) security 162 mechanism to protect a protocol stack from CPU-utilization based 163 attacks.TCP Robustness [RFC5961] recommends some TCP level 164 mitigations against spoofing attacks targeted towards long lived 165 routing protocol sessions. 167 Even when BGP, LDP, PCEP and MSDP sessions use access list they are 168 subject to spoofing and man in the middle attacks. Authentication 169 and integrity checks allow the receiver of a routing protocol update 170 to know that the message genuinely comes from the node that purports 171 to have sent it and to know whether the message has been modified. 173 TCP MD5 [RFC2385] specifies such a mechanism to protect BGP and other 174 TCP based routing protocols via the TCP MD5 option. TCP MD5 option 175 provides a way for carrying an MD5 digest in a TCP segment. This 176 digest acts like a signature for that segment, incorporating 177 information known only to the connection end points. The MD5 key 178 used to compute the digest is stored locally on the router. This 179 option is used by routing protocols to provide for session level 180 protection against the introduction of spoofed TCP segments into any 181 existing TCP streams, in particular TCP Reset segments. TCP MD5 does 182 not provide a generic mechanism to support Key roll-over. 184 However, the Message Authentication Codes (MACs) used by MD5 to 185 compute the signature are considered to be too weak. TCP-AO 186 [RFC5925] and its companion documentCrypto Algorithms for TCP-AO 188 [RFC5926] is a step towards correcting both the MAC weakness and KMP. 189 For MAC it specifies two MAC algorithms that MUST be supported. They 190 are HMAC-SHA-1-96 as specified in HMAC [RFC2104] and AES-128-CMAC-96 191 as specified in NIST-SP800-38B [NIST-SP800-38B]. Cryptographic 192 research suggests that both these MAC algorithms defined are fairly 193 secure and are not known to be broken in any ways. It also provides 194 for additional MACs to be added in the future. 196 2.2. Keying mechanisms 198 For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used 199 to manage the keys that are used for generating the Message 200 Authentication Code (MAC). It allows for a master key to be 201 configured manually or for it to be managed from a out of band 202 mechanism. Most routers are configured with a static key that does 203 not change over the life of the session. 205 For point-to-point key management IKE [RFC2409] tries to solve the 206 issue of key exchange under a SA. 208 2.3. LDP 210 Section 5 of LDP [RFC5036] states that LDP is subject to three 211 different types of attacks. It talks about spoofing, protection of 212 privacy of label distribution and denial of service attacks. 214 2.3.1. Spoofing attacks 216 Spoofing attack occur both during the discover phase and during the 217 session communication phase. 219 2.3.1.1. Discovery exchanges using UDP 221 Label Switching Routers (LSRs) indicate their willingness to 222 establish and maintain LDP sessions by periodically sending Hello 223 messages. Receipt of a Hello message serves to create a new "Hello 224 adjacency", if one does not already exist, or to refresh an existing 225 one. 227 Unlike all other LDP messages, the Hello messages are sent using UDP 228 not TCP. This means that they cannot benefit from the security 229 mechanisms available with TCP. LDP [RFC5036] does not provide any 230 security mechanisms for use with Hello messages except to note that 231 some configuration may help protect against bogus discovery events. 233 Spoofing a Hello packet for an existing adjacency can cause the 234 adjacency to time out and that can result in termination of the 235 associated session. This can occur when the spoofed Hello message 236 specifies a small Hold Time, causing the receiver to expect Hello 237 messages within this interval, while the true neighbor continues 238 sending Hello messages at the lower, previously agreed to, frequency. 240 Spoofing a Hello packet can also cause the LDP session to be 241 terminated directly. This can occur when the spoofed Hello specifies 242 a different Transport Address from the previously agreed one between 243 neighbors. Spoofed Hello messages are observed and reported as real 244 problem in production networks. 246 2.3.1.2. Session communication using TCP 248 LDP like other TCP based routing protocols specifies use of the TCP 249 MD5 Signature Option to provide for the authenticity and integrity of 250 session messages. As stated above, some assert that MD5 251 authentication is now considered by some to be too weak for this 252 application. A stronger hashing algorithm e.g SHA1, could be 253 deployed to take care of the weakness. 255 2.3.2. Privacy Issues 257 LDP provides no mechanism for protecting the privacy of label 258 distribution. The security requirements of label distribution are 259 similar to other routing protocols that need to distribute routing 260 information. 262 2.3.3. Denial of Service Attacks 264 LDP is subject to Denial of Service (DoS) attacks both in its 265 discovery mode as well as during the session mode. 267 The discovery mode attack is similar to the spoofing attack except 268 that when the spoofed Hello messages are sent with a high enough 269 frequency can cause the adjacency to time out. 271 2.4. PCEP 273 Attacks on PCEP [RFC5440] may result in damage to active networks. 274 This may include computation responses, which if changed can cause 275 protocols like LDP to setup sub-optimal or inappropriate LSPs. In 276 addition, PCE itself can be attacked by a variety of DoS attacks. 277 Such attacks can cause path computations to be supplied too slowly to 278 be of any value particularly as it relates to recovery or 279 establishment of LSPs. 281 As the RFC states, PCEP could be the target of the following 282 attacks.. 284 o Spoofing (PCC or PCE implementation) 286 o Snooping (message interception) 288 o Falsification 290 o Denial of Service 292 According to the RFC, inter-AS scenarios when PCE-to-PCE 293 communication is required, attacks may be particularly significant 294 with commercial as well as service-level implications. 296 Additionally, snooping of PCEP requests and responses may give an 297 attacker information about the operation of the network. Simply by 298 viewing the PCEP messages someone can determine the pattern of 299 service establishment in the network and can know where traffic is 300 being routed, thereby making the network susceptible to targeted 301 attacks and the data within specific LSPs vulnerable. 303 Ensuring PCEP communication privacy is of key importance, especially 304 in an inter-AS context, where PCEP communication end-points do not 305 reside in the same AS, as an attacker that intercepts a PCE message 306 could obtain sensitive information related to computed paths and 307 resources. 309 2.5. MSDP 311 Similar to BGP and LDP, TCP MD5 [RFC2385] specifies a mechanism to 312 protect TCP sessions via the TCP MD5 option. But with a weak MD5 313 authentication, TCP MD5 is considered too weak for this application. 315 MSDP also advocates imposing a limit on number of source address and 316 group addresses (S,G) that can be stored within the protocol and 317 thereby mitigate state explosion due to any denial of service and 318 other attacks. 320 3. Optimal State for BGP, LDP, PCEP, and MSDP 322 The ideal state for BGP, LDP and MSDP protocols are when they can 323 withstand any of the known types of attacks. 325 Additionally, Key Management Protocol (KMP) for the routing sessions 326 should help negotiate unique, pair wise random keys without 327 administrator involvement. It should also negotiate Security 328 Association (SA) parameter required for the session connection, 329 including key life times. It should keep track of those lifetimes 330 and negotiate new keys and parameters before they expire and do so 331 without administrator involvement. In the event of a breach, the 332 keys should be changed immediately. 334 The DoS attacks for BGP, LDP and MSDP are attacks to the transport 335 protocol, TCP in this case. TCP should be able to withstand any of 336 DoS scenarios by dropping packets that are attack packets in a way 337 that does not impact legitimate packets. 339 The routing protocols should provide a mechanism to determine 340 authenticate and validate the routing information carried within the 341 payload. 343 3.1. LDP 345 For the spoofing kind of attacks that LDP is vulnerable to during the 346 discovery phase, it should be able to determine the authenticity of 347 the neighbors sending the Hello message. 349 There is currently no requirement to protect the privacy of label 350 distribution as labels are carried in the clear like other routing 351 information. 353 4. Gap Analysis for BGP, LDP, PCEP and MSDP 355 This section outlines the differences between the current state of 356 the routing protocol and the desired state as outlined in section 4.2 357 of KARP Design Guidelines [draft-ietf-karp-design-guide]. It covers 358 issues that are common to the four protocols leaving protocol 359 specific issues to sub-sections. 361 At a transport level the routing protocols are subject to some of the 362 same attacks that TCP applications are subject to. These include but 363 are not limited to DoS attacks. 365 From a security perspective we lack comprehensive KMP. As an example 366 TCP-AO [RFC5925] talks about coordinating keys derived from MKT 367 between endpoints, the MKT itself has to be configured manually or 368 through a out of band mechanism. Even when keys are configured 369 manually, a method for their rollover has not been defined. This 370 leads to keys not being updated regularly which in itself increases 371 the security risk. Also TCP-AO does not address the issue of 372 connectionless reset. 374 Authentication, tamper protection, and encryption all require the use 375 of keys by sender and receiver. An automated KMP therefore has to 376 include a way to distribute MKT between two end points with little or 377 no administration overhead. It has to cover automatic key rollover. 378 There are two methods of automatic key rollover. Implicit key 379 rollover can be initiated after certain volume of data gets exchanged 380 or when a certain time has elapsed. This does not require explicit 381 signaling. On the other hand, explicit key rollover requires a out 382 of band key signaling mechanism. An example of this is IKE [RFC2409] 383 but it could be any other new mechanisms also. 385 There is a need to protect authenticity and validity of the routing/ 386 label information that is carried in the payload of the sessions. 387 However, we believe that is outside the scope of this document at 388 this time and is being addressed by SIDR WG. Similar mechanisms 389 could be used for intra-domain protocols. 391 4.1. LDP 393 As described in LDP [RFC5036], the threat of spoofed Basic Hellos can 394 be reduced by accepting Basic Hellos on interfaces that LSRs trust, 395 employing GTSM [RFC5082] and ignoring Basic Hellos not addressed to 396 the "all routers on this subnet" multicast group. Spoofing attacks 397 via Extended Hellos are potentially a more serious threat. An LSR 398 can reduce the threat of spoofed Extended Hellos by filtering them 399 and accepting Hellos from sources permitted by an access list. 400 However, performing the filtering using access lists requires LSR 401 resource, and the LSR is still vulnerable to the IP source address 402 spoofing. Spoofing attacks can be solved by being able to 403 authenticate the Hello messages, and an LSR can be configured to only 404 accept Hello messages from specific peers when authentication is in 405 use. 407 LDP Hello Cryptographic Authentication 408 [draft-zheng-mpls-ldp-hello-crypto-auth-01] suggest a new 409 Cryptographic Authentication TLV that can be used as an 410 authentication mechanism to secure Hello messages. 412 4.2. PCEP 414 PCE discovery according to its RFC is a significant feature for the 415 successful deployment of PCEP in large networks. This mechanism 416 allows a PCC to discover the existence of suitable PCEs within the 417 network without the necessity of configuration. It should be obvious 418 that, where PCEs are discovered and not configured, the PCC cannot 419 know the correct key to use. There are different approaches to 420 retain some aspect of security, but all of them require use of a keys 421 and a keying mechanism, the need for which has been discussed above. 423 5. Security Requirements 425 This section describes requirements for BGP, LDP, PCEP and MSDP 426 security that should be met within the routing protocol. 428 As with all routing protocols, they need protection from both on-path 429 and off-path blind attacks. A better way to protect them would be 430 with per-packet protection using a cryptographic MAC. In order to 431 provide for the MAC, keys are needed. 433 Once keys are used, mechanisms are required to support key rollover. 434 This should cover both manual and automatic key rollover. Multiple 435 approaches could be used. However since the existing mechanisms 436 provide a protocol field to identify the key as well as management 437 mechanisms to introduce and retire new keys, focusing on the existing 438 mechanism as a starting point is prudent. 440 Finally, replay protection is required. The replay mechanism needs 441 to be sufficient to prevent an attacker from creating a denial of 442 service or disrupting the integrity of the routing protocol by 443 replaying packets. It is important that an attacker not be able to 444 disrupt service by capturing packets and waiting for replay state to 445 be lost. 447 6. Acknowledgements 449 We would like to thank Brian Weis for encouraging us to write this 450 draft and providing comments on it. 452 7. References 454 7.1. Normative References 456 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 457 Signature Option", RFC 2385, August 1998. 459 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 460 for the TCP Authentication Option (TCP-AO)", RFC 5926, 461 June 2010. 463 [draft-ietf-karp-design-guide] 464 Lebovitz, G., "KARP Design Guidelines", September 2010. 466 7.2. Informative References 468 [NIST-SP800-38B] 469 Dworking, "Recommendation for Block Cipher Modes of 470 Operation: The CMAC Mode for Authentication", May 2005. 472 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 473 Hashing for Message Authentication", RFC 2104, 474 February 1997. 476 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 477 (IKE)", RFC 2409, November 1998. 479 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 480 Group Domain of Interpretation", RFC 3547, July 2003. 482 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 483 Protocol 4 (BGP-4)", RFC 4271, January 2006. 485 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 486 Specification", RFC 5036, October 2007. 488 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 489 Pignataro, "The Generalized TTL Security Mechanism 490 (GTSM)", RFC 5082, October 2007. 492 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 493 (PCE) Communication Protocol (PCEP)", RFC 5440, 494 March 2009. 496 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 497 Authentication Option", RFC 5925, June 2010. 499 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 500 Robustness to Blind In-Window Attacks", RFC 5961, 501 August 2010. 503 [draft-ietf-opsec-routing-protocols-crypto-issues] 504 Manral, "Issues with existing Cryptographic Protection 505 Methods for Routing Protocols", September 2010. 507 [draft-zheng-mpls-ldp-hello-crypto-auth-01] 508 Zheng, "LDP Hello Cryptographic Authentication", 509 March 2011. 511 Authors' Addresses 513 Mahesh Jethanandani 514 Cisco Systems, Inc 515 170 Tasman Drive 516 San Jose, CA 95134 517 USA 519 Phone: +1 (408) 527-8230 520 Email: mahesh@cisco.com 522 Keyur Patel 523 Cisco Systems, Inc 524 170 Tasman Drive 525 San Jose, CA 95134 526 USA 528 Phone: +1 (408) 526-7183 529 Email: keyupate@cisco.com 531 Lianshu Zheng 532 Huawei 533 No. 3 Xinxi Road, Hai-Dian District 534 Beijing, 100085 535 China 537 Phone: +86 (10) 82882008 538 Fax: 539 Email: verozheng@huawei.com 540 URI: