idnits 2.17.1 draft-ietf-karp-routing-tcp-analysis-04.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], [RFC6518]), 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 (July 30, 2012) is 4288 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IRR' is mentioned on line 93, but not defined == Unused Reference: 'RFC2409' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC3547' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 574, 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: 4 errors (**), 0 flaws (~~), 5 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: January 31, 2013 Cisco Systems, Inc 6 L. Zheng 7 Huawei 8 July 30, 2012 10 Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design 11 Guide 12 draft-ietf-karp-routing-tcp-analysis-04.txt 14 Abstract 16 This document analyzes BGP, LDP, PCEP and MSDP according to 17 guidelines set forth in section 4.2 of Keying and Authentication for 18 Routing Protocols Design Guidelines [RFC6518]. 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119].. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 31, 2013. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 60 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Current State of BGP, LDP, PCEP and MSDP . . . . . . . . . . . 5 62 2.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. Keying mechanisms . . . . . . . . . . . . . . . . . . . . 6 64 2.3. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 6 66 2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 7 67 2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 8 68 2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 10 71 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 11 73 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5. Transition and Deployment Considerations . . . . . . . . . . . 13 76 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 14 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 In March 2006 the Internet Architecture Board (IAB) in its "Unwanted 86 Internet Traffic" workshop documented in Report from the IAB workshop 87 on Unwanted Traffic March 9-10, 2006 [RFC4948] described an attack on 88 core routing infrastructure as an ideal attack with the most amount 89 of damage. Four main 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 This document looking at the last bullet performs an initial analysis 103 of the current state of BGP, LDP, PCEP and MSDP according to the 104 requirements of KARP Design Guidelines [RFC6518]. This draft builds 105 on several previous analysis efforts into routing security. The 106 OPSEC working group published Issues with existing Cryptographic 107 Protection Methods for Routing Protocols [RFC6039] an analysis of 108 cryptographic issues with routing protocols and Analysis of OSPF 109 Security According to KARP Design Guide 110 [draft-ietf-karp-ospf-analysis-03]. 112 Section 2 of this document looks at the current state of security for 113 the four routing protocols. Section 3 examines what the optimal 114 state would be for the four routing protocols according to KARP 115 Design Guidelines [RFC6518] and Section 4 does a analysis of the gap 116 between the existing state and the optimal state of the protocols and 117 suggests some areas where improvement is needed. 119 1.1. Contributing Authors 121 Anantha Ramaiah, Mach Chen 123 1.2. Abbreviations 125 BGP - Border Gateway Protocol 127 DoS - Denial of Service 129 KARP - Key and Authentication for Routing Protocols 130 KDF - Key Derivation Function 132 KEK - Key Encrypting Key 134 KMP - Key Management Protocol 136 LDP - Label Distribution Protocol 138 LSR - Label Switch Routers 140 MAC - Message Authentication Code 142 MKT - Master Key Tuple 144 MSDP - Multicast Source Distribution Protocol 146 MD5 - Message Digest algorithm 5 148 OSPF - OPen Shortest Path First 150 PCEP - Path Computation Element Protocol 152 TCP - Transmission Control Protocol 154 UDP - User Datagram Protocol 156 2. Current State of BGP, LDP, PCEP and MSDP 158 This section looks at the current state of transport protocol and any 159 authentication mechanisms used by the protocol. It describes the 160 current security mechanisms if any used by BGP, LDP, PCEP and MSDP. 162 2.1. Transport layer 164 At a transport layer, routing protocols are subject to a variety of 165 DoS attacks as outlined in Internet Denial-of-Service Considerations 166 [RFC4732]. Such attacks can cause the routing protocol to become 167 congested with the result that routing updates are supplied too 168 slowly to be useful. In extreme cases, these attacks prevent routes 169 from converging after a change. 171 Routing protocols use several methods to protect themselves. Those 172 that use TCP as a transport protocol use access lists to accept 173 packets only from known sources. These access lists also help 174 protect edge routers from attacks originating from outside the 175 protected domain. In addition for edge routers running eBGP, TCP 176 LISTEN is run only on interfaces on which its peers have been 177 discovered or via which routing sessions are expected (as specified 178 in router configuration databases). 180 GTSM [RFC5082] describes a generalized Time to Live (TTL) security 181 mechanism to protect a protocol stack from CPU-utilization based 182 attacks.TCP Robustness [RFC5961] recommends some TCP level 183 mitigations against spoofing attacks targeted towards long-lived 184 routing protocol sessions. 186 Even when BGP, LDP, PCEP and MSDP sessions use access lists they are 187 subject to spoofing and man in the middle attacks. Authentication 188 and integrity checks allow the receiver of a routing protocol update 189 to know that the message genuinely comes from the node that purports 190 to have sent it, and to know whether the message has been modified. 191 Sometimes routers can be subjected to a large number of 192 authentication and integrity requests, exhausting connection 193 resources on the router in a way that deny genuine requests. 195 TCP MD5 [RFC2385] deprecated, but widely used, specifies a mechanism 196 to protect BGP and other TCP based routing protocols via the TCP MD5 197 option. TCP MD5 option provides a way for carrying an MD5 digest in 198 a TCP segment. This digest acts like a signature for that segment, 199 computed using information known only to the connection end points. 200 The MD5 key used to compute the digest is stored locally on the 201 router. This option is used by routing protocols to provide for 202 session level protection against the introduction of spoofed TCP 203 segments into any existing TCP streams, in particular TCP Reset 204 segments. TCP MD5 does not provide a generic mechanism to support 205 key roll-over. 207 The Message Authentication Codes (MACs) used by the TCP MD5 option is 208 considered too weak both because of the use of the hash function and 209 because of the way the secret key used by TCP MD5 is managed. TCP-AO 210 [RFC5925] and its companion document Crypto Algorithms for TCP-AO 211 [RFC5926] describe steps towards correcting both the MAC weakness and 212 the management of secret keys. For MAC it specifies two MAC 213 algorithms that MUST be supported. They are HMAC-SHA-1-96 as 214 specified in HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST- 215 SP800-38B [NIST-SP800-38B]. Cryptographic research suggests that 216 both these MAC algorithms defined are fairly secure. TCP-AO allows 217 additional MACs to be added in the future. 219 2.2. Keying mechanisms 221 For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used 222 to manage the keys that are employed to generate the Message 223 Authentication Code (MAC). TCP-AO allows for a master key to be 224 configured manually or for it to be managed via a out of band 225 mechanism. 227 It should be noted that most routers configured with static keys have 228 not seen the key changed ever. The common reason given for not 229 changing the key is the difficulty in coordinating the change between 230 pairs of routers when using TCP MD5. It is well known that longer 231 the same key is used, higher is the chance that it can be guessed or 232 exposed e.g. when an administrator with knowledge of the keys leaves 233 the company. 235 For point-to-point key management IKEv2 [RFC5996] provides for 236 automated key exchange under a SA and can be used for a comprehensive 237 Key Management Protocol (KMP) solution. 239 2.3. LDP 241 Section 5 of LDP [RFC5036] states that LDP is subject to two 242 different types of attacks: spoofing, and denial of service attacks. 243 In addition, labels are distributed in the clear, enabling hackers to 244 see what labels are being exchanged that could then be used to launch 245 an attack. 247 2.3.1. Spoofing attacks 249 A spoofing attack against LDP can occur both during the discovery 250 phase and during the session communication phase. 252 2.3.1.1. Discovery exchanges using UDP 254 Label Switching Routers (LSRs) indicate their willingness to 255 establish and maintain LDP sessions by periodically sending Hello 256 messages. Receipt of a Hello message serves to create a new "Hello 257 adjacency", if one does not already exist, or to refresh an existing 258 one. 260 Unlike all other LDP messages, the Hello messages are sent using UDP. 261 This means that they cannot benefit from the security mechanisms 262 available with TCP. LDP [RFC5036] does not provide any security 263 mechanisms for use with Hello messages except for some configuration 264 which may help protect against bogus discovery events. These 265 configurations include directly connected links and interfaces. 266 Routers that do not use directly connected links have to use Extended 267 Hello messages. 269 Spoofing a Hello packet for an existing adjacency can cause the 270 adjacency to time out and result in termination of the associated 271 session. This can occur when the spoofed Hello message specifies a 272 small Hold Time, causing the receiver to expect Hello messages within 273 this interval, while the true neighbor continues sending Hello 274 messages at the lower, previously agreed to frequency. 276 Spoofing a Hello packet can also cause the LDP session to be 277 terminated. This can occur when the spoofed Hello specifies a 278 different Transport Address from the previously agreed one between 279 neighbors. Spoofed Hello messages are observed and reported as real 280 problem in production networks. 282 2.3.1.2. Session communication using TCP 284 LDP like other TCP based routing protocols specifies use of the TCP 285 MD5 Signature Option to provide for the authenticity and integrity of 286 session messages. As stated above, MD5 authentication is considered 287 too weak for this application. A stronger hashing algorithm e.g 288 SHA1, which is supported by TCP-AO [RFC5925] could be deployed to 289 take care of the weakness. 291 Alternatively, one could move to using TCP-AO which provides for 292 stronger MACs, makes it easier to setup manual keys and protects 293 against replays. 295 2.3.2. Privacy Issues 297 LDP provides no mechanism for protecting the privacy of label 298 distribution. The security requirements of label distribution are 299 similar to other routing protocols that need to distribute routing 300 information and as such LDP is vulnerable to the same extent as other 301 routing protocols that distribute their routing information in the 302 clear. 304 2.3.3. Denial of Service Attacks 306 LDP is subject to Denial of Service (DoS) attacks both in its 307 discovery mode and in session mode. 309 The discovery mode attack is similar to the spoofing attack except 310 that when the spoofed Hello messages are sent with a high enough 311 frequency, it can cause the adjacency to time out. 313 2.4. PCEP 315 Attacks on PCEP [RFC5440] may result in damage to active networks. 316 These include computation responses, which if changed can cause 317 protocols like LDP to setup sub-optimal or inappropriate LSPs. In 318 addition, PCE itself can be attacked by a variety of DoS attacks. 319 Such attacks can cause path computations to be supplied too slowly to 320 be of any value particularly as it relates to recovery or 321 establishment of LSPs. 323 As the RFC states, PCEP could be the target of the following attacks. 325 o Spoofing (PCC or PCE implementation) 327 o Snooping (message interception) 329 o Falsification 331 o Denial of Service 333 According to the RFC, inter-AS scenarios when PCE-to-PCE 334 communication is required, attacks may be particularly significant 335 with commercial as well as service-level implications. 337 Additionally, snooping of PCEP requests and responses may give an 338 attacker information about the operation of the network. By viewing 339 the PCEP messages an attacker can determine the pattern of service 340 establishment in the network and can know where traffic is being 341 routed, thereby making the network susceptible to targeted attacks 342 and the data within specific LSPs vulnerable. 344 Ensuring PCEP communication privacy is of key importance, especially 345 in an inter-AS context, where PCEP communication end-points do not 346 reside in the same AS. An attacker that intercepts a PCE message 347 could obtain sensitive information related to computed paths and 348 resources. 350 2.5. MSDP 352 Similar to BGP and LDP, MSDP uses TCP MD5 [RFC2385] to protect TCP 353 sessions via the TCP MD5 option. But with a weak MD5 authentication, 354 TCP MD5 is not considered strong enough for this application. 356 MSDP also advocates imposing a limit on number of source address and 357 group addresses (S,G) that can be stored within the protocol and 358 thereby mitigate state explosion due to any denial of service and 359 other attacks. 361 3. Optimal State for BGP, LDP, PCEP, and MSDP 363 The ideal state for BGP, LDP, PCEP and MSDP protocols are when they 364 can withstand any of the known types of attacks. 366 Additionally, Key Management Protocol (KMP) for the routing sessions 367 should help negotiate unique, pair wise random keys without 368 administrator involvement. It should also negotiate Security 369 Association (SA) parameter required for the session connection, 370 including key life times. It should keep track of those lifetimes 371 and negotiate new keys and parameters before they expire and do so 372 without administrator involvement. In the event of a breach, 373 including when an administrator with knowledge of the keys leaves the 374 company, the keys should be changed immediately. 376 The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the 377 transport protocol, TCP for the most part and UDP in case of 378 discovery phase of LDP. TCP and UDP should be able to withstand any 379 of DoS scenarios by dropping packets that are attack packets in a way 380 that does not impact legitimate packets. 382 The routing protocols should provide a mechanism to authenticate the 383 routing information carried within the payload. 385 3.1. LDP 387 For spoofing attacks that LDP is vulnerable to during the discovery 388 phase, LDP should be able to determine the authenticity of the 389 neighbors sending the Hello message. 391 There is currently no requirement to protect the privacy of label 392 distribution as labels are carried in the clear like other routing 393 information. 395 4. Gap Analysis for BGP, LDP, PCEP and MSDP 397 This section outlines the differences between the current state of 398 the routing protocol and the desired state as outlined in section 4.2 399 of KARP Design Guidelines [RFC6518]. As that document states, these 400 routing protocols fall into the category of one-to-one peering 401 messages and will use peer keying protocol. It covers issues that 402 are common to the four protocols in this section, leaving protocol 403 specific issues to sub-sections. 405 At a transport level the routing protocols are subject to some of the 406 same attacks that TCP applications are subject to. These include DoS 407 and spoofing attacks. Internet Denial-of-Service Considerations 408 [RFC4732] outlines some solutions. Defending TCP Against Spoofing 409 Attacks [RFC4953] recommends ways to prevent spoofing attacks. In 410 addition Improving TCP's Robustness to Blind In-Window Attacks. 411 [RFC5961] should also be followed and implemented to strengthen TCP. 413 From a security perspective there is lack of comprehensive KMP. As 414 an example TCP-AO [RFC5925], talks about coordinating keys derived 415 from MKT between endpoints, but the MKT itself has to be configured 416 manually or through a out of band mechanism. Also TCP-AO does not 417 address the issue of connectionless reset, as it applies to routers 418 that do not store MKT across reboots. 420 Authentication, tamper protection, and encryption all require the use 421 of keys by sender and receiver. An automated KMP therefore has to 422 include a way to distribute MKT between two end points with little or 423 no administration overhead. It has to cover automatic key rollover. 424 It is expected that authentication will cover the packet, i.e. the 425 payload and the TCP header and will not cover the frame i.e. the link 426 layer 2 header. 428 There are two methods of automatic key rollover. Implicit key 429 rollover can be initiated after certain volume of data gets exchanged 430 or when a certain time has elapsed. This does not require explicit 431 signaling nor should it result in a reset of the TCP connection in a 432 way that the links/adjacencies are affected. On the other hand, 433 explicit key rollover requires a out of band key signaling mechanism. 434 It can be triggered by either side and can be done anytime a security 435 parameter changes e.g. an attack has happened, or a system 436 administrator with access to the keys has left the company. An 437 example of this is IKEv2 [RFC5996] but it could be any other new 438 mechanisms also. 440 As stated earlier TCP-AO [RFC5925] and its accompanying document 441 Crypto Algorithms for TCP-AO [RFC5926] suggest that two MAC 442 algorithms that MUST be supported are HMAC-SHA-1-96 as specified in 443 HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST-SP800-38B 444 [NIST-SP800-38B]. 446 There is a need to protect authenticity and validity of the routing/ 447 label information that is carried in the payload of the sessions. 448 However, that is outside the scope of this document at this time and 449 is being addressed by SIDR WG. Similar mechanisms could be used for 450 intra-domain protocols. 452 4.1. LDP 454 As described in LDP [RFC5036], the threat of spoofed Basic Hellos can 455 be reduced by accepting Basic Hellos on interfaces that LSRs trust, 456 employing GTSM [RFC5082] and ignoring Basic Hellos not addressed to 457 the "all routers on this subnet" multicast group. Spoofing attacks 458 via Extended Hellos are potentially a more serious threat. An LSR 459 can reduce the threat of spoofed Extended Hellos by filtering them 460 and accepting Hellos from sources permitted by an access lists. 461 However, performing the filtering using access lists requires LSR 462 resource, and the LSR is still vulnerable to the IP source address 463 spoofing. Spoofing attacks can be solved by being able to 464 authenticate the Hello messages, and an LSR can be configured to only 465 accept Hello messages from specific peers when authentication is in 466 use. 468 LDP Hello Cryptographic Authentication 469 [draft-zheng-mpls-ldp-hello-crypto-auth-04] suggest a new 470 Cryptographic Authentication TLV that can be used as an 471 authentication mechanism to secure Hello messages. 473 4.2. PCEP 475 PCE discovery according to its RFC is a significant feature for the 476 successful deployment of PCEP in large networks. This mechanism 477 allows a PCC to discover the existence of suitable PCEs within the 478 network without the necessity of configuration. It should be obvious 479 that, where PCEs are discovered and not configured, the PCC cannot 480 know the correct key to use. There are different approaches to 481 retain some aspect of security, but all of them require use of a keys 482 and a keying mechanism, the need for which has been discussed above. 484 5. Transition and Deployment Considerations 486 As stated in KARP Design Guidelines [RFC6518] it is imperative that 487 the new authentication and security mechanisms defined support 488 incremental deployment, as it is not feasible to deploy the new 489 routing protocol authentication mechanism overnight. 491 Typically authentication and security in a peer-to-peer protocol 492 requires that both parties agree to the mechanisms that will be used. 493 If an agreement is not reached the setup of the new mechanism will 494 fail or will be deferred. Upon failure, the routing protocols can 495 fallback to the mechanisms that were already in place e.g. use static 496 keys if that was the mechanism in place. It is usually not possible 497 for one end to use the new mechanism while the other end uses the 498 old. Policies can be put in place to retry upgrading after a said 499 period of time, so a manual coordination is not required. 501 If the automatic KMP requires use of public/private keys to exchange 502 key material, the required CA root certificates may need to be 503 installed to verify authenticity of requests initiated by a peer. 504 Such a step does not require coordination with the peer except to 505 decide what CA authority will be used. 507 6. Security Requirements 509 This section describes requirements for BGP, LDP, PCEP and MSDP 510 security that should be met within the routing protocol. 512 As with all routing protocols, they need protection from both on-path 513 and off-path blind attacks. A better way to protect them would be 514 with per-packet protection using a cryptographic MAC. In order to 515 provide for the MAC, keys are needed. 517 Once keys are used, mechanisms are required to support key rollover. 518 This should cover both manual and automatic key rollover. Multiple 519 approaches could be used. However since the existing mechanisms 520 provide a protocol field to identify the key as well as management 521 mechanisms to introduce and retire new keys, focusing on the existing 522 mechanism as a starting point is prudent. 524 Finally, replay protection is required. The replay mechanism needs 525 to be sufficient to prevent an attacker from creating a denial of 526 service or disrupting the integrity of the routing protocol by 527 replaying packets. It is important that an attacker not be able to 528 disrupt service by capturing packets and waiting for replay state to 529 be lost. 531 7. Acknowledgements 533 We would like to thank Brian Weis for encouraging us to write this 534 draft and providing comments on it. 536 8. References 538 8.1. Normative References 540 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 541 Signature Option", RFC 2385, August 1998. 543 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 544 for the TCP Authentication Option (TCP-AO)", RFC 5926, 545 June 2010. 547 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 548 Routing Protocols (KARP) Design Guidelines", RFC 6518, 549 February 2012. 551 [draft-ietf-karp-threats-reqs] 552 Lebovitz, G. and M. Bhatia, "KARP Threats and 553 Requirements", March 2012. 555 8.2. Informative References 557 [NIST-SP800-38B] 558 Dworking, "Recommendation for Block Cipher Modes of 559 Operation: The CMAC Mode for Authentication", May 2005. 561 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 562 Hashing for Message Authentication", RFC 2104, 563 February 1997. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", BCP 14, RFC 2119, March 1997. 568 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 569 (IKE)", RFC 2409, November 1998. 571 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 572 Group Domain of Interpretation", RFC 3547, July 2003. 574 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 575 Protocol 4 (BGP-4)", RFC 4271, January 2006. 577 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 578 Service Considerations", RFC 4732, December 2006. 580 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 581 IAB workshop on Unwanted Traffic March 9-10, 2006", 582 RFC 4948, August 2007. 584 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 585 RFC 4953, July 2007. 587 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 588 Specification", RFC 5036, October 2007. 590 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 591 Pignataro, "The Generalized TTL Security Mechanism 592 (GTSM)", RFC 5082, October 2007. 594 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 595 (PCE) Communication Protocol (PCEP)", RFC 5440, 596 March 2009. 598 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 599 Authentication Option", RFC 5925, June 2010. 601 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 602 Robustness to Blind In-Window Attacks", RFC 5961, 603 August 2010. 605 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 606 "Internet Key Exchange Protocol Version 2 (IKEv2)", 607 RFC 5996, September 2010. 609 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 610 with Existing Cryptographic Protection Methods for Routing 611 Protocols", RFC 6039, October 2010. 613 [draft-ietf-karp-ospf-analysis-03] 614 Hartman, S., "Analysis of OSPF Security According to KARP 615 Design Guide", March 2012. 617 [draft-zheng-mpls-ldp-hello-crypto-auth-04] 618 Zheng, "LDP Hello Cryptographic Authentication", May 2012. 620 Authors' Addresses 622 Mahesh Jethanandani 623 Ciena Corporation 624 1741 Technology Drive 625 San Jose, CA 95110 626 USA 628 Phone: + (408) 436-3313 629 Email: mjethanandani@gmail.com 631 Keyur Patel 632 Cisco Systems, Inc 633 170 Tasman Drive 634 San Jose, CA 95134 635 USA 637 Phone: +1 (408) 526-7183 638 Email: keyupate@cisco.com 640 Lianshu Zheng 641 Huawei 642 No. 3 Xinxi Road, Hai-Dian District 643 Beijing, 100085 644 China 646 Phone: +86 (10) 82882008 647 Fax: 648 Email: verozheng@huawei.com 649 URI: