idnits 2.17.1 draft-ietf-karp-routing-tcp-analysis-05.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 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 ([RFC3618], [RFC5440], [RFC6518], [RFC5036], [RFC4271]), 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 (October 18, 2012) is 4205 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IRR' is mentioned on line 92, but not defined == Unused Reference: 'RFC2409' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'RFC3547' is defined on line 588, 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) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Working Group M. Jethanandani 3 Internet-Draft Ciena Corporation 4 Intended status: Informational K. Patel 5 Expires: April 21, 2013 Cisco Systems, Inc 6 L. Zheng 7 Huawei Technologies 8 October 18, 2012 10 Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design 11 Guide 12 draft-ietf-karp-routing-tcp-analysis-05.txt 14 Abstract 16 This document analyzes Border Gateway Protocol (BGP) [RFC4271], Label 17 Distribution Protocol (LDP) [RFC5036], Path Computation Element 18 Protocol (PCEP) [RFC5440] and Multicast Source Distribution Protocol 19 (MSDP) [RFC3618] according to guidelines set forth in section 4.2 of 20 Keying and Authentication for Routing Protocols Design Guidelines 21 [RFC6518]. 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 April 21, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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. Conventions Used in This Document . . . . . . . . . . . . 3 59 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Current Assessment of BGP, LDP, PCEP and MSDP . . . . . . . . 5 61 2.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 8 67 2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 10 70 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 11 72 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 5. Transition and Deployment Considerations . . . . . . . . . . . 13 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 In March 2006 the Internet Architecture Board (IAB) in its "Unwanted 85 Internet Traffic" workshop documented in Report from the IAB workshop 86 on Unwanted Traffic March 9-10, 2006 [RFC4948] described an attack on 87 core routing infrastructure as an ideal attack with the most amount 88 of damage. Four main steps were identified for that tightening: 90 1. Create secure mechanisms and practices for operating routers. 92 2. Clean up the Internet Routing Registry [IRR] repository, and 93 securing both the database and the access, so that it can be used 94 for routing verifications. 96 3. Create specifications for cryptographic validation of routing 97 message content. 99 4. Secure the routing protocols' packets on the wire. 101 In order to secure the routing protocols this document performs an 102 initial analysis of the current state of BGP, LDP, PCEP and MSDP 103 according to the requirements of KARP Design Guidelines [RFC6518]. 104 Section 4.2 of the document uses the term "state" which will be 105 referred to as the "state of the security method". Thus a term like 106 "Define Optimal State" would be referred to as "Define Optimal State 107 of the Security Method". This document builds on several previous 108 analysis efforts into routing security. The OPSEC working group 109 published Issues with existing Cryptographic Protection Methods for 110 Routing Protocols [RFC6039] an analysis of cryptographic issues with 111 routing protocols and Analysis of OSPF Security According to KARP 112 Design Guide [draft-ietf-karp-ospf-analysis-03]. 114 Section 2 of this document looks at the current state of security 115 method for the four routing protocols, BGP, LDP, PCEP and MSDP. 116 Section 3 examines what the optimal state of the security method 117 would be for the four routing protocols according to KARP Design 118 Guidelines [RFC6518] and Section 4 does a analysis of the gap between 119 the existing state of the security method and the optimal state of 120 the security method for protocols and suggests some areas where 121 improvement is needed. 123 1.1. Conventions Used in This Document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 1.2. Abbreviations 131 AS - Autonomous Systems 133 BGP - Border Gateway Protocol 135 DoS - Denial of Service 137 GTSM - Generalized TTL Security Mechanism 139 KARP - Key and Authentication for Routing Protocols 141 KDF - Key Derivation Function 143 KEK - Key Encrypting Key 145 KMP - Key Management Protocol 147 LDP - Label Distribution Protocol 149 LSR - Label Switch Routers 151 MAC - Message Authentication Code 153 MKT - Master Key Tuple 155 MSDP - Multicast Source Distribution Protocol 157 MD5 - Message Digest algorithm 5 159 OSPF - OPen Shortest Path First 161 PCEP - Path Computation Element Protocol 163 TCP - Transmission Control Protocol 165 TTL - Time To Live 167 UDP - User Datagram Protocol 169 2. Current Assessment of BGP, LDP, PCEP and MSDP 171 This section assesses the transport protocols for any authentication 172 or integrity mechanisms used by the protocol. It describes the 173 current security mechanisms if any used by BGP, LDP, PCEP and MSDP. 175 2.1. Transport layer 177 At a transport layer, routing protocols are subject to a variety of 178 DoS attacks as outlined in Internet Denial-of-Service Considerations 179 [RFC4732]. Such attacks can cause the routing protocol to become 180 congested with the result that routing updates are supplied too 181 slowly to be useful. In extreme cases, these attacks prevent routers 182 from converging after a change. 184 Routing protocols use several methods to protect themselves. Those 185 that use TCP as a transport protocol use access lists to accept 186 packets only from known sources. These access lists also help 187 protect edge routers from attacks originating from outside the 188 protected domain. In addition for edge routers running eBGP, TCP 189 LISTEN is run only on interfaces on which its peers have been 190 discovered or via which routing sessions are expected (as specified 191 in router configuration databases). 193 Generalized TTL Security Mechanism (GTSM) [RFC5082] describes a 194 generalized Time to Live (TTL) security mechanism to protect a 195 protocol stack from CPU-utilization based attacks.TCP Robustness 196 [RFC5961] recommends some TCP level mitigations against spoofing 197 attacks targeted towards long-lived routing protocol sessions. 199 Even when BGP, LDP, PCEP and MSDP sessions use access lists they are 200 vulnerable to spoofing and man in the middle attacks. Authentication 201 and integrity checks allow the receiver of a routing protocol update 202 to know that the message genuinely comes from the node that purports 203 to have sent it, and to know whether the message has been modified. 204 Sometimes routers can be subjected to a large number of 205 authentication and integrity requests, exhausting connection 206 resources on the router in a way that deny genuine requests. 208 TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925]. However it 209 is still widely used to authenticate TCP based routing protocols such 210 as BGP. It provides a way for carrying a MD5 digest in a TCP 211 segment. This digest acts like a signature for that segment, 212 computed using information known only to the connection end points. 213 The MD5 key used to compute the digest is stored locally on the 214 router. This option is used by routing protocols to provide for 215 session level protection against the introduction of spoofed TCP 216 segments into any existing TCP streams, in particular TCP Reset 217 segments. TCP MD5 does not provide a generic mechanism to support 218 key roll-over. 220 The Message Authentication Codes (MACs) used by the TCP MD5 option is 221 considered too weak both because of the use of the hash function and 222 because of the way the secret key used by TCP MD5 is managed. TCP-AO 223 [RFC5925] and its companion document Crypto Algorithms for TCP-AO 224 [RFC5926] describe steps towards correcting both the MAC weakness and 225 the management of secret keys. For MAC it specifies two MAC 226 algorithms that MUST be supported. They are HMAC-SHA-1-96 as 227 specified in HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST- 228 SP800-38B [NIST-SP800-38B]. Cryptographic research suggests that 229 both these MAC algorithms defined are fairly secure. TCP-AO allows 230 additional MACs to be added in the future. 232 2.2. Keying mechanisms 234 For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used 235 to manage the keys that are employed to generate the Message 236 Authentication Code (MAC). TCP-AO allows for a master key to be 237 configured manually or for it to be managed via a out of band 238 mechanism. 240 It should be noted that most routers configured with static keys have 241 not seen the key changed ever. The common reason given for not 242 changing the key is the difficulty in coordinating the change between 243 pairs of routers when using TCP MD5. It is well known that the 244 longer the same key is used, the greater the chance that it can be 245 guessed or exposed e.g. when an administrator with knowledge of the 246 keys leaves the company. 248 For point-to-point key management IKEv2 [RFC5996] provides for 249 automated key exchange under a SA and can be used for a comprehensive 250 Key Management Protocol (KMP) solution. 252 2.3. LDP 254 Section 5 of LDP [RFC5036] states that LDP is subject to two 255 different types of attacks: spoofing, and denial of service attacks. 256 In addition, LDP distributes labels in the clear, enabling hackers to 257 see what labels are being distributed. The attacker can use that 258 information to spoof a connection and distribute a different set of 259 labels causing traffic to be dropped. 261 2.3.1. Spoofing attacks 263 A spoofing attack against LDP can occur both during the discovery 264 phase and during the session communication phase. 266 2.3.1.1. Discovery exchanges using UDP 268 Label Switching Routers (LSRs) indicate their willingness to 269 establish and maintain LDP sessions by periodically sending Hello 270 messages. Receipt of a Hello message serves to create a new "Hello 271 adjacency", if one does not already exist, or to refresh an existing 272 one. 274 Unlike all other LDP messages, the Hello messages are sent using UDP. 275 This means that they cannot benefit from the security mechanisms 276 available with TCP. LDP [RFC5036] does not provide any security 277 mechanisms for use with Hello messages except for some configuration 278 which may help protect against bogus discovery events. These 279 configurations include directly connected links and interfaces. 280 Routers that do not use directly connected links have to use Extended 281 Hello messages. 283 Spoofing a Hello packet for an existing adjacency can cause the 284 adjacency to time out and result in termination of the associated 285 session. This can occur when the spoofed Hello message specifies a 286 small Hold Time, causing the receiver to expect Hello messages within 287 this interval, while the true neighbor continues sending Hello 288 messages at the lower, previously agreed to frequency. 290 Spoofing a Hello packet can also cause the LDP session to be 291 terminated. This can occur when the spoofed Hello specifies a 292 different Transport Address from the previously agreed one between 293 neighbors. Spoofed Hello messages are observed and reported as real 294 problem in production networks. 296 2.3.1.2. Session communication using TCP 298 LDP like other TCP based routing protocols specifies use of the TCP 299 MD5 Signature Option to provide for the authenticity and integrity of 300 session messages. As stated above, MD5 authentication is considered 301 too weak for this application. A stronger hashing algorithm e.g 302 SHA1, which is supported by TCP-AO [RFC5925] could be deployed to 303 take care of the weakness. 305 Alternatively, one could move to using TCP-AO which provides for 306 stronger MACs, makes it easier to setup manual keys and protects 307 against replays. 309 2.3.2. Privacy Issues 311 LDP provides no mechanism for protecting the privacy of label 312 distribution. The security requirements of label distribution are 313 similar to other routing protocols that need to distribute routing 314 information. 316 2.3.3. Denial of Service Attacks 318 LDP is subject to Denial of Service (DoS) attacks both in its 319 discovery mode and in session mode. These are documented in Section 320 5.3 of LDP [RFC5036]. 322 2.4. PCEP 324 Attacks on PCEP [RFC5440] may result in damage to active networks. 325 These include computation responses, which if changed can cause 326 protocols like LDP to setup sub-optimal or inappropriate LSPs. In 327 addition, PCE itself can be attacked by a variety of DoS attacks. 328 Such attacks can cause path computations to be supplied too slowly to 329 be of any value particularly as it relates to recovery or 330 establishment of LSPs. 332 As RFC 5440 states, PCEP could be the target of the following 333 attacks. 335 o Spoofing (PCC or PCE implementation) 337 o Snooping (message interception) 339 o Falsification 341 o Denial of Service 343 In inter-Autonomous Systems (AS) scenarios where PCE-to-PCE 344 communication is required, attacks may be particularly significant 345 with commercial as well as service-level agreement implications. 347 Additionally, snooping of PCEP requests and responses may give an 348 attacker information about the operation of the network. By viewing 349 the PCEP messages an attacker can determine the pattern of service 350 establishment in the network and can know where traffic is being 351 routed, thereby making the network susceptible to targeted attacks 352 and the data within specific LSPs vulnerable. 354 Ensuring PCEP communication privacy is of key importance, especially 355 in an inter-AS context, where PCEP communication end-points do not 356 reside in the same AS. An attacker that intercepts a PCE message 357 could obtain sensitive information related to computed paths and 358 resources. 360 2.5. MSDP 362 Similar to BGP and LDP, Multicast Source Distribution Protocol (MSDP) 363 uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5 364 option. But with a weak MD5 authentication, TCP MD5 is not 365 considered strong enough for this application. 367 MSDP also advocates imposing a limit on number of source address and 368 group addresses (S,G) that can be cached within the protocol and 369 thereby mitigate state explosion due to any denial of service and 370 other attacks. 372 3. Optimal State for BGP, LDP, PCEP, and MSDP 374 The ideal state of the security method for BGP, LDP, PCEP and MSDP 375 protocols are when they can withstand any of the known types of 376 attacks. 378 Additionally, Key Management Protocol (KMP) for the routing sessions 379 should help negotiate unique, pair wise random keys without 380 administrator involvement. It should also negotiate Security 381 Association (SA) parameter required for the session connection, 382 including key life times. It should keep track of those lifetimes 383 and negotiate new keys and parameters before they expire and do so 384 without administrator involvement. In the event of a breach, 385 including when an administrator with knowledge of the keys leaves the 386 company, the keys should be changed immediately. 388 The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the 389 transport protocol, TCP for the most part and UDP in case of 390 discovery phase of LDP. TCP and UDP should be able to withstand any 391 of DoS scenarios by dropping packets that are attack packets in a way 392 that does not impact legitimate packets. 394 The routing protocols should provide a mechanism to authenticate the 395 routing information carried within the payload. 397 3.1. LDP 399 To harden LDP against its current vulnerability to spoofing attacks, 400 LDP needs to be upgraded such that an implementation is able to 401 determine the authenticity of the neighbors sending the Hello 402 message. 404 There is currently no requirement to protect the privacy of label 405 distribution as labels are carried in the clear like other routing 406 information. 408 4. Gap Analysis for BGP, LDP, PCEP and MSDP 410 This section outlines the differences between the current state of 411 the security methods for routing protocols and the desired state of 412 the security methods as outlined in section 4.2 of KARP Design 413 Guidelines [RFC6518]. As that document states, these routing 414 protocols fall into the category of one-to-one peering messages and 415 will use peer keying protocol. It covers issues that are common to 416 the four protocols in this section, leaving protocol specific issues 417 to sub-sections. 419 At a transport level these routing protocols are subject to some of 420 the same attacks that TCP applications are subject to. These include 421 DoS and spoofing attacks. Internet Denial-of-Service Considerations 422 [RFC4732] outlines some solutions. Defending TCP Against Spoofing 423 Attacks [RFC4953] recommends ways to prevent spoofing attacks. In 424 addition Improving TCP's Robustness to Blind In-Window Attacks. 425 [RFC5961] should also be followed and implemented to strengthen TCP. 427 Routers lack comprehensive key management and keys derived from it 428 that they can use to authenticate data. As an example TCP-AO 429 [RFC5925], talks about coordinating keys derived from Master Key 430 Table (MKT) between endpoints, but the MKT itself has to be 431 configured manually or through an out of band mechanism. Also TCP-AO 432 does not address the issue of connectionless reset, as it applies to 433 routers that do not store MKT across reboots. 435 Authentication, tamper protection, and encryption all require the use 436 of keys by sender and receiver. An automated KMP therefore has to 437 include a way to distribute MKT between two end points with little or 438 no administration overhead. It has to cover automatic key rollover. 439 It is expected that authentication will cover the packet, i.e. the 440 payload and the TCP header and will not cover the frame i.e. the link 441 layer 2 header. 443 There are two methods of automatic key rollover. Implicit key 444 rollover can be initiated after certain volume of data gets exchanged 445 or when a certain time has elapsed. This does not require explicit 446 signaling nor should it result in a reset of the TCP connection in a 447 way that the links/adjacencies are affected. On the other hand, 448 explicit key rollover requires an out of band key signaling 449 mechanism. It can be triggered by either side and can be done 450 anytime a security parameter changes e.g. an attack has happened, or 451 a system administrator with access to the keys has left the company. 452 An example of this is IKEv2 [RFC5996] but it could be any other new 453 mechanisms also. 455 As stated earlier TCP-AO [RFC5925] and its accompanying document 456 Crypto Algorithms for TCP-AO [RFC5926] suggest that two MAC 457 algorithms that MUST be supported are HMAC-SHA-1-96 as specified in 458 HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST-SP800-38B 459 [NIST-SP800-38B]. 461 There is a need to protect authenticity and validity of the routing/ 462 label information that is carried in the payload of the sessions. 463 However, that is outside the scope of this document and is being 464 addressed by SIDR WG. Similar mechanisms could be used for intra- 465 domain protocols. 467 4.1. LDP 469 As described in LDP [RFC5036], the threat of spoofed Basic Hellos can 470 be reduced by only accepting Basic Hellos on interfaces that LSRs 471 trust, employing GTSM [RFC5082] and ignoring Basic Hellos not 472 addressed to the "all routers on this subnet" multicast group. 473 Spoofing attacks via Targeted Hellos are potentially a more serious 474 threat. An LSR can reduce the threat of spoofed Extended Hellos by 475 filtering them and accepting Hellos from sources permitted by an 476 access lists. However, performing the filtering using access lists 477 requires LSR resource, and the LSR is still vulnerable to the IP 478 source address spoofing. Spoofing attacks can be solved by being 479 able to authenticate the Hello messages, and an LSR can be configured 480 to only accept Hello messages from specific peers when authentication 481 is in use. 483 LDP Hello Cryptographic Authentication 484 [draft-zheng-mpls-ldp-hello-crypto-auth-04] suggest a new 485 Cryptographic Authentication TLV that can be used as an 486 authentication mechanism to secure Hello messages. 488 4.2. PCEP 490 Path Computation Element (PCE) discovery according to its RFC 491 [RFC5440] is a significant feature for the successful deployment of 492 PCEP in large networks. This mechanism allows a Path Computation 493 Client (PCC) to discover the existence of suitable PCEs within the 494 network without the necessity of configuration. It should be obvious 495 that, where PCEs are discovered and not configured, the PCC cannot 496 know the correct key to use. There are different approaches to 497 retain some aspect of security, but all of them require use of a keys 498 and a keying mechanism, the need for which has been discussed above. 500 5. Transition and Deployment Considerations 502 As stated in KARP Design Guidelines [RFC6518] it is imperative that 503 the new authentication and security mechanisms defined support 504 incremental deployment, as it is not feasible to deploy the new 505 routing protocol authentication mechanism overnight. 507 Typically authentication and security in a peer-to-peer protocol 508 requires that both parties agree to the mechanisms that will be used. 509 If an agreement is not reached the setup of the new mechanism will 510 fail or will be deferred. Upon failure, the routing protocols can 511 fallback to the mechanisms that were already in place e.g. use static 512 keys if that was the mechanism in place. It is usually not possible 513 for one end to use the new mechanism while the other end uses the 514 old. Policies can be put in place to retry upgrading after a said 515 period of time, so a manual coordination is not required. 517 If the automatic KMP requires use of public/private keys to exchange 518 key material, the required CA root certificates may need to be 519 installed to verify authenticity of requests initiated by a peer. 520 Such a step does not require coordination with the peer except to 521 decide what CA authority will be used. 523 6. Security Considerations 525 This section describes security considerations that BGP, LDP, PCEP 526 and MSDP should try to meet. 528 As with all routing protocols, they need protection from both on-path 529 and off-path blind attacks. A better way to protect them would be 530 with per-packet protection using a cryptographic MAC. In order to 531 provide for the MAC, keys are needed. 533 Once keys are used, mechanisms are required to support key rollover. 534 This should cover both manual and automatic key rollover. Multiple 535 approaches could be used. However since the existing mechanisms 536 provide a protocol field to identify the key as well as management 537 mechanisms to introduce and retire new keys, focusing on the existing 538 mechanism as a starting point is prudent. 540 Finally, replay protection is required. The replay mechanism needs 541 to be sufficient to prevent an attacker from creating a denial of 542 service or disrupting the integrity of the routing protocol by 543 replaying packets. It is important that an attacker not be able to 544 disrupt service by capturing packets and waiting for replay state to 545 be lost. 547 7. Acknowledgements 549 We would like to thank Brian Weis for encouraging us to write this 550 draft and to Anantha Ramaiah and Mach Chen for providing comments on 551 it. 553 8. References 555 8.1. Normative References 557 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 558 Signature Option", RFC 2385, August 1998. 560 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 561 for the TCP Authentication Option (TCP-AO)", RFC 5926, 562 June 2010. 564 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 565 Routing Protocols (KARP) Design Guidelines", RFC 6518, 566 February 2012. 568 [draft-ietf-karp-threats-reqs] 569 Lebovitz, G. and M. Bhatia, "KARP Threats and 570 Requirements", March 2012. 572 8.2. Informative References 574 [NIST-SP800-38B] 575 Dworking, "Recommendation for Block Cipher Modes of 576 Operation: The CMAC Mode for Authentication", May 2005. 578 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 579 Hashing for Message Authentication", RFC 2104, 580 February 1997. 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 586 (IKE)", RFC 2409, November 1998. 588 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 589 Group Domain of Interpretation", RFC 3547, July 2003. 591 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 592 Protocol (MSDP)", RFC 3618, October 2003. 594 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 595 Protocol 4 (BGP-4)", RFC 4271, January 2006. 597 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 598 Service Considerations", RFC 4732, December 2006. 600 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 601 IAB workshop on Unwanted Traffic March 9-10, 2006", 602 RFC 4948, August 2007. 604 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 605 RFC 4953, July 2007. 607 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 608 Specification", RFC 5036, October 2007. 610 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 611 Pignataro, "The Generalized TTL Security Mechanism 612 (GTSM)", RFC 5082, October 2007. 614 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 615 (PCE) Communication Protocol (PCEP)", RFC 5440, 616 March 2009. 618 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 619 Authentication Option", RFC 5925, June 2010. 621 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 622 Robustness to Blind In-Window Attacks", RFC 5961, 623 August 2010. 625 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 626 "Internet Key Exchange Protocol Version 2 (IKEv2)", 627 RFC 5996, September 2010. 629 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 630 with Existing Cryptographic Protection Methods for Routing 631 Protocols", RFC 6039, October 2010. 633 [draft-ietf-karp-ospf-analysis-03] 634 Hartman, S., "Analysis of OSPF Security According to KARP 635 Design Guide", March 2012. 637 [draft-zheng-mpls-ldp-hello-crypto-auth-04] 638 Zheng, "LDP Hello Cryptographic Authentication", May 2012. 640 Authors' Addresses 642 Mahesh Jethanandani 643 Ciena Corporation 644 1741 Technology Drive 645 San Jose, CA 95110 646 USA 648 Phone: + (408) 436-3313 649 Email: mjethanandani@gmail.com 651 Keyur Patel 652 Cisco Systems, Inc 653 170 Tasman Drive 654 San Jose, CA 95134 655 USA 657 Phone: +1 (408) 526-7183 658 Email: keyupate@cisco.com 660 Lianshu Zheng 661 Huawei Technologies 662 China 664 Phone: +86 (10) 82882008 665 Fax: 666 Email: vero.zheng@huawei.com 667 URI: