idnits 2.17.1 draft-ietf-karp-routing-tcp-analysis-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 08, 2013) is 4035 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC3618' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 677, 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: 0 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: October 10, 2013 Cisco Systems, Inc 6 L. Zheng 7 Huawei Technologies 8 April 08, 2013 10 Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design 11 Guide 12 draft-ietf-karp-routing-tcp-analysis-07.txt 14 Abstract 16 This document analyzes TCP based routing protocols, Border Gateway 17 Protocol (BGP), Label Distribution Protocol (LDP), Path Computation 18 Element Communication Protocol (PCEP), and Multicast Source 19 Distribution Protocol (MSDP) according to guidelines set forth in 20 section 4.2 of Keying and Authentication for Routing Protocols Design 21 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 October 10, 2013. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Current Assessment of BGP, LDP, PCEP and MSDP . . . . . . . . 4 60 2.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Keying mechanisms . . . . . . . . . . . . . . . . . . . . 6 62 2.3. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.4.1. Spoofing attacks . . . . . . . . . . . . . . . . . . 7 65 2.4.2. Denial of Service Attacks . . . . . . . . . . . . . . 8 66 2.5. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.6. 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 . . . . . . . . . . 13 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 79 9.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 the following TCP based 104 protocols: 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 This document builds on several previous efforts into routing 113 security: 115 o Issues with existing Cryptographic Protection Methods for Routing 116 Protocols [RFC6039], describes issues with existing cryptographic 117 protection methods for routing protocols. 119 o Analysis of OSPF Security According to KARP Design Guide [RFC6863] 120 analyzes Open Shortest Path First (OSPF) security according to 121 KARP Design Guide. 123 Section 2 of this document looks at the current state of the security 124 method for the four routing protocols, BGP, LDP, PCEP and MSDP. 125 Section 3 examines what the optimal state of the security method 126 would be for the four routing protocols, according to KARP Design 127 Guidelines [RFC6518] and Section 4 does an analysis of the gap 128 between the existing state of the security method and the optimal 129 state of the security method for protocols and suggests some areas 130 where improvement is needed. 132 1.1. Abbreviations 134 AES - Advanced Encryption Standard 136 AO - Authentication Option 138 AS - Autonomous Systems 140 BGP - Border Gateway Protocol 142 CMAC - Ciper Based MAC 144 DoS - Denial of Service 145 GTSM - Generalized TTL Security Mechanism 147 HMAC - Hash Based MAC 149 KARP - Key and Authentication for Routing Protocols 151 KDF - Key Derivation Function 153 KEK - Key Encrypting Key 155 KMP - Key Management Protocol 157 LDP - Label Distribution Protocol 159 LSR - Label Switching Routers 161 MAC - Message Authentication Code 163 MKT - Master Key Tuple 165 MSDP - Multicast Source Distribution Protocol 167 MD5 - Message Digest algorithm 5 169 OSPF - Open Shortest Path First 171 PCEP - Path Computation Element Communication Protocol 173 PCC - Path Computation Client 175 PCE - Path Computation Element 177 SHA - Security Hash Algorithm 179 TCP - Transmission Control Protocol 181 TTL - Time To Live 183 UDP - User Datagram Protocol 185 WG - Working Group 187 2. Current Assessment of BGP, LDP, PCEP and MSDP 189 This section assesses the transport protocols for any authentication 190 or integrity mechanisms used by the protocol. It describes the 191 current security mechanisms if any used by BGP, LDP, PCEP and MSDP. 193 2.1. Transport layer 195 At a transport layer, routing protocols are subject to a variety of 196 DoS attacks, as outlined in Internet Denial-of-Service Considerations 197 [RFC4732]. Such attacks can cause the routing protocol to become 198 congested with the result that routing updates are supplied too 199 slowly to be useful. In extreme cases, these attacks prevent routers 200 from converging after a change. 202 Routing protocols use several methods to protect themselves. Those 203 that use TCP as a transport protocol use access lists to accept 204 packets only from known sources. These access lists also help 205 protect edge routers from attacks originating outside the protected 206 domain. In addition, for edge routers running eBGP, TCP LISTEN is 207 run only on interfaces on which its peers have been discovered or via 208 which routing sessions are expected (as specified in router 209 configuration databases). 211 Generalized TTL Security Mechanism (GTSM) [RFC5082] describes a 212 generalized Time to Live (TTL) security mechanism to protect a 213 protocol stack from CPU-utilization based attacks.TCP Robustness 214 [RFC5961] recommends some TCP level mitigations against spoofing 215 attacks targeted towards long-lived routing protocol sessions. 217 Even when BGP, LDP, PCEP and MSDP sessions use access lists, they are 218 vulnerable to spoofing and man in the middle attacks. Authentication 219 and integrity checks allow the receiver of a routing protocol update 220 to know that the message genuinely comes from the node that claims to 221 have sent it, and to know whether the message has been modified. 222 Sometimes routers can be subjected to a large number of 223 authentication and integrity requests, exhausting connection 224 resources on the router in a way that could lead to deny genuine 225 requests. 227 TCP MD5 [RFC2385] has been obsoleted by TCP-AO [RFC5925]. However, 228 it is still widely used to authenticate TCP based routing protocols 229 such as BGP. It provides a way for carrying a MD5 digest in a TCP 230 segment. This digest is computed using information known only to the 231 end points and this ensures authenticity and integrity of messages. 232 The MD5 key used to compute the digest is stored locally on the 233 router. This option is used by routing protocols to provide for 234 session level protection against the introduction of spoofed TCP 235 segments into any existing TCP streams, in particular TCP Reset 236 segments. TCP MD5 does not provide a generic mechanism to support 237 key roll-over. It also does not support algorithm agility. 239 The Message Authentication Codes (MACs) used by TCP MD5 option, is 240 considered too weak both because of the use of the hash function and 241 because of the way the secret key used by TCP MD5 is managed. 242 Furthermore, TCP MD5 does not support any algorithm agility. TCP-AO 243 [RFC5925], and its companion document Crypto Algorithms for TCP-AO 244 [RFC5926], describe steps towards correcting both the MAC weakness 245 and the management of secret keys. For MAC it requires that two MAC 246 algorithms be supported. They are HMAC-SHA-1-96 as specified in HMAC 247 [RFC2104], and AES-128-CMAC-96 as specified in NIST-SP800-38B 248 [NIST-SP800-38B]. Cryptographic research suggests that both these 249 MAC algorithms defined are fairly secure. By supporting multiple MAC 250 algorithms, TCP-AO supports algorithm agility. TCP-AO also allows 251 additional MACs to be added in the future. 253 2.2. Keying mechanisms 255 For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used 256 to manage the keys that are employed to generate the Message 257 Authentication Code (MAC). TCP-AO talks about coordinating keys 258 derived from Master Key Table (MKT) between endpoints and allows for 259 a master key to be configured manually or for it to be managed via a 260 out of band mechanism. 262 It should be noted that most routers configured with static keys have 263 not seen the key changed ever. The common reason given for not 264 changing the key is the difficulty in coordinating the change between 265 pairs of routers when using TCP MD5. It is well known that the 266 longer the same key is used, the greater the chance that it can be 267 guessed or exposed e.g. when an administrator with knowledge of the 268 keys leaves the company. 270 For point-to-point key management IKEv2 [RFC5996] protocol provides 271 for automated key exchange under a SA, and can be used for a 272 comprehensive Key Management Protocol (KMP) solution for routers. 273 IKEv2 can be used for both IPsec SAs [RFC4301] and other types of 274 SAs. For example, Fibre Channel SAs [RFC4595] are currently 275 negotiated with IKEv2. Using IKEv2 to negotiate TCP-AO is a possible 276 option. 278 2.3. BGP 280 All BGP communications take place over TCP. Therefore, all security 281 vulnerabilities for BGP can be categorised as relating to the 282 security of the transport protocol itself, or to the compromising of 283 individual routers and the data they handle. This document examines 284 the issues for the transport protocol, while the SIDR Working Group 285 (WG) looks at ways to sign and secure the data exchanged in BGP as 286 described in An Infrastructure to Support Secure Internet Protocol 287 [RFC6480]. 289 2.4. LDP 291 Security Framework for MPLS and GMPLS Networks [RFC5920] outlines 292 security aspects that are relevant in the context of MPLS and GMPLS. 293 It describes the security threats, the related defensive techniques, 294 and the mechanism for detection and reporting. 296 Section 5 of LDP [RFC5036] states that LDP is subject to two 297 different types of attacks: spoofing, and denial of service attacks. 299 2.4.1. Spoofing attacks 301 A spoofing attack against LDP can occur both during the discovery 302 phase and during the session communication phase. 304 2.4.1.1. Discovery exchanges using UDP 306 Label Switching Routers (LSRs) indicate their willingness to 307 establish and maintain LDP sessions by periodically sending Hello 308 messages. Reception of a Hello message serves to create a new "Hello 309 adjacency", if one does not already exist, or to refresh an existing 310 one. 312 There are two variants of the discovery mechanism. A Basic Discovery 313 mechanism that is used to discover LSR neighbors that are directly 314 connected at the link level and a Extended Discovery mechanism that 315 is used by LSRs that are more than one hop away. 317 Unlike all other LDP messages, the Hello messages are sent using UDP. 318 This means that they cannot benefit from the security mechanisms 319 available with TCP. LDP [RFC5036] does not provide any security 320 mechanisms for use with Hello messages except for some configuration 321 which may help protect against bogus discovery events. These 322 configurations include directly connected links and interfaces. 323 Routers that do not use directly connected links have to use Extended 324 Discovery mechanism, and will not be able to use configuration to 325 protect against bogus discovery events. 327 Spoofing a Hello packet for an existing adjacency can cause the 328 adjacency to time out and result in termination of the associated 329 session. This can occur when the spoofed Hello message specifies a 330 small Hold Time, causing the receiver to expect Hello messages within 331 this interval, while the true neighbor continues sending Hello 332 messages at the lower, previously agreed to frequency. 334 Spoofing a Hello packet can also cause the LDP session to be 335 terminated. This can occur when the spoofed Hello specifies a 336 different Transport Address from the previously agreed one between 337 neighbors. Spoofed Hello messages are observed and reported as real 338 problem in production networks. 340 2.4.1.2. Session communication using TCP 342 LDP like other TCP based routing protocols specifies use of the TCP 343 MD5 Signature Option to provide for the authenticity and integrity of 344 session messages. As stated in section 2.1 of this document and in 345 section 2.9 of LDP [RFC5036], MD5 authentication is considered too 346 weak for this application as outlined in MD5 and HMAC-MD5 Security 347 Considerations [RFC6151]. It also does not support algorithm 348 agility. A stronger hashing algorithm e.g SHA1, which is supported 349 by TCP-AO [RFC5925] could be deployed to take care of the weakness. 351 Alternatively, one could move to using TCP-AO which provides for 352 stronger MAC algorithms, makes it easier to setup manual keys and 353 protects against replay attacks. 355 2.4.2. Denial of Service Attacks 357 LDP is subject to Denial of Service (DoS) attacks both in its 358 discovery mode and in session mode. These are documented in 359 Section 5.3 of LDP [RFC5036]. 361 2.5. PCEP 363 For effective selection by PCCs, a PCC needs to know the location of 364 PCEs in its domain along with some information relevant for PCE 365 selection. Such PCE information could be learned through manual 366 configuration, on each PCC, along with their capabilities or 367 automatically through a PCE discovery mechanism as outlined in 368 Requirements for PCE Discovery [RFC4674]. 370 Attacks on PCEP [RFC5440] may result in damage to active networks. 371 These include computation responses, which if changed can cause 372 protocols like RSVP-TE [RFC3209] to setup sub-optimal or 373 inappropriate LSPs. In addition, PCE itself can attacked by a 374 variety of DoS attacks. Such attacks can cause path computations to 375 be supplied too slowly to be of any value particularly as it relates 376 to recovery or establishment of LSPs. 378 Finally, PCE discovery as outlined in OSPF Protocol Extensions for 379 PCE Discovery [RFC5088] and IS-IS Protocol Extensions for PCE 380 Discovery [RFC5089] is a significant feature for the successful 381 deployment of PCEP in large networks. These mechanisms allow PCC to 382 discover the existence of PCEs within the network. If the discovery 383 mechanism is compromised, it will impair the ability of the nodes to 384 function as described below. 386 As RFC 5440 states, PCEP which makes use of TCP as a transport, could 387 be the target of the following attacks: 389 o Spoofing (PCC or PCE implementation) 391 o Snooping (message interception) 393 o Falsification 395 o Denial of Service 397 In inter-Autonomous Systems (AS) scenarios where PCE-to-PCE 398 communication is required, attacks may be particularly significant 399 with commercial as well as service-level agreement implications. 401 Additionally, snooping of PCEP requests and responses may give an 402 attacker information about the operation of the network. By viewing 403 the PCEP messages an attacker can determine the pattern of service 404 establishment in the network, and can know where traffic is being 405 routed, thereby making the network susceptible to targeted attacks 406 and the data within specific LSPs vulnerable. 408 Ensuring PCEP communication privacy is of key importance, especially 409 in an inter-AS context, where PCEP communication end-points do not 410 reside in the same AS. An attacker that intercepts a PCE message 411 could obtain sensitive information related to computed paths and 412 resources. 414 At the time PCEP was documented in [RFC5440], TCP-AO had not been 415 fully specified. Therefore, [RFC5440] mandates that PCEP 416 implementations include support for TCP-MD5, and that use of the 417 function should be configurable by the operator. [RFC5440] also 418 describes the vulnerabilities and weaknesses of TCP-MD5 as noted in 419 this document. [RFC5440] goes on to state that PCEP implementations 420 should include support for TCP-AO as soon as that specification is 421 complete. Since TCP-AO [RFC5925] has now been published, new PCEP 422 implementation should fully support TCP-AO. 424 2.6. MSDP 426 Similar to BGP and LDP, Multicast Source Distribution Protocol (MSDP) 427 uses TCP MD5 [RFC2385] to protect TCP sessions via the TCP MD5 428 option. But with a weak MD5 authentication, TCP MD5 is not 429 considered strong enough for this application. It also does not 430 support algorithm agility. 432 MSDP also advocates imposing a limit on number of source address and 433 group addresses (S,G) that can be cached within the protocol and 434 thereby mitigate state explosion due to any denial of service and 435 other attacks. 437 3. Optimal State for BGP, LDP, PCEP, and MSDP 439 The ideal state of the security method for BGP, LDP, PCEP and MSDP 440 protocols are when they can withstand any of the known types of 441 attacks. The protocols also need to support algorithm agility, i.e. 442 they must not hardwire themselves to one algorithm. 444 Additionally, Key Management Protocol (KMP) for the routing sessions 445 should help negotiate unique, pair wise random keys without 446 administrator involvement. It should also negotiate Security 447 Association (SA) parameters required for the session connection, 448 including key life times. It should keep track of those lifetimes 449 and negotiate new keys and parameters before they expire and do so 450 without administrator involvement. In the event of a breach, 451 including when an administrator with knowledge of the keys leaves the 452 company, the keys should be changed immediately. 454 The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the 455 transport protocol, TCP for the most part and UDP in case of 456 discovery phase of LDP. TCP and UDP should be able to withstand any 457 of DoS scenarios by dropping packets that are attack packets in a way 458 that does not impact legitimate packets. 460 The routing protocols should provide a mechanism to authenticate the 461 routing information carried within the payload and administrators 462 should enable it. 464 3.1. LDP 466 To harden LDP against its current vulnerability to spoofing attacks, 467 LDP needs to be upgraded such that an implementation is able to 468 determine the authenticity of the neighbors sending the Hello 469 message. 471 Labels are similar to routing information which is distributed in the 472 clear. However, there is currently no requirement that the labels be 473 encrypted. And stated before, is currently out of scope of this 474 document. 476 Similarly, it is important to ensure that routers exchanging labels 477 are mutually authenticated, and that there are no rogue peers or 478 unauthenticated peers that can compromise the stability of the 479 network. 481 4. Gap Analysis for BGP, LDP, PCEP and MSDP 483 This section outlines the differences between the current state of 484 the security methods for routing protocols, and the desired state of 485 the security methods as outlined in section 4.2 of KARP Design 486 Guidelines [RFC6518]. As that document states, these routing 487 protocols fall into the category of one-to-one peering messages and 488 will use peer keying protocol. It covers issues that are common to 489 the four protocols in this section, leaving protocol specific issues 490 to sub-sections. 492 At a transport level these routing protocols are subject to some of 493 the same attacks that TCP applications are subject to. These include 494 DoS and spoofing attacks. Internet Denial-of-Service Considerations 495 [RFC4732] outlines some solutions. Defending TCP Against Spoofing 496 Attacks [RFC4953] recommends ways to prevent spoofing attacks. In 497 addition, the recommendations in [RFC5961] should also be followed 498 and implemented to strengthen TCP. 500 Routers lack comprehensive key management and keys derived from it 501 that they can use to authenticate data. As an example TCP-AO 502 [RFC5925], talks about coordinating keys derived from Master Key 503 Table (MKT) between endpoints, but the MKT itself has to be 504 configured manually or through an out of band mechanism. Also TCP-AO 505 does not address the issue of connectionless reset, as it applies to 506 routers that do not store MKT across reboots. 508 Authentication, integrity protection, and encryption all require the 509 use of keys by sender and receiver. An automated KMP therefore has 510 to include a way to distribute key material between two end points 511 with little or no administration overhead. It has to cover automatic 512 key rollover. It is expected that authentication will cover the 513 packet, i.e. the payload and the TCP header and will not cover the 514 frame i.e. the link layer 2 header. 516 There are two methods of automatic key rollover. Implicit key 517 rollover can be initiated after certain volume of data gets exchanged 518 or when a certain time has elapsed. This does not require explicit 519 signaling nor should it result in a reset of the TCP connection in a 520 way that the links/adjacencies are affected. On the other hand, 521 explicit key rollover requires an out of band key signaling 522 mechanism. It can be triggered by either side and can be done 523 anytime a security parameter changes e.g. an attack has happened, or 524 a system administrator with access to the keys has left the company. 525 An example of this is IKEv2 [RFC5996], but it could be any other new 526 mechanisms also. 528 As stated earlier TCP-AO [RFC5925], and its accompanying document 529 Crypto Algorithms for TCP-AO [RFC5926], requires that two MAC 530 algorithms be supported, and they are HMAC-SHA-1-96 as specified in 531 HMAC [RFC2104], and AES-128-CMAC-96 as specified in NIST-SP800-38B 532 [NIST-SP800-38B]. Therefore, TCP-AO meets the algorithm agility 533 requirement. 535 There is a need to protect authenticity and validity of the routing/ 536 label information that is carried in the payload of the sessions. 537 However, that is outside the scope of this document and is being 538 addressed by SIDR WG. Similar mechanisms could be used for intra- 539 domain protocols. 541 Finally, replay protection is required. The replay mechanism needs 542 to be sufficient to prevent an attacker from creating a denial of 543 service or disrupting the integrity of the routing protocol by 544 replaying packets. It is important that an attacker not be able to 545 disrupt service by capturing packets and waiting for replay state to 546 be lost. 548 4.1. LDP 550 As described in LDP [RFC5036], the threat of spoofed Basic Hellos can 551 be reduced by only accepting Basic Hellos on interfaces that LSRs 552 trust, employing GTSM [RFC5082] and ignoring Basic Hellos not 553 addressed to the "all routers on this subnet" multicast group. 554 Spoofing attacks via Targeted Hellos are potentially a more serious 555 threat. An LSR can reduce the threat of spoofed Extended Hellos by 556 filtering them and accepting Hellos from sources permitted by an 557 access lists. However, performing the filtering using access lists 558 requires LSR resource, and the LSR is still vulnerable to the IP 559 source address spoofing. Spoofing attacks can be solved by being 560 able to authenticate the Hello messages, and an LSR can be configured 561 to only accept Hello messages from specific peers when authentication 562 is in use. 564 LDP Hello Cryptographic Authentication 565 [draft-zheng-mpls-ldp-hello-crypto-auth-04] suggest a new 566 Cryptographic Authentication TLV that can be used as an 567 authentication mechanism to secure Hello messages. 569 4.2. PCEP 571 Path Computation Element (PCE) discovery according to its RFC 572 [RFC5440], is a significant feature for the successful deployment of 573 PCEP in large networks. This mechanism allows a Path Computation 574 Client (PCC) to discover the existence of suitable PCEs within the 575 network without the necessity of configuration. It should be obvious 576 that, where PCEs are discovered and not configured, the PCC cannot 577 know the correct key to use. There are different approaches to 578 retain some aspect of security, but all of them require use of a keys 579 and a keying mechanism, the need for which has been discussed above. 581 5. Transition and Deployment Considerations 583 As stated in KARP Design Guidelines [RFC6518], it is imperative that 584 the new authentication, security mechanisms defined, and key 585 management protocol support incremental deployment, as it is not 586 feasible to deploy the new routing protocol authentication mechanism 587 overnight. 589 Typically, authentication and security in a peer-to-peer protocol 590 requires that both parties agree to the mechanisms that will be used. 591 If an agreement is not reached the setup of the new mechanism will 592 fail or will be deferred. Upon failure, the routing protocols can 593 fallback to the mechanisms that were already in place e.g. use 594 static keys if that was the mechanism in place. The fallback should 595 be configurable on a per-node or per-interface. It is usually not 596 possible for one end to use the new mechanism while the other end 597 uses the old. Policies can be put in place to retry upgrading after 598 a said period of time, so a manual coordination is not required. 600 If the automatic KMP requires use of Public Key Infrastructure 601 Certificates [RFC5280] to exchange key material, the required 602 Certificate Authority (CA) root certificates may need to be installed 603 to verify authenticity of requests initiated by a peer. Such a step 604 does not require coordination with the peer except to decide what CA 605 authority will be used. 607 6. Security Considerations 609 This section describes security considerations that BGP, LDP, PCEP 610 and MSDP should try to meet. 612 As with all routing protocols, they need protection from both on-path 613 and off-path blind attacks. A better way to protect them would be 614 with per-packet protection using a cryptographic MAC. In order to 615 provide for the MAC, keys are needed. 617 The routing protocols need to support algorithm agility, i.e. they 618 must not hardwire themselves to one algorithm. 620 Once keys are used, mechanisms are required to support key rollover. 621 This should cover both manual and automatic key rollover. Multiple 622 approaches could be used. However, since the existing mechanisms 623 provide a protocol field to identify the key as well as management 624 mechanisms to introduce and retire new keys, focusing on the existing 625 mechanism as a starting point is prudent. 627 Furthermore, it is strongly suggested that these routing protocols 628 need to support algorithm agility. It has been proven that 629 algorithms weaken over time. Supporting algorithm agility assists in 630 smooth transition from old to new algorithms. 632 7. IANA Considerations 634 None. 636 8. Acknowledgements 638 We would like to thank Brian Weis for encouraging us to write this 639 draft, and to Anantha Ramaiah and Mach Chen for providing comments on 640 it. 642 9. References 644 9.1. Normative References 646 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 647 for the TCP Authentication Option (TCP-AO)", RFC 5926, 648 June 2010. 650 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 651 Routing Protocols (KARP) Design Guidelines", RFC 6518, 652 February 2012. 654 9.2. Informative References 656 [NIST-SP800-38B] 657 Dworking, , "Recommendation for Block Cipher Modes of 658 Operation: The CMAC Mode for Authentication", May 2005. 660 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 661 Hashing for Message Authentication", RFC 2104, February 662 1997. 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, March 1997. 667 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 668 Signature Option", RFC 2385, August 1998. 670 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 671 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 672 Tunnels", RFC 3209, December 2001. 674 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 675 Protocol (MSDP)", RFC 3618, October 2003. 677 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 678 Protocol 4 (BGP-4)", RFC 4271, January 2006. 680 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 681 Internet Protocol", RFC 4301, December 2005. 683 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel 684 Security Association Management Protocol", RFC 4595, July 685 2006. 687 [RFC4674] Le Roux, J.L., "Requirements for Path Computation Element 688 (PCE) Discovery", RFC 4674, October 2006. 690 [RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of- 691 Service Considerations", RFC 4732, December 2006. 693 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 694 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 695 4948, August 2007. 697 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 698 4953, July 2007. 700 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 701 Specification", RFC 5036, October 2007. 703 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 704 Pignataro, "The Generalized TTL Security Mechanism 705 (GTSM)", RFC 5082, October 2007. 707 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 708 "OSPF Protocol Extensions for Path Computation Element 709 (PCE) Discovery", RFC 5088, January 2008. 711 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 712 "IS-IS Protocol Extensions for Path Computation Element 713 (PCE) Discovery", RFC 5089, January 2008. 715 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 716 Housley, R., and W. Polk, "Internet X.509 Public Key 717 Infrastructure Certificate and Certificate Revocation List 718 (CRL) Profile", RFC 5280, May 2008. 720 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 721 (PCE) Communication Protocol (PCEP)", RFC 5440, March 722 2009. 724 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 725 Networks", RFC 5920, July 2010. 727 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 728 Authentication Option", RFC 5925, June 2010. 730 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 731 Robustness to Blind In-Window Attacks", RFC 5961, August 732 2010. 734 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 735 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 736 5996, September 2010. 738 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 739 with Existing Cryptographic Protection Methods for Routing 740 Protocols", RFC 6039, October 2010. 742 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 743 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 744 RFC 6151, March 2011. 746 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 747 Secure Internet Routing", RFC 6480, February 2012. 749 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 750 According to the Keying and Authentication for Routing 751 Protocols (KARP) Design Guide", RFC 6863, March 2013. 753 [draft-zheng-mpls-ldp-hello-crypto-auth-04] 754 Zheng, , "LDP Hello Cryptographic Authentication", May 755 2012. 757 Authors' Addresses 758 Mahesh Jethanandani 759 Ciena Corporation 760 1741 Technology Drive 761 San Jose, CA 95110 762 USA 764 Phone: + (408) 436-3313 765 Email: mjethanandani@gmail.com 767 Keyur Patel 768 Cisco Systems, Inc 769 170 Tasman Drive 770 San Jose, CA 95134 771 USA 773 Phone: +1 (408) 526-7183 774 Email: keyupate@cisco.com 776 Lianshu Zheng 777 Huawei Technologies 778 China 780 Phone: +86 (10) 82882008 781 Email: vero.zheng@huawei.com