Éric Vyncke has entered the following ballot position for draft-ietf-bfd-secure-sequence-numbers-23: Discuss
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-secure-sequence-numbers/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-bfd-secure-sequence-numbers-23 CC @evyncke Thank you for the work put into this document. I find the idea smart and useful. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Reshad Rahman for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I am puzzled though by `No implementations and no known plans to implement.` ... It also claims that there is no YANG module while there is one. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Update to RFC 5880 As the section 2 contains `this document describes an experimental update to BFD [RFC5880].`, then I think that there is a need for an "Update" tag. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### No implementation plans ? Per shepherd's write-up: `No implementations and no known plans to implement.` ... This is rather sad for a set of 3 I-Ds. ### Use of optimized Like Gorry, I would prefer "lightweight" rather than "optimized" (the latter being a little unclear about which part is optimized). ### Abstract s/This document describes a *new* BFD/This document describes a BFD/ ### Section 1 Even if obvious, s/it is possible for an attacker/it is possible for an *on-path* attacker/ ### Section 1.1 BIG thank you for the explanation about "meticulous" :-) ### Sectin 2 Please consider rewriting `existing document` as this I-D will be a RFC once published and this sentence will flip sense. ### Section 3 The SEC ADs will have a better view of course, but why `Auth Keys` as they are more suitable terms such as "nonces" or "cookies" (like TCP cookies)? ### Section 3.1 Who is the "we" in `so we explain why ISAAC was chosen` ? The authors ? The WG ? The IETF community ? Please rephrase to avoid using "we". Possible typo in `the internal state un an irreversible fashion` s/secret key/shared key/ ? The page size of 256 sequence number is not really justified, I would naively have expected a much larger "page". Rate of 100's of pps is rather low level. ### Section 4 Unsure how to address my comment, but I had to read twice the subsection to understand the role of "opt mode". A leading text would make the reading task easier. Also, why using a full octet for just 1 bit of information? ### Section 4.3 The figure 3 should be clearer that the "auth key" is 20 octets long. Also, the text is about "Auth Key/Digest" and not about "Hash" ### Section 6 It is unclear whether the procedure applies to all BFD packets or only to the non-Up ones.
