Mahesh,
> On Jan 23, 2024, at 1:18 PM, Mahesh Jethanandani <mjethanand...@gmail.com> > 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
