> On Jan 21, 2024, at 8:23 PM, Alan DeKok <al...@deployingradius.com> wrote: > > (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.
I've sent out a correction on this detail to the bfd mail list. But fundamentally, it's not a requirement that we restate the procedures, just nod they they're already covered. > >>> 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. I think the relevant bit of RFC 5880 is: https://datatracker.ietf.org/doc/html/rfc5880#autoid-31 <https://datatracker.ietf.org/doc/html/rfc5880#autoid-31> If the A bit is set, the packet MUST be authenticated under the rules of section 6.7 <https://datatracker.ietf.org/doc/html/rfc5880#section-6.7>, based on the authentication type in use (bfd.AuthType). This may cause the packet to be discarded. Basically, if you have authentication configured, and you're expecting it to be used, someone doesn't blindly get to send you something else and knock your session over. Thus it's feasible for ISAAC mode to cause parameters changes, even if that's not necessarily what we want. Clarifying that we don't want that is in the purview of the optimizing draft basically saying "since the methods used for altering BFD session parameters might not be authenticated, stronger authentication MUST be used" and then otherwise refer back to the motivations for the draft. > > 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". I think this is mostly making sure the optimizing authentication authors review their procedural text vs. these details and then we make sure the ISAAC document is in harmony with it. > > 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. Note that the text we had last reviewed on your branch had reached broader consensus. I'd suggest that text get merged and these details be worked out separately. -- Jeff > > Alan DeKok.
