Attacking BFD with NULL auth

Jeffrey Haas <jhaas@pfrc.org> Tue, 06 February 2024 13:56 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 920D6C14F721 for <rtg-bfd@ietfa.amsl.com>; Tue, 6 Feb 2024 05:56:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tFHIT7RwDhP6 for <rtg-bfd@ietfa.amsl.com>; Tue, 6 Feb 2024 05:56:37 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 69D8BC14F70F for <rtg-bfd@ietf.org>; Tue, 6 Feb 2024 05:56:37 -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 BCC501E039; Tue, 6 Feb 2024 08:56:36 -0500 (EST)
From: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Date: Tue, 06 Feb 2024 08:56:36 -0500
Subject: Attacking BFD with NULL auth
Message-Id: <336054A1-4729-446B-BE73-832650B75BED@pfrc.org>
To: "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/dww_bSJXp3dWnqAxkKU2XqjFzYg>
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: Tue, 06 Feb 2024 13:56:39 -0000

My thought over first cup of caffeine for the morning: You can have an active attacker attack a session using NULL auth and knock over a BFD session.  This is counter to the usual "silly" attack of keeping BFD Up.

Presume the session is in the Up state between A and B and using NULL auth.  The current expected sequence number at A from B is 100.

An active attacker, seeing that 100 is the sequence number, spoofs packets rapidly in order 101..200.

Sequence number procedures are, tersely, "accept the larger sequence number as long as it's bigger".  Presume that some portion of that spray of packets gets through and moves the sequence number > 100 + 3 before B would have sent sequence 101.

B then continues happily sending the meticulously increasing packets, 101, 102, 103.  These packets are discarded because the sequence number is under the "last seen" sequence number.

The session drops.

I don't believe there is any mitigation against this attack in NULL auth.

The impacts of this, if so:
1. NULL auth and using the sequence numbers becomes impractical to use for optimizing authentication procedures.  ISAAC and no-auth still work.  
2. BFD stability really wants that increasing sequence number.  This leads to using either meticulous types from the strong authentication mechanisms, or ISAAC.

Counter observation 1: Stability doesn't really care about the sequence numbers from a security standpoint, just a dropped packet standpoint.  The attack against stability if the sequence numbers aren't used for authentication of the session to drop the session is to trigger an "unstable" event and whatever trigger might be tied to that mechanism as a client.

Counter observation 2: If the sequence numbers are ignored as a mechanism for taking the session down, you can't use it to prevent PITM attacks, but it's no worse than no-auth.  The periodic strong authentication becomes more important.


-- Jeff