On Jan 16, 2024, at 11:28 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > We're in agreement.
<whew> > There is one additional corner case to deal with. Here's the scenario: ... lost packets ... > Option 2: > Each side changing to ISAAC authentication knows that lost packets could be a > problem. The draft says the window we need to keep around is 3*Detect Mult > as part of our receive procedures. Ergo, as long as the side transitioning > into ISAAC does so only at a sequence number such that it is within the > 3*Detect Mult window, it's reasonable to expect that at least ONE of the > packets is expected to get through to the remote side. Yes. The nice thing is we know how many packets we lost. So if we have: bfd.AuthSeqKnown = 1, which means: bfd.RcvAuthSeq is also known And then when we receive a packet which suddenly contains ISAAC, we have a "packet.AuthSeq" which is the sequence number in the received packet. The difference between packet.AuthSeq and bfd.RcvAuthSeq is the number of "lost" packets. We can then generate the first ISAAC page, and then simply run through the generated keys 0..255, finding one which matches. Once we've found a matching key, we know it's index. And we know the sequence number of the packet which was lost. That sequence number becomes bfd.MetKeyIsaacPageBase, and everything proceeds as if there were no packets lost. > Side observation1: I no longer remember why RFC 5880 chose the 3* multiplier. > > Side observation 2: The Detect Mult itself can go up to 255. This > pathologically means the session may stay up under hefty packet loss and the > best we can do is do the switch starting at index 0 of a new page and hope > that we sync up. I think it's best to point this out, and demand that for ISAAC, the number of lost packets must always be less than 256. > Another point likely in need of text in the draft is what ISAAC needs to have > done when switching from ISAAC back to strong authentication. Since the > sequence numbers are kept going regardless of the authentication mechanism, > ISAAC will need to produce new pages when it flips to strong authentication. > This is to avoid needing to "fast forward" if strong authentication is left > going for a while. Hmm... yes. I would suggest also that the use of strong authentication should only be for: 1) state transitions, in which case we toss all existing ISAAC information. We can generate a new ISAAC seed when the state transitions from down->up again 2) we want to send an "up" packet with stronger authentication. In that case, there are few reasons to send many packets. Just send one, and swap back to ISAAC. I'm working on updated text, and hope to have a PR out later today. Alan DeKok.
