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

[Mahesh Jethanandani <[e-mail]>]

[Adding Manav back in the thread]

Hi Alan,

Even if I were to agree that securing the sequence number using ISAAC is another form of authentication, “optimized auth” is based on the premise that only an occasional authentication check is required when the BFD session is in UP state. Once the session is in UP state, most of the time the BFD session can do fine without any form of authentication. I want to keep the discussion of what goes into the sequence number field separate from whether we use authentication all the time or not.

Can we move the discussion below to the “secure-sequence-numbers” thread?

Thanks.

> On Jan 21, 2024, at 8:58 AM, Alan DeKok <[e-mail]> wrote:
> 
> 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.
> 
> 
> 


Mahesh Jethanandani
[e-mail]