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

[Alan DeKok <[e-mail]>]

  (removing optimizing authentication)

> On Jan 21, 2024, at 3:37 PM, Jeffrey Haas <[e-mail]> 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.