Subject: stopping amplification

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Mar 2006 11:48:03 -0500

I've been urged to send out this proposal, which even I think is rather goofy.

Problem statement:

Recently, there has been a lot of hub-bub about the use of recursive 
servers to amplify traffic sent in a DDoS attack.

Problem Analysis:

There are three thorns in folks' side about this.

1) The attacks use spoofed source addresses.  This ain't something 
that can be fixed in the DNS protocol, BCP38(+/-3) be, uh, hanged.

2) The attacks make use of servers that will answer to arbitrarily 
sourced packets with lots of data.  Currently only recursive servers 
can really to this, sooner or later any DNSSEC zone server will 
qualify for this duty.

3) The attacks make use of something called amplification, 
specifically the ability to send a little message in and get a lot of 
message out.

Item 2 is something that is rather operations-ish.  But is bodes not 
well for protocol developments in the future.  Currently the only 
effective amplification that DNS affords is via recursive servers 
caching large data sets.  In the future, authoritative servers will 
do so too, via DNSSEC and other means.  (The pinata du jour on this 
one is DNSSEC.)  (Ooh, English, Spanish, and French.)

Item 3 is something that can be dealt with within the protocol.  And 
this is what my goofy idea addresses.

Potential Solution:

The crux of the goofy idea is that the only way to prevent DNS from 
being an agent of amplification is to make the queries (almost) as 
big as or bigger than the responses.  Via padding, of course.

That would enable this: I could require that such a query be padded 
up to the size in the EDNS0 field before I'll deal with it?  I know 
it's goofy to send the extra, useless bytes, but what's more 
important?   Smaller messages or stopping the "baddies" out there?

The proposal is to add an optional padding field to EDNS0.5 to allow 
for padding.  A server operator *could* then have a policy that says: 
answer up to the lesser of the EDNS0 size field and the size of the 
query.  Or, if the query is smaller than the EDNS0 size field, answer 
REFUSED.

Obligatory disclaimer:

Yes, this is goofy.  But, if we want to stamp out amplification, how 
else can it be done?  I am willing to accept that "we don't intend to 
stamp out amplification." Or, "is this a long term solution to a 
short term problem?"

PS - Yes, April 1 is this Saturday.  Take that for what it's worth.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 28 Mar 2006 13:12:19 -0800

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

But they are using spoofed source addresses?

> HBP> The only difference I can see between direct and 
> reflected is that 
> HBP> the open 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.

In which case won't the same problem affect every DNS server?

> HBP> I have a very hard time seeing how extending the packet 
> size from 
> HBP> about 50 bytes plus header to 500 bytes plus header turns the 
> HBP> attack into a devestating one,
> 
> (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.

And what is the bandwidth these people are using to create the attack? A
botnet can generate gigabits per second too. If we were talking about jumbo
packets and there was an order of magnitude difference I could see
amplification as being the motivation. 

It is much easier to run a flood attack on the botnet host fast than to find
a DNS resolver that responds fast enough to make this an amplification
attack. The DNS resolver has to be on iron big enough to saturate its output
bandwidth for a start.

I understand the damage caused, like Paul I do not agree that amplification
is the primary motive for this behavior.

---

From: Roy Arends <[email-masked]>
Date: Wed, 29 Mar 2006 01:03:53 +0200

bert hubert <[email-masked]> wrote on 03/29/2006 12:50:31 AM:

> On Wed, Mar 29, 2006 at 12:26:59AM +0200, Roy Arends wrote:
> > The resolver has the ability to use tcp. The spoofed source does not 
have 
> 
> This has been tried. http://www.irbs.net/internet/nanog/0507/0186.html
> 
> WorldNic quit doing that pretty soon - I bet it didn't work, too many
> clients behind firewalls that were stupidly configured.

This has nothing to do with 'what has been tried'. Furthermore the reason 
why "it didn't work" might have something to do with broken resolvers as 
well.

Roy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Mar 2006 10:08:50 +1100

> But they are using spoofed source addresses?

	You have to get the ISP of the reflector to initiate the
	traffic backtrace rather than initiating the traffic traceback
	your self.  With the latter you might have agreements with your
	peers that they will do a traceback through their network if
	you request it.

	You are unlikely to have such a agreement with the reflectors
	ISP.

> In which case won't the same problem affect every DNS server?

	Yes.  Closing ORNs is just exercise to reduce the scale
	of the problem.
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Wed, 29 Mar 2006 01:53:38 +0200

Peter Koch <[email-masked]> wrote on 03/29/2006 01:28:41 AM:

> On Wed, Mar 29, 2006 at 01:12:04AM +0200, Roy Arends wrote:
> 
> > They were. my servers are authoritative only. It turned out that the 
only 
> > requests coming in with RD bit set where my own debug attempt using 
DiG 
> > which sets RD by default. 
> 
> i'll try to back this with some 'fresh' figures the next days.
> 
> > RD              Recursion Desired - this bit may be set in a query and
> >                 is copied into the response.  If RD is set, it directs
> >                 the name server to pursue the query recursively.
> >                 Recursive query support is optional.
> > 
> > This 'optional' is ambiguous enough to interpret as 'ignore'. In fact, 

> 
> Come on, apply the robustness principle, not martial law.

I was. I'm being liberal in what I accept, but very, VERY consertive in 
what I send back.

> Support being
> optional means that the targeted server may not honor the RD bit (which 
is
> what we are talking about closing recursors) but is no excuse for 
dropping
> the query on the floor (at least not during the 'normal' resolution 
process).

I'm acting as the devils' advocate here. 

Recursive nameservers talk to authoritative nameservers. They clear the RD 
bit since they intent to do recursion themselves. If a request does not 
come from a recursive server, and the authoritative server is not willing 
to do recursion, who is doing the recursion ? Anykey, one may imho explain 
'drops the request' as a result of 'Recursive query support is optional'.

It has been implemented this way.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Wed, 29 Mar 2006 15:15:25 +0100

> I was. I'm being liberal in what I accept, but very, VERY consertive in 

I should note that it is not considered a very good idea to be liberal
in what you accept these days: it has a tendency to cause interesting
security problems.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff