[secdir] secdir review of draft-ietf-opsawg-coman-use-cases-03

⌘ Matt Miller <mamille2@cisco.com> Tue, 13 January 2015 20:49 UTC

Return-Path: <mamille2@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181541AD061; Tue, 13 Jan 2015 12:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level:
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gxpWSkVnOja; Tue, 13 Jan 2015 12:49:21 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179501AD05B; Tue, 13 Jan 2015 12:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3011; q=dns/txt; s=iport; t=1421182161; x=1422391761; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=y69IZIoAK74S+fduFXd47I+CSST1u07uaw0C28sxqGA=; b=aV2Q9GRCuQUdOP7fyco093N5CVjH1T/7tcAFj9wllfqpV2s2po9qEJ0D YMYWGMi0aVER/R2O1CUxKTrZ5s1kcgigiZBAFCxtOWpVcM5gSdZiMl3Bn PUXz4tsKlFn/Vsvjcrj0CM/yRPryZRlg6YwCZbZXLGek+xop6Ak3eaKrU Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjsGAKeDtVStJA2B/2dsb2JhbABbgwZSWASDAcMPhw5DAQEBAQF9hDYPAUU2AgUWCwILAwIBAgE1FgEMBgIBAYgoDbt3k3cBAQEBAQEEAQEBAQEBGASBIZFHgUEFiWaIIYIGg0KGGotiIoQOT4FFfgEBAQ
X-IronPort-AV: E=Sophos;i="5.07,751,1413244800"; d="scan'208";a="112978024"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP; 13 Jan 2015 20:49:20 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t0DKnKGs019249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 20:49:20 GMT
Received: from [10.129.24.63] (10.129.24.63) by xhc-aln-x09.cisco.com (173.36.12.83) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 13 Jan 2015 14:49:20 -0600
Message-ID: <54B584CF.2030909@cisco.com>
Date: Tue, 13 Jan 2015 13:49:19 -0700
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= <mamille2@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: The IESG <iesg@ietf.org>, IETF Security Directorate <secdir@ietf.org>, <draft-ietf-opsawg-coman-use-cases.all@tools.ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.129.24.63]
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Y5dGaS956eJbxQeyjPIJ9ODK9ZE>
Subject: [secdir] secdir review of draft-ietf-opsawg-coman-use-cases-03
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: <http://www.ietf.org/mail-archive/web/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: Tue, 13 Jan 2015 20:49:23 -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 Informational document describes use cases for managing a network
involving constrained devices (e.g., sensors, smart controllers), along
with a discussion on network access and the operational lifecycle of
such devices.  This also covers some situational guidelines and
requirements specific to the discussed use cases.

This document is ready with nits.  My one issue I have might not be
appropriate for this use case document, and my other nits are simply
editorial.


MINOR ISSUE:

There is little mention about data protection within this document, but
is discussed some in [COM-REQ].  However, neither this document nor
[COM-REQ] include any discussion about protecting data as it traverses
networks (e.g., using TLS or DTLS), as far as I can tell.  I assume this
will be covered in greater detail in any Standards Track documents
derived from these documents, but might be worthwhile to at least
mention in the use cases where in-transit data protection needs special
considerations, if not more generally in [COM-REQ].


NITS (not security related):

* RFC7228 is listed as informational, but it probably ought to be
normative.  It seems to me that it's necessary to understand the terms
from RFC7228 in order to understand this document.

* [COM-REQ] is listed as an informational reference, but ought to be
normative.  It seems to me that it's necessary to understand [COM-REQ]
in order to understand this document, at least from a security perspective.

* Throughout the document, the locution "ad-hoc" should be "ad hoc".

* Throughout the document, the phrase "In cases" is almost always (two
out of three) followed by a comma, which seems superfluous.

* In section 1. second paragraph, "type" should be "types" in the phrase
"... the management of a network with constrained devices offers
different type of challenges compared to ...".

* In section 2. last paragraph, "since tend" should be "since they tend"
in the phrase "... are not discussed here since tend to be quite static
and do not typically impose ..."

* In section 4.1. second paragraph, "looses" should be "loses" in the
phrase "... new constrained devices in case the system looses too much
of its structure."

* In section 4.1. second paragraph, "loosing" should be "losing" in the
phrase "... deal with events such as loosing neighbors or being moved to
other locations."


-- 
- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

[COM-REQ] "Management of Networks with Constrained Devices: Problem
Statement and Requirements"
<https://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs>