Hi,
I've provided some comments to the authors privately, sharing them here to
restart/continue the discussion on the WG alias.
My main technical concern is in the changes to BFD auth mode: when
transitioning to No auth for up packets, we don't know if the other end
supports procedure changes from this document. So the other end could just drop
the unauthenticated UP packets and the session will go down, eventually go back
up, in a loop. The counter-argument which has been made is that this issue
isn't new e.g. if one end is misconfigured for BFD auth, the session will not
come up, so this boils down to being a typical config issue. I do agree
partially, but I think the changes in this document can make things worse than
usual in that the session will come up, go down very quickly and keep on ding
that. We don't have any room left in the BFD header to indicate the desired
behaviour. The only thing I could think of is to use Poll sequence with A=0 (on
top of the expected A=1 packets), and transition to only A=0 if the Poll
sequence succeeds (and the Poll sequence has to be for N packets where N is
equal to "remote multiplier"). Jeff has pointed out that Xiao Min has suggested
a similar solution in
https://datatracker.ietf.org/doc/html/draft-xiao-bfd-padding-alteration-00.
In terms of editorial comment, I am now questioning the term NULL auth since we
also use the term No auth. Suggestions: Meticulous sequence number, sequence
number or something along those lines.
YANG comments/questions/suggestions:
identity no-auth {
base key-chain:crypto-algorithm;<RR> It is a bit odd to have a crypto
algorithm which says none. I wonder if a boolean would have been better to
indicate no-auth.
identity null {
base key-chain:crypto-algorithm;<RR> null-auth to be consistent with
no-auth (assuming we keep NULL auth)?
leaf reauth-interval { when "../optimized-auth = 'true'";
type uint32; units "microseconds";<RR> I think it's overkill to have
this in microsecs. Other intervals use micro secs because we exchange timer
values in micro secs. This value is not exchanged so we don't need microsecs.
Or are you doing this for consistency?<RR> Mention that value of 0 means that
we don't do periodic reauth with strong authentication.
leaf up-auth-type {<RR> Since this points to a key-chain, rename to
something like opt-auth-key-chain? type key-chain:key-chain-ref;
must "(../optimized-auth = 'true') and " +
"(../bfd-ip-sh:meticulous = 'true')";<RR> Why the check for meticulous? Is the
reasoning that for non-meticulous opt-auth isn't needed or is it something
else? description "The authentication type that should be
used once the connection transitions to Up state. In case <RR> Why
in case? Isn't this only for optimized auth? of optimized auth, the
choices are Reserved (or no authentication), NULL Auth, or
Meticulous Keyed ISAAC."; } description "Augment the 'bfd'
container to add attributes related to BFD <RR> The 'authentication' container?
Same below optimized authentication."; }
Regards,Reshad.
On Monday, February 5, 2024, 12:14:55 PM EST, [email protected]
<[email protected]> wrote:
Internet-Draft draft-ietf-bfd-optimizing-authentication-14.txt is now
available. It is a work item of the Bidirectional Forwarding Detection (BFD)
WG of the IETF.
Title: Optimizing BFD Authentication
Authors: Mahesh Jethanandani
Ashesh Mishra
Ankur Saxena
Manav Bhatia
Name: draft-ietf-bfd-optimizing-authentication-14.txt
Pages: 26
Dates: 2024-02-05
Abstract:
This document describes an optimization to BFD Authentication as
described in Section 6.7 of BFD RFC 5880. This document updates RFC
5880.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-14
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-optimizing-authentication-14
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
