[Responding to original head of thread] The following pull request has been queued for coauthor review to address the majority of these points with a notable exception.
https://github.com/mjethanandani/bfd-secure-sequence-numbers/pull/53 Hopefully after their review we'll be able to push updates for the optimizing and isaac drafts to the datatracker to move IESG review to the next step. > On Sep 17, 2025, at 8:59 AM, Deb Cooley via Datatracker <[email protected]> > wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > 1. operating situation: Fast networks speeds combined with inadequate > CPU capability will drive the solution which is practical. Please > explain this. The optimizing BFD draft has been updated to discuss the general operational considerations for what we're trying to accomplish. This isaac (secure-sequence-numbers) document defers to that document for the general scenario. This will hopefully provide a level of future-proofing vs. the "why are you doing this" for any less computationally intensive authentication mechanism for BFD using the optimized BFD procedures. > 2. Use of previously unheard of 30 year old algorithms: In this > particular case, because the security requirements are rudimentary at > best, this is ok. But the draft needs to reduce the language leading > the reader to overestimate the strength or assurance provided by this > algorithm. The PR attempts to remove the broad claims. > 3. key management: There is very little information in this draft > that outlines how various keys (per party Secret keys, per session > seeds, initial sequence numbers) are handled. This includes > generation, distribution, storage, and removal. While there are many > references to a 'cryptographically strong pseudo-number generator', it > is never defined. The test data in Section 10 apparently encourages > operators to use a password as a Secret Key without any further > processing (no pbkdf required, apparently). There is no mention in the > Security Considerations to caution the implementer on what care needs > to be taken with respect to these values, and their handling. Hopefully in better shape in the PR. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Section 1: Please mention earlier in the specification that this technique > can > only be used in conjunction with draft-ietf-bfd-optimizing-authentication. As > it stands, there is no use for this specification without that specification. Addressed. > > Section 1: Please add a little bit more explanation to remind the reader why > these normally fast hashes are too slow/hard. Please address both speed of > the > transmission and capability of the device performing the hashes. Deferred to the updated text in optimizing BFD. > Section 1, Paragraph 3 and many other places: significant cryptanalysis/some > cryptanalysis (2 documented efforts over 30 years is hardly 'significant'). > I'm not sure who the authors are trying to convince. Addressed. > > Section 2: Please define CSPRNG (I don't care where). This draft currently > makes the assumption that everyone knows what a CSPRNG is. [Note: even though > RFC 4086 is a decade younger than ISAAC, it is not considered to be > up-to-date] The acronym was expanded. Was there a further need for a reference? > > Section 4.1, sequence number and Section 6, para 1: It is unclear to me how > an > unprotected sequence number prevents a replay attack. Certainly the attacker > can change the sequence number, or replay a packet with a modified sequence > number. The only protection against replay attacks for this system is via the > Auth Key. The sequence number is merely helpful for the recipient to attempt > to determine the place on the table (and that only works if the packet hasn't > been replayed). Previously addressed. > > Section 4.2 and 4.3: These sections are merely repeats of sections in > draft-ietf-bfd-optimizing-authentication? Previously addressed. > > Section 6, 'The Auth key field: Where the sequence number is merely an index > into the table of 256 values, no? The sequence number is not part of the > seeding of ISAAC. Correct. > > Section 7: Some of the state variables defined here have been used earlier in > the specification. Consider moving this section up to a place before the > variables are used. Moved up in the PR. > > Section 8, para 2: Multiple Secret Keys: If this specification doesn't want > to explain how they are used, then one should say they are 'out of scope'. > Please put the 'MUST NOT' sentence second in the paragraph (and remove the > 'however'. This puts the requirement where it will be more easily seen (i.e. > don't bury the lead). Hopefully addressed in the PR. Primarily this section addresses two things: The fact that multiple keys can be provisioned and that there is a selector for which key is to be used. Also, some clearer text noting that we are unable to switch keys without resetting the state machine. > > Section 8, para 3: This could easily be put in Security Considerations. Addressed. > > Section 8: How are the per party secret keys generated, distributed, > protected? If that is in scope, please describe. If it is out of scope, > please add appropriate guidance to Security Considerations. Please check vs. the latest text and see prior discussion. > > Section 9, para 8,9,&10: Starting a paragraph with 'However' isn't clear. > Remove the 'However', add the word 'state' to variables, and combine the > paragraphs/sentences. Remove the last paragraph, or move it into Section 10. Addressed. > > Section 10, para 1: This is the very first mention of 'Your Discriminator' > field. No where in the previous sections is this field discussed, defined. > In > addition My Discriminator and Your Discriminator changes depending on > perspective. Does the sending and receiving systems use the same field > (presumably with different values)? The fields were noted earlier and are core BFD protocol fields. I'd added a reference in the first occurrence for Your Discriminator to the appropriate section of RFC 5880. > > Section 10: In addition to ISAAC, a system is required to have a second > CSPRNG > to generate session seeds? "Insert random number here, your choice of how it's random." > Section 11.2, para 1: This paragraph is not about multiple keys, but about > key > distribution. Please rename this to 'Secret Key Distribution' (if indeed this > section is about Secret Keys). What keys are being discussed here? The > Secret > Key? Are you saying that distribution of the Secret Key (aka password) is out > of scope? Not quite about secret key distribution. See updated text. > > Section 11.2, para 2: The discussion of multiple keys needs to be defined to > be out of scope too (again?). > > Section 12: I thought that draft-ietf-optimizing-authentication required that > 'strong' authentication was used periodically, see Section 5. 'Thousands of > packets' doesn't seem to be what was being proposed in that draft. Please > make > these estimation of number of packets (currently thousands and hundreds) more > realistic. Removed the thousands comment and made sure document refers to the optimized reauthentication procedures in appropriate sections. > > Section 15: Please add a section about CSPRNGs. Describe the requirements > for > strength and assurance. There are multiple mentions of CSPRNG for all the > various fields used in BFD (Session Seeds, Secret Keys, Sequence Numbers). > What are the consequences of using a sub par PRNG? What are the mitigations? No text has been added - perhaps Alan has something in mind. That said, this seems like a generic issue for IETF standard documents. Is there not a general bit of recommendation about such things already? If not, you're surely not asking BFD authors to create that? > > Section 15: If the Secret Key is basically a password (see Section 10 test > vectors) please explain how that generation should be accomplished. Also > please explain why a PBKDF isn't used to distribute what little entropy is in > that password. Or alternatively, explain how a PBKDF could be used. Note: > since this is virtually the only value not transmitted across the network in > the clear, it is the only unknown value to the attacker on the network. Previously discussed. > > Section 15.1, last paragraph: Please tone down the 'analyzed for almost 3 > decades' language. I'm also curious about the perceived ineffectiveness of > AES > (which is commonly a standard cell in most CPUs). The choice of AES in a > stream cipher mode might have been just as quick, and certainly has almost 3 > decades of real analysis. Addressed by removing some of the feel of a broad claim. I've also tweaked the language relating to the AES example based on our casual experiments. > > Section 15.1.1, last paragraph: More accurately, this technique prevents the > attacker from spoofing UP packets. It absolutely does not do anything to > protect availability, injection of spoofed packets can take down a link (the > definition of availability, right?). If there is an ability to modify/block > packets will destroy the link in very little time. Please correct. I've addressed this. > > Section 15.1.2: Are you recommending that the keys used for keyed MD5, keyed > SHA1, and ISAAC be the same (aka the Secret Key)? Please change this. Any > leak of any one of these keys (the ISAAC version is specified to be a > password) > would result in the attacker being able to construct any BFD packet, for any > purpose. In the current text, there is discussion about what happens if you do or do not leverage the same key for the more/less computationally intensive mechanism. As we previously discussed, and noted in the document, there is a warning that is an operational consideration about issues with maintaining two keys and what happens if the less computationally intensive key isn't consistently provisioned. The document permits implementations to use two keys if it desires to do so. There is no consideration in the current YANG modules for such a secondary key. The optimizing BFD document would be the place such a thing would go. -- Jeff
