Telechat Review of draft-ietf-homenet-hncp-09

Request Review of draft-ietf-homenet-hncp
Requested rev. no specific revision (document currently at 10)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2015-10-20
Requested 2015-10-08
Authors Markus Stenberg, Steven Barth, Pierre Pfister
Draft last updated 2015-10-15
Completed reviews Genart Last Call review of -09 by Francis Dupont (diff)
Secdir Telechat review of -09 by Yoav Nir (diff)
Opsdir Telechat review of -09 by Sheng Jiang (diff)
Rtgdir Early review of -04 by Thomas Clausen (diff)
Assignment Reviewer Yoav Nir
State Completed
Review review-ietf-homenet-hncp-09-secdir-telechat-nir-2015-10-15
Reviewed rev. 09 (document currently at 10)
Review result Ready
Review completed: 2015-10-15



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.

Summary: This document is ready

The document is a profile of the DNCP document that is being progressed at the same time. Together they form an implementable protocol. The protocol runs among internal routers within a home network. The document requires such routers not to forward HNCP messages to leaves, guests, or to external interfaces. 

The Security Considerations section addresses the major threat of mis-classification of interfaces. If an external interface is classified as internal, hosts outside the home (or at least the home network) would be able to reconfigure the home network by sending HNCP messages. One way to mitigate this is by static configuration or the external interface(s) as well as guest and leaf interfaces. Another is to use the secure mode on DNCP. The section describes those options adequately. For some reason the wording suggests that both of these options are exceptions to the rule: we’d like as little configuration requirements as possible, and on the other hand the secure mode of DNCP requires X.509 certificates. I guess in the normal case, such as a special connection for the external interface on the CPE (say, coaxial cable or fiber vs Ethernet) it’s easy for the CPE to identify the external interface, and no further configuration *by the user* is needed.

One threat that is not addressed in the draft is the possibility of a rogue router within the network (maybe it’s compromised by malware). It’s fine not to have a mitigation for this, but I think it should be called out.