Subject: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-05.txt

From: [email-masked]
Date: Mon, 03 Dec 2007 21:50:01 -0500

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 Recursive Nameservers in Reflector Attacks
	Author(s)       : J. Damas, F. Neves
	Filename        : draft-ietf-dnsop-reflectors-are-evil-05.txt
	Pages           : 8
	Date            : 2007-12-03

This document describes ways to prevent the use of default configured
recursive nameservers as reflectors in Denial of Service (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-05.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-05.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-05.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.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Dec 2007 17:10:38 -0800

1) (Somewhat jokingly) I would strike the first word ("Recently") as 
the attacks were almost two years ago now.  In the spirit of "sending 
text" it might be more appropriate to start with "Once upon a 
time...".

2) I guess I should get over the fact that "are-evil" is part of the 
the file name and that will go away when this document gets out of 
the RFC Editor.  I think the tone of the document is right as is, 
recommending ways to have name servers not offer free and unchecked 
services unless the owner is aware.

3) I was a bit troubled by the discussion in the room on Monday. 
Parts of the discussion were hard to hear (the acoustics plus my 
aging ears) and I my laptop was off (no jabber for me).  It sounded 
like someone (not present) claimed that they required open resolvers 
for roaming.  The discussion seemed to criticize that comment because 
it is not generalizable, but I think that wasn't the intent.  I 
thought the comment was offered as a reason why a blanket prohibition 
against open resolvers was a bad idea.

I would be against a campaign to cajole people into closing open 
resolvers.  One reason is that I don't believe that the problem is 
the open resolvers but the inherent nature of UDP involved.  Two is 
that it is up to operators to decide how to responsibly operate their 
network (and it is up to the IETF to give them the educational 
materials they need).

I think the document is a good balance.  It recommends closing access 
to resolvers but does not berate those that leave them open.  (Unless 
I missed something.)  It lists approaches to selective openness.  I 
apologize if I lost the train of thought of the mic discussion.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Dec 2007 17:10:38 -0800

---

From: Dean Anderson <[email-masked]>
Date: Mon, 10 Dec 2007 09:15:26 -0500 (EST)

On Tue, 4 Dec 2007, Edward Lewis wrote:

> the attacks were almost two years ago now.  

Yes. And those attacks seemed to be contrived at the time. Perhaps the
attack described isn't (as I previously argued) a genuine concern.

"generation of massive amounts of traffic" is also a misnomer. None of
the attacks generated very large amounts of traffic in comparison with
other types of DOS attacks.  Perhaps 'generation of a significant amount
of traffic'

The draft still asserts incorrectly that 

   DNS authoritative servers which do not provide recursion to clients
   can also be used as amplifiers; however, the amplification potential
   is greatly reduced when authoritative servers are used. 

The exact same traffic can be generated with authority servers.  
Authority abuse traffic is much more difficult to mitigate, and so is a
much worse problem that recursor traffic. The draft should state the
facts, otherwise it is misleading.

> In the spirit of "sending text" it might be more appropriate to start
> with "Once upon a time...".

I disagree. IETF Documents should have a serious subject, and a serious
tone.

> services unless the owner is aware.

I'm not sure this should be ignored. Anyone who looks up the document
history will find that name.  It doesn't ever really go away.  While
there are no official requirements on document names, I think they
should avoid religious and unprofessional terms. If nothing else, it
reflects both on the author, and on the IETF because the IETF accepted
to work on the document with the offensive name.  I think this is a good
reason to oppose this document.

> apologize if I lost the train of thought of the mic discussion.

I think the document needs to include discussion of the more serious 
attack vectors using authority servers. Even though this has been 
discussed, and is more difficult to mitigate, and a more serious problem 
that administrators may need guidance in how to handle, this is 
completely ignored. 

This document is just an 'open relays are bad' document, couched in DNS 
terms.  

I am strongly opposed to this document, so long as it contains incorrect
and misleading claims.

		--Dean

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

---

From: Dean Anderson <[email-masked]>
Date: Mon, 10 Dec 2007 09:15:26 -0500 (EST)

--Dean

---

From: Matt Larson <[email-masked]>
Date: Mon, 10 Dec 2007 10:32:38 -0500

Much against my better judgement, I'm replying to an author who
repeatedly shows himself incorrigible.  But lest his continued
repetition of a false claim--that authority servers can be used to
mount as large an attack as open servers--begin to give it an air of
truth, I'd like to point out:

> facts, otherwise it is misleading.

We've been over this ground before over a year ago.  Please see this
message from me on this list, in reply to a message of yours on this
exact same topic:

  http://www1.ietf.org/mail-archive/web/dnsop/current/msg04723.html

