Re: draft-ietf-bfd-optimizing-authentication (WGLC for the 3 BFD auth documents and IPR check)

Jeffrey Haas <jhaas@pfrc.org> Wed, 19 June 2024 18:51 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 A0DBFC14CE29; Wed, 19 Jun 2024 11:51:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.942
X-Spam-Level:
X-Spam-Status: No, score=-4.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1.955, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 G1T3hrICX4NE; Wed, 19 Jun 2024 11:51:37 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 771E8C14F691; Wed, 19 Jun 2024 11:51:36 -0700 (PDT)
Received: from smtpclient.apple (172-125-100-52.lightspeed.livnmi.sbcglobal.net [172.125.100.52]) by slice.pfrc.org (Postfix) with ESMTPSA id 881971E039; Wed, 19 Jun 2024 14:51:35 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D6E9E31B-E9E3-4399-8588-37FBBA24C683"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: draft-ietf-bfd-optimizing-authentication (WGLC for the 3 BFD auth documents and IPR check)
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <1786682735.2925035.1718248783001@mail.yahoo.com>
Date: Wed, 19 Jun 2024 14:51:34 -0400
Message-Id: <02400F90-1392-4767-BB0D-F97EFDF7EC1E@pfrc.org>
References: <588053236.815879.1717464587414.ref@mail.yahoo.com> <588053236.815879.1717464587414@mail.yahoo.com> <1786682735.2925035.1718248783001@mail.yahoo.com>
To: Reshad Rahman <reshad@yahoo.com>
X-Mailer: Apple Mail (2.3696.120.41.1.8)
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Hits: max-size
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-bfd.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; news-moderation; no-subject; digests; suspicious-header
Message-ID-Hash: KOJJRJZSSQ2DHLZOFFBCBMI43BFVZGRL
X-Message-ID-Hash: KOJJRJZSSQ2DHLZOFFBCBMI43BFVZGRL
X-Mailman-Approved-At: Wed, 19 Jun 2024 11:53:53 -0700
CC: BFD WG <rtg-bfd@ietf.org>, "draft-ietf-bfd-optimizing-authentication@ietf.org" <draft-ietf-bfd-optimizing-authentication@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection" <rtg-bfd.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/9TXTXEiQmUsy73M1Hy64L08vVxg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-bfd-owner@ietf.org>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Subscribe: <mailto:rtg-bfd-join@ietf.org>
List-Unsubscribe: <mailto:rtg-bfd-leave@ietf.org>

Reshad,

The pending changes covered in addressing your comments are currently in this github pull request:
https://github.com/bfd-wg/optimized-auth/pull/46 <https://github.com/bfd-wg/optimized-auth/pull/46>

Details below.


> On Jun 12, 2024, at 11:19 PM, Reshad Rahman <reshad=40yahoo.com@dmarc.ietf.org> wrote:
> 
> Authors, BFD WG,
> 
> Here are my comments on draft-ietf-bfd-optimizing-authentication (hence subject change). I have strived to go back to previous discussions to make sure I'm not reopening any closed issues, but I could have missed some.
> 
> Section 1
> ---------
> 
> - 2nd paragraph "Control packets that do not require a poll sequence, such as bfd.RequiredMinRxInterval...". I think the last part should be "such as a change in bfd.RequiredMinRxInterval..."

Changed.

>  
> - 2nd paragraph, last sentence starting with "In other words": I have a hard time groking the part "...aside from the authentication section without stronger authentication...". I think this is reiterating that if an Up packet changes we need to use stronger authentication, but is there anything else?

There's nothing else.  The intent here is to summarize the key point succinctly.

> 
> - Part which starts with "Once the session has reached the Up state". There is 1 less computationally intensive auth type which is using ISSAC. Then it says that "To detect an on-path attacker" we have 2 options: strong auth or ISAAC. If we were already using ISAAC and we switch to ISAAC, hoes does that help? I am probably missing something. 

This is a lingering issue from when null auth was part of this procedure.

My proposed change is to remove the text about "to detect an on-path attacker", to use the following text instead:

