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

[Stephen Farrell via Datatracker <[e-mail]>]

Reviewer: Stephen Farrell
Review result: Has Nits

This is an "early" secdir review. The document seems to be in WGLC though, so I'm not sure
how early this really is, or how malleable the draft may be. If it's not really that early
that's ok. I'd say you can consider these comments as nits. Please also consider me as a
BFD ignoramous, so I may be off-base in some of the comments below.

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.

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

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

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

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