Let me quote the relevant part:

  On Mon, 02 Oct 2006, Dean Anderson wrote:
  > Finding authority servers for large in-addr responses is
  > just a walk of the in-addr.arpa.  One can get forward zones from a
  > variety of places to find large SPF, DNSSEC or TXT records.
  > Furthermore, the search for such records is completely innocent, while
  > the search for open recursors is suspicious. [one can put up traps for
  > the latter search]

  That is all true.  However, I am extremely dubious that today--right
  now--one could mount a reflector attack using only authoritative
  servers that would equal the magnitude of the attacks seen at the
  beginning of this year that used open recursive servers.  To mount an
  attack equivalent to those already seen, one would need to find tens
  of thousands of authoritative servers able to produce a 4K response.
  Every byte in the response size is significant, given the large number
  of reflectors involved.  The bar has already been set at 4Kb, so one
  needs to find at least ~34,500 authoritative servers with responses at
  least that large to equal this year's earlier attacks.

  (The problem is actually worse, because the number of open recursive
  name servers has been estimated at around half a million by multiple
  sources, so that's the current theoretical worst case, an even harder
  number to reach using authoritative servers.)

  Can you point us to even one 4Kb response from an authoritative
  server?

You did not answer my question then and it still stands: if your
assertion that authority servers pose just as large a risk as open
resolvers for DDoS attacks, then point us to a large number of
authority servers with large (~4Kb) responses.

Matt

P.S.  For you or anyone else who'd like to recall the details of the
open-resolver based DDoS attacks from early 2006, my colleagues
prepared an excellent (and frightening) presentation on them:

  http://www.nanog.org/mtg-0606/scalzo.html

---

From: Matt Larson <[email-masked]>
Date: Mon, 10 Dec 2007 10:32:38 -0500

Matt

---

From: Dean Anderson <[email-masked]>
Date: Wed, 12 Dec 2007 12:07:43 -0500 (EST)

> truth, I'd like to point out:

We have been over this before. The size of an attack depends only on the 
size of the botnet sending queries and the bandwidth available to the 
server responding. 

Authority servers send the exact same size packet as do recursive 
servers.

Therefore, the exact same attack can be mounted with authority servers.

>   Can you point us to even one 4Kb response from an authoritative

This is a frivolous assertion. _Any_ EDNSO-capable authority server can
be legitimately configured to provide an 8kb response.  Some authority
servers are known to provide quite large SPF responses.  The exact list
of authority servers that currently provide large responses is not
necesseary to prove my assertions.

Furthermore, once root DNS servers start including IPV6 responses, their 
responses will be quite large.  Other authorities will also have much 
larger responses.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 12 Dec 2007 12:07:43 -0500 (EST)

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Dec 2007 12:16:26 -0500

At 10:32 -0500 12/10/07, Matt Larson wrote:

>mount as large an attack as open servers--

So what if authority servers can be used for attacks?  What does that 
have to do with the recommendations in the subject document?