"When using optimized methods of authentication, BFD sessions should periodically test the session using strong authentication. Strong authentication is tested using a Poll sequence. To test strong authentication, a Poll sequence SHOULD be initiated by the sender using the strong authentication Auth Type rather than the chosen optimized Auth Type. If a control packet with the Final (F) bit is not received within the Detect Interval, the session has been compromised, and should be brought down. The interval for initiating a Poll sequence can be configured depending on the capability of the system."

> 
> - "If a Fin is not received" should be "If a control packet with the Final (F) but is not received".

In the diff.

> 
> - Last paragraph, the term "configured interval" here and in 1.3 refers to the "reauth-interval"? Mention that in section 1 and also "configured interval" if used alone is misleading since there are many configured intervals in BFD? Also I don't see the need to have "configured interval" in the terminology section since it's only used once afaik in the document.

I'm proposing this become "configured strong reauthentication interval" to clarify the situation.

> 
> Section 1.3
> -----------
> 
> - Add "Auth Type" to terminology section?

Done.

> 
> Section 2
> ---------
> 
> - Typo: authentiation

Fixed.

> 
> - Figure 1: so we can use OPT if there's no state change even when in INIT or DOWN state? Per section 1, it should only be in UP state?

Oi, that's been in there for a while.  Auth now only in Up/Up states.

The other authors will have to remind me if there was reason we had it in the other states.

> 
> Section 3
> ---------
> 
> - Section 3, first sentence "type supporting Optimized BFD authentication", add a reference to section 6.1.

Done.

> 
> - "Optimized:", mention those are the values of the field with "Values are:" as is typically done.


Now reads:

         The values of the Optimized field are:

> 
> Section 4
> ---------
> 
> - Typo in 3rd paragraph "there is problems"

Fixed.

> 
> Section 5.3 (YANG)
> ------------------
> 
> - It needs to be mentioned explicitly that optimizing authentication is enabled by using 1 of the 2 new crypto-algorithm, it's implied but not clearly spelled out.

I've added:
"Implementations supporting the optimization procedures defined in this document enable optimization by using one of the newly defined key-chain crypto-algorithms defined in this YANG module."

> 
> - Define a grouping for reauth-interval

Done.

> - There's an identity for null-auth but IIRC use of null-auth has been removed from the optimization mechanism a few months ago. can we remove null-auth from this document?

Removed.

Fundamentally the thing we're juggling with the reorgs is to make sure we don't have conflicting updates in the yang modules.  So, we'll be checking this vs. the bfd stability document as well.

> 
> Section 7
> ---------
> 
> - If reauth-interval is set very low, I understand how the optimization is worthless. But why is that the case if reauth-interval is very high, I mean optimization would be great? Do you mean that we'd be insecure if it's too high?

This was addressed as part of the secdir review.  See if the new text addresses your concerns.

> 
> - Some time ago we discussed the impact of enabling optimized authentication and how it could make a session go down. IIRC the mixed (strong + opt) crypto-algorithm was added to mitigate that. Do we need some text in this section or elsewhere to describe that procedure?

I don't think so, but might be convinced otherwise.  The current procedures are "one-stop enable this auth type and you get all of the appropriate things".  Before, it was the weird conflict between which mode was configured and whether there was an optimized flag to turn things on.


> Did we consider putting a session admin-down before enabling/disabling optimized auth?

In the current procedure, it's a single setting to use a pairing of strong/optimized auth in a single type.  This wouldn't be necessary.

More broadly, this also avoids the mid-flight auth changes that RFC 5880 handwaves the complexity for.

> 
> Section 8
> ---------
> 
> Rehman -> Rahman

Fixed.

> 
> Section B.1
> -----------
> 
> - key-chain "bfd-auth-config' is defined but not used in the BFD session authentication section. Sigh, why didn't we put key-chain as mandatory...

Fixed example, and to be audited by Mahesh.  

At least one motivation to not make it mandatory is a lack of clear procedure of "auth is enabled, and that auth is 'off'". :-P

Attached, find the output from iddiff.

-- Jeff