Re: [6tsch] (my comments) Re: Security slides

Rene Struik <rstruik.ext@gmail.com> Fri, 26 July 2013 15:49 UTC

Return-Path: <rstruik.ext@gmail.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 3092021F9991 for <6tsch@ietfa.amsl.com>; Fri, 26 Jul 2013 08:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 usrB4RuKzbub for <6tsch@ietfa.amsl.com>; Fri, 26 Jul 2013 08:49:33 -0700 (PDT)
Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4F821F9971 for <6tsch@ietf.org>; Fri, 26 Jul 2013 08:49:30 -0700 (PDT)
Received: by mail-qe0-f43.google.com with SMTP id k5so581794qej.16 for <6tsch@ietf.org>; Fri, 26 Jul 2013 08:49:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=ganM9Z3D9wTwnlkfN6xdi/8R4WQWOgRawyPP2YVSp/E=; b=Hen8esCO4zAVGWa5YjkE2tO9FpT1FVjPoGuiJ90TMsrCRhXr/Rl+CxWpib5avXwVT/ MNecsRbTUfTKyaRsqDfywDABz0hfP50DgijieZPnhjhLUQiKIKvI7NhDsafHtQawaXa3 lW8slyIUrj8CKc22U4fhP+in7oR4NCU9EbbLKOGOdiHAOAjWRaFgFXzE8zmAZKwOv8in mtXzNfi3FBx/f7M3CWXfrhnX9SkFozd5Itbg6qfRBZzlLnCets3FHXt2KmXyLaUGxW8f TjdQ6LCsXSA99XNUGIEPywOEWiZnKn2HNg264q5R1M7bHcjTHEcSw2r1yOcpy3j9IT53 boEw==
X-Received: by 10.49.74.136 with SMTP id t8mr55075443qev.28.1374853767537; Fri, 26 Jul 2013 08:49:27 -0700 (PDT)
Received: from [192.168.1.101] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.4.27]) by mx.google.com with ESMTPSA id a4sm2391718qai.3.2013.07.26.08.49.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 26 Jul 2013 08:49:26 -0700 (PDT)
Message-ID: <51F29A82.3090800@gmail.com>
Date: Fri, 26 Jul 2013 11:49:22 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: yoshihiro.ohba@toshiba.co.jp
References: <674F70E5F2BE564CB06B6901FD3DD78B12D3F92D@tgxml338.toshiba.local> <51F171D8.1060702@gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B12D3FF36@tgxml338.toshiba.local>
In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D3FF36@tgxml338.toshiba.local>
Content-Type: multipart/alternative; boundary="------------070501090100080500010107"
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] (my comments) Re: Security slides
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, 26 Jul 2013 15:49:34 -0000

Hi Yoshi:

The problem below would be a nice homework assignment, so as to
encourage people to play around with concepts and see hurdles and
implicit assumptions in specifications. We could revisit after the
Berlin meeting. However, please reflect on this.

(I just wanted to illustrate that the question as to how to complement
what is in 802.15.4e security requires more thought than it seems to be
given right now.)

Best regards, Rene

==

One interesting problem would be how to use 802.15.4e security, after a
joining operation, but prior to getting a reliable Absolute Slot Number..

[YO] I am interested in knowing what exactly the problem you mention is.


On 7/26/2013 12:08 AM, yoshihiro.ohba@toshiba.co.jp wrote:
>
> Hi Rene,
>
> Thank you very much for your comments. Please see my response below.
>
> *From:*Rene Struik [mailto:rstruik.ext@gmail.com]
> *Sent:* Friday, July 26, 2013 3:44 AM
> *To:* ohba yoshihiro(大場義洋○RDC□NSL)
> *Cc:* 6tsch@ietf.org <mailto:6tsch@ietf.org>
> *Subject:* (my comments) Re: [6tsch] Security slides
>
> Hi Yoshi:
>
> I am not sure why ZigBee IP is mentioned on the slides, since ZigBee
> does not use TSCH. If mentioning a potential "user" at all, it seems
> more appropriate to mention w/HART or ISA SP100. (It is quite likely
> not needed, though, since covered elsewhere on general overview slides.)
>
> [YO] Sorry for confusion. ZigBee IP is mentioned because it is an
> existing wireless mesh standard that uses higher-layer (IP-layer and
> above) key management protocols to manage 802.15.4 link layer keys,
> and 6TSCH is also looking at higher-layer key management protocols as
> well. Having said that I would rather add the following bullet to make
> this point clear:
>
> “- ZIP uses higher-layer key management protocol (PANA) to distribute
> the network key.”
>
> Why not using the 802.15.4e specification as basis for security
> slides? Section 5.1.2.6 describes PAN formation. It would also help to
> have a few words on "basic" security features of 802.15.4, so that
> people get an idea what is in there.
>
> [YO] We can add a few words on "basic" security features of 802.15.4
> based on your edits. BTW, 802.15.4e TSCH security is also mentioned in
> the original slides.
>
> 802.15.4e nodes use time-scheduling info to determine when to
> communicate (time scheduling) and on which communication channel
> (channel hopping). The 802.15.4e specification describes how this is
> done, based on available TSCH parameters, but does not describe how
> these TSCH parameters are set. That is where some of the work comes
> in, also for security.
>
> [YO] Your editing of Background (1/2) is covered by earlier
> presentations and we don’t need to reiterate it.
>
> I edited the slides you sent out for review, so as to reflect the
> above (please see attached). BTW - I did not delve into PAN formation
> as hinted at in 802.15.4e.
>
> As you can see, I suggest partitioning security work in two stages,
> where the second stage is conditional on rechartering. More
> importantly, though, I feel one needs to focus on understanding the
> space (and the "hooks" in 802.15.4e) first, before putting "solutions"
> on the table. In other words, first define the problem on which these
> solutions should be based.
>
> [YO] If we want to **explicitly** mention “two-stage” approach, it is
> better to change the security part of the text in the current charter
> accordingly. Your edits goes beyond the current charter text, which
> seems to contradict with your previous comment “I suggest to leave the
> current language in the draft charter as is right now.” I would rather
> stop at mentioning requirements & framework in the slides, and
> verbally mention two-stage approach.
>
>
> One interesting problem would be how to use 802.15.4e security, after
> a joining operation, but prior to getting a reliable Absolute Slot
> Number..
>
> [YO] I am interested in knowing what exactly the problem you mention is.
>
> We can discuss more on the call tomorrow.
>
> [YO] I won’t be able to attend the call since I will be traveling to
> Berlin.
>
> Thanks,
>
> Yoshihiro Ohba
>
>
> Best regards, Rene
>
> On 7/24/2013 6:05 PM, yoshihiro.ohba@toshiba.co.jp
> <mailto:yoshihiro.ohba@toshiba.co.jp> wrote:
>
>     Security slides are available at:
>
>     https://bitbucket.org/6tsch/meetings/src/master/130730_ietf-87_berlin/3f_draft-ohba-6tsch-security.pptx
>
>     Please review and send your feedback.
>
>     Regards,
>
>     Yoshihiro Ohba
>
>
>
>
>     _______________________________________________
>
>     6tsch mailing list
>
>     6tsch@ietf.org <mailto:6tsch@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
> -- 
> email: rstruik.ext@gmail.com <mailto:rstruik.ext@gmail.com> | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363