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

From: Joe Touch <[email-masked]>
Date: Thu, 28 Apr 2011 13:38:19 -0700

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] 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.

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.

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.

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.

Sec 6.2 notes that deployment of whitelisting might require an Internet 
Draft; this should be replaced with "RFC" (presumably standards track or 
BCP).

-----