Re: Resolving lingering issues with BFD authentication drafts

[Reshad Rahman <[e-mail]>]

 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 <[e-mail]> 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


-