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 < [email protected]> 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 > [email protected] 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. > > > >
