Mike,
On 9/17/25 17:10, Mike Bishop via Datatracker wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
If there are no implementations and no plans to implement, why are we
publishing this?
Mahesh gave the polite form of this answer, which applies to all three
BFD document that are under discussion.
I support Deb's DISCUSS regarding the term "strong authentication" throughout.
MD5 and SHA1 are *not* strong. In other contexts, they are the primitives that
are used when stronger hash functions are too expensive and the additional
security doesn't justify the cost.
As already noted in the response to her discuss, once appropriately
blessed terms are given, they'll be swapped into the relevant slots in
the document. The relevant property is they're the stronger of the pair.
I also support Gorry's DISCUSS on "optimized". I understand the reasoning, but
that term doesn't make it clear what property is being improved without loss of
function. In Section 10, it even asserts that this "enhances the ability to
authenticate a BFD session" when in fact this explicitly *reduces* the
authentication of the session. Perhaps this should be "lower effort" instead?
Maybe even "lazy", if that's not seen as too judgmental?
When the WG and authors were discussing what to call the optimized
mechanism (ISAAC being the single proposal that's survived discussion),
we did note that calling it "weak" or "weaker" doesn't exactly fill one
with confidence. That said, it was easier than giving them names like
method-Alice and method-Bob and noting that Alice was stronger than Bob.
The overall sense that is intended to be conveyed in the document is the
optimization is that it permits higher BFD scaling. As you'll note from
the various threads thus far, scaling is a multidimensional thing that
may encompass number of sessions, or speed. The cryptographic
operations for authentication degrade performance in one or more of
these considerations. This motivates operators and implementers to opt
to not to use authentication.
The rationale for reducing overhead in sending packets that effectively say
"nothing has changed" seems reasonable at first glance. However, it seems to me
that an attacker who can drop the "significant change" packets could carry out
an attack by fabricating "nothing has changed" messages and preventing
detection of a change.
See the response to Deb's discuss to cover the usual attacks vs. BFD.
The scenario you're highlighting is "spoofing packets to keep the
session in the Up state".
"Nothing has changed" is still a message that needs to
be protected.
This is the intention of the optimized method; currently ISAAC. Also
discussed by the WG was no or next to no authentication of the Up
packets. However, as you'll see in other responses to the IESG, this
increased the attack surface on the state machinery and was eventually
dropped from consideration.
The requirement to "periodically test the session using the
strong authentication mechanism" attempts to bound this risk. This should be
discussed in the Security Considerations, emphasizing that the period used is
the amount of time the parties are willing to allow an attacker to conceal a
state change they attempted to communicate.
Is the text in section 10.2 covering "reauth-interval" not sufficient?
-- Jeff
