Subject: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

From: Dave CROCKER <[email-masked]>
Date: Fri, 29 Apr 2011 16:32:19 -0700

Review:

Title:  IPv6 AAAA DNS Whitelisting Implications
I-D:    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

By:     D. Crocker <[email-masked]>
Date:   29 April 2011

Summary:

This draft is a discussion of a technique for resolving a dual-stack problem 
between IPv4 and IPv6, through the use of special DNS records.

The document appears to continue a recent use of the term 'whitelisting' that 
strongly conflicts with long-standing use of the term by the anti-abuse community.

The document needs to do a more careful job of introducing the problem it is 
solving and the explaining the way the 'whitelisting' mechanism works.

I also very strongly encourage finding a different term.

d/

> Abstract
>
>    The objective of this document is to describe what the whitelisting
>    of DNS AAAA resource records is, hereafter referred to as DNS

RRs are whitelisted?  Isn't it the addresses and not the records that are 
whitelisted?

Does this mean putting whitelisting records into the DNS or does it mean 
something else?

Comcast's own considerable expertise notwithstanding, has this doc been vetted 
with a range of organizations that actually DO whitelisting?  Has it been 
circulated through MAAWG and APWG?  Any comments from Spamhaus?  The 
Acknowledgements list does not seem to indicate a range of whitelist ops folks 
whose names I know.  (But then, I only know a few...)

>    whitelisting, as well as the implications of this emerging practice
>    and what alternatives may exist.  The audience for this document is
>    the Internet community generally, including the IETF and IPv6
>    implementers.

I suspect that product marketers won't have much interest in this.  I suspect 
that the target for this is anti-abuse technical and operations staff.

