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

Alan DeKok <aland@deployingradius.com> Tue, 16 January 2024 16:48 UTC

Return-Path: <aland@deployingradius.com>
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 1F230C14F713; Tue, 16 Jan 2024 08:48:04 -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, 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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8Vy08s5PqA4; Tue, 16 Jan 2024 08:48:02 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 8CA59C14F610; Tue, 16 Jan 2024 08:47:59 -0800 (PST)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id B0EF54DD; Tue, 16 Jan 2024 16:47:56 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: Comments on draft-ietf-bfd-secure-sequence-numbers-12.txt
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <EF836FF4-708A-4985-8FD1-56CD4EC4943E@pfrc.org>
Date: Tue, 16 Jan 2024 11:47:54 -0500
Cc: rtg-bfd@ietf.org, draft-ietf-bfd-secure-sequence-numbers@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <422E5293-1B87-415E-A49C-F5940DFF01A4@deployingradius.com>
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>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/RlAahfYhpXCDOSHAN4JgoudSOos>
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: Tue, 16 Jan 2024 16:48:04 -0000

On Jan 16, 2024, at 11:28 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> We're in agreement.

  <whew>

> There is one additional corner case to deal with.  Here's the scenario:

  ... lost packets ...

> Option 2:
> Each side changing to ISAAC authentication knows that lost packets could be a problem.  The draft says the window we need to keep around is 3*Detect Mult as part of our receive procedures.  Ergo, as long as the side transitioning into ISAAC does so only at a sequence number such that it is within the 3*Detect Mult window, it's reasonable to expect that at least ONE of the packets is expected to get through to the remote side.

  Yes.  The nice thing is we know how many packets we lost.  So if we have:

bfd.AuthSeqKnown = 1, which means:

bfd.RcvAuthSeq is also known

  And then when we receive a packet which suddenly contains ISAAC, we have a "packet.AuthSeq" which is the sequence number in the received packet.

  The difference between packet.AuthSeq and bfd.RcvAuthSeq is the number of "lost" packets.  We can then generate the first ISAAC page, and then simply run through the generated keys 0..255, finding one which matches.

  Once we've found a matching key, we know it's index.  And we know the sequence number of the packet which was lost.  That sequence number becomes bfd.MetKeyIsaacPageBase, and everything proceeds as if there were no packets lost.

> Side observation1: I no longer remember why RFC 5880 chose the 3* multiplier.
> 
> Side observation 2: The Detect Mult itself can go up to 255.  This pathologically means the session may stay up under hefty packet loss and the best we can do is do the switch starting at index 0 of a new page and hope that we sync up.

  I think it's best to point this out, and demand that for ISAAC, the number of lost packets must always be less than 256.

> Another point likely in need of text in the draft is what ISAAC needs to have done when switching from ISAAC back to strong authentication.  Since the sequence numbers are kept going regardless of the authentication mechanism, ISAAC will need to produce new pages when it flips to strong authentication.  This is to avoid needing to "fast forward" if strong authentication is left going for a while.

  Hmm... yes.  I would suggest also that the use of strong authentication should only be for:

1) state transitions, in which case we toss all existing ISAAC information.  We can generate a new ISAAC seed when the state transitions from down->up again

2) we want to send an "up" packet with stronger authentication.  In that case, there are few reasons to send many packets.  Just send one, and swap back to ISAAC.

  I'm working on updated text, and hope to have a PR out later today.

  Alan DeKok.