Greg, The shorter form is "if you can use BFD Echo, U-BFD is probably applicable".
Rather than have the argument as to what that means, I suspect the authors would be satisfied to cover the RFC 5881 deployment cases where BFD Echo is already used. -- Jeff > On Oct 17, 2024, at 3:39 PM, Greg Mirsky <[email protected]> wrote: > > 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] > <mailto:[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] >> <mailto:[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] >>> <mailto:[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" >
