hi Erik, 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. And thanks all for the discussion here, it sheds some light on the state of things. Erik’s message is the most comprehensive though so I’ll continue the thread by responding to it, though I’ll pull in other bits of the thread here as well. My most serious concerns here are summed up in Greg’s last message (though I’m not as versed in the details of interactions with SR): in its well-behaved, deployed-as-intended state this seems fine, it’s my lack of understanding around the safeguards against (1) a malicious actor who has access to a u-bfd endpoint or (2) the impact of implementation faults breaking the sandbox assumptions around the protocol. Now, it may be that these safeguards do indeed exist in some other document I didn’t read. The minimum effort fix here is probably an expanded security considerations section explaining how u-bfd doesn’t escape to the Internet. > On 15 Oct 2024, at 22:43, Erik Auerswald <auerswal@xxxxxxxxxxxxxxxxx> wrote: > > Hi Brian, > > On Tue, Oct 15, 2024 at 07:21:51AM -0700, Brian Trammell via Datatracker wrote: >> >> Reviewer: Brian Trammell >> Review result: Not Ready >> [...] >> In its current form appears harmful to deploy in the Internet, unless >> I deeply misunderstand the context in which it is deployed. > > I'll comment some parts of your review that seem to be based on some > kind of misunderstanding. Hence the hedge-word “appears” in my review :) I figured I must be missing something fairly fundamental here. >> 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. > > This specification does not (re)create a UDP Echo service. Nothing > described in this draft creates a response packet to a received BFD > Echo packet. Okay, then I am confused by the name of the protocol (“[…] Echo”), as well as figure 1, which clearly shows device B sending packets back to device A. I’m not sure I understand the distinction between “looping” a packet and “creating a response packet” unless said looping functionality is at layer 1, but I see no reference here to optical or electromagnetic delay lines, so I assume that is not the case. >> 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. > > Unaffiliated BFD Echo is based on the fact that BFD Echo packets are not > handeled on any device except the device creating them. I’m also having a lot of trouble reconciling Figure 1 with this, and with Jeff’s statement “[t]he actual idea of a remote system is farcical for this mode[…, in] U-bfd the system is only talking to itself.” Either the packets stay on the device (and there are strong protocol-level guarantees that would isolate the protocol from the Internet in cases of implementation fault or unintentional misconfiguration, and the document needs to detail what those are), or the session runs between two devices (in which case the concerns about isolation need to be addressed explicitly). Though it was written for a slightly different and more expansive context, I find the guidance in RFC 9419 section 2.6 useful here: "While it is tempting to consider removing these limitations in the context of closed, private networks, each interaction is still best considered separately, rather than simply allowing all information exchanges within the closed network. Even in a closed network with carefully managed elements, there may be compromised components, as evidenced in the most extreme way by the Stuxnet worm that operated in an air-gapped network. Most "closed" networks have at least some needs and means to access the rest of the Internet and should not be modeled as if they had an impenetrable security barrier.” >> "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? > > This pertains to the device sending a BFD Echo packet and then receiving > this same packet (TTL decremented during IP forwarding) back again. > No other device implements receiving or dropping of this packet. > > This uses the idea from RFC 5082, "The Generalized TTL Security Mechanism > (GTSM)", adapted to work over a single hop instead of no hop. There is no citation to 5082 in this document. Please consider adding one to help readers understand that that’s the intent here. > Setting the TTL to 2 when sending and expecting a TTL of 1 for received > packets would not help to detect that a received packet was sent from > more than 1 hop away. Yes, but it would ensure that non-compromised intermediate devides would not forward the packet, therefore reducing the risk of misuse via reflection. This concept seems to lean very heavily on the assumption that these packets will never leave the u-bfd sandbox (in the sense of “restricted environment”), otherwise I would expect that using TTL as an escape safety feature would take priority over using it as an internal detection feature. >> (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. > > The potential DoS is the denial of a fault detection service. If > bidirectional forwarding has turned into unidirectional forwarding from > the gateway to the BFD speaker, and an attacker can successfully spoof > BFD Echo packets (e.g., because of missing authentication), BFD does not > detect the fault. This is identical to the other operating modes of BFD. > This DoS situation is identical to the current state of affairs without > Unaffiliated BFD Echo. > > Since the BFD speaker does not respond to received BFD packets, it > cannot be abused for reflection attacks. Since it cannot be abused for > reflection attacks, it cannot be abused for amplification attacks either. > > The operation of Unaffiliated BFD Echo is similar to that of BFD Echo as > specified in the BFD RFCs. Those RFCs also say SHOULD use authentication. Okay, then this document needs to be much more clear about how u-bfd’s basic sandbox assumption is guaranteed. >> (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. > > Unaffiliated BFD does not send bursts of packet, it always sends a single > probe, then waits. The draft specifies that the "slow transmission rate" > of at most 1 packet per second is used unless the probes are received as > expected (i.e., from the directly connected gateway). Then a faster rate > can be used, but this still sends individual probe packets with pacing > according to that rate. Congesting that link would most likely result > in dropped BFD Echo packets and thus switching to the slow rate again, > and usually shifting all traffic to another link. Cool. This paragraph should appear in the document. :) >> 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. > > Unaffiliated BFD Echo is still BFD, it is a "new" operating mode of BFD. > I-D.ietf-bfd-unaffiliated-echo fills in a part left open in the original > BFD RFCs, i.e., the format of BFD Echo packets used for the "new" > Unaffiliated BFD Echo functionality. Since the original BFD RFCs did > not include this operating mode, they are updated. To me, this patch > mode seems much better than copying all content from the BFD RFCs just > to add one operating mode, keeping most of BFD the same. Okay. A clear statement as to whether I can consider an implementation based only on section 2 or whether it’s necessary to follow the in-place edits of 5880 would be appreciated then. Thanks, cheers, Brian > [I use "new" in quotes, because the idea was already mentioned over a > decade ago in the "BBF Technical Report - Subscriber Sessions Issue 1" > from 2013. That technical report lacks a detailed specification, though. > This draft fills that gap.] > > Best regards, > Erik > > P.S. I have nothing to do with the draft, I just think it is a good idea > in need of a proper specification. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
