Alan,
> On Jan 16, 2024, at 11:47 AM, Alan DeKok <al...@deployingradius.com> wrote: > On Jan 16, 2024, at 11:28 AM, Jeffrey Haas <jh...@pfrc.org> wrote: >> 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. Hm. I realize what you're saying here. It might be okay. 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. Based on the total packets lost and the modulus boundary, you can determine whether you even need to try the prior page as well. So, the negative point here is that you may need to do the expensive computation at most twice to get in sync. That said, it's worth providing text suggesting to implementors "this is an issue (here's the fix), try to avoid making the other side do that work by holding off switching until you're able to guarantee the other side should get it." > >> 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. A cautionary note is the best we can do here. That said, deployed Detect Mult values tend to be low, and often simply default to 3. > >> 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. I believe all of this is simply covered under: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13 <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-13> Once we have our ISAAC text, our roadmap is: 1. secure seq# WGLC Depends on: optimizing bfd 2. bfd stability WGLC. Needs republish. Depends on optimizing bfd 3. optimizing BFD WGLC. Needs republish. These two proceed as a bundle to IESG. So, please review the next round of text vs. optimizing bfd. -- Jeff
