Re: [apps-review] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*

[Dave CROCKER <[e-mail]>]

(I see that you've posted -05.  This response is for completeness.)


On 5/29/2011 7:54 PM, Livingood, Jason wrote:
> [JL] Duly noted in my previous emails. I'm keeping the naming as an open issue
> in the –04 and will be seeking WG and WG co-chair guidance one way or the other.

One of the reasons for cross-area review is to look for cross-area problems.

Separate from the legal formalities, the purpose of 'trademark' is to try to 
avoid market confusion.  Market confusion was exactly the reason that I raised 
concern about the naming and I wasn't the only one who noticed the problem.  (My 
original, informal posting was directly result of that confusion...)

So I'm sorry to see that the naming conflict is felt to be irrelevant by those 
running the working group.  (I was also a little surprised to see that that core 
of folk constitute working group rough consensus, for removing open items.)

As for the actual term "whitelisting" I suppose we should admire the boldness of 
the view that access to v6 is a priviledge -- note that that's the denotational 
perspective of the word whitelisting...


>         operator of a website, such as www.example.com, the operator
>         essentially applies an access control list (ACL) on the authoritative
>         DNS servers for the domain example.com. The ACL is populated with
>
>     An ACL usually is a yes/no mechanism. Here, however, the mechanism is for
>     asserting a preference for IPv6 over IPv4.
>
>     That does not seem to match the definition of ACL that I'm used to, unless the
>     semantic is defined as denying IPv4 access to the listed clients.
>
>     The term ACL is particularly odd to use if the mechanism pertains to responses
>     rather than queries.
>
>
> [JL] I am using 'ACL' in the most general possible sense and am open to
> alternative descriptors if you wish to suggest one. But most people seem to know
> an ACL is a list that, if you are listed on it, grants you access to some
> resource. In this case if the resolver is on the list then it gets AAAA RRs.

On reflection, the term is growing on me for this use.

"AAAA ACL" or "V6 DNS ACL" or "V6 resolver ACL" now seem to me quite good 
labels.  They provide useful, direct and precise meaning, while avoiding the 
various referential and denotational problems of a loaded term like whitelist.



