Subject: [v6ops] Soliciting feedback on draft-livingood-dns-whitelisting-implications

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 1 Oct 2010 18:28:20 +0000

Hi -

I am soliciting feeback on this new draft, available at http://tools.ietf.org/html/draft-livingood-dns-whitelisting-implications. In particular, I am looking for more text to add in the justifications / rationale for this practice in an attempt to objectively examine the issue from many sides.  This is only a first draft of course.

Regards
Jason Livingood

---

From: Erik Kline <[email-masked]>
Date: Fri, 1 Oct 2010 15:03:42 -0700

On 1 October 2010 11:28, Livingood, Jason
<[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

In general:

    * consider the similarities to DNS load balancing
    * consider the similarities in implication to DNS64
    * you should understand and document that no network-level access
control restrictions are implied

There seems to be some confusion wrt to this last point throughout the document.

A few other, technical issues listed below.

[Section 2]

Your examples/diagrams imply that an end client requests a general
list of addresses for www.example.com.  [I actually might prefer it if
that were true.]  In practice however A RR lookups are separate, and
usually subsequent to, AAAA RR requests.  If a record of any kind
exists for the name being resolved but the server is not going to
return the RR type requested (usually because it genuinely doesn't
exist) then OK with 0 RRs in the answer section is what is returned.
In the case of whitelisting the code is slightly more complex in that
if an AAAA is the only record in the zone for the name being requested
and that name is not going to be returned then it's probably more
correct to return NXDOMAIN; otherwise if other RRs (e.g. A) then
SUCCESS with 0 RRs in the answer section is the proper response.
These examples and diagrams might be a bit more technically precise
wrt DNS mechanics (although I understand that there is no IETF RFC or
draft discussing the true mechanics of whitelisting wrt the DNS
protocol).

[Section 3]

"Some parties" requires a reference.  Otherwise "some parties" might
just be you.  Since I know this is not the case, and I also know that
references exist, please link to one from here (and elsewhere).

The "model" of DNS described is also not quite the current state of
the world.  "Everyone", in deliberate quotation marks, employs DNS
load balancing and any specific A RR may never be seen by some
requesters (usually because of geographic/network latency
considerations).  Your text implies that DNS for A RRs is currently
vastly more egalitarian than it actually is.  Perhaps discussion of
DNS load balancing and its relationship to whitelisting could
supplement section 4, which might then be relabeled "Similarities to
other DNS Operations", or something.

[Section 6]

All basically true; it's mostly about the end user experience.  This
is also the primary motivation behind DNS load balancing, the way CDNs
do it.

Although I'll add this odd anecdote.  In the course of discussing
whitelisting with a few different organizations I have actually been
told by some operators/administrators that they did not want us to
serve them AAAAs.  Upon further discussion what became clear is that
some folks don't want the full load of youtube traffic to shift to
their IPv6 infrastructure until they're ready to support it.

So yes, we've had requests from folks to /not/ be served AAAAs.  At
first I was surprised, but now I understand.

[Section 7.1]

The end-to-end model does not prevail on the IPv4 Internet today.  See
previous comment.

It is not clear how operators of authoritative servers for domains are
somehow "in the middle" of the network, except possibly as transit
points on the resolution path to subdomains.  Perhaps you mean "in the
middle" in some social or political sense?  In which case you may wish
to select a different document, or different subsection, to reference.

[Section 7.2]

Again: not true in the IPv4 Internet today where DNS load balancing is employed.

Note also that "reachability", in the true sense, is unaffected by the
whitelisting you're talking about.  It's network "knowledge" or
"awareness" that's affected.  There is no discussion of ACLs that
prevent IPv6 connections from succeeding, just like there is no
discussion of ACLs that prevent IPv4 connections from succeeding.
Whitelisting, as I believe you're trying to discuss it, only refers to
a resolver's awareness that an IPv6 address is associated with a
hostname.  No barriers to true reachability exist.

[Section 7.4]

What is the definition of an "important domain"?

[Section 7.5]

The relationship to governmental censorship seems imprecise, or
inapplicable.  In the governmental censorship case, logical access to
a resource is denied, as mandated by law.  In the whitelisting case,
logical access to a resource /remains unrestricted/.

[Section 7.6]

Do you have a reference to anyone who has publicly stated they are not
deploying IPv6 and that the principal reason for their not deploying
IPv6 is somehow whitelisting-related?

[Section 9.1]

Quite the contrary: any implementation of DNS whitelisting that also
seeks to support DNSSEC must be extremely careful in doing so.  The
implications are very similar to those of DNS64.

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Fri, 22 Oct 2010 20:52:34 +0000

I have reviewed this draft (-01 version), and have some comments. I think that there's value in having a draft like this, so keep up the good work!

First, I might recommend taking your introduction and splitting it into a basic explanation of what whitelisting is, and then move the section where you discuss *why* people are doing this into its own section. Since you have a specific section on concerns, it would make sense to have a complimentary section on justification/pros for using whitelisting.

Second, in your concerns section (3), you refer to "these [concerned] parties" multiple times. I think it would be cleaner to simply start the section as you have (concerns in parts of the internet community), and then just discuss the issue. Rather than trying to distance yourself in your language from the concept being expressed, with "some people say..." just state it as fact. While not everyone may agree with the opinion being discussed, you are still stating a factual representation of the opinions of a group of folks, so I don't think that it's necessary to qualify it so much. I think that would be clearer and cleaner than the current language.

You talk in the concerns section about the fact that whitelisting requires new IPv6 networks to seek out and contact all of the whitelisters to get their DNS resolvers approved, and how that is difficult and time-consuming, but I think that you could clarify why this is a bad thing, independent of the effort required to manage it. You mention barriers to IPv6 deployment, but I can think of a specific example that may help to clarify what you mean: When you deploy IPv6 in any form on an eyeball network, it is often at least partially as a way to reduce the pressure on IPv4 exhaustion within that network, as well as to reduce the load on any IPv4 extension technologies that you may have implemented (NATs of various flavors, DSLite, etc). Anything that can go native IPv6 can likely bypass that infrastructure, depending on implementation. Whitelists dramatically reduce this benefit by masking what would otherwise be IPv6-reachable content and keeping it on the IPv4 infrastructure. It's not really a question of preventing IPv6 deployment, as that really shouldn't still be a question. Really, it is preventing providers from being able to leverage what they have deployed. While you could argue that even a partial whitelist (based on your top 10 customer destinations) would help, the other several thousand that are missing have a combined negative effect that should be noted here.

You touch on this a bit in your section on de-listing and in 7.4 but whitelisting can also provide a false sense of security to the content network, and it is highly reliant on the vetting process and the individual network implementation in order for it to actually provide the benefit being sought.
What I mean by this is, even on a network with ubiquitous IPv6 support, if it is opt-in, or reliant on compatible customer-owned CPE, I can still have a "broken" host behind legacy equipment and have a bad user experience.
Unless the network in question is very homogenous, and IPv6 is deployed in the same way (and possibly the same time) network-wide, there is a question as to whether the whitelister can trust the requestor (whitelistee?) that their entire network will provide the expected level of IPv6 service everywhere. If the requestor happens to provide publicly reachable DNS cache servers, there is no guarantee that all hosts using those servers are not "broken" and may well defeat the purpose of the whitelist.
So the alternative is to either deny those networks whitelist until they are nearly finished with what may be a multiyear IPv6 deployment, or take what are essentially the same risks of poor end user experience, and hope that they'll be resolved before they're overly detrimental to your business. Otherwise, it may require the end network to make architectural changes to their DNS infrastructure to ensure that they can segregate the IPv6-capable parts of the network onto one set of resolvers that are separate from the IPv4-only sections, or make their whitelisted resolvers no longer publicly available, etc.

This problem can be even worse in SPs that serve primarily commercial/enterprise networks. Residential network SPs can make a reasonable assumption that the majority of their customers will be using the in-network resolvers. Large ISPs with large business customers cannot assume this. In fact, the majority of their customers may be rolling their own DNS caches locally. Some may ultimately point back to the ISP's cache servers, but an equal amount will do their own recursion from the root, or point to someone else's DNS resolvers. This now dramatically increases the scope of folks that must be whitelisted to see any benefit from an IPv6 deployment, and as an ISP, I have almost no control over whether my customer expends the energy (or even knows how) to get their servers whitelisted.

Regarding section 5 - I'm not sure I agree with the assertion that whitelisting would need to be built into all auth server software for universal implementation. The proposal I saw for making this a little less manual (I would cite a draft, but I'm not aware of one - Erik Kline from Google presented the idea at a conference) used in-addr.arpa TXT records, combined with some external scripting to collect and verify IP addresses of resolvers to feed into whitelists. I would think that this could be implemented without special software in the auth server itself, but I'm by no means an expert on existing implementations of DNS auth/whitelist as to where the magic actually happens. I just bring it up as a point to verify.
I think that there is also a subset that is sort of both of your two categories - ad-hoc deployment, but universal (if still mostly ad-hoc) coordination. Think in terms of a well-known email distro ([email-masked]) or website (like peeringdb) that anyone who is whitelisting their auth servers can join, and when new people want to qualify their networks for whitelisting, they send mail to that address. This at least removes the barrier associated with having to find and reach all of the folks who are doing the whitelisting.

