Re: [tcpm] TCP persist state issue.

"John Heffner" <johnwheffner@gmail.com> Wed, 02 July 2008 05:08 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8583A6845; Tue, 1 Jul 2008 22:08:59 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC423A6845 for <tcpm@core3.amsl.com>; Tue, 1 Jul 2008 22:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmFgyLJrLiwM for <tcpm@core3.amsl.com>; Tue, 1 Jul 2008 22:08:57 -0700 (PDT)
Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id 3B6293A67FC for <tcpm@ietf.org>; Tue, 1 Jul 2008 22:08:57 -0700 (PDT)
Received: by an-out-0708.google.com with SMTP id d18so81431and.122 for <tcpm@ietf.org>; Tue, 01 Jul 2008 22:09:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=mQ5kmK6OKsR9GH0FW494dhrqxLUCXhMC+RMTp3ATxUk=; b=ceA1Hi3Y4f995tZ9DxCkft68uc9zmB6bqSgliv9yD2Zg4kE6ykf9bgK1TCLPf51lIn sN+OTC59r62V3dB189Js0CAt0DwxFsEeOy7oBUGng59k7mz7yiIbnhg/2DgkIFEC0Qe+ DelHL1kEFxFXHI5aZqlAe8JLQq3G7yIyh3trc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=eHQocasZpL9by/1Ok5KUblEqUEGM+36rMdS4n57uGtY8lwIjwRmjiHNt2O9R0JN17H 8513SRgFxD7qeFbrwkrzm6LUPyuWqKhruWM0Lgze87K9+wFQSmr7GyQ4k6W77X7LUIsL zQlKnyaxPkD6l/SZuAal5Imed6bD+ASQIlPQQ=
Received: by 10.100.3.4 with SMTP id 4mr5915698anc.54.1214975342964; Tue, 01 Jul 2008 22:09:02 -0700 (PDT)
Received: by 10.100.135.3 with HTTP; Tue, 1 Jul 2008 22:09:02 -0700 (PDT)
Message-ID: <1e41a3230807012209j4a564e5bpd1b0b190c74e0ad1@mail.gmail.com>
Date: Tue, 01 Jul 2008 22:09:02 -0700
From: John Heffner <johnwheffner@gmail.com>
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
In-Reply-To: <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com>
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] TCP persist state issue.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On Mon, Jun 30, 2008 at 10:44 PM, Anantha Ramaiah (ananth)
<ananth@cisco.com> wrote:
>> You can find the copy of the first draft at :
>> http://www.ietf.org/internet-drafts/draft-ananth-tcpm-persist-00.txt.
>> Comments welcome.


As with the previous draft, I think the greatest weakness of this one
is that it focuses so much on the persist state.  The conclusion
states, "The document addresses the fact that terminating TCP
connections stuck in the persist condition does not violate any RFC."
But isn't this statement also true without the condition that
connections are "stuck" in persist?  That is, terminating a connection
at any time is allowed, regardless of its state (see RFC 793, section
3.8, the ABORT command).

And again, I think the persist state has fairly little to do with the
more general DoS issue.  Consider the following: a client that,
instead of shrinking its window to zero, simply stops ACKing after
sending the request, or a client that slowly acks one byte at a time.
Both have the same effect on the server, are fairly straightforward,
and neither advertise a zero window.

  -John
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm