> On Jan 21, 2024, at 11:58 AM, Alan DeKok <al...@deployingradius.com> wrote:
>
> On Jan 21, 2024, at 10:43 AM, Jeffrey Haas <jh...@pfrc.org> 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.
That's rather the point. The optimization procedures rely on the fact that
we're requiring strong authentication as part of the ability to switch to
something weaker.
For md5/sha1 procedures, the entirety of the PDU is part of the digest. For
ISAAC, we're saying, "here's the next sequence number". We admit in the
procedures we're not checking the rest of the fields.
A reasonable procedure for an implementation of ISAAC is verifying that the
contents do not vary. For the BFD state machinery, any changes to those fields
is expected to be accomplished through a poll sequence, unless we're going
Down/AdminDown, in which case we're also wanting strong authentication.
>
> i.e. We may not need the full packet to be authenticated in order to
> maintain an "Up" state.
We've agreed to this, and the logic is covered in the optimizing text.
>
> 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.
I'd not pushed for those details to be spelled out because the only legitimate
way an implementation can accomplish this is, as above, through a poll sequence.
That said, since ...
>
> 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.
... is perhaps a late understanding for you as the expert in ISAAC rather than
BFD, we certainly can spell it out in a sentence or two in the secure sequence
numbers document
-- Jeff
