Subject: Re: [6tisch] [6tisch-security] WGLC comments on 6tisch-security

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 18 Mar 2015 07:16:32 +0000

Hello René:

OTOH, we can introduce our own terms if we find them useful. But then we must agree on the definition before we use the term, else misunderstandings will follow. 

As it goes, key separation effectively segregates wireless networks efficiently, even if a same pan id is being used. 

We could define one or more production networks as separate entities, each with different keys and time slots, so they do not overlap between one another and with the network that is used for joining devices. 

Based on the result of the join, the device would be redirected to the production network that is indicated to it, by using the schedule as well as the key that is obtained during the join.

One value of that model is that the joining devices do not interfere with the running network.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: mardi 17 mars 2015 14:59
To: Tero Kivinen; Jonathan Simon
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [6tisch] [6tisch-security] WGLC comments on 6tisch-security

Dear colleagues: 

FYI - there is no such thing as a production network vs. join network: there is only one PAN. Please also see Section 1.1, Item #5, pp. 3-4 of draft-struik-6tisch-security-architectural-considerations-01, part of which is excerpted here:

This does not mean, however, that these nodes operate in a separate PAN, though, since incoming frame processing relies on filtering on a single destination PAN Identifier (see 802.15.4-2011, 5.1.6.2), which implies that the neighbor node can only be part of a single PAN (802.15.4-2011 does not know the concept of "multiple PAN instances"). This also implies that there is no mechanism within 802.15.4 to designate frames for "join" purposes or other special uses (as Wireless HART seems to do with enhanced beacon frames).

Best regards, Rene

On 3/17/2015 6:58 AM, Tero Kivinen wrote:

Jonathan Simon writes:

Linear has 1000’s of TSCH networks running, and I was an author of
the standard so I can speak to this - the background is that since
802.15.4e was a MAC amendment, there was a lot of pressure to remove
what was thought of as “upper layer” behavior.  So we have minimal
primitives to send synchronization, timeslot, hopping sequence,
link, and slotframe information over the air using Enhanced Beacons,
timing feedback through enhanced acknowledgements, and primitives
and to assign MAC properties by a Management layer (the MLME), but
we don’t have a general 4e mechanism for assigning slotframes and
links over the air.  The intent was the EBs are used for initial
synchronization and temporary joining link assignment, but that the
“full" link/slotframe configuration is left to a higher layer to
deal with, i.e. there needs to be an application layer that defines
the protocol - we use data frames and basically reuse the IE format
from the EB in our application layer.  6TiSCH is proposing to use
CoAP.

But there might also be nodes which only use shared slots, and which
are mostly sleeping, thus might not keep track of time exactly, thus
they might benefit from using EBs also in production network. Or are
such devices always assumed to be joining and leaving the network for
every time they send frames.
 
Also EB frames are something that can be used for time
syncronmization, i.e. if your timing parent happens to be sending
beacons, you can listen to them and stay in sync with the timing.
 
So I would think EBs do have use in production network too, not only
for joining devices.
 
On the other hand as the protocol in higher layer managing the full
link/slotframe configuration is not yet defined, we do not know what
it will be using...
 
But your explanation helped a lot, and reading the
draft-ietf-6tisch-tsch also helped a lot, but in general before we
have the upper layer protocol defined we cannot say whether EBs are
used in production network or not...

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

---

From: Rene Struik <[email-masked]>
Date: Wed, 18 Mar 2015 09:30:02 -0400

Hi Pascal:

Indeed, one can define one's own terms. {One note of caution, though: 
there seem to be lots of misconception on how PANs operate, so any 
definition of own terms should not make these misconceptions even larger.}

I do not entirely understand the detailed mechanics of how what you 
describe below would easily allow a "hot swap" or "hot placement" 
deployment scenarios. When a device joins a network, it will communicate 
to the nodes in this network via a neighbor node (aka JA) that is in 
this (operational) network.

Some potentially useful notes on joining, join properties, and 
flexibility of joining, see 
draft-struik-6tisch-security-architectural-considerations-01 that I 
posted January 8th (in particular Section 1.3.2, items 7-12).

We can discuss more in Dallas.

Best regards, Rene

On 3/18/2015 3:16 AM, Pascal Thubert (pthubert) wrote:
>
> Hello René:
>
> OTOH, we can introduce our own terms if we find them useful. But then 
> we must agree on the definition before we use the term, else 
> misunderstandings will follow.
>
> As it goes, key separation effectively segregates wireless networks 
> efficiently, even if a same pan id is being used.
>
> We could define one or more production networks as separate entities, 
> each with different keys and time slots, so they do not overlap 
> between one another and with the network that is used for joining 
> devices.
>
> Based on the result of the join, the device would be redirected to the 
> production network that is indicated to it, by using the schedule as 
> well as the key that is obtained during the join.
>
> *From:*6tisch [mailto:[email-masked]] *On Behalf Of *Rene Struik
> *Sent:* mardi 17 mars 2015 14:59
> *To:* Tero Kivinen; Jonathan Simon
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [6tisch] [6tisch-security] WGLC comments on 6tisch-security
>
> Dear colleagues:
>
> FYI - there is no such thing as a production network vs. join network: 
> there is only one PAN. Please also see Section 1.1, Item #5, pp. 3-4 
> of draft-struik-6tisch-security-architectural-considerations-01, part 
> of which is excerpted here:
>
> This does not mean, however, that these nodes operate in a separate 
> PAN, though, since incoming frame processing relies on filtering on a 
> single destination PAN Identifier (see 802.15.4-2011, 5.1.6.2), which 
> implies that the neighbor node can only be part of a single PAN 
> (802.15.4-2011 does not know the concept of "multiple PAN instances"). 
> This also implies that there is no mechanism within 802.15.4 to 
> designate frames for "join" purposes or other special uses (as 
> Wireless HART seems to do with enhanced beacon frames).
>
> Best regards, Rene
>
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik