Re: application level accept() filter for 1.3.x

["Theo E. Schlossnagle" <je...@cnds.jhu.edu>]

I saw this...  I think this is great, though I haven't tested how well it work
-- we don't run 2.4 anywhere yet.  As for comparing an application filter and
a kernel filter, I don't see how an app filter (my patches specifically) won't
perform as well.

I don't do anything but a select on the accepted socket to see if there is
data ready.  So it serves the same purpose but it doesn't live in the kernel,
so it induces more context switching.  A kernel level filter, assuming it is
written correctly, should beat the pants off my "parental accept" patch.

MSIE and netscape can't send the data in the first packet right?  You have to
send a few packets to establish the session first.  The problem is latency (of
a modem or shotty network connection) between the establishment and that first
data packet.

Am I losing my mind?  I have seen this sort of thing frequently across very
high traffic sites.

With that said, if you are having lulls between connect() and read() on the
server side and you OS doesn't support accept filtering.  The "parental
accept" patch should solve the problem.

dean gaudet wrote:
> as of linux 2.4 there is a TCP_DEFER_ACCEPT option which behaves like
> freebsd's "dataready" filter.
> 
> i'd actually be curious to know how much the "http" filter actually gains
> over just plain dataready... given that MSIE always sends the headers in
> the first packet; and so does netscape unless its POSTing.  (netscape
> splits the headers before the Content-Length/post body.)

--
Theo Schlossnagle
1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E  2DC2 72C2 AD05 A8EB CF8F
2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7

Re: application level accept() filter for 1.3.x

[dean gaudet <dg...@arctic.org>]

well if you used UDP to essentially re-implement TCP, i.e. with a 3-way
handshake to open up a reliable, sequenced stream.  then it'd be as secure
as TCP is to outside attacks.

the issue is when you implement certain protocols which transmit data
without the handshake... i don't know the exact details, but you can
mathematically prove that without enough handshaking you can't implement a
*secure* reliable sequenced stream.

it's the 3rd party issue -- an attacker sourcing packets which look to
come from either end of the communication.  something to do with sequence
number safety.

so yeah T/TCP gets you a reliable sequenced stream, it's just not safe
from attackers.

-dean

On Wed, 3 Jan 2001, Tony Finch wrote:

> dean gaudet <dg...@arctic.org> wrote:
> >
> >TTCP which lets data go in the first packet is not
> >secure / not useable on an open network.
>
> I've seen this comment a few times recently, but I don't see why it
> should be any worse than UDP from that perspective. Perhaps the issue
> is just that it isn't quite as safe as TCP.
>
> Tony.
> --
> f.a.n.finch    fanf@covalent.net    dot@dotat.at
> " ``Well, let's go down and find out who's grave it is.''
> ``How?''  ``By going down and finding out!'' "
>

Re: application level accept() filter for 1.3.x

[Tony Finch <do...@dotat.at>]

dean gaudet <dg...@arctic.org> wrote:
>
>TTCP which lets data go in the first packet is not
>secure / not useable on an open network.

I've seen this comment a few times recently, but I don't see why it
should be any worse than UDP from that perspective. Perhaps the issue
is just that it isn't quite as safe as TCP.

Tony.
-- 
f.a.n.finch    fanf@covalent.net    dot@dotat.at
" ``Well, let's go down and find out who's grave it is.''
``How?''  ``By going down and finding out!'' "

Re: application level accept() filter for 1.3.x

[dean gaudet <dg...@arctic.org>]

i didn't read your patch i was just commenting on your comment that linux
didn't have accept filtering :)

an HTTP session goes like this:

client -> server:  SYN
server -> client:  SYN|ACK
client -> server:  SYN|ACK
   accept() succeeds here
client -> server:  data
   read() succeeds here

with the TCP_DEFER_ACCEPT and the "dataready" kernel filters, the
accept() is deferred until after that 4th packet is received.  as far
as i understand your patch, it defers passing the accepted socket to a
heavyweight httpd child until that 4th packet appears as well.

when i referred to "first packet" i actually meant that 4th packet... the
first packet of actual data transfer.  the first 3 are handshakes you
can't do much about.  (TTCP which lets data go in the first packet is not
secure / not useable on an open network.)

-dean

On Sun, 31 Dec 2000, Theo E. Schlossnagle wrote:

> I saw this...  I think this is great, though I haven't tested how well it work
> -- we don't run 2.4 anywhere yet.  As for comparing an application filter and
> a kernel filter, I don't see how an app filter (my patches specifically) won't
> perform as well.
>
> I don't do anything but a select on the accepted socket to see if there is
> data ready.  So it serves the same purpose but it doesn't live in the kernel,
> so it induces more context switching.  A kernel level filter, assuming it is
> written correctly, should beat the pants off my "parental accept" patch.
>
> MSIE and netscape can't send the data in the first packet right?  You have to
> send a few packets to establish the session first.  The problem is latency (of
> a modem or shotty network connection) between the establishment and that first
> data packet.
>
> Am I losing my mind?  I have seen this sort of thing frequently across very
> high traffic sites.
>
> With that said, if you are having lulls between connect() and read() on the
> server side and you OS doesn't support accept filtering.  The "parental
> accept" patch should solve the problem.
>
> dean gaudet wrote:
> > as of linux 2.4 there is a TCP_DEFER_ACCEPT option which behaves like
> > freebsd's "dataready" filter.
> >
> > i'd actually be curious to know how much the "http" filter actually gains
> > over just plain dataready... given that MSIE always sends the headers in
> > the first packet; and so does netscape unless its POSTing.  (netscape
> > splits the headers before the Content-Length/post body.)
>
> --
> Theo Schlossnagle
> 1024D/A8EBCF8F/13BD 8C08 6BE2 629A 527E  2DC2 72C2 AD05 A8EB CF8F
> 2047R/33131B65/71 F7 95 64 49 76 5D BA  3D 90 B9 9F BE 27 24 E7
>