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

Jonathan Simon <jsimon@linear.com> Tue, 02 July 2013 22:45 UTC

Return-Path: <jsimon@linear.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 04C3011E8111 for <6tsch@ietfa.amsl.com>; Tue, 2 Jul 2013 15:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 guXf6rA8Znpn for <6tsch@ietfa.amsl.com>; Tue, 2 Jul 2013 15:45:50 -0700 (PDT)
Received: from p02c12o142.mxlogic.net (p02c12o142.mxlogic.net [208.65.145.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9E79D11E8105 for <6tsch@ietf.org>; Tue, 2 Jul 2013 15:45:45 -0700 (PDT)
Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o142.mxlogic.net(mxl_mta-7.1.0-3) with ESMTP id 91853d15.2b82b2e2a940.63834.00-546.158071.p02c12o142.mxlogic.net (envelope-from <jsimon@linear.com>); Tue, 02 Jul 2013 16:45:45 -0600 (MDT)
X-MXL-Hash: 51d358197c333bde-ec21aecc4c4b9ebe724b507effaba1ca79c9c91e
Received: from unknown [12.218.215.72] (EHLO smtpauth1.linear.com) by p02c12o142.mxlogic.net(mxl_mta-7.1.0-3) with ESMTP id 71853d15.0.63826.00-328.158047.p02c12o142.mxlogic.net (envelope-from <jsimon@linear.com>); Tue, 02 Jul 2013 16:45:44 -0600 (MDT)
X-MXL-Hash: 51d35818584a1dd9-1bcd3c7d98b9ce74d885324316b41b2f0c6381ef
Received: from jsimonmacmini.engineering.linear.com (unknown [10.70.48.25]) by smtpauth1.linear.com (Postfix) with ESMTPSA id 2A959740A4; Tue, 2 Jul 2013 15:45:40 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary="Apple-Mail-154--638997614"
From: Jonathan Simon <jsimon@linear.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD841337035@xmb-rcd-x01.cisco.com>
Date: Tue, 02 Jul 2013 15:46:33 -0700
Message-Id: <DA03B233-6FC6-448F-9177-A91A368A6068@linear.com>
References: <674F70E5F2BE564CB06B6901FD3DD78B12D258EB@tgxml338.toshiba.local> <8E172190-20C7-4BD4-96B8-E3F79684FECD@linear.com> <E045AECD98228444A58C61C200AE1BD841337035@xmb-rcd-x01.cisco.com>
To: Pascal Thubert <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1085)
X-AnalysisOut: [v=2.0 cv=LKDRtuq9 c=1 sm=1 a=glloKNylpeYNumXQcclYyA==:17 a]
X-AnalysisOut: [=6gXxV4Ww6ikA:10 a=D2_GN2MmYMYA:10 a=BLceEmwcHowA:10 a=MqD]
X-AnalysisOut: [INYqSAAAA:8 a=c9vm7nRTORYA:10 a=Fngfi1JL9BZM4dHOOBYA:9 a=p]
X-AnalysisOut: [ILNOxqGKmIA:10 a=19wCD08tTksA:10 a=vsVyj9psLt0A:10 a=qVizm]
X-AnalysisOut: [W-ZYBIA:10 a=p-HxVa_ds0YA:10 a=xLpt9-x9cSEA:10 a=oCcf4Ptsk]
X-AnalysisOut: [GSZ8XKA:21 a=4b-A_9Wk8iIUj9qn:21 a=UehEbJaHVAMUATYONV8A:9 ]
X-AnalysisOut: [a=_W_S_7VecoQA:10 a=FZ1qcOeFKKtiWncU:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <jsimon@linear.com>
X-SOURCE-IP: [12.218.215.72]
Cc: "6tsch@ietf.org" <6tsch@ietf.org>, "<yoshihiro.ohba@toshiba.co.jp>" <yoshihiro.ohba@toshiba.co.jp>
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: Tue, 02 Jul 2013 22:45:56 -0000

Pascal - I don't think we're disagreeing that very large networks of sensors have tremendous value, or that the totality sensor inputs is more valuable than the sum of the individual inputs.  I was simply trying to point out that the language in the draft implies that there is n^2 value in the mote interconnectivity - the utility is not in having 10000 nodes all talking to every other node, it's in connecting each node to a few nearby nodes and through clever routing protocols like RPL getting access to all the data at a central coordinator. 
-- 
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

**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 28, 2013, at 8:00 AM, Pascal Thubert (pthubert) wrote:

> 
> "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…
> 
> -- 
> Jonathan Simon, Ph. D
> Director of Systems Engineering
> Linear Technology, Dust Networks product group