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

[Christian Huitema <[e-mail]>]

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 
>> <[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
>>
> 
> _______________________________________________
> secdir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> wiki: https://wiki.ietf.org/group/secdir/SecDirReview