Subject: RE: [tcpm] DoS attack from misbehaving receivers

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 12 Jan 2007 17:05:20 -0800

-----Original Message-----
From: [email-masked] on behalf of David Malone
Sent: Fri 1/12/2007 4:01 AM
To: Gavin McCullagh
Cc: Rob Sherwood; Caitlin Bestler; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: David Malone <[email-masked]>
Date: Sat, 13 Jan 2007 10:52:37 +0000

> partial blindness, since *some* of the send segments reach

Yes - indeed. This is kind of important, because it means that the
defences currently described in draft-azcorra-tcpm-tcp-blind-ack-dos
will not be effective.

> the wide internet can be easily flagged at many different 

Sometimes this is not so easy - some people want to ship 10Mbps
streams to those that can receive them but do not want send them
to people for whom it will cause congestion (for example, people
providing mirror services). I guess it could be flagged by the
network, but few people want routers to send source quench messages
any more ;-)

To me it seems natural to address this at the TCP layer because it
is essentially an attack on TCP's congestion control mechanism.

> to predict the timing of tcp sequences.

There's no prediction involved in the attack that we were demoing
- it is entirely deterministic. We just send an ACK for every packet
we get, providing the sequence number is higher than the previous ACK
that we sent.

	David.

---

From: Gavin McCullagh <[email-masked]>
Date: Sat, 13 Jan 2007 11:36:05 +0000

Hi,

> stack as a counter-measure.

Of course, if it were well thought-out enough to be made part of the
standard then it ceases to be non-standard :-)

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

I think expecting every potentially large-data TCP application to implement
rate-limiting is odd when the danger can only be understood at the
transport layer.  

We'd be expecting every sysadmin to make some guess what their cap should
be.  Should it be half of their uplink, a tenth, a hundredth?  Is it a
function also of the number of connections they expect today or even of the
number of attackers?  What if the attack is not on the sender but on some
narrower bottleneck between the sender and the attacker?

It's a workaround in some instances but I don't see how it could be a
solution to this problem.

> to predict the timing of tcp sequences.

Perhaps I've misunderstood you here, but I don't think this would prevent
the attack we have implemented.  What the attack does is simply to
acknowledge those packets which are received regardless of whether they are
in sequence.  There's no prediction at all.  As the attack progresses,
a constant number of acks is sent -- one for each packet received, but the
amount of data being acknowledged grows linearly (though some ack division
could probably improve on that).

In a sense "optimistic acking" is not really the best name for this
incarnation of the attack.  Perhaps better names might be "out of sequence
acking", "hole acking" or just plain "dishonest acking" to cover the
multitude.

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

I'm not sure if you mean variation of MSS or of the congestion avoidance
increase?  Again, I'm often wrong but I don't think that's effective
against the above attack.

Gavin

---

From: Rob Sherwood <[email-masked]>
Date: Sat, 13 Jan 2007 11:18:08 -0500

In addition to David and Gavin's comments:

> the wide internet can be easily flagged at many different 

There is no requirement in the attack that any one flow would be large
(10MB or what have you) or in any way anomalous.  As discussed in the
paper, the attacker can simply create many small streams instead of few
large streams such that no intrusion detection system or rate limiting
queue is affected.  Because the ACK stream is used to determine when to
timeout (ACK clocking, forged TCP timestamps), when to send (incoming ACK
frees new segments), and how much to send (the number of new segments
freed), the attacker is in complete control of the connection, and can
shape traffic nearly arbitrarily.  So an intelligent attacker can shape
each connection to appear to be a perfectly "normal" connection to any
other layer then layer4, for any definition of normal.  That is why the
fix to this problem must be at the transmission layer.

> to predict the timing of tcp sequences.

I do not believe this to be true.  The attack described by David and Gavin
("lazy optack" in my paper) defeats this.  Additionally, the standard
optack attack defeats this when the attack simply ACKs less often (e.g.,
1 ack/500ms) but to more streams for the same total aggregate traffic.
This behavior, as described in the paper, is actually required in practice
to prevent ACKing ahead of sent data, because non-randomized rate TCP
streams naturally have sufficient entropy in the segment generation rate
that this is already a concern.

- Rob
.