Re: [tcpm] Is this a problem?

Mahesh Jethanandani <mahesh@cisco.com> Tue, 30 October 2007 08:05 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 1Imm60-0006EQ-FS; Tue, 30 Oct 2007 04:05:08 -0400
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Imm5y-0006E9-W6 for tcpm-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 04:05:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imm5t-0006As-F9 for tcpm@ietf.org; Tue, 30 Oct 2007 04:05:01 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imm5n-0004zC-8z for tcpm@ietf.org; Tue, 30 Oct 2007 04:05:01 -0400
X-IronPort-AV: E=Sophos;i="4.21,346,1188802800"; d="scan'208";a="244277376"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Oct 2007 23:46:02 -0700
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9U6k2Bm002278; Mon, 29 Oct 2007 23:46:02 -0700
Received: from [10.21.106.209] (sjc-vpnasa-718.cisco.com [10.21.106.209]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l9U6k1lX014411; Tue, 30 Oct 2007 06:46:01 GMT
Message-ID: <4726D328.4040209@cisco.com>
Date: Mon, 29 Oct 2007 23:46:00 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
Subject: Re: [tcpm] Is this a problem?
References: <472654F9.5030308@cisco.com> <472661E1.9020805@isi.edu>
In-Reply-To: <472661E1.9020805@isi.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2319; t=1193726762; x=1194590762; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:=20Mahesh=20Jethanandani=20<mahesh@cisco.com> |Subject:=20Re=3A=20[tcpm]=20Is=20this=20a=20problem? |Sender:=20; bh=Foc0APi3BGn2TkO9E04nvIorsnRKnPqdZvMR/MtK634=; b=BQWDUdRQYMf/tz0D2GpT7gwmgNlmVFaC42jR5TSP7JHrgbuzq/ck5BatG8inQm403QXpR1+6 NwZAT/6kXP8e/j4ABPokcb4e/hfLc/2Z+g8XjDEVCJVEi0bKRXqKIE/H;
Authentication-Results: sj-dkim-3; header.From=mahesh@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
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>
Errors-To: tcpm-bounces@ietf.org


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

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. Looking into the 
TCP connection state allows us to differentiate between the two 
different conditions and treat the connections fairly.
> 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. 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.

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


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