Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Oct 2007 12:40:31 -0400

>>>>> "Joao" == Joao Damas <[email-masked]> writes:

    Joao> It does indeed as Stephane pointed out.  Opening up your
    Joao> resolver so you can server roaming users, without further
    Joao> protection, is, at best, naive.

I'd appreciate it if you took Paul's comments a lot more seriously and
looked at whether the dnsop view on this issue extends to other parts
of the ietf.  To the extent that it does not, please engage in a
discussion designed to build consensus rather than assertions that
someone who disagrees with you is naive.

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Oct 2007 12:40:31 -0400

(Exim 4.43)
	id 1IczmF-0003Lh-Pf; Wed, 03 Oct 2007 04:40:19 -0400
From: Sam Hartman <[email-masked]>
To: Joao Damas <[email-masked]>
Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil
	(Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
Date: Tue, 02 Oct 2007 12:40:31 -0400
Cc: [email-masked], Jaap Akkerhuis <[email-masked]>, [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 3 Oct 2007 11:25:38 +0200

On Tue, Oct 02, 2007 at 12:40:31PM -0400,
 Sam Hartman <[email-masked]> wrote 
 a message of 17 lines which said:

> I'd appreciate it if you took Paul's comments a lot more seriously
> and looked at whether the dnsop view on this issue extends to other
> parts of the ietf.  To the extent that it does not, please engage in
> a discussion designed to build consensus rather than assertions that

OK, since I agree with Joao Damas on this point, let me rephrase it
(again) without harsh words.

Everyone took Paul Hoffman's and John Klensin's comments
seriously. But these comments have a big flaw, they jump from the
(legitimate) use case to a specific (and bad) solution. John Klensin's
message wasted many bytes describing the (well known) problem instead
of trying to see if the current I-D properly describes the solutions.

Everyone agrees that there is a very real and very legitimate use case
for roaming users to *not* use the default DNS resolver of the current
access point (see RFC 4925, section 2.5.2 for a typical reason).

But suggesting ORNS (Open Recursive Name Servers) for the solution to
this issue is, indeed, a bad idea (do note I did not say the N word),
for the reasons explained in
draft-ietf-dnsop-reflectors-are-evil-04.txt (reflections attack).

There are other solutions to this issue and lists have already been
given in this thread *and* in the I-D we discuss. These solutions are
TSIG, local caching resolvers and VPN. May be there is an editorial
problem if they are not well explained but the I-D does completely
cover the issue of romaing users.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 3 Oct 2007 11:25:38 +0200

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2007 10:58:21 -0400

>>>>> "Stephane" == Stephane Bortzmeyer <[email-masked]> writes:

    Stephane> But suggesting ORNS (Open Recursive Name Servers) for
    Stephane> the solution to this issue is, indeed, a bad idea (do
    Stephane> note I did not say the N word), for the reasons
    Stephane> explained in draft-ietf-dnsop-reflectors-are-evil-04.txt
    Stephane> (reflections attack).

Hmm.  All I get is that suggesting open recursive nameservers has the
harm that it creates reflection attacks.  The current text of section
4 to me says that you SHOULD NOT offer recursive name service by
default and the generic recommendation is that you should not offer
recursive name service to other clients than those you need.  However
if I've evaluated the harm caused by the attack, evaluated the costs
of other solutions and concluded that the best tradeoff is running an
open recursive nameserver, I can do so.  That seems like a balanced
and reasonable approach.

If you intend the draft to same something else, you have some work to
do.

    Stephane> There are other solutions to this issue and lists have
    Stephane> already been given in this thread *and* in the I-D we
    Stephane> discuss. These solutions are TSIG, local caching
    Stephane> resolvers and VPN. May be there is an editorial problem
    Stephane> if they are not well explained but the I-D does
    Stephane> completely cover the issue of romaing users.

People have explained why the cost/benefit tradeoff may not favor
these solutions.  tsig is not realistic in the current software
implementation space; it has promise for the future.  VPN is very
complicated and probably not worth it if all you want is more reliable
nameservice.  (I do understand the man-in-the-middle and transparent
proxy issues).  Caching resolvers are problematic for deployment
complexity reasons .

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Oct 2007 10:58:21 -0400