Last Call Review of draft-ietf-dnsop-as112-dname-04
review-ietf-dnsop-as112-dname-04-secdir-lc-wierenga-2014-08-15-00
Request | Review of | draft-ietf-dnsop-as112-dname |
---|---|---|
Requested revision | No specific revision (document currently at 06) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2014-08-19 | |
Requested | 2014-07-17 | |
Authors | Joe Abley , Brian Dickson , Warren "Ace" Kumari , George G. Michaelson | |
I-D last updated | 2014-08-15 | |
Completed reviews |
Genart Last Call review of -04
by Roni Even
(diff)
Opsdir Telechat review of -04 by David L. Black (diff) Opsdir Telechat review of -04 by Scott O. Bradner (diff) Secdir Last Call review of -04 by Klaas Wierenga (diff) |
|
Assignment | Reviewer | Klaas Wierenga |
State | Completed | |
Request | Last Call review on draft-ietf-dnsop-as112-dname by Security Area Directorate Assigned | |
Reviewed revision | 04 (document currently at 06) | |
Result | Has issues | |
Completed | 2014-08-15 |
review-ietf-dnsop-as112-dname-04-secdir-lc-wierenga-2014-08-15-00
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is "ready with issues." The document describes adding and dropping of zones for AS112, the zone that is meant rot act as a sinkhole for reverse lookups for addresses that are for private-use only. I think the document is clearly written and with my limited understanding of DNS it all seems to make sense from a technical point of view. What I am not so sure of however is the statement in the security considerations: "This document presents no known additional security concerns to the Internet. For security considerations relating to AS112 service in general, see RFC6304bis]." And in the introduction "The AS112 project does not accommodate the addition and removal of DNS zones elegantly. Since additional zones of definitively local significance are known to exist” It appears to me that moving from a static list of well known ranges as defined in 6304bis to a dynamic adding and dropping of IP-address ranges that are "of definitively local significance” is prone to error, potentially leading to blackholing valid address space, either on purpose or by accident. I may show my ignorance here, but I feel that a discussions as to why that risk doesn’t exist is warranted. Hope this helps, Klaas