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

Mahesh Jethanandani <mjethanandani@gmail.com> Sat, 20 January 2024 00:14 UTC

Return-Path: <mjethanandani@gmail.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 2B57EC14F6EF; Fri, 19 Jan 2024 16:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Rstryv1ITDOE; Fri, 19 Jan 2024 16:14:41 -0800 (PST)
Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 CC323C14F6B5; Fri, 19 Jan 2024 16:14:41 -0800 (PST)
Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-1d70b0e521eso10306195ad.1; Fri, 19 Jan 2024 16:14:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705709681; x=1706314481; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=ZD3UL1hTv/4nDY2fHicI1+yrx8xHLDyO0uE1OLa9exI=; b=lhuamn6UpUjM1QfiGC8GSpSAjB548+hJhPpC2M6A7Gq/Pxa3vpaF1jpRhedzSG4J2u mfeX6uTowzAwykNCCQBBAC+LH0KaeD0N0p3ahQsIB+78bOXQ0yHPp3j6VF/V2MH91hU5 DK4g2Qto4/ntlK+AEmU/NeOrhAYwBwNeu0FrzRpd879uw37gIyeLyL9rA+Kp5zUmVzGj 6ZkrM+5nIIE6+6iSaRB13Y/i1HGoOwN6cw514BsC+f89eJEatZKUExcpy+n7PXpPtW4J MbHWGQzyly4khvdJ/hbB2ZaSoSsa/zsw32B32C6bKCUX0JHjLiBEOYoucCy+QfpnUlZ9 H6Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705709681; x=1706314481; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZD3UL1hTv/4nDY2fHicI1+yrx8xHLDyO0uE1OLa9exI=; b=oBrga5+IAm2zHwwiyFuTMaodCAvZej2PK41J0Y7a9vNDV8LkDplQ3U15wOwtyxC+5q dKR78FcnR1k+xYQALcRSQEGe2nqwLFTTIcuevDoisLr7YA+c0NdwxUXZ10lTSdjxQ/uu hwovrfFxVJuxHL3GBNFmBCDZ1GaBKAb5QaZKVZl8tyBRhF/sTK3Av9q2SyqPtcWqEqOS z7EluEEu1TBY67aE5zc12ZSjQG5mN1Q0vExoy1K+TRBAnbh6vpaYEshUDdAusx4E1fqM LjAo49dASX37w0DzeuDHgJ75d7dCYhQDPC8dL1bhITmeN2I+Q+wMBq6C5JseogOtHmha b0Zg==
X-Gm-Message-State: AOJu0YwTlz0E3sXF1fSeYCb9XdKeb47bIHiiAVrW4881olTKwh0gsDM5 0A6GzU3aEBVhElKV1/wSG1YNjwvlcdrZxfnjyOdMfZIVFPccprbe
X-Google-Smtp-Source: AGHT+IGhvV2gW/1vukZvWOBvVbX49bUsM3f4u3c/kEX+ClOXELec91xumCxFxSOz8GM6OylUWd7lbQ==
X-Received: by 2002:a17:902:f54a:b0:1d5:f223:a27a with SMTP id h10-20020a170902f54a00b001d5f223a27amr911797plf.39.1705709680745; Fri, 19 Jan 2024 16:14:40 -0800 (PST)
Received: from smtpclient.apple (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id q12-20020a170902c9cc00b001d7267934c7sm1139840pld.298.2024.01.19.16.14.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2024 16:14:38 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <9CDB2C7B-BAB6-476C-9F12-BFA7EAD6DD60@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_865B7135-E162-4848-B0B3-AA8FC6260544"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Subject: Re: draft-ietf-bfd-optimizing-authentication-13 nits
Date: Fri, 19 Jan 2024 16:14:36 -0800
In-Reply-To: <D3DB82BE-730A-4D7C-88B8-3B309C5AC3B9@pfrc.org>
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>
To: Jeffrey Haas <jhaas@pfrc.org>
References: <4F3695C8-3736-4E55-B5BB-84671FDC367E@pfrc.org> <A8D0BCD4-15FA-4061-A7F0-6D888158F5A3@gmail.com> <D3DB82BE-730A-4D7C-88B8-3B309C5AC3B9@pfrc.org>
X-Mailer: Apple Mail (2.3696.120.41.1.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/QJgJSDp3cTs3BA-eUVq8oN67eJQ>
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: Sat, 20 Jan 2024 00:14:46 -0000

Hi Jeff,

> On Jan 19, 2024, at 4:19 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> 
> 
> 
>> On Jan 18, 2024, at 7:26 PM, Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>>> On Jan 17, 2024, at 5:05 PM, Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> wrote:
>> That is a good point. However, and thinking of this from a management perspective, the operator can signal a they want optimized auth. It will up to the implementation to update the bfd.AuthType field as it toggles through the different authentication types. For example, if optimized-auth is set to true, the session could start with no auth, transition to bfd.AuthType=5 as the session is coming up, and then transition to bfd.AuthType=0 after it has reached UP state. 
>> 
>> Orthogonally, the operator can indicate whether they want to secure the sequence numbers that are included in the BFD packet. It will be up to implementation to decide whether they want to use it when bfd.AuthType is set to a non-zero value, or only use it when bfd.AuthType is set to 0.
>> 
>> In summary, two new leafs in the YANG model, one boolean leaf for “optimized-auth” and one boolean leaf for “secure-seq-num”.
>> 
>> If this sounds kosher, I will add text to that effect in the draft.
> 
> At the moment, the keychain model is being used for BFD authentication.  It has provision for one key set.
> 
> Adding new leaves (in a container?) for optimized-auth is one way to do it.  Having a mode for the optimized auth in a choice for NULL-auth or secure-seq-number would do the trick.  There's probably a must condition for setting this mode vs. authentication otherwise being set?

I think I see where the confusion could be.

In my mind, and my co-authors can correct me if my understanding is incorrect, I do not see "optimized auth" as a choice between "NULL-auth" and "secure-sequence" numbers. When the A-bit is set, the choice is between doing authentication as described in RFC 5880 (bfd.AuthType=[1..5]), or doing "optimized auth". If "optimized auth" is chosen, bfd.AuthType can toggle from one of the non-zero values to NULL-auth (whatever non-zero value is assigned to it) and back.

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.

> 
> Interesting edge choice question: Alan's recent changes permits even "simple password" to be a valid mode, but it's probably not something we want to operationally support.  In particular, because it does NOT include sequence numbers and thus provides zero protection vs. reply during the non-optimized path.

Agree. Where do we call this out? In this or in the secure-sequence-number draft?

> 
>>> "configured interval" probably needs to be more specific to this mechanism.  In particular, this is the interval for how long before we retry strong authentication.
>> 
>> There is no “strong” vs “weak” authentication, unless I am missing something.
>> 
>> I have rephrased it to:
>> 
>> “ Interval at which BFD control packets are retried for authentication”
> 
> The tone of language I'm suggesting we find wording for is the non-optimized authentication vs. the optimized.  Optimized will currently consist of NULL and secure-seq-number.
> 
> Both of those new types are authentication.  See below.

Ahh! I see. How about

“Interval at which BFD control packets are retried with strong authentication” or
“interval at which BFD control packets are retried with non-optimized authentication”?

> 
>>> 
>>> 2. Authentication Mode:
>>> 
>>> The text in this section indicates that there are circumstances where no authentication (a-bit is off) is permissible.  However, the text then moves to discuss NULL authentication, which is authentication that still carries an a-bit, and has contents. This is likely from earlier work prior to realizing we want some form of anti-replay attack.
>>> 
>>> I suspect the correct thing to do here is move all text toward discussing the "non-authenticated" mode as the less encumbered authentication, of which this document defines the NULL method. 
>> 
>> Ok. I have changed the text to talk about the value of bfd.AuthType as either a non-zero value or using a zero (NULL) value, even as A-bit is set.
> 
> Note that the "NULL" auth type is likely to be not-zero. :-)  Zero is reserved.

Thanks for correcting that perception. I did think it would be zero, but I can see that it would be NBC change. So a non-zero NULL value 😉.

Thanks.

> 
>>> 3. NULL Auth Type.
>>> 
>>> The main text here in need of updating is the sequence numbers.  As we've worked through in the discussions for secure sequence numbers, we want the sequence numbers to be preserved across authentication mechanisms.
>>> 
>>> Is the answer to take the text we have in secure sequence numbers covering this detail and move them to this document?
>> 
>> Most the text in this document defers to the I-D.ietf-bfd-secure-sequence-numbers draft, and I would not duplicate any text from there in this document.
> 
> Ok, we'll review the documents versus each other once edits are in.
> 
> Thanks!
> 
> -- Jeff
> 


Mahesh Jethanandani
mjethanandani@gmail.com