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

From: Danny McPherson <[email-masked]>
Date: Sun, 30 Sep 2007 22:32:39 -0600

I do support this document being published as BCP.

A couple of minor comments:

Section 4's reference to BCP 84, in part, creates a false sense of
useful action on part of the operator, IMO (in addition, there's a
typo; s/were/where/).

    In situations were more complex network setups are in place,  
"Ingress
    Filtering for Multihomed Network" [BCP84] maybe a useful additional
    reference.

Perhaps clarifying that Strict and Feasible methods do provide some
protection, but Loose provides zero protection from reflective attacks,
as they really only require that the target "exist" - they usually do.

You might stress that the "IP based authentication" recommendation
is pretty much useless -- unless you implement policy at all ingress
points (including from peers/providers).  In particular, if you don't  
filter
you're permitted-query-address-sources coming from "the Internet" or
peers, then spoofing can still be used to launch reflective attacks:

    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.

Also, I'm not sure I'd call this "authentication", perhaps IP-based
access policy" is more appropriate?

Some more details and recommendations on SOHOish ORNS
might be useful for implementers.

As for the TSIG or SIG(0) recommendation, I'm not sure what
the numbers are for client support today, but I suspect it's at
best an negligible sample.

I also agree with Paul Hoffman's comments on some reasons
for ORNSs.  There are many reasons why I may want to use a
specific resolver consistently, to include those outlined by
Paul/John.

-danny

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 1 Oct 2007 09:52:27 +0200

On Sun, Sep 30, 2007 at 10:32:39PM -0600,
 Danny McPherson <[email-masked]> wrote 
 a message of 51 lines which said:

> useful action on part of the operator,

This could be said of all the parts of the I-D which mentions non-DNS
issues such as BCP 38. In that respect, I full agree with Stephen
Hanna's review
(http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html).

> Some more details and recommendations on SOHOish ORNS might be
> useful for implementers.

Any idea? The current draft mentions "Incoming Interface based
selection" and I do not see what to add?

> I also agree with Paul Hoffman's comments on some reasons for ORNSs.
> There are many reasons why I may want to use a specific resolver
> consistently, to include those outlined by Paul/John.

Sorry, but their messages are quite off the track. The problem is not
wether there is an use case for using a resolver different from the
one provided by the current access point. There are, indeed, many
reasons for *not* using the default resolver (ISP which violates RFC
4925, section 2.5.2 are a very good example). But ORNS are *not* the
proper solution for that use case. TSIG signatures, VPNs, local
caching resolvers are the good solutions.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 10:47:44 -0600

> (http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html).

I read Stephen's comments before posting, and I agree
as well.

However, the BCP 84 bit is slightly different because it's
only useful for mitigating reflective attacks IF it's employed
in a particular way.  If this document is going to reference it
then it should make a distinction here.

> selection" and I do not see what to add?

Perhaps expanding in the "Problem Description" section
would be beneficial.  Something mentioning that Many
SOHO and broadband access devices provide some flavor
of name resolution services (e.g., there are 4 flavors
outlined by JKT and others; Recursive, Forwarder, Caching-
only and Restricted).

Some other empirical bits might be useful as well, though
and although I'm not sure they need to be in the I-D, they
would be useful:

E.g., 16M recursive "type" servers, , with 800k or so being
the larger problem.   Also, some references that provide usual
information on actual numbers, such as John's work here:

http://condor.depaul.edu/~jkristof/orns/
http://maps.measurement-factory.com/gallery/Openresolvers/

And this is particularly illustrative:

http://maps.measurement-factory.com/gallery/Openresolvers/20070429.png

As for the current text, you don't provide much in the way
of explaining that queries should probably not be accepted
from the Internet/untrusted interfaces, you just essentially
state that interface-based discrimination might be employed.
That was my initial concern.  If your attempt is to progress as
BCP, then some actual specific guidelines on this front
for implementers and administrators alike might provide more
actionable information.
> caching resolvers are the good solutions.

I think you made my point.  Where is this currently explained in the
document as such?  Acknowledging existence and practical realities
is important, methinks.

-danny

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2007 11:42:01 +1000

> best an negligible sample.

	Well all Windows XP/2003/Vista boxes can be configured to
	support TSIG, with free software, if not natively.

	All Linux, *BSD and Apple boxes can do this with what ships
	with the OS.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Danny McPherson <[email-masked]>
Date: Mon, 1 Oct 2007 19:52:33 -0600

> 	All Linux, *BSD and Apple boxes can do this with what ships

Sorry, I said "support", I meant "use".  Any numbers there?

-danny

---

From: Mark Andrews <[email-masked]>
Date: Tue, 02 Oct 2007 13:45:30 +1000

> Sorry, I said "support", I meant "use".  Any numbers there?

	I use TSIG on my laptop.

	As for others I have no idea.

	Mark

---

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.

---

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: Paul Wouters <[email-masked]>
Date: Fri, 28 Sep 2007 12:16:20 -0400 (EDT)

On Fri, 28 Sep 2007, Joe Abley wrote:

> I'm surprised by that comment.
>
> I think it's a common use case that organisations who deploy VPNs have split
> DNS; that is, namespaces available through internal network resolvers that do
> not appear in the global namespace. In my experience, it is normal for:
>
> - VPN client software to use IP addresses rather than names to establish a
> secure tunnel with the home network

If you are a worldwide organisation, you want to connect to the nearest
VPN point, and not your "home vpn point". This is done by customising
DNS answers (eg bind views or akamai like setups). The last thing I want
is for my Dutch branch, to connect me to the company vpn in The Netherlands,
when I'm in the US, crossing the atlantic twice.

You only start to use the internal company's DNS server, after you have
connected to the VPN - if only to resolve internal network only machines.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Sep 2007 12:07:56 -0400 (EDT)

On Fri, 28 Sep 2007, Jaap Akkerhuis wrote:

>     There are two major reasons for an organization to not want roaming
>     users to trust locally-assigned DNS servers.
>
> Open recursive servers doesn't help in against man in the middle
> attacks. If you want to avoid that use VPN's or (for DNS) TSIG.

That's why you want your own caching resolver on your laptop. But I
guess hotspots won't work as well with that. Then again, the whole
captive portal by hacking up DNS packets needs to go away when DNSSEC
deployment deems that interfering inappropriate.

Is there some IETF work going on to standarize captive portal bootstraps?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Sep 2007 12:16:20 -0400 (EDT)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Sep 2007 12:16:20 -0400 (EDT)

Paul

---

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 .