hi Erik, Thanks for this message, I think we can finally conclude this thread; see in line below. > On 16 Oct 2024, at 20:34, Erik Auerswald <auerswal@xxxxxxxxxxxxxxxxx> wrote: > > Hi Brian, > > On Wed, Oct 16, 2024 at 07:39:15PM +0200, Brian Trammell (IETF) wrote: >>> On 16 Oct 2024, at 18:54, Erik Auerswald <auerswal@xxxxxxxxxxxxxxxxx> wrote: >>> On Wed, Oct 16, 2024 at 12:28:46PM -0400, Jeffrey Haas wrote: >>>>> On Oct 16, 2024, at 1:31 AM, Brian Trammell (IETF) <ietf@xxxxxxxxxxx> wrote: >>>>> >>>>> Thanks for the clarifications. Xiao, please take this reply as a >>>>> reply to your own request for an amendment to this review; tl;dr the >>>>> recommendations to the authors, WG, and IESG change in their details >>>>> but my headline opinion (“Not Ready”) stands until the document >>>>> is revised. >>>> >>>> FWIW, I agree with Xiao that Erik's analysis is well considered. >>>> He saved me from writing a large amount of similar tax, and did so >>>> with less frustrated sarcasm. >>> >>> Thanks, Jeff! >>> >>> I agree with your analysis in this email. I'll trim it from my reply >>> to present an additional viewpoint that I hope is helpful: >>> >>> Every described abuse scenario that works with Unaffiliated BFD Echo also >>> works without it. The abuse is possible already. It is built into the >>> very foundation of the Internet. >> >> Generalizing Greg Mirsky’s potentially-in-the-rough assessment >> (I’m not equipped to evaluate it in depth, nor do I have the time >> right now to devote to becoming so), the question here is a fairly >> simple one: are there deployment scenarios for this protocol by which a >> nonparticipant may send UDP packets to a Unaffiliated BFD Echo endpoint >> in order to cause those packets to be echoed elsewhere by which this >> protocol becomes a vector for nonamplifying reflection attacks. > > No, because the Unaffiliated BFD Echo endpoint (I understand that as a > device implementing Unaffiliated BFD Echo) does not respond to received > Echo packets. It does not use any IP address from a received BFD Echo > packet to construct a packet. Those packets are always addressed to > the endpoint sending them. AH. Okay, I get it now. That’s *weird*, or certainly weird enough to my layer-4-addled brain that I didn’t get it on my admittedly relatively quick pass through 5880, and it still fits fairly uncomfortably in my worldview. > The Unaffiliated BFD Echo endpoint creates new packets according to its > configuration on a configured schedule. > > An endpoint not implementing Unaffiliated BFD Echo does not respond > to received BFD Echo packets either (well, it might send a port > unreachable ICMP message to the source address from the received BFD > Echo packet... you might say that implementing Unaffiliated BFD Echo > removes this reflection possibility ;-) ). > >> If there are not, a clear description of why the architecture of the >> protocol makes this impossible in the Security Considerations section >> would save the confusion evident in this conversation for future >> readers of the RFC. > > I am at a loss here, because for me this was obvious from reading RFC 5880 > many years ago. RFC 5880 section 3.2 describes on page 6: > > "[…]a stream of BFD Echo packets is transmitted in such a way as > to have the other system loop them back through its forwarding path." Okay, that’s the distinction that I didn’t get in my earlier message between “looping back” and “generating reply packets”. There actually *is* one. Like I said, weird. :) > That describes the important part. A packet is created such that after > sending it to a directly connected router, the basic IP forwarding > function of that router returns it to the sender. This is a pure data > path operation for that router. > >> If the assertion is instead that “this echo protocol is okay to define >> and expose to the Internet because other nonamplifying UDP protocols >> that can be used for echo spoofing exist”, > > That is not the case. Yep, understood now. >> that is a philosophical >> discussion that I’m not sure is in scope for this review: it’s >> my job as a TSV reviewer to make sure that these concerns are aired, >> and for the IESG to make decisions about the publication of the draft >> based on those concerns. >> >>> The Unaffiliated BFD Echo draft describes how to make use of an >>> existing aspect of IP forwarding without harming the Internet. >> >> What I’m asking for above is some demonstration in the document text >> that this last part of the assertion is true. :) > > IMHO the document text clearly describes that received BFD Echo packets > are only processed to determine the session they belong to. IMHO it > also clearly describes that packets are sent on a configured schedule, > with a rate of at most 1 packet per second until detection that the > router forwards the BFD Echo packets back as expected. I’d still prefer a reiteration of these points in this draft, but I will defer to the responsible AD (hi Éric!) as to whether that’s necessary for the intended implementor community. In general, referencing the points in 8085 for protocols using UDP explicitly would make transport reviews of routing area documents, especially incremental ones, lower-friction than this one has been. >> With said demonstration in place, my position would be “ready” >> with nits, and the authors can feel free to take my other feedback >> as intended to improve document quality and usability, and make their >> own judgements as to how they’d like to use them. In case it’s not clear from the above, this is my position now. Thanks again, cheers, Brian >>> The BFD >>> specification describes, e.g., how to avoid ICMP unreachables from the >>> tested gateway, i.e., useless additional CPU load. It also describes, >>> e.g., how to limit the sending rate without compromising detection time. >> >>> The Unaffiliated BFD Echo draft, together with the BFD RFCs, provides >>> a well considered specification everyone is free to implement. To me, >>> this is much better than hoping that everybody wanting such functionality >>> implements something that works as well without causing problems. >> >> I can certainly agree with that. > > :-) > > Best regards, > Erik -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
