Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

Jeffrey Haas <jhaas@pfrc.org> Fri, 07 April 2023 17:47 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 9E45FC151B1D for <rtg-bfd@ietfa.amsl.com>; Fri, 7 Apr 2023 10:47:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 24qwcXtqnDMn for <rtg-bfd@ietfa.amsl.com>; Fri, 7 Apr 2023 10:47:50 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AD2BCC14CEFD for <rtg-bfd@ietf.org>; Fri, 7 Apr 2023 10:47:50 -0700 (PDT)
Received: from smtpclient.apple (104-10-90-238.lightspeed.livnmi.sbcglobal.net [104.10.90.238]) by slice.pfrc.org (Postfix) with ESMTPSA id 4EC2C1E037; Fri, 7 Apr 2023 13:47:49 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F9E22B66-17AF-4E82-9F6B-1EDCA561B0F1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CA+RyBmWoPk0Gx2iUn9Vb3s3zDs5HTVp_zk6PcDFFbw0tFhEOzQ@mail.gmail.com>
Date: Fri, 07 Apr 2023 13:47:48 -0400
Cc: rtg-bfd@ietf.org
Message-Id: <AF7BC79C-3BD9-4A1D-99A4-08FC7D4727D0@pfrc.org>
References: <20230321160207.GA7334@pfrc.org> <CA+RyBmXtST1EZcba_RM90NLf5hYAiKL2+XjSZwO2r-d_XNjwqA@mail.gmail.com> <D26572BA-08CE-4D33-ADDD-07033CDAA0E9@pfrc.org> <CA+RyBmWoPk0Gx2iUn9Vb3s3zDs5HTVp_zk6PcDFFbw0tFhEOzQ@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/dbmg2DPhMnVTl79pIue4_EqQvjc>
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: Fri, 07 Apr 2023 17:47:54 -0000

Greg,


> On Apr 7, 2023, at 1:10 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> On Thu, Apr 6, 2023 at 7:36 AM Jeffrey Haas <jhaas@pfrc.org <mailto:jhaas@pfrc.org>> wrote:
> Greg,
> 
> 
>> On Mar 27, 2023, at 1:40 AM, Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote:
>> 
>> Dear Authors,
>> I read the latest version of the draft. I appreciate your work on improving its readability. I have several concerns and appreciate your consideration:
>> It appears like the document defines the format of the Echo message. As I understand the RFC 5880, the format of the Echo message is not specified in the RFC 5880. It seems like by defining the format in this document, you affect RFC 5880 compliance of implementations that do support RFC 5880 as it exists today.
> One way to alternatively view this is we're documenting what one implementation puts in its Echo packets.  This draft does not try to require that all BFD Echo implementations use these procedures.
> GIM>> That is an interesting perspective. If that is the purpose of this specification, then the amount of updates it requires seems excessive. On the other hand, if the group agrees to reflect such intention in the draft, it will alleviate my concern.

The intention for the RFC 5880 changes are to deal with the fact that BFD normally expects to be able to send Echo packets only after a session is Up.  In the case of this document, BFD Async procedures may not happen.

> Furthermore, if that is the position explicitly communicated in the draft, making it Experimental seems like the next logical step. 

I don't think this explicitly follows.

> 
>> The draft, in my opinion, significantly changes the architecture of the BFD, as it is defined in RFC 5880. I believe that characterizing Echo as a function stresses its dependency from a BFD mode, Asynchronous and Demand. The changes proposed in this draft are very extensive and severely affect the existing architecture of BFD by setting the Echo function on par, unrelated with the BFD modes.
> 
> Interesting.  My view has been that this mechanism leverages existing BFD Async procedures to avoid trying to completely invent new mechanisms for the unafilliated case.  Where I might have some level of agreement with your point is this "mode" needs to be clearly defined from a configuration standpoint.  For example, how would it manifest in YANG?
> GIM>> It seems that we have different views. I consider the limitation of using the Echo function, specified in RFC 5880, only after the session reaches the Up state as a part of the BFD security mechanism. Personally, I would encourage not to use a well-known UDP port for the type of operation described in the draft. I think it would be more secure to use a port number from the dynamic range. Defining that function as a new optional BFD function without severely updating RFC 5880, in my opinion, is a safer path.

I must give you the same answer we'd have to give to the security ADs: A form of this feature has been deployed via BBF TR-146 for quite some time, and leverages the BFD Echo port.

At one point, it had been described to me that the motivation for the invention of this feature was that it was trivial to enable in some third party chipsets.  A quick Google brought me to a manual covering some Broadcom chips.  Some of the information in the document is helpful for this discussion:

https://manualzz.com/doc/o/1277tk/broadcom-bcm88690--bcm88800--bcm88480--and-bcm88280-packe...-32.13.5--configuring-bfd-echo

Section 32.13 suggests that dst ip and src ip must be identical and that the service will use udp port 3785.

Particularly interesting:
"The Device OAMP supports transmission BFD Echo frames and processing looped-back Echo frames. BFD Echo frames are generated by the OAMP as BFD Control packets. Upon reception, BFD echo packets are identified at the PMF using a specific rule (based on Your-Discriminator), and are sent to the OAMP for monitoring through trap mechanisms. The OAMP verifies the applicable fields, and monitor reception of the packet to determine LoC."

So, the chipset appears to largely do what we're describing in this document. :-)



> 
>> Also, I think that the normative language in the last paragraph of the Secrity Considerations sections are too soft. Currently used recommendation level, in my opinion, is insufficient and should be brought to the requirement level. I.e., I propose s/RECOMMENDED/MUST/ and s/SHOULD NOT/SHALL NOT/
> 
> I'd recommend that you show the explicit sections you want updated.
> GIM>> Thank you for pointing that out for me. Below are the proposed updates:
> OLD TEXT:
>    In order to mitigate the potential reflector attack by the remote
>    attackers, or infinite loop of the BFD Unaffiliated Echo packets,
>    it's RECOMMENDED to put two requirements, also known as Generalized
>    TTL Security Mechanism (GTSM) [RFC5082], on the device looping BFD
>    Unaffiliated Echo packets, the first one is that a packet SHOULD NOT
>    be looped unless it has a TTL or Hop Limit value of 255, and the
>    second one is that a packet being looped MUST NOT reset the TTL or
>    Hop Limit value to 255, and MUST use a TTL or Hop Limit value of 254.
> NEW TEXT:
>    In order to mitigate the potential reflector attack by the remote
>    attackers, or infinite loop of the BFD Unaffiliated Echo packets,
>    this specification puts two requirements, also known as Generalized
>    TTL Security Mechanism (GTSM) [RFC5082], on the device looping BFD
>    Unaffiliated Echo packets, the first one is that a packet MUST NOT
>    be looped unless it has a TTL or Hop Limit value of 255, and the
>    second one is that a packet being looped MUST NOT reset the TTL or
>    Hop Limit value to 255, and MUST use a TTL or Hop Limit value of 254.
> 
> 
>  Using version -06:
> - I would not personally suggest that the RECOMMENDED for authentication turn into a MUST.  BFD Authentication simply isn't used in enough circumstances to try to turn this into the default case, especially when the intent of this feature is to deal with systems that don't have a matching BFD on the opposite side.
> - I not super supportive of the SHOULD NOT for the TTL 255 loop being upgraded to SHALL NOT.  This will likely make a number of existing deployments of this feature non-conformant.

Thanks for the specific text.  As noted in my last point above, I believe this will likely render existing implementations non-conformant.

Your concern here is acknowledged.

See my other comment immediately below. :-)

> 
> Please note that I expect to have a repeat of this conversation with the security AD during review.  So, your comments are apropos.
> 
> -- Jeff
>