Subject: [6tisch] Recording security webex 18 February 2014

From: Thomas Watteyne <[email-masked]>
Date: Wed, 19 Feb 2014 22:06:06 -0800

All,

You find the attendance, recording and minutes of this week's security
webex at:
https://bitbucket.org/6tisch/meetings/wiki/140218_webex_security

For your convenience, I also copy-pasted them below.

Thomas

---

Minutes Webex 18 February 2014, 6TiSCH Security Task Force

Note: timestamps in PST.
Taking notes *(using Etherpad)*

   1. Pascal Thubert
   2. Thomas Watteyne

Present *(alphabetically)*

   1. Jonathan Simon
   2. Pascal Thubert
   3. Patrick Wetterwald
   4. Rene Struik
   5. Subir Das
   6. Thomas Watteyne
   7. Yoshihiro Ohba

Recording

   - Webex recording (audio+slides,streaming)
   -
   https://cisco.webex.com/ciscosales/lsr.php?RCID=b0bc89dfcf4b472fafdeae0723fcccab
    *[43min]*

Minutes

could publish the security draft at teh reopening and discuss it at the
meeting?

   - *[Rene]* made sure we know what facilities of interface we want to use
   - Rene tries summarizes what the status is with ZIP and WHART. If
   standard uses 15.4, different versions of 15.4 are used in those (ZIP
   -2006, WHART -2003?). We want to build on top of -2011. Rene could look at
   15.4-2011 on top of processing.
   - *[Rene]* we need to discuss a bit more with 4e interface: how do we
   get a device on the network from scheduling perspective. Jonathan had good
   feedback, EB, we need to fine-tune a little bit more there. 6TiSCH need to
   define this a little bit more.
   - *[Jonathan]* big difference is nonce construction, because it is
   related to time. In 4e, a device that attempts to join cannot solicit a
   beacon. We would have to define an additional mechanism. These are the
   types of subtleties that we need to take into account. Security-related
   headers look very similar between different 15.4 versions, with some
   differences in the ability to elide some parts of the header. Define what
   the size of the header will be. Cannot see any particular barrier. For
   example, a device need to hear EB before joining. We could specify that EB
   can be sent in unsecure, but not in favor.
   - *[Rene]* About 6TiSCH minimal draft. Idea of scheduling of individual
   frames between joining node and node already in network.
   - *[Thomas]* 15ms, 101 slots
   - *[Jonathan]* Minimize contentions for those communication 6 slots.
   - *[Rene]* Computation time might be longer than 10ms. Latency between
   node and centralized entity might be large.
   - *[Yoshihiro]* We need exponential backoff.
   - *[Subir]* if backoff is defined at MAC layer, it would still be
   restricted with MAC layer backoff. Initial joining is only little data.
   - *[Jonathan]* backoff is expressed in number of shared slots. You may
   need a lot of backoff for communication to spill into the next slotframe.
   - *[Subir]* In a power failure situation, all nodes will join at the
   same time.
   - *[Jonathan]* One try per slot, may have multiple tries per slotframe.
   - *[Yoshihiro]* Higher-layer back off mechanisms is really needed, since
   not CSMA access.
   - *[Thomas]* When a node joins, it has limited bandwidth. This
   limitation is managed by the MAC layer, but we need to be aware of the
   variability of latency across different networks. For upper layer, looks
   like a slow medium. If the time outs at upper layer account for the low L2,
   then MAC can handle its own and we can keep a clean layering.
   - *[Subir]* Works as long as security layer knows how long it should
   wait before triggering sec procedures. Works if that latency is provisioned.
   - *[Yoshihiro]* Higher layer to do congestion avoidance during joining.
   After joining applications are not required to do congestion avoidance.
   - *[Thomas]* Michael Behringer's draft indicates that we should
   rate-limit the packets injected through an already joined node. Important
   to understand constraints but independent from security handshake.
   - *[Rene]* As long as time constraints are taken into account. Should
   make that available at local level.
   - *[Jonathan]* A small part of security handshake should give a better
   sync to be able to live longer in the network.
   - *[Yoshihiro]* Can the join helper tell the joining node to back off?
   - *[Jonathan]* Yes but that message should be secured. Else a random
   node can kill network formation by backing off everyone else.
   - *[Subir]* Agree.
   - *[Rene]* How many hops to a time source?
   - *[Thomas]* Immediate neighbor should provide that, sync at MAC layer.
   It all depends on deployments, and we should allow for anything that RPL
   allows. 5 to 10 hops?
   - *[Patrick]* We see up to 20 in smart grid deployments.
   - *[Subir]* Need to set timers accordingly, to avoid undue resend of
   packets. Random backoff is a good approach for that.
   - *[Thomas]* A major feature is that the delays are very different from
   case to case. Schedules can be very sparse to very dense. Orders of
   magnitudes on possible delays.
   - *[Rene]* Suppose you can allocate something more periodic we do not
   have to wait. Maybe good to put a few of these considerations in a small
   write up.
   - *[Thomas]* The TSCH draft details these points.

   See http://tools.ietf.org/html/draft-ietf-6tisch-tsch