Subject: Re: [6tisch] 6top commands for security purposes

From: Giuseppe Piro <[email-masked]>
Date: Sat, 18 Jan 2014 17:29:14 +0100

Hi Qin,

thank you very much for these very useful comments.

I've understood that modification to the standardized MAC layer are not
allowed ... and I will re-design the whole security procedure by using new
IEs and corresponding commands.

I agree with your that it is more useful adding a KEY manager above 6top to
handled security issues.

In summary, this discussion has produced these three important action
points:
1) remove modification to the MAC layer proposed
in draft-piro-6tisch-security-issues
2) introduce new IEs and corresponding commands for initializing,
configuring, and updating the L2 security
3) assign to the KEY manager the role of handling security capabilities
conceived in draft-piro-6tisch-security-issues

Is it right ?

Are there any other comments on that issue ?

Thanks and regards
Giuseppe

On Sun, Dec 22, 2013 at 2:52 PM, Qin Wang <[email-masked]> wrote:

> Hi Giuseppe,
>
> (1) From protocol stack point of view, MAC command frame should be inside
> of MAC layer. Its upper layer, including 6top, should call primitives of
> MAC layer to invoke a MAC frame, instead of accessing MAC frame directly.
> In another word, the primitives, instead of MAC frames, are the interface
> between MAC layer and its upper layer. And, 6top commands set is the
> interface between 6top sublayer and its upper layer. Thus, 6top commands
> can not replace MAC primitives.
>
> (2) In the 6top WG, I don't think we can propose some change to
> IEEE802.15.4, or take it as assumption to design 6top. What we can do is
> based on the existing IEEE802.15.4-2011 and IEEE802.15.4e-2012.
>
> (3) I'm not sure if negotiating KEYs should be part of 6top, because,
> according to Charter, 6top sublayer is for communication resource
> allocation. More specifically, 6top is used to fill the schedule used by
> TSCH. I believe KEYs management is critical for the network. But, at this
> step, I would like to suggest to put the KEYs manager, no matter
> centralized or distributed, above 6top, just like what we do for
> communication resource management.
>
> (4) If the one-hop KEY negotiation is really needed to be supported by
> 6top, I would suggest to design some additional security IEs and
> corresponding commands to implement.
>
> What do you think?
>
> Qin
>
>
>
>
>
>
>
>
> On Sat, Dec 21, 2013 at 12:24 PM, Giuseppe Piro <[email-masked]>wrote:
>
>> Hi Qin,
>>
>> On Sat, Dec 21, 2013 at 5:48 PM, Qin Wang <[email-masked]> wrote:
>>
>>> Hi Giuseppe,
>>>
>>> I just did a quick read of your draft. According to my understanding,
>>> what you say is that, for supporting your proposal, two things are needed,
>>> one is extending IEEE802.15.4 command frame, another is adding some 6top
>>> commands to negotiate  KEYs. In addition, the communication for the KEYs
>>> negotiation between a pair of nodes will conducted by exchanging MAC
>>> command frames. Correct?
>>>
>>>
>> Yes, it is correct.
>>
>>> If yes, from protocol stack of view, I think the named 6top commands are
>>> more likely MAC layer primitives. In another word, what you need is
>>> extending IEEE802.15.4 only, including additional command frame and
>>> corresponding primitives. Right?
>>>
>>
>> I believe that this vision could be correct if we focus the attention
>> only to IEEE 802.15.4(e) networks. In our proposal, we are considering
>> 6tisch environments and we entrust to the 6top sub-layer the capability to
>> configure and manage the secured domain.
>> For this reason, we adopt 6top commands (included those introduced on our
>> draft) instead of using only MAC primitives.
>>
>>
>> What do you think about ?
>>
>> Thanks,
>> Giuseppe
>>
>
>

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: telematics.poliba.it/piro