Re: Attacking BFD with NULL auth

Jeffrey Haas <jhaas@pfrc.org> Wed, 07 February 2024 17:59 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8B5C14CF12 for <rtg-bfd@ietfa.amsl.com>; Wed, 7 Feb 2024 09:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHHShMpgD0s9 for <rtg-bfd@ietfa.amsl.com>; Wed, 7 Feb 2024 09:59:13 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 307FAC14CF0D for <rtg-bfd@ietf.org>; Wed, 7 Feb 2024 09:59:13 -0800 (PST)
Received: from smtpclient.apple (172-125-100-52.lightspeed.livnmi.sbcglobal.net [172.125.100.52]) by slice.pfrc.org (Postfix) with ESMTPSA id A3C4C1E039; Wed, 7 Feb 2024 12:59:12 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DBF8C3E6-1AA2-4A95-8562-0BDF1F2C0505"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Subject: Re: Attacking BFD with NULL auth
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <1364271043.3638553.1707328102005@mail.yahoo.com>
Date: Wed, 07 Feb 2024 12:59:12 -0500
Cc: "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>
Message-Id: <FCF00A96-9383-4CD3-90A9-DC90F6706CFF@pfrc.org>
References: <336054A1-4729-446B-BE73-832650B75BED@pfrc.org> <189423773.3335904.1707238309952@mail.yahoo.com> <955C0C79-FCB3-4FFA-AFA9-C43697E08927@pfrc.org> <1060883557.3646248.1707326519734@mail.yahoo.com> <6E4A650D-49BB-4164-83CA-1D02ABA3E6BD@pfrc.org> <1364271043.3638553.1707328102005@mail.yahoo.com>
To: Reshad Rahman <reshad@yahoo.com>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ecut4GVeYeV082P__3S0I3PQ-1I>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Feb 2024 17:59:15 -0000


> On Feb 7, 2024, at 12:48 PM, Reshad Rahman <reshad@yahoo.com> 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