> [JL] I took a stab at a new diagram in –04 — so take a look and let me know if
> it is what you are suggesting (I've left the original one in for now).

Took a quick look at the added diagram in the new draft.  The thing about a 
protocol timeline diagram is that it uses verticality to provide ordering.  So a 
response is lower down than a request. I don't get that from your Figure 2.

(By the way, your first sub-scenario, with Resolver 1, shows only a v4 response, 
without indicating whether the resolver sent a v6 or v4 query.  For the review, 
I think this distinction between transport and data -- "how is the 
query/response transported" vs. "what RRs are returned" -- was a continuing 
point of confusion for me. )


>         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
>
>
>     "At least one" seems a rather tiny statistic. Perhaps the actual statistic is
>     significantly larger?
>
>
> [JL] It does not seem to be. Other than this being passed along by Google, I've
> not heard of any similar stories. Nevertheless, it seemed interesting enough to
> include.

As an anecdote, it is perhaps interesting.  As a basis for promoting the entire 
effort, not so much.  I couldn't tell which role it was serving, but it felt 
like the latter.


>         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
>
>
>     So even though the site allows v6 DNS queries to go out from a host, it can't
>     really support having the host use v6?
>
>
> [JL] A network isn't really in control of the end host's limitations w/r/t IPv6
> impairment. A good summary of the issue of impairment is @ http://www.fud.no/ipv6/

That sort of commentary, along with the citation, might be good to include, for 
clarification.


>         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
>
>
>     8 hundredths of one percent?

I think that that's 8 of every 10,000 Internet users?


>     That's considered a high percentage?
>
>
> [JL] It is. I joked at one of the v6ops WG meetings awhile ago that at that
> rate, it'd be cheaper and easier for me (an ISP) to just buy new computers for
> the affected "impaired" users than to have to navigate years of whitelisting
> with a variety of domains. In any case, one recent measurement estimates it at
> 0.05% now and another at 0.015%. Despite this, this practice is still generating
> some interest. I'm hoping World IPv6 Day goes well and is informative for the
> community as to this percentage on a widespread basis, across a wide variety of
> web sites.
>
>
>     Even if it is 8%, is that considered high?
>
>
> [JL] 8% of the Internet finding google.com or facebook.com inaccessible would be
> bad for everyone. That could generate several hundred thousand support calls per
> day to a big ISP.

On reflection, I'm surprised to hear that IPv6 usage is up as high as 8 out of 
every 10,000 users, nevermind a large multiple of that.  (Although it does carry 
a backhanded note of encouragement about v6 adoption, I'm a bit suspicious of 
the statistic.)


>         troubleshooting standpoint. In this scenario, a DNS recursive
>         resolver operator will have no way to systematically determine
>         whether DNS whitelisting is or is not implemented for a domain, since
>         the absence of AAAA resource records may simply be indicative that
>         the domain has not yet added IPv6 addressing for the domain, rather
>         than that they have done so but have restricted query access via DNS
>
>
>     The premise is that, in large scale use, servers /will/ have a way to
>     systematically determine whether it is implemented? What are the existing
>     examples of having such a capability for other Internet protocols and services?
>
>
> [JL] Perhaps I'm overplaying this point, but you know someone has email service
> if they have an MX record for example, or a website if the host answers on
> TCP/80. But as I re-read this it is probably overkill and so I've deleted it. I
> have however moved some of the text to a prior section, since determining
> whether or not domains are whitelisting is still a challenge at scale.

Note that a site can have email service without an MX and that TCP:80 is not 
merely an "indicator" of web service, but actually /is/ the web service.

My point is that this idea of signaling/registering support of a service, as 
separate from actually providing the service, is not part of typical Internet 
service requirements and the simplification this provides is significant.  We 
need to be careful that we do not inadvertently teach folks that "signaling 
support" is an expected feature.

(And with this response, given that you already deleted the text, it's my turn 
to overplay a point...)



>         nature, not to mention physics. For example, as Sir Issac Newton
>         noted, "Every object in a state of uniform motion tends to remain in
>         that state of motion unless an external force is applied to it" [Laws
>
>
>     Code does not have momenum. Neither do configurations or lists. This really
>     isn't about physics.
>
>
> [JL] But people and processes do have (operational) momentum…

Indeed, and the process of dealing with the naming issue for this does seem to 
show that...


>     It is entirely about group psychology, as you note, and the administrative
>     challenges in the logistics of large-scale operational changes (which probably
>     /does/ have something to with physics, but it seems a stretch to credit Newton.
>     How about Heisenberg?...)
>
>
> [JL] Hmmm… I don't think it is Heisenberg-related. But it's such an interesting
> citation I feel it's almost a personal challenge to figure out a way to keep it
> in there. ;-)

How certain of it's being a challenge are you?  Does your certainty change as 
you think about it?


  The way I think about it is that in 5 or 10 years none of the
> people working on the details of the IPv6 transition now will still be involved
> in the day-to-day operational work. But DNS Whitelisting could still be in place
> – and once something gets a momentum to it (people, processes, and
> organizations) it is really, really hard to change that.

Well, I seriously applaud that concern, especially since its validity is proven 
every day (including in the IETF...)

On the average, I tend to believe that the best way to instruct folks later is 
by imparting information about tradeoffs and, especially, cost vs. benefit.

In the current case, the near-term cost/benefit makes some sense.

In the long term, the scaling cost of maintenance and the architectural cost of 
losing spontaneous interoperability strike me as pretty f'ing expensive.


>         8.3. Do Not Implement DNS Whitelisting
>
>         As an alternative to adopting DNS whitelisting, the Internet
>         community generally can choose to take no action whatsoever,
>         perpetuating the current predominant authoritative DNS operational
>         model on the Internet, and leave it up to end users with IPv6-related
>         impairments to discover and fix those impairments.
>
>
>     That is, place the burden of fixing a problem on those creating it?
>
>
> [JL] In a way. It gets back to the question you asked about what level of
> impairment justifies this practice. One obvious option is to let end users sort
> it out (presumably by consulting with their ISPs / network operators). This may
> be simpler and it's the way solutions to non-IPv6 problems tend to work today.

On the average, demanding that an end-user make an explicit decision about an 
operational tuning issue does not work very well.


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net