linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul Albrecht" <palbrecht@qwest.net>
To: "Andi Kleen" <ak@suse.de>
Cc: niv@us.ibm.com, linux-kernel@vger.kernel.org,
	"netdev" <netdev@oss.sgi.com>
Subject: Re: question about linux tcp request queue handling
Date: Mon, 7 Jul 2003 21:14:48 -0700	[thread overview]
Message-ID: <001501c34507$7a19baa0$6801a8c0@oemcomputer> (raw)
In-Reply-To: p73fzliqa91.fsf@oldwotan.suse.de

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.





  parent reply	other threads:[~2003-07-08  2:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3F08858E.8000907@us.ibm.com.suse.lists.linux.kernel>
     [not found] ` <001a01c3441c$6fe111a0$6801a8c0@oemcomputer.suse.lists.linux.kernel>
     [not found]   ` <3F08B7E2.7040208@us.ibm.com.suse.lists.linux.kernel>
     [not found]     ` <000d01c3444f$e6439600$6801a8c0@oemcomputer.suse.lists.linux.kernel>
     [not found]       ` <3F090A4F.10004@us.ibm.com.suse.lists.linux.kernel>
     [not found]         ` <001401c344df$ccbc63c0$6801a8c0@oemcomputer.suse.lists.linux.kernel>
2003-07-07 21:48           ` question about linux tcp request queue handling Andi Kleen
2003-07-07 22:25             ` Doug McNaught
2003-07-07 23:52               ` Andi Kleen
2003-07-08  0:17                 ` Doug McNaught
2003-07-08  0:25                   ` Andi Kleen
2003-07-08 14:09                   ` Horst von Brand
2003-07-08  4:14             ` Paul Albrecht [this message]
2003-07-08 19:23             ` Paul Albrecht
2003-07-06 21:19 Paul Albrecht
  -- strict thread matches above, loose matches on Subject: below --
2003-07-06 20:24 Nivedita Singhvi
2003-07-07  0:12 ` Paul Albrecht
2003-07-06 23:59   ` Nivedita Singhvi
2003-07-07  6:20     ` Paul Albrecht
2003-07-07  5:51       ` Nivedita Singhvi
2003-07-07  5:59         ` Nivedita Singhvi
2003-07-07 23:30         ` Paul Albrecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001501c34507$7a19baa0$6801a8c0@oemcomputer' \
    --to=palbrecht@qwest.net \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=niv@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).