Re: [DNSOP] draft-ietf-dnsop-reflectors-are-evil-05.txt

[Dean Anderson <[e-mail]>]

On Wed, 12 Dec 2007, Peter Koch wrote:

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

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


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




_______________________________________________
DNSOP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dnsop