Hi Jeff, I have been thinking of keeping the configuration information related to the draft in the draft itself. I know that will mean three small YANG models, but if keeps the discussion in one place rather than referring to another document. If the configuration of one parameters affects the other draft, we will have to revisit my thinking.
With that in mind, ... > On Jan 23, 2024, at 10:30 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > > 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? I see that there is some confusion that still needs to be cleared. I brought it up, but apparently I did not do a good job of it. You mention two authentications proposed for Optimized auth. I think there is only one, i.e. the one that uses NULL Auth. Meaning, in Optimized auth mode, you start with strong auth for state transitions, and once the session is in UP state, transition to NULL auth, with occasional strong auth to prevent MITM attack. The Meticulous Keyed ISAAC in my mind is independent of Optimized auth. It can be enabled by itself, or along with Optimized auth to secure the sequence number. Did you have something else in mind? > > 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. I agree with you on the question of using a meticulous auth mechanism when stability is enabled, and something that you highlight on the other thread. But could it be as simple as some text that says that when stability is enabled, only meticulous auth should be used. I am not sure what you mean when you say “ability to pick the meticulous authentication that will be used …”. The base BFD YANG model does not allow us to specify what bfd.AuthType will be used. Just the key-chain and whether we want meticulous auth or not. Here are some of the possible scenarios that I can think of, what config would apply, and what would be the behavior. - No auth, no secure sequence number, no stability. No new config. Things will work as defined in RFC 5880. - Strong auth, no secure sequence number, no stability. No new config. Things will work as defined in RFC 5880. - Optimized auth, no secure sequence number, no stability. 'optimized-auth' flag is set to true, along with an interval for strong auth. The system decides what strong auth it uses for state change and occasional auth. - No auth, secure sequence number, no stability. A config variable 'secure-sequence-number' is set to true, and the system uses ISAAC. - No auth, no secure sequence number, stability. A config variable of ‘stability' is set to true. System uses the increasing sequence number to detect drops. - Optimized auth, secure sequence number, no stability. 'optimized-auth' and 'secure-sequence-number' are set to true. System picks a strong auth for state transitions and occasional auth, and NULL auth otherwise. In parallel, it uses ISAAC to secure the sequence number. - Optimized auth, no secure sequence number, stability. 'optimized-auth' and ‘stability' is set to true. System picks a strong meticulous auth for state transitions and occasional auth, and NULL auth otherwise. It uses the increasing sequence number to detect drops. - Optimized auth, secure sequence number, stability. 'optimized-auth', 'secure-sequence-number', and ‘stability' is set to true. System picks a strong meticulous auth for state transitions and occasional auth, and NULL auth otherwise. In parallel it uses meticulous ISAAC to secure the sequence number. It uses the increasing sequence number to detect drops. > > > >> - 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. Ok. I will set the default to 1 minute. > > 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. Ok. Will add text to that effect. > >> >> 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 > Mahesh Jethanandani mjethanand...@gmail.com
