Hi Brian,
On Tue, Oct 15, 2024 at 07:21:51AM -0700, Brian Trammell via Datatracker wrote:
>
> Reviewer: Brian Trammell
> Review result: Not Ready
> [...]
> In its current form appears harmful to deploy in the Internet, unless
> I deeply misunderstand the context in which it is deployed.
I'll comment some parts of your review that seem to be based on some
kind of misunderstanding.
> Stripping echo from the rest of BFD in essence recreates a UDP
> echo service, which, while unlikely to be a useful vector for
> UDP amplification attacks, does at least seem to be a method for
> spoofed-packet abuse should an Unaffiliated BFD Echo endpoint be opened
> to the Internet through implementation or configuration inattention.
This specification does not (re)create a UDP Echo service. Nothing
described in this draft creates a response packet to a received BFD
Echo packet.
> The specification's consideration and defense against this situation,
> especially as embodied in the operational considerations and security
> considerations sections, are inadequate.
>
> (1) "Unaffiliated BFD Echo can only be used across one hop, which
> result in unneccessity of a congestion control mechanism." Erm,
> no. First, single hops can also congest if your transport scheduler
> is rudimentary enough. Second, and more importantly, the mechanism
> enforcing the "can only be used across one hop" assumes that all
> devices that might handle an unaffiliated echo implement this RFC,
> which is not the case for UDP encapsulation.
Unaffiliated BFD Echo is based on the fact that BFD Echo packets are not
handeled on any device except the device creating them.
> "All Unaffiliated BFD Echo packets for the session MUST be sent with
> a Time to Live (TTL) or Hop Limit value of 255, and received with a
> TTL or Hop Limit value of 254, otherwise the received packets MUST
> be dropped" -- dropping packets with a TTL of 254 is not a behavior
> that is likely or desirable to widely deploy in the Internet. The
> desired behavior of drop-after-one-hop would better be specified as
> "MUST set to 1, MUST ignore any received not set to 0". Why is this
> not what the document says?
This pertains to the device sending a BFD Echo packet and then receiving
this same packet (TTL decremented during IP forwarding) back again.
No other device implements receiving or dropping of this packet.
This uses the idea from RFC 5082, "The Generalized TTL Security Mechanism
(GTSM)", adapted to work over a single hop instead of no hop.
Setting the TTL to 2 when sending and expecting a TTL of 1 for received
packets would not help to detect that a received packet was sent from
more than 1 hop away.
> (2) "Specifically for Unaffiliated BFD Echo, a DoS attacker may send
> spoofed Unaffiliated BFD Echo packets to the loop-back device, so some
> form of authentication SHOULD be included." This SHOULD is not adequate
> to protect this feature; authentication needs to be mandatory here.
The potential DoS is the denial of a fault detection service. If
bidirectional forwarding has turned into unidirectional forwarding from
the gateway to the BFD speaker, and an attacker can successfully spoof
BFD Echo packets (e.g., because of missing authentication), BFD does not
detect the fault. This is identical to the other operating modes of BFD.
This DoS situation is identical to the current state of affairs without
Unaffiliated BFD Echo.
Since the BFD speaker does not respond to received BFD packets, it
cannot be abused for reflection attacks. Since it cannot be abused for
reflection attacks, it cannot be abused for amplification attacks either.
The operation of Unaffiliated BFD Echo is similar to that of BFD Echo as
specified in the BFD RFCs. Those RFCs also say SHOULD use authentication.
> (3) The state of the art in running stuff over UDP has advanced in
> the intervening decade since RFC 5881 was published. At a minimum,
> I would expect this document to consider the points in section 3 of
> RFC 8085 and explicitly state how it addresses them.
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.
> 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.
[I use "new" in quotes, because the idea was already mentioned over a
decade ago in the "BBF Technical Report - Subscriber Sessions Issue 1"
from 2013. That technical report lacks a detailed specification, though.
This draft fills that gap.]
Best regards,
Erik
P.S. I have nothing to do with the draft, I just think it is a good idea
in need of a proper specification.
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
