Re: Hardening the TCP/IP Stack Qt. - KeepAliveTime

From: Ray (res0cu5i@verizon@net)
Date: 03/20/03 

From: "Ray" <res0cu5i@verizon@net>
Date: Thu, 20 Mar 2003 11:42:24 -0500

    This clears up a few things up, but open up some too. Is this parameter
relevant to SYN attack? From my understanding, the session is never fully
established (during a SYN attack). Would this be more useful against an
enormous amount of spoofed addresses (it seems there are more feasible
attack vectors)? Or is this parameter added in to "round out" hardening the
(tcp/ip) stack?
    Thanks for wealth of info you've provided.
Ray

"Keith W. McCammon" <km@km.com> wrote in message
news:OIV#X0v7CHA.2308@TK2MSFTNGP10.phx.gbl...
> > This brings up a couple more questions. I've configured the Web
> server
> > as follows: ISM | WWW Service | Edit | Web site tab | Connection Timeout
=
> > 300 seconds| & Home Directory tab | Configuration | App Options Tab |
> > Session timeout = 5 minutes. I was under the impression these settings
> were
> > all different.
>
> They are.
>
> > For instance the TCP resources would be held (by default)
> > for 2 hours while the http connection resources (10 kb per connection)
> would
> > be for 5 minutes (15 by default but I reduced it).
>
> TCP resources are not held for two hours. A single HTTP 1.0 GET opens a
TCP
> connection, makes the request, receives the reply, and then closes the TCP
> connection. HTTP 1.1, on the other hand, uses HTTP keep-alives by
default.
> When HTTP keep-alives are used, multiple GET requests could be sent via
the
> same TCP connection, reducing the overhead of opening multiple TCP
> connections between the same hosts.
>
> In either case, an HTTP connection that is not used for 900 seconds (600
in
> your case) would be actively closed by IIS, thus closing the TPC
connection
> as well.
>
> > In addition, the App
> > Session State was something else too.
>
> App session state controls application-side sessions created using ASP,
PHP,
> etc. These are entirely different that both TCP and HTTP sessions.
> Application sessions are used within the web-based application to track
> users and store information associated with a user's visit. These can be
> created by using the ASP session object, cookies, etc.
>
> > Maybe if you had an example of an
> > application that did not close the connection after the transaction was
> > complete.
>
> Can't think of one off the top of my head, because most day-to-days apps
> would close a session once a given transaction was complete. Maybe
someone
> else will chime in on this...
>
> > I think what adds to my confusion is that http is stateless.
>
> It is.
>
> > From that, I assume that the http (layer 7) session will be closed while
> the
> > tcp (layer 4) will still allocate the resources until 2 hours has
expired
>
> In theory, this could happen. However, client/server implementations
> provide for interaction with the TCP that let it know when a session is no
> longer needed. If the two were entirely separate, and every TCP-based app
> just allowed every connection to linger for the maximum segment lifetime,
> memory use would be out of hand. Part of implementing these types of
> applications involves issuing timely calls to the TCP.
>
> --
> Keith W. McCammon
>
>
>

Relevant Pages