Skip to main content

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