"Paul Albrecht" [off-list ref] writes:
This statement is inconsistent with the description of this scenario in
Steven's TCP/IP Illustrated. Specifically, continuing the handshake in the
TCP layer, i.e., sending a syn/ack and moving to the syn_recd state, is
incorrect if the limit of the server's socket backlog would be exceeded.
How do you account for this discrepancy between linux and other
berkeley-derived implementations?
The 4.4BSD-Lite code described in Stevens is long outdated. All modern
BSDs (and probably most other Unixes too) do it in a similar way to what
Nivedita described. The keywords are "syn flood attack" and "DoS".
-Andi
Andi Kleen writes:
The 4.4BSD-Lite code described in Stevens is long outdated.
I was referring to volume one subtitled: "The Protocols." It doesn't
describe implementation and the examples are not limited to bsd-lite.
All modern BSDs (and probably most other Unixes too) do it in a similar way
to what
Nivedita described.
Linux doesn't operate in the manner Nivedita describes ... the tcp layer on
the server side moves to the syn_recd state, but doesn't accept the ack back
from client. Instead it times out and sends its syn/ack back to the client
and again ignores the client's ack, ... Eventually, either there's room on
backlog queue and the server side moves to the established state or the
server side stops resending the its syn/ack. This doesn't seem to make much
sense. If the tcp layer can send the syn/ack it seems like it should
probably respond to the client's ack.
The keywords are "syn flood attack" and "DoS".
I'd be interested in a more specific reference detailing the changes
required to the listen syscall as a consequence of the changes required for
avoidance of syn flood attacks. Thanks.
Andi Kleen writes:
The 4.4BSD-Lite code described in Stevens is long outdated. All modern
BSDs (and probably most other Unixes too) do it in a similar way to what
Nivedita described. The keywords are "syn flood attack" and "DoS".
I have attached a copy of tcpdump output for two linux systems connected
over ether replaying the scenario for incoming request queue handling given
in Stevens's TCP/IP Illustrated Volume 1: The Protocols. What I don't
understand about the third handshake is if the server is going to send the
syn/ack in response the client's initial syn then why does server repeatly
ignore the subsequent ack from the client?