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
