Minutes 6TiSCH Security conf call, Tue February 17, 2015, 9-10am EST

• note taker: Rene Struik
• discussion material (referenced in minutes): presentation, titled "latency_tsch_dedicated_cells", posted on the 6tisch bitbucket list

Attendance

1. Giuseppe Piro
2. Thomas Watteyne
3. Malisa Vucinic
4. Rene Struik

Agenda

The suggested updated agenda was approved, with the amendment that Malisa Vucinic, rather than Thomas Watteyne, would present on time latency aspects (agenda item #2 below)

Suggested agenda, after amendment: 1. administrativia {agenda bashing/minutes} 1. time latency aspects (Malisa Vucinic) 1. AOB

Minutes

The minutes of the previous 6TiSCH security conference call (Tue February 10, 2015) still have to be approved.

Time latency aspects

• MV gave a presentation on time latency aspects of TSCH, which focused on average time delays in the event of a random TSCH schedule with one dedicated cell per slotframe, respectively C cells per slotframe. For slotframes consisting of L timeslots and C random slots per slotframe, the avg frame delay amounts to roughly L/(C+1) timeslots, assuming ideal circumstances (no packet loss, no queueing, etc.). For slotframes with L=101 timeslots of 10ms and C=1 dedicated scheduled cell, this amounts to an avg single hop delay of roughly half a second. As special example, he discussed time latencies to be expected with DTLS with pre-shared keys (11 MAC frames), both in the single-hop scenario (latency ~ 8 seconds) and in the scenario where entities would be 5 hops away (~40 seconds). Finally, he discussed complications in modeling shared, rather than dedicated cells.
• RS remarked that in tree-like routing protocols, such as RPL, nodes closer to the DODAG root would need to get more dedicated cells per slotframe, since with "pure" routing in a balanced tree one would expect half of the traffic to pass via the root. He also noted that the DTLS example focused on the device authentication and authorization steps of the join protocol and did not include the configuration step (which might very well dominate overall join traffic); thus, total join protocol communication time latency might very well be significantly higher than what arises from the DTLS protocol itself.
• ThW suggested that with a join protocol using public-key based techniques communication latencies might be higher than with the pre-shared keying material scenario, e.g., due to use of certificates -- as also alluded to at the end of Slide 5 of the presentation. A brief discussion ensued. RS noted that the ephemeral public keys exchanged between entities (e.g., joining node JN and JCE) were expected to fit within a single 802.15.4 frame, as these would be well below 90 bytes.
• As a general note, the presentation on expected TSCH time latencies made it clear that
  • caching of JCE certificates and configuration information on the join assistant (JA) would greatly help in reducing the total time latency of the join protocol, due to reduction of long-haul traffic between joining node and JCE that would otherwise be required.
  • time delays due to cryptographic computations would be less important, relative to communication time delays caused by TSCH.
  • distributed implementation of the JCE and PCE functionality would greatly help in reducing the total time latency of the join protocol, due to route diversity and expected reduction of the length of the communication path between joining node and network-resident nodes involved with the join protocol, such as JCE/PCE.
• RS volunteered to validate time latency formulas presented and try and come up with a simple proof/argument for these (note: posted later the same day, see http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00430.html)

AOB

No other business.