Hi, Jason,
Looks good. The issue about section ordering is up to you and the WG; I
just thought it might flow better.
I'm glad the input was useful.
Joe
On 5/6/2011 2:04 PM, Livingood, Jason wrote:
Hi Joe – Thank you for your thorough review and detailed response. Your
feedback will be incorporated into a –04 update with other changes
received in last call and from the IESG. (I'm still working through all
of the changes though.)
In any case, see my detailed responses inline below. I appreciate any
suggested changes to the proposed new text of course.
Regards
Jason
On 4/28/11 4:38 PM, "Joe Touch" <touch@xxxxxxx <mailto:touch@xxxxxxx>>
wrote:
Hi, all,
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-dir@xxxxxxxx <mailto:tsv-dir@xxxxxxxx> if you reply to or
forward this review.
The document describes the issues associated with the practice of
whitelisting in DNS servers, in an attempt to limit which recursive
resolvers receive responses to requests for AAAA (IPv6) records.
The practice of whitelisting can have significant impact on transport
protocols in the reachability of IPv6 endpoints. There are no transport
issues of a more specific nature discussed or determined as part of
this
review.
I do have some other concerns which are noted below, and which are
offered for consideration.
I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.
Joe
---------------------------------------------------------------------
Overall, this document is quite long and has many gratuitous
digressions
which could easily be omitted. It is unnecessarily verbose and lengthy
for its topic. E.g., the architectural implications that stretch this
issue into network heterogeneity are a bit of a stretch, and the
discussion (and citation) for Newton's notion of momentum is
unnecessary.
[JL] Thanks for the general feedback. As for the inclusion of CPE
homogeneity being encouraged (Section 7.4) as a result of whitelisting,
I am attempting to highlight that on the one hand there is a natural
trend towards greater heterogeneity while whitelisting policies may
encourage an opposite trend back towards homogeneity. In part this is
due to the fact that so may different types of CPE exist and these vary
widely with respect to IPv6-related impairments and capabilities. But it
seems that whitelisting approvals for domains may occur more readily for
those networks with a greater level of control (or complete control)
over endpoints, where less variation in those devices exists as a result
of that control, since the network can then push out device fixes for
IPv6 impairments and so on. This is a tension that I know I as an ISP
feel – on the one hand it seems desirable to have greater control over
and less variation of CPE in order to win approval to be added to
whitelists, while on the other hand there is a great deal of pressure in
the opposite direction to enable any IP-capable CPE to connect (often
this is encompassed in various countries' "open Internet" or "network
neutrality" guidelines).
Blacklisting is noted in other environments in Sec 6, and noted as an
alternative for the DNS AAAA issue in a cursory fashion in Sec
7.3.7. It
should certainly be introduced and defined earlier, and included in the
alternatives discussed in Sec 8. Blacklisting provides a useful
alternative because it requires explicit action to inhibit, rather than
requiring explicit action to avoid, and the tradeoff between
blacklisting and whitelisting should be discussed in more detail.
[JL] This is an excellent suggestion. I have acted on it in the
following ways:
1 – Added this to Section 2, How DNS Whitelisting Works:
/"At a high level, using a whitelist means no traffic is permitted to
the destination host unless the originating host's IP address is
contained in the whitelist. In contrast, using a blacklist means that
all traffic is permitted to the destination host unless the originating
host's IP address is contained in the blacklist."/
/
/
2 – I have added a new section in the solutions/alternatives, 8.4
Implement DNS Blacklisting, with the following text:
/"Some domains may wish to be more permissive than if they adopted DNS
whitelisting [Section 8.2], but not still have some level of control
over returning AAAA record responses [Section 8.3]. An alternative in
this case may be to employ DNS blacklisting, which would enable all DNS
recursive resolvers to receive AAAA record responses except for the
relatively small number that are listed in the blacklist. This could
enable an implementer to only prevent such responses where there has
been a relatively high level of IPv6-related impairments, until such
time as these impairments can be fixed or otherwise meaningfully reduced
to an acceptable level./
/
/
/This approach is likely to be significantly less labor intensive for an
authoritative DNS server operator, as they would presumably focus on a
smaller number of DNS recursive resolvers than if they implemented
whitelisting. Thus, these authoritative DNS server operators would only
need to communicate with a few DNS recursive resolver operators rather
than potentially all such operators. This should result in lower labor,
systems, and process requirements, which should be beneficial to all
parties. This is not to say that there will be no time required to work
with those operators affected by a blacklist, simply that there are
likely to be fewer such interactions and that each such interaction may
be shorter in duration./
/
/
/Of course one downside of this approach may be that the perception of
being blocked (blacklisted) is sometimes worse that not being permitted
to have access (whitelisted). However, the email industry has a long
experience with blacklists and, very generally speaking, blacklists tend
to be effective and well received when it is easy to discover if a
server is on a blacklist, if there is a transparent and easily
understood process for requesting removal from a blacklist, and if the
decision-making criteria for placing a server on a blacklist is
transparently disclosed and perceived as fair."/
The list of alternate solutions (Sec 8) might be placed much earlier
(Sec 2, after an intro), as it provides the background for the rest of
the discussion.
[JL] This is a fair suggestion worthy of suggestion. However, I'm going
to defer consideration of it until after I post the –04 if for no other
reason than feedback I have already given that changes from someone with
appear in some numbered section will all be thrown off by such a change.
So I'll come back to this one after pushing out the –04 update…
The document might also benefit from a brief discussion of how users are
rarely in control of their DNS, given hijacking that currently
occurs in
ISPs. I.e., even when they could use a whitelisted recursive resolver,
that might be impossible due to current ISP practices.
[JL] Good suggestion. I have added the following text as a new section,
7.8, Implications for Users of Third-Party DNS Recursive Resolvers, as
follows:
/" In most cases it is assumed that end users will make use of DNS
recursive resolvers which are operated by their network provider,
whether that is an ISP, campus network, enterprise network, or some
other type of access network. However there are also cases where an end
user has changed their DNS server IP addresses in their device's
operating system to those of another party which operates DNS recursive
resolvers independently of end user access networks. In these cases, an
authoritative DNS server may receive a query from a DNS recursive
resolver in one network, though the end user sending the original query
to the DNS recursive resolver is in an entirely different network. It
may therefore be more challenging for a DNS whitelist implementer to
determine the level of IPv6-related impairment when such third-party DNS
recursive resolvers are used, given the wide variety of end user access
networks which may be used and that this mix may change in unpredictable
ways over time./
/
/
/There may also be cases where end users are using a network where the
assigned DNS recursive resolver has not been whitelisted by a particular
authoritative DNS server, but where the end user knows that a particular
third-party DNS recursive resolver has been whitelisted. While in most
cases the end user will be able to switch to use that third-party's
servers, some access networks may prevent switching to any DNS recursive
resolvers other than those authorized by or residing within a given
access network. While the blocking of third-party DNS recursive
resolvers may be observed in many types of networks such as ISPs, campus
networks, and enterprise networks, this may most often be observed in
the specialized networks setup in hotels, conference centers, coffee
shops, and similar access networks. In these cases, end users may be
frustrated at their inability to access content over IPv6 as a result of
their access network preventing them from using a whitelisted
third-party DNS recursive resolver. This may also result in complaints
to both the operator of the authoritative DNS server which has
implemented whitelisting as well as to the access network operator."/
Sec 6.2 notes that deployment of whitelisting might require an Internet
Draft; this should be replaced with "RFC" (presumably standards
track or
BCP).
[JL] Change made!
Thanks again,
Jason
-----
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf