RE: [tcpm] DoS attack from misbehaving receivers

"Caitlin Bestler" <caitlinb@broadcom.com> Thu, 11 January 2007 20:05 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56Ao-0005ys-Oo; Thu, 11 Jan 2007 15:05:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H56An-0005ye-GQ for tcpm@ietf.org; Thu, 11 Jan 2007 15:05:17 -0500
Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H56Am-00041Y-4M for tcpm@ietf.org; Thu, 11 Jan 2007 15:05:17 -0500
Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Thu, 11 Jan 2007 12:02:19 -0800
X-Server-Uuid: 9206F490-5C8F-4575-BE70-2AAA8A3D4853
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 83E1B2AF; Thu, 11 Jan 2007 12:02:19 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 5C7342AE; Thu, 11 Jan 2007 12:02:19 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id ETE57324; Thu, 11 Jan 2007 12:01:28 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 9B4D920502; Thu, 11 Jan 2007 12:01:28 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [tcpm] DoS attack from misbehaving receivers
Date: Thu, 11 Jan 2007 12:00:59 -0800
Message-ID: <54AD0F12E08D1541B826BE97C98F99F1EE6E3A@NT-SJCA-0751.brcm.ad.broadcom.com>
In-Reply-To: <20070111105348.546de25e@freekitty>
Thread-Topic: [tcpm] DoS attack from misbehaving receivers
Thread-Index: Acc1sfgl/tcq6oX2TC2xki56IGehMAACHGTw
From: Caitlin Bestler <caitlinb@broadcom.com>
To: Stephen Hemminger <shemminger@osdl.org>, tcpm@ietf.org
X-WSS-ID: 69B848412CC19647350-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: david.malone@nuim.ie
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>
Errors-To: tcpm-bounces@ietf.org

Stephen Hemminger wrote:
> Has anyone in this group explored the problems described in:
> "Misbehaving TCP Receivers Can Cause Internet-Wide Congestion
> Collapse"? 
> 
> 	http://www.cs.umd.edu/~capveg/optack/optack-ccs05.pdf
> 	http://www.cs.umd.edu/~capveg/
> 	http://www.kb.cert.org/vuls/id/102014
> 
> A possible solution (optack) is described in the paper that
> involves the sender randomly skipping segments and resetting
> connections that ACK data that was never sent.  But it is not
> clear that the impacts of such a change have been fully investigated.
> 
> Comments?
> 

The proposed test for a non-compliant receiver would seem to
require that the sender be non-compliant itself.

For many of the applications cited, wouldn't a more general
solution be to apply connection-specific rate limiters at
the sender (in the stack or at the application layer)?


Even if one client could truly receive at full line rate,
is is truly wise at the application layer to agree to give
all of your capacity to one client when hundreds or thousands
of clients are anticipated?



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