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

From: [email-masked]
Date: Sat, 14 Mar 2015 17:28:51 -0400

Tero Kivinen <[email-masked]> wrote:
    >> But, we aren't using the Enhanced Beacons (they are enhanced, not
    >> extended, aren't they? or did I get that backwards again?) for
    >> production network use...

    > They are Enhanced Beacons, and yes you DO need them on the production
    > network (unless your network is completely statically configured).

{sorry to reply so late...}
We've been back and forth on this, and Kris seemed to suggest that EBs
were just not needed for regular operation.

I wonder if we have a disagreement about what is part of the "production
network"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 16 Mar 2015 17:39:20 +0200

> were just not needed for regular operation.

Actually, every time I ask this question from people who should know,
I seem to be getting different answer. Sometimes they say oh, those
beacons are only needed for new devices joining the network to get
information of initial schedule to use. Then when I ask how do the
devices get their full schedule, I usually get answer that upper layer
distributes it using some unspecified method using some unspecified
frames etc, i.e. by magic...

> I wonder if we have a disagreement about what is part of the
> "production network"

Or as they do not realy have TSCH networks set up at all, there is no
general answer for that. If I understood correctly in the WirelessHART
this was done using some proprietary upper layer protocol. 
-- 
[email-masked]

---

From: Jonathan Simon <[email-masked]>
Date: Mon, 16 Mar 2015 10:01:23 -0700

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.

-- 
Jonathan Simon

On Mar 16, 2015, at 8:39 AM, Tero Kivinen <[email-masked]> wrote:

> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> http://cp.mcafee.com/d/5fHCN8p43qb2rzWtSn7ztPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTtAQsKKnvvW_8zD64NPDnKnjpppVdZ5cQsIcsJteOaqJNP_axVZicHs3jq9J4TvAn3hOYyyODtUTsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9BWvpKcFBzrAVkIjbQ-Pspjb5O5mUm-waBYTu00CTS4kjobZ8Qg6BJOsGm9BWvpKcFBziWq8052gl4zh0KHY9Qd45o6y1OsGm9BWvpKcFBzrX1K-CJG4Xz

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Mar 2015 12:58:24 +0200

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

---

From: Rene Struik <[email-masked]>
Date: Tue, 17 Mar 2015 09:59:23 -0400

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] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 17 Mar 2015 09:55:38 -0700

> every time they send frames.

JS - Once you lose synchronization, you’re no longer in the network, since without time link layer security fails. 

> beacons, you can listen to them and stay in sync with the timing.

JS - Yes this is true, but normally the EBs used to solicit new nodes uses different link-layer keys than you would use “in-network.”  TSCH is a little weird in that it uses EBs, but is considered a non-beaconing PAN, because all communication isn’t managed by beacons, only initial synchronization.

> So I would think EBs do have use in production network too, not only

JS - They could. In our networks we put EB’s on a schedule that admitted nodes don’t listen to, and only send EB’s with a pre-shared link key.