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

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Sep 2007 18:45:55 -0700

The Security Considerations section for this document is much too 
narrow. It ignores one of the main reasons that many organizations 
purposely choose to provide recursive lookup to the public, namely 
for their own roaming users. Without an open, known-good nameserver 
at a fixed address, roaming users need to trust whatever is given to 
them by their ISP at the moment, and it is reasonable for 
organizations to consider this too large of a risk. Unless the 
organization has a way to tunnel DNS queries back to a non-recursive 
nameserver (such as through IPsec), having a recursive nameserver 
available increases the security of their roaming users.

There are two major reasons for an organization to not want roaming 
users to trust locally-assigned DNS servers.

- An attacker might have compromised the DHCP server to which the 
user conntect to point to a compromised DNS server. Although such an 
attacker can also cause the DHCP server to point to a compromised 
next-hop router, it is easier and less detectable for most attackers 
to compromise a DNS server than a router. There are plenty of 
examples where compromised DNS servers lead to spoofing and MITM 
attacks.

- Some ISPs use DNS servers that purposely do not follow the same 
good practices that the organization uses. In particular, some ISPs 
have used bogus TLDs and name-lookup services to generate revenue.

The Security Considerations section needs to deal with these issues, 
even if they do not change the advice given in section 4.

--Paul Hoffman, Director
--VPN Consortium

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 27 Sep 2007 22:31:23 -0400

--On Thursday, 27 September, 2007 18:45 -0700 Paul Hoffman
<[email-masked]> wrote:

> The Security Considerations section for this document is much
> too narrow. It ignores one of the main reasons that many
> organizations purposely choose to provide recursive lookup to
> the public, namely for their own roaming users. Without an
> open, known-good nameserver at a fixed address, roaming users
> need to trust whatever is given to them by their ISP at the
> moment, and it is reasonable for organizations to consider
>...

Hi.

I want to express general agreement with Paul's comment, but
also to stress the importance of one of the points he has made...

Even if one ignores attacks of the usual sorts (i.e., bad acts
conducted out of malice or juvenile behavior) the ISP who plays
alternate root, DNS query interception and diversion, and
similar games is too large for comfort and probably growing.
Paul's explanation of this: 

> - Some ISPs use DNS servers that purposely do not follow the
> same good practices that the organization uses. In particular,
> some ISPs have used bogus TLDs and name-lookup services to
> generate revenue.

covers most of the problem, but it is perhaps also useful to
point out that some of these ISPs try to block DNS traffic that
is not directed to their preferred servers.  For many users and
enterprises, the warning implicit in not being able to reach
their own servers under those circumstances is an important, and
security-enhancing, source of information.   Of course, some of
those ISPs take the next step and divert all DNS traffic,
regardless of specified destination, to their own servers, but
the fact that simply making recursive nameservers available
doesn't solve it (at least absent well-deployed DNSSEC) doesn't
mean that the often-useful "use your own server" approach is
useless or should be avoided.

> The Security Considerations section needs to deal with these
> issues, even if they do not change the advice given in section
> 4.

Yeah.

    john

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 28 Sep 2007 09:19:31 +0200

On Thu, Sep 27, 2007 at 06:45:55PM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 36 lines which said:

> It ignores one of the main reasons that many organizations purposely
> choose to provide recursive lookup to the public, namely for their
> own roaming users.

No, it is *not* ignored. See section 4, for instance :

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

VPN are another solution, although not mentioned in the I-D, may be
because it is obvious.

---

From: SM <[email-masked]>
Date: Fri, 28 Sep 2007 02:07:43 -0700

At 18:45 27-09-2007, Paul Hoffman wrote:
>them by their ISP at

The same question of trust is applicable to general users as well as 
you pointed out in your comment about ISPs.

>even if they do not change the advice given in section 4.

Although this document does not create any new security issues for 
the DNS protocol, it may be an issue for users of the service.  A 
note covering the points you raised could be added under security 
considerations.

Regards,
-sm

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 28 Sep 2007 12:15:58 +0200

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.

I seem to remember that the ID actually mentions that.

	jaap

---

From: Joao Damas <[email-masked]>
Date: Fri, 28 Sep 2007 13:20:53 +0200

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

Joao

On 28 Sep 2007, at 12:15, Jaap Akkerhuis wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Sep 2007 08:36:04 -0700

>       change IP address frequently (e.g. roaming clients).

This is a suggestion for something that essentially no one can use 
today (as is admitted after the text after the quote).

>VPN are another solution, although not mentioned in the I-D, may be

It is not "obvious", at least to some of the people I have spoken 
with. It is also not obvious to VPN vendors; otherwise, they would 
have easy-to-use settings to make it happen. None of the VPN client 
that I have seen have such settings. Listing such things in the 
Security Considerations section of a document is a good practice, 
regardless of what you think is obvious.

>Open recursive servers doesn't help in against man in the middle

Correct; no one said that they did. Open recursive name servers help 
against against roaming users being directed to DNS servers whose 
security policy is different than their organizations'.

>If you want to avoid that use VPN's or (for DNS) TSIG.

Indeed.

>I seem to remember that the ID actually mentions that.

I cannot find any mentions of VPNs or IPsec. Given that the document 
admits that TSIG and SIG(0) are essentially unavailable today on end 
users systems, and IPsec is much more common, saying something about 
this in the Security Considerations section might be of value. As my 
earlier message said, this is not for Section 4, which is only 
talking about authentication of clients.

>further protection, is, at best, naive.

 From the standpoint of the organization whose security policy 
includes the way their users do DNS resolution, it is better than 
nothing, and this document's "best practices" pretty much limit them 
to nothing. For a non-ISP, ingress filtering will not help at all 
(even though it should still be implemented, and customers should 
urge their ISPs to implement it). IP-based authentication does not 
work for mobile users. Interface-based authentication does not work 
for mobile users. TSIG and SIG(0) does not work for mobile users 
until it is implemented in their computers, which the draft admits it 
is not for the vast majority of users.

If the document doesn't want to deal with those organizations, it 
needs to say so in the introduction and again in the Security 
Considerations section.

--Paul Hoffman, Director
--VPN Consortium

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Sep 2007 12:04:34 -0400

On 28-Sep-2007, at 1136, Paul Hoffman wrote:

> have easy-to-use settings to make it happen.

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
  - Local resolver settings on the VPN client's machine to be re- 
written to use internal home network nameservers while the VPN  
session is active

This is certainly how the cisco VPN client supplied to me by my  
employer (and the subsequent versions I've downloaded directly from  
cisco) work, for example. I was under the impression that cisco had  
fairly significant market share in this area.

This is not to say that the topic doesn't deserve mention in the  
draft at hand. However, your logic in the last sentence above seems  
suspect to me.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Sep 2007 09:16:12 -0700

At 12:04 PM -0400 9/28/07, Joe Abley wrote:
>  - Local resolver settings on the VPN client's machine to be 
>re-written to use internal home network nameservers while the VPN 
>session is active

That's completely true for remote users who are already using a VPN. 
In that case, there is no reason for the organization to have a 
recursive resolver facing outwards.

What was being discussed was setting up a VPN just for getting DNS 
resolution, not for access to other internal resources. IPsec can be 
used to create a tunnel to just a single resource if the organization 
wants the external user to access that resource only.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ned Freed <[email-masked]>
Date: Fri, 28 Sep 2007 09:17:25 -0700 (PDT)

> I'm surprised by that comment.

I'm not. As it happens I've used three different VPN services in the past few
years and I will soon be forced to switch to a fourth. In each case the IT
folks managed to jury-rig things so that DNS queries got redirected, but I've
been told in some cases it required quite a bit of effort. And it is also my
understanding that requiring this significantly limited our our options in
choosing VPN solutions.

> network resolvers that do not appear in the global namespace.

Yes, we have this in spades at Sun. Can't say it works all that well, but this
is really a separate issue.

> In my experience, it is normal for:

> establish a secure tunnel with the home network

I'm sure this is done, but I think it is more common to use DNS entries. You
have to validate the server's certificate or whatever anyway, so all direct use
of IP address does is limit certain denial of service attacks but at the cost
of a significant loss in flexibility.

> written to use internal home network nameservers while the VPN

Yeah, that's what the client ends up doing. I don't know the specifics of how
this has been implemented in the various clients I've had to use, but it has
tended to be quite fragile - on numerous occasions things have failed in such a
way that my DNS settings were completely trashed and I had to go in and reset
them manually. I eventually wrote a little script I can run to force things
back to where they're supposed to be with a single command.

Perhaps if this the need for this were called out more specifically more
attention would be paid to making this work well.

> fairly significant market share in this area.

Since I don't really know who or what's responsible for the many problems I've
seen with this I'm not going to provide specifics regarding the clients I've
used. However, I will say that I think you've had a fair bit of luck here.

> draft at hand. However, your logic in the last sentence above seems

FWIW, I am in full support of Paul and John's position here.

				Ned