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

From: MURALI BASHYAM <[email-masked]>
Date: Fri, 2 Nov 2007 00:00:22 -0700 (PDT)

Clearly there seems to be no consensus on where the problem lies.  I've heard that it's not a transport problem, and that the responsibility for mitigating the problem lies with a) sockets API, b) OS, and
c) the application. That's as varied a response as one can get...

It seems to me that all of these approaches have a key flaw in that they leave the solution to be handled by a proprietary method of defending against the attack. Solving the problem in the transport layer would make the solution a standard one and applicable to environments a) where the standard BSD socket API is not the transport layer interface of choice, b) would work for user space or kernel-less TCP implementations such as TCP proxies and hence would not have to depend on the OS, and c) certainly would not have to be at the mercy of the plethora of TCP based applications out there which have not done anything abt it so far and are making the entire server vulnerable in the process.

----- Original Message ----
From: John Heffner <[email-masked]>
To: Mahesh Jethanandani <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, October 30, 2007 11:58:58 AM
Subject: Re: [tcpm] Is this a problem?

Mahesh Jethanandani wrote:
> Folks,
> 
> 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.

This problem has been well documented for at least seven years.
http://shlang.com/netkill/
http://shlang.com/netkill/20000421-netkill-bugtraq-announcement.txt

> 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.
> 
> We (the authors) believe that this is a huge problem. What do you
 folks feel?

I personally believe it is a problem, but the absence of wide-spread 
attacks using this technique leads me to believe that other attacks are
 
still more effective.  All the same, I would like to see more
 widespread 
defense against it.

> Previous responses to this documentation has been that it is a
 application problem. It is clear from our experimentation that most HTTP
 servers (and FTP too) have not implemented any mitigation techniques. We
 believe that this problem exists across the whole range of TCP based
 applications prevalent on the internet, although our experiments were
 limited to the web application. Where applications have tried to put
 mitigation techniques in place, workaround has been easy. This is mainly
 because applications do not have the same amount of visibility as TCP does
 on the state of the connection.

I think nearly all responses (including mine) have been of the opinion 
that this is not a transport problem.  However, I think this is not 
necessarily an application problem, either.  Since the contended 
resource is system memory, the best place to implement a fairness
 policy 
is in the operating system -- possibly but not necessarily in the
 kernel 
(for OS's where such a distinction applies).

   -John

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

__________________________________________________
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: [email-masked](speakeasy)
Date: Fri, 2 Nov 2007 00:20:04 -0700

On Nov 2, 2007, at 12:00 AM, MURALI BASHYAM wrote:

>
> Clearly there seems to be no consensus on where the problem lies.   
> I've heard that it's not a transport problem, and that the
> responsibility for mitigating the problem lies with a) sockets API,  
> b) OS, and

There is no need for TCPM to decide which of the three is the best  
solution, since all
three solutions can interoperate on the wire.

The fact that this behavior is not specified by TCP is actually a  
strength. It allows different
hosts to use very different stack strategies. Even for web servers one  
size does not fit all.
What makes sense for a high volume site supporting a large number of  
virtual sites does
not make sense for an embedded web server in a home router that  
supports configuration.

And once you vary the ULP the variations get even greater.

You need to find a more narrowly focused forum that can judge whether  
the proposed
solutions are proper for Web servers (or whatever). But these are all  
issues that the
transport layer needs to avoid.

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Nov 2007 15:26:24 -0700

speakeasy wrote:
>> responsibility for mitigating the problem lies with a) sockets API, b)
>> OS, and

I agree - the fact that these all vary is less important to TCPM than
the fact that none have anything to do with TCP.

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.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Nov 2007 07:31:14 -0800

Lars Eggert wrote:
> Hi,
> 
> attached is a diff between -06 and my current working copy, to let the
> WG know about the changes I've made so far to address WG last call
> comments.
> 
> There were some suggestions discussed in response to Joe's and Alfred's
> comments that I haven't made, because the rest of the WG was silent,
> which I interpreted as lack of consensus for the change. Speak up if you
> disagree with this resolution.

PS - could you provide a brief list of those suggestions?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Nov 2007 07:31:14 -0800

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 05 Nov 2007 21:16:13 +0000

>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. No, that itself is not justification for assuming TCP is the place to do this."

...but congestion control was put in TCP _anyway_. I still don't see what output behaviour algorithms have to do with on-the-wire header layout specifications, but that is all that is being discussed here.

L.

Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Nov 2007 13:27:52 -0800

Lloyd Wood wrote:
...
> "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.

Joe

---

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

> Clearly there seems to be no consensus on where the problem lies.

That is my read of this thread.

> It seems to me that all of these approaches have a key flaw in that
> they leave the solution to be handled by a proprietary method of
> defending against the attack. Solving the problem in the transport
> layer would make the solution a standard one 

I think a key question here is whether we need a standard solution.  If
this were solved in a 'proprietary' manner, why would that be a big
deal?  I don't understand this notion that we need some sort of standard
behavior here.  Please explain.

allman