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

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 11 Jan 2007 12:59:10 -0800

Rob Sherwood wrote:
> I guess I should probably jump in here somewhere :-)
> 
> On Thu, Jan 11, 2007 at 12:00:59PM -0800, Caitlin Bestler wrote:
>> The proposed test for a non-compliant receiver would seem to require
>> that the sender be non-compliant itself.
> 
> I'm not sure I understand this comment.  Part of the utility
> of the solution is that unmodified receivers can communicate
> with senders that randomly skip segments, because segment
> reordering and dropping is already handled by TCP.
> 

Having the sender skip segments will indeed detect a non-compliant
receiver that acks segments that were never sent. But sending
non-contiguous TCP segments is itself not compliant.

> 
>> 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)?
> 
> As mentioned in the paper, rate limiting does not prevent the attack.
> The attack is for many servers to send a small amount of TCP
> unfriendly traffic into the network, which results in
> significant traffic in aggregate.  Reducing the rate of
> traffic at any one server only causes the attacker to target
> more servers.
> 

You can generate a large amount of traffic simply sending small
requests that generate large responses and then bit-bucketing
the results. If you are doing so from a botnet you can even
actually receive all of the segments in the distributed clients
before dropping the segments.

Before endorsing a counter-measure that calls for what was
previously non-compliant behavior there should be a showing
that the problem being solved is indeed severe and unique.

If my understanding is correct, the problem is that an attacker
can simulate reception of more material than their actual local
link can support, and thereby trick a large group of senders
into saturating *their* local links and/or intermediate segments.

But is it not correct that the same attack could be launched
from a botnet just as effectively even without faking acks?
Until typical home computers are more secure from being drafted
into a botnet is there a real benefit from this counter-measure?

Having transmitters engage in non-compliant behavour in order
to catch cheaters is a slippery slope best avoided.

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

---

From: Rob Sherwood <[email-masked]>
Date: Thu, 11 Jan 2007 16:27:32 -0500

> that the problem being solved is indeed severe and unique.

Agreed.  This is the crux of the discussion: is this attack severe
enough to motivate the admittedly invasive change to the TCP stack.

> into saturating *their* local links and/or intermediate segments.

This is mostly correct.  The true concern is that *backbone* links,
not just local links, will be saturated, bringing about, as the title
suggests, Internet-wide congestion collapse.  It is this concern that
I feel motivates the need to change the specification.

> into a botnet is there a real benefit from this counter-measure?

A botnet of sufficient size, maybe.  An open question (read: subject of
my current research) is how much traffic is required to overcome Internet
backbone links.  The reason for concern with the OptAck attack is that
the amplification factors are large (~1600x and higher from the paper),
which reduces the size of the botnet required to cause significant damage.

For example, if a 100,000 node botnet has sufficient bandwidth to
overwhelm backbone links without OptAck, then a 60 node botnet can
overwhelm the network with OptAck.  I believe that there is a qualitative
difference between these two attacks in terms of attacker capability,
i.e., it takes significantly more work to compromise 100K machines
then 60.

> to catch cheaters is a slippery slope best avoided.

In general I agree, but I believe that the danger here is significant
to warrant futher consideration.

- Rob
.

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Jan 2007 13:28:38 -0800

> non-contiguous TCP segments is itself not compliant.

Technically, that's equivalent to losing or reordering segments. As long
as you can't tell the difference from the receiver's point of view, why
is this not compliant?

Joe
-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 11 Jan 2007 13:37:00 -0800

Joe Touch wrote:
>>>> The proposed test for a non-compliant receiver would seem to
>>>> require that the sender be non-compliant itself.
>>> I'm not sure I understand this comment.  Part of the utility of the
>>> solution is that unmodified receivers can communicate with senders
>>> that randomly skip segments, because segment reordering and dropping
>>> is already handled by TCP.
>> 
> Technically, that's equivalent to losing or reordering
> segments. As long as you can't tell the difference from the
> receiver's point of view, why is this not compliant?
> 
> Joe

There's a difference between L3 or L2 dropping a segment
because a queue was full and L4 simply not generating it.

Granted, there is no method to prove the difference when
observing from the other end of the network, but that still
isn't a reason to bless generation of non-compliant TCP streams.

A TCP connection is supposed to be a peer-to-peer relationship.
Once you start playing liar's poker to try to trip up the other
end things are going to get messy very quickly. What if receivers
started doing things to try to detect sender's who were sending
out of order?

Be paranoid in what you accept and devious in what you send?

---

From: Christian Huitema <[email-masked]>
Date: Thu, 11 Jan 2007 13:45:13 -0800

> which reduces the size of the botnet required to cause significant

I have witnessed distributed DOS attacks generating several Gbps of
traffic, and that was a couple of years ago. I have also witnessed DOS
attacks implemented by simply opening multiple TCP connections. The
attack software started several threads, and in each thread a loop would
keep loading a particular web page. That actually gives a lot of
amplification, since the size of the HTTP request is only a fraction of
the size of the response. There was no attempt to hide the origin of the
attack, spoof the IP address, hack the TCP stack, or any of that. These
particular attacks were trying to bring down a web site, but similar
attacks could easily target a particular link in the infrastructure.

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Thu, 11 Jan 2007 14:12:05 -0800

Caitlin Bestler wrote:
...
> because a queue was full and L4 simply not generating it.

Not to the receiver!

('goes to intent' - the receiver doesn't know intent).

> isn't a reason to bless generation of non-compliant TCP streams.

It's not non-compliant to do something that the receiver can't
differentiate from legitimate behavior.

> started doing things to try to detect sender's who were sending

What would you do? You can't punish them, since you can't know whether
the network is the cause or not.

The better quote might be a version of the (in)famous "don't attribute
to malice that which can be attributed to ignorance"; my version here
would be:

"don't attribute to malice that which can be attributed to entropy"

Joe

---

From: John Heffner <[email-masked]>
Date: Thu, 11 Jan 2007 17:15:24 -0500

> enough to motivate the admittedly invasive change to the TCP stack.

Yep.

> I feel motivates the need to change the specification.

The links with heavily aggregated traffic from local or regional ISPs up 
to the tier 1 ISPs are almost always bandwidth capped, and are almost 
always purchased in such that they are able to carry "just enough" 
traffic -- that is, it's pegged for at least some of the time.  (Who 
wants to pay for more than they use?)  The core of the Internet today is 
provisioned to handle the load.  It seems to me the threat of 
Internet-wide congestion collapse is a bit overstated these days.  (This 
also applies to recent congestion control discussions.)

I could see this attack as being effective at saturating something like 
a university's access link where a small number of well-connected 
servers could severely congest it.  However, in my experience, server 
and network admins are very reluctant to run any sort of service that 
will stream arbitrary amounts of data as fast as they can.  (I've 
sometimes tried to get such services made available for measurement 
purposes.)

The defense proposed in the paper is pretty cool, but implementing it 
and running it on a production machine would make me a bit nervous.  If 
this were a significant problem, you could always turn on bandwidth caps 
in the server application or in the kernel's networking system.  This 
would probably be my favored approach.  In reality, I've never heard of 
this attack being perpetrated in the wild, while DDOS is quite common.

   -John

---

From: Rob Sherwood <[email-masked]>
Date: Thu, 11 Jan 2007 17:30:01 -0500

> also applies to recent congestion control discussions.)

This is the part that is not clear to me: is it really the case that
back bone links have sufficient capacity to handle the sum of all
the access link capacity?  That is to say not the expected load, but
the maximum capacity?   I am familiar with many of the link capacity
estimation tools available, and it's my understanding that there is not
a conclusive answer here.

- Rob
.

---

From: Gavin McCullagh <[email-masked]>
Date: Fri, 12 Jan 2007 09:34:32 +0000

> enough to motivate the admittedly invasive change to the TCP stack.

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/

Kernel: 2.6.18 on both
OS: Debian GNU/Linux "edgy"
Apache v2.0.55
wget v1.10.2

The patch to linux is a short one.  I can make it available, but have held
off doing so for now.

Gavin