[secdir] SecDir Review of draft-ietf-homenet-hncp

Yoav Nir <ynir.ietf@gmail.com> Sun, 11 October 2015 10:13 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C90831A7008; Sun, 11 Oct 2015 03:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Http8-JWB8_9; Sun, 11 Oct 2015 03:13:32 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3ADF1A7004; Sun, 11 Oct 2015 03:13:31 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so118964299wic.0; Sun, 11 Oct 2015 03:13:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=qZ8vzbOoPGod1lGplF3bMElf6nJQuX45qdl5UEXlVI8=; b=qpdcLak6pEVgC7UQP/hebCua4PfeTC3vH9KOUgNEPd7TnrKeS077iaCWcj34AF70uC yA197DUM4LVVYX9kzQ0He8e0gV6JD7OHLphQ9rY/RItPxox5/10NBnIQPfaMuqCi1FTR nFQ83vLotzVclnVZ1cZm3aWpMCenG3YQi5L4JJe+QBoIq/K04DMChzl5AQni0CbLHqwE xh13oro7M5U6zO0rvGpqDjv6ww61qXeVe3sggwp89tZATpVa/Alk43jYDdNLy6EVIzpq 563ipkohR5EIvEWqpUohNLIk2zDi3xQTfKMtmP+EWo0Fl+hzNpBazOzr8Ay0zFToX9Y4 ytlA==
X-Received: by with SMTP id mb8mr12235680wjb.108.1444558410596; Sun, 11 Oct 2015 03:13:30 -0700 (PDT)
Received: from [] ([]) by smtp.gmail.com with ESMTPSA id fv5sm6279473wic.7.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Oct 2015 03:13:29 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <90E412D8-0B02-4863-8EB9-D7DC2CD62E44@gmail.com>
Date: Sun, 11 Oct 2015 13:13:26 +0300
To: draft-ietf-homenet-hncp.all@tools.ietf.org, The IESG <iesg@ietf.org>, secdir <secdir@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/sjm4YqR0a3xMePW9QjhgzkBGyC0>
Subject: [secdir] SecDir Review of draft-ietf-homenet-hncp
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Oct 2015 10:13:33 -0000


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.