Also, you should point out a potential timing issue with universal implementation - if we go the route of standardizing a whitelisting implementation (pushing through IETF, multiple vendors implementing, multiple networks using), we're likely to miss the window where this actually matters. Ultimately, I have always understood whitelisting to be a set of "training wheels" until big content providers were more confident that IPv6 would work for enough of their users that there was no risk in mainstreaming their AAAA records. In most cases, this translates into an increase in the amount of good IPv6 deployments so that the amount of broken deployments both is reduced and made statistically insignificant. If we still have major problems with IPv6 working on the other end of a standards and deployment cycle, especially since it would likely take us post IPv4 exhaustion, I'd say we have a larger problem.

Section 8 - Another alternative would be DNS shared fate - only responding with AAAA queries to IPv6 source addresses, either at the auth or recursive server as a coarse way to verify that IPv6 is functioning properly before sending a client to use it. I am aware of two main concerns with this - that it doesn't actually prove functional IPv6, because it doesn't necessarily verify MTU and routing all work correctly, and that it would shut out any hosts that cannot do DNS via IPv6, either because they don't support it (like Windows XP), or because they have not been configured with an IPv6 DNS server. There are likely others, but that's all I can think of right now.

Lastly, I think you probably need either an informative reference or a companion draft explaining what "broken IPv6" whitelisting is attempting to protect against. I agree with what you say in section 6 that it's not in scope of this document, but since the real solution is to fix what's broken, a reference can't hurt, especially in 8.3.1.

