[Cake] CAKE AQM- security

[Frantisek Borsik]

Wouldn't make sense to sent it over to *l4s-discuss at ietf.org
<l4s-discuss at ietf.org>* also? I mean, they should at least try (however
lame it would be) to address it...

All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik at gmail.com


On Thu, Jan 25, 2024 at 10:54 AM Dave Taht via Cake <
cake at lists.bufferbloat.net> wrote:

> 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:
> https://www.youtube.com/watch?v=D9RGX6QFm5E
> Dave Täht CSO, LibreQos
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20240126/9df5b580/attachment.html>