hi Erik, > On 16 Oct 2024, at 18:54, Erik Auerswald <auerswal@xxxxxxxxxxxxxxxxx> wrote: > > Hi all, > > 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. 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. 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 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. :) 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. > 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. Cheers, Brian -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
