Alan,
> On Jan 16, 2024, at 6:47 PM, Alan DeKok <[email protected]> wrote: > > On Jan 16, 2024, at 12:00 PM, Jeffrey Haas <[email protected]> wrote: >> This means the two scenarios we have during the first transition to ISAAC in >> the face of packet loss are: >> 1. It's on "this" page. >> 2. It's on the prior page. > > The simple solution to page issues is to just require that there be no more > than 255 lost packets allowed. That way the current packet is always in the > first page of derived ISAAC values. I've reviewed the relevant text for the "search" and think it's correct. A possible tweak: <t>If a calculated key at index "I" does match the Auth Key in the packet, then the bfd.MetKeyIsaacRcvAuthIndex field is initialized to this value. THe bfd.MetKeyIsaacRcvAuthBase field is then initialized to contain the value of bfd.RcvAuthSeq, minus the value of bfd.MetKeyIsaacRcvAuthIndex. This process allows the pseudo-random stream to be re-synchronized in the event of lost packets.</t> 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. > > 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. A thought about the receiving mode: <t>Note that in some cases, calculating the expected output of ISAAC will result in the creation of a new "page" of 256 numbers. This process will irreversible, and will destroy the current "page". As a result, if the generation of a new output will create a new "page", the receiving party MUST save a copy of the entire ISAAC state before proceeding with this calculation. If the outputs match, then the saved copy can be discarded, and the new ISAAC state is used. If the outputs do not match, then the saved copy MUST be restored, and the modified copy discarded, or cached for later use.</t> 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". 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. <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. > > The reworked text doesn't address all of your review, but it does go into > great detail into how to initialize and operate meticulous keyed ISAAC. If > defines a large number of variables specific to this Auth Type method. That > may seem surprising, but I think that the resulting text was made clearer. > > The document still needs updates to address the other comments in your > review, but it's late here, and the bulk of the work seems to be done. I'll > do more tomorrow, in order to get this off of my plate. This is very close to done. Thanks for helping drive this to conclusion. -- Jeff
