Deb, thanks for your review. Note that I'll be letting the other authors comment on the majority of the security claims about ISAAC. Here's a few comments on the procedural usage of the mechanism with BFD.
> On Sep 17, 2025, at 8:59 AM, Deb Cooley via Datatracker <[email protected]> > wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Discuss: A discuss is merely the start of a conversation. The terseness of > this review reflects on my history (37 years as a security evaluator). I > believe it is possible to get this draft to publication, but it will take real > work (I'm happy to help). This is a list of the areas that I believe are > poorly > specified: > > 1. operating situation: Fast networks speeds combined with inadequate > CPU capability will drive the solution which is practical. Please > explain this. Note that this completely overlaps with the similar discuss on the optimizing bfd draft. We'll want to choose a single set of text for both sets of documents. > 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. Partially discussed in the other document, but pre-shared secrets are the common practice for the majority of IETF routing protocols. I'd suggest we find text that makes you and the other security reviewers satisfied that's what we're saying is done. Anything beyond that is overreach. Discussion of the BFD security properties for the protocol's discriminators is covered in RFC 5880's security considerations. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > 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). You're correct that in respect to the ISAAC portion of the mechanism that it's used for the index operation into the generated ISAAC output for validation. From section 6: "The receiving system accepts the packet if the key ID matches one of the configured Keys, and the Auth Key derived from the selected Key, Seed, and Sequence Number matches the Auth Key carried in the packet, and the sequence number is strictly greater than the last sequence number received (modulo wrap at 2^32)." also: "If bfd.AuthSeqKnown is 1, examine the Sequence Number field. For Meticulous keyed ISAAC, if the sequence number lies outside of the range of bfd.RcvAuthSeq+1 to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when treated as an unsigned 32-bit circular number space) the received packet MUST be discarded." The first citation is a requirement for the sequence number to be monotonically increasing when accepted. The second citation provides for a limited window under which a packet could be accepted. It requires the implementation to only accept at least the next sequence number (with the expectation that sequence numbers are meticulously increasing by one on each packet sent) and tolerates packet loss within a window under which the protocol will stay in the Up state and not take the session down due to packet loss. Together, this means replays of prior valid packets are not considered valid Up packets for purposes of keeping the session in the Up state when it might otherwise be in a different state. This is in contrast with non-meticulous modes in RFC 5880 wherein duplicate sequence numbers are permitted to keep the session in the Up state. > Section 4.2 and 4.3: These sections are merely repeats of sections in > draft-ietf-bfd-optimizing-authentication? (Deep breath. Of course this was going to come up.) Not quite. While it's correct that the draft-ietf-bfd-optimizing-authentication-33 §7 Figure 1 is present, the differentiator for each section is the contents of the Auth Key/Digest field. If one were to observe "this seems highly redundant, just say that you're putting that data in this portion of the common header"... that's what we had. And were strongly encouraged to make it crystal clear what goes in the entire authentication section and not just the one field of the common header. It also gives us a spot to absolutely clearly indicate the required auth len for this type. > 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)? This draft extends RFC 5880 and they are defined there. > 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? > > Section 11.2, para 2: The discussion of multiple keys needs to be defined to > be out of scope too (again?). RFC 5880 §6.7.1. mostly talks about not regularly changing authentication modes. It's possible that the best answer for these paragraphs is to simply delete them. > > 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. Or perhaps simply drop the "thousands of packets". A general approximate bound on the number of packets exchanged, including jittering of the timers, across a given interval for a stable set of BFD timers could be calculated... and isn't really helpful here. > 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. While I find your cryptographic heart to be in the right place relating the desire for PBKDF to be part of the process, this is not a common practice for routing protocols including existing RFC 5880 mechanisms. Requiring one would be overreach, IMO. Certainly commenting on best password practices with regard to entropy is appropriate. I suspect Alan will partially respond to this as part of the update that ISAAC+ added to the original ISAAC mechanism. > > Section 15.1, last paragraph: [...] > 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. Note to all concerned: The following is pasted as an example and without negative connotations about the vendor in question. https://knowledge.broadcom.com/external/article/72584/aes-256bit-encryption-and-cpu-in-top-sec.html The conversation point becomes whether the mechanism has, or does not have, hardware support between the two systems and what the amortized cost of generating N outputs is within a constrained time window to keep the protocol running at speed. Seeing such a comparison would be interesting. This is also a recognition that these things have cost and that cost can be disruptive to the other useful work network elements need to do. > > 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. As we previously discussed, the attacks are: 1. The attacker is trying to keep the BFD session up when it should otherwise go down. Doing this requires access to the key, the ability to do MITM, suppress the remote system's ability to send packets. Further, to generate the necessary packets, it'd require the outputs from ISAAC for the relevant page in the sequence number space. The algorithm requires iterating the pages as many times as is necessary to catch up from initial starting condition to the current page. This requires more work the longer the session has been up. 2. The attacker wants to knock the session over (move to Down). In the protocol, this would require spoofing a packet with the stronger authentication method. Alternatively, if the attacker was MITM, there are significant other methods that could be leveraged: Spoof ARP/NDP to cause packet loss. Volumetric DoS vs. the network element. Etc. Cleaning this text up is probably appropriate. > 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. Yes, this is the current recommendation. Failure to leverage the same key increases operational likelihood that the BFD session may be able to reach the Up state with Key1, and then fail when it tries to transition to optimized mode with an improperly provisioned Key2. The concern here is that if you could derive the shared secret from the less strong mechanism that you could spoof packets for the strong one. This is a valid concern. However, given that the authentication mechanisms for the stronger mode and the less strong mode are different, this would seem to imply to me that it would require deriving the actual shared secret rather than a collision on that shared secret. That said, I don't pretend to be a cryptographer and know how hard that is likely to be. -- Jeff
