Subject: A question about BFD authentication sequence number

From: Mach Chen <[email-masked]>
Date: Mon, 20 Sep 2010 18:05:00 +0800

Hi,

When I read RFC 5880, I have some questions about the receiving process of 
RcvAuthSeq, which said that the Sequence Number MUST lies in the range of 
bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult). And IMHO, how to judge the 
RcvAuthSeq is vaild or not is highly related to how to increment it at the 
sender. But in the document, it said "The decision as to when to increment 
bfd.XmitAuthSeq is outside the scope of this specification". How to 
understand it?  In addition, why "3" is used?

I'd appreciate that someone would explain this to me!

Quoted from Section 6.7.3
"
If bfd.AuthSeqKnown is 1, examine the Sequence Number field.  For
      Keyed MD5, if the Sequence Number lies outside of the range of
      bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult) inclusive (when
      treated as an unsigned 32 bit circular number space), the received
      packet MUST be discarded.
"

Best regards,
Mach

---

From: Dave Katz <[email-masked]>
Date: Mon, 20 Sep 2010 09:50:56 -0400

The point of the vague language is to provide flexibility on when an implementation chooses to increment the sequence number, but it is always an increment (add 1) and by definition it cannot happen more than once per packet, so it is not unbounded in its flexibility.

The range specified for acceptable sequence numbers maps into the largest number of consecutive packets that can be lost before the protocol fails (since once the sequence numbers get too far out of sync, none will be received.)  Since Detect Mult is only a rough estimate at the number of lost packets before the session drops anyhow, the *3 gives some wiggle room to avoid accidental failures (at the cost of a slightly wider increase of window size through which a packet could be replayed.

--Dave
 
On Sep 20, 2010, at 6:05 AM, Mach Chen wrote:

> Hi,
> 
> When I read RFC 5880, I have some questions about the receiving process of RcvAuthSeq, which said that the Sequence Number MUST lies in the range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult). And IMHO, how to judge the RcvAuthSeq is vaild or not is highly related to how to increment it at the sender. But in the document, it said "The decision as to when to increment bfd.XmitAuthSeq is outside the scope of this specification". How to understand it?  In addition, why "3" is used?
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 21 Sep 2010 11:00:57 +0800

Hi Dave,

Got it, thanks for your prompt explanation!

So, if my understanding is correct, although most implementations will 
choose to add 1, theoretically, the "*3" implicits that the implementation 
could choose to increment the sequence number with 1, 2 or maybe 3.

Best regards,
Mach

--------------------------------------------------
From: "Dave Katz" <[email-masked]>
Sent: Monday, September 20, 2010 9:50 PM
To: "Mach Chen" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: A question about BFD authentication sequence number

> The point of the vague language is to provide flexibility on when an 
> implementation chooses to increment the sequence number, but it is always 
> an increment (add 1) and by definition it cannot happen more than once per 
> packet, so it is not unbounded in its flexibility.
>
> The range specified for acceptable sequence numbers maps into the largest 
> number of consecutive packets that can be lost before the protocol fails 
> (since once the sequence numbers get too far out of sync, none will be 
> received.)  Since Detect Mult is only a rough estimate at the number of 
> lost packets before the session drops anyhow, the *3 gives some wiggle 
> room to avoid accidental failures (at the cost of a slightly wider 
> increase of window size through which a packet could be replayed.
>
> --Dave
>
>> When I read RFC 5880, I have some questions about the receiving process 
>> of RcvAuthSeq, which said that the Sequence Number MUST lies in the range 
>> of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult). And IMHO, how to 
>> judge the RcvAuthSeq is vaild or not is highly related to how to 
>> increment it at the sender. But in the document, it said "The decision as 
>> to when to increment bfd.XmitAuthSeq is outside the scope of this 
>> specification". How to understand it?  In addition, why "3" is used?
>>

---

From: Dave Katz <[email-masked]>
Date: Mon, 20 Sep 2010 23:30:45 -0400

On Sep 20, 2010, at 11:00 PM, Mach Chen wrote:

> So, if my understanding is correct, although most implementations will choose to add 1, theoretically, the "*3" implicits that the implementation could choose to increment the sequence number with 1, 2 or maybe 3.

No, that should not be the case;  an implementation should always add 1 (that's what "increment" means).

The math has to do with the detection time.  The goal is to ensure that, even if a bunch of consecutive packets are lost, if the session would otherwise stay up, the receive window should accept the "last" packet so that the session *does* stay up.

For example, let's say that the multiplier is 3 and the (nominal) transmit interval is one second.  This means that the detection time is three seconds.  Under normal circumstances, a packet will be sent every .875 seconds on average (due to applied jitter).  An implementation following the spec can send one extra packet per transmit interval (in the case where the state is changing, or replying to a Poll, for example.)  This means that the average interval is .4375 seconds.  This is just shy of seven packets within the three seconds.  If six packets are lost in a row, the session would stay up if authentication weren't running.  So to keep authentication from killing the session (by falling outside of the receive window) the window must be at least six (or twice the multiplier).  If you increase the multiplier, the jitter becomes more significant (with a multiplier of 4, you can get 9 packets within the detection time).  So we chose to multiply by three.

Not sure if that's entirely clear...

--Dave

---

From: Mach Chen <[email-masked]>
Date: Tue, 21 Sep 2010 11:55:38 +0800

Hi Dave,

I am clear now, many thanks for your detailed explanation!

Best regards,
Mach

Sent: Tuesday, September 21, 2010 11:30 AM

>> choose to add 1, theoretically, the "*3" implicits that the 
>> implementation could choose to increment the sequence number with 1, 2 or 
>> maybe 3.
>
> The math has to do with the detection time.  The goal is to ensure that, 
> even if a bunch of consecutive packets are lost, if the session would 
> otherwise stay up, the receive window should accept the "last" packet so 
> that the session *does* stay up.
>
> For example, let's say that the multiplier is 3 and the (nominal) transmit 
> interval is one second.  This means that the detection time is three 
> seconds.  Under normal circumstances, a packet will be sent every .875 
> seconds on average (due to applied jitter).  An implementation following 
> the spec can send one extra packet per transmit interval (in the case 
> where the state is changing, or replying to a Poll, for example.)  This 
> means that the average interval is .4375 seconds.  This is just shy of 
> seven packets within the three seconds.  If six packets are lost in a row, 
> the session would stay up if authentication weren't running.  So to keep 
> authentication from killing the session (by falling outside of the receive 
> window) the window must be at least six (or twice the multiplier).  If you 
> increase the multiplier, the jitter becomes more significant (with a 
> multiplier of 4, you can get 9 packets within the detection time).  So we 
> chose to multiply by three.
>
>>> implementation chooses to increment the sequence number, but it is 
>>> always an increment (add 1) and by definition it cannot happen more than 
>>> once per packet, so it is not unbounded in its flexibility.
>>>
>>> The range specified for acceptable sequence numbers maps into the 
>>> largest number of consecutive packets that can be lost before the 
>>> protocol fails (since once the sequence numbers get too far out of sync, 
>>> none will be received.)  Since Detect Mult is only a rough estimate at 
>>> the number of lost packets before the session drops anyhow, the *3 gives 
>>> some wiggle room to avoid accidental failures (at the cost of a slightly 
>>> wider increase of window size through which a packet could be replayed.
>>>
>>> --Dave
>>>
>>>> of RcvAuthSeq, which said that the Sequence Number MUST lies in the 
>>>> range of bfd.RcvAuthSeq to bfd.RcvAuthSeq+(3*Detect Mult). And IMHO, 
>>>> how to judge the RcvAuthSeq is vaild or not is highly related to how to 
>>>> increment it at the sender. But in the document, it said "The decision 
>>>> as to when to increment bfd.XmitAuthSeq is outside the scope of this