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

[Jeffrey Haas <[e-mail]>]

Christian,


> On Jul 1, 2024, at 3:38 PM, Christian Huitema <[e-mail]> wrote:
> 
> 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.

The cluster of the optimizing authentication, "secure sequence numbers", and "stability" drafts have spent time passing ideas back and forth over the years they've been getting worked on.  Stability has been the easiest one to think through since it's always been "just count missing packets".

Originally, null authentication was considered as an option for the optimizing draft in addition to the secure sequence numbers option.  However, when the analysis concluded that NULL authentication could be used as an attack on the session, it was removed. This left only secure sequence numbers as the optimized option.

Very similarly, the original idea of the secure sequence numbers draft had been to use a deterministic but apparently random number sequence to replace the sequence number field in an otherwise "no authentication" BFD session.  In that case, there were two points recognized that caused us to alter the proposal to the current version:
- Getting the ISAAC mechanism into sync so that it was clear how the generated values appropriately aligned was challenging, especially in circumstances where packet drop might be possible.  Fix: Use existing sequence numbers for coordination, make the output of ISAAC the authentication value.
- Toggling between BFD authentication types meant that a possible failure modality was BFD could come up for the strong authentication method and then fail when the optimized algorithm method was used.  Fix: Authentication codes are now the pair of the strong and the optimized algorithm.

Returning to your observation, the "NULL" method has potential to similarly leverage a paired strong/optimized authentication code for periodic authentication... but that doesn't address any of the shorter lived attacks.  More importantly, NULL is intended to be leveraged by operators in the same environment that would otherwise not be provisioning authentication in the first place.  The CPU may simply not be available for any security.  

If you have available CPU, leverage the optimized procedures for your "strong" cipher of choice, including MD5, and ISAAC for the optimized form.  We do say that BFD authentication that protects the session is RECOMMENDED.  The challenge was dealing with the situations where it wasn't practicable.

-- Jeff

> 
> -- Christian Huitema