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] > <mailto:[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 >> <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] >> <mailto:[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"
