Date: Sun, 22 Sep 1996 04:56:40 +0200 (MET DST) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: security@freebsd.org Subject: Re: comments on the SYN attack Message-ID: <199609220256.EAA01434@ocean.campus.luth.se> In-Reply-To: <199609212143.PAA02996@rover.village.org> from Warner Losh at "Sep 21, 96 03:43:35 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Hello... Hello! Not saying I know anything about this at all, really, but I have to get a word in here... > I think that if you get the point of discarding stuff, then you are in > trouble anyway. It would be nice to not discard it too soon. Also, > if the rates are such that you know you can handle it, then I think > the determanistic would be better. If they are absolutely hammering > the snot out of you, then the random one would be better because the > service is so crappy anyway that a little flakiness is better than no > possibility of a connection. Wouldn't it then simply be easy to implement both, instead of arguing? Make the random_packet_to_kill function return a biased random, like: I assume older packets have lower numbers... tmp = "SYNs per sec" * "Time to hold SYNs before normal drop" tmp = tmp / "queuelength" return "oldest SYN" + (tmp * "random number") Which should be tuned to that it drops the oldest ones, until the SYN load starts to go above a certain limit, compaired with the queue length, and the the random value would kick in and become more and more random the higher the load. Then we would get the benefits of both methods. I have no knowledge about anything involved here, but it seem to make logical sense in my mind. Or am I completely off here? > Bottom line: You don't want to drop these things if you can help > it... Ofcourse... if the bandwidth of the net between you and the attacker only makes it possible for him to flood you with a certain rate, simply enlarging the queue so that you can hold (floodrate+some)*timeout entries, would make the attack only have two effects: Stealing some bandwidth and memory. If you have enough memory to spare a bit, and your net connection is not too dameged by it, you could sustain such an attack until the attacker gets bored, without it costing you much. The problem arises when you can't hold a queue big enough. Right? Just $.02 from me. /Mikael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609220256.EAA01434>