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

Jeffrey Haas <jhaas@pfrc.org> Wed, 17 January 2024 16:24 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 24F3FC14CE5D; Wed, 17 Jan 2024 08:24:01 -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 J4VuUrbwE9bg; Wed, 17 Jan 2024 08:24:00 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E955EC14CE54; Wed, 17 Jan 2024 08:23:59 -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 1C8E71E039; Wed, 17 Jan 2024 11:23:59 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Subject: Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <516235FF-363B-41E3-90F3-0386E753160E@deployingradius.com>
Date: Wed, 17 Jan 2024 11:23:58 -0500
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, draft-ietf-bfd-secure-sequence-numbers@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <71FE43BF-20A7-41CA-B2CF-CCF7BC63BF2B@pfrc.org>
References: <170130738712.52125.9313047708000913054@ietfa.amsl.com> <20240115232214.GB20424@pfrc.org> <E718BC59-7496-4E73-A4D9-AA5015DD9449@deployingradius.com> <EF836FF4-708A-4985-8FD1-56CD4EC4943E@pfrc.org> <422E5293-1B87-415E-A49C-F5940DFF01A4@deployingradius.com> <DDE71390-FF3F-4B28-9E06-D5D28973F5AF@pfrc.org> <481615F0-F0B4-432A-8A8B-08DAB8BE5B9D@deployingradius.com> <5B2CABEF-C7AB-4AD1-8B37-11972E4CF8A2@pfrc.org> <73FFF609-0CA3-411E-A68F-B4EAA9A4E18C@deployingradius.com> <4DC28E28-BF45-495B-AE0F-1A110F5B8E94@pfrc.org> <516235FF-363B-41E3-90F3-0386E753160E@deployingradius.com>
To: Alan DeKok <aland@deployingradius.com>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/FTWCElvHG5F9yIXtmLbiHef1D0w>
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, 17 Jan 2024 16:24:01 -0000

Alan,

On Jan 17, 2024, at 11:19 AM, Alan DeKok <aland@deployingradius.com> wrote:
>  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
>      target="I-D.ietf-bfd-optimizing-authentication">BFD
>      Authentication</xref> for appropriate procedures.</t>

This part is good.


>      <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>

The fundamental issue here is that once we've selected a seed, we need to maintain the ISAAC pages vs. the page base we've selected.

As you note above, if we switch out of ISAAC mode for a few packets, this is no different than "lost packets" from the perspective of figuring out what our next page should be.  I.e., we should only need to flip a page or two.

Alternatively, if the ISAAC page is maintained with the sequence number no matter what on the presumption that we will eventually move back to ISAAC, there's no issues.

Noting that we do not have procedure to permit a new seed to be exchanged as the limiting factor causing the above is appropriate justification.

-- Jeff