Hi Jeff,
> On Jan 24, 2024, at 12:19 PM, Jeffrey Haas <jh...@pfrc.org> wrote:
>
> 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 <mjethanand...@gmail.com
>> <mailto:mjethanand...@gmail.com>> wrote:
>>
>>> On Jan 23, 2024, at 10:30 AM, Jeffrey Haas <jh...@pfrc.org
>>> <mailto:jh...@pfrc.org>> 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).
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).
>
> 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.
>
> 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.
>
> 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
>
>
>>
>>>
>>> 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".
But stability can be detected even when A bit is not set. Do we need to
configure NULL auth to detect loss of packets?
>
>> - 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.
Ok. The ’strong-auth’ in the above tree diagram can be used to specify the auth.
>
> 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.
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.
>
> 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.
Agree. The model suggests that the ’strong-auth’ should be one of the
meticulous auth types.
Thanks.
>
> 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
>
Mahesh Jethanandani
mjethanand...@gmail.com
