Re: Attacking BFD with NULL auth

[Reshad Rahman <[e-mail]>]

 Jeff, authors,
If NULL auth cannot be used for opt auth, does it belong in the bfd-stability doc instead? I don't recall if this was brought up.
So looking at the current text in -14:
   Once the session has reached the Up state, the session can choose the
   Auth Type to be one of:
   *  No authentication, i.e., Authentication Present (A-bit) is zero.
      Having no authentication provides computational relief to the
      system.  However, a malicious user can blindly inject traffic that
      will be accepted by the BFD session.
The paragraph above needs to be updated as per Jeff below.
   *  NULL Auth Type (Section 3) as defined in this document.  This type
      prevents blind injection, but is vulnerable to active attacks,
      where the attacker is aware of the sequence number, and
      potentially becomes the PITM.  However, periodic check with
      stronger authentication can thwart that attack as described below.

The paragraph above needs to be removed and we need to mention somewhere why NULL auth cannot be used for opt-auth. 
 * Meticulous Keyed ISAAC authentication as described in Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]. This authentication type prevents the attack when the Up packets do not change, because only the paired devices know the shared secret, key, and sequence number to select the ISAAC result.

Regards,Reshad.
    On Wednesday, February 7, 2024, 05:37:20 PM EST, Reshad Rahman <reshad=[e-mail]> wrote:  
 
  "Thus, if we're in no-auth, injecting anything other than "I'm still up!" gets ignored.  You can keep the session up, but you can't change parameters or take the session down.  State changes require strong auth anyway."

Ah right, I forgot about that. I think the text you're referring might be in section 1 now, at least part of it.
Regards,Reshad.


    On Wednesday, February 7, 2024, 12:59:13 PM EST, Jeffrey Haas <[e-mail]> wrote:  
 
 


On Feb 7, 2024, at 12:48 PM, Reshad Rahman <[e-mail]> wrote:
 Jeff,
"No authentication also thus means you can't attack the system by sending a sequence number".
I agree. But you don't need a seq number with no auth, you just attack by sending a packet to take the session down. That's why I still view NULL auth as (slightly) better than no auth.

I think I see the problem.  At some point in the github merges, we lost text that effectively asserts that in the Up state, you cannot change the BFD control packet contents excluding the auth section without flipping to the strong auth mode.
Basically:If state is Up:    If authentication is Optimized mode:        Validate authentication, if any, and discard on fail.        Validate control packet contents have not changed.  We are still Up and haven't been convinced to change BFD parameters.
Thus, if we're in no-auth, injecting anything other than "I'm still up!" gets ignored.  You can keep the session up, but you can't change parameters or take the session down.  State changes require strong auth anyway.  The clarification is we don't let other parameters get tweaked because portions of the 5880 state machinery didn't require either a state change or a poll sequence to  happen.
I'll open a github issue to track this point.
I see also that we have some zombie text:"Implementations supporting this feature will send BFD packets with authentications that always carry a meticulously increasing sequence number. This meticulously increasing sequence number prevents replay attacks"
Since we're deciding to support no-auth, this sentence is wrong.  I'll pen a second issue.
-- Jeff