On Tue, Mar 25, 2025 at 09:24:16AM -0700, Jürgen Schönwälder via Datatracker
wrote:
> Reviewer: Jürgen Schönwälder
> Review result: Has Issues
>
> * Abstract
>
> It fails to tell a reader what this document provides and leaves the
> paper with a pointer to section 6.7 of RFC 5880.
Interesting that we've gotten so far through the review process and this is
the first complaint on the abstract.
Perhaps:
: This document describes an optimization to BFD Authentication
: as described in Section 6.7 of BFD RFC 5880. It provides procedure
: where only important BFD state transitions require strong
: authentication and permits the majority of BFD Control Packets to use
: a less computationally intensive authentication mechanism. This
: enables BFD to scale better when there is a desire to use strong
: authentication.
> * Introduction
>
> The first paragraph leaves me puzzled as it is not clear what the
> concerns are.
The first two sentences of that paragraph would seem to highlight the
critical detail:
: Authenticating every BFD [RFC5880] control packet with MD5 Message-Digest
: Algorithm [RFC1321], or Secure Hash Algorithm (SHA-1) is a computationally
: intensive process. This makes it difficult, if not impossible, to
: authenticate every packet - particularly at faster rates.
> Is it that cryptographic hash algorithms are generally
> too expensive? Is this still true of you have hardware support? Or
> is this work driven by specific concerns about the security of
> specific cryptographic hash algorithms? Anyway, cryptoagility
> implies that hash algorithms should be replaceable.
A form of this conversation is repeated in every BFD security review.
"Hashes are cheap" tends to be the thinking. The issues are:
- The hash is being run on a very small PDU in a very small amount of time.
If the BFD packet rate is a packet every 10ms, the sender must perform
this cryptographic operation every 10ms for a single session and a
receiver must perform verification every 10ms. Typically no more than 3
packets (the BFD Detection Multiplier) may be lost in a row or the session
will go down.
- There may be a large number of BFD sessions on a given forwarding element.
- Those line cards will want to do other work than just generating hashed
packets.
- Hardware acceleration may or may not be present for the hash operation in
the forwarding element. Even when it is present, it's not free.
I often summarize attempts to change the BFD protocol with "what is so
interesting that you want to tell a remote system that thing every 3ms?"
Authentication is important, but not so important that is should consume all
of a line card's resources.
> The second paragraph describes what the experiment is but it still
> does not say what the optimization is all about. And then I read
> about procedural classification of this document. It is only
> afterwards that the text starts to educate the reader what this is
> all about. But again, this is by first introducing details first
> before coming to the point that the idea is to authenticate only some
> of the BFD packets and not all of them. This should have been in the
> abstract and right at the beginning of the introduction.
Does the addition to the abstract, above, adress this concern?
> I found it funny that MD5 and SHA1 are considered "strong" a few
> sentences after it was said that there are substantial concerns
> about the strength of MD5 and SHA1. Interestingly, RFC 5880 actually
> says: "The use of MD5-based authentication is strongly discouraged."
> That is clear language. ;-)
The authors have struggled to find appropriate language to describe the two
modes this procedure operates in. "Strong" is relative to the "less
computationally intensive mode" that the majority of the authentication
opeates in. "Weak" was inappropriate for that other mode as was "less
strong".
And similarly, a motivation for this work was the original KARP WG analysis
that showed that even moving to something as "simple" as SHA-2 would melt
most systems using BFD.
Thus, there's a desire to provide a method by which stronger authentication
COULD be used at all. That can't be each packet - it must be a subset.
> What does "significantly reduces the computational demand for the
> system while maintaining security of the session across the
> configured strong reauthentication interval" mean? If you go from
> authenticating each packet to authenticating say every N packets,
> then the performance gain does come with a reduced level of security
> since there are packets that are not authenticated. Perhaps it is OK
> to make this trade-off but it feels like the authors prefer to not be
> explicit about this trade-off.
Prior versions of this proposal worked through additional use cases that
were eventually disconsidered:
Perform NO authentication for the majority of the Up PDUs. This permited a
blind attacker to keep a BFD session inappropriately Up.
Detect issues in sequence numbers between Up packets. (Null authentication
mode.) It was eventually determined that an active attacker could use
packet injection within the sequence number window to push the session's
validated sequence number space outside of that window and cause the session
to incorrectly go Down.
The current procedures thus use an "optimized" authentication mechanism
where all PDUs are authentication and only the strength of the
authentication varies. The only optimized mode specified at this time is
ISAAC.
> * Authentication Mode
>
> I wonder whether "optimized" is the right term. Is less security
> more optimal? Perhaps it is "reduced" authentication or "more
> lightweight" authentication? Well, perhaps in the industry,
> "optimized" authentication is just a synonym for reduced
> authentication?
Here we dance between technical correctness and marketing. :-)
Is more security more optimal if it decreases the scalability of the system?
The procedure isn't fully lightweight - it is selectively so.
Thus, "optimized" is used in the sense that it performs a tradeoff between
using strong(er) authentication mechanisms for the important parts of the
protocol while using "less strong" mechanisms that scale better for the vast
majority of the protocol.
To give a more tangible sense of why this is so, consider a system that has
1000 sessions configured using this mechanism. BFD sessions that have
active participants at each side of the connection will usually transition
to the Up state within 3-5 packets exchanged. In such a case, 5000
"strongly authenticated" packets are required to bring 1000 sessions Up.
After that, the remainder of the PDUs between the systems will use less CPU.
> * Signaling Optimized Authentication
>
> Existing implementations will ignore the optimized authentication
> mode, I assume authors have verified that some systems ignoring the
> mode will not cause operational problems.
Base RFC 5880 section 6.7+ procedures already provide for ignoring packets
that don't have an expected Auth Type.
> * Optimizing Authentication YANG Model
>
> What is the reason for a default of 60 seconds for the reauth
> interval? According to the security considerations, there is a
> security vs. performance trade-off here. Any particular reason
> why 60 seconds is a good setting?
"Constants are always wrong".
We picked a number. That number needs to be "not too small" otherwise we'll
lose the benefits we're trying to achieve. The number needs to be "not too
big" such that a compromise of the "less computationally intensive"
mechanism is not otherwise caught. (We don't expect attacks on this to
succeed as of this time.)
We even argued do we want to do this at all? As noted above, we considered
other mechanisms than ISAAC. At that time, periodic stronger
re-authentication may have prevented a session from being kept
indefinitely in the Up state. With ISAAC as our optimized mode,
re-authentication is significantly less required and perhaps even optional.
If you have good logic as to why such a number is a wrong fit, we'll happily
take that into consideration.
> * Security Considerations
>
> I am puzzled by this statement:
>
> "The approach described in this document enhances the ability to
> authenticate a BFD session by taking away the onerous requirement
> that every BFD control packet be authenticated."
>
> How does strongly authenticating only some packets enhance the
> ability to authenticate a BFD session? I also wonder how you close
> the section with "further enhances the security of BFD sessions".
This is a fair point, and the text is from the prior proposal where Up
packets were not authenticated.
I have adjusted the text in this paragraph to always read "strongly
authenticated":
: The approach described in this document enhances the ability
: to authenticate a BFD session by taking away the onerous
: requirement that every BFD control packet be strongly authenticated.
By
: strongly authenticating packets that affect the state of the session,
: the security of the BFD session is maintained. In this mode,
: packets that are a significant change but are not
: strongly authenticated, are dropped by the system. Therefore, a
: malicious user that tries to inject a non-authenticated
: packet; e.g. with a Down state to take a session down will
: fail. That combined with the proposal of using sequence number
: defined in <xref
: target="I-D.ietf-bfd-secure-sequence-numbers">Meticulous Keyed
: ISAAC for BFD Authentication</xref> further enhances the
: security of BFD sessions.
I will push a pull request for the edits noted above to the github for this
document:
https://github.com/bfd-wg/optimized-auth/pulls
As always, thanks for your careful review.
-- Jeff
