Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited
Stefanos Harhalakis <v13@v13.gr> Fri, 01 August 2008 10:07 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 52C803A6D8C; Fri, 1 Aug 2008 03:07:25 -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 2EDDF3A6D8E for <tcpm@core3.amsl.com>; Fri, 1 Aug 2008 03:07:24 -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 rspzwdRt1Ig6 for <tcpm@core3.amsl.com>; Fri, 1 Aug 2008 03:07:23 -0700 (PDT)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by core3.amsl.com (Postfix) with ESMTP id E48143A6D8C for <tcpm@ietf.org>; Fri, 1 Aug 2008 03:07:22 -0700 (PDT)
Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id m71A7NE5022122; Fri, 1 Aug 2008 13:07:23 +0300
Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-06.forthnet.gr (8.14.3/8.14.3) with ESMTP id m71A74YH021905; Fri, 1 Aug 2008 13:07:05 +0300
Received: from hell.hell.gr (adsl69-188.lsf.forthnet.gr [79.103.196.188]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m71A6uF0015729; Fri, 1 Aug 2008 13:06:58 +0300
Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral
Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@v13.gr; sender-id=neutral
From: Stefanos Harhalakis <v13@v13.gr>
To: tcpm@ietf.org
Date: Fri, 01 Aug 2008 13:06:40 +0300
User-Agent: KMail/1.9.9
References: <4892063D.3010703@cisco.com>
In-Reply-To: <4892063D.3010703@cisco.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200808011306.40543.v13@v13.gr>
Cc: Caitlin Bestler <Caitlin.Bestler@neterion.com>
Subject: Re: [tcpm] Persist condition clarification draft, now "clarification of sending behavior" draft - comments solicited
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
I'm resending this as a reply to the 'new' thread just to change the spammy subject. Sorry for the duplicate. On Thursday 31 July 2008, Caitlin Bestler wrote: > Is an RFC really needed? > > I've always assumed that the application layer MAY > do pretty much whatever it wants. Further application > layer servers SHOULD protect their own resources against > abusive clients. Those protection mechanisms MAY include > terminating connections. > > All of that is true independent of any specific method > of abusing server resources. Since this is an OS issue that will affect all running applications and it is impossible to ensure that all TCP-listening applications won't be exploitable, I believe it is best to take some (customizable) measures at the OS side too (if understand correctly, that's what the resource management entity, even if it is implemented as a user-space part). Of course any application is able to enforce stricter rules. Apart from that, I believe that the problem is not well defined. I don't exactly understand what differentiates a zero sized window with a one-byte window, etc... Transferring a 1MB file with 1-byte window is essentially the same (no?). It is also almost the same as never acking the last data segment and sending dup-acks for the previous for some time, or just acking 1 byte every N retransmits, etc... Where exactly do you draw the line? Taking a broader look, since TCP's fundamental assumption is that the remote end is trustworthy, perhaps it is better to look at this and other TCP attack methods as a resource allocation problem and handle it as such. Most of the time there won't be such an issue but in cases of an attack, there can be algorithms that "evenly" allocate the shared resource (like available sockets or available buffer space). Also, to my knowledge there are cases where it is impossible to distinguish between legitimate behavior and malicious behavior. Most probably, taking at look at the shared resource approach will solve this and perhaps other future problems too that can be caused by attacks or legitimate remote-ends. At the end, we may only need to point to that problem and indicate what a good policy is made of. Nonce? p.s. I'll be away from keyboard for the next two weeks (starting tomorrow) so please excuse any delayed replies. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] Persist condition clarification draft, now… Mahesh Jethanandani
- Re: [tcpm] Persist condition clarification draft,… Stefanos Harhalakis
- Re: [tcpm] Persist condition clarification draft,… Caitlin Bestler
- Re: [tcpm] Persist condition clarification draft,… Eddy, Wesley M. (GRC-RCN0)[VZ]