Subject: [6tsch] Security slides

From: <[email-masked]>
Date: Wed, 24 Jul 2013 22:05:15 +0000

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

---

From: Rene Struik <[email-masked]>
Date: Thu, 25 Jul 2013 14:43:36 -0400

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

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.

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.

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.

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

We can discuss more on the call tomorrow.

Best regards, Rene

On 7/24/2013 6:05 PM, [email-masked] wrote:
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: <[email-masked]>
Date: Fri, 26 Jul 2013 04:08:07 +0000

Hi Rene,

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

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

[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, [email-masked]<mailto:[email-masked]> wrote:
Security slides are available at:

Regards,
Yoshihiro Ohba

6tsch mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Fri, 26 Jul 2013 11:49:22 -0400

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

On 7/26/2013 12:08 AM, [email-masked] wrote:
> *From:*Rene Struik [mailto:[email-masked]]
> *Sent:* Friday, July 26, 2013 3:44 AM
> *To:* ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* (my comments) Re: [6tsch] Security slides
>
> Hi Yoshi:
>
> 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:
>
> 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.
>
> 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.
>
> 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..
>
> On 7/24/2013 6:05 PM, [email-masked]
> <mailto:[email-masked]> wrote:
>
>     [email-masked] <mailto:[email-masked]>
>
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Fri, 26 Jul 2013 12:07:05 -0400

Hi Yoshi:

I believe there is really no reason to mention ZigBee here (or advertise
PANA for that matter [it smells too much like predisposition as to
solution directions, without knowing how it fits with requirements [the
whole point of my comments so far]). Focus should be on how to trigger
802.15.4e TSCH behavior... So, I would argue to remove all this (hence,
me editing slides). If you want to mention something it should be a
current TSCH users, such as w/HART or ISA.

Best regards, Rene

[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.”