(removing optimizing authentication) > On Jan 21, 2024, at 3:37 PM, Jeffrey Haas <jh...@pfrc.org> wrote: > 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.
Ah, I had forgotten that. I've been working on the ISAAC bits, and was studiously ignoring the rest of the BFD state machine. >> 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 Perhaps not quite too late. I can add some text to the document before another rev is sent out. The text should say that none of the fields in the header normally change. [RFC5880] Section 6.8.3 says: If either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated There's no similar text for "Required Min Echo RX Interval" changes, but that's fine. The ISAAC document also could to be updated to state that a stronger authentication method is used for every Poll Sequence, too. Because that signifies a change of session state (management information), even if the bfd.SessionState variable remains in "Up". For me, that's the main reason to switch to a stronger Auth Type. The ISAAC document can then say that the BFD packets can at least be verified to be unchanged if: * the packet information is cached during an Auth Type which verifies the packet contents * the same packet header (modulo Sequence Number) is seen for all packets using ISAAC I'll try to work up some text tomorrow. Alan DeKok.