> Status of this Memo
>
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    This Internet-Draft will expire on August 26, 2011.
>
> Copyright Notice
>
>    Copyright (c) 2011 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (http://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>
>
>
> Livingood                Expires August 26, 2011                [Page 1]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    described in the Simplified BSD License.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Livingood                Expires August 26, 2011                [Page 2]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
> Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
>    2.  How DNS Whitelisting Works . . . . . . . . . . . . . . . . . .  6
>      2.1.  Description of the Operation of DNS Whitelisting . . . . .  7
>    3.  What Problems Are Implementers Trying To Solve?  . . . . . . .  8
>    4.  Concerns Regarding DNS Whitelisting  . . . . . . . . . . . . .  9
>    5.  Similarities to Other DNS Operations . . . . . . . . . . . . . 12
>      5.1.  Similarities to Split DNS  . . . . . . . . . . . . . . . . 12
>      5.2.  Similarities to DNS Load Balancing . . . . . . . . . . . . 12
>    6.  Likely Deployment Scenarios  . . . . . . . . . . . . . . . . . 13
>      6.1.  Deploying DNS Whitelisting On An Ad Hoc Basis  . . . . . . 13
>      6.2.  Deploying DNS Whitelisting Universally . . . . . . . . . . 14
>    7.  Implications of DNS Whitelisting . . . . . . . . . . . . . . . 15
>      7.1.  Architectural Implications . . . . . . . . . . . . . . . . 15
>      7.2.  Public IPv6 Address Reachability Implications  . . . . . . 16
>      7.3.  Operational Implications . . . . . . . . . . . . . . . . . 17
>        7.3.1.  De-Whitelisting May Occur  . . . . . . . . . . . . . . 17
>        7.3.2.  Authoritative DNS Server Operational Implications  . . 17
>        7.3.3.  DNS Recursive Resolver Server Operational
>                Implications . . . . . . . . . . . . . . . . . . . . . 18
>        7.3.4.  Monitoring Implications  . . . . . . . . . . . . . . . 19
>        7.3.5.  Implications of Operational Momentum . . . . . . . . . 19
>        7.3.6.  Troubleshooting Implications . . . . . . . . . . . . . 20
>        7.3.7.  Additional Implications If Deployed On An Ad Hoc
>                Basis  . . . . . . . . . . . . . . . . . . . . . . . . 20
>      7.4.  Homogeneity May Be Encouraged  . . . . . . . . . . . . . . 20
>      7.5.  Technology Policy Implications . . . . . . . . . . . . . . 21
>      7.6.  IPv6 Adoption Implications . . . . . . . . . . . . . . . . 22
>    8.  Solutions  . . . . . . . . . . . . . . . . . . . . . . . . . . 23
>      8.1.  Implement DNS Whitelisting Universally . . . . . . . . . . 23
>      8.2.  Implement DNS Whitelisting On An Ad Hoc Basis  . . . . . . 23
>      8.3.  Do Not Implement DNS Whitelisting  . . . . . . . . . . . . 23
>        8.3.1.  Solving Current End User IPv6 Impairments  . . . . . . 24
>        8.3.2.  Gain Experience Using IPv6 Transition Names  . . . . . 24
>    9.  Is DNS Whitelisting a Recommended Practice?  . . . . . . . . . 24
>    10. Security Considerations  . . . . . . . . . . . . . . . . . . . 25
>      10.1. DNSSEC Considerations  . . . . . . . . . . . . . . . . . . 25
>      10.2. Authoritative DNS Response Consistency Considerations  . . 26
>    11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 26
>    12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
>    13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27
>    14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
>    15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
>      15.1. Normative References . . . . . . . . . . . . . . . . . . . 28
>      15.2. Informative References . . . . . . . . . . . . . . . . . . 29
>    Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 31
>    Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 32
>
>
>
> Livingood                Expires August 26, 2011                [Page 3]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Livingood                Expires August 26, 2011                [Page 4]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
> 1.  Introduction
>
>    This document describes the emerging practice of whitelisting of DNS
>    AAAA resource records (RRs), which contain IPv6 addresses, hereafter
>    referred to as DNS whitelisting.  The document explores the
>    implications of this emerging practice are and what alternatives may
>    exist.
>
>    The practice of DNS whitelisting appears to have first been used by
>    major web content sites (sometimes described herein as "highly-

Really?  Not for email first?

>    trafficked domains" or "major domains").  These web site operators,
>    or domain operators, observed that when they added AAAA resource
>    records to their authoritative DNS servers in order to support IPv6

Oh.  You mean /IPv6/ whitelisting.

>    access to their content that a small fraction of end users had slow
>    or otherwise impaired access to a given web site with both AAAA and A
>    resource records.  The fraction of users with such impaired access
>    has been estimated to be roughly 0.078% of total Internet users
>    [IETF-77-DNSOP] [NW-Article-DNSOP] [Evaluating IPv6 Adoption] [IPv6
>    Brokenness].  Thus, in an example Internet Service Provider (ISP)
>    network of 10 million users, approximately 7,800 of those users may
>    experience such impaired access.

At a minimum, these sorts of statistics need to be normalized across IPv6 
users/traffic, given how small a percentage that is in total users and total 
traffice.  If that's what is meant it should be stated.  If it isn't, the 
statistic should be recalculated.

>    As a result of this impairment affecting end users of a given domain,
>    a few major domains have either implemented DNS whitelisting or are
>    considering doing so [NW-Article-DNS-WL] [IPv6 Whitelist Operations].

How or why does whitelisting affect slow performance for these folk?

>    When implemented, DNS whitelisting in practice means that a domain's
>    authoritative DNS will return a AAAA resource record to DNS recursive
>    resolvers [RFC1035] on the whitelist, while returning no AAAA
>    resource records to DNS resolvers which are not on the whitelist.  It

Oh.  The whitelisting is for resolving a conflict between AAAA and A record choices?

Normally, the term 'whitelisting' is used to refer to bypass anti-abuse 
mechanisms.  This appears to be for something else and it seems odd to call it 
whitelisting.

Note the more typical use of the term:

    <http://www.dnswl.org/>

    <http://en.wikipedia.org/wiki/DNSBL>

<http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.help.domino.admin.doc/DOC/H_USING_DNS_whitelists_OVER.html>

It appears that some v6 folks have chosen to co-opt a distinctive and very well 
established anti-abuse term for an entirely different purpose.

>    is important to note that these major domains are motivated by a
>    desire to maintain a high-quality user experience for all of their
>    users.  By engaging in DNS whitelisting, they are attempting to
>    shield users with impaired access from the symptoms of those
>    impairments.
>
>    Critics of the practice of DNS whitelisting have articulated several
>    concerns.  Among these are that:
>
>    o  DNS whitelisting is a very different behavior from the current
>       practice concerning the publishing of IPv4 address resource
>       records,
>
>    o  that it may create a two-tiered Internet,
>
>    o  that policies concerning whitelisting and de-whitelisting are
>       opaque,
>
>
>
>
>
> Livingood                Expires August 26, 2011                [Page 5]
> 
> Internet-Draft   IPv6 AAAA DNS Whitelisting Implications   February 2011
>
>
>    o  that DNS whitelisting reduces interest in the deployment of IPv6,

Well, it certainly suggests that there is a problem handling v4/v6 in dual stack 
environments cleanly.  And it certainly seems that dealing with the underlying 
problem would be better.

Beyond that, this appears to be a hack that is useful but not scalable.

>
>    o  that new operational and management burdens are created,

well, yeah...

>    o  and that the costs and negative implications of DNS whitelisting
>       outweigh the perceived benefits, compared to fixing underlying
>       impairments.
>
>    This document explores the reasons and motivations for DNS
>    whitelisting.  It also explores the outlined concerns regarding this
>    practice.  Readers will hopefully better understand what DNS
>    whitelisting is, why some parties are implementing it, and what
>    criticisms of the practice exist.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net