idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-13.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5880, updated by this document, for RFC5378 checks: 2004-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 August 2021) is 999 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-ietf-bfd-secure-sequence-numbers-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft Kloud Services 4 Updates: 5880 (if approved) A. Mishra 5 Intended status: Standards Track SES Networks 6 Expires: 2 February 2022 A. Saxena 7 Ciena Corporation 8 M. Bhatia 9 Nokia 10 1 August 2021 12 Optimizing BFD Authentication 13 draft-ietf-bfd-optimizing-authentication-13 15 Abstract 17 This document describes an optimization to BFD Authentication as 18 described in Section 6.7 of BFD RFC 5880. This document updates RFC 19 5880. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 2 February 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 4 58 3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 6.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 Authenticating every BFD [RFC5880] control packet with a Simple 69 Password, or with a MD5 Message-Digest Algorithm [RFC1321] , or 70 Secure Hash Algorithm (SHA-1) algorithms is a computationally 71 intensive process. This makes it difficult, if not impossible to 72 authenticate every packet - particularly at faster rates. Also, the 73 recent escalating series of attacks on MD5 and SHA-1 described in 74 Finding Collisions in the Full SHA-1 [SHA-1-attack1] and New 75 Collision Search for SHA-1 [SHA-1-attack2] raise concerns about their 76 remaining useful lifetime as outlined in Updated Security 77 Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm 78 [RFC6151] and Security Considerations for the SHA-0 and SHA-1 79 Message-Digest Algorithm [RFC6194]. If replaced by stronger 80 algorithms, the computational overhead, will make the task of 81 authenticating every packet even more difficult to achieve. 83 This document proposes that only BFD control packets that signal a 84 state change, a demand mode change (to D bit) or a poll sequence 85 change (P or F bit change) in a BFD control packet be categorized as 86 a significant change. This document also proposes that all BFD 87 control packets which signal a significant change MUST be 88 authenticated if the session's bfd.AuthType is non-zero. Other BFD 89 control packets MAY be transmitted and received without the A bit 90 set. 92 Most packets that are transmitted and received have no state change 93 associated with them. Limiting authentication to packets that affect 94 a BFD session state allows more sessions to be supported with this 95 optimized method of authentication. Moreover, most BFD control 96 packets that signal a significant change are generally transmitted at 97 a slower interval of 1s, leaving enough time to compute the hash. 99 To detect a Man In the Middle (MITM) attack, it is also proposed that 100 a BFD control packet without a significant change be authenticated 101 occasionally. The interval of the BFD control packets without a 102 significant change can be configured depending on the detect 103 multiplier and the capability of the system. As an example, this 104 could be equal to the detect multiplier number of packets. 106 The rest of the document is structured as follows. Section 2 talks 107 about the changes to authentication mode as described in BFD 108 [RFC5880]. Section 3 goes into the details of the new Authentication 109 Type. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in BCP 14 [RFC2119] 116 [RFC8174] when, and only when, they appear in all capitals, as shown 117 here. 119 1.2. Terminology 121 The following terms used in this document have been defined in BFD 122 [RFC5880]. 124 * Detect Multiplier 126 * Detection Time 128 The following terms are introduced in this document. 130 +====================+==============================================+ 131 | Term | Meaning | 132 +====================+==============================================+ 133 | significant | State change, a demand model change (to D | 134 | change | bit) or a poll sequence change (P or F bit). | 135 +--------------------+----------------------------------------------+ 136 +--------------------+----------------------------------------------+ 137 | configured | Interval at which BFD control packets are | 138 | interval | authenticated in the UP state. | 139 +--------------------+----------------------------------------------+ 141 Table 1 143 2. Authentication Mode 145 The cryptographic authentication mechanisms specified in BFD 146 [RFC5880] describes enabling and disabling of authentication as a one 147 time operation. As a security precaution, it mentions that 148 authentication state be allowed to change at most once. Once 149 enabled, every packet must have Authentication Bit set and the 150 associated Authentication Type appended. In addition, it states that 151 an implementation SHOULD NOT allow the authentication state to be 152 changed based on the receipt of a BFD control packet. 154 This document proposes that the authentication mode be modified to be 155 enabled on demand. Instead of authenticating every packet, BFD peers 156 are configured for which packets need to be authenticated, and 157 authenticate only those packets. Rest of the packets can be 158 transmitted and received without authentication. For example, the 159 two ends can be configured such that BFD control packets that 160 indicate a significant change should be authenticated and enable 161 authentication on those packets only. If the two ends have 162 previously been configured as such, but at least one side decides not 163 to authenticate a significant change packet, then the BFD session 164 will fail to come up. 166 This proposal outlines which BFD control packets need to be 167 authenticated (carry the A-bit), and which packets can be transmitted 168 or received without authentication enabled. A BFD control packet 169 that fails authentication is discarded, or a BFD control packet that 170 was supposed to be authenticated, but was not, e.g. a significant 171 change packet, is discarded. However, there is no change to the 172 state machine for BFD, as the decision of a significant change is 173 still decided by how many valid consecutive packets were received, 174 authenticated or otherwise. 176 The following table summarizes when the A bit should be set. The 177 table should be read with the column indicating the BFD state the 178 receiver is currently in, and the row indicating the BFD state the 179 receiver might transition to based on the BFD control packet 180 received. The interesection of the two indicates whether the 181 received BFD control packet should have the A bit set (Auth), no 182 authentication is needed (NULL), most packets are NULL AUTH (Select) 183 or the state transition is not applicable. The BFD state refers to 184 the states in BFD state machine described in Section 6.2 of BFD 185 [RFC5880]. 187 Read : On state change from to 188 Auth : Authenticate BFD control packet 189 NULL : No Authentication. Use NULL AUTH Type. 190 n/a : Invalid state transition. 191 Select : Most packets NULL AUTH. Selective (periodic) 192 packets authenticated. 193 +--------+--------+--------+--------+ 194 | | DOWN | INIT | UP | 195 +--------+--------+--------+--------+ 196 | DOWN | NULL | Auth | Auth | 197 +--------+--------+--------+--------+ 198 | INIT | Auth | NULL | n/a | 199 +--------+--------+--------+--------+ 200 | UP | Auth | Auth | Select | 201 +--------+--------+--------+--------+ 203 Figure 1: Optimized Authentication Map 205 If P or F bit changes value, the BFD control packet MUST be 206 authenticated. If the D bit changes value, the BFD control packet 207 MUST be authenticated. 209 All packets already carry the sequence number. The NULL AUTH packets 210 MUST contain the Type specified in Section 3. This enables a 211 monotonically increasing sequence number to be carried in each 212 packet, and prevents man-in-the-middle from capturing and replaying 213 the same packet again. Since all packets still carry a sequence 214 number, the logic for sequence number maintenance remains unchanged 215 from BFD [RFC5880]. If at a later time, a different scheme is 216 adopted for changing sequence number, e.g. Secure BFD Sequence 217 Numbers [I-D.ietf-bfd-secure-sequence-numbers], this method can use 218 the updated scheme without any impact. 220 Most packets transmitted on a BFD session are BFD UP packets. 221 Authenticating a small subset of these packets, for example, a detect 222 multiplier number of packets per configured interval, significantly 223 reduces the computational demand for the system while maintaining 224 security of the session across the configured interval. A minimum of 225 Detect Multiplier packets MUST be transmitted per configured 226 interval. This ensures that the BFD session should see at least one 227 authenticated packet during that interval. 229 3. NULL Auth Type 231 This section describes a new Authentication Type as: 233 0 1 2 3 234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Auth Type | Auth Len | Auth Key ID | Reserved | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Sequence Number | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 2: NULL Auth Type 243 where: 245 Auth Type: The Authentication Type, which in this case is TBD (NULL, 246 to be assigned by IANA) 248 Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes 250 Auth Key ID: The authentication key ID in use for this packet. Must 251 be set to zero. 253 Reserved: This byte MUST be set to zero on transmit and ignored on 254 receive. 256 Sequence Number: The sequence number for this packet. Implementation 257 may use sequence numbers (bfd.XmitAuthSeq) as defined in BFD 258 [RFC5880], or secure sequence numbers as defined in Secure BFD 259 Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]. 261 The NULL Auth Type must be used for all packets that are not 262 authenticated. This protects against replay-attacks by allowing the 263 session to maintain an incrementing sequence number for all packets 264 (authenticated and un-authenticated). 266 In the future, if a new scheme is adopted for changing the sequence 267 number, this method can adopt the new scheme without any impact. 269 4. IANA Considerations 271 This document requests an update to the registry titled "BFD 272 Authentication Types". IANA is requested to assign a new BFD Auth 273 Type for "NULL" (see Section 3). 275 Note to RFC Editor: this section may be removed on publication as an 276 RFC. 278 5. Security Considerations 280 The approach described in this document enhances the ability to 281 authenticate a BFD session by taking away the onerous requirement 282 that every BFD control packet be authenticated. By authenticating 283 packets that affect the state of the session, the security of the BFD 284 session is maintained. In this mode, packets that are a significant 285 change but are not authenticated, are dropped by the system. 286 Therefore, a malicious user that tries to inject a non-authenticated 287 packet, e.g. with a Down state to take a session down will fail. 288 That combined with the proposal of using sequence number defined in 289 Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers] 290 further enhances the security of BFD sessions. 292 6. References 294 6.1. Normative References 296 [I-D.ietf-bfd-secure-sequence-numbers] 297 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 298 A. DeKok, "Secure BFD Sequence Numbers", Work in Progress, 299 Internet-Draft, draft-ietf-bfd-secure-sequence-numbers-08, 300 8 March 2021, . 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 309 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 310 . 312 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 313 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 314 May 2017, . 316 6.2. Informative References 318 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 319 DOI 10.17487/RFC1321, April 1992, 320 . 322 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 323 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 324 RFC 6151, DOI 10.17487/RFC6151, March 2011, 325 . 327 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 328 Considerations for the SHA-0 and SHA-1 Message-Digest 329 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 330 . 332 [SHA-1-attack1] 333 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 334 Full SHA-1", 2005. 336 [SHA-1-attack2] 337 Wang, X., Yao, A., and F. Yao, "New Collision Search for 338 SHA-1", 2005. 340 Authors' Addresses 342 Mahesh Jethanandani 343 Kloud Services 344 United States of America 346 Email: mjethanandani@gmail.com 348 Ashesh Mishra 349 SES Networks 351 Email: mishra.ashesh@gmail.com 353 Ankur Saxena 354 Ciena Corporation 355 3939 N 1st Street 356 San Jose, CA 95134 357 United States of America 359 Email: ankurpsaxena@gmail.com 360 Manav Bhatia 361 Nokia 362 Bangalore 363 India 365 Email: manav.bhatia@nokia.com