Re: [tcpm] DoS attack from misbehaving receivers

[Gavin McCullagh <[e-mail]>]

Hi,

On Fri, 12 Jan 2007, Caitlin Bestler wrote:

> But I still don't see doing anything non-standard in the TCP
> 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.

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

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

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

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


_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm