Last Call Review of draft-ietf-homenet-arch-10
review-ietf-homenet-arch-10-secdir-lc-weiler-2013-09-12-00

Request Review of draft-ietf-homenet-arch
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-09-10
Requested 2013-08-08
Other Reviews Genart Last Call review of -10 by Elwyn Davies (diff)
Review State Completed
Reviewer Samuel Weiler
Review review-ietf-homenet-arch-10-secdir-lc-weiler-2013-09-12
Posted at http://www.ietf.org/mail-archive/web/secdir/current/msg04214.html
Reviewed rev. 10 (document currently at 17)
Review result Has Nits
Draft last updated 2013-09-12
Review completed: 2013-09-12

Review
review-ietf-homenet-arch-10-secdir-lc-weiler-2013-09-12

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.




Even though this is an architecture document, I think it deserves some 


AD attention.







First: it seems odd to set an expectation for (near) 


zero-configuration:




   It is not practical to expect home users to configure their networks.
   Thus the assumption of this document is that the homenet is as far  as
   possible self-organising and self-configuring, i.e. it should
   function without pro-active management by the residential user.



and then decline to give any guidance about, arguably, the most 


important security choice in the document:




   This document takes no position on [whether 'default allow' or
   'default deny'] mode is the default, but assumes
   the choice for the homenet to use either mode would be available.




I found the "Name spaces" section (3.7.3) a bit confusing, in part 


because it doesn't specifically name DNS at the start of the section, 


even though the details below clearly point to DNS (IDNA, possible 


conflicts with dotless TLDs).  Perhaps the second paragraph of 3.7.4, 


explaining that there are some non-DNS alternatives under 


consideration, should be moved up?  Furthermore, there are some 


particular assertions in both 3.7.3 and 3.7.4 that need to be 


reconsidered:




-- "When DNS is used as the homenet name service, it includes both a
   resolving service and an authoritative service."  Does it
   necessarily?

-- "The name space(s) should be served authoritatively by the
   homenet..."   Why is that necessary?  (Indeed, there is text in
   3.7.4 that seems to conflict with this.)

-- There is a recommendation to support DNSSEC on the authoritative
   server side (in 3.7.4).  Shouldn't there be a similar
   recommendation on the resolver side?