Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt

[Mahesh Jethanandani <[e-mail]>]

[Putting the thread on the BFD mailing list]

Hi Jeff/Alan,

I wanted to understand the changes the authors need to make to move the draft forward.

On this thread <https://mailarchive.ietf.org/arch/msg/rtg-bfd/jw1aH07S363k41OCbBDUk2INmRE/>, @Jeff stated that you were looking for clarity on the following statement.

   Note: The first sequence number can
   be obtained using the same logic as used in determining Local
   Discriminator value for the session or by using a random number.
For which I believe the consensus is the suggestion from Alan below to add an authentication section in the first packet that carries the nonce. Right?

See inline for more.

> On Apr 6, 2021, at 3:09 AM, Alan DeKok <[e-mail]> wrote:
> 
> On Apr 5, 2021, at 3:08 PM, Jeffrey Haas <[e-mail]> wrote:
>> BFD needs an increasing sequencing number.  But we also are trying to
>> get replay protection.  What that means is that we likely don't want to
>> start at sequence 1 every time - or we need to have a nonce to make sure we
>> don't get a replay if we do.  
>> 
>> The protocol currently doesn't carry anything to use as a nonce.
> 
>  Maybe add an authentication section in the first packet, which can then carry a nonce?
> 
>> As written (see section 3), it's written as a reversible operation, which
>> would be reasonable from a symmetric bit of crypto.  But if we're using a
>> hash, I don't believe we get that property.  Instead, we have to know what
>> we're expecting in each side and have the next k values computed, where k is
>> in the window of the BFD Detect Multiplier (lost packets maximum).
> 
>  Yes.
> 
>> Somewhere in between draft-06 and -07, the text started moving toward
>> "symmetric key algorithm" from hash, probably as part of the clarification
>> requests for how the mechanism worked.  Likely my request, and I failed to
>> remember that we wanted fast hash rather than reversible.
> 
>  It depends on what the goals are, I guess.  A cryptographic random number generator is likely to be much faster than a reversible encryption method, especially on constrained CPUs.  But random number generators aren't reversible, which is also a useful property.
> 
>  The main issue with a strong hash function is that it's a hash, and isn't intended to generate sequences of numbers.

What I understand from this discussion is that the WG feels that rather than symmetric key algorithm, a hash should be used for computing the ciphertext (if that is the correct term for computed hash?) that will be inserted in the sequence number field, and the other end will compare the computed hash against the next k values it has computed on the expected sequence numbers within the window of BFD Detect Multiplier. Did I get that right?

Inserting this from the same thread.

> 
>>> If so, getting some text would help a bunch.
>> 
>>  I'll see what I can do.
> 
> That'd be great.

Alan, could you help us with the text here.

> 
>> That was my impression.  Complexity might be worthwhile as long as the memory
>> is constrained.  This is going onto linecards with the CPUs that would
>> embarass a lot of people, after all.
> 
>  The Blake3 code isn't trivial, and doesn't seem to have fixed-size memory requirements, unlike MD5 / SHA.
> 
>  Looking around, we also have https://tools.ietf.org/html/rfc8937, which recommends against directly using the output of a PRNG.  It recommends instead a fairly complex scheme, which isn't applicable here.  But perhaps we could do something similar.
> 
>  My suggestion would be to do something vaguely like what RFC 8937 suggests, but with weaker / faster algorithms.
> 
>  We could use ISAAC to securely generate a sequence of random numbers.  The first packets exchanged could contain an authentication section with a nonce.  ISAAC would be seeded with a secret key and a nonce, and would generate a stream of 32-bit cryptographically strong pseudo-random numbers.
> 
>  We could use this output directly, but we might want to go a step further.  We could add a fast hash function to further hide the output of the random number generator, and also get authentication of the packet contents.
> 
>  i.e. for a packet P, set My-Discriminator to zero, take the random number X from Isaac, and then calculate Hash(X, P).  The output is a 32-bit number which can go into the discriminator field.
> 
>  The other end can set the discriminator to zero, calculate the hash, and then see if the packet has been authenticated.  The benefit here is that it's authenticating not just the particular sequence from the random number generator.  It is also authenticating the packet.  And, because the packet contains Your-Discriminator, the has would authenticate the entire sequence of packets.  Which seems a desirable property.
> 
>  Either option would be imperfect, but fast and reasonably secure.

Not clear on whether we are now trying to define how the nonce should be calculated, and if that is not getting into implementation level details. 

Thanks.

> 
>  Alan DeKok.
> 

Mahesh Jethanandani
[e-mail]