Hello Everyone, I have 2 different suggestions about syn-cookies method which is used to block syn-flood attacks.
Syn cookies bitwise image
——————————————-
One thought on - New Approach Syncookies Help Me
You’re probably better off on the kernel devel list or a TCP specific list.
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.
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.
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.
One thought on - New Approach Syncookies Help Me
You’re probably better off on the kernel devel list or a TCP specific list.
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.
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.
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.