Re: [6tsch] draft-ohba-6tsch-security-00

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 28 June 2013 15:00 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556E221F9BDC for <6tsch@ietfa.amsl.com>; Fri, 28 Jun 2013 08:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1XKpdccXdnT for <6tsch@ietfa.amsl.com>; Fri, 28 Jun 2013 08:00:49 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3C221F9BBA for <6tsch@ietf.org>; Fri, 28 Jun 2013 08:00:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15258; q=dns/txt; s=iport; t=1372431649; x=1373641249; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0AXyR9eqv0Y4zBdnC1A2GJMDMr6Axuhi2gXU1Qd7VOY=; b=mQSi/rnvpYFz3SruA/yvNgMl42PnvRE9jwq6hr5nzcHmAKJI319g+dq9 aEF1D5xvlj7sDQxYvzCh9QZ/JTGvJ6gfo02xTPe+72ZZF/FWgAT4F+i4B riJb6tw9W2+wpuPwHa3+GfwVLgZDSlJO5Q/hYdL7SxOM6G/xTBCgKBKDn w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUFAK6jzVGtJV2b/2dsb2JhbABYA4JFRDFJtk2IPIEIFnSCJAEBBAEBASpBCxACAQgOFB0HJwsUEQIEAQ0FCIgGDLtvjhMKBoEBIQwEBgERgnFjA4U/ky+QHIMRgWgCBxcGGg
X-IronPort-AV: E=Sophos; i="4.87,958,1363132800"; d="scan'208,217"; a="228641024"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jun 2013 15:00:40 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5SF0dE9017468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 15:00:40 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.80]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 10:00:39 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Jonathan Simon <jsimon@linear.com>, "<yoshihiro.ohba@toshiba.co.jp>" <yoshihiro.ohba@toshiba.co.jp>
Thread-Topic: [6tsch] draft-ohba-6tsch-security-00
Thread-Index: AQHOc3p+kI1T3ecSMECMDBzStid+V5lLNA/g
Date: Fri, 28 Jun 2013 15:00:38 +0000
Deferred-Delivery: Fri, 28 Jun 2013 15:00:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD841337035@xmb-rcd-x01.cisco.com>
References: <674F70E5F2BE564CB06B6901FD3DD78B12D258EB@tgxml338.toshiba.local> <8E172190-20C7-4BD4-96B8-E3F79684FECD@linear.com>
In-Reply-To: <8E172190-20C7-4BD4-96B8-E3F79684FECD@linear.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.160.31]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD841337035xmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] draft-ohba-6tsch-security-00
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jun 2013 15:00:54 -0000

Hello Jonathan:

On top of Yoshi's answers, please see inline


"6TSCH builds on a series of semi-proprietary wireless protocols..."
Is it really relevant that TSCH was built on concepts in WirelessHART?  TSCH is not proprietary, and saying it builds on proprietary protocols is a red flag.

[] Yes, the wording is probably ill chosen. WiHART and ISA100.11a have successfully demonstrated the feasibility and value of the TSCH technique.
The idea is that 6TSCH will build on that knowledge to provide an open standard suite of protocols closely following the same principles...



"Following Metcalf's law..."
Not only is it not clear what point is being made, Metcalf's law measures "utility" in connections.  For a networked sensor device, there are likely a finite number of consumers of its data, and the total number of nodes is an irrelevant utility metric. Additionally, in terms of mesh connectivity, in general there is little additional utility to having 1000 neighbors (which may be more than the node can store) over 100, and perhaps 100 over 10 provided there is sufficient connectivity for the network to function.
[] And here I respectfully disagree; 6TSCH brings 2 things: 1) better guarantees (deterministic) for a network of limited size under the control of a PCE and for that piece I'm entirely with you but also 2) better scalability for applications such as monitoring using distributed routing (RPL). For the latter, size definitely matters. Take rust monitoring, intrusion detection, etc, one may want to deploy a large number of devices with very low reporting rate. The number of connected devices and the fact that we can correlate inputs from multiple parties, all this augments the value of the network, though maybe not by the square since the idea came from any to any communication. This does not mean that the network is very dense and/or that nodes will need to neighbor with tons of one hop devices. But sometimes brute force has value. I'm curious what Kris had in mind with the idea of sensor dust...

Cheers,

Pascal


General

So the problem this draft is trying to solve is shared link-layer keys in the network.  It does this by proposing an 3-phase authentication scheme with unstated overhead to provide unique per-peer link-layer keys, among other things.

a) Each node would need to be preconfigured with every node's certificate material (bad), or communicate with the coordinator to validate PK certs for every device attempting to join (nearly as bad if this takes a lot of packets).  Without seeing the overhead, its hard to tell if this would even work - if a device has to stay synchronized for a long time using unsecured frames, how is that any better than a shared secret? There's still a DoS vector in the unsecured bandwidth.

b) I agree that in protocols with a well-known key for authenticating join requests, an attacker can perform a DoS attack by simulating many devices joining.  These messages are passed up to the coordinator (and rejected).  However this requires distributed injection of messages to be maximally effective, and this is little worse than flooding the network with packets authenticated with the wrong key, so I don't see how per-peer keys is an effective DoS mitigator.
--
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
jsimon@linear.com<mailto:jsimon@linear.com>

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

On Jun 23, 2013, at 7:10 PM, <yoshihiro.ohba@toshiba.co.jp<mailto:yoshihiro.ohba@toshiba.co.jp>> <yoshihiro.ohba@toshiba.co.jp<mailto:yoshihiro.ohba@toshiba.co.jp>> wrote:


6tsch-security draft has been submitted to IETF:

http://tools.ietf.org/html/draft-ohba-6tsch-security-00

Regards,
Yoshihiro Ohba

_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch