Gunter Van de Velde has entered the following ballot position for draft-ietf-bfd-optimizing-authentication-32: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-bfd-optimizing-authentication-32 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bfd-optimizing-authentication-32.txt # for your convenience, please find some non-blocking COMMENTS # I am missing an operational guidance section to help operators to operate optimized bfd. # comments # ======== 17 Abstract 18 19 This document describes an experimental optimization to BFD 20 Authentication. It provides a procedure where BFD state transitions 21 require strong authentication and permits the majority of BFD Control 22 Packets to use a less computationally intensive authentication 23 mechanism. This enables BFD to scale better when there is a desire 24 to use strong authentication. GV> This draft seems to suggest updating the procedures of RFC5880. Should that not be mentioned in some form or embodiment within the abstract? demand mode changes 143 | significant | State change, a demand mode change (to | 144 | change | D bit) or a poll sequence change (P or | 145 | | F bit). Changes to BFD control packets | 146 | | that do not require a poll sequence, | 147 | | such as bfd.DetectMult are also | 148 | | considered as a significant change. | GV> The abstract mentions only state transitions, but with this definition of "significant change" there may be more included as just state change. Is my assumption correct? What i considered as state change: * Down → Init: When a system starts sending BFD packets to initiate a session. * Init → Up: When a system receives valid BFD packets from the remote peer and both sides agree on session parameters. * Up → Down: When a failure is detected (e.g., missing packets beyond the detection time threshold). * Up → Init: May occur during reinitialization or configuration changes. 162 BFD. For example, MD5 and SHA1 (Section 6.7 of [RFC5880]). GV> If the list is short, maybe display them all and not an example set 164 The intention of these optimized procedures is to permit strong 165 authentication for BFD state changes and utilize the less 166 computationally intensive authentication mechanisms to provide 167 protection for the session in the Up state while performing less 168 overall work. Such procedures will aid BFD session scaling without 169 compromising BFD session security. GV> " The optimized procedures are intended to enable the use of strong authentication for BFD state transitions while relying on less computationally intensive mechanisms to protect sessions in the Up state. This approach reduces overall processing requirements and facilitates BFD session scaling without reducing session security. " 171 All BFD Control Packets with the states AdminDown, Down, and Init 172 MUST use strong authentication. GV> s/Packets with the states/Packets when in the state/ 174 Once the BFD state machine has reached the Up state, it will continue 175 to send BFD Control Packets in the Up state for a period as discussed 176 in Section 7.2. If optimized authentication mechanisms are in use, GV> s/it will continue to send BFD Control Packets/it will continue to send computationally intensive BFD Control Packets/ 180 The contents of an Up packet MUST NOT change aside from the 181 Authentication Section without strong authentication. GV> " The contents of an Up packet, other than the Authentication Section, MUST NOT change unless strong authentication is in use. " 233 This "strong reauthentication interval" for performing such periodic 234 tests using the strong authentication mechanism can be configured 235 depending on the capability of the system. GV> The description here does not suggest min or maximum interval. It would be operational interesting to have a suggested interval guideline, and an absolute minimum of these polls to do per second or minute to avoid security degradation 237 Most packets transmitted on a BFD session are BFD Up packets. 238 Strongly authenticating a small subset of these packets with a Poll 239 sequence as described above, for example every one minute, 240 significantly reduces the computational demand for the system while 241 maintaining security of the session across the configured strong 242 reauthentication interval. GV> " Most packets transmitted in a BFD session are Up packets. Strongly authenticating a limited subset of these packets, for example through a Poll sequence performed once per minute, substantially reduces system computational load while preserving session security across the configured strong reauthentication interval. " 317 The values of the Optimized Authentication Mode field are: 318 319 1. When using the strong authentication type for optimized BFD Auth 320 Types. 321 322 2. When using the less computationally intensive authentication type 323 for optimized BFD Auth Types. GV> are these numerical values "1" and "2" set within the Opt. Mode field? or are both examples? (easy fix to clarify) 329 7.1. Transmitting and Receiving Using Optimized Authentication GV> Would this be non-backward compatible, as rfc5880 assumes (i seem to remember) a single authentication type per session, and now with this experimental proposal we have multiple. Shoud the non-backward compatible property be called out in this section? 418 8.1. Data Model Overview GV> Some of the default values for this experimental draft are already defined in the YANG model. But for the purpose of making things easier to follow, wouldn’t it be helpful to also mention them explicitly in an operational guidance section? That way, readers working with optimized BFD don’t have to go digging through the model just to figure out what defaults they’re expected to use. Kind Regards, Gunter Van de Velde RTG Area Director
