On Jul 26, 2021, at 10:14 AM, Jeffrey Haas <jh...@pfrc.org> 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.
