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

[Jeffrey Haas <[e-mail]>]

> On Jan 25, 2024, at 6:39 PM, Mahesh Jethanandani <[e-mail]> wrote:
> 
>> On Jan 24, 2024, at 12:19 PM, Jeffrey Haas <[e-mail] <mailto:[e-mail]>> wrote:
> Ok. I have added a couple of leafs. One is called ‘up-auth-type’ which is of type iana-bfd-types:auth-type that can be used to indicate what auth-type should be used once the session reaches UP state. It should be one of NULL Auth type or Meticulous ISAAC. The second is a strong-auth leaf which is also of type iana-bfd-types:auth-type which specifies one of the strong authentication mechanisms (not including simple password).

I've started annotating the repository with comments to help converge there.

The thing I think is missing in the most recent round is that the up-auth flavor of things is really a keychain entry of its own, or something similar.  As per the Meticulous Keyed ISAAC proposal, there may be distinct authentication parameters, like a secret, vs. the one used for strong.

> 
>> 
>> If you use NULL auth for the optimization procedures, you require no additional authentication parameters.  
> 
> Not quite. We still have the 'strong-auth-interval’ that specifies how often we need to perform a strong authentication when NULL Auth is used, something we discussed below.

Agreed. I had meant the secret.

>> If you use Meticulous Keyed ISAAC, you require a key-id and a shared secret, same as you do for SHA-1, MD5, etc.
> 
> True, but in the base BFD YANG model we point to the key-chain for it, which is what ISAAC will have to use.

See above; the secret may be different.

As I flagged in the review, I'll check the keychain semantics in more detail tomorrow.


> 
>> 
>> Thus what is needed for the optimization case is "do optimization, here's my second mechanism and its configuration".
> 
> Ok. The tree diagram currently looks like this:
> 
>     augment /rt:routing/rt:control-plane-protocols
>             /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
>             /bfd-ip-sh:sessions/bfd-ip-sh:session
>             /bfd-ip-sh:authentication:
>     +--rw optimized-auth?         boolean {optimized-auth}?
>     +--rw up-auth-type?           iana-bfd-types:auth-type
>     +--rw strong-auth?            iana-bfd-types:auth-type
>     +--rw strong-auth-interval?   uint32
> 

I'll also note that the existing YANG module includes a leaf for meticulous mode which can help with the bfd-stability work.

> 
> But stability can be detected even when A bit is not set. Do we need to configure NULL auth to detect loss of packets?

It cannot be detected without the a-bit.  As I noted in the review, "NULL" auth is not "a-bit zero", it's a specific authentication type that includes the sequence number.

Raw RFC 5880 BFD without authentication DOES NOT contain any sequence numbers.  That's why we need the NULL auth.

I'm starting to wonder if we need a rename of "NULL" to something else because as someone clued on BFD you're wanting it to mean "no authenticaton". You wouldn't be the only one.

> 
> If Meticulous Keyed ISAAC is used as the second bit of authentication when optimization is configured, then we do not need the ’secure-sequence-number’ flag. 

Exactly.  And, as Alan keeps helping to point out, we really don't have a "secure sequence number" feature any more.  It evolved into a full authentication type.

-- Jeff