[Last-Call] Re: draft-ietf-bfd-optimizing-authentication-28 ietf last call Tsvart review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux