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:25 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 1Iwglz-0002P2-TG; Mon, 26 Nov 2007 11:25:27 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwglz-0002Ov-17 for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:25:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgly-0002On-Nm for tcpm@ietf.org; Mon, 26 Nov 2007 11:25:26 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwgls-0002Ig-A6 for tcpm@ietf.org; Mon, 26 Nov 2007 11:25:26 -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 lAQGOs6d005137; Mon, 26 Nov 2007 08:24:54 -0800 (PST)
Message-ID: <474AF34B.40805@isi.edu>
Date: Mon, 26 Nov 2007 08:24:43 -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: <20071126161259.29EFA2FC343@lawyers.icir.org>
In-Reply-To: <20071126161259.29EFA2FC343@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: f60d0f7806b0c40781eee6b9cd0b2135
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="===============2136038378=="
Errors-To: tcpm-bounces@ietf.org


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.

Or can you find that in the requirements?

...
> It is absurd to me that a TCP (or any protocol) would allow a peer to
> indefinitely tie up a local resource without being subject to local
> policies on that resource.

It's very specifically in 1122. Local policies can kill applications,
but can't go around gleaning connections it *thinks* aren't useful.

If you want a new RFC that allows connection revocation, then it's
*definitely* a standards change.

I would favor a BCP that says that:

---
an OS under attack MAY terminate applications to recover their
resources, and the decision of which applications to terminate is a
matter of local policy. when such applications are terminated, their TCP
sessions would, as usual, be aborted
---

Note also that DOS attacks would likely not keep TCP connections around
with zero windows AND continue to ACK - they'd stop ACKing, the
connection would drop for *that* reason, and be recovered.

I would object to an RFC that allows TCP connection revocation to
compensate for not wanting to kill the apps.

Joe

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