Thanks,
Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Livingood, Jason
> Sent: Friday, October 01, 2010 2:28 PM
> To: [email-masked]
> Subject: [v6ops] Soliciting feedback on draft-livingood-dns-
> whitelisting-implications
>
> Hi -
>
> I am soliciting feeback on this new draft, available at
> http://tools.ietf.org/html/draft-livingood-dns-whitelisting-
> implications. In particular, I am looking for more text to add in the
> justifications / rationale for this practice in an attempt to
> objectively examine the issue from many sides.  This is only a first
> draft of course.
>
> Regards
> Jason Livingood

________________________________

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Erik Kline <[email-masked]>
Date: Fri, 22 Oct 2010 17:39:09 -0700

>
> Regarding section 5 - I'm not sure I agree with the assertion that
> whitelisting would need to be built into all auth server software for
> universal implementation. The proposal I saw for making this a little less
> manual (I would cite a draft, but I'm not aware of one - Erik Kline from
> Google presented the idea at a conference) used in-addr.arpa TXT records,
> combined with some external scripting to collect and verify IP addresses of
> resolvers to feed into whitelists. I would think that this could be
> implemented without special software in the auth server itself, but I'm by
> no means an expert on existing implementations of DNS auth/whitelist as to
> where the magic actually happens. I just bring it up as a point to verify.
> I think that there is also a subset that is sort of both of your two
> categories - ad-hoc deployment, but universal (if still mostly ad-hoc)
> coordination. Think in terms of a well-known email distro (
> [email-masked]) or website (like peeringdb) that anyone who is
> whitelisting their auth servers can join, and when new people want to
> qualify their networks for whitelisting, they send mail to that address.
> This at least removes the barrier associated with having to find and reach
> all of the folks who are doing the whitelisting.
>

The thing you describe is here:
http://ipv6whitelist.googlecode.com/hg/spec.txt

> Section 8 - Another alternative would be DNS shared fate - only responding
> with AAAA queries to IPv6 source addresses, either at the auth or recursive
> server as a coarse way to verify that IPv6 is functioning properly before
> sending a client to use it. I am aware of two main concerns with this - that
> it doesn't actually prove functional IPv6, because it doesn't necessarily
> verify MTU and routing all work correctly, and that it would shut out any
> hosts that cannot do DNS via IPv6, either because they don't support it
> (like Windows XP), or because they have not been configured with an IPv6 DNS
> server. There are likely others, but that's all I can think of right now.

Actually, [a variant of] this is another idea on which I've recently begun
some implementation work, to see just how feasible it might be.  =)