idnits 2.17.00 (12 Aug 2021) /tmp/idnits25561/draft-ietf-karp-bfd-analysis-08.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 (February 9, 2015) is 2651 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Ionos Networks 4 Intended status: Informational D. Zhang 5 Expires: August 13, 2015 Alibaba 6 M. Jethanandani 7 Ciena Corporation 8 February 9, 2015 10 Analysis of Bidirectional Forwarding Detection (BFD) Security According 11 to KARP Design Guide 12 draft-ietf-karp-bfd-analysis-08 14 Abstract 16 This document analyzes the Bidirectional Forwarding Detection 17 protocol (BFD) according to the guidelines set forth in section 4.2 18 of KARP Design Guidelines RFC6518. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 13, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 This document performs a gap analysis of the current state of 55 Bidirectional Forwarding Detection [RFC5880] according to the 56 requirements of KARP Design Guidelines [RFC6518]. Previously, the 57 OPSEC working group has provided an analysis of cryptographic issues 58 with BFD in Issues with Existing Cryptographic Protection Methods for 59 Routing Protocols [RFC6039]. 61 The existing BFD specifications provide a basic security solution. 62 Key ID is provided so that the key used in securing a packet can be 63 changed on demand. Two cryptographic algorithms (MD5 and SHA-1) are 64 supported for integrity protection of the control packets; the 65 algorithms are both demonstrated to be subject to collision attacks. 66 Routing protocols like RIPv2 Cryptographic Authentication [RFC4822], 67 IS-IS Generic Cryptographic Authentication [RFC5310] and OSPFv2 HMAC- 68 SHA Cryptographic Authentication [RFC5709] have started to use BFD 69 for liveliness check. Moving the routing protocols to a stronger 70 algorithm while using weaker algorithm for BFD would allow the 71 attacker to bring down BFD in order to bring down the routing 72 protocol. BFD therefore needs to match the routing protocols in its 73 strength of algorithm. 75 While BFD uses a non-decreasing per-packet sequence number to protect 76 itself from intra-connection replay attacks, it still leaves the 77 protocol vulnerable to the inter-session replay attacks. 79 2. Requirements to Meet 81 There are several requirements described in section 3 of The Threat 82 Analysis and Requirements for Cryptographic Authentication of Routing 83 Protocols' Transports [RFC6862] that BFD as defined in BFD [RFC5880] 84 does not currently meet: 86 Replay Protection: BFD provides an incomplete intra-session and no 87 inter-session replay attack protection; this creates significant 88 denial-of-service opportunities. 90 Strong Algorithms: the cryptographic algorithms adopted for 91 message authentication in BFD are MD5 or SHA-1 based. However, 92 both algorithms are known to be vulnerable to collision attacks. 93 BFD Generic Cryptographic Authentication 94 [I-D.ietf-bfd-generic-crypto-auth] and Authenticating BFD using 95 HMAC-SHA-2 procedures [I-D.ietf-bfd-hmac-sha] together propose a 96 solution to support HMAC with the SHA-2 family of hash functions 97 for BFD. 99 DoS Attacks: BFD packets can be sent at millisecond intervals (the 100 protocol uses timers at microsecond intervals). When malicious 101 packets are sent at short intervals, with the authentication bit 102 set, it can cause a DoS attack. There is currently no light 103 weight mechanism within BFD to address this issue and is one of 104 the reasons BFD authentication is still not widely deployed in the 105 field. 107 The remainder of this document explains the details of how these 108 requirements fail to be met and proposes mechanisms for addressing 109 them. 111 3. Current State of Security Methods 113 BFD [RFC5880] describes five authentication mechanisms for the 114 integrity protection of BFD control packets: Simple Password, Keyed 115 MD5 The MD5 Message-Digest Algorithm [RFC1321], Meticulous Keyed MD5, 116 Keyed SHA-1 and Meticulous SHA-1. In the simple password mechanism, 117 every control packet is associated with a password transported in 118 plain text; attacks eavesdropping the network traffic can easily 119 learn the password and compromise the security of the corresponding 120 BFD session. In the Keyed MD5 and the Meticulous Keyed MD5 121 mechanisms, BFD nodes use share secret keys to generate keyed MD5 122 digests for control packets. Similarly, in the Keyed SHA-1 and the 123 Meticulous Keyed SHA-1 mechanisms, BFD nodes use shared secret keys 124 to generate keyed SHA-1 digests for control packets. Note that in 125 the keyed authentication mechanisms, every BFD control packet is 126 associated with a non-decreasing 32-bit sequence number to resist 127 replay attacks. In the Keyed MD5 and the Keyed SHA-1 mechanisms, the 128 sequence member is only required to increase occasionally. However, 129 in the Meticulous Keyed MD5 and the Meticulous Keyed SHA-1 130 mechanisms, the sequence member is required to increase with each 131 successive packet. 133 Additionally, limited key updating functionality is provided. There 134 is a Key ID in every authenticated BFD control packet, indicating the 135 key used to hash the packet. However, there is no mechanism 136 described to provide a smooth key rollover that the BFD routers can 137 use when moving from one key to the other. 139 The BFD session timers are defined with the granularity of 140 microseconds, and it is common in practice to send BFD packets at 141 millisecond intervals. Since the cryptographic sequence number space 142 is only 32 bits, a sequence number used in a BFD session may reach 143 its maximum value and roll over within limited period. For instance, 144 if a sequence number is increased by one every 3.3 millisecond, then 145 it will reach its maximum value in less than 24 weeks. This can 146 result in potential inter-session replay attacks especially when BFD 147 uses the non-meticulous authentication modes. 149 Note that when using authentication mechanisms, BFD drops all packets 150 that fall outside the limited range (3* Detection time multiplier). 151 Therefore, when meticulous authentication modes are used, a replayed 152 BFD packet will be rejected if it cannot fit into a relatively short 153 window (3 times the detect interval of the session). This introduces 154 some difficulties for replaying packets. However, in a non- 155 meticulous authentication mode, such windows can be large as sequence 156 numbers are only increased occasionally, thus making it easier to 157 perform replay attacks . 159 In a BFD session, each node needs to select a 32-bit discriminator to 160 identify itself. Therefore, a BFD session is identified by two 161 discriminators. If a node will randomly select a new discriminator 162 for a new session and uses authentication mechanism to secure the 163 control packets, inter-session replay attacks can be mitigated to 164 some extent. However, in existing BFD demultiplexing mechanisms, the 165 discriminators used in a new BFD session may be predictable. In some 166 deployment scenarios, the discriminators of BFD routers may be 167 decided by the destination and source addresses. So, if the sequence 168 number of a BFD router rolls over for some reason (e.g., reboot), the 169 discriminators used to identify the new session will be identical to 170 the ones used in the previous session. This makes performing a reply 171 attack relatively simple. 173 BFD allows a mode called the echo mode. Echo packets are not defined 174 in the BFD specification, though they can keep the BFD session up. 175 The format of the echo packet is local to the sending side and there 176 are no guidelines on the properties of these packets beyond the 177 choice of the source and destination addresses. While the BFD 178 specification recommends applying security mechanisms to prevent 179 spoofing of these packets, there are no guidelines on what type of 180 mechanisms are appropriate. 182 4. Impacts of BFD Replays 184 As discussed, BFD cannot meet the requirements of inter-session or 185 intra-session replay protection. This section discusses the impacts 186 of BFD replays. 188 When cryptographic authentication mechanisms are adopted for BFD, a 189 non-decreasing 32-bit long sequence number is used. In the Keyed MD5 190 and the Keyed SHA-1 mechanisms, the sequence member is not required 191 to increase for every packet. Therefore an attacker can keep 192 replaying the packets with the latest sequence number until the 193 sequence number is updated. This issue is eliminated in the 194 Meticulous Keyed MD5 and the Meticulous Keyed SHA-1 mechanisms. 195 However, note that a sequence number may reach its maximum and be 196 rolled over in a session. In this case, without the support from a 197 automatic key management mechanism, the BFD session will be 198 vulnerable to replay attacks performed by sending the packets before 199 the roll over of the sequence number. For instance, an attacker can 200 replay a packet with a sequence number which is larger than the 201 current one. If the replayed packet is accepted, the victim will 202 reject the legal packets whose sequence members are less than the one 203 in the replayed packet. Therefore, the attacker can get a good 204 chance to bring down the BFD session. This kind of attack assumes 205 that attacker has access to the link when the BFD session is on a 206 point to point link, or can inject packets for a BFD session with 207 multiple hops. 209 Additionally, the BFD specification allows for the change of 210 authentication state based on the state of a received packet. For 211 instance, according to BFD [RFC5880], if the state of a accepted 212 packet is down, the receiver of the packet needs to transfer its 213 state to down as well. Therefore, an carefully selected replayed 214 packet can cause a serious denial-of-service attack. 216 BFD does not provide any solution to deal with inter-session replay 217 attacks. If two subsequent BFD sessions adopt an identical 218 discriminator pair and use the same cryptographic key to secure the 219 control packets, it is intuitive to use a malicious authenticated 220 packet (stored from the past session) to perform inter-connection 221 replay attacks. 223 Any security issues in the BFD echo mode will directly affect the BFD 224 protocol and session states, and hence the network stability. For 225 instance, any replay attacks would be indistinguishable from normal 226 forwarding of the tested router. An attack would still cause a 227 faulty link to be believed to be up, but there is little that can be 228 done about it. However, if the echo packets are guessable, it may be 229 possible to spoof from an external source and cause BFD to believe 230 that a one-way link is really bidirectional. As a result, it is 231 important that the echo packets contain random material that is also 232 checked upon reception. 234 5. Impact of New Authentication Requirements 236 BFD can be run in software or hardware. Hardware implementations run 237 BFD at a much smaller timeout, typically in the order of few 238 milliseconds. For instance with a timeout of 3.3 milliseconds, a BFD 239 session is required to send or receive 3 packets every 10 240 milliseconds. Software implementations typically run with a timeout 241 in hundreds of milliseconds. 243 Additionally, it is not common to find hardware support for computing 244 the authentication data for the BFD session in hardware or software. 245 In the keyed MD5 and Keyed SHA-1 implementation where the sequence 246 number does not increase with every packet, software can be used to 247 compute the authentication data. This is true if the time between 248 increasing sequence number is long enough to compute the data in 249 software. The ability to compute the hash in software is difficult 250 with Meticulous Keyed MD5 and Meticulous Keyed SHA-1 if the time 251 interval between transmits or between receives is small. The 252 computation problem becomes worse if hundred or thousands of sessions 253 require the hash to be recomputed every few milliseconds. 255 Smaller and cheaper boxes that have to support a few hundred BFD 256 sessions are boxes that also use a slower CPU. The CPU is used for 257 running the entire control plane software in addition to supporting 258 the BFD sessions. As a general rule, no more than 40-45% of the CPU 259 can be dedicated towards supporting BFD. Adding computation of the 260 hash for every BFD session, can easily cause the CPU to exceed the 261 40-45% limit even with a few tens of sessions. On higher end boxes 262 with faster and more CPU cores, the expectation is that the number of 263 sessions that need to be supported are in the thousands, but the 264 number of BFD sessions with authentication that CPU can support is 265 still in the hundreds. 267 Implementors should assess the impact of authenticating BFD sessions 268 on their platform. 270 6. Considerations for improvement 272 This section suggests changes that can be adopted to improve the 273 protection of BFD. 275 The security risks brought by SHA-1 and MD5 have been well 276 understood. However, when using stronger digest algorithm, e.g., 277 SHA-2, the imposed computing overhead will seriously affect the 278 performance of BFD implementation. In order to make the trade-off 279 between the strong algorithm requirement and the imposed overhead, 280 Galois Message Authentication Code (GMAC) can be a candidate option. 281 This algorithm is relatively effective and has been supported by 282 IPsec for data origin authentication. More detailed information can 283 be found in The Use of GMAC in IPsec ESP and AH [RFC4543]. 285 There has been some hallway conversation around the idea of using BFD 286 cryptographic authentication only when some data in the BFD payload 287 changes. The other BFD packets can be transmitted and received 288 without authentication enabled. Bulk of the BFD packets that are 289 transmitted and received have no state change associated with them. 290 Limiting authentication to BFD packets that affect a BFD session 291 state allows for more sessions to be supported for authentication. 292 This change can significantly help the routers since they dont have 293 to compute and verify the authentication digest for the BFD packets 294 coming at the milli-second intervals. This proposal needs some more 295 discussion in the BFD working group and is certainly a direction that 296 BFD could look at. 298 7. IANA Considerations 300 This document makes no request of IANA. 302 Note to RFC Editor: this section may be removed on publication as an 303 RFC. 305 8. Security Considerations 307 This document discusses vulnerabilities in the existing BFD protocol 308 and suggests possible mitigations. 310 In analyzing the improvements for BFD the ability to repel a replay 311 attack is discussed. For example, increasing the sequence number to 312 a 64bit value makes the wrap around time much longer and a replay 313 attack can be easily prevented. 315 Mindful of the impact that stronger algorithms can have on the 316 performance of BFD, the document suggests GMAC as a possible 317 candidate for MAC function. 319 9. Acknowledgements 321 We would like to thank Alexander Vainshtein for his comments on this 322 document. 324 10. References 326 10.1. Normative References 328 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 329 April 1992. 331 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 332 (BFD)", RFC 5880, June 2010. 334 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 335 with Existing Cryptographic Protection Methods for Routing 336 Protocols", RFC 6039, October 2010. 338 10.2. Informative References 340 [I-D.ietf-bfd-generic-crypto-auth] 341 Bhatia, M., Manral, V., Zhang, D., and M. Jethanandani, 342 "BFD Generic Cryptographic Authentication", draft-ietf- 343 bfd-generic-crypto-auth-06 (work in progress), April 2014. 345 [I-D.ietf-bfd-hmac-sha] 346 Zhang, D., Bhatia, M., Manral, V., and M. Jethanandani, 347 "Authenticating BFD using HMAC-SHA-2 procedures", draft- 348 ietf-bfd-hmac-sha-05 (work in progress), July 2014. 350 [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message 351 Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, 352 May 2006. 354 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 355 Authentication", RFC 4822, February 2007. 357 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 358 and M. Fanto, "IS-IS Generic Cryptographic 359 Authentication", RFC 5310, February 2009. 361 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 362 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 363 Authentication", RFC 5709, October 2009. 365 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 366 Routing Protocols (KARP) Design Guidelines", RFC 6518, 367 February 2012. 369 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 370 Authentication for Routing Protocols (KARP) Overview, 371 Threats, and Requirements", RFC 6862, March 2013. 373 Authors' Addresses 375 Manav Bhatia 376 Ionos Networks 377 Bangalore 378 India 380 Email: manav@ionosnetworks.com 381 Dacheng Zhang 382 Alibaba 383 Beijing 384 China 386 Email: dacheng.zdc@alibaba-inc.com 388 Mahesh Jethanandani 389 Ciena Corporation 390 3939 North 1st Street 391 San Jose, CA 95134 392 USA 394 Phone: 408.904.2160 395 Fax: 408.436.5582 396 Email: mjethanandani@gmail.com