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

Alan DeKok <> Wed, 17 January 2024 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BF89C14F602; Wed, 17 Jan 2024 08:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 o_ckwdRt5ISC; Wed, 17 Jan 2024 08:19:20 -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 F3993C14F5E4; Wed, 17 Jan 2024 08:19:18 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPSA id E219B4DD; Wed, 17 Jan 2024 16:19:15 +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 11:19:14 -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 16:19:21 -0000

On Jan 17, 2024, at 11:13 AM, Jeffrey Haas <> wrote:
> I'd recommend this specific text be dropped from the secure sequence number document.  The expected procedure for doing the periodic stronger authentication is part of the optimizing BFD text.

  Sure.  My concern is that this document should define how to use ISAAC in that process.

> The test present currently in draft-ietf-bfd-optimizing-authentication-13 is:
> "Most packets transmitted on a BFD session are BFD UP packets. Authenticating a small subset of these packets, for example, a detect multiplier number of packets per configured interval, significantly reduces the computational demand for the system while maintaining security of the session across the configured interval. A minimum of Detect Multiplier packets MUST be transmitted per configured interval. This ensures that the BFD session should see at least one authenticated packet during that interval."
> If you must have anything in the secure-sequence draft, I suggest no more than:
> "It is RECOMMENDED that implementations periodically use a strong Auth Type for packets which maintain the session in an Up state.  See [optimizing-bfd] for appropriate procedures."
> Any tweaks to the procedure can be discussed in the context of that document, which will handle not only secure-sequence, but NULL and future options.


  Perhaps then this text.  Which both refers to the other draft, and then also says how such a switch impacts ISAAC.

      <t>It is RECOMMENDED that implementations periodically use a
      strong Auth Type for packets which maintain the session in an Up
      state.  See <xref
      Authentication</xref> for appropriate procedures.</t>

      <t>The nature of the Meticulous Keyed ISAAC method means that
      there is no issue with this switch, so long as it is for a small
      number of packets.  From the point of view of the Meticulous
      Keyed ISAAC state machine, this switch can be handled similarly
      to a lost packet.  The state machine simply notices that instead
      of Sequence Number value being one more than the last value used
      for ISAAC, it is larger by two.  The ISAAC state machine then
      calculates the index into the current "page", and uses the found
      number to validate (or send) the Auth Key.</t>