(I know Matt wasn't the one who initiated the claim.)

The draft has good recommendations regardless of the events that gave 
rise to it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Dec 2007 12:16:26 -0500

---

From: Dean Anderson <[email-masked]>
Date: Wed, 12 Dec 2007 12:22:27 -0500 (EST)

On Mon, 10 Dec 2007, Matt Larson wrote:

> repeatedly shows himself incorrigible. 

This seems to be a personal attack. 

But in anycase, I have demonstrated the math governing the size of the
attack, and the math proves that there is no size difference (the key
factor) between attacks using authority and attacks using recursive
servers.

In contrast, the proponents have made the completely unfounded assertion
that there _is_ a difference in the attacks conducted using authority
servers as contrasted with those conducted using recursive servers, but
they have not shown any reason whatsoever why they are different.

It seems to me that repeating assertions without any foundation
whatsoever seems to be more aptly describable as "incorrigible".

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 12 Dec 2007 12:22:27 -0500 (EST)

--Dean

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 Dec 2007 12:46:50 -0500

On 12-Dec-2007, at 12:16, Edward Lewis wrote:

> So what if authority servers can be used for attacks?  What does  
> that have to do with the recommendations in the subject document?
>

It seems like it might have some relevance to the decision on whether  
this document is worth spending time on in the first place. However,  
since the document is already written and has been already extensively  
reviewed, this seems hardly relevant. (For the record, I think the  
document was worth writing.)

The (tangential!) question of whether recursive resolvers provide a  
simpler mechanism for launching these kinds of attacks than  
authoritative-only servers has been answered by several people,  
several times, I think (one example is <http://www1.ietf.org/mail-archive/web/dnsop/current/msg04457.html 
 >).

> The draft has good recommendations regardless of the events that  
> gave rise to it.

I agree. The sooner it is published, the better.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 Dec 2007 12:46:50 -0500

Joe

---

From: Peter Koch <[email-masked]>
Date: Wed, 12 Dec 2007 19:42:10 +0100

> I agree. The sooner it is published, the better.

\begin{chair}
I'd like to remind everyone that this draft has passed IETF Last Call,
as a result of which several ADs put DISCUSSes into the ballot.
<https://datatracker.ietf.org/idtracker/draft-ietf-dnsop-reflectors-are-evil/>.

The main task of the WG w.r.t. this draft is now to consider the issues
raised and support the editors in addressing and resolving the concerns
voiced in LC.  The editors have submitted -05 as an attempt to cover the
discussing ADs' concerns and we are - together with our AD - continuing work
to get the DISCUSSes cleared.
<http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reflectors-are-evil/draft-ietf-dnsop-reflectors-are-evil-05-from-04.diff.html>

Input from the WG received on list and in Vancouver was helpful in making
progress here.  Please let's keep the discussion focussed on the remaining
open items.
\end{chair}

-Peter

---

From: Peter Koch <[email-masked]>
Date: Wed, 12 Dec 2007 19:42:10 +0100

\begin{chair}

-Peter

---

From: Dean Anderson <[email-masked]>
Date: Wed, 12 Dec 2007 16:34:38 -0500 (EST)

On Wed, 12 Dec 2007, Peter Koch wrote:

> voiced in LC.  

I have reviewed the IESG comments.  Besides removing the false claim I
previously noted about authority servers (which is partly covered by
Cullen Jennings in his discuss comment), I think the draft should
explain the qualitative differences between authority attacks and
recursor attacks.  As previously noted, it is much more difficult, if
not impossible, to mitigate attacks which use authority servers. This
feature makes the authority attack much more fearsome. Closing open
recursors does not eliminate these attacks.

I seem to note 3 ways of searching for open recursors:

	1) walk in-addr.arpa, and test those authority servers to find 
those that also do recursion. This produces a subset of authority 
servers.
	2) scan by brute force the entire internet for recursors.  This 
method seems unattractive, and likely to be too difficult or too time 
consuming for "script kiddies".
	3) collect recursor data from queries at root and TLD server
sites.  This vector is very limited due to the relatively small number
of people who have the necessary access.

I note that the most likely vector for finding open recursors (number 1
above) requires searching authority servers.  Plainly, obtaining large
authority records is just as easy as obtaining the list of recursors, if 
not easier.

The following seem to be obvious:

X	Some people will need to run open recursors.  

X	Few people can obtain lists of open recursors more easily than 
searching authority servers.

X 	"it seems like a reasonable assumption there will be plenty 
of large DNS records on authoritative servers without the attacker 
needing to create them." (Cullen Jennings)

None of these is really noted or explained in the draft.

I have no problem with the WG offering operational advice on this
subject.  I do think a recommendation _could_ be helpful, if it is based
on _fact_ and rational, transparent analysis, and ultimately helps
administrators understand the attack and what they can do about it.  
This draft does not do that. Instead, it promotes unfounded "religous"
views that aren't even reflective of the WG views--if WG members can't
recommend closing open recursors, one wonders how a WG consensus was
achieved to send it to the IESG.  Sometimes I get the feeling that some
people support advancement of drafts as favors to the authors, rather
than on the technical merits of the draft.  This draft starts with a
conclusion, and tries to support that conclusion despite the contrary
evidence that shows this conclusion is unwise and unnecessary.

I think the focus of the draft should be on helping administrators with
methods of how to address such attacks when they happen, rather than on
ineffective reactions telling people needlessly to close open recursors;  
something most people won't do anyway. This document promotes a
particular solution; one which wasn't very well thought out to begin
with, and one which can easily be seen to be ineffective, inadequate,
and completely unhelpful to the administrator who is concerned about or
subjected to this type of attack.

Sam Hartman writes in his comment:
  "Please add security considerations text to address Paul's issue 
   without making a recommendation about whether the practice is
   advisable."

I think the entire draft should be rewritten to be informative without
being religious. Despite the document name, open recursors are neither
good, nor evil. They are tools which like other tools, can be abused.  
Information about how they can be abused and what can be done would be
helpful.  But that description can't ignore the more fearsome attacks
available for authority servers.  For example, while dealing with any
DNS DOS attack, one must avoid blocking authority servers because there
are additional consquences to doing that.  Authority operators must also
avoid blocking queries when they detect abuse, since there are
additional consequences in that case, too.  These issues, quite
important to anyone actually dealing with an attack, are ignored and
dismissed.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 12 Dec 2007 16:34:38 -0500 (EST)

--Dean

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 13 Dec 2007 14:51:27 +0100

