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

[<[e-mail]>]

Hi Rene,

Thank you very much for your comments. Please see my response below.


From: Rene Struik [mailto:[e-mail]]
Sent: Friday, July 26, 2013 3:44 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [e-mail]<mailto:[e-mail]>
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, [e-mail]<mailto:[e-mail]> 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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/6tsch




--

email: [e-mail]<mailto:[e-mail]> | Skype: rstruik

cell: [phone] | US: [phone]