Subject: [dnsop] I-D ACTION:draft-ietf-dnsop-reflectors-are-evil-00.txt

From: [email-masked]
Date: Wed, 17 May 2006 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title		: Preventing Use of Nameservers in Reflector Attacks
	Author(s)	: J. Damas, F. Neves
	Filename	: draft-ietf-dnsop-reflectors-are-evil-00.txt
	Pages		: 7
	Date		: 2006-5-17
	
   This document describes the use of default configured recursive name
   servers as reflectors on DOS attacks.  Recommended configuration as
   measures to mitigate the attack are given.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsop-reflectors-are-evil-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-reflectors-are-evil-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 May 2006 16:55:24 -0400 (EDT)

Isn't it the case that this attack can be carried out against any nameserver,
that could receive spoofed packets, not just public recursive nameservers?

If the nameserver receives a spoofed request from the target (and is configured
to respond for the target--that is private recursive), then even though it is
not a public recursive nameserver, it will still get the LRECORD, and still
forward that long record to the target, resulting in exactly the same
amplification factor.  

Further, if the root nameservers are attacked with spoofed requests for large
DNSSEC records, then the roots have to respond to the target.  The root servers 
must respond, and have no way to determine if the packet is spoofed.

Further, the attack is enhanced by abusing nameservers that are proximate and 
have high bandwidth to the target. That would tend to be the nameservers run by 
the target's ISP, and perhaps the root nameservers.

Further, the attack can be conducted using _any_ authoritative nameserver that 
contains large records, since these nameservers would have to respond to all 
queries.  One does not need to use recursive nameservers at all.

So how does limiting public recursive nameservers reduce this attack?  The
attack scales regardless depending only on the number of spoofed packets sent.  
The volume calcuations does not include a factor of the number of public
recursive nameservers.

It seems that the number of public recursive nameservers does not factor into
the size of the attack, nor actually contribute in any way that is special to
being public recursive.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Peter Koch <[email-masked]>
Date: Fri, 19 May 2006 15:52:41 +0200

Dear WG,

> 	Filename	: draft-ietf-dnsop-reflectors-are-evil-00.txt

this is the first draft as discussed under (6.2) in Dallas. Our goal is to
have <= two editing cycles and have a WGLC around Montreal. Thanks to Joao and
Fred. There were eight volunteer reviewers so far, but of course everyone
is encouraged to review this document and submit comments and feedback.
Editorial issues may go to the editors, issues of content should go to this
list.

-Peter
.

---

From: Joe Abley <[email-masked]>
Date: Fri, 19 May 2006 12:08:19 -0400

On 18-May-2006, at 16:55, Dean Anderson wrote:

> So how does limiting public recursive nameservers reduce this attack?

An attack which uses EDNS0-capable public recursive nameservers has  
the potential to achieve 60-to-80-fold amplification.

An attack which uses authority servers is likely to achieve a much  
lower amplification per request (e.g. a small request which yields a  
referral to the root acts as a 6-fold amplifier).

So, I think it's reasonable to conclude that a static population of  
request generators would achieve reduced attack volume towards  
victims if they were forced to use authority servers as amplifiers  
rather than open recursive nameservers.

Closing all open recursive nameservers will not remove this attack  
vector. However, I don't see that Joao and Frederico's document  
asserts otherwise (in fact, the document goes out of its way to  
mention that the only real solution to the problem is widespread  
deployment of BCP38).

Joe

.

---

From: Joe Abley <[email-masked]>
Date: Fri, 19 May 2006 13:05:22 -0400

Some (mainly pedantic, grammatical, stylistic) observations follow.

> 1.  Introduction
>
>    Recently, DNS [RFC1034] has been named as a major factor in the
>    generation of massive amounts of network traffic used in Denial of
>    Service (DoS) attacks.  These attacks, called reflector attacks,
>    while not being due to any particular flaw in the design of the DNS
>    or its implementations, have preferentially used DNS due to common
>    default configurations that allow for easy use of public recursive
>    name servers that make use of such a default configuration.
>
>    In addition, due to the small query-large response potential of the
>    DNS system it is easy to yield great amplification of the source
>    traffic as reflected traffic towards the victims.

