Re: Resolving lingering issues with BFD authentication drafts

[Jeffrey Haas <[e-mail]>]

Reshad,


> On Feb 25, 2024, at 5:31 PM, Reshad Rahman <[e-mail]> wrote:
> 
> Jeff, overall this looks to be a good way forward, it addresses the main concern I had expressed. 

Excellent.

> On Friday, February 23, 2024, 04:32:55 PM EST, Jeffrey Haas <[e-mail]> wrote:
> - The optimization procedures currently can have BFD go Up with the initial
>   stronger authentication, then go down once the optimized mode kicks in.
> 
> <RR> That's the scenario where only 1 end supports optimized procedures?

In the current version of the document, yes.  That's an item the suggested changes are intended to address.

> Possible ways to address these:
> 
> For BFD optimization:
> [...]

> - Optimized authentication should kick in ASAP when we are in the Up state.
>   I believe this means that we send out at least Detect Mult packets in the
>   strong mechanism and then switch to the optimized mechanism.  This bounds
>   the amount of time when we're not running in optimized mode.
> 
> <RR> Why does optimized procedures need to kick in asap? Is this in case there's an issue with the optimized procedures?

The general concern is not overly delaying the client's idea of when BFD transitions to Up.

The suggested changes take us from Up to an internal "pending" state waiting for the optimized mode to kick in.  We can theoretically linger there however long we like since we've signaled that this change is coming, but it's not helpful to the client to linger there longer than necessary.

The suggestion above is really the lowest bound on time we can take for such a transition to ensure we can safely transition to ISAAC mode and entrain the sequence numbers for the ISAAC algorithm.

> 
> - BFD clients that are expecting optimized authentication SHOULD NOT convey
> <RR> BFD sessions (not clients)?

Session on a client. :-)

>   to their clients that the session is in the Up state until we've
>   successfully switched over to the optimized mechanism.  While this seems
>   contrary to BFD behavior, it's no different than any of the existing
>   "holddown" procedures clients like BGP can implement to ensure that BFD is
>   stable for long enough before using the session.
> <RR> Is this in case there's an issue with the optimized procedures?
> If yes, do we also need some text for the case where optimized procedures fail? e.g., at a certain point we have to stick to strong auth but do we retry eventually (that could cause the session to go down if we do)?

From the client's session perspective, BFD simply is Up/Down as normal.

From the protocol perspective, lingering forever waiting for the optimized mode kicking in isn't what we'd want.  So, yes, we need some form of default timeout recommended for implementors.

If we repeatedly bounce the BFD session from Up to Down only at the transition to the optimized mode, we likely want to dampen that behavior. At least with the new code points we have a sense that this transition to the optimized mode is the actual problem between devices that have agreed to use that authentication type.  

> 
> Thoughts?
> <RR> When transitioning from strong auth to optimized procedures, could we send both types of packets when attempting the transition? The aim being to avoid the BFD session from going down. I haven't thought this through so this may well not hold water.

For the ISAAC procedures, the only requirement is that we believe the other side of the session has seen at least one Up packet out of the expected Detect Mult packets.  That's sufficient for the entraining procedure.

Once we have entrained the ISAAC session, we should be able to flip in and out of the optimized mode at will.

The idea I think you're trying to convey is similar to how other protocols handle a graceful rollover for key.  That's normally done by having the rollover timeframe being willing to authenticate with both old and new key, not having the side generating the packets sending it twice.

For BFD in particular, sending the same PDU with different auth types would probably play havoc with the meticulously increasing sequence number requirements.  Further, there's no mechanism we have to convey that we've successfully processed the rollover.

-- Jeff