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

Alan DeKok <> Wed, 17 January 2024 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A988CC14F5E4; Wed, 17 Jan 2024 06:55: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 irphljMD-Rw2; Wed, 17 Jan 2024 06:55: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 C4ED0C14F5E9; Wed, 17 Jan 2024 06:55:13 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPSA id 8C4F24ED; Wed, 17 Jan 2024 14:55:10 +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: Wed, 17 Jan 2024 09:55:09 -0500
Cc: rtg-bfd WG <>,
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: Wed, 17 Jan 2024 14:55:20 -0000

On Jan 17, 2024, at 9:40 AM, Jeffrey Haas <> wrote:
> Effectively, bfd.MetKeyIsaacRcvAuthBase is the sequence number at which ISAAC was first found valid.  This may be a lost packet. Working this into the text may help clarify this scenario for implementors.

  Yes.  I'll add some text.

>>  For now, I've largely reworked the text.  The new text is at:
> Thanks.  These comments are against the current snapshot at that repository.  Note that the repository doesn't currently compile so I'm reviewing this via the .xml.

  My current system doesn't build any XML files, so I'm just hacking the text for content.

> Similar to our prior discussion about determining the first sequence number of synchronizing ISAAC page 0, we can observe that we should only generate the next page of the ISAAC table if the received sequence number is in the expected range for an Up session.  
> This means that on an attack where the attacker is generating a sequence number greater than the actual sequence number, we generate at most the next table, which will eventually be valid for an Up session.  Those invalid packets will not validate, but can at most cause us to do the work "early".

  Yes.  The implementation in the repository does exactly this.

> The related requirement would be that we have the "current" page associated with the most recently valid sequence number, and one possible pending "next" page.

  The nice thing is that the "next" page can be calculated asynchronously.  i.e. outside of the "fast path" for BFD.  If the normal BFD process uses 60 packets per second, we have about 4 seconds to calculate the "next" page.

>       <t>bfd.MetKeyIsaacRcvKeyKnown</t>
>         <li>A boolean value which indicates whether or not the system
>         knows the receive key for the Meticulous Keyed ISAAC Auth Type
>         method.  The initial value is "false".  This value is changed
>         to "true" when a party sees that the other party has started
>         to use the Meticulous Keyed ISAAC Auth Type method.</li>
> I think this changes to true the first time we see an _acceptable_ ISAAC authenticated PDU.  I.e. we're not permitting the local state to be set and spoiled by invalid inputs.

  Yes.  I'll update.

  Alan DeKok.