Subject: [dnsop] WGLC for draft-ietf-dnsop-reflectors-are-evil-02.txt

From: Peter Koch <[email-masked]>
Date: Thu, 26 Oct 2006 19:34:11 +0200

Dear WG,

this message initiates a working group last call for

	"Preventing Use of Recursive Nameservers in Reflector Attacks"
		draft-ietf-dnsop-reflectors-are-evil-02.txt

to be published as a BCP. The WGLC will end Sat, 2006-11-11 23:59 UTC.

Please review and comment on this draft on this mailing list. The chairs
will not forward the document to the AD unless at least five reviewers
have indicated their support (for both the draft and the intended status).
Vendors' indication to follow (or not) the recommendation would be appreciated.

Please also include editorial comments; there will be a -03 anyway since
the current draft does not yet have an IANA considerations section.

Given the title, the history and the purpose of this draft (remember the
attacks launched at the beginning of this year?), vulnerability of other
systems or server types to (becoming an accomplice in) reflection or
amplification attacks and their specific counter measures is out of scope
for this particular document.

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Oct 2006 16:08:45 +0200

On Thu, Oct 26, 2006 at 07:34:11PM +0200,
 Peter Koch <[email-masked]> wrote 

> 		draft-ietf-dnsop-reflectors-are-evil-02.txt

I've reviewed it and I approve the document and its intended status.

I have a reservation which may be addressed in -03 by an editorial
change. The draft repeats many (too many) times that "the only truly
real solution, the wide-scale deployment of ingress filtering". In
computer and network security, sentences such as "the only truly real
solution" are meaningless and should be used only by marketeers. (For
instance, BCP 38 does not prevent attacks when the attacker and the
victim are on the same side of the filters, for instance when they are
customers of the same ISP, and this ISP deploys filtering only at its
borders.)

I suggest to say instead something like "a better solution, the
wide-scale deployment of ingress filtering". 

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Oct 2006 21:03:47 +0300 (EEST)

> customers of the same ISP, and this ISP deploys filtering only at its

While I agree that the text need not necessarily be so absolute, I 
would not consider the ingress filtering proper or wide-scale 
deployment.  Better than nothing, to be sure, but not enough.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Oct 2006 22:28:09 +0300 (EEST)

> would not consider the ingress filtering proper or wide-scale 
                     ^^^
oops, wrote too fast: I meant s/the/such/

---

From: Mark Andrews <[email-masked]>
Date: Sat, 28 Oct 2006 08:42:10 +1000

> customers of the same ISP, and this ISP deploys filtering only at its
	
	Remember the ISP's network borders with their customers
	network / hosts.  BCP 38 says that it should be applied
	at that border.

	ISP's should be preventing customers spoofing other
	customers.  Apart from broadcast media this should not
	be impossible.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
.
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, 30 Oct 2006 02:46:53 -0500 (EST)

I've reviewed the draft, and do not find it suitable for publication.  

I strongly oppose the draft for the reasons described in:
http://darkwing.uoregon.edu/~llynch/dnsop/msg03891.html
http://darkwing.uoregon.edu/~llynch/dnsop/msg03893.html
http://darkwing.uoregon.edu/~llynch/dnsop/msg03902.html

A great number of issues, logic flaws and false assumptions identified
previously with the document, have not been addressed nor corrected.

During 2 sessions of discussion, the authors made assertions for which
there is no basis in fact.  In the second session, the authors and
proponents simply repeated claims discredited in May, as though those
arguments had no prior opposition whatsoever. They just repeated a
mantra, as if repeating it often and ignoring the contrary evidence
somehow makes the mantra true.

Documents published by the ISOC should be based on facts, not on
disputed, unsupported, even illogical assertions, and should be as
accurate as possible. High standards of fidelity are required. This
document does not meet such standards. Documents should also have a high
degree of community interest, which hasn't been seen for this document.  
Many of the messages and most of the support has been from persons
closely associated with the authors.

In my opinion, this working group should not be in the business of
uncritically approving documents which cannot stand critical
examination, and will, therefore, be subsequently discredited.  It may
take some time to discredit such a faith-based belief, especially in the
face of promotion using the ISOC's credibility, but time passes, and the
results are permanent.

Dean Anderson
Av8 Internet, Inc

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

.

---

From: Joe Abley <[email-masked]>
Date: Mon, 30 Oct 2006 08:55:04 -0500

On 30-Oct-2006, at 08:21, Joe Abley wrote:

> I may be procedurally out-of-touch, but in a recent draft I was  
> involved in editing that was also aimed at BCP and which was  
> subject to a lot of IESG scrutiny, I was repeatedly criticised for  
> including an "IANA Considerations" section which included the  
> single sentence "This document requires no actions of the IANA".
>
> I was told that if no actions are required, no IANA Considerations  
> section is necessary.

My memory was faulty -- in fact it was a "Protocol Considerations"  
section which contained the single sentence "This document does not  
impose any protocol considerations" that was criticised ("This  
section does not impose any knowledge. What is it for?").

As was pointed out to me at that time the IANA and Security  
Considerations sections are required, but Protocol Considerations are  
not.

Joe
.

---

From: Joe Abley <[email-masked]>
Date: Mon, 30 Oct 2006 08:21:14 -0500

> Vendors' indication to follow (or not) the recommendation would be  

I have just reviewed this version of the document, and I support its  
publication as BCP as-is.

If another version is rolled for some reason, I would modify section  
3, replacing the following text:

    o  Use TSIG [RFC2845] or SIG(0) [RFC2931] 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 (e.g. roaming clients).  The current
       drawback of this method is that very few stub resolver
       implementations support TSIG or SIG(0) 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 nameserver of choice.

with something like this:

    o  Use TSIG [RFC2845] or SIG(0) [RFC2931] signed queries to
       authenticate the clients.  This provides stronger authentication
       of clients than access lists based on query source addresses,
       and also facilitates access by authorised clients whose IP
       addresses change unpredictably (e.g. roaming clients). Practical
       drawbacks to this approach include the problem of key
       distribution, the requirement for clients and servers to have
       synchronised clocks, and the lack of deployed resolver
       implementations which support either TSIG or SIG(0).

Specifically, I think that key distribution and time synchronisation  
issues should be mentioned, the frequency of IP address changes is  
not the real problem (it's the problem of predicting what addresses  
will be used), and that the comment about running a local forwarder  
is redundant given the comment about resolver implementations (and  
has the slight aroma of implementation-specific advice).

However, as I mentioned above, I support -02 being published as-is  
without these changes.

I may be procedurally out-of-touch, but in a recent draft I was  
involved in editing that was also aimed at BCP and which was subject  
to a lot of IESG scrutiny, I was repeatedly criticised for including  
an "IANA Considerations" section which included the single sentence  
"This document requires no actions of the IANA".

Joe

.