On Wed, Dec 12, 2007 at 07:42:10PM +0100,
 Peter Koch <[email-masked]> wrote 
 a message of 30 lines which said:

> The editors have submitted -05 as an attempt to cover the discussing
> ADs' concerns and we are - together with our AD - continuing work to
> get the DISCUSSes cleared.

The problem is that some are quite bogus. For instance,
https://datatracker.ietf.org/idtracker/draft-ietf-dnsop-reflectors-are-evil/comment/72422/
describes in detail why someone might not trust his ISP's resolver
(something quite obvious and with which we all agree) and then jumps
directly to say that the only solution is to allow ORNS, ignoring the
other solutions mentioned in the draft.

Is it really necessary to "address" such not-well-thought-out
comments?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 13 Dec 2007 14:51:27 +0100

---

From: Dean Anderson <[email-masked]>
Date: Thu, 13 Dec 2007 11:33:51 -0500 (EST)

> other solutions mentioned in the draft.

Instead of more tedious acronyms and jargon, how about just using 'open
recursors' to mean 'open recursors'?

Anyway, the comment was good. It is the solutions in the draft that are 
bad, for the reasons explained in the comment.

The notion that 'no one needs open recursors' has not been supported by
clear analysis in the draft. There are legitimate reasons to run open
recursors.  I think a lot of people on DNSOP share this view.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 13 Dec 2007 11:33:51 -0500 (EST)

--Dean

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Dec 2007 12:54:00 -0500

I'd like to direct a question to the chairs - would you summarize the 
open IESG discuss issues with the current document?  In this mail 
I'll allude to some of what I guess are the open discuss items.

Looking at the tracker there are discusses against -04 and a note 
that a new version is needed.  We have a -05 now, I suppose that 
qualifies as the new version.

Even though I am not an enthusiast of the notion that the attacks 
reported in spring 2006 incriminate open recursive resolvers, I think 
the draft should be published as it is and that we free this mailing 
list of any more arguments on the topic.

The document only recommends that name server code should be shipped 
with the open recursive configuration in the "off" position.  It does 
not say that operating an open recursive resolver is evil, despite 
the the file name.

Recommending that an operator attempt to scope the source of requests 
is harmless to those that want a wide open scope.  A recommendation 
of a scooping based on source IP address is not a client 
authentication vulnerability (as in it is trivial to spoof the source 
field of UDP) but is a reflection or a widely followed practice in 
operations.  Regardless of the IETF's notion of security, operators 
have their own rules of thumb and source IP address ACLs are part of 
that.

I can live with the details of the attacks, perhaps some find the 
prose confusing and I am sympathetic to calls to shore it up.  But I 
think that it really isn't crucial as the recommendations section is 
quite distinct from it.

There is one line in the -05 which I find to be the "meat."

"By default, nameservers SHOULD NOT offer recursive service to 
external networks."

Note the "by default."  If that were not present, I would object to 
the document.  To me, the statement is safe because there is no 
penalty to operating in any manner that is not the "default" way.  No 
justification is needed to diverge from "default."  So saying that 
the default is to not be an open recursive server is acceptable to me.

PS - The other comment in the discuss items - removing the 
possibility of amplification.  That can be done, but the cure is 
worse than the disease.  We can expand all queries to be the maximum 
acceptable response size (512 or to the size indicated via EDNS0) 
with padding of the queries.  That removes the incentive to use the 
recursive server as a reflector because you can then just have the 
botnet directly target the victim, probably with more aggregate 
bandwidth.  (Botnets could do that now, hit a victim with overstuffed 
DNS queries or falsified answers for that matter, thanks to UDP's 
fire and forget paradigm.)  For legitimate DNS, it would be a 
bandwidth waste.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Dec 2007 12:54:00 -0500

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 18 Dec 2007 10:09:56 +0100

On Mon, Dec 03, 2007 at 09:50:01PM -0500,
 [email-masked] <[email-masked]> wrote 

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

%  dig +short NS ietf.org 
ns1.yyz1.afilias-nst.info.
ns6.amsl.com.
ns0.amsl.com.
ns1.ams1.afilias-nst.info.
ns1.amsl.com.
ns1.hkg1.afilias-nst.info.
ns1.mia1.afilias-nst.info.
ns1.sea1.afilias-nst.info.

~ % dig @ns0.amsl.com. SOA  mq.
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 984
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;mq.                            IN      SOA

;; ANSWER SECTION:
mq.                     86400   IN      SOA     fado.mediaserv.net. noc.mediaserv.net. 2007062903 86400 7200 2592000 345600

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 18 Dec 2007 10:09:56 +0100

%  dig +short NS ietf.org 

;; QUESTION SECTION:
;mq.                            IN      SOA

;; ANSWER SECTION: