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

[Jeffrey Haas <[e-mail]>]

Mahesh,


> On Jan 23, 2024, at 1:18 PM, Mahesh Jethanandani <[e-mail]> wrote:
> 
> I am proposing two config variables that I think that are pertinent to optimized configuration, and I can put a small YANG model that augments BFD YANG model to demonstrates it. They are:
> 
> - optimized-auth flag: A boolean flag, when set to true, the implementation would like to make use of optimized auth for the session in question.

We have two authentications proposed for optimization: NULL and Meticulous Keyed ISAAC.  Were you expecting another leaf and the relevant keychain parameters for these to be defined elsewhere and tied in?

Further, for the bfd-stability feature, we need to have the ability to pick the meticulous authentication that will be used potentially in addition to non-meticulous authentication that might be stronger. 

I think this is pushing us toward having a secondary bit of authentication configured for the session and a selector for the mode of why it's needed: optimized vs. stability.

Working through both use cases will likely drive the outcome.



> - strong-auth-interval: A uint32 value that takes a microsecond value for the interval after which the session MUST try a strong authentication mechanism to prevent a MITM attack. The default value is default value of required-min-rx-interval as defined in the BFD YANG model, times the local-multiplier with a default value of 3 for a total of 3000000.

The danger of saying "pick a reasonable value" is the back and forth of what should be reasonable.  3s is certainly better than doing expensive authentication every 30ms.  Would every 30s?  Every 5m? 

I would recommend something probably in the minute time frame. 

I would also suggest we want text that says "this value will have jitter applied to it to avoid self-synchronization of expensive authentication operations".  Basically, if you presume a system that is doing the expensive thing every N seconds, we don't want it trying to do that expensive thing for every single session all at the same time.

> 
> Both these variables can be protected with a feature statement that implementations will enable if they want to support optimized authentication.

Perfect.

> 
> Is that what you were looking for?

This is the right direction!

-- Jeff