Re: [tcpm] Is this a problem?

[Joe Touch <[e-mail]>]

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.
> 
> 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 agree with Caitlin and your previous responses; this is an application
problem.

> 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.

Applications know when a connection hasn't closed. They also know when a
write would block due to insufficient socket resources. Either or both
of these provide sufficient visibility to avoid the problem entirely.

As you note, applications can solve this easily. Since it's their
obligation to do so, and it's easy for them to do so, there's no reason
to complicate the transport layer with this responsibility.

Furthermore, does the propose solution solve the DOS problem? Aren't
there other ways to keep a source stalled? (i.e., what about continued
SACKs? or repeated ACKs indicating a lost segment? at the very least, we
could ACK a byte at a time, sending 3-4 duplicate ACKs for each byte,
which would keep the sender from opening its window and stall things a
lot...).

Joe

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