Subject: Re: Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 29 May 2011 14:46:03 +0000

Hi Bernard – I've finally found the time to close out the last bits of feedback in this version of the draft. Your comments will be incorporated shortly into a –04 version of the document. Please see specific replies inline below.

Thanks!
Jason

On 4/18/11 2:08 PM, "Bernard Aboba" <[email-masked]<mailto:[email-masked]>> wrote:

Overall, I think this is a useful document.

My suggestions below mostly relate to potential organizational improvements, as well as as a bit more detail in some areas.

Section 2

This section talks about how white-listing works, but does not talk about potential mechanisms by which the whitelist is determined.  For example, in addition to techniques for manually maintaining the whitelist, there have been some suggestions that would involve automatic determinations (e.g. only answering with AAAA RRs if the query comes in over IPv6).   It might be useful to cover some of the proposals, since they might have different implications.

[JL] I added a bit of text in the ad hoc DNS whitelisting section noting that there are two approaches. I did not include the part about only responding with a AAAA RR if the query comes in via IPv6, as I've not heard much about this in practice and discussion from implementers seems to indicate that even if they recursive server sent the query over IPv6 they still may have end hosts that are broken.

Section 2.1

Is the term "IP address" here intended to include both IPv4 and IPv6 addresses?

[JL] Yes, and I updated the text to clarify that.

Section 3

   At least one highly-trafficked domain has noted that they have
   received requests to not send DNS responses with AAAA resource
   records to particular resolvers.  In this case, the operators of
   those recursive resolvers have expressed a concern that their IPv6
   network infrastructure is not yet ready to handle the large traffic
   volume which may be associated with the hosts in their network
   connecting to the websites of these domains.  This concern is clearly
   a temporary consideration relating to the deployment of IPv6 network
   infrastructure on the part of networks with end user hosts, rather
   than a long-term concern.  These end user networks may also have
   other tools at their disposal in order to address this concern,
   including applying rules to network equipment such as routers and
   firewalls (this will necessarily vary by the type of network, as well
   as the technologies used and the design of a given network), as well
   as configuration of their recursive resolvers (though modifying or
   suppressing AAAA resource records in a DNSSEC-signed domain on a
   Security-Aware Resolver will be problematic Section 10.1).

[BA]  This paragraph seems to be distinguishing "blacklisting" from "whitelisting" as well as describing some of the implications of attempting to suppress AAAA RRs in the recursive resolver.  It might be worthwhile to introduce the distinction between "blacklisting" and "whitelisting" earlier on.
Such a section might also include the following paragraph from Section 7.3.7:

[JL] Good idea – I added a brief section contrasting whitelisting and blacklisting, including some of the text you suggest.

   It is unclear when and if it would be appropriate to change from
   whitelisting to blacklisting, and whether or how this could feasibly
   be coordinated across the Internet, which may be proposed or
   implemented on an ad hoc basis when a majority of networks (or
   allocated IPv6 address blocks) have been whitelisted.  Finally, some
   parties implementing DNS whitelisting consider this to be a temporary
   measure.  As such, it is not clear how these parties will judge the
   network conditions to have changed sufficiently to justify disabling
   DNS whitelisting and/or what the process and timing will be in order
   to discontinue this practice.

Section 4

   While in Section 1 the level of IPv6-related impairment has been
   estimated to be as high as 0.078% of Internet users, which is a
   primary motivation cited for the practice of DNS whitelisting, it is
   not clear if the level of IPv4-related impairment is more or less
   that this percentage (which in any case is likely to have declined
   since its original citation).  Indeed, as at least one document
   reviewer has pointed out, it may simply be that websites are only
   measuring IPv6 impairments and not IPv4 impairments, whether because
   IPv6 is new or whether those websites are simply unable to or are
   otherwise not in a position to be able to measure IPv4 impairment
   (since this could result in no Internet access whatsoever).  As a
   result, it is worth considering that IPv4-related impairment could
   exceed that of IPv6-related impairment and that such IPv4-related
   impairment may have simply been accepted as "background noise" on the
   Internet for a variety of reasons.  Of course, this comparison of the
   level of worldwide IPv6 impairments to IPv4 impairments is
   speculation, as the author is not aware of any good measurement of
   IPv4-related impairments which are comparable in nature to the IPv6-
   related impairment measurements which have recently been conducted
   around the world.

[BA] It seems to me that discussion of measurement issues should probably come earlier in the document, possibly in its own section.
My suggestion is to move this paragraph as well other paragraphs referring to measurement into its own section (Section 1.1?).
The following paragraph from Section 3.2 might be a candidate:

[JL] Good suggestion - I have done so. I moved the impairment percentage citation to section 3 and have greatly re-worked section 3 to address this (and add a new motivation I've heard from one implementer).

   Finally, some domains, have run IPv6 experiments whereby they added
   AAAA resource records and observed and measured errors [Heise Online
   Experiment], which should be important reading for any domain
   contemplating either the use of DNS whitelisting or simply adding
   IPv6 addressing to their site.

Section 6

This section talks about Adhoc versus universal deployment scenarios.  It strikes me that the underlying distinction is not so much the universality of whitelisting deployment as much as whether the whitelists are shared or independent. The document seems to argue that independence is the most likely outcome:

   It is probably unlikely that a single clearinghouse for
   managing whitelisting is possible; it will more likely be unique to
   the source content owners and/or domains which implement DNS
   whitelists.

[BA] While a single clearinghouse might be unlikely, I'm not sure that this necessarily argues against the likelihood of multiple clearinghouses.  It might be helpful to provide a little more detail on the motivation behind the views on the likelihood of clearinghouses emerging (e.g. is this based on discussions with content providers?).  For example, if the concept of IPv6 whitelisting becomes more widespread among smaller content providers, it would seem that the need for clearinghouses might emerge.

[JL] Added a note on this.

Section 7.3.3

It seems to me that there might be some operational implications that might arise from some potential whitelisting mechanisms such as differentiating DNS queries sent over IPv6 versus IPv4.

[JL] Good feedback – I'll incorporate that into the I-D.

Section 7.6

   At the same time, as noted in Section 3, some highly-trafficked
   domains may find the prospect of transitioning to IPv6 daunting
   without having some short-term ability to incrementally control the
   amount and source of IPv6 traffic to their domains.

[BA] The issue of traffic control is a distinct problem. This is partially discussed in Section 3 (from the point of view of the recursive resolver owner),
but here it is referring to the problem as experienced by the content owner.  Perhaps it would make sense to make the distinction between the
"impairment" and "traffic control" problems earlier? (maybe even in Section 1, referring to a subsequent discussion in Section 3).

Section 8.3.1

This section refers to fixes for the "impairment" problem, but as noted above, there may also be other potential motivations for whitelisting.

[JL] Indeed. Based on your suggestion for section 3, I hope to have addressed this.

Section 9

   World IPv6 Day, sponsored by the Internet Society [World IPv6 Day],
   is scheduled to occur on June 8, 2011.  This will be an opportunity
   for domains to add AAAA resource records to the DNS without using DNS
   whitelisting.  As a result, this is likely an excellent opportunity
   for domains to evaluate the utility or necessity of DNS whitelisting,
   even in the short-term.  A major German news website, Heise Online,
   also ran a similar IPv6 experiment whereby they added AAAA resource
   records and observed and measured any errors [Heise Online
   Experiment], which is important reading for any domain contemplating
   either the use of DNS whitelisting or simply adding IPv6 addressing
   to their site.

[BA] You might consider moving this paragraph into a separate "measurement" section (e.g. Section 1.1).

[JL] Thanks for all the feedback!

=============================================
From: The IESG <[email-masked]<mailto:[email-masked]>>
To: IETF-Announce <[email-masked]<mailto:[email-masked]>>
Reply-to: [email-masked]<mailto:[email-masked]>
Subject: Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> (IPv6 AAAA DNS Whitelisting Implications) to Informational RFC
X-RSN: 1/0/934/8529/9220

The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'IPv6 AAAA DNS Whitelisting Implications'
<draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt> as an
Informational RFC

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]<mailto:[email-masked]> mailing lists by 2011-04-29. Exceptionally, comments may be
sent to [email-masked]<mailto:[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://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-implications/

No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________Ietf mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 29 May 2011 14:59:58 +0000

Thank you for your review, and a –04 revision is coming soon. Other comments inline below.

Thanks!
Jason

On 4/26/11 5:51 AM, "Pekka Savola" <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, 15 Apr 2011, The IESG wrote:

This is an ops-dir review of
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.

The document is readable and could be published as-is.  I share some of the
concerns already expressed in the document, but I think the doc strikes a
reasonable balance between the concerns and practical points.

One bigger comment:
-------------------

Section 6 on deployment scenarios seems too black and white: either it is
done ad-hoc or (completely) universally.  The latter is unfeasible.

[JL] I received similar feedback from others and have tried to address this better in the upcoming –04 version.

The document should cover a middle ground which is already discussed in
[NW-Article-DNS-WL], i.e., one or more whitelisting information providers
would be used by multiple content networks.  This has many benefits compared
to completely ad-hoc model, and is feasible compared to universal model.

[JL] Added a note concerning this in the I-D.

The "universal deployment model" proposition has created ripples throughout
the document (one such place is S 7.3.7), and I think the document might
have been clearer if that was taken out completely -- or at least, issues
related to each deployment model would be more clearly separated.

[JL] Good question, which is such a meta-concern that I'm going to list it in the open items tracker at the end of the document for consideration after the –04 update (since so many other changes are taking place in that version).

8.3.1. Solving Current End User IPv6 Impairments
...
    One challenge with this option is the potential difficulty of
    motivating members of the Internet community to work collectively
    towards this goal, sharing the labor, time, and costs related to such
    an effort.  Of course, since just such a community effort is now
    underway for IPv6, it is possible that this would call for only a
    moderate amount of additional work.

... I would observe that ad-hoc whitelisting is already requiring a lot of
work from each of whitelisting providers.  Would this require more than
that?  If the alternative is to do nothing (no whitelisting, no user
impairment notification) that is clear the winner from the selfish POV. But
if the choice is between whitelisting and alerting, I don't see much
difference between the two.  Both could benefit from joint activities, but
both can also be operated in an ad-hoc fashion.

editorial:
----------

7.3.7. Additional Implications If Deployed On An Ad Hoc Basis

    Additional implications, should this be deployed on an ad hoc basis,
    could include scalability problems relating to operational processes,
    monitoring, and ACL updates.

... this could be read to imply that S 7.3.1-6 would be applicable to
universal deployment.  This is not what is meant.  Maybe clarify somewhat
like as follows:

    Previous subsections described implications that apply to both ad-hoc and
    universal deployment models.  Some additional implications are specific
    to ad-hoc deployment models, namely ...

[JL] Great suggestion! I have made this change.

S 7.5

    governmental, and/or cultural conflicts, given the new control point
    which has be established with DNS whitelisting.  For example, in one

s/be/been/

[JL] Corrected

    [IPv6 Brokenness]
               Anderson, T., "Measuring and Combating IPv6 Brokenness",
               Reseaux IP Europeens (RIPE) 61st Meeting, November 2011,
               <http://ripe61.ripe.net/presentations/162-ripe61.pdf>.

s/2011/2010/

[JL] Corrected

Thanks again,
Jason