Re: [tcpm] Is this a problem?

Joe Touch <touch@ISI.EDU> Tue, 30 October 2007 13:33 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrDP-0004gJ-1Z; Tue, 30 Oct 2007 09:33:07 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1ImrDO-0004gD-Er for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 09:33:06 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImrDO-0004g5-49 for tcpm@ietf.org; Tue, 30 Oct 2007 09:33:06 -0400
Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImrDN-0003LF-Eg for tcpm@ietf.org; Tue, 30 Oct 2007 09:33:06 -0400
Received: from [192.168.1.44] (pool-71-106-89-188.lsanca.dsl-w.verizon.net [71.106.89.188]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id l9UDWjfx013221; Tue, 30 Oct 2007 06:32:45 -0700 (PDT)
Message-ID: <47273276.4050300@isi.edu>
Date: Tue, 30 Oct 2007 06:32:38 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mahesh Jethanandani <mahesh@cisco.com>
Subject: Re: [tcpm] Is this a problem?
References: <472654F9.5030308@cisco.com> <472661E1.9020805@isi.edu> <4726D328.4040209@cisco.com>
In-Reply-To: <4726D328.4040209@cisco.com>
X-Enigmail-Version: 0.95.4
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0911613191=="
Errors-To: tcpm-bounces@ietf.org


Mahesh Jethanandani wrote:
> 
> 
> Joe Touch wrote:
>> 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.
>>   
> Knowing those two facts only gives applications some of the information.
> It still would not know why the write is blocked? You agree that
> penalizing legitimate connections is a broken implementation. 

My point is that your solution does this.

> How does
> application then differentiate between a legitimate connection that is
> slow and one that is malicious (by advertising a zero window for an
> extended period of time)?

Since it never can, it shouldn't try. It depends on the application.
That's why it's the application's decision as to when to give up on a
client, not TCP's.

> It is important to understand that a slow legitimate connection is a
> behavior that is almost entirely contained within TCP but the client
> sending zero window can be a case of a malicious user level program
> (read externally triggered attack) not reading data. 

I agree that sending a zero window CAN be an attack. Unfortunately, it
CAN be legitimate behavior.

Since you agree we can't decide between the two at the TCP layer, we
should not fix this at that layer either.

> Looking into the
> TCP connection state allows us to differentiate between the two
> different conditions and treat the connections fairly.

You are asserting that "all zero-window receivers are attackers". This
is incorrect, and leading you to the conclusion that TCP should fix this.

A legitimate receiver could have a backed-up application - i.e., a slow
processor, more pressing other applications, etc. - which could cause it
to advertise a zero window for an arbitrary time.

There is no requirement of timeliness in TCP data processing. When data
arrives at the receiver, if it backs up, the receiver could send a zero
window. That condition could legitimately persist a long time - I gave a
real example before (a backup device waiting for a human to insert a new
DVD).

>> 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.
>>   
> The reality is that few applications if any implement any mechanism to
> detect a connection that is stalled in such a manner.

I agree. That doesn't make it TCP's responsibility.

> Our experiment
> shows that  the most commonly used application (HTTP) used on some of
> the biggest web sites are vulnerable today holding on to connections in
> EST state for days. Yes, they should implement a mechanism, but can TCP
> count on it. What is it supposed to do if applications do not clear
> connections in a timely manner.

TCP is the servant of the application, not its master. If the
application doesn't clear connections TCP should - and must - sit and wait.

>> 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...).
>>   
> You are talking about a malicious TCP implementation that would require
> special permissions in a DDoS scenario. What we used was a simple user
> level program that required no special privileges to run.

Yes, but as I've shown, your case is indistinguishable from legitimate
behavior. Let's not 'fix' that.

Joe

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm