idnits 2.17.1 draft-ietf-bfd-optimizing-authentication-09.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). -- The document date (December 9, 2019) is 1572 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-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Jethanandani 3 Internet-Draft VMware 4 Intended status: Standards Track A. Mishra 5 Expires: June 11, 2020 SES Networks 6 A. Saxena 7 Ciena Corporation 8 M. Bhatia 9 Nokia 10 December 9, 2019 12 Optimizing BFD Authentication 13 draft-ietf-bfd-optimizing-authentication-09 15 Abstract 17 This document describes an optimization to BFD Authentication as 18 described in Section 6.7 of BFD RFC5880. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in BCP 14 [RFC2119] 25 [RFC8174] when, and only when, they appear in all capitals, as shown 26 here. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 11, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3 64 3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 6.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Authenticating every BFD [RFC5880] packet with a Simple Password, or 75 with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash 76 Algorithm (SHA-1) algorithms is computationally intensive process, 77 making it difficult if not impossible to authenticate every packet - 78 particularly at faster rates. Also, the recent escalating series of 79 attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise 80 concerns about their remaining useful lifetime as outlined in Updated 81 Security Considerations for the MD5 Message-Digest and the HMAC-MD5 82 Algorithm [RFC6151] and Security Considerations for the SHA-0 and 83 SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by stronger 84 algorithms, the computational overhead, will make the task of 85 authenticating every packet even more difficult to achieve. 87 This document proposes that only BFD frames that signal a state 88 change in BFD be authenticated. Rest of the frames can be 89 transmitted and received without authentication enabled. Most frames 90 that are transmitted and received have no state change associated 91 with them. Limiting authentication to frames that affect a BFD 92 session state allows more sessions to be supported for 93 authentication. Moreover, most BFD frames that signal a state change 94 are generally transmitted at a slower interval of 1s leaving enough 95 time to compute the hash. To detect a Man In the Middle (MITM) 96 attack, it is also proposed that a non-state change frame be 97 authenticated occasionally. The interval of this non-state change 98 frame can be configured depending on the detect multiplier and the 99 capability of the system. As an example, this could be equal to the 100 detect multiplier number of packets. 102 The rest of the document is structured as follows. Section 2 talks 103 about the changes to authentication mode as described in BFD 104 [RFC5880]. Section 3 goes into the details of the new Authentication 105 TLV. 107 2. Authentication Mode 109 The cryptographic authentication mechanisms specified in BFD 110 [RFC5880] describes enabling and disabling of authentication as a one 111 time operation. As a security precaution, it mentions that 112 authentication state be allowed to change at most once. Once 113 enabled, every packet must have Authentication Bit set and the 114 associated Authentication TLV appended. In addition, it states that 115 an implementation SHOULD NOT allow the authentication state to be 116 changed based on the receipt of a BFD Control packet. 118 This document proposes that the authentication mode be modified to be 119 enabled on demand. Instead of authenticating every packet, BFD peers 120 are configured for which frames need to be authenticated, and 121 authenticate only those frames. Rest of the frames can be 122 transmitted and received without authentication. For example, the 123 two ends can be configured such that BFD frames that indicate a state 124 change should be authenticated and enable authentication on those 125 frames only. If the two ends have previously been configured as 126 such, but at least one side decides not to authenticate a state 127 change frame, then the BFD session will fail to come up. 129 This proposal outlines which frames need to be authenticated (carry 130 the A-bit), and which frames can be transmitted or received without 131 authentication enabled. A frame that fails authentication is 132 discarded, or a frame that was supposed to be authenticated, but was 133 not, e.g. a state-change frame, is discarded. However, there is no 134 change to the state machine for BFD, as the decision of a state 135 change is still decided by how many valid consecutive frames were 136 received, authenticated or otherwise. 138 The state changes for which authentication is being suggested 139 include: 141 Read : On state change from to 142 Auth : Authenticate frame 143 NULL : No Authentication. Use NULL AUTH TLV. 144 n/a : Invalid state transition. 145 Select : Most frames NULL AUTH. Selective (periodic) 146 frames authenticated. 147 +--------+--------+--------+--------+--------+--------+ 148 | | DOWN | INIT | UP | POLL | DEMAND | 149 +--------+--------+--------+--------+--------+--------+ 150 | DOWN | NULL | Auth | Auth | Auth | Auth | 151 +--------+--------+--------+--------+--------+--------+ 152 | INIT | Auth | NULL | Auth | Auth | Auth | 153 +--------+--------+--------+--------+--------+--------+ 154 | UP | Auth | n/a | Select | Auth | Auth | 155 +--------+--------+--------+--------+--------+--------+ 156 | POLL | Auth | n/a | Auth | Auth | Auth | 157 +--------+--------+--------+--------+--------+--------+ 158 | DEMAND | Auth | Auth | Auth | Auth | Auth | 159 +--------+--------+--------+--------+--------+--------+ 161 Optimized Authentication Map 163 All frames already carry the sequence number. The NULL AUTH frames 164 MUST contain the TLV specified in Section 3. This enables a 165 monotonically increasing sequence number to be carried in each frame, 166 and prevents man-in-the-middle from capturing and replaying the same 167 frame again. Since all frames still carry a sequence number, the 168 logic for sequence number maintenance remains unchanged from 169 [RFC5880]. If at a later time, a different scheme is adopted for 170 changing sequence number, this method can use the updated scheme 171 without any impact. 173 Most frames transmitted on a BFD session are BFD CC UP frames. 174 Authenticating a small subset of these frames, for example, a detect 175 multiplier number of packets per configured period, significantly 176 reduces the computational demand for the system while maintaining 177 security of the session across the configured authentication periods. 178 A minimum of Detect Multiplier packets MUST be transmitted per 179 configured periodic authentication interval. This ensures that the 180 BFD session should see at least one authenticated packet during that 181 interval. 183 3. NULL Auth TLV 185 This section describes a new Authentication TLV as: 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Auth Type | Auth Len | Auth Key ID | Reserved | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Sequence Number | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 NULL Auth TLV 197 where: 199 Auth Type: The Authentication Type, which in this case is TBD (NULL 200 Auth TLV, to be assigned by IANA) 202 Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes 204 Auth Key ID: The authentication key ID in use for this packet. Must 205 be set to zero. 207 Reserved: This byte MUST be set to zero on transmit and ignored on 208 receive. 210 Sequence Number: The sequence number for this packet. Implementation 211 may use sequence numbers as defined in [RFC5880], or secure sequence 212 numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers]. 214 The NULL Auth TLV must be used for all frames that are not 215 authenticated. This protects against replay-attacks by allowing the 216 session to maintain an incrementing sequence number for all frames 217 (authenticated and un-authenticated). 219 In the future, if a new scheme is adopted for changing the sequence 220 number, this method can adopt the new scheme without any impact. 222 4. IANA Considerations 224 This document requests an update to the registry titled "BFD 225 Authentication Types". IANA is requested to to assign a new BFD Auth 226 Type for "NULL Auth TLV" (see Section 3). 228 Note to RFC Editor: this section may be removed on publication as an 229 RFC. 231 5. Security Considerations 233 The approach described in this document enhances the ability to 234 authentication a BFD session by taking away the onerous requirement 235 that every frame be authenticated. By authenticating frames that 236 affect the state of the session, the security of the BFD session is 237 maintained. As such this document does not change the security 238 considerations for BFD. 240 6. References 242 6.1. Normative References 244 [I-D.ietf-bfd-secure-sequence-numbers] 245 Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and 246 A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- 247 secure-sequence-numbers-04 (work in progress), August 248 2019. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 256 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 257 May 2017, . 259 6.2. Informative References 261 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 262 DOI 10.17487/RFC1321, April 1992, 263 . 265 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 266 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 267 . 269 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 270 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 271 RFC 6151, DOI 10.17487/RFC6151, March 2011, 272 . 274 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 275 Considerations for the SHA-0 and SHA-1 Message-Digest 276 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 277 . 279 [SHA-1-attack1] 280 Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the 281 Full SHA-1", 2005. 283 [SHA-1-attack2] 284 Wang, X., Yao, A., and F. Yao, "New Collision Search for 285 SHA-1", 2005. 287 Authors' Addresses 289 Mahesh Jethanandani 290 VMware 291 USA 293 Email: mjethanandani@gmail.com 295 Ashesh Mishra 296 SES Networks 298 Email: mishra.ashesh@gmail.com 300 Ankur Saxena 301 Ciena Corporation 302 3939 N 1st Street 303 San Jose, CA 95134 304 USA 306 Email: ankurpsaxena@gmail.com 308 Manav Bhatia 309 Nokia 310 Bangalore 311 India 313 Email: manav.bhatia@nokia.com