Alan, To your final point, ISAAC is reasonably secure for the Up case. However it doesn’t authenticate the packet contents.
Jeff > On Jan 20, 2024, at 19:45, Alan DeKok <al...@deployingradius.com> wrote: > > On Jan 19, 2024, at 7:14 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > wrote: >> In my mind, and my co-authors can correct me if my understanding is >> incorrect, I do not see "optimized auth" as a choice between "NULL-auth" and >> "secure-sequence" numbers. When the A-bit is set, the choice is between >> doing authentication as described in RFC 5880 (bfd.AuthType=[1..5]), or >> doing "optimized auth". If "optimized auth" is chosen, bfd.AuthType can >> toggle from one of the non-zero values to NULL-auth (whatever non-zero value >> is assigned to it) and back. >> >> At the same time, if 'secure-seq-num' is configured as ’true’, the sequence >> number is generated as defined by I-D.ietf-bfd-secure-sequence-numbers, and >> inserted into the packet. The only question I ask is, if “optimized auth” is >> enabled, and when there is a state transition, the packet is “fully” >> authenticated by selecting bfd.AuthType as one of the non-zero values (but >> not NULL-auth). Do we need to generate a secure sequence number at that >> time? Or is it easier/simpler to let it continue generating the secure >> sequence number, and not deal with “lost” packets as the session transitions >> from bfd.AuthType with a non-zero value and NULL-auth. > > We should probably stop calling it "secure sequence numbers". I think that > name doesn't help. > > Instead, the draft migrated towards just being another Auth Type, but one > where the BFD packets are not authenticated. Instead, the sender is verified > to follow a PRNG sequence. The PRNG is seeded using the secret key and > various per-session information. > > So the Auth Types are "full packet authentication" via SHA, MD5, etc or > "verified sender". > > If the packet isn't authenticated but the sender is verified, then we still > can decide that the sender is up. And it matters a lot less what the rest of > the packet contents are. > >>> Interesting edge choice question: Alan's recent changes permits even >>> "simple password" to be a valid mode, but it's probably not something we >>> want to operationally support. In particular, because it does NOT include >>> sequence numbers and thus provides zero protection vs. reply during the >>> non-optimized path. >> >> Agree. Where do we call this out? In this or in the secure-sequence-number >> draft? > > i would lean towards forbidding "simple password", unless it uses a > different password than is used for the stronger authentication methods. > Otherwise it leads to the password being exposed. > > I would also ask if the ISAAC PRNG is reasonably secure, do we really need > to occasionally swap to another Auth Type? > > i.e. what is the reason for switching from ISAAC to SHA1, and then back > again? What are we trying to prove? > > Alan DeKok.
