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