idnits 2.17.1 draft-ietf-karp-routing-tcp-analysis-02.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 (June 23, 2012) is 4325 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: 'RFC3547' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 564, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 4 errors (**), 0 flaws (~~), 4 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: December 25, 2012 Cisco Systems, Inc 6 L. Zheng 7 Huawei 8 June 23, 2012 10 Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design 11 Guide 12 draft-ietf-karp-routing-tcp-analysis-02.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 December 25, 2012. 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 level . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 7 68 2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 9 71 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 10 73 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Transition and Deployment Considerations . . . . . . . . . . . 12 76 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 13 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 the initial 103 analysis of the current state of BGP, LDP, PCEP and MSDP according to 104 the requirements of KARP Design Guidelines [RFC6518]. This draft 105 builds on several previous analysis efforts into routing security. 106 The OPSEC working group put together Issues with existing 107 Cryptographic Protection Methods for Routing Protocols [RFC6039] an 108 analysis of cryptographic issues with routing protocols and Analysis 109 of OSPF Security According to KARP Design Guide 110 [draft-ietf-karp-ospf-analysis-03]. 112 Section 2 looks at the current state of the four routing protocols. 113 Section 3 goes into what the optimal state would be for the three 114 routing protocols according to KARP Design Guidelines [RFC6518] and 115 Section 4 does a analysis of the gap between the existing state and 116 the optimal state of the protocols and suggest some areas where we 117 need to improve. 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 underlying transport protocol and key 159 mechanisms built for the protocol. It describes the security 160 mechanisms built into BGP, LDP, PCEP and MSDP. 162 2.1. Transport level 164 At a transport level, routing protocols are subject to a variety of 165 DoS attacks. Such attacks can cause the routing protocol to become 166 congested with the result that routing updates are supplied too 167 slowly to be useful or in extreme case prevent route convergence 168 after a change. 170 Routing protocols use several methods to protect themselves. Those 171 that run use TCP as a transport protocol use access list to permit 172 packets from know sources only. These access lists also help edge 173 routers from attacks originating from outside the protected cloud. 174 In addition for edge routers running eBGP, TCP LISTEN is run only on 175 interfaces on which its peers have been discovered or that are 176 configured to expect routing sessions on. 178 GTSM [RFC5082] describes a generalized Time to Live (TTL) security 179 mechanism to protect a protocol stack from CPU-utilization based 180 attacks.TCP Robustness [RFC5961] recommends some TCP level 181 mitigations against spoofing attacks targeted towards long lived 182 routing protocol sessions. 184 Even when BGP, LDP, PCEP and MSDP sessions use access list they are 185 subject to spoofing and man in the middle attacks. Authentication 186 and integrity checks allow the receiver of a routing protocol update 187 to know that the message genuinely comes from the node that purports 188 to have sent it and to know whether the message has been modified. 189 Sometimes routers can be subjected to a large number of 190 authentication and integrity checks which can result in genuine 191 requests failing. 193 TCP MD5 [RFC2385] specifies a mechanism to protect BGP and other TCP 194 based routing protocols via the TCP MD5 option. TCP MD5 option 195 provides a way for carrying an MD5 digest in a TCP segment. This 196 digest acts like a signature for that segment, incorporating 197 information known only to the connection end points. The MD5 key 198 used to compute the digest is stored locally on the router. This 199 option is used by routing protocols to provide for session level 200 protection against the introduction of spoofed TCP segments into any 201 existing TCP streams, in particular TCP Reset segments. TCP MD5 does 202 not provide a generic mechanism to support key roll-over. 204 However, the Message Authentication Codes (MACs) used by MD5 to 205 compute the signature are considered to be too weak. TCP-AO 206 [RFC5925] and its companion document Crypto Algorithms for TCP-AO 207 [RFC5926] describe steps towards correcting both the MAC weakness and 208 KMP. For MAC it specifies two MAC algorithms that MUST be supported. 209 They are HMAC-SHA-1-96 as specified in HMAC [RFC2104] and AES-128- 210 CMAC-96 as specified in NIST-SP800-38B [NIST-SP800-38B]. 211 Cryptographic research suggests that both these MAC algorithms 212 defined are fairly secure and are not known to be broken in any ways. 213 It also provides for additional MACs to be added in the future. 215 2.2. Keying mechanisms 217 For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used 218 to manage the keys that are used for generating the Message 219 Authentication Code (MAC). It allows for a master key to be 220 configured manually or for it to be managed from a out of band 221 mechanism. Most routers are configured with a static key that does 222 not change over the life of the session. 224 It should also be mentioned that those routers that have been 225 configured with static keys have not seen the key changed. The 226 common reason given for not changing the key is the difficulty in 227 coordinating the change, at least with TCP MD5. It is well known 228 that longer the same key is used, higher is the chance that it can be 229 guessed, particularly if it is not a strong key. 231 For point-to-point key management IKE [RFC2409] tries to solve the 232 issue of key exchange under a SA. 234 2.3. LDP 236 Section 5 of LDP [RFC5036] states that LDP is subject to three 237 different types of attacks. These are spoofing, protection of 238 privacy of label distribution and denial of service attacks. 240 2.3.1. Spoofing attacks 242 Spoofing attack for LDP occur both during the discovery phase and 243 during the session communication phase. 245 2.3.1.1. Discovery exchanges using UDP 247 Label Switching Routers (LSRs) indicate their willingness to 248 establish and maintain LDP sessions by periodically sending Hello 249 messages. Receipt of a Hello message serves to create a new "Hello 250 adjacency", if one does not already exist, or to refresh an existing 251 one. 253 Unlike all other LDP messages, the Hello messages are sent using UDP 254 not TCP. This means that they cannot benefit from the security 255 mechanisms available with TCP. LDP [RFC5036] does not provide any 256 security mechanisms for use with Hello messages except to note that 257 some configuration may help protect against bogus discovery events. 259 Spoofing a Hello packet for an existing adjacency can cause the 260 adjacency to time out and that can result in termination of the 261 associated session. This can occur when the spoofed Hello message 262 specifies a small Hold Time, causing the receiver to expect Hello 263 messages within this interval, while the true neighbor continues 264 sending Hello messages at the lower, previously agreed to, frequency. 266 Spoofing a Hello packet can also cause the LDP session to be 267 terminated directly. This can occur when the spoofed Hello specifies 268 a different Transport Address from the previously agreed one between 269 neighbors. Spoofed Hello messages are observed and reported as real 270 problem in production networks. 272 2.3.1.2. Session communication using TCP 274 LDP like other TCP based routing protocols specifies use of the TCP 275 MD5 Signature Option to provide for the authenticity and integrity of 276 session messages. As stated above, some assert that MD5 277 authentication is now considered by some to be too weak for this 278 application. A stronger hashing algorithm e.g SHA1, could be 279 deployed to take care of the weakness. 281 Alternatively, one could move to using TCP-AO which provides for 282 stronger MACs and protects against replays. 284 2.3.2. Privacy Issues 286 LDP provides no mechanism for protecting the privacy of label 287 distribution. The security requirements of label distribution are 288 similar to other routing protocols that need to distribute routing 289 information. 291 2.3.3. Denial of Service Attacks 293 LDP is subject to Denial of Service (DoS) attacks both in its 294 discovery mode as well as during the session mode. 296 The discovery mode attack is similar to the spoofing attack except 297 that when the spoofed Hello messages are sent with a high enough 298 frequency can cause the adjacency to time out. 300 2.4. PCEP 302 Attacks on PCEP [RFC5440] may result in damage to active networks. 303 This may include computation responses, which if changed can cause 304 protocols like LDP to setup sub-optimal or inappropriate LSPs. In 305 addition, PCE itself can be attacked by a variety of DoS attacks. 306 Such attacks can cause path computations to be supplied too slowly to 307 be of any value particularly as it relates to recovery or 308 establishment of LSPs. 310 As the RFC states, PCEP could be the target of the following attacks. 312 o Spoofing (PCC or PCE implementation) 314 o Snooping (message interception) 316 o Falsification 318 o Denial of Service 320 According to the RFC, inter-AS scenarios when PCE-to-PCE 321 communication is required, attacks may be particularly significant 322 with commercial as well as service-level implications. 324 Additionally, snooping of PCEP requests and responses may give an 325 attacker information about the operation of the network. Simply by 326 viewing the PCEP messages someone can determine the pattern of 327 service establishment in the network and can know where traffic is 328 being routed, thereby making the network susceptible to targeted 329 attacks and the data within specific LSPs vulnerable. 331 Ensuring PCEP communication privacy is of key importance, especially 332 in an inter-AS context, where PCEP communication end-points do not 333 reside in the same AS, as an attacker that intercepts a PCE message 334 could obtain sensitive information related to computed paths and 335 resources. 337 2.5. MSDP 339 Similar to BGP and LDP, TCP MD5 [RFC2385] specifies a mechanism to 340 protect TCP sessions via the TCP MD5 option. But with a weak MD5 341 authentication, TCP MD5 is not considered strong enough for this 342 application. 344 MSDP also advocates imposing a limit on number of source address and 345 group addresses (S,G) that can be stored within the protocol and 346 thereby mitigate state explosion due to any denial of service and 347 other attacks. 349 3. Optimal State for BGP, LDP, PCEP, and MSDP 351 The ideal state for BGP, LDP and MSDP protocols are when they can 352 withstand any of the known types of attacks. 354 Additionally, Key Management Protocol (KMP) for the routing sessions 355 should help negotiate unique, pair wise random keys without 356 administrator involvement. It should also negotiate Security 357 Association (SA) parameter required for the session connection, 358 including key life times. It should keep track of those lifetimes 359 and negotiate new keys and parameters before they expire and do so 360 without administrator involvement. In the event of a breach, 361 including when an administrator with knowledge of the keys leaves the 362 company, the keys should be changed immediately. 364 The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the 365 transport protocol, TCP in this case. TCP should be able to 366 withstand any of DoS scenarios by dropping packets that are attack 367 packets in a way that does not impact legitimate packets. 369 The routing protocols should provide a mechanism to determine 370 authenticate and validate the routing information carried within the 371 payload. 373 3.1. LDP 375 For the spoofing kind of attacks that LDP is vulnerable to during the 376 discovery phase, it should be able to determine the authenticity of 377 the neighbors sending the Hello message. 379 There is currently no requirement to protect the privacy of label 380 distribution as labels are carried in the clear like other routing 381 information. 383 4. Gap Analysis for BGP, LDP, PCEP and MSDP 385 This section outlines the differences between the current state of 386 the routing protocol and the desired state as outlined in section 4.2 387 of KARP Design Guidelines [RFC6518]. As that document states, these 388 routing protocols fall into the category of the one-to-one peering 389 messages and will use peer keying protocol. It covers issues that 390 are common to the four protocols leaving protocol specific issues to 391 sub-sections. 393 At a transport level the routing protocols are subject to some of the 394 same attacks that TCP applications are subject to. These include but 395 are not limited to DoS attacks. Defending TCP Against Spoofing 396 Attacks [RFC4953] recommends ways to do just that. In addition 397 Improving TCP's Robustness to Blind In-Window Attacks. [RFC5961] 398 should also be followed and implemented. 400 From a security perspective there is a lack of comprehensive KMP. As 401 an example TCP-AO [RFC5925] talks about coordinating keys derived 402 from MKT between endpoints, but the MKT itself has to be configured 403 manually or through a out of band mechanism. Even when keys are 404 configured manually, a method for when to start using the new keys or 405 stop using old keys has not been defined. This leads to keys not 406 being updated regularly which in itself increases the security risk. 407 Also TCP-AO does not address the issue of connectionless reset, as it 408 applies to routers that do not store MKT across reboots. 410 Authentication, tamper protection, and encryption all require the use 411 of keys by sender and receiver. An automated KMP therefore has to 412 include a way to distribute MKT between two end points with little or 413 no administration overhead. It has to cover automatic key rollover. 414 It is expected that authentication will cover the packet, i.e. the 415 payload and the TCP header and will not cover the frame i.e. the link 416 layer 2 header. 418 There are two methods of automatic key rollover. Implicit key 419 rollover can be initiated after certain volume of data gets exchanged 420 or when a certain time has elapsed. This does not require explicit 421 signaling nor should it result in a reset of the TCP connection in a 422 way that the links/adjacencies are affected. On the other hand, 423 explicit key rollover requires a out of band key signaling mechanism. 424 It can be triggered by either side and can be done anytime a security 425 parameter changes e.g. an attack has happened, or a system 426 administrator with access to the keys has left the company. An 427 example of this is IKE [RFC2409] but it could be any other new 428 mechanisms also. 430 As stated earlier TCP-AO [RFC5925] and its accompanying document 431 Crypto Algorithms for TCP-AO [RFC5926] suggest that two MAC 432 algorithms that MUST be supported are HMAC-SHA-1-96 as specified in 433 HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST-SP800-38B 434 [NIST-SP800-38B]. 436 There is a need to protect authenticity and validity of the routing/ 437 label information that is carried in the payload of the sessions. 438 However, we believe that is outside the scope of this document at 439 this time and is being addressed by SIDR WG. Similar mechanisms 440 could be used for intra-domain protocols. 442 4.1. LDP 444 As described in LDP [RFC5036], the threat of spoofed Basic Hellos can 445 be reduced by accepting Basic Hellos on interfaces that LSRs trust, 446 employing GTSM [RFC5082] and ignoring Basic Hellos not addressed to 447 the "all routers on this subnet" multicast group. Spoofing attacks 448 via Extended Hellos are potentially a more serious threat. An LSR 449 can reduce the threat of spoofed Extended Hellos by filtering them 450 and accepting Hellos from sources permitted by an access list. 451 However, performing the filtering using access lists requires LSR 452 resource, and the LSR is still vulnerable to the IP source address 453 spoofing. Spoofing attacks can be solved by being able to 454 authenticate the Hello messages, and an LSR can be configured to only 455 accept Hello messages from specific peers when authentication is in 456 use. 458 LDP Hello Cryptographic Authentication 459 [draft-zheng-mpls-ldp-hello-crypto-auth-01] suggest a new 460 Cryptographic Authentication TLV that can be used as an 461 authentication mechanism to secure Hello messages. 463 4.2. PCEP 465 PCE discovery according to its RFC is a significant feature for the 466 successful deployment of PCEP in large networks. This mechanism 467 allows a PCC to discover the existence of suitable PCEs within the 468 network without the necessity of configuration. It should be obvious 469 that, where PCEs are discovered and not configured, the PCC cannot 470 know the correct key to use. There are different approaches to 471 retain some aspect of security, but all of them require use of a keys 472 and a keying mechanism, the need for which has been discussed above. 474 5. Transition and Deployment Considerations 476 As stated in KARP Design Guidelines [RFC6518] it is imperative that 477 the new authentication and security mechanisms defined support 478 incremental deployment, as it is not feasible to deploy the new 479 routing protocol authentication mechansim overnight. 481 Typically authentication and security in a peer-to-peer protocol 482 requires that both parties agree to the mechanisms that will be used. 483 If an agreement is not reached the setup of the new mechanism will 484 fail or will be deferred. Upon failure, the routing protocols can 485 fallback to the mechanisms that were already in place e.g. use static 486 keys if that was the mechanism in place. It is usually not possible 487 for one end to use the new mechanism while the other end uses the 488 old. Policies can be put in place to retry upgrading after a said 489 period of time, so a manual coordiantion is not required. 491 If the automatic KMP requires use of public/private keys to exchange 492 key material, the required CA root certificates may need to be 493 installed to verify authenticity of requests initiated by a peer. 494 Such a step does not require coordination with the peer except to 495 decide what CA authority will be used. 497 6. Security Requirements 499 This section describes requirements for BGP, LDP, PCEP and MSDP 500 security that should be met within the routing protocol. 502 As with all routing protocols, they need protection from both on-path 503 and off-path blind attacks. A better way to protect them would be 504 with per-packet protection using a cryptographic MAC. In order to 505 provide for the MAC, keys are needed. 507 Once keys are used, mechanisms are required to support key rollover. 508 This should cover both manual and automatic key rollover. Multiple 509 approaches could be used. However since the existing mechanisms 510 provide a protocol field to identify the key as well as management 511 mechanisms to introduce and retire new keys, focusing on the existing 512 mechanism as a starting point is prudent. 514 Finally, replay protection is required. The replay mechanism needs 515 to be sufficient to prevent an attacker from creating a denial of 516 service or disrupting the integrity of the routing protocol by 517 replaying packets. It is important that an attacker not be able to 518 disrupt service by capturing packets and waiting for replay state to 519 be lost. 521 7. Acknowledgements 523 We would like to thank Brian Weis for encouraging us to write this 524 draft and providing comments on it. 526 8. References 528 8.1. Normative References 530 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 531 Signature Option", RFC 2385, August 1998. 533 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 534 for the TCP Authentication Option (TCP-AO)", RFC 5926, 535 June 2010. 537 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 538 Routing Protocols (KARP) Design Guidelines", RFC 6518, 539 February 2012. 541 [draft-ietf-karp-threats-reqs] 542 Lebovitz, G. and M. Bhatia, "KARP Threats and 543 Requirements", March 2012. 545 8.2. Informative References 547 [NIST-SP800-38B] 548 Dworking, "Recommendation for Block Cipher Modes of 549 Operation: The CMAC Mode for Authentication", May 2005. 551 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 552 Hashing for Message Authentication", RFC 2104, 553 February 1997. 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 559 (IKE)", RFC 2409, November 1998. 561 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 562 Group Domain of Interpretation", RFC 3547, July 2003. 564 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 565 Protocol 4 (BGP-4)", RFC 4271, January 2006. 567 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 568 IAB workshop on Unwanted Traffic March 9-10, 2006", 569 RFC 4948, August 2007. 571 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 572 RFC 4953, July 2007. 574 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 575 Specification", RFC 5036, October 2007. 577 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 578 Pignataro, "The Generalized TTL Security Mechanism 579 (GTSM)", RFC 5082, October 2007. 581 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 582 (PCE) Communication Protocol (PCEP)", RFC 5440, 583 March 2009. 585 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 586 Authentication Option", RFC 5925, June 2010. 588 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 589 Robustness to Blind In-Window Attacks", RFC 5961, 590 August 2010. 592 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 593 with Existing Cryptographic Protection Methods for Routing 594 Protocols", RFC 6039, October 2010. 596 [draft-ietf-karp-ospf-analysis-03] 597 Hartman, S., "Analysis of OSPF Security According to KARP 598 Design Guide", March 2012. 600 [draft-zheng-mpls-ldp-hello-crypto-auth-01] 601 Zheng, "LDP Hello Cryptographic Authentication", 602 March 2011. 604 Authors' Addresses 606 Mahesh Jethanandani 607 Ciena Corporation 608 1741 Technology Drive 609 San Jose, CA 95110 610 USA 612 Phone: + (408) 436-3313 613 Email: mjethanandani@gmail.com 615 Keyur Patel 616 Cisco Systems, Inc 617 170 Tasman Drive 618 San Jose, CA 95134 619 USA 621 Phone: +1 (408) 526-7183 622 Email: keyupate@cisco.com 624 Lianshu Zheng 625 Huawei 626 No. 3 Xinxi Road, Hai-Dian District 627 Beijing, 100085 628 China 630 Phone: +86 (10) 82882008 631 Fax: 632 Email: verozheng@huawei.com 633 URI: