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
<[email protected]> 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
<[email protected]> wrote:
On Feb 7, 2024, at 12:48 PM, Reshad Rahman <[email protected]> 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
