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 anok 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 selectiveauthentication 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 morelike "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
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
