Mallory,
Thanks for your comments. A partial response to some of your points:
On 8/14/25 10:40, Mallory Knodel via Datatracker wrote:
It seems that the nomenclature should be somewhat patterned in format
everywhere consistently thusly:
Too many hands on the diff. These are details where the RFC editor is
capable of normalizing things. But since edits need to happen, some
work can happen prior to that.
Thus one could instead just rely on "Meticulously Keyed" as the
proper noun and treat the rest as adjectives or descriptors in context.
Those happen to be adjectives to a specific type of authentication and
would be inappropriate to use solely as nouns.
I do agree with other reviewers' suggestions that without a clear definition
that unfamiliar readers might be struggle to understand the core specification.
This was a strong motivation for the text in section 1.1 that defines
what those adjectives are intended to mean in a BFD context. However,
since this would have best gone in an update to RFC 5880 and anchored
that way in the document stream, we have a problem. There is now a
perverse incentive to want to define it once in a single document while
being motivated to repeat that definition in each additional document.
I found reading the bfd charter and milestone drafts helpful and perhaps you
could write a brief description in the introduction, perhaps as a second
paragraph, about this document as it relates to the BFD's larger slate of work.
Section 3 helpfully does some of this work.
I appreciate Section 1.1. but I think it can be presented as an update to
RFC5880 unself-consciously, for instance:
In RFC5880 [RFC5880], "(sequence number excerpt)." Here the terms "meticulous
keyed" and "meticulous keying" ... (final paragraph) means that the Sequence
number is incremented on every new packet that is sent. The term "keyed" means
that ... "Meticulous Keyed" therefore refers to BFD authentication type where
each packet is unique, and can be authenticated.
Just pointing out that if meticulous means unique and keyed means authenticated
then 'meticulous keyed bfd authentication' means unique authenticated bfd
authentication. This coarse simplification might illustrate how to streamline
the terminology, to the extent that you can use this document and the
optimizing-authentication draft to gently revise terms and definitions
inherited from prior documents.
While your observation is well-intentioned, it also loses focus that the
property is not solely unique, but incrementing with each subsequent
packet. That property is important in this document, but it is critical
in the bfd stability draft.
Minor issues:
* What is the reason that this draft is experimental? Is there something more
stable that is or should be used instead that this replaces? If so, please
clearly state that.
It is left in this form as part of prior discussion with the
routing-ADs. If they wish to include a shortened form of a rather long
history of why we got to this status, it should be supplied as part of
IESG review.
Tersely for your information and the archives, it's because this work
had gotten far enough along that there was a desire for it to be
"finished", but that the individuals doing that finishing work had
diminished to a fraction of the original contributors. Thus,
experimental is intended to reflect the overall scrutiny these documents
have received in WG review.
That terse explanation is not present because it's incomplete and mostly
leads to more questions than it answers. :-)
* S 3.1. "originator of the packet is authentic" or "originator of the packet
is authenticated"?
I agree the wording here is unusual, but I would like to see what
security practitioners would like to use. BFD Up packets containing
ISAAC have not been "signed" in the way that usually represents
authentication in many contexts. They are literally just carriers for
"the next number". The wording should convey some sense of that
distinction, I think. (I am not a security professional.)
* Document outline could be streamlined. Sections 4.1. and 6. have the same
title but present different information. Perhaps Sections 4-6 could be better
organized, or the current structure justified with more descriptive titles.
Perhaps sections 5 and 6 could be stated as "BFD authentication
procedures when using XXX formats"?
The functional distinctions are that section 4 describes a PDU format,
and section 5 and 6 describe using them as part of BFD authentication.
* In security considerations I think the final sentence could be more explicit
about the tradeoff between generator security and resource constraints and
that picking something stronger like AES is infeasible in routing protocols.
An observation about being infeasible for routing protocols is
over-generalized. "Resource constrained systems" attempts to capture
the usual dueling considerations for security practitioners vs. the BFD
protocol. Namely, the tiny CPUs in line cards have better things to be
doing than doing expensive crypto - even with acceleration. Also, such
line cards have limited memory. Mechanisms that eat either CPU or
memory are thus inappropriate, and hardware accelerators for such
operations often are created after the mechanism is defined and deployed.
Nits/editorial comments:
Noted.
Again, appreciate all your work on this document. I hope these comments and
suggestions can be helpful.
They have been. Thanks.
-- Jeff
