Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Alan DeKok <[e-mail]>]

On Jan 19, 2024, at 7:14 PM, Mahesh Jethanandani <[e-mail]> 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.