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