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

[Mahesh Jethanandani <[e-mail]>]

> On Jan 22, 2024, at 2:20 PM, Jeffrey Haas <[e-mail]> wrote:
> 
> Mahesh,
> 
> 
>> On Jan 22, 2024, at 5:15 PM, Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> On Jan 19, 2024, at 4:14 PM, Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
>>> 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.
>> 
>> Want to make sure that this is clear enough (here), and if you think text to that effect should be added to the draft.
> 
> I'm not really looking for text that says the procedure sets specific bfd variables in order to say what is going on the wire.
> 
> However, what's needed is discussing that we're switching from a primary configuration for authentication with "strong" properties to a "weaker" one for the optimization.  We also need to discuss that for certain "weaker" authentications, like NULL, we may need to periodically do the strong authentication to ensure we haven't been MITMed.
> 
> And for that periodic strong auth check, what's the configuration element and what's the recommended time to do it?  For example, a few times an hour?  I suspect we'll pick a value and it'll immediately get hate mail from the security directorate no matter what so my recommendation is to pick something the authors think is reasonable and we'll iterate that conversational point in that thread.

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.
- 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.

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

Is that what you were looking for?


Mahesh Jethanandani
[e-mail]