ietf
[Top] [All Lists]

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

2011-05-29 09:48:37
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" 
<bernard_aboba(_at_)hotmail(_dot_)com<mailto:bernard_aboba(_at_)hotmail(_dot_)com>>
 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 
<iesg-secretary(_at_)ietf(_dot_)org<mailto:iesg-secretary(_at_)ietf(_dot_)org>>
To: IETF-Announce 
<ietf-announce(_at_)ietf(_dot_)org<mailto:ietf-announce(_at_)ietf(_dot_)org>>
Reply-to: 
iesg-secretary(_at_)ietf(_dot_)org<mailto:iesg-secretary(_at_)ietf(_dot_)org>
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
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org> mailing lists by 
2011-04-29. Exceptionally, comments may be
sent to iesg(_at_)ietf(_dot_)org<mailto:iesg(_at_)ietf(_dot_)org> 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
IETF-Announce(_at_)ietf(_dot_)org<mailto:IETF-Announce(_at_)ietf(_dot_)org>
https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________Ietf mailing list 
Ietf(_at_)ietf(_dot_)org<mailto:Ietf(_at_)ietf(_dot_)org> 
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>