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

[Greg Mirsky <[e-mail]>]

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.

Regards,
Greg

On Fri, Apr 14, 2023 at 3:31 PM Jeffrey Haas <[e-mail]> wrote:

> Greg,
>
>
> > On Apr 14, 2023, at 6:23 PM, Greg Mirsky <[e-mail]> 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
encapsulation:
   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
>
>