[secdir] Re: Secdir early review of draft-ietf-bfd-stability-13

[Reshad Rahman <[e-mail]>]

 Chiming in late. Inline.
    On Monday, June 10, 2024, 12:22:13 PM EDT, Jeffrey Haas <[e-mail]> wrote:  
 
 Christian,

Thanks for your review.  Some of my comments will overlap those from Alan.

On Fri, Jun 07, 2024 at 09:54:57PM -0700, Christian Huitema via Datatracker wrote:
> The authentication sequence number is a 32 bit field. Such numbers can roll
> over, either after a long duration session or due to a packet injection attack.

As Alan points out, normal rollover is something we're usually unbothered by
in the existing authentication algorithms.

The point you have here is far more about the underlying issue for the null
authentication procedures:

> There is some text about that in the description of the NULL authentication. It
> says:
> 
>    If bfd.AuthSeqKnown is 1, and the received Sequence Number field is
>    not equal to bfd.RcvAuthSeq + 1 (in a circular number space), then
>    the loss count is incremented by one and bfd.RcvAuthSeq is set to the
>    received Sequence Number.
> 
> That does not look quite right. Suppose that due to out of order delivery, the
> packets are received in order 1-3-2-4. Upon reception of packet 3, the
> algorithm counts one loss and set the next expected value to 4. After packet 2,
> another loss and expected value to 3. After packet 4, another loss and expected
> value to 5. So, three losses when none actually occurred.

Agreed.  We do mention this here:

: Implementations MAY provide mechanisms wherein all expected packets received
: across an expected interval but delivered out of order are not considered
: lost packets.

We indeed discussed the option about how to avoid some of these out of order
issues as part of active attacks vs. BFD sessions with NULL authentication.
The conclusion from that thread is we simply CANNOT leverage the sequence
numbers for purposes of "do we pass the authentication checks".  As you note
here:

<RR> Was there any consideration to change the procedure to increment the loss count so that if we get 1-3-2-4, we increment loss count when we receive 3 (2 is deemed lost) but not when we receive 2 (2 < 3 so that means out of order). Also when we receive 2, since 2 < 3 (OOO) if we don't update bfd.RcvAuthSeq, then when we receive 4 we won't increment loss count. So it'd be counted as 1 loss.
Regards,Reshad.