1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 140218_webex_security

View History

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

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

Updated