Hi Jeff,
On Thu, Oct 10, 2024 at 07:45:26PM -0400, Jeffrey Haas wrote:
>
> Note that I agree wholeheartedly with this analysis.
Thanks!
> The scenario Stephen points out is a reflection attack, and thus
> potentially has a role in obscuring the attacker, but it is NOT an
> amplification attack. The device providing the looping service is
> simply acting as a forwarding router.
This "reflection" does not obscure the source IP address. Both source and
destination IP addresses stay the same. (What is usually understood as
a reflection attack creates a new IP packet with the source IP address
of the reflector. The destination IP of the reflected packet is the
(spoofed) source IP of the original packet. This is not the case here.)
This "reflection" possibility exists independently of Unaffiliated
BFD Echo. The "reflecting" device in general does not implement BFD,
or does not have it enabled for use by the system using Unaffiliated
BFD Echo (otherwise "affiliated" BFD could be used). The "reflection"
does not depend on Unaffiliated BFD Echo. The "reflection" does not use
Unaffiliated BFD Echo. The "reflection" reflects every protocol based
on IP, including, e.g., SSH. After disabling Unaffiliated BFD Echo,
the same "reflection" possibility exists. It existed even before any
Unaffiliated BFD Echo implementation was created.
The original claim from the Secdir review has been that Unaffiliated
BFD Echo possibly introduces a reflection attack possibility:
"I wondered if this setup might create potential reflection attacks"
It does not. Instead, the Internet Protocol creates this "reflection
attack" possibility. (Please note that I do not consider IP forwarding
an attack, but rather a useful service.)
> The unaffiliated BFD instance has multiple opportunities to not pay
> attention to the spoofed traffic:
> - GTSM is recommended. This ideally would reduce the attacker to
> being on-link.
Since the BFD Echo packet needs to be forwarded by a router to work as
intended, its TTL is decremented by 1 to 254. Both an on-link attacker
and an attacker one hop away can get around this hardening measure.
An on-link attacker can create a packet with TTL 254 and send it directly
to the target. They can also create a packet with a TTL of 255 and send
it via an on-link router. An on-link attacker cannot hide their IP by
sending the packet through an on-link router.
> - BFD authentication is recommended. This will avoid disrupting the
> unaffiliated session.
> - BFD authentication mechanisms that include a sequence number can
> reduce the attack space of an attacker trying to use the cryptographic
> mechanism as a CPU exhaustion attack. However, an on-link attacker
> may be able to observe the sequence number.
Indeed, any control plane protocol provides a possibility for CPU
exhaustion. This can be changed into a denial of this control protocol
service by per protocol rate limiting of control plane packet delivery
to the CPU.
This also affects "affiliated" BFD. Unaffiliated BFD sharing the security
considerations of ("affiliated") BFD is already mentioned in the draft.
Br,
Erik
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
