[secdir] Re: Secdir early review of draft-ietf-bfd-optimizing-authentication-16

[Jeffrey Haas <[e-mail]>]

Stephen,

Thanks for your review.

On Jun 17, 2024, at 9:54 AM, Stephen Farrell via Datatracker <[e-mail]> 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.

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.

It's worth noting that section 6 of RFC 7492 notes "hallway conversation" that this optimization draft is addressing. :-)

> 
> - 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.  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.
?

> 
> - 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.

> 
> - looks like a typo in section 4: " there is problems" maybe "there are problems"?

Fixed, thanks.

-- Jeff