The issue of selective authentication is interesting. After reviewing
draft-ietf-bfd-stability-13, we had some discussion of attacks made
possible by spoofing BFD packets, and specifically spoofing their
sequence numbers. I was under the impression that for a given
association, all packets will have the same authentication -- MD5, SHA1,
or NULL. There maybe ways to improve robustness of "NULL" sessions if a
fraction of the packets are authenticated, but that would require some
explicit study.
-- Christian Huitema
On 6/19/2024 1:40 PM, Stephen Farrell wrote:
Hi Jeff,
On 19/06/2024 18:39, Jeffrey Haas wrote:
[External Email] This email originated outside of Trinity College
Dublin. Do not click links or open attachments unless you recognise
the sender and know the content is safe.
Stephen,
Thanks for your review.
On Jun 17, 2024, at 9:54 AM, Stephen Farrell via Datatracker
<[email protected] <mailto:[email protected]>> wrote:
Generally the idea seems to be to avoid spending CPU on hashing
except for cases where the
state changes, and with periodic checks that BFD auth is still
working. That seems like an
ok idea to me, given the kinds of authentication that are defined for
BFD.
- For security reviewers, it'd be great if there were a reference to
something that sets out
the performance requirements for BFD, and justifies the claims that
hashing is such a
burden. That's counterintuitive for people (like me) who consider
hashing as fast. (And
md5 as broken, but that's a different matter:-) That text probably
shouldn't be here but
it'd be good if there were a reference to it in most BFD security
consdiderations sections.
The analysis you're looking for is somewhat covered under RFC 7492,
which was done as part of the KARP Working Group tasks. Due to that
specific focus, while still a valuable document, we've generally not
cited it as a primary reference.
Yeah, it's useful but not the kind of thing I meant.
The property you're bothered by is that these "cheap" hashes, when
done for a modest to large number of BFD sessions on a linecard that
is otherwise wanting that CPU for other useful work related to
forwarding is an attack against the linecard doing its actual job.
So, there's a need to balance the costs of strong enough
authentication for a BFD scaled scenario vs. the utility that the
authentication brings.
Right, I think your/the draft's case would be much improved if
some such measurements were added or referenced that demonstrated
the problem in a convincing manner.
It's worth noting that section 6 of RFC 7492 notes "hallway
conversation" that this optimization draft is addressing. :-)
Well, it's not quite been a decade since that RFC was published;-)
- I wondered if the "optimized" terminology is best - say if someone
figures out some new
way to optimise things using a different mechanism (e.g. some new way
of amortising the cost
of hashing over more packets, or multiple links or something),
wouldn't this terminology
then be a bit of a pain? Maybe it'd be better to name this as as a
periodic or selective
authentication mechanism or something?
While I agree with and am sympathetic to this point, it'd take strong
Working Group consensus to change the name.
That's fine.
I like "selective authentication".
The issue you note is the usual caveat at naming a thing that may have
a followup. How many "next generation" technologies got the next-next?
Note that the following comments are contained in an upcoming pull
request in the github repo for this document:
https://github.com/bfd-wg/optimized-auth/tree/jhaas/17-comments
<https://github.com/bfd-wg/optimized-auth/tree/jhaas/17-comments>
- The description in the yang text of the retry-interval seemed odd
to me. It says "interval
of time after which a strong authentication should be enabled..." but
should that be more
like "re-tried" rather than "enabled"?
How about:
+ "Interval of time after which strong authentication
+ should be utilized to prevent an on-path-attacker attack.
?
That still seems to have sorta the same issue, how about:
Interval of time after which strong authentication must be
re-enabled for a number of packets as defined above.
- The security considerations says "If this interval is set very low,
or very high, then it
will make optimization worthless." It might be worth stating that a
very high interval value
would allow an attacker that much time to muck about (with whatever
attack they're trying),
but I don't have a concrete attack in mind, so feel free to ignore this.
How about:
If this interval is
+ set very low, the utility of these optimization procedures are
+ lessened. If this interval is set very high, attacks detected
+ by the strong authentication mechanisms may happen overly
+ late.
WFM
Cheers,
S.
- looks like a typo in section 4: " there is problems" maybe "there
are problems"?
Fixed, thanks.
-- Jeff
_______________________________________________
secdir mailing list -- [email protected]
To unsubscribe send an email to [email protected]
wiki: https://wiki.ietf.org/group/secdir/SecDirReview
