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

Mark Allman <mallman@icir.org> Mon, 26 November 2007 19:38 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 1Iwjmz-0002TL-7B; Mon, 26 Nov 2007 14:38:41 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwjmx-0002TG-E5 for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:38:39 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjmx-0002T7-3J for tcpm@ietf.org; Mon, 26 Nov 2007 14:38:39 -0500
Received: from pork.icsi.berkeley.edu ([192.150.186.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwjmw-0003BY-IY for tcpm@ietf.org; Mon, 26 Nov 2007 14:38:39 -0500
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id lAQJcbcC007171; Mon, 26 Nov 2007 11:38:37 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 6293C1263D7A; Mon, 26 Nov 2007 14:38:32 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 585E12FC5BE; Mon, 26 Nov 2007 14:38:03 -0500 (EST)
To: Joe Touch <touch@ISI.EDU>
From: Mark Allman <mallman@icir.org>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
In-Reply-To: <474AFB2A.9080504@isi.edu>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Walk on the Wild Side
MIME-Version: 1.0
Date: Mon, 26 Nov 2007 14:38:03 -0500
Message-Id: <20071126193803.585E12FC5BE@lawyers.icir.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
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="===============0008497595=="
Errors-To: tcpm-bounces@ietf.org

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

Yep.

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

Yep.

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

I agree that you cannot tell the difference, per se.  But, IMO, one can
look around at the context and make a good guess and accept the
collateral damage.  I.e., if I see a zillion of these ZWP connections
when I normally see ~none I could decide that this is an attack and take
what I consider appropriate actions, knowing full well that everything
in the class of connections may not be an attack.

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

That's great, but the problem with that is that an application hasn't
the context of the underlying TCP or OS.  Clearly you could feed
something to the app that says "kill some connections" and the apps
might or might not.  So, that might or might not solve the problem and
it is more complicated and depends on much more software being right. 

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

I see a TCP solution as being within the scope of the 1122 we have.

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

I can't even believe I am having this discussion, Joe.  It isn't the app
that is DoS-ed.

Like I said: you and I are not going to agree about how to interpret
RFC112 (in 2007).  It would be good to hear other opinions.

allman



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