Re: draft-ietf-bfd-optimizing-authentication-13 nits

Jeffrey Haas <jhaas@pfrc.org> Mon, 22 January 2024 22:20 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 EF420C14CE2C; Mon, 22 Jan 2024 14:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Kj9g38-jOP14; Mon, 22 Jan 2024 14:20:53 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 284F5C16A126; Mon, 22 Jan 2024 14:20:47 -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 DF1921E039; Mon, 22 Jan 2024 17:20:46 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7B998D48-35A1-46E0-87E5-50FB7FDB0E5D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Subject: Re: draft-ietf-bfd-optimizing-authentication-13 nits
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <478E63ED-1784-4522-96A8-6813A2028F40@gmail.com>
Date: Mon, 22 Jan 2024 17:20:45 -0500
Cc: draft-ietf-bfd-optimizing-authentication@ietf.org, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, Manav Bhatia <manavbhatia@gmail.com>, Ashesh Mishra <mishra.ashesh@gmail.com>
Message-Id: <3B169E77-D0E6-4282-9F74-5ED9E0CB45CF@pfrc.org>
References: <4F3695C8-3736-4E55-B5BB-84671FDC367E@pfrc.org> <A8D0BCD4-15FA-4061-A7F0-6D888158F5A3@gmail.com> <D3DB82BE-730A-4D7C-88B8-3B309C5AC3B9@pfrc.org> <9CDB2C7B-BAB6-476C-9F12-BFA7EAD6DD60@gmail.com> <478E63ED-1784-4522-96A8-6813A2028F40@gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/8UtTElaYE2kNJ0GrPq6MEfUjl_E>
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: Mon, 22 Jan 2024 22:20:58 -0000

Mahesh,


> On Jan 22, 2024, at 5:15 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> 
>> On Jan 19, 2024, at 4:14 PM, Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>> At the same time, if 'secure-seq-num' is configured as ’true’, the sequence number is generated as defined by I-D.ietf-bfd-secure-sequence-numbers, and inserted into the packet. The only question I ask is, if “optimized auth” is enabled, and when there is a state transition, the packet is “fully” authenticated by selecting bfd.AuthType as one of the non-zero values (but not NULL-auth). Do we need to generate a secure sequence number at that time? Or is it easier/simpler to let it continue generating the secure sequence number, and not deal with “lost” packets as the session transitions from bfd.AuthType with a non-zero value and NULL-auth.
> 
> Want to make sure that this is clear enough (here), and if you think text to that effect should be added to the draft.

I'm not really looking for text that says the procedure sets specific bfd variables in order to say what is going on the wire.

However, what's needed is discussing that we're switching from a primary configuration for authentication with "strong" properties to a "weaker" one for the optimization.  We also need to discuss that for certain "weaker" authentications, like NULL, we may need to periodically do the strong authentication to ensure we haven't been MITMed.

And for that periodic strong auth check, what's the configuration element and what's the recommended time to do it?  For example, a few times an hour?  I suspect we'll pick a value and it'll immediately get hate mail from the security directorate no matter what so my recommendation is to pick something the authors think is reasonable and we'll iterate that conversational point in that thread.

-- Jeff