Jeff,
The only thing I am still a bit hesitant about is delaying the notification to
the BFD clients (that the session is up) until we've successfully moved to the
optimized mode. It's not the actual delay, which should be short, but the fact
that it's changing the BFD state machine a bit. But I don't see any other way
to do this without the risk of bouncing the BFD session.
Regarding "until we've successfully switched over to the optimized mechanism",
what does a successful switch mean? Does it mean sending detect mult packets
with optimized auth?
Regards,Reshad.
On Sunday, February 25, 2024, 06:53:52 PM EST, Jeffrey Haas
<[email protected]> wrote:
Reshad,
On Feb 25, 2024, at 5:31 PM, Reshad Rahman <[email protected]> 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 <[email protected]>
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
