+1 Cheers, Manav
On Tue, Aug 19, 2025 at 9:46 AM Ashesh Mishra <[email protected]> wrote: > Likewise. Thanks! > > On Tue, Aug 19, 2025 at 12:15 PM Mahesh Jethanandani < > [email protected]> wrote: > >> 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] >> >> >> >> >> >> >>
