Subject: RE: stopping amplification

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Mar 2006 11:40:54 -0800

> [mailto:[email-masked]] On Behalf Of Paul Vixie

> since recursion and amplification aren't necessary to the 
> success of this attack, i think we had better focus on 
> reflection and spoofing.  

I have been trying to work out what the real problem here is. In particular
why is the reflected attack worse than the direct attack?

The only difference I can see between direct and reflected is that the open
resolver used in the reflected attack is going to do retries. 

In other words the 'amplification' effect is the number of packets and not
just the individual packet size. Moreover there are probably broken
resolvers out there that will oblige with ridiculous retry policies. 

I have a very hard time seeing how extending the packet size from about 50
bytes plus header to 500 bytes plus header turns the attack into a
devestating one, the cost of switching is going to dominate the bandwidth
cost. Increasing the packet count is a completely different matter. As soon
as the congestion starts you get an avalanche effect and the effect of the
attack suddenly steps up. 

The real crux of the problem here is that the open recursive resolvers
respond to unauthenticated requests. I don't see much value in the proposed
ad-hoc protocol change to relieve the symptoms when the deployment cost is
the same as the change necessary to address the cause. 

We could fix the open resolvers with code to detect repeated requests for a
particular host and go into a rate limiting mode. This would be at the cost
of creating a DoS attack for users of the resolver. 

The best approach would be to combine the above with a 'registration'
protocol. For example the party that ants to register with the server does a
computational proof for X units of work, establishes a TSIK shared secret
with the resolver, this is used to authenticate requests (including
detecting spoofed source address).

---

From: Robert Story <[email-masked]>
Date: Tue, 28 Mar 2006 15:12:58 -0500

On Tue, 28 Mar 2006 11:40:54 -0800 Phillip wrote:
HBP> I have been trying to work out what the real problem here is. In particular
HBP> why is the reflected attack worse than the direct attack?

Reflection helps hide the source of the attack.

HBP> The only difference I can see between direct and reflected is that the open
HBP> resolver used in the reflected attack is going to do retries. 

You are looking at the wrong end of the resolver. The attack is the
response from the open resolver, not the queries the resolver makes to
respond to the (spoofed) packet. The resolver will not retry sending
response packets.

HBP> I have a very hard time seeing how extending the packet size from about 50
HBP> bytes plus header to 500 bytes plus header turns the attack into a
HBP> devestating one,

When you multiply that by the number of open recursive servers
(unknowingly) participating in the attack, bandwidth very much becomes
a factor. Haven't you seen the bandwidth numbers people were reporting
for these attacks? Gigabits per second.

HBP> The real crux of the problem here is that the open recursive resolvers
HBP> respond to unauthenticated requests.

Uhhmm... yes, the very definition of an 'open' recursive resolver is
one that responds to unauthenticated requests. So one step in reducing
the number of potential participants in these attacks is to close as
many open recursive resolvers as possible.

HBP> We could fix the open resolvers with code to detect repeated requests for a
HBP> particular host and go into a rate limiting mode. This would be at the cost
HBP> of creating a DoS attack for users of the resolver. 

That wouldn't fix anything. Each open resolver only sees a very small
number of requests, so this 'fix' would more likely affect legitimate
users of the resolver, and not the attackers.

-- 
Robert Story
SPARTA