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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-----
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]