Wouldn't make sense to sent it over to *l4s-disc...@ietf.org <l4s-disc...@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.bor...@gmail.com On Thu, Jan 25, 2024 at 10:54 AM Dave Taht via Cake < c...@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 > <muhammadah...@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 > c...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake >
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat