Thread (32 messages) 32 messages, 8 authors, 2012-05-31

Re: [RFC PATCH 0/2] Faster/parallel SYN handling to mitigate SYN floods

From: Jesper Dangaard Brouer <hidden>
Date: 2012-05-30 22:40:55

On Wed, 2012-05-30 at 10:53 +0200, Christoph Paasch wrote:
On 05/30/2012 10:44 AM, Jesper Dangaard Brouer wrote:
quoted
quoted
quoted
Then the receiver will receive two SYN/ACK's for the same SYN with
different sequence-numbers. As the "SYN cookie SYN-ACK" will arrive
second, it will be discarded and seq-numbers from the first one will be
taken on the client-side.
I thought that the retransmitted SYN packet, were caused by the SYN-ACK
didn't reach the client?
Or, if the SYN/ACK got somehow delayed in the network and the
SYN-retransmission timer on the client-side fires before the SYN/ACK
reaches the client.
That seems like a very unlikely situation, which we perhaps should
neglect as we are under SYN attack.

I will test the attack vector, if we instead of dropping the reqsk, fall
back into the slow locked path.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help