Skip to main content

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

Request Review of draft-ietf-homenet-hncp
Requested revision 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
I-D 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 H. Clausen (diff)
Assignment Reviewer Yoav Nir
State Completed
Request Telechat review on draft-ietf-homenet-hncp by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 10)
Result Ready
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

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

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.