[secdir] SecDir Review of draft-ietf-roll-rpl-industrial-applicability

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 20 December 2013 13:14 UTC

Return-Path: <alexey.melnikov@isode.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 496871AE272 for <secdir@ietfa.amsl.com>; Fri, 20 Dec 2013 05:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 PYBXEOHAA1ms for <secdir@ietfa.amsl.com>; Fri, 20 Dec 2013 05:14:45 -0800 (PST)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71A1AC403 for <secdir@ietf.org>; Fri, 20 Dec 2013 05:14:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1387545281; d=isode.com; s=selector; i=@isode.com; bh=BTitHSG7wYXMX9ovaEOLSLbj/9xQqeHPkeot/0jgrOE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=bETtZIb07XkGEOu6sVtWj6940ITmF3HbbpglVpjFZS0alQrTFXO/Fs0/v4qE32fPXQHwAW GzVMOTTVSVog7kkaV+CTfeNIFKhNaKNzvEEF+9SiQESGpszRu0qRIgJdcqLP0Sap3xkBav GCf+3NSyRyvp1g61m/bsVT2o1wlohE0=;
Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id <UrRCwABvgRnJ@statler.isode.com>; Fri, 20 Dec 2013 13:14:41 +0000
Message-ID: <52B442CA.8090909@isode.com>
Date: Fri, 20 Dec 2013 13:14:50 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
To: draft-ietf-roll-rpl-industrial-applicability.all@tools.ietf.org, Michael Richardson <mcr+ietf@sandelman.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: secdir@ietf.org
Subject: [secdir] SecDir Review of draft-ietf-roll-rpl-industrial-applicability
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: Fri, 20 Dec 2013 13:14:48 -0000

Hi,

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.

The document is well written and was quite educational for me. However 
the Security Considerations section is incomplete and not quite ready.

 >    This document does not specify operations that could introduce new
 >    threats.  Security considerations for RPL deployments are to be
 >    developed in accordance with recommendations laid out in, for
 >    example, [I-D.tsao-roll-security-framework].

This document got obsoleted by a WG document. I am not entirely sure 
whether this is intended to be draft-ietf-roll-security-threats or 
draft-ietf-roll-security-framework. Please update your draft to point to 
the latest document.

 >    Industrial automation networks are subject to stringent security
 >    requirements as they are considered a critical infrastructure
 >    component.  At the same time, since they are composed of large
 >    numbers of resource- constrained devices inter-connected with
 >    limited-throughput links, many available security mechanisms are
 >    not practical for use in such networks.  As a result, the choice of
 >    security mechanisms is highly dependent on the device and network
 >    capabilities characterizing a particular deployment.

While this sounds plausible, this is not very helpful for deployments. 
Are there any documents (maybe even research papers) that talk about 
different types of deployments and suitable security mechanisms for them?

 >    In contrast to other types of LLNs, in industrial automation
 >    networks centralized administrative control and access to
 >    a permanent secure infrastructure is available.
 >    As a result link-layer, transport-layer
 >    and/or application-layer security mechanisms are typically in place
 >    and may make use of RPL's secure mode unnecessary.

Pointing to RFC 6550 and describing how RPL security services described 
there can be replaced by link/transport/application-layer technologies 
would be helpful as well.

 > 6.1.  Security Considerations during initial deployment
 >
 > 6.2.  Security Considerations during incremental deployment

These sections need completing. Looking at 
draft-ietf-roll-applicability-template-03, I can see there a useful 
pointer to a document about getting initial keys and trust anchors.