Hi Jeff,
On Tuesday, February 6, 2024, 08:41:12 AM EST, Jeffrey Haas
<[email protected]> wrote:
Reshad,
On Feb 5, 2024, at 4:18 PM, Reshad Rahman <[email protected]>
wrote:
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.
Related notes from those conversations for the mailing list:
- A poll mechanism to test for a new behavior where the possibility exists for
the poll packets to be lost means you have to be mindful of Detect Mult
(permitted number of lost packets) and timers. For example, a one packet poll
is enough to probe if the packet isn't lost in either direction. In case of
loss, you don't want to do the poll for Detect Mult packets because if the drop
is the result, the session goes down.
Mitigations may include temporarily changing the Detect Mult.
- One mitigation for the repeatedly bouncing sessions is to have the BFD
session keep state. If the implementation switches to optimized mode and the
session drops, don't permit the session to automatically restart if it does
this after more than X tries. Require the operator to clear the state?
<RR2> Requiring operator to clear the state is fine in e.g. a lab environment.
But in a prod env where opt-auth could be enabled on 1 side by mistake, I'd
rather we find a way to handle that automatically in the protocol.
Other questions on section 2: - In paragraph 2, does this new procedure of
accepting unauthenticated packets on a receiver apply even if opt-auth is
disabled on the receiver (but is a supported feature)?- It would be interesting
to walkthrough the sequence to upgrade a BFD session from Auth to opt-auth.
Both ends can not be configured simultaneously, so I *think* this answers my
question above.
Would an early review e.g. by ops, help to catch issues?
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.
We're looking for consistency in configuration.
If optimized procedures require another mechanism to be chosen for the
optimized Up side of things, and that's done via the keychain, you need a valid
keychain entry.
Further, properties such as "when is this valid" and other keychain properties
are still valid.
identity null {
base key-chain:crypto-algorithm;<RR> null-auth to be consistent with
no-auth (assuming we keep NULL auth)?
If we don't change the name, sure.
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?
This is a headache elsewhere in YANG modules. While the units clause lets us
be clear that leaf A and leaf B aren't directly comparable if they don't share
the units, it still trips people up.
That said, it's also not forbidden. re-auth on the interval of seconds seems
reasonable to me.
And, as I mentioned in a prior thread, the 60 second value that's been chosen
is rather arbitrary.
<RR> Mention that value of 0 means that we don't do periodic reauth with strong
authentication.
We could probably do that, especially in support of ISAAC procedures.
leaf up-auth-type {<RR> Since this points to a key-chain, rename to
something like opt-auth-key-chain?
Also reasonable. The move to the "opt" name token in the draft is largely over
the most recent discussion.
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?
The optimized procedures require meticulous authentication. The NULL and ISAAC
methods use this mode to prevent PITM. If you don't regularly increment the
numbers, you're defining the interval in which the "attack" (silly as it is to
some people) can happen.
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?
What wording would you prefer for "select this type for this mode"?
<RR2> I am just not groking the "in case of optimized auth". Ignore if it's
just me.IIUC, based on the other thread, NULL auth will be removed from the
description below?
Regards,Reshad.
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
