RE: [tcpm] DoS attack from misbehaving receivers

"Caitlin Bestler" <caitlinb@broadcom.com> Sat, 13 January 2007 01:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5XOV-0005sw-Nn; Fri, 12 Jan 2007 20:09:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5XOT-0005so-Ug for tcpm@ietf.org; Fri, 12 Jan 2007 20:09:13 -0500
Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5XOS-0007wK-I8 for tcpm@ietf.org; Fri, 12 Jan 2007 20:09:13 -0500
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Fri, 12 Jan 2007 17:08:54 -0800
X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id F30A12AF; Fri, 12 Jan 2007 17:08:53 -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 CA25F2AE; Fri, 12 Jan 2007 17:08:53 -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 ETJ03338; Fri, 12 Jan 2007 17:08:49 -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 10D6A20501; Fri, 12 Jan 2007 17:08:49 -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: Fri, 12 Jan 2007 17:05:20 -0800
Message-ID: <54AD0F12E08D1541B826BE97C98F99F1025E8B@NT-SJCA-0751.brcm.ad.broadcom.com>
Thread-Topic: [tcpm] DoS attack from misbehaving receivers
Thread-Index: Acc2QYwgSlCVYNsBTHyXNG8Pq2WfFQAbVmQ8
References: <200701121201.l0CC1tnv002619@kac.cnri.dit.ie>
From: Caitlin Bestler <caitlinb@broadcom.com>
To: David Malone <David.Malone@nuim.ie>, Gavin McCullagh <gavin.mccullagh@nuim.ie>
X-WSS-ID: 69B6EEAC3S41140981-01-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
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>
Errors-To: tcpm-bounces@ietf.org



-----Original Message-----
From: dwmalone@cnri.dit.ie on behalf of David Malone
Sent: Fri 1/12/2007 4:01 AM
To: Gavin McCullagh
Cc: Rob Sherwood; Caitlin Bestler; tcpm@ietf.org
Subject: Re: [tcpm] DoS attack from misbehaving receivers
 
> We implemented a basic attack of this recently before realising that others
> had been here first.  I've thrown up a few quick results here using a
> recent linux kernel on sender and receiver:

> 	http://www.hamilton.ie/gavinmc/drop_dupack_attack/

Note, while this was in the lab, we achieved similar results in the
wild. Using a clean Linux+Apache install over the Internet, we
convinced Apache to send a large file at 80Mbps to a host with a
1Mbps access link.  In light of some of the recent discussion on
Bugtraq, we probably don't really even need the large file.

We'd also arrived at basically the same fix as suggested by Rob.
Would it be interesting to see the fix written up as a draft, so
technical issues surrounding it can be identified? Certainly, some
care is required in the details of the fix to avoid introducing
other attacks on TCP. (It could fit naturally as an additional fix
section in draft-azcorra-tcpm-tcp-blind-ack-dos?)

	David.

------------------------

Documenting the attack is definitely a good idea, and I agree
that it is essentially a blind ack attack (even though it is a 
partial blindness, since *some* of the send segments reach
the attacker).

But I still don't see doing anything non-standard in the TCP
stack as a counter-measure.

Single flows of over 10 Mbits being sent to a stranger over
the wide internet can be easily flagged at many different 
layers.

Keep in mind that *any* form of rate shaping will severely
impact this attack because the attacker will no longer be able
to predict the timing of tcp sequences.

Slightly random rate shaping has no impact on TCP, and
could easily be just as effective.





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