Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Alan DeKok <[e-mail]>]

On Jan 21, 2024, at 10:43 AM, Jeffrey Haas <[e-mail]> wrote:
> To your final point, ISAAC is reasonably secure for the Up case. However it doesn’t authenticate the packet contents. 

  What fields can be modified which *don't* affect the BFD state machine?  Most of the fields are mandated to have specific values for this particular session and this particular state.

  i.e. We may not need the full packet to be authenticated in order to maintain an "Up" state.

  Perhaps the RX / TX intervals could be modified without detection.  We could update the ISAAC doc to say that these fields need to be cached when ISAAC starts, and can only be changed via an Auth Type which authenticates the full packet content.

  Doing that would address pretty much all of the issues related to not authenticating the packet.  Either a received packet is byte-for-byte identical to what we expect (plus ISAAC key), or it's not, and we drop it.

  So the process is:

BFD packet is exactly what we expect (except for Auth Key)
         |
        +--- no?  drop it
         |
         | yes
         |
  check if the ISAAC Auth Key matches
         |
        +--- no?  drop it
         |
         | yes
         |
   session remains Up.

  I see a fully authenticated packet as being needed for state changes, or perhaps modifying the RX / TX intervals.

  But at a very high level, so long as the receiver sees the correct ISAAC Auth Type, the rest of the BFD packet almost doesn't matter.  No one other than the sender could have calculated the correct Auth Key.  Therefore the sender is still Up.

  Alan DeKok.