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.