On 05/12/2015 05:57 AM, Ibrahim Celikbilek wrote:> I have 2 different suggestions about syn-cookies method which is used to
> block syn-flood attacks.
You're probably better off on the kernel devel list or a TCP specific list.
> 1- T value can be decreased to 2 bit which is already 5 bit.And hash value
> will be 27 bit.
Why? You'd lose a tremendous amount of resolution on the time value and
gain a tiny bit better hash value. And since the current implementation
encodes TCP options in the t value, you'd lose a significant feature of
the existing implementation.
> 2-Normally syn-cookies is activated when syn-list is fulled.
Which is pretty much the only time it makes sense to do so, since you
lose TCP features when you use the syn cookie mechanism. Earlier you
proposed a per-connection cookie, or something of that sort, but TCP
flood attacks, which syn cookies are designed to work around, will
almost always come in with random/forged source host and port values.
Since those values can't be authenticated in the syn packet, the
existing trigger on memory limits are the only logically correct trigger
for the syn cookie mechanism.
> At this point I suggest a hybrid system.Syn packages and eck packages
> which received to server will be counted, if the difference is bigger than
> a reference value syn-cookies will be activated.
You're actually describing the way that the system already works. The
difference between those two values will be the size of the syn queue.
The "reference value" is the maximum size.