Jeff, overall this looks to be a good way forward, it addresses the main
concern I had expressed.
BFD WG, please take a look at the procedures outlined below and provide
feedback.
Comments/questions inline.
On Friday, February 23, 2024, 04:32:55 PM EST, Jeffrey Haas
<jh...@pfrc.org> wrote:
Here's an attempt to provide a path to resolve the lingering issues in the
authentication drafts.
Core lingering issues:
- The NULL auth method is attackable, but still potentially useful for the
stability procedures.
- 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?
Right now, the text doesn't place any bounds on how long it might be until
the optimized procedures are initiated once the session moves to Up.
The issue here is less about bouncing the BFD session, but the impact on
BFD clients.
Possible ways to address these:
For BFD optimization:
- We remove no-authentication and NULL-authentication as methods for the
optimized session. This leaves us solely with one defined method that
both provides good enough security. It also leaves us room to add other
authentications in the future that have similar properties.
- 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?
- BFD clients that are expecting optimized authentication SHOULD NOT convey<RR>
BFD sessions (not clients)?
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)?
This is also not the length of time such features want. BGP BFD holddown
is in the multiples of seconds time frame. I believe we want something
that is within two Detection Intervals once the session is Up.
+ It should be noted we already require sending out this number of Up
packets in the strong mode for entraining ISAAC. However, I'm not sure if
our procedures are clear on that point. To be audited.
- How does a client tell that "we are expecting optimized authentication"?
We define parallel authentication code points for the procedure. Today,
our strong meticulous features are currently meticulous md5 and sha1; code
points 5 and 3, respectively.
We allocate two new code points, "ISAAC-optimized meticulous sha-1" and
"ISAAC-optimized meticulous md5". When these code points are used, the
expectation is the strong cipher is used to get the session to the Up
state, and the session expects to transition to ISAAC afterwards. Thus,
we no longer have the opportunity for an implementation that doesn't
support optimization to have the session half transition to up using the
strong mode and fail once the switch attempts to a mode it doesn't
understand.<RR> I like it!
- We might want to consider having the shared secret used for both strong
and optimized mode. While we've had discussion that we might not want to
do this, having a common shared secret means that misconfiguration stops
being the operational consideration that drives the most likely reasons
for failure of the transition to optimized authentication.
+ This can be a SHOULD for the above reasons.
+ If the operator does not want to use the same shared secret, that's
still fine. It just means they're accepting the potential additional
fragility.
- The NULL auth mechanism is moved out of the optimized draft into the
stability draft.
For BFD stability:
- The NULL auth method is pulled into this document.
- The NULL auth's procedures are slightly updated such that the sequence
number SHOULD NOT be used for authentication. Effectively, it transitions
to a counter. This avoids the ability to use it for attacking the
protocol as noted in prior discussion.
- The NULL auth security properties are no worse at that point than no
authentication.
- Existing meticulous methods can be used as well - no change.
- ISAAC can be used when optimized mode is in use. No change.
+ ISAAC mode cannot be used alone. Its procedures for entraining the
sequence numbers currently mean it can't be the only authentication.
Lingering cleanup:
- The IANA considerations and the YANG definitions need to be readjusted
based on where we move things.
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.
Regards,Reshad.
-- Jeff
-
