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 <jhaas@xxxxxxxx> 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?-- JeffOn Oct 17, 2024, at 1:26 PM, Greg Mirsky <gregimirsky@xxxxxxxxx> 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 <jhaas@xxxxxxxx> wrote:Brian,
On Oct 16, 2024, at 1:31 AM, Brian Trammell (IETF) <ietf@xxxxxxxxxxx>
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 <auerswal@xxxxxxxxxxxxxxxxx>
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"
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
