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

[Jeffrey Haas <[e-mail]>]

Mahesh,

I don't think we're too far off from each other's perspective.


> On Jan 23, 2024, at 9:15 PM, Mahesh Jethanandani <[e-mail]> wrote:
> 
>> On Jan 23, 2024, at 10:30 AM, Jeffrey Haas <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 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?

A boolean of "doing optimization" isn't sufficient on its own.

Optimization means you have the original strong auth mechanism to start. E.g. sha-1.
Optimization means you switch to the other auth once you're in the Up state.  We have two use cases we're considering: NULL auth (a new auth method), Meticulous Keyed ISAAC (a new auth method).

If you use NULL auth for the optimization procedures, you require no additional authentication parameters.  

If you use Meticulous Keyed ISAAC, you require a key-id and a shared secret, same as you do for SHA-1, MD5, etc.

Thus what is needed for the optimization case is "do optimization, here's my second mechanism and its configuration".


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

These two are good.

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

The mechanism for the optimized Up state needs configuration.  See above.

> - No auth, secure sequence number, no stability. A config variable 'secure-sequence-number' is set to true, and the system uses ISAAC.

Invalid configuration.  Meticulous Keyed ISAAC is only applicable to packets in the Up state due to the lack of a digest computed over the whole PDU.


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

What this would translate to is "NULL auth is the only authentication mechanism configured". 

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

There's no "system picks", the user has to specify what we start with because the strong auth requires configuration.  E.g. sha-1.

In this example, if "secure sequence number" is set, it means the optimization configuration uses Meticulous Keyed ISAAC as its second bit of authentication for that mode, and it will need its configuration parameters.

In the scenario above, if the primary authentication mechanism is Meticulous, the system can provide stability data.  However, if it uses non-Meticulous MD-5, we can't run the stability procedures until we're in the Up state.

Prior thread discussion is suggesting that simple password and optimizing is invalid configuration.  I believe that would also be the case for NULL as main authentication and optimizing.

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

Again, there's no "system picks" due to need for configuration of the authentication parameters.

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

Agreed.

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

We'll start from there.  I expect everyone to have an opinion. :-)

-- Jeff