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

[Jeffrey Haas <[e-mail]>]

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