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

[Stephen Farrell <[e-mail]>]

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 
> <[e-mail] <mailto:[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.

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
>