Add some reference to authority servers, perhaps: "DNS authority  
servers which do not provide recursion to clients can also be used as  
amplifiers; however, the amplification potential is greatly reduced  
when authority servers are used. It is also not practical to restrict  
access to authority servers to a subset of the Internet, since their  
normal operation relies on them being able to serve a wide audience,  
and hence the opportunities to mitigate the scale of an attack by  
modifying authority server configurations are limited. This  
document's recommendations are concerned with recursive nameservers  
only."

> 2.  Problem Description
>
>    Because of the fact that most of the DNS traffic is stateless by

Remove "of the".

>    design an attacker could make use of the following scenario to  
> start
>    a DOS attack using DNS packets:

Make it "DoS" (or change the text in section 1 where the DoS acronym  
was introduced).

>    1.  The attacker starts by configuring a record (LRECORD) on an
>        undistinct zone he has access to (AZONE), normally with large
>        RDATA and TTL.

"Undistinct" is not a word; you probably meant "indistinct". However,  
I think "... on any zone he has access to..." is better.

>    2.  Taking advantage of clients (ZCLIENTS) on non-BCP38  
> networks, the
>        attacker then crafts a query using the source address of their
>        target victim and sends it to a Public Recursive Name Server
>        (PRNS).

The text should make it more clear that the same query is sent to one  
or more PRNS from each client, and that there can be a very large  
population of clients involved. Also, it's relevant from the point of  
view of attack mitigation that the clients are usually operated by  
users who are not aware that their resources are being used to  
participate in an attack.

For completeness, you might also mention that the large client  
population is often referred to as a botnet, is typically under some  
form of centralised control such that attacks can be coordinated  
amongst them all.

>    3.  The PRNS proceeds with the resolution, caches the LRECORD and
>        finally sends it to the target.

Given that in general many PRNS are involved, make it "Each PRNS..."  
instead of "The PRNS".

>                                         After this first packet,  
> access

Since the LRECORDS which provide the high level of amplification  
common in these attacks are large, one packet is rarely sufficient to  
carry a response containing one. Perhaps "transaction" or "lookup"  
would be better choices than "packet".

>        to the authoritative name servers for AZONE is normally no  
> longer
>        necessary.  The LRECORD will remain cached for the duration of
>        the TTL at the PRNS even if the AZONE is corrected.
>
>    4.  Cleanup of the AZONE might, depending on the implementation  
> used
>        in the PRNS, afford a way to clean the cached LRECORD from the
>        PRNS.

Since the text in (4) seems, on the face of it, to contradict the  
text in (3), more detail is probably worthwhile. Is this a reference  
to the idea of causing data in the caches of PRNS to be removed  
earlier than the TTL would normally indicate by sending new queries  
to the PRNS which cause them to discover that the delegation for the  
LRECORD's parent zone has been removed, or something like that?

>    Because the characteristics of the attack normally use a low volume

"involve" might be better than "use"

>    of packets on all the kinds of actors besides the victim (AZONE,

"between" might be better than "on" (or "amongst", if you subscribe  
to the belief that "between" is only for use between exactly two  
things, not more).

>    ZCLIENTS, PRNS), it's unlikely any one of them would notice their
>    involvement based on traffic pattern changes.
>
>    Taking advantage of PRNS that support EDNS0 [RFC2671], the
>    amplification factor (response size / query size) could be  
> around 80.
>    With this amplification factor a relatively small army of ZCLIENTS
>    and PRNS could generate gigabits of traffic towards the targetted
>    victim.

"targeted", not "targetted". (Or you could just remove the word  
altogether, or make it "towards the single victim" to emphasise how  
the gang of PRNS are acting together to give the victim a bad hair day.

>    This amplification attack is possible because for historical  
> reasons,
>    out of times when the Internet was a much closer-knit community,  
> some
>    name server implementations have been made available with default
>    configurations that when used for recursive name servers made the
>    server accessible to all hosts on the Internet.

Surely the core reason that the amplification attack is possible is  
because BCP38 is not widely deployed. The default configuration of  
nameservers might provide a larger population of available PRNS than  
would otherwise exist, but it's not the root cause of the problem.

How about "There are thought to be a very large number of deployed  
PRNS available to be used as amplifiers in this attack. This is at  
least partially due to the historical practice of shipping nameserver  
implementations whose default configurations caused them to act as  
open resolvers, during times when the Internet was a much closer-knit  
community than today, and when protection of infrastructure from  
attack was less of a pressing concern."

>    For years this was a convenient and helpful configuration, enabling
>    wider availability of services.  As the subject of this document
>    tries to make apparent,

"As this document aims to make apparent,"

>                        it is now much better to be conscious of ones
>    own name server services and focus the delivery of services on the
>    intended audience of those services, may them be a University  
> Campus,

"they", not "them".

>    an Enterprise or an ISP's customers.  The authors also want to draw
>    the attention of small network operators and private server  
> managers
>    who decide to operate name servers with the aim of optimizing their
>    DNS service, as these are more likely to use default configurations
>    as shipped by implementors.

"as shipped by implementors" is redundant, I think (that's implicit  
in "default"). "Optimising" is the non-US-English spelling of  
"optimizing", in case you were aiming for the former.

> 3.  Recommended Configuration
>
>    From the description of the problem in the previous section it
>    follows that the solution to this sort of attacks is the wide
>    deploying of ingress filtering in routers to prevent use of address

"deployment", not "deploying".

>    spoofing as a viable course of action to elicit the attacks.

That sentence seems like it wants a reference to BCP38.

>    Nonetheless, the fact remains that DNS servers acting as open
>    recursive servers provide an easy means to obtain great rates of
>    amplification for attack traffic, requiring only a small amount of
>    traffic from the attack sources to generate a vast amount of  
> traffic
>    towards the victim.
>
>    In this section we describe the Current Best Practice for operating
>    recursive name servers.  Following these recommendations would  
> reduce
>    the chances of having a given recursive name server be used for the
>    generation of an amplification attack.
>
>    The generic recommendation to name server operators is to use the
>    means provided by the implementation of choice to provide recursive
>    name lookup service only to the intended clients.  Client
>    authentication can be usually done in several ways:
>
>   o  IP based authentication.  Use the IP address of the sending host
>       and filter them through and Access Control List (ACL) to service
>       only the intended clients.
>
>    o  Use TSIG [RFC2845]signed queries to authenticate the clients.
>       This is a less error prone method, which allows server operators
>       to provide service to clients who change IP address frequently
>       (eg. roaming clients).  The current drawback of this method is

"e.g.", not "eg.".

>       that very few stub resolver implementations support TSIG signing
>       of outgoing queries.  The effective use of this method  
> implies in
>       most cases running a local instance of a caching nameserver or
>       forwarder that will be able to TSIG sign the queries and send  
> them
>       on to the recursive name server of choice.

Widespread use of TSIG between resolvers and recursive nameservers  
would also require accurate timekeeping on end users' devices. That  
seems like a significant barrier to deployment.

The document does not give any advice on the preferred response of a  
nameserver to a recursive request from a client that is outside its  
nominal service area. Should it silently discard the request, or  
reply from the cache if a suitable response can be found there, or  
reply with an error, or return a referral to the root, or something  
else? If the document specifically does not wish to offer advice on  
that point, it should say so (but I think advice would be useful).

Many authority servers are not used for recursive lookups by clients,  
and have recursion turned on for no particularly good reason  
(probably because turning it off requires explicit configuration,  
which you alluded to in section 2). The recommended change for those  
servers is presumably to turn off recursion altogether. Perhaps a  
clearer statement of recommendations would be:

1. Unless you really need recursion on a nameserver, turn it off  
completely. For example, authority-only servers which are not used by  
client resolvers do not need recursion turned on.

2. If you do need recursion on a particular nameserver, make sure  
that the nameserver only provides service for a limited set of  
clients, and not the whole Internet.

3. In the case where a recursive nameserver receives a request from a  
remote client, for which it is not configured to provide service, the  
appropriate response to that request is XXX.

One last thing: in common with many other drafts relating to the DNS,  
"nameserver" is used in some places whilst "name server" is used in  
others. It might be good to choose one, rather than mixing them.

Joe
.

---

From: Joe Abley <[email-masked]>
Date: Fri, 19 May 2006 13:11:01 -0400

>>    Because of the fact that most of the DNS traffic is stateless by

I meant the second "of the", not the first one :-)

Joe
.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 22 May 2006 10:48:03 +0200

On Fri, May 19, 2006 at 01:05:22PM -0400,
 Joe Abley <[email-masked]> wrote 
 a message of 255 lines which said:

> to act as open resolvers,

BTW, "open resolvers" or "Open Recursive Nameservers" was, it seems,
the most common term but the draft calls them PRN (Public Recursive
Nameservers). Why the change?
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Dean Anderson <[email-masked]>
Date: Mon, 22 May 2006 13:39:28 -0400 (EDT)

> the potential to achieve 60-to-80-fold amplification.

An attack which uses EDNS0-capable private recursive nameservers also has  
the potential to achieve 60-to-80-fold amplification.

An attack which uses EDNS0-capable authoritative nameservers also has the
potential to achieve 60-to-80-fold amplification.

> lower amplification per request 

This isn't the case. By definition, the "attack" record has to come from an
authoritative server.  The amplification factor is the ratio between the size of
the request and the size of the response.  Recursive servers of any kind cannot
achieve a greater amplification factor than the authoritative server.  

All that matters is what bandwidth and packet rate is available to the authority
(or another) server(s), and whether that server is important to the target. That
is, can they block packets from that server.

> (e.g. a small request which yields a referral to the root acts as a 6-fold
> amplifier).

This also isn't true.  The amplification factor from the roots is greater than
"6 or 7".  Without DNSSEC, and without Anycasted roots, it would be about that.  
But with 100+ Anycasted roots, the amplification is much greater. With DNSSEC
its much greater still.  You are aware of the "performance improvements" of
Anycast DNS, right?

An attack involving the roots should be able to obtain a response bandwidth well
in excess of 10Gbps.  Mitigation would be difficult. One would have to trace the
bots back to source (or BCP38).

In fact, with Anycasted roots (particularly with BGP anycast) the amplification
is particularly pernicious for this attack.  The anycasted roots appear to be
closer to the bots, and have a much greater bandwidth, and a much higher rate of
packet handling than do most ordinary nameservers. A "problem" of BGP anycast,
uneven load distribution, is exploited to very negative effect, since the
lightly loaded servers have more headroom than the others, and thus can use the
headroom to respond with a higher "attack" load.

Further, the anycasted roots for the most part sit on very high bandwidth 
connections, and are capable of handling very high packet rates.  

Next in line for high bandwidth connections to the target are the target's ISP 
(public/private) recursors.

Next in line are the authoritative servers of the "big" sites.

The odd public recursor on and end user link does not have access to these
connections, and the attacker has to scan for them.

> rather than open recursive nameservers.

Well, plainly, doing the math show that isn't the case.

> vector. 

No sensible attacker would use open recursors (i.e. the Nanog example), which
indicates that the attackers have an alternate agenda. For example, we saw
exactly this pattern with open relay abuse.  We found that open relay blacklists
and their associates were behind the open relay abuse. We found this by
connecting the scanning for open relays with the abuse of open relays [And by
tracing abuse back to anti-spam zealots, who then admitted the abuse, and
claimed that open relays were "free"]

Similarly, we can start looking for people scanning for open recursors, and 
waiting for those recursors to be abused. [of course, "real attackers" wouldn't 
give themselves away by scanning, when they can conduct abuse more effectively 
with less work, without giving away their identities.]

> However, I don't see that Joao and Frederico's document asserts otherwise (in
> fact, the document goes out of its way to mention that the only real solution
> to the problem is widespread deployment of BCP38).

That is correct: they don't assert that this is a solution. And they do go out
of their way to assert that BCP38 is the __ONLY__ real solution.  Rather leads
me to wonder why this draft was proposed....

		--Dean

.

---

From: Joe Abley <[email-masked]>
Date: Mon, 22 May 2006 13:54:46 -0400

> the potential to achieve 60-to-80-fold amplification.

I'll presume you mean a recursive nameserver acting on behalf of a  
client which is a member of the set of clients for which the server  
is configured to perform recursive lookups when you say "private  
recursive nameserver".

> potential to achieve 60-to-80-fold amplification.

For sure.

However, both these cases require far greater effort in logistics if  
maximum amplification is to be achieved. By contrast, if you amplify  
an attack using open ("public") recursive nameservers you probably  
only need to arrange for one enormous record to be introduced to one  
master server, and the drones you use to spoof requests can use any  
of a large set of available amplifiers without having to worry about  
customising the list per drone.

> This isn't the case.

In practice, I believe it is. See above.

> "6 or 7".  Without DNSSEC, and without Anycasted roots, it would be  

DNSSEC is barely deployed anywhere, and we are talking about  
mitigating a problem now rather than in N years time.

> its much greater still.  You are aware of the "performance  

A referral to the root is a referral to the root, and whether or not  
individual servers are anycast is not relevant to response size.

> Well, plainly, doing the math show that isn't the case.

Your logic is faulty.

> No sensible attacker would use open recursors (i.e. the Nanog  
> example),

Since the majority of documented examples of reflection attacks (if  
not all of them) do involve open recursive nameservers, you might  
consider the possibility that you are confused.

Joe

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 23 May 2006 00:36:38 -0400 (EDT)

> is configured to perform recursive lookups when you say "private  

Yes. "private" contrasts with "public".

> maximum amplification is to be achieved. 

You have failed to offer any evidence whatsoever for this assertion. But I've
shown that 3 other cases offer the same results for less effort and less risk to
the attacker.

I'm wondering: have you specifically disputed any specific fact I've asserted?  
If you could organize a list of what you dispute, it would be more helpful than
summary statements with contrary conclusions.  I could then identify what
exactly the points of contention are.

> By contrast, if you amplify an attack using open ("public") recursive
> nameservers you probably only need to arrange for one enormous record to be
> introduced to one master server, and the drones you use to spoof requests can
> use any of a large set of available amplifiers without having to worry about

See my other messages on this topic.  Drones can just as easily (more easily)  
hit Anycasted roots.  Drones can more easily hit authoritative servers. Drones
can more easily hit the ISP private resolvers. Mitigation (other than BCP38) is
nearly impossible for these cases.  How is public recursion easier than this?

Also, to exploit recursion of any type, they ___first___ have to find or create
the authoritative record before they can exploit any recursors at all (public or
private).  If they create their own, they leave a forensic trail.  If they
search for ordinary authority servers, they now have a list of authoritive
servers: Having searched out these records ___first___, they can simply use
these authoritive servers. Or they can use the private resolvers of the target's
ISP.  

But ___first___, they have to find or create the authority record.  You
understand and agree with that, right?

In none of these cases do they need to "worry about customizing the list per 
drone". They have one list, either way.  All drones can have the same list.

Or they can use root servers, hitting a hundred+ servers with only 13 IP
addresses, with each server having very high bandwidth, and each tuned to turn
around packets at a high rate. But you should know this: Doesn't Nominum and ISC
offer consulting services and custom software just for this purpose?

The only reason an attacker would exploit public recursors is because they are 
ignorant of the other attacks. Or they have an axe to grind.

> In practice, I believe it is. See above.

There is very little practice, and "above" wasn't very convincing.

> mitigating a problem now rather than in N years time.

Err, I think ICANN/RSSAC has different plans for DNSSEC. But you avoided the 
issue of root amplification and packet rates from the high bandwidth roots.

> individual servers are anycast is not relevant to response size.

Anycast is relevent to the bit rate of the response.  Many servers, big pipes, 
fast packet handling.  More than 7x amplification.

> > Well, plainly, doing the math show that isn't the case.

Mere assertions of faultiness do not demonstrate faultiness.

But since you didn't offer any logic in response, I can't directly comment on
your logical faultiness, other than your lack of dispute of any specific facts.

> consider the possibility that you are confused.

There are very few examples. But I suggest that perhaps the attackers in these
examples are trying to make a point about the dangers of open recursors. Rather
like the no-open-relay crowd previously attempted to do.  I think we can just
about conclude at this point that the people behind those previous reflector
attacks are simply ignorant of DNS.  Rather like the no-open-relay crowd was
ignorant of SMTP, and particularly which headers can be forged, and whether open
relay abuse can be traced. Similarly, the reflector attackers are undone by
their ignorance about the attack: they hadn't considered the other
possibilities, and they hadn't considered that their wrongness (and thus their
motives) would be revealed by analyzing the attacks.

Finding the DNS scanners will lead us right to the abusers.

		--Dean

.