Re: [tcpm] TCP zero window timeout?

Mahesh Jethanandani <mahesh@cisco.com> Mon, 28 August 2006 23:49 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqrY-0004Yv-PN; Mon, 28 Aug 2006 19:49:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHqrX-0004Yp-AF for tcpm@ietf.org; Mon, 28 Aug 2006 19:49:51 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqrW-0003Nz-0T for tcpm@ietf.org; Mon, 28 Aug 2006 19:49:51 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2006 16:49:49 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SNnnkg005436; Mon, 28 Aug 2006 16:49:49 -0700
Received: from [10.34.37.171] ([10.34.37.171]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7SNnm1E016917; Mon, 28 Aug 2006 16:49:48 -0700 (PDT)
Message-ID: <44F3811C.70209@cisco.com>
Date: Mon, 28 Aug 2006 16:49:48 -0700
From: Mahesh Jethanandani <mahesh@cisco.com>
Organization: Cisco Systems Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: [tcpm] TCP zero window timeout?
References: <7.0.1.0.0.20060826070050.062ba618@gont.com.ar> <20060826230546.41460.qmail@web31713.mail.mud.yahoo.com> <7.0.1.0.0.20060828174420.07977518@gont.com.ar>
In-Reply-To: <7.0.1.0.0.20060828174420.07977518@gont.com.ar>
Content-Type: multipart/mixed; boundary="------------090104060508010207040709"
DKIM-Signature: a=rsa-sha1; q=dns; l=2265; t=1156808989; x=1157672989; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mahesh@cisco.com; z=From:Mahesh=20Jethanandani=20<mahesh@cisco.com> |Subject:Re=3A=20[tcpm]=20TCP=20zero=20window=20timeout?; X=v=3Dcisco.com=3B=20h=3DqMMY8yA42yCrNp4dBnJrPBJCEUQ=3D; b=hVO+btT8Y2WJCY2FMm6T8f5V+RkfCqVUks8Y3tW8oS/I9qEjvVwR+a4lBZPovEExwC9NU5NB JCdmsxkaR5xCwRHMfv7Ig4rPNIPTAFDSj28SJDhD3UuspHSuklPHyo+W;
Authentication-Results: sj-dkim-4.cisco.com; header.From=mahesh@cisco.com; dkim=pass ( 44 extraneous bytes; sig from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: "Mahdavi, Jamshid" <jamshid.mahdavi@bluecoat.com>, tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>
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


Fernando Gont wrote:

> In the case of zero window, as far as TCP is concerned, there's 
> nothing wrong with an endpoint advertising a zero window. And you do 
> know that packets are getting to the remote TCP endpoint (that's why 
> you are getting the advertisements, after all).

The problem with the client advertising a zero window is that it lends 
itself to a DOS attack. The problem is particularly bad if you are 
dealing with thousands of connections each of them chewing up connection 
blocks and TCP data buffers. That is what happened in the particular 
customer scenario.

>> The problem is that
>> TCP has a persist state which can potentially exist
>> infinitely long  and which lends itself to abuse by a
>> malicious peer.
>
>
> This is the same thing as saying that there should be an "idle 
> connection timeout", because a connection can be opened, and no data 
> needs to be transmitted on the connection for the connection to be 
> kept open.

But you would agree that a large number of idle connections without a 
idle timeout is a problem for any TCP implementation.

>
> That said, some upper limit on the number of window-probes might not 
> hurt, but then you get into which value to use.
> If too small, you may kill legitimate users. If too long, it may be 
> useless.

If we agree that a limit is required on the number of probes then we can 
move to discussing how to implement that, what its default value should 
be and whether that value can be changed by the user etc.

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