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

From: Giuseppe Piro <[email-masked]>
Date: Sat, 21 Dec 2013 16:13:40 +0100

Dear Qin, Xavier, Thomas, and all

as I've anticipated during the yesterday meeting, we supposed to use the
6top layer to perform security procedures envisaged in our draft
(draft-piro-6tisch-security-issues-01).

In Sec. 2.4.9 of the 6top draft are described some commands related to
security aspects. They mainly are used to set security attributes stored in
the MAC PIB.

We exploited these attributes to manage the configuration of the secured
domain (see Sec. 6.2 of the draft
http://tools.ietf.org/html/draft-piro-6tisch-security-issues-01).

To perform the Key Management Protocol in the Key Negotiation Phase we need
to define new messages, which a couple of nodes should exchange to
negotiate the link key and to perform the mutual authentication.

Since 6top has been selected as the entity that handles these procedures,
we though to introduce additional 6top commands to resolve this issue. They
are CONFIGURE.security.startKMP and CONFIGURE.security.completeKMP (we
provide a description in Sec. 6.3.2 of our draft).

What do you think about this choice ?
Is it possible to add these new 6top commands to those already provided for
the 6top layer ?

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

---

From: Qin Wang <[email-masked]>
Date: Sat, 21 Dec 2013 11:48:52 -0500

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?

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?

Maybe I miss something.

Thanks
Qin

On Sat, Dec 21, 2013 at 10:13 AM, Giuseppe Piro <[email-masked]>wrote:

> To perform the Key Management Protocol in the Key Negotiation Phase we
> need to define new messages, which a couple of nodes should exchange to
> Is it possible to add these new 6top commands to those already provided
> for the 6top layer ?
>
> Thanks,
> Giuseppe
>
>
> --
> *Giuseppe Piro, PhD*
> Post Doc Researcher
> DEI, Politecnico di Bari

---

From: Giuseppe Piro <[email-masked]>
Date: Sat, 21 Dec 2013 18:24:54 +0100

Hi Qin,

> negotiation between a pair of nodes will conducted by exchanging MAC
Yes, it is correct.

> 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

---

From: Qin Wang <[email-masked]>
Date: Sun, 22 Dec 2013 08:52:38 -0500

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:

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