On Sep 19, 2022, at 1:39 PM, Mahesh Jethanandani <mjethanand...@gmail.com> wrote: > Since you asked what can be done to move this document forward, I went > digging to find out what was the last communication about it. Here is one of > the last e-mail exchange we had on the subject. While the procedure of how > sequence numbers could be secured was clear, there were lingering questions > on how it would fit within the framework of existing specification and what > was the overlap with optimizing authentication.
The document still needs updates for the BFD part. I'm less sure what to do there, and can't offer a lot of advice. As for the current questions, my responses are below. >> On Aug 31, 2021, at 11:12 AM, Jeffrey Haas <jh...@pfrc.org> wrote: >> >> Since this mechanism is intended to work along with >> optimizing-authentication, which implies that we'll be using existing >> authentication mechanisms, how would this be carried? >> >> A core detail we're dealing with is establishing the expected sequence >> number to run through our hash. Consider the text from RFC 5880, ยง6.7.3 >> for keyed MD5: Some of this has been addressed in my last set of updates. The output of the CSPRNG is in the authentication portion of the packet, and doesn't affect the normal BFD sequence number. The discussion in March of this year ended up being that it was too difficult to use the output of ISAAC as the BFD sequence number. There was minimal cost to creating an ISAAC authentication section, and major benefit. i.e. all BFD packet process can remain unchanged. And the authentication section operates as a normal authentication section. A prototype of this is implemented in the code I added to the document repository. > This was one of the questions that we have not addressed in the document. > More on it below. I do not know if this overlaps with the seeding of ISAAC > question, which we marked as outside the scope of the document. The code offers some suggestion for seeding ISAAC. For the simple reason that the two parties have to agree on what numbers are generated / expected. So seeding should be explicitly in scope for the document. The updates I put into the document have two possibilities. Both use a new authentication section: 1) ISAAC. The packet is not authenticated. The authentication section carries an authentication sequence number, and the 32-bit ISAAC output. 2) FNV1A. Which is a hash over the ISAAC output, and the packet. The hash is placed into the authentication section. > I like this suggestion. We could limit the use of secure-sequence-number when > NULL is intended to be used, whereas authenticated packets could use > clear-text sequence numbers. The use of the ISAAC method means that while the BFD packet contents aren't authenticated, that doesn't matter. The packets containing ISAAC authentication only signal "I'm alive". They cannot be used to signal state changes. The repository has been updated to reflect the discussion from March 2022. The document addresses these points, and the sample code implements this. The only thing that's left to do is to update the BFD-specific portions of the document. Alan DeKok.
