<div dir="ltr">Wouldn't make sense to sent it over to <i><a href="mailto:l4s-discuss@ietf.org">l4s-discuss@ietf.org</a></i> also? I mean, they should at least try (however lame it would be) to address it...<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>All the best,</div><div><br></div><div><p class="MsoNormal" style="color:rgb(34,34,34)">Frank<u></u><u></u></p><p class="MsoNormal" style="color:rgb(34,34,34)"><u></u><u></u></p><p class="MsoNormal" style="color:rgb(34,34,34)">Frantisek (Frank) Borsik<u></u><u></u></p><p class="MsoNormal" style="color:rgb(34,34,34)"><u></u> <u></u></p><p class="MsoNormal" style="color:rgb(34,34,34)"><a href="https://www.linkedin.com/in/frantisekborsik" style="color:rgb(17,85,204)" target="_blank">https://www.linkedin.com/in/frantisekborsik</a><u></u><u></u></p><p class="MsoNormal" style="color:rgb(34,34,34)">Signal, Telegram, WhatsApp: +421919416714 <u></u><u></u></p><p class="MsoNormal" style="color:rgb(34,34,34)">iMessage, mobile: +420775230885<u></u><u></u></p><p class="MsoNormal" style="color:rgb(34,34,34)">Skype: casioa5302ca<u></u><u></u></p><p class="MsoNormal" style="color:rgb(34,34,34)"><a href="mailto:frantisek.borsik@gmail.com" style="color:rgb(17,85,204)" target="_blank">frantisek.borsik@gmail.com</a></p></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 25, 2024 at 10:54 AM Dave Taht via Cake <<a href="mailto:cake@lists.bufferbloat.net">cake@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">The cake mailing list is more appropriate for this question, but as it<br>
has not come up much before, I figured I would attempt to answer it.<br>
<br>
In general, FQ and AQM technologies are more resistant to simple<br>
floods and even DDOS attacks than a FIFO. Starting with FQ first,<br>
a single DOS (or unresponsive flow) ends up invisible to the overall<br>
operation of the queues aside from running the qdisc to its memory<br>
limit. Fq_codel then drops robustly (the drop_batch facility drops 64<br>
packets at a time), or cake engages the "blue" algorithm which<br>
operates on a per packet basis, usually before it hits the memory<br>
limit. Both of these defenses operate independently of if a packet is<br>
ECN marked or not.<br>
<br>
There was an infamous bug where the odhcpd client would have an<br>
overflow at 51 days, and then flood the upstream with dhcpv6 requests,<br>
which was invisible to the fq_codeled end user (but not the<br>
provider!). Had it been on a FIFO perhaps that bug would have been<br>
noticed sooner.<br>
<br>
Running out of memory somewhere in the system in general has bad<br>
side-effects but they are common to all queueing mechanisms. fq_codel<br>
and cake are perhaps more subject to running small systems out of<br>
memory than most FIFOs as their defaults are sized to handle 10Gbit<br>
traffic. Openwrt patches down cake and fq_codel to saner defaults for<br>
tiny systems (64MB ram typically) running at less than a gbit/sec.<br>
<br>
A DDOS attack is handled fairly well (and in all cases better than a<br>
FIFO, we think - luca muscarillo has a paper on it) by a FQ technology<br>
- the hash used against the 5 tuple is salted by a random number<br>
created at instantation time so the underlying tuple must have many,<br>
many flows in order to completely disable the link. 1024 flows will<br>
knock out cake, but a FIFO would have fallen over long before that.<br>
<br>
These days on DC links where we see fq_codel, there are multiple<br>
hardware queues so there are 1024*cores fq_codel queues in play. There<br>
is a slight difference between cake and fq_codel, where in that case<br>
fq_codel attempts to get the total queue time down below 5ms (by<br>
default) over time and load, even dropping the last packet in a queue,<br>
where cake takes the latency hit and tries to deliver the last packet<br>
in a queue, except when blue is engaging. We keep hoping to see more<br>
cake in the DC...<br>
<br>
Moving onto AQM technology:<br>
<br>
There was an attack published against RED many years ago which used<br>
short bursts and RED's decay time to cause collateral damage. I think<br>
all single queued AQMs are subject to attacks like these, but to what<br>
extent is unknown.<br>
<br>
Adding ECN into the mix increases the vulnerability to non-ecn'd<br>
packets to be dropped while the ECN packets are preserved.<br>
<br>
A ping -f -s 1400 -Q 1 somewhere is sufficient to DOS the dualpi L4S<br>
queue. -Q 1 or -Q 2 sufficient to DOS a single codel, pie, or RED<br>
queue (with ecn enabled)<br>
<br>
The simplicity of ECN'd DOS attacks like these led to us leaving ecn<br>
off by default in the single queued implementations of codel and pie,<br>
but we were encouraged to enable ECN for fq_codel and fq_pie so<br>
RFC3168 style ecn is supported by default for the users of it there,<br>
at least in Linux.<br>
<br>
The L4S architecture specification contains elaborate out of band<br>
defenses against {D}DOS attacks but not in the qdisc itself (e.g. the<br>
code I have seen has neither the drop_batch or blue facilities in<br>
fq_codel and cake). In serious cases of DOS or DDOSes the current<br>
architectures for blackholing that sort of traffic somewhere else via<br>
bgp/cloudflare/etc apply. I am not aware of any service presently<br>
targetting coping with mis-marked, mis-behaving ECN'd traffic, nor of<br>
any ECN-enabled attacks, though I viewed those as inevitable if ecn<br>
ever took off.<br>
<br>
There are no doubt "interesting" new edge cases and attacks against<br>
these AQM and FQ technologies, which cost me sleep because I cannot<br>
forecast what they will be, and will no doubt take heat for one when<br>
one inevitably occurs.<br>
<br>
On Thu, Jan 25, 2024 at 12:20 AM Muhammad Ahsan<br>
<<a href="mailto:muhammadahsan@umt.edu.pk" target="_blank">muhammadahsan@umt.edu.pk</a>> wrote:<br>
><br>
><br>
><br>
> Hi,<br>
><br>
><br>
><br>
> I was wondering , if anyone can share the security related part of  CAKE AQM .<br>
><br>
> I mean the security considerations CAKE takes into account in preventing against certain LDDOS, spoofing type attacks. etc<br>
><br>
><br>
><br>
><br>
><br>
> Rgds,<br>
><br>
> Ahsan<br>
<br>
<br>
<br>
-- <br>
40 years of net history, a couple songs:<br>
<a href="https://www.youtube.com/watch?v=D9RGX6QFm5E" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=D9RGX6QFm5E</a><br>
Dave Täht CSO, LibreQos<br>
_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</blockquote></div>