Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt

Alan DeKok <> Tue, 16 January 2024 00:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ECBB7C14F682; Mon, 15 Jan 2024 16:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xoanykGZ7igQ; Mon, 15 Jan 2024 16:25:19 -0800 (PST)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 6D3F2C14F68C; Mon, 15 Jan 2024 16:25:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id 2666A1D1; Tue, 16 Jan 2024 00:25:13 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Subject: Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt
From: Alan DeKok <>
In-Reply-To: <>
Date: Mon, 15 Jan 2024 19:25:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Jeffrey Haas <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jan 2024 00:25:21 -0000

On Jan 15, 2024, at 6:22 PM, Jeffrey Haas <> wrote:
> Authors,
> Feedback on version -12:

  Thanks.  I'll check these and hopefully push a PR tomorrow.  I just want to comment on one suggestion below.

> RFC 5880 defines 
> :    bfd.XmitAuthSeq
> : 
> :       A 32-bit unsigned integer containing the next sequence number for
> :       Keyed MD5 or SHA1 Authentication to be transmitted.  This variable
> :       MUST be initialized to a random 32-bit value.
> Thus, the intention is that we start with a random value.


> If the session is Up with one of the existing types with a known sequence
> number, and then we switch to Meticulous Keyed ISAAC, what is likely
> happening is:
> 1. We learn the Seed for this session for the first time.  This somewhat
> argues we need a bfd.MetKeyIsaacKnown variable.  We require it to not
> change.  Note that it's critical that we say that we're setting it only
> after ISAAC authentication has succeeded.

  That makes sense.

> 2. We need to generate the ISAAC table from the existing sequence number.
> It can't simply be sequence 0 because that's attackable.

  Section 5.1 defines how ISAAC is seeded.  It doesn't use sequence numbers to generate the information.

  More below.

> 3. Since we can't set it to zero, and we don't want to generate all
> intervening ISAAC pages to "catch up" to our random sequence number we
> started with,

  But we don't need to "catch up".   We just need to record that we started at an agreed-upon sequence number.

The important bit is that we have a transition from




  When that transition happens, the sequence number in the packet is used as the start point.  That number is the new bfd.MetKeyIsaacPageBase variable you mentioned.

  Saving that number means that if we get a new sequence number Y, we can do:

	Auth Key index = Y - bfd.MetKeyIsaacPageBase

  If that value is smaller than 256, the sequence number is in the current page.  If it's 256 or more, then we need to generate a new page.

  I'll add some text to clarify this.

  Alan DeKok.