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

From: The IESG <[email-masked]>
Date: Tue, 11 Sep 2007 15:02:15 -0400

The IESG has received a request from the Domain Name System Operations 
WG (dnsop) to consider the following document:

- 'Preventing Use of Recursive Nameservers in Reflector Attacks '
   <draft-ietf-dnsop-reflectors-are-evil-04.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-09-25. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14686&rfc_flag=0

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

---

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: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 28 Sep 2007 09:19:31 +0200

---

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

_______________________________________________
DNSFrom [email-masked] Fri Sep 28 04:33:04 2007
Date: Thu, 27 Sep 2007 22:31:23 -0400
From: John C Klensin <[email-masked]>
To: Paul Hoffman <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil
 (Preventing Use  of Recursive Nameservers in Reflector Attacks)
 to BCP

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

OP mailing list
[email-masked]

---

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

--Paul Hoffman, Director
--VPN Consortium

---

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

--Paul Hoffman, Director
--VPN Consortium

---

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

Hi.

Yeah.

    john

---

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: Jaap Akkerhuis <[email-masked]>
Date: Fri, 28 Sep 2007 12:15:58 +0200

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

---

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

Joao

---

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

jaap

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

99); 
	Fri, 28 Sep 2007 13:20:27 +0200
To: [email-masked], [email-masked]
Date: Fri, 28 Sep 2007 12:15:58 +0200
From: Jaap Akkerhuis <[email-masked]>
Cc: 
Subject: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil
	(Preventing Use
	of Recursive Nameservers in Reflector Attacks) to BCP 

	jaap

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

---

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

I seem to remember that the ID actually mentions tFrom [email-masked] Fri Sep 28 07:26:16 2007

	jaap

---

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

Joao

hat.

	jaap

---

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

Joao

---

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: Paul Hoffman <[email-masked]>
Date: Fri, 28 Sep 2007 08:36:04 -0700

Indeed.

--Paul Hoffman, Director
--VPN Consortium

---

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

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

Paul

---

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

Joe

---

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

Joe

---

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

Paul

---

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

On Fri, 28 Sep 2007, Joe Abley wrote:

> 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 Hoffman <[email-masked]>
Date: Fri, 28 Sep 2007 09:16:12 -0700

--Paul Hoffman, Director
--VPN Consortium

---

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

--Paul Hoffman, Director
--VPN Consortium

---

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

Paul

g)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1IbIVM-0006zG-5M; Fri, 28 Sep 2007 12:15:52 -0400
Date: Fri, 28 Sep 2007 12:16:20 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Joe Abley <[email-masked]>
Subject: Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil
	(Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
Cc: [email-masked], Paul Hoffman <[email-masked]>, [email-masked]

Paul

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Sep 2007 15:16:29 -0400 (EDT)

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

Not widely supported in clients. Therefore, not a solution.

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

Maybe its not mentioned because its not a practical solution. But
whatever the reason it isn't mentioned, a 25 million user VPN is not
going to happen with 10/8. A comcast person recently complained on PPML
that there wasn't enough RFC1918 space for their internal network.

		--Dean

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

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Sep 2007 15:16:29 -0400 (EDT)

--Dean

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Sep 2007 17:08:42 -0400

> Not widely supported in clients. Therefore, not a solution.

In fact, it's quite feasible in operating systems which can run a  
local instance of (say) BIND9. It would be fair to say that  
installing and configuring BIND9 on an average laptop is far beyond  
the abilities of the average laptop owner, but that's presumably just  
a matter of packaging.

> going to happen with 10/8.

Well, that depends on what you mean by "VPN". If you mean "a hub and  
spoke topology of tunnels, all concentrated centrally" then yeah,  
that sounds like a bit of a stretch. If you mean "use of AH in  
queries sent towards a resolver which is configured somehow to  
discard packets that are not authentic" then I suspect there are ways  
to make that scale, even for quite large client populations.

(I might choose to incorporate anycast into such a design. You,  
presumably, would not. :-)

> A comcast person recently complained on PPML

I have heard such reports from Comcast in various forums. I have no  
reason to doubt them. I do not think that is especially pertinent to  
the question at hand, however.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 28 Sep 2007 17:08:42 -0400

Joe

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Sep 2007 17:29:43 -0400 (EDT)

> that there wasn't enough RFC1918 space for their internal network.

Time for them to migrate to IPv6? :)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Sep 2007 17:29:43 -0400 (EDT)

Paul

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Sep 2007 22:55:31 -0400 (EDT)

> Time for them to migrate to IPv6? :)

There was an extended discussion of that.  It was suggested that IPv6
would be killed by IPv4 IP address exhaustion through route table
expansion.

I suggested that maybe IPv6 was already dead, and that one might
consider instead CLNP/TUBA (RFC1347, RFC1561, et al) because it works
already.  One would use ISIS and IDRP instead of OSPF and BGP. Then add
IPv4 proxy gateways and client support as necessary, etc.  I was
surprised to find that this is about as much work as what remains for
IPv6, and we know that CLNP is stable.

I digress. I wrote a detailed message posted on 9/10 on the subject if 
anyone is interested. Contact me offlist, or look in the ppml archives 
at arin.net.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Sep 2007 22:55:31 -0400 (EDT)

--Dean

---

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

---

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

Ned

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 29 Sep 2007 21:46:30 +0200

On Fri, Sep 28, 2007 at 05:29:43PM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 10 lines which said:

> > A comcast person recently complained on PPML that there wasn't
> > enough RFC1918 space for their internal network.
> 

That's exactly what Comcast is doing:

http://www.nanog.org/mtg-0606/durand.html

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 29 Sep 2007 21:46:30 +0200