> On Jan 25, 2024, at 6:39 PM, Mahesh Jethanandani <[email protected]>
> wrote:
>
>> On Jan 24, 2024, at 12:19 PM, Jeffrey Haas <[email protected]
>> <mailto:[email protected]>> 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
