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.
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."
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.
> 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.
> 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.
:-)
Best regards,
Erik
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
