IETF Logo Mail Archive

Re: [tcpm] TCP persist state issue.

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Wed, 02 July 2008 14:55 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 614503A6BCA; Wed, 2 Jul 2008 07:55:01 -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 CA1C43A687E for <tcpm@core3.amsl.com>; Wed, 2 Jul 2008 07:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.305
X-Spam-Level:
X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 8Rp2RsU8Oq1w for <tcpm@core3.amsl.com>; Wed, 2 Jul 2008 07:54:59 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E4DC43A6C7B for <tcpm@ietf.org>; Wed, 2 Jul 2008 07:54:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,737,1204502400"; d="scan'208";a="17166313"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2008 14:55:09 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m62Et9Pr001891; Wed, 2 Jul 2008 07:55:09 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m62Et7MY026005; Wed, 2 Jul 2008 14:55:09 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 07:55:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 02 Jul 2008 07:54:07 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC58056AE1FC@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <1e41a3230807012209j4a564e5bpd1b0b190c74e0ad1@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] TCP persist state issue.
Thread-Index: AcjcAcJC+GWbdDHFS1qYXfNCcrNsUAAT7+IQ
References: <0C53DCFB700D144284A584F54711EC58056ADBF7@xmb-sjc-21c.amer.cisco.com> <0C53DCFB700D144284A584F54711EC58056ADBFB@xmb-sjc-21c.amer.cisco.com> <1e41a3230807012209j4a564e5bpd1b0b190c74e0ad1@mail.gmail.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: John Heffner <johnwheffner@gmail.com>
X-OriginalArrivalTime: 02 Jul 2008 14:55:09.0395 (UTC) FILETIME=[9F5A4A30:01C8DC53]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2376; t=1215010509; x=1215874509; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20TCP=20persist=20state=20issue. |Sender:=20; bh=LU20eUKEV24C0z2+ynz0mxbIvPVfxIvfsQbCv7HXImw=; b=Uxi0wz9lw2ZhhWBIrpNlRcYaKbuozlyK3CamTOL97mZYnp5sFzQDAu3Y9K WE1r3m8SzPT0Hefu45VKKVki0eiU0SsPUOr6mKnn1FaFfXWrjgJ3fdremi6f IxgFSt4lRxyzfjSM7AANndYfVXo1gUZS5wY0CN0siAv7ysXn2PMnY=;
Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
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

Hi John,
   Thanks for your comments, Pl see inline. 

> -----Original Message-----
> From: John Heffner [mailto:johnwheffner@gmail.com] 
> Sent: Tuesday, July 01, 2008 10:09 PM
> To: Anantha Ramaiah (ananth)
> Cc: TCP Maintenance and Minor Extensions WG
> Subject: Re: [tcpm] TCP persist state issue.
> 
> 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).

Correct. The whole point of writing this draft is that there is
confusion w.r.t RFC 1122 verbiage which needed clarification. Atleast
there was some consensus to that. 
It focuses on persist state because that is where the clarification is
needed. Atleast that is the reading which was gathered after 60+ email
exchanges last time.

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

This will cause retransmissions from the server and eventually the
connection would timeout.

> slowly acks one byte at a time.
> Both have the same effect on the server, are fairly 
> straightforward, and neither advertise a zero window.

Slowly acking "one( or n << MSS) byte at a time" OR "ACK division
attack"  has other side effects too.. Like purposefully increase cwnd is
covered by ABC draft. 

Again, the purpose of this document is not about various scenarios and
solutions , it is written as an informational draft to clarifiy RFC 1122
verbiage w.r.t persist state. 

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

v2.23.0 | Report a Bug | By Email