Re: Comments on draft-ietf-bfd-secure-sequence-numbers-10

[Alan DeKok <[e-mail]>]

On Mar 21, 2023, at 5:07 PM, Jeffrey Haas <[e-mail]> 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.