Re: [Last-Call] Tsvart telechat review of draft-ietf-bfd-unaffiliated-echo-12

[Jeffrey Haas <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> Brian,
>> 
>> 
>> On Oct 16, 2024, at 1:31 AM, Brian Trammell (IETF) <[e-mail]>
>> 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 <[e-mail] <mailto:[e-mail]>>
>> 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"