Subject: Re: [tcpm] Is this a problem?

From: MURALI BASHYAM <[email-masked]>
Date: Mon, 5 Nov 2007 15:14:29 -0800 (PST)

----- Original Message ----
From: Joe Touch <[email-masked]>
To: Lloyd Wood <[email-masked]>
Cc: [email-masked]
Sent: Monday, November 5, 2007 1:27:52 PM
Subject: Re: [tcpm] Is this a problem?

Lloyd Wood wrote:
...
>> Yes, this is a problem for which a variety of solutions exist, and
 for
>> which a coordinated solution would be useful. No, that itself is not
>> justification for assuming TCP is the place to do this.
> 
> try this thought on for size:
> 
> "The need for congestion control is a problem for which a variety of
> solutions exist, and for which a coordinated solution would be
 useful.

I should have said "for which a variety of solutions in a variety of
places - OS, application, API, protocol - exist..."

The primary point is that this isn't owned by communications layers.

The point is that it can be solved in TCP or at the transport layer ALSO. It's as good a place
if not better (from the co-ordination point of view and from the sender state visibility points of view). 
Let me ask the question: Can you elaborate the reasons why doing it in TCP is not a good idea? 
"A variety of solutions in a variety of places" is not a good position to be in, we want the right
solution in the one, correct place, with the least possible disruption to the server community.

Joe

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Mon, 19 Nov 2007 08:35:29 -0500

[catching up]

> We have documented a case of HTTP servers that are prone to resource
> starvation with the use of a small user level program. The program
> does not require any special privileges or changes in the kernel. The
> user level program on the client opens a connection to a HTTP server,
> sends a GET request for a large file (larger than the advertised
> window of the client) but never reads the response.
> 
> Three well-known, public sites were tested for this vulnerability. The
> two most common HTTP servers, Apache and IIS were the target. While
> one site had put mitigation technique in place, the others had
> none. With the latter two we were able to hold connections in
> ESTABLISHED state for days. The former site had a mitigation in place
> with a fixed timeout of 11 min., which was easy to guess and work
> around. 

I want to try to understand these experiments.  You used your program
against public, well-known sites, right?  I also assume you did this in
a sort of "one at a time" fashion, right?  That is, you didn't beat
these web sites with a zillion of your test connections.  Am I right
here?

If I read all this right then I don't understand how you can claim that
two of the three sites used **no mitigation** for the problem you
describe.  It seems to me that they could well have a mitigation that
kicks in when their resources are in high-demand (this is a resource
contention problem after all) and your one "malicious" connection did
not send them to that state.  This, of course, may not be the case.
But, I don't see how you can make the above claim.

allman