Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check

Jeffrey Haas <> Fri, 14 April 2023 22:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06F74C14CE40; Fri, 14 Apr 2023 15:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7dnJQiWimwHS; Fri, 14 Apr 2023 15:31:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5E0D1C14CF1A; Fri, 14 Apr 2023 15:31:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 269931E037; Fri, 14 Apr 2023 18:31:47 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
From: Jeffrey Haas <>
In-Reply-To: <>
Date: Fri, 14 Apr 2023 18:31:46 -0400
Cc:, rtg-bfd WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Greg Mirsky <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Apr 2023 22:31:50 -0000


> On Apr 14, 2023, at 6:23 PM, Greg Mirsky <> wrote:
> Hi Jeff,
> thank you for your kind consideration of the proposal. Indeed, leaving a chunk of memory unchanged is a privacy issue. As I understand the proposal, none of the fields defined in RFC 5880 for the BFD Control message is used for demultiplexing BFD sessions and/or packet validation. Is that correct?

The Discriminator field is used for demux.  Authentication is utilized, if present.

> If that is the case, what is the need to use the BFD Control message altogether? And one more step, What is the benefit of using a well-known BFD Echo UDP port number? I believe that using a well-known port increases the security risk rather than bringing any benefits. From what I understand in the application of the mechanism, the sender can use a UDP port number assigned from the dynamic/private range of port numbers. And the payload can be anything, i.e., filled with bit pattern randomly chosen by the Sender. Am I missing something?

Please note you're trying to fight up the slope of the mountain.  This feature exists and has long been shipping in various forms already.  Our goal here is to try to take the less precise descriptions of the feature and apply some IETF rigor to it.  Thanks for helping with that effort.

Recall that the point is that using the BFD echo port in packet loopback mode and sending BFD Async packets within it is largely "talking to yourself".  The device running this proposal is still running BFD, using as much of the BFD Async machinery as makes sense in the mode.  The time fields are, as you note, useless.  However, the authentication, discriminator fields let an implementation still do demux and authentication without having to write new code.

BFD Echo mode was intentionally underspecified to allow implementations to decide what they're going to put in the packets.  Implementation considerations of BFD Echo have always had the concerns for:
- Is this packet actually sourced by the implementation
- Is spoofing happening
- How do you handle demux when there might be multiple sessions?

The fact that this information is part of the BFD control messages has clearly been a convenience to multiple implementations of Echo.

This document simply formalizes one flavor of it.

-- Jeff