idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-11.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 (July 28, 2020) is 1365 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-05 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: January 29, 2021 A. Saxena 7 Ciena Corporation 8 M. Bhatia 9 Nokia 10 July 28, 2020 12 Optimizing BFD Authentication 13 draft-ietf-bfd-optimizing-authentication-11 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 January 29, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 4 59 3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 6.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Authenticating every BFD [RFC5880] control packet with a Simple 70 Password, or with a MD5 Message-Digest Algorithm [RFC1321] , or 71 Secure Hash Algorithm (SHA-1) algorithms is a computationally 72 intensive process. This makes it difficult, if not impossible to 73 authenticate every packet - particularly at faster rates. Also, the 74 recent escalating series of attacks on MD5 and SHA-1 described in 75 Finding Collisions in the Full SHA-1 [SHA-1-attack1] and New 76 Collision Search for SHA-1 [SHA-1-attack2] raise concerns about their 77 remaining useful lifetime as outlined in Updated Security 78 Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm 79 [RFC6151] and Security Considerations for the SHA-0 and SHA-1 80 Message-Digest Algorithm [RFC6194]. If replaced by stronger 81 algorithms, the computational overhead, will make the task of 82 authenticating every packet even more difficult to achieve. 84 This document proposes that only BFD control packets that signal a 85 state change, a demand mode change (to D bit) or a poll sequence 86 change (P or F bit change) in a BFD control packet be categorized as 87 a significant change. This document also proposes that all BFD 88 control packets which signal a significant change MUST be 89 authenticated if the session's bfd.AuthType is non-zero. Other BFD 90 control packets MAY be transmitted and received without the A bit 91 set. 93 Most packets that are transmitted and received have no state change 94 associated with them. Limiting authentication to packets that affect 95 a BFD session state allows more sessions to be supported with this 96 optimized method of authentication. Moreover, most BFD control 97 packets that signal a significant change are generally transmitted at 98 a slower interval of 1s, leaving enough time to compute the hash. 100 To detect a Man In the Middle (MITM) attack, it is also proposed that 101 a BFD control packet without a significant change be authenticated 102 occasionally. The interval of the BFD control packets without a 103 significant change can be configured depending on the detect 104 multiplier and the capability of the system. As an example, this 105 could be equal to the detect multiplier number of packets. 107 The rest of the document is structured as follows. Section 2 talks 108 about the changes to authentication mode as described in BFD 109 [RFC5880]. Section 3 goes into the details of the new Authentication 110 Type. 112 1.1. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14 [RFC2119] 117 [RFC8174] when, and only when, they appear in all capitals, as shown 118 here. 120 1.2. Terminology 122 The following terms used in this document have been defined in BFD 123 [RFC5880]. 125 o Detect Multiplier 127 o Detection Time 129 The following terms are introduced in this document. 131 +--------------+----------------------------------------------------+ 132 | Term | Meaning | 133 +--------------+----------------------------------------------------+ 134 | significant | State change, a demand model change (to D bit) or | 135 | change | a poll sequence change (P or F bit). | 136 | | | 137 | configured | Interval at which BFD control packets are | 138 | interval | authenticated in the UP state. | 139 +--------------+----------------------------------------------------+ 141 2. Authentication Mode 143 The cryptographic authentication mechanisms specified in BFD 144 [RFC5880] describes enabling and disabling of authentication as a one 145 time operation. As a security precaution, it mentions that 146 authentication state be allowed to change at most once. Once 147 enabled, every packet must have Authentication Bit set and the 148 associated Authentication Type appended. In addition, it states that 149 an implementation SHOULD NOT allow the authentication state to be 150 changed based on the receipt of a BFD control packet. 152 This document proposes that the authentication mode be modified to be 153 enabled on demand. Instead of authenticating every packet, BFD peers 154 are configured for which packets need to be authenticated, and 155 authenticate only those packets. Rest of the packets can be 156 transmitted and received without authentication. For example, the 157 two ends can be configured such that BFD control packets that 158 indicate a significant change should be authenticated and enable 159 authentication on those packets only. If the two ends have 160 previously been configured as such, but at least one side decides not 161 to authenticate a significant change packet, then the BFD session 162 will fail to come up. 164 This proposal outlines which BFD control packets need to be 165 authenticated (carry the A-bit), and which packets can be transmitted 166 or received without authentication enabled. A BFD control packet 167 that fails authentication is discarded, or a BFD control packet that 168 was supposed to be authenticated, but was not, e.g. a significant 169 change packet, is discarded. However, there is no change to the 170 state machine for BFD, as the decision of a significant change is 171 still decided by how many valid consecutive packets were received, 172 authenticated or otherwise. 174 The following table summarizes when the A bit should be set. The 175 table should be read with the column indicating the BFD state the 176 receiver is currently in, and the row indicating the BFD state the 177 receiver might transition to based on the BFD control packet 178 received. The interesection of the two indicates whether the 179 received BFD control packet should have the A bit set (Auth), no 180 authentication is needed (NULL), most packets are NULL AUTH (Select) 181 or the state transition is not applicable. The BFD state refers to 182 the states in BFD state machine described in Section 6.2 of BFD 183 [RFC5880]. 185 Read : On state change from to 186 Auth : Authenticate BFD control packet 187 NULL : No Authentication. Use NULL AUTH Type. 188 n/a : Invalid state transition. 189 Select : Most packets NULL AUTH. Selective (periodic) 190 packets authenticated. 191 +--------+--------+--------+--------+ 192 | | DOWN | INIT | UP | 193 +--------+--------+--------+--------+ 194 | DOWN | NULL | Auth | Auth | 195 +--------+--------+--------+--------+ 196 | INIT | Auth | NULL | n/a | 197 +--------+--------+--------+--------+ 198 | UP | Auth | Auth | Select | 199 +--------+--------+--------+--------+ 201 Optimized Authentication Map 203 If P or F bit changes value, the BFD control packet MUST be 204 authenticated. If the D bit changes value, the BFD control packet 205 MUST be authenticated. 207 All packets already carry the sequence number. The NULL AUTH packets 208 MUST contain the Type specified in Section 3. This enables a 209 monotonically increasing sequence number to be carried in each 210 packet, and prevents man-in-the-middle from capturing and replaying 211 the same packet again. Since all packets still carry a sequence 212 number, the logic for sequence number maintenance remains unchanged 213 from BFD [RFC5880]. If at a later time, a different scheme is 214 adopted for changing sequence number, e.g. Secure BFD Sequence 215 Numbers [I-D.ietf-bfd-secure-sequence-numbers], this method can use 216 the updated scheme without any impact. 218 Most packets transmitted on a BFD session are BFD UP packets. 219 Authenticating a small subset of these packets, for example, a detect 220 multiplier number of packets per configured interval, significantly 221 reduces the computational demand for the system while maintaining 222 security of the session across the configured interval. A minimum of 223 Detect Multiplier packets MUST be transmitted per configured 224 interval. This ensures that the BFD session should see at least one 225 authenticated packet during that interval. 227 3. NULL Auth Type 229 This section describes a new Authentication Type as: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Auth Type | Auth Len | Auth Key ID | Reserved | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Sequence Number | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 NULL Auth Type 241 where: 243 Auth Type: The Authentication Type, which in this case is TBD (NULL, 244 to be assigned by IANA) 246 Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes 248 Auth Key ID: The authentication key ID in use for this packet. Must 249 be set to zero. 251 Reserved: This byte MUST be set to zero on transmit and ignored on 252 receive. 254 Sequence Number: The sequence number for this packet. Implementation 255 may use sequence numbers (bfd.XmitAuthSeq) as defined in BFD 256 [RFC5880], or secure sequence numbers as defined in Secure BFD 257 Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]. 259 The NULL Auth Type must be used for all packets that are not 260 authenticated. This protects against replay-attacks by allowing the 261 session to maintain an incrementing sequence number for all packets 262 (authenticated and un-authenticated). 264 In the future, if a new scheme is adopted for changing the sequence 265 number, this method can adopt the new scheme without any impact. 267 4. IANA Considerations 269 This document requests an update to the registry titled "BFD 270 Authentication Types". IANA is requested to assign a new BFD Auth 271 Type for "NULL" (see Section 3). 273 Note to RFC Editor: this section may be removed on publication as an 274 RFC. 276 5. Security Considerations 278 The approach described in this document enhances the ability to 279 authenticate a BFD session by taking away the onerous requirement 280 that every BFD control packet be authenticated. By authenticating 281 packets that affect the state of the session, the security of the BFD 282 session is maintained. In this mode, packets that are a significant 283 change but are not authenticated, are dropped by the system. 284 Therefore, a malicious user that tries to inject a non-authenticated 285 packet, e.g. with a Down state to take a session down will fail. 286 That combined with the proposal of using sequence number defined in 287 Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers] 288 further enhances the security of BFD sessions. 290 6. References 292 6.1. Normative References 294 [I-D.ietf-bfd-secure-sequence-numbers] 295 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 296 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 297 secure-sequence-numbers-05 (work in progress), February 298 2020. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, 302 DOI 10.17487/RFC2119, March 1997, 303 . 305 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 306 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 307 . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 6.2. Informative References 315 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 316 DOI 10.17487/RFC1321, April 1992, 317 . 319 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 320 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 321 RFC 6151, DOI 10.17487/RFC6151, March 2011, 322 . 324 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 325 Considerations for the SHA-0 and SHA-1 Message-Digest 326 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 327 . 329 [SHA-1-attack1] 330 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 331 Full SHA-1", 2005. 333 [SHA-1-attack2] 334 Wang, X., Yao, A., and F. Yao, "New Collision Search for 335 SHA-1", 2005. 337 Authors' Addresses 339 Mahesh Jethanandani 340 Kloud Services 341 USA 343 Email: mjethanandani@gmail.com 345 Ashesh Mishra 346 SES Networks 348 Email: mishra.ashesh@gmail.com 350 Ankur Saxena 351 Ciena Corporation 352 3939 N 1st Street 353 San Jose, CA 95134 354 USA 356 Email: ankurpsaxena@gmail.com 358 Manav Bhatia 359 Nokia 360 Bangalore 361 India 363 Email: manav.bhatia@nokia.com