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

Greg Mirsky <> Fri, 14 April 2023 23:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E7E1C1516E9; Fri, 14 Apr 2023 16:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0gh8RI7o7PkK; Fri, 14 Apr 2023 16:05:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::112f]) (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 (Postfix) with ESMTPS id AB85AC14CF1F; Fri, 14 Apr 2023 16:05:26 -0700 (PDT)
Received: by with SMTP id 00721157ae682-54fa9da5e5bso169234787b3.1; Fri, 14 Apr 2023 16:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1681513526; x=1684105526; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Qz/RhHSK45p47DKa1ufwzUE6BjHZixeMKxj8/5+pCl4=; b=eDBM9z6J9gVTzQMmNet4WIIkB5M9nYL+lsp71km12jFKf5k2wQjYtRGnc8icM8xRdl cFtGP3r2Pj3oNDONpo8R+7Lq/h50Q3eoSrGUtfTVua1KJpHv1xBQ4VYbymN5r2ciKVTR aLj31oXUMVmSMRtubNFcBEMuQ6gTn1JOxWna9J+m0MsXzAtZGf0TQYZqyrPyBqsUzhz5 0dlAlt8yfcT6blyuls6gvYYb0Hanxz97jBzYNxv3+28vhOpGaG2ZsUq8Uf4ml+jNC5fO FCscDU3cXRPTKKMzfYw9mJmd7WZM0380pjfa4Xum8T3kFHALDU6d9jJoSfKYiZoepCHI dqyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1681513526; x=1684105526; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qz/RhHSK45p47DKa1ufwzUE6BjHZixeMKxj8/5+pCl4=; b=fzYvG6NsgaRjMCMZamXiJqy11YFgKRp6vUbYl/f6odTg23WLOTzflNPounsZJQCbGS YBiNTnvWwPir6GJAgRapTwoyLQKcJkYdecYy9vIubjvAWVN5cODgjT0jLcSQ07Crrx7u V6vxmBB8gp4xQ3dAXJg0dKKU+Pgyz+qI41j9ldEY6eVLcMlVTv+X1+bvIp1vqN89xUa2 w2u5lZGTugXdbvVKXdivoAYcPPgxefGznJGdyN266Y3To7RW2CMMvXGeaMMQxrM9dCdV 2UUcF2yFCy2fMZW/5OFeD//mAw3sBjbVqBcTRo+UMFeyklA55pRID0SCKVrr2dfy6yNF zxGw==
X-Gm-Message-State: AAQBX9c8z69SKzrCJS35O+fnjWUvueESDSdbQj1HOonDIzKvCxtvv1IZ dBIwT5FeeAMXzh/ztY5ARyiYTEqLhnit4x+ymPhK7X6aivc=
X-Google-Smtp-Source: AKy350ZO+Pz5T4gtk1uBSvgygb9GoENyiTTNI/GPHx1L8qo1Ghlki+R850h6CYxxZb2/FBYn758kUXR4B3Y2Eo59iyE=
X-Received: by 2002:a81:9846:0:b0:544:bbd2:74be with SMTP id p67-20020a819846000000b00544bbd274bemr8544240ywg.4.1681513525712; Fri, 14 Apr 2023 16:05:25 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Fri, 14 Apr 2023 16:05:14 -0700
Message-ID: <>
Subject: Re: draft-ietf-bfd-unaffiliated-echo WGLC and IPR check
To: Jeffrey Haas <>
Cc:, rtg-bfd WG <>
Content-Type: multipart/alternative; boundary="000000000000629bab05f953e05f"
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 23:05:27 -0000

Hi Jeff,
I am not trying to stop this work but understand what is being standardized
by this document. So far, I don't see that there's anything that goes
outside of the BFD system that transmits self-addressed IP/UDP packets. The
fact that there are implementations using self-addressed IP/UDP packets
seems like a weak argument for standardization, especially since there's no
interoperability among network systems to be defined. Of course, that is my
personal opinion.
Also, a note in-line below under the GIM>> tag.


On Fri, Apr 14, 2023 at 3:31 PM Jeffrey Haas <> wrote:

> Greg,
> > 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.
GIM>> My understanding of the draft in regard to the use of the
Discriminator (I assume My Discriminator) field is different. Although the
draft refers to the Discriminators as "demultiplexing fields":
   Once a BFD Unaffiliated Echo session is created on device A, it
   starts sending BFD Unaffiliated Echo packets, which MUST include BFD
   Unaffiliated Echo session demultiplexing fields, such as BFD "Your
   Discriminator" and/or "My Discriminator" defined in [RFC5880].
it later states that demultiplexing is done based on IP and UDP
   Device A performs its initial demultiplexing of a BFD Unaffiliated
   Echo session using the source IP address or UDP source port.
Am I missing something?

> > 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