On Jan 17, 2024, at 9:40 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > Effectively, bfd.MetKeyIsaacRcvAuthBase is the sequence number at which ISAAC > was first found valid. This may be a lost packet. Working this into the text > may help clarify this scenario for implementors.
Yes. I'll add some text. >> >> For now, I've largely reworked the text. The new text is at: >> https://github.com/mjethanandani/bfd-secure-sequence-numbers/tree/v14-alan > > Thanks. These comments are against the current snapshot at that repository. > Note that the repository doesn't currently compile so I'm reviewing this via > the .xml. My current system doesn't build any XML files, so I'm just hacking the text for content. > Similar to our prior discussion about determining the first sequence number > of synchronizing ISAAC page 0, we can observe that we should only generate > the next page of the ISAAC table if the received sequence number is in the > expected range for an Up session. > > This means that on an attack where the attacker is generating a sequence > number greater than the actual sequence number, we generate at most the next > table, which will eventually be valid for an Up session. Those invalid > packets will not validate, but can at most cause us to do the work "early". Yes. The implementation in the repository does exactly this. > The related requirement would be that we have the "current" page associated > with the most recently valid sequence number, and one possible pending "next" > page. The nice thing is that the "next" page can be calculated asynchronously. i.e. outside of the "fast path" for BFD. If the normal BFD process uses 60 packets per second, we have about 4 seconds to calculate the "next" page. > <t>bfd.MetKeyIsaacRcvKeyKnown</t> > <li>A boolean value which indicates whether or not the system > knows the receive key for the Meticulous Keyed ISAAC Auth Type > method. The initial value is "false". This value is changed > to "true" when a party sees that the other party has started > to use the Meticulous Keyed ISAAC Auth Type method.</li> > > I think this changes to true the first time we see an _acceptable_ ISAAC > authenticated PDU. I.e. we're not permitting the local state to be set and > spoiled by invalid inputs. Yes. I'll update. Alan DeKok.
