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.
* Introduction
The first paragraph leaves me puzzled as it is not clear what the
concerns are. 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.
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.
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. ;-)
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.
* 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?
* 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.
* 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?
* 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".
My naive understanding is that non-optimized BFD authentication is
stronger than optimized secure BFD authentication even with sequence
number authentication. Or said differently, if security is your
prime operational concern, do not use "optimized" BFD authentication.
From an operational perspective, I prefer documents that are clear
about what they propose. If the goal is to improve performance by
lowering the security level of sequences of BFD packets, just say
so. (And I apologize in case I misunderstood document.)
