Thanks for the quick response.
The proposed text looks good to me.
BR
Marcus
-----Original Message-----
From: Jeffrey Haas <jhaas@xxxxxxxx>
Sent: Monday, 18 August 2025 23:16
To: Marcus Ihlar <marcus.ihlar@xxxxxxxxxxxx>; tsv-art@xxxxxxxx
Cc: draft-ietf-bfd-optimizing-authentication.all@xxxxxxxx; last-call@xxxxxxxx; rtg-bfd@xxxxxxxx
Subject: Re: draft-ietf-bfd-optimizing-authentication-28 ietf last call Tsvart review
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.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
