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

[Alan DeKok <[e-mail]>]

On Jul 26, 2021, at 10:14 AM, Jeffrey Haas <[e-mail]> wrote:
> So, what is needed:
> - A mechanism that can be used with the optimizing authentication extension.
> - That is light weight enough to justify it as being better than existing
>  HMAC MD5 for periodic transmissions.
> - The value of which could be encoded in the BFD Authentication section.

  That should be possible.

> Upon receipt, the BFD neighbor needs to verify the packet.  As currently
> written, the secure sequence number draft seems to suggest a reversible
> mechanism from which the hash packet may be reversed and the sequence number
> determined.  This sequence number is required by the validation procedure
> for BFD sessions.  It's my belief that the form of cryptographic hash
> function we're discussing is a one-way function.

  Yes.

> If it is a one-way function, the receiving procedure can't be to "reverse"
> it.  At best, it can take the PDU as input, try the BFD Detection Multiplier
> number (valid packet sequence window), then see if a hash that is computed
> on the input PDU with the possible sequence numbers yields the received
> sequence number, H, in the PDU.

  Yes.

> This means that the benefit for the feature would require a function that
> can be run on a window of packets for predicted inputs and generate the pool
> of next expected sequence numbers.

  Yes.

  I think a cryptographic random number generator here is likely OK.  Those are usually simple, and fast.  The system can be seeded with a strong secret, or maybe hash of a secret and other information.

  My suggestion to calculate a hash over the packet is that it prevents certain kinds of attacks.  i.e. an attacker could take packet X, and sequence number Y, and put the two together, to spoof / forge state.

  Fixing that requires that the sequence number is somehow tied to a particular packet.

  Alan DeKok.