Re: draft-ietf-bfd-optimizing-authentication-13 nits

[Alan DeKok <[e-mail]>]

On Jan 23, 2024, at 9:15 PM, Mahesh Jethanandani <[e-mail]> wrote:
> Here are some of the possible scenarios that I can think of, what config would apply, and what would be the behavior.
> 
> - No auth, no secure sequence number, no stability. No new config. Things will work as defined in RFC 5880.
> - Strong auth, no secure sequence number, no stability. No new config. Things will work as defined in RFC 5880.

  I would reiterate that the "secure sequence number" draft has evolved away from "securing" the sequence number.  It turned out that it was too difficult to mangle the sequence number and have the BFD state machine still work.

  Instead, the document now proposes a normal Auth Type method which uses the normal BFD state machine.  i.e. It doesn't modify the sequence numbers at all.

  The ISAAC method is an Auth Type which doesn't verify the entire packet.  As such it is faster, but less secure.

  The authentication done by ISAAC is just to exchange a series of numbers based on a keyed pseudo-random number generator.  If both parties have the key, they can calculate the same sequence.

  I would see the choices as:

* session state changes, including poll mode: entire packet MUST be verified with a strong Auth Type

* session remains "Up", use one of:

  * NULL auth, but attackers can send spoofed packets to keep the session up

  * ISAAC auth - each packet contains a changing Auth Key which proves that the other end is still alive

  I dropped the other bullet points, because they assumed that the sequence numbers were being mangled, and they're not.

  I think for the "Up" state, it's useful to require a meticulous Auth Type method.  That way you know that each new packet is a new signal that the session is still up.  I don't see much use for a non-meticulous Auth Type method, as packets can just be replayed.

  Alan DeKok.