Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]

Ted Faber <faber@ISI.EDU> Wed, 21 November 2007 21:37 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 1IuxGT-0007vR-JU; Wed, 21 Nov 2007 16:37:45 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IuxGR-0007vE-Ji for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:37:43 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxGR-0007v4-8t for tcpm@ietf.org; Wed, 21 Nov 2007 16:37:43 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuxGQ-0002jd-NO for tcpm@ietf.org; Wed, 21 Nov 2007 16:37:43 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lALLaAsE022200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 13:36:11 -0800 (PST)
Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lALLaAqn019212; Wed, 21 Nov 2007 13:36:10 -0800 (PST) (envelope-from faber)
Date: Wed, 21 Nov 2007 13:36:10 -0800
From: Ted Faber <faber@ISI.EDU>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Message-ID: <20071121213610.GH13024@hut.isi.edu>
References: <20071121192901.GF13024@hut.isi.edu> <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com>
Mime-Version: 1.0
In-Reply-To: <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com>
User-Agent: Mutt/1.4.2.3i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
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="===============0538219731=="
Errors-To: tcpm-bounces@ietf.org

Continuing to speak for myself.

On Wed, Nov 21, 2007 at 12:22:27PM -0800, Anantha Ramaiah (ananth) wrote:
> > 
> > It looks to me that there is considerable resistance to 
> > standardizing the proposed solution, both on the grounds of 
> > placement in the stack and on the limitations of the solution.  
> 
> Ok. That is the reason I pointed that, I believe the draft is not trying
> to "standardize" the solution part and that is informational and
> illustrational purpose only. 

I don't understand your snicker quotes around standardize.  Changing a
MUST NOT to a MAY or SHOULD NOT in 1122 is about as serious as
standardizarion effort as one can undertake in TCPM.

I (personally) don't see the point of publishing an RFC that describes
a technique that a conformant TCP cannot implement.

>                              It also mentions about the role of the
> application, which is again needed to be treated as informational. Do
> you see the need for making further clarifications that would make this
> look better?.

Section 3 of the draft is very hard to follow and is unclear on what's
being proposed.  If the work were taken up, I'd recommend rewriting it.

> > [ For example, connections that advertise a large initial 
> > window and then read a byte every (proposed timer size -1) 
> > seconds will replicate the problem in the limit. Using timers 
> > alone penalizes stopped connections when there is no resource 
> > shortage. ]
> 
> Good point. I would think that this is a non-standard behavior, corner
> case, why would an application do this in reality and how many times we
> have seen such behaviors? I don't want lengthy thread on this, but this
> is debatable, IMO.

While one might dismiss a legitimate connection holding a zero window
for a long time as a corner case (though doing so is projecting
application semantics into the transport), the more telling criticism is
the first case.

An attacker who wanted to mount the DoS attack described in the draft
could defeat your proposed mitigation by asking for the same large
window and then draining it slowly rather than simply holding the zero
window.  The draft mentions that the silly window avoidance makes this
difficult, but it just requires the attacker to ACK an MSS worth of data
less frequently then if they read a single byte.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm