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

Joe Touch <touch@ISI.EDU> Mon, 26 November 2007 16:59 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 1IwhIU-0007er-Fi; Mon, 26 Nov 2007 11:59:02 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwhIT-0007eh-GR for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:59:01 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhIT-0007eA-5R for tcpm@ietf.org; Mon, 26 Nov 2007 11:59:01 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwhIS-00069t-JJ for tcpm@ietf.org; Mon, 26 Nov 2007 11:59:01 -0500
Received: from [192.168.1.46] (pool-71-106-88-149.lsanca.dsl-w.verizon.net [71.106.88.149]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lAQGwSL3016145; Mon, 26 Nov 2007 08:58:29 -0800 (PST)
Message-ID: <474AFB2A.9080504@isi.edu>
Date: Mon, 26 Nov 2007 08:58:18 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: mallman@icir.org
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
References: <20071126163305.326192FC402@lawyers.icir.org>
In-Reply-To: <20071126163305.326192FC402@lawyers.icir.org>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
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="===============0537265008=="
Errors-To: tcpm-bounces@ietf.org


Mark Allman wrote:
>> Mark Allman wrote:
>>> Joe-
>>>
>>> You and I are just going to disagree.
>>>
>>>> That OS is required to reserve per-connection resources when
>>>> connections are created. It can halt new connections.
>>> If this is the general reading of the spec then TCP has a built-in DoS
>>> vulnerability that we need to fix.
>> There's nothing in TCP that says that new connections will ALWAYS
>> succeed.
> 
> Can you find a prohibition on connections failing?
> 
> Joe, you surely see the problem, right?

I see an OS that has to decide how to allocate resources:

	a- leave them with existing apps and prohibit new ones

	b- terminate existing apps to make room for new ones

I expect that a reasonable, modern OS would do (a).

> I am not saying that new
> connections always have to succeed.  I am saying that if the spec allows
> for a case whereby an attacker can coax a host into a state whereby all
> new connections will fail that is a DoS attack.  Do you disagree with
> that?

I agree that attackers, as well as legitimate users, can consume local
resources on servers, and that such consumption can reach a limit beyond
what the server can support.

The question is "what do you do when you run out of resources?"

TCP allows killing connections where the other end doesn't respond, via
timeouts. We're all talking about what to do when the attacker is
willing to commit more resources, i.e., to keep ACKing, or even just go
very slowly.

IMO, under those conditions you cannot know the difference between a
legitimate user and an attacker. Under those conditions, 1122
specifically claims that not making progress due to an ACKd zero window
isn't a connection failure.

IMO, the application (i.e., service) ought to determine when to give up
on a connection, and issue ABORTs.

That solves the problem entirely and is entirely within the scope of
1122 as it currently exists.

I don't agree that the OS has any business terminating connections to
make up for poorly-written, and thus DOS-susceptible applications, or
that 1122 should be modified to either permit or encourage this sloppy
handling of DOS attacks.

Joe

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