Subject: Re: TSVDIR review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 6 May 2011 21:04:19 +0000

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" <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]> 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

-----

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 May 2011 17:00:18 -0700

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" <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi, all,
>
>     [email-masked] <mailto:[email-masked]> if you reply to or
>     forward this review.
>
> [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).
>
> /"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."/
>
> [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…
>
> [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."/
>