On Jul 26, 2021, at 12:26 AM, Mahesh Jethanandani <mjethanand...@gmail.com> wrote: > I wanted to understand the changes the authors need to make to move the draft > forward. > > On this thread, @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?
I think that makes sense. > 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? Yes. >> 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. If the secure sequence numbers are based on a particular algorithm, then that algorithm should be documented. If we have a fast hash and CSPRNG, we can combine the two to get secure sequence numbers. Plus, we may also leverage this to get the entire packet signed, which might be a desirable property. Alan DeKok.
