On Fri, Jul 12, 2013 at 1:47 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2013-07-12 at 13:35 -0400, Dave Taht wrote: > >> Against a syn flood attack? > > > Yes. SYNACK messages are in the band 1. SYNACK messages might be > dropped, but your precious management traffic will not.
I think I'm beginning to gain clue here, in that 1) in a big outward facing deployment, some work is done to ensure that certain kinds of traffic ends up in the priority queue, by matching against a range of internal ips, etc. Sure, this always happens and is another good argument for a multiband solution, but I note that those deployments have special requirements in general as you've noted from the htb scheme you've had to deal with. And/or 2) there is in-kernel stuff that utilizes skb->priority to ensure that some other in-kernel systems (like the synack defense) do that? Which is what I think you mean... (?) so I'll go poke around there. I have treated that feature as a black box, sorry. I should probably try to return this thread to establishing "a reasonable default for desktops, servers, androids, routers, etc" and having a mechanism to provide that at kernel buildtime... but we're making progress, so... > >> >> > Thats the point you absolutely missed. Its kind of incredible. >> >> I guess I'm still entirely missing it. By default the networks I have >> are protected by the syn_flood mechanism as enabled in openwrt. > > Most servers coping with synflood or any kind of traffic flood do not > use openwrt ;) Heh. I have plenty of other servers at linode, I just don't attack them, because then I get nasty notes from their management. I ran operations for a large ISP and later a large banner ad company back in the 90s, so my skills are out of date, the hair loss still memorable, and the tools I use to protect them (things like xinetd) archaic. I should probably have said merely that syn flooding stuff in sysctl is turned on, and to me, it was a magic option that I (still) have no idea how it works, so if I'm reading your mind correctly about an innate usage of pfifo_fast, cool, I'll go read. I know it's a wild and wooly internet, believe me. I rant on ECN a bit... But I do not as a rule talk about security/attack problems publicly. I should probably note that a reason for wanting a service guarantee for a background queue is part of a half thought out approach towards being able to deal with certain kinds of floods better (ICMP etoobig and related in particular. If it was up to me I'd toss nearly all non-link-local icmp traffic into a background queue) The design goal is "something less horrible than pfifo_fast". It is good to identify features and problems and to figure out what can be solved to move along incrementally. and a mechanism for enabling it (or whatever) > > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel