Hello Authors/WG, Thanks for the work put into this document. I know this has been in the works for a long time but there is still some more work needed before it can be taken up for IESG evaluation.
I would like to share my review of the v24 of this document. General Comment/Suggestion: This is about the contents of this document and its relationship with draft-ietf-bfd-stability and draft-ietf-bfd-secure-sequence-numbers. I believe this document does not depend on those other two, at least not normatively as indicated today. This proposal is self sufficient in that it defines the optimized authentication framework without defining any of the optimized auth types - this is perfectly OK. As such, for smooth progression of this work, I would strongly recommend moving all text related to the ISAAC-based auth types from this document into draft-ietf-bfd-secure-sequence-numbers. I am sure there is a solution to avoid reference to the draft-ietf-bfd-stability which is currently used only for the updated YANG model. This way, this document becomes independent of the other two for its further processing. Please find below my comments in the idnits output of v24 and look for <EoRv24> at the very end of the review. If you don't see that, then likely the email has been truncated by your email client and you should look at the BFD WG email archive for the full version. Thanks, Ketan 17 Abstract 19 This document describes an optimization to BFD Authentication as 20 described in Section 6.7 of BFD RFC 5880. It provides procedure <minor> For clarity, I would suggest simplifying the first sentence as follows: This document describes an optimization to BFD Authentication. 88 1. Introduction <major-editorial> There is a lot of normative text and details in this section that may be better moved to Section 4 where they are missing. 90 Authenticating every BFD [RFC5880] control packet with MD5 91 Message-Digest Algorithm [RFC1321], or Secure Hash Algorithm (SHA-1) 92 is a computationally intensive process. This makes it difficult, if 93 not impossible, to authenticate every packet - particularly at faster <minor> I am not sure about the use of "impossible" here. Is that assertion necessary? If so, I suggest providing additional context such as hardware offload and such to project it perhaps as "challenging"? 100 SHA-0 and SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by 101 stronger algorithms the computational overhead will make the task of 102 authenticating every packet even more difficult to achieve. <minor> s/every packet/every BFD packet 104 This document describes an experimental update to BFD [RFC5880]. <major> Since an experimental track document cannot update an standards track document, this needs to be rephrased. Perhaps "describes an experiment that presents a candidate solution to update BFD Authentication that is currently specified in RFC5880" ... or something along those lines? 110 * In the initial stages of the document, there were significant 111 participation and reviews from the working group. Since then, 112 there has been considerable changes to the document, e.g. the use 113 of ISAAC, allowing for ISAAC bootstrapping when a BFD session 114 comes up and use of a single Auth Type to indicate use of 115 optimized authentication etc. These changes did not get 116 significant review from the working group and therefore does not 117 meet the bar set in Section 4.1.1 of [RFC2026] <major> The above bullet needs rephrasing for this document. Isn't the point that the mechanism for alternating between strong and light modes of auth that is described in this document does not meet the bar? The reference to ISAAC does not seem appropriate here. 154 Once the session has reached the Up state, the session can choose a 155 less computationally intensive Auth Type. Currently, this includes: 157 * Meticulous Keyed ISAAC authentication as described in 158 [I-D.ietf-bfd-secure-sequence-numbers]. This authentication type 159 protects the BFD session when BFD Up packets do not change, 160 because only the paired devices know the shared secret, key, and 161 sequence number to select the ISAAC result. <major> Is it not possible to make this document about the mechanism of switching between strong and light auth modes and that alone? Is it not possible to leave the actual auth types to a separate document (i.e. sequence numbers draft) ? 226 +------------------+----------------------------------------------+ 227 | configured | Interval at which BFD control packets are | 228 | strong | retried with strong authentication. | 229 | reauthentication | | 230 | interval | | 231 +------------------+----------------------------------------------+ <question> Can the terms for the two modes of authentication be introduced? Say "strong mode" and "light mode" - where the light mode is what is being referred to as "less computationally intensive" mode in multiple places throughout this document? I believe doing so would help simply the text. 265 3. Signaling Optimized Authentication 267 When the Authentication Present (A) bit is set and the Auth Type is a 268 type supporting Optimized BFD Authentication (Section 6.1), the Auth <minor> The reference to section 6.1 is confusing here. Is it necessary? 279 * The requirement to carry a Sequence Number. <major> Why does this document expect that there can never be an optimized authentication type that would not use/require the use of Sequence Numbers? IOW why does this document not leave the Sequence Number field to the specific Auth Type? i.e., in the sequence number draft. RFC5880 has the precedence to include the sequence number field as something specific to the auth type. 296 The Meticulous Keyed MD5, Meticulous Keyed SHA-1, and Meticulous 297 Keyed ISAAC Authentication Sections define the fourth octet as <major> Where are these sections? 298 "Reserved". This document repurposes the "Reserved" field as the 299 "Optimized Authentication Mode" field when used for authentication 300 types for optimized BFD procedures. <major> Ref sec 4.1 of RFC5880, everything after Auth type and length is specific to the auth type. Ref sec 4.2, there is no reserved field. Ref sec 4.3 and 4.4 which introduces the reserved field but only for those specific types - this document does not affect those types. So, why does this document need to talk about the Auth Type specific formats? Why not just say there needs to be an Opt Mode field in the header of the new Auth Types that support this framework and leave the Auth specific format definition to those Auth Types (i.e., in the sequence numbers draft)? 302 The values of the Optimized Authentication Mode field are: 304 1. When using the strong authentication type for optimized BFD Auth 305 Types. 307 2. When using the less computationally intensive authentication type 308 for optimized BFD Auth Types. <major> Can the two statements be rephrased for clarity? e.g., the field is set to 1 when the strong type is in use and set to 2 when the light type is in use? <major> Do we foresee any other values such that we need IANA to maintain a registry for this? 375 Once the BFD session has reached the Up state, the BFD Up state MUST 376 be signaled to the remote BFD system using the strong authentication 377 mode for an interval that is at least the Detection Time before 378 switching to the less computationally intensive authentication mode. 379 This is to permit mechanisms such as Meticulous Keyed ISAAC for BFD 380 Authentication [I-D.ietf-bfd-secure-sequence-numbers] to be 381 bootstrapped before switching to the less computationally intensive 382 mode. 384 It is RECOMMENDED that when using optimized authentication that 385 implementations switch from strong authentication to the less 386 computationally intensive authentication mode after an interval that 387 is at least the Detection Time. In the circumstances where a BFD <major> Why is this RECOMMENDED required when the previous paragraph makes this a MUST? Am I missing something? Also importantly, the document does not specific the behavior or the action that needs to be taken if these are not followed by the other side? e.g., should the BFD session be brought down (say as a result of those packets being dropped)? 388 session successfully reaches the Up state with strong authentication, 389 but there are problems with the optimized authentication, this will 390 permit the remote system to tear down the session as quickly as 391 possible. <major> What about the need for using strong mode when doing DOWN notification or any other state change (e.g. AdminDown)? What about when doing any parameter change? What happens if there were to be a parameter change detected when using the light mode? How about mandating that strong mode be used for the Initial period? Please consider beefing up this most important section by moving some of the text from the introduction here and then specifying normatively the behavior for all these scenarios and conditions. 399 It is further RECOMMENDED that BFD implementations using optimized 400 authentication defer notifying their client that the session has 401 reached the Up state until it has transitioned to using the optimized <major> Can this be specified in a more formal manner? I would assume that one needs to wait for a long enough period in the light mode to cover the BFD interval and multiplier values in use? Why not make it a MUST? 406 5. Optimizing Authentication YANG Model 407 5.1. Data Model Overview <question> Is there a precedent to augment standards based YANG models with experimental augments? 515 Authors: Mahesh Jethanandani ([email protected]) 516 Ashesh Mishra ([email protected]) 517 Ankur Saxena ([email protected]) 518 Manav Bhatia ([email protected])."; <minor> Author list here is not aligned with the document 654 6.1. Auth Type 656 This document requests an update to the registry titled "BFD 657 Authentication Types". IANA is requested to assign two new BFD 658 AuthType: 660 * Optimized MD5 Meticulous Keyed ISAAC Authentication 661 [I-D.ietf-bfd-secure-sequence-numbers] (Part 662 meticulous-keyed-isaac-authentication), with a suggested value of 663 7. 665 * Optimized SHA-1 Meticulous Keyed ISAAC Authentication 666 [I-D.ietf-bfd-secure-sequence-numbers] (Part 667 meticulous-keyed-isaac-authentication), with a suggested value of 668 8. <major> I don't understand why this document is doing IANA allocations for something that is specified in the sequence numbers document? 696 7. Security Considerations <major> Please cover the security considerations for the base protocol feature first before getting into the considerations for the YANG model. Better still, carve them into separate sub-sections for clarity. 737 The approach described in this document enhances the ability to <minor> I would not call it enhancement. However, some of the text from the introduction section can be moved here - the one that talks about the vulnerabilities for existing auth types and the need to find a balance for supporting hardware offload, etc. <EoRv24>
