On Mar 21, 2023, at 5:07 PM, Jeffrey Haas <[email protected]> wrote:
> The "use sequence number taken from previous auth method" is what I had in
> mind.
>
> A concrete example might explain my thinking. Let's start with a mechanism
> that has has sequence numbers, such as md5.
> ...
> If the state we're keeping isn't only the simple boring scalar variable
> that's in the document (bfd.XmitAuthSeq) and is rather the per-session,
> per-type, we can envision maintaining sequence numbers separately for each
> method. That's pretty straight forward.
I agree.
> This makes our state for ISAAC:
>
> For a given session
> - For the meticulous ISAAC auth type
> - For a specific meticulous ISAAC auth key id
> - For a specific seed
> - There's a sequence number (bfd.XmitAuthSeq)
Yes.
>
> However, if we do so, this means that our packet acceptance criteria gains
> complexity. We're expected to verify that our received authseq is within the
> expected range allowing for dropped packets. (RFC 5880, ยง6.7.3) It's still
> easy to envision we keep that acceptable window per auth method. Keeping
> track of those windows and whether we're missing a packet or not based on
> authentication method is doable, but gets messier. This impacts the
> draft-ietf-bfd-stability draft a bit.
>
> None of these things are impossible. It does, however, mean we need more
> text covering that detail. (It's just text.)
>
> By contrast, if we used a single shared authseq, we change none of the above
> protocol complexity. If the number is 20 for md5 and the next packet is
> ISAAC with sequence number 21 and seed-x, the implementation still computes
> the ISAAC table and indexes into 21. Basically, it has skipped 0..20.
The issue there is that the sequence numbers are 32 bits, and ISAAC produces
"pages" of 256 32-bit numbers. So it's effectively impossible to "seek" to
some random 32-bit value. The key generation has to start somewhere. If it
starts at zero, then if the current sequence number is 0x01000000, then it has
to generate 2^24 pages to "sync up".
A simple approach is to just declare a synchronization point. The current
value of bfd.XmitAuthSeq is where we start ISAAC. Let's call this value w
In that case, the N'th output of ISAAC is just bfd.LocalIsaacStart + N. The
"next" value of bfd.XmitAuthSeq is (bfd.LocalIsaacStart + N) mod 2^32.
> I'm fine with either answer, and I suspect your inclination is keeping the
> separate sequence number spaces and updating the rest of the procedure to
> clarify for that. It'd be good to hear from the other authors as well on
> this point.
The only issue with starting at a value other than zero is that it's slightly
harder to synchronize. The receiving party has to obtain (3*Detect Mult), and
the meticulously compare the received 32-bit Auth-Key with each value. If one
matches, the bfd.LocalIsaacStart variable is set to that. The expected value
for bfd.RcvAuthSeq is set to match.
>> What if there's no auth method, or auth-type==simple?
>
> Another argument for a separate numbering space.
I think that's the best approach.
>> It just keeps going. The sequence number isn't used to derive the 32-bit
>> Auth-Keys taken from ISAAC. So wrapping doesn't matter to it.
>
> I may be confused here.
>
> The current sequence number is 2^32 -1, we're on page X for ISAAC.
> The sequence number wraps to 0 next round. ISAAC would normally generate
> another page.
> The index into that page is 0 rather than 2^32 at the API level.
I think the misconception here is that the ISAAC pages depend on the sequence
numbers. They don't.
Instead, we have the following properties, in vague pseudo-math notation
Dependency between pages:
ISAAC page (n) = ISAAC magic (ISAAC page (n - 1))
Auth Key is derived from the current page:
BFD Auth Key for ISAAC = ISAAC current page [ bfd.XmitAuthSeq & 0xff ]
We change pages after we've generated 256 values:
if bfd.XmitAuthSeq & 0xff == 0xff
ISAAC page (n) = ISAAC magic (ISAAC page (n - 1))
ISAAC current page = ISAAC page (n)
I hope that makes sense.
So with those properties, page(n) doesn't depend on bfd.XmitAuthSeq at all.
> Is the presumption here that this is a modulus operation and it's unimportant
> that the next number is 0 rather than 2^32?
There's no modulus for pages, just for indexes into a page.
Alan DeKok.
