Hi Brian, et al,
I share your concern regarding U-BFD proliferation on the Internet. For example, https://datatracker.ietf.org/doc/draft-lin-bfd-path-consistency-over-sr/ discusses using U-BFD over SR Policies, SRv6 and SR-MPLS, to monitor candidate paths. IMHO, that is a very troubling idea.
Regards,
Greg
On Tue, Oct 15, 2024 at 7:22 AM Brian Trammell via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Brian Trammell
Review result: Not Ready
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
This document expands the BFD Echo facility (RFC 5880) over IPv4/v6 (for which
read UDP) (RFC 5881) to include "unaffiliated echo" (i.e., BFD Echo without
other Echo functions). While the original UDP bindings for the full BFD
protocol did make some provisions for attempting to use UDP in a friendly way
(citing RFC 5348), I cannot find any evidence that the original design of
BFD-over-UDP considered the other guidelines considered to be best current
practices at the time of publication (RFC 5405 / BCP 11).
It is not ready for publication as Proposed Standard.
In its current form appears harmful to deploy in the Internet, unless I deeply
misunderstand the context in which it is deployed.
Stripping echo from the rest of BFD in essence recreates a UDP echo service,
which, while unlikely to be a useful vector for UDP amplification attacks, does
at least seem to be a method for spoofed-packet abuse should an Unaffiliated
BFD Echo endpoint be opened to the Internet through implementation or
configuration inattention.
The specification's consideration and defense against this situation,
especially as embodied in the operational considerations and security
considerations sections, are inadequate.
(1) "Unaffiliated BFD Echo can only be used across one hop, which result in
unneccessity of a congestion control mechanism." Erm, no. First, single hops
can also congest if your transport scheduler is rudimentary enough. Second, and
more importantly, the mechanism enforcing the "can only be used across one hop"
assumes that all devices that might handle an unaffiliated echo implement this
RFC, which is not the case for UDP encapsulation.
"All Unaffiliated BFD Echo packets for the session MUST be sent with a Time to
Live (TTL) or Hop Limit value of 255, and received with a TTL or Hop Limit
value of 254, otherwise the received packets MUST be dropped" -- dropping
packets with a TTL of 254 is not a behavior that is likely or desirable to
widely deploy in the Internet. The desired behavior of drop-after-one-hop would
better be specified as "MUST set to 1, MUST ignore any received not set to 0".
Why is this not what the document says?
(2) "Specifically for Unaffiliated BFD Echo, a DoS attacker may send spoofed
Unaffiliated BFD Echo packets to the loop-back device, so some form of
authentication SHOULD be included." This SHOULD is not adequate to protect this
feature; authentication needs to be mandatory here.
(3) The state of the art in running stuff over UDP has advanced in the
intervening decade since RFC 5881 was published. At a minimum, I would expect
this document to consider the points in section 3 of RFC 8085 and explicitly
state how it addresses them.
Beyond this, as an editorial comment: section 3 is somewhat confusing to me.
Which parts of this document are assumed to be authoritative: section 2, or
5880 as edited by section 3? As an implementor, having the specification I'm
supposed to build to be expressed as a 2010 document as edited in specific
paragraphs by a 2024 document is not an ideal user experience.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
