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 <[email protected]> wrote: > Greg, > > > > On Apr 14, 2023, at 6:23 PM, Greg Mirsky <[email protected]> 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 > >
