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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 03 July 2013 07:29 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 F131021F866E for <6tsch@ietfa.amsl.com>; Wed, 3 Jul 2013 00:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.098
X-Spam-Level:
X-Spam-Status: No, score=-8.098 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, 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 4hInp-U7sD6a for <6tsch@ietfa.amsl.com>; Wed, 3 Jul 2013 00:29:08 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B1D9B21F9C4F for <6tsch@ietf.org>; Wed, 3 Jul 2013 00:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12646; q=dns/txt; s=iport; t=1372836547; x=1374046147; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OgxdUwj6ekfRIHy7m/vprJ4isv9H8yuCNj4aPbqRYJY=; b=mVbe8NJnWujcJ9o710APspF/plaKzqWbYdlx2Xwgz/TfYcRWNJ4gZoSf WC0NjHx99f4cZNxVRYp96raUDOInHd5lBe7KdA90+m9s6XbWZbfmTsVQy 5oDQaLu4ASdJLqWuB5qX3bdVXNfnwbUQm7HyGSoDT70GrkvnTio7ZB4KJ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAF7S01GtJXG9/2dsb2JhbABXA4JFRDJJwC6BABZ0giMBAQEELUwQAgEIDgMEAQELHQcyFAkIAgQOBQiIB7sHjiMKBoEBIRAGARGCc2kDhUCjT4MRgWgJFyA
X-IronPort-AV: E=Sophos; i="4.87,986,1363132800"; d="scan'208,217"; a="230371656"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jul 2013 07:29:06 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r637T5Ah015053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Jul 2013 07:29:05 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.9]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 3 Jul 2013 02:29:05 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Jonathan Simon <jsimon@linear.com>
Thread-Topic: [6tsch] draft-ohba-6tsch-security-00
Thread-Index: AQHOd3XmWynKI+L2nk+hAhLZWFYDm5lSji2Q
Date: Wed, 03 Jul 2013 07:29:04 +0000
Deferred-Delivery: Wed, 3 Jul 2013 07:29:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD84134C589@xmb-rcd-x01.cisco.com>
References: <674F70E5F2BE564CB06B6901FD3DD78B12D258EB@tgxml338.toshiba.local> <8E172190-20C7-4BD4-96B8-E3F79684FECD@linear.com> <E045AECD98228444A58C61C200AE1BD841337035@xmb-rcd-x01.cisco.com> <DA03B233-6FC6-448F-9177-A91A368A6068@linear.com>
In-Reply-To: <DA03B233-6FC6-448F-9177-A91A368A6068@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.209.15]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD84134C589xmbrcdx01ciscoc_"
MIME-Version: 1.0
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: Wed, 03 Jul 2013 07:29:14 -0000

Yes, I can buy that, Jonathan.

We'll discuss this at the next call when Yoshi presents and I think we'll remove my misleading reference to Metcalf on the next revision.

Cheers,

Pascal

From: Jonathan Simon [mailto:jsimon@linear.com]
Sent: mercredi 3 juillet 2013 00:47
To: Pascal Thubert (pthubert)
Cc: <yoshihiro.ohba@toshiba.co.jp>; 6tsch@ietf.org
Subject: Re: [6tsch] draft-ohba-6tsch-security-00

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<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 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