On Jan 21, 2024, at 10:43 AM, Jeffrey Haas <[email protected]> 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.
