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

Jeffrey Haas <jhaas@pfrc.org> Wed, 17 January 2024 16:13 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 4DE30C14CEE4; Wed, 17 Jan 2024 08:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 TyL8dR09MtNO; Wed, 17 Jan 2024 08:13:33 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4626FC14F74E; Wed, 17 Jan 2024 08:13:32 -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 18D981E039; Wed, 17 Jan 2024 11:13:32 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_94983AA1-00F3-4D39-B692-A2ACB275F08A"
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: <73FFF609-0CA3-411E-A68F-B4EAA9A4E18C@deployingradius.com>
Date: Wed, 17 Jan 2024 11:13:31 -0500
Cc: rtg-bfd WG <rtg-bfd@ietf.org>, draft-ietf-bfd-secure-sequence-numbers@ietf.org
Message-Id: <4DC28E28-BF45-495B-AE0F-1A110F5B8E94@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>
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/FB7pg8vm1rvkscYcrFzv0bvByWY>
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:13:36 -0000

Alan,

> On Jan 17, 2024, at 10:18 AM, Alan DeKok <aland@deployingradius.com> wrote:
> 
>  OK, I've pushed my latest set of changes which address all open concerns.

In that push:

+      <t>It is RECOMMENDED that implementations periodically use a
+      strong Auth Type for packets which maintain the session in an Up
+      state.  We offer no advice here as to how often that signalling
+      should be done.  From a practical point of view, if both parties
+      are using Meticulous Keyed ISAAC and the stream of pseudo-random
+      numbers continues to be correct, then the link must be up, and
+      the other party must be authentic.  The rest of the BFD packet
+      contents then serve to maintain the BFD state machine, which is
+      external to the ISAAC authentication.</t>
+
+      <t>When a system switches from using Meticulous Keyed ISAAC to a
+      different Auth Type method during a session, it MUST do so only
+      for a small number of packets.  It is RECOMMENDED that only one
+      such packet is sent, and the system can then switch back to
+      using Meticulous Keyed ISAAC on the next packet which signals
+      that the session remains in the Up state.</t>
+
+      <t>The nature of the Meticulous Keyed ISAAC method means that
+      there is no issue with this switch.  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>

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.

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.

-- Jeff