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], 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".
Okay, then this document needs to be much more clear about how u-bfd’s basic sandbox assumption is guaranteed.
You have not clearly articulated what "basic sandbox" means here.
Unaffiliated BFD does not send bursts of packet, it always sends a single
probe, then waits. The draft specifies that the "slow transmission rate"
of at most 1 packet per second is used unless the probes are received as
expected (i.e., from the directly connected gateway). Then a faster rate
can be used, but this still sends individual probe packets with pacing
according to that rate. Congesting that link would most likely result
in dropped BFD Echo packets and thus switching to the slow rate again,
and usually shifting all traffic to another link.
Cool. This paragraph should appear in the document. :)
We do not copy and paste portions of other normative documents in extension mechanisms in IETF. Whether we should is a different conversation.
The reader is expected to be familiar with RFC 5880.
Beyond this, as an editorial comment: section 3 is somewhat confusing
to me. Which parts of this document are assumed to be authoritative:
section 2, or 5880 as edited by section 3? As an implementor, having
the specification I'm supposed to build to be expressed as a 2010
document as edited in specific paragraphs by a 2024 document is not
an ideal user experience.
Unaffiliated BFD Echo is still BFD, it is a "new" operating mode of BFD.
I-D.ietf-bfd-unaffiliated-echo fills in a part left open in the original
BFD RFCs, i.e., the format of BFD Echo packets used for the "new"
Unaffiliated BFD Echo functionality. Since the original BFD RFCs did
not include this operating mode, they are updated. To me, this patch
mode seems much better than copying all content from the BFD RFCs just
to add one operating mode, keeping most of BFD the same.
Okay. A clear statement as to whether I can consider an implementation based only on section 2 or whether it’s necessary to follow the in-place edits of 5880 would be appreciated then.
What part of "The Unaffiliated BFD Echo described in this document reuses the BFD Echo function as
described in [
RFC5880] and [
RFC5881]" is not clear?
-- Jeff
