The change makes sense to me. Thanks.

> On Aug 18, 2025, at 2:16 PM, Jeffrey Haas <[email protected]> wrote:
> 
> Marcus,
> 
> On 8/18/25 15:56, Marcus Ihlar via Datatracker wrote:
>> Periodic Strong Reauthentication (Section 5):
>> This procedure reuses the BFD Poll Sequence, with packets carrying strong
>> authentication until a response with F=1 is received. If no F=1 arrives 
>> within
>> the Detection Time, the session is torn down. Lack of Final packets could
>> result either from authentication failure or from packet loss. In demand mode
>> this behavior is consistent with RFC 5880, but in asynchronous mode it
>> introduces a slightly stricter failure mode: where in base BFD a lost F=1 
>> only
>> prevented parameter changes, here it can lead to session teardown.
>> 
>> This is probably a very unlikely case in practice, but the likelihood could 
>> be
>> influenced by the choice of Min TX interval ßand Detect Multiplier. A short
>> discussion on loss and reauthentication in Section 5, or in an Operational
>> Considerations section, might be warranted.ß
> 
> This is an interesting corner case.  I'll be posting the following diff to 
> the github repo for review by the other authors to address this point. Please 
> let us know what you think of it:
> 
> --- a/draft/draft-ietf-bfd-optimizing-authentication.xml
> +++ b/draft/draft-ietf-bfd-optimizing-authentication.xml
> @@ -260,8 +260,18 @@
>          Poll sequence. To test strong authentication, a Poll sequence SHOULD
>          be initiated by the sender using the strong authentication mode 
> rather
>          than the less computationally intensive mechanism. If a control 
> packet
> -        with the Final (F) bit is not received within the Detect Interval, 
> the
> -        session has been compromised, and MUST be brought down.
> +        with the Final (F) bit is not received within twice the Detect 
> Interval
> +       as would be calculated by the receiving system, the session has been
> +       compromised, and MUST be brought down.
> +      </t>
> +      <t>
> +       The value "twice the Detect interval as would be calculated by the
> +       receiving system" is, roughly, twice the number of packets the local
> +       system would transmit to the receiving system within its own Detect
> +       Interval.  This accommodates for possible packet loss from the sending
> +       system during the Poll sequence to the receiving system, plus time for
> +       the receiving system to transmit control packet with the Final (F) bit
> +       set to the local system.
> 


Mahesh Jethanandani
[email protected]






Reply via email to