[Bloat] CAKE AQM- security

Dave Taht dave.taht at gmail.com
Thu Jan 25 04:54:22 EST 2024

The cake mailing list is more appropriate for this question, but as it
has not come up much before, I figured I would attempt to answer it.

In general, FQ and AQM technologies are more resistant to simple
floods and even DDOS attacks than a FIFO. Starting with FQ first,
a single DOS (or unresponsive flow) ends up invisible to the overall
operation of the queues aside from running the qdisc to its memory
limit. Fq_codel then drops robustly (the drop_batch facility drops 64
packets at a time), or cake engages the "blue" algorithm which
operates on a per packet basis, usually before it hits the memory
limit. Both of these defenses operate independently of if a packet is
ECN marked or not.

There was an infamous bug where the odhcpd client would have an
overflow at 51 days, and then flood the upstream with dhcpv6 requests,
which was invisible to the fq_codeled end user (but not the
provider!). Had it been on a FIFO perhaps that bug would have been
noticed sooner.

Running out of memory somewhere in the system in general has bad
side-effects but they are common to all queueing mechanisms. fq_codel
and cake are perhaps more subject to running small systems out of
memory than most FIFOs as their defaults are sized to handle 10Gbit
traffic. Openwrt patches down cake and fq_codel to saner defaults for
tiny systems (64MB ram typically) running at less than a gbit/sec.

A DDOS attack is handled fairly well (and in all cases better than a
FIFO, we think - luca muscarillo has a paper on it) by a FQ technology
- the hash used against the 5 tuple is salted by a random number
created at instantation time so the underlying tuple must have many,
many flows in order to completely disable the link. 1024 flows will
knock out cake, but a FIFO would have fallen over long before that.

These days on DC links where we see fq_codel, there are multiple
hardware queues so there are 1024*cores fq_codel queues in play. There
is a slight difference between cake and fq_codel, where in that case
fq_codel attempts to get the total queue time down below 5ms (by
default) over time and load, even dropping the last packet in a queue,
where cake takes the latency hit and tries to deliver the last packet
in a queue, except when blue is engaging. We keep hoping to see more
cake in the DC...

Moving onto AQM technology:

There was an attack published against RED many years ago which used
short bursts and RED's decay time to cause collateral damage. I think
all single queued AQMs are subject to attacks like these, but to what
extent is unknown.

Adding ECN into the mix increases the vulnerability to non-ecn'd
packets to be dropped while the ECN packets are preserved.

A ping -f -s 1400 -Q 1 somewhere is sufficient to DOS the dualpi L4S
queue. -Q 1 or -Q 2 sufficient to DOS a single codel, pie, or RED
queue (with ecn enabled)

The simplicity of ECN'd DOS attacks like these led to us leaving ecn
off by default in the single queued implementations of codel and pie,
but we were encouraged to enable ECN for fq_codel and fq_pie so
RFC3168 style ecn is supported by default for the users of it there,
at least in Linux.

The L4S architecture specification contains elaborate out of band
defenses against {D}DOS attacks but not in the qdisc itself (e.g. the
code I have seen has neither the drop_batch or blue facilities in
fq_codel and cake). In serious cases of DOS or DDOSes the current
architectures for blackholing that sort of traffic somewhere else via
bgp/cloudflare/etc apply. I am not aware of any service presently
targetting coping with mis-marked, mis-behaving ECN'd traffic, nor of
any ECN-enabled attacks, though I viewed those as inevitable if ecn
ever took off.

There are no doubt "interesting" new edge cases and attacks against
these AQM and FQ technologies, which cost me sleep because I cannot
forecast what they will be, and will no doubt take heat for one when
one inevitably occurs.

On Thu, Jan 25, 2024 at 12:20 AM Muhammad Ahsan
<muhammadahsan at umt.edu.pk> wrote:
> Hi,
> I was wondering , if anyone can share the security related part of  CAKE AQM .
> I mean the security considerations CAKE takes into account in preventing against certain LDDOS, spoofing type attacks. etc
> Rgds,
> Ahsan

40 years of net history, a couple songs:
Dave Täht CSO, LibreQos

More information about the Bloat mailing list