Re: [tcpm] DoS attack from misbehaving receivers

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

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

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

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.

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

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.

> Having transmitters engage in non-compliant behavour in order
> 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
.

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