Hi Jeff, That update is a good step to address my concern. It seems that the document can take one or two more steps to demonstrate why U-BFD in environments other than RFC 5881 is not operable. I think that closing this issue in the core U-BFD specification is prudent and future-proof.
Regards, Greg On Thu, Oct 17, 2024 at 12:18 PM Jeffrey Haas <[email protected]> wrote: > Greg, > > Would you be satisfied to update the text to say this applies to RFC 5881 > IPv4/IPv6 single-hop use cases and that all others are out of scope? > > -- Jeff > > > On Oct 17, 2024, at 1:26 PM, Greg Mirsky <[email protected]> wrote: > > Hi Jeff, > it appears that you and other proponents of this draft concentrate on the > single-hop BFD (RFC 5881) case. But single-hop BFD is also used in > BFD-over-foo, e.g., RFC 5884, RFC 8971, RFC 9521, draft-ietf-bess-evpn-bfd. > All these specifications all state that > Support for echo BFD is outside the scope of this document. > According to draft-ietf-bfd-unaffiliated-echo, U-BFD is applicable in, for > example, VXLAN, what would happen to the looped packet? I seems like it > will be routed through the underlay network. AFAICS, that is not part of > BFD Echo function per RFC 5880. > > Regards, > Greg > > On Wed, Oct 16, 2024 at 9:28 AM Jeffrey Haas <[email protected]> wrote: > > Brian, > > > On Oct 16, 2024, at 1:31 AM, Brian Trammell (IETF) <[email protected]> > wrote: > > 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. > > > 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. > > > 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. > > > Please note that I consider Greg's references to be a "red herring", and > an unnecessary distraction. The issues with SRv6 are security issues with > SRv6 and not specifically BFD related. > > BFD Echo is a feature that has been shipping for years. Echo relies on > three things: > 1. A BFD implementation sends echo packets to a designated port addressing > those packets to itself. > 2. The adjacent system loops those packets back. The sender, talking to > itself, leverages the contents of the packet to determine that it is indeed > talking to itself and uses that information to decide that bi-directional > connectivity thus exists. > > Point 3, which I suspect is part of Greg's contention, is that such Echo > reply functionality is enabled as part of BFD negotiation. BFD's primary > role is permitting rate negotiation for the feature. (See RFC 5880, > section 6.8.9) > > That point is not necessarily true. > > Routers will happily provide the loop behavior as part of IP forwarding. > > Endpoints that are not routers that are asked to implement this mechanism > need to implement IP forwarding, even if in a limited context. > > > > The minimum effort fix here is probably an expanded security > considerations section explaining how u-bfd doesn’t escape to the Internet. > > > Unfamiliarity with BFD is likely what makes this comment seem reasonable. > it's not. > > From the draft: > > "Similar to what's specified in [RFC5880 > <https://www.rfc-editor.org/info/rfc5880>], the Unaffiliated BFD Echo > session begins with the periodic, slow transmission of Unaffiliated BFD > Echo packets. The slow transmission rate SHOULD be no less than one second > per packet, until the session is Up. After the session is Up, the > provisioned transmission interval is used." > > If it's the case that a U-BFD session is provisioned to test a system that > isn't a willing participant, these things follow from underlying > procedures: > - If the system doesn't loop the U-BFD packets, the BFD session never goes > to Up and thus the packet rate is 1/second. This is less aggressive in > many respects that someone leaving ping running because the target IP stack > doesn't need to process this in user-land. > - If the system does loop the U-BFD packets and it is more than one IP hop > away, the TTL check will cause the U-BFD packets to be dropped and the > session will never go Up. See prior comment for impact. > > Is there something outside of these considerations that are intended to > cover "escape to the Internet" because that phrase doesn't actually make > much sense. > > Other comments follow: > > > On 15 Oct 2024, at 22:43, Erik Auerswald <[email protected]> > wrote: > > 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. > > > You may wish to review the Echo procedures from RFC 5880 since the > terminology originates there. > > In this case, it is loopback where a sender "talks to itself" by sending a > packet to an adjacent node with its own address as the destination. IP > forwarding on that system sends the traffic back to itself. No packet > reception by the remote system beyond that required for forwarding is > required. > > 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). > > > How would you suggest graphically depicting "Device A" sending a PDU with > a destination of Device A to Device B and Device B, using standard IP > forwarding, sending the PDU back to Device A? A UML sequence diagram? > Pseudocode? > > Perhaps the term "loopback" is confusing some people because they think > they're talking to 127.0.0.1? > > > 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. > > > The citation would, at best, be to the non-normative appendix A. Is that > satisfactory? > > Yes, but it would ensure that non-compromised intermediate devides would > not forward the packet > > > Forward what packet? > If it's a configured U-BFD session from a conformant implementation, it'd > be the system addressing PDUs to itself. > > > , 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. > > > Your scenario is not clear. Are you arguing "don't use GTSM"? > > Consider articulating a full scenario rather than some abstract "escapes" > > >
