Minutes Webex 06 January 2015, 6TiSCH Security Task Force

5-6pm EST

• note taker: Rene Struik}
• slides discussed (and referenced in minutes): no slides this time }

Attendance

1. Michael Richardson
2. Malisa Vucinic
3. Yoshi Ohba
4. Thomas Watteyne
5. Kris Pister
6. Rene Struik

Agenda

The suggested agenda was approved, after removal of item #2 below (speaker not available) * administrativia {agenda bashing/minutes} * {still to be confirmed} presentation Giuseppe Piro * join protocol details * a) (done) status update MAC behavior * b) (brief!) recap of routing/communication flow aspects * c) incremental deployment aspects * input 6tisch security to other 6tisch documents * a) terminology draft * b) architecture draft

Minutes

RS apologized for being late with sending out the minutes of the previous call.

Brief recap of routing/communication flow aspects (item #3b of agenda)

• RS summarized some of the discussion at the previous call regarding communication flows between joining node, neighbor node (the join assistant), and server (JCE). Main discussion point was that the slides assumed a role for the router node (join assistant) that stretches further than just the role of relay station: it only forwards traffic to the server after first authenticating the joining node. Here, the idea was that while authentication does not offer fine-grained authorization control (without further filtering mechanisms on the router (join assistant)), it might help in limiting denial-of-service attacks targeting the long-haul communication channel between the router (join assistant) and the server (JCE). RS suggested that it would not be too hard to extend this mechanism to support both the relay and the authenticating role of the router (join assistant). Upon question by MV as to whether it was decided what to actually support, RS suggested this would depend on more detailed cost/benefit analysis (which is still to be done).
• KP asked how the terminology of joining node, neighbor node, and server related to the notions JN, JA, and JCE. RS suggested that these would be the same notions, if each role would be implemented on a single device; he simply used notions in slides circulated during earlier calls and also presented at IETF-90 and -91 meetings.
• RS mentioned that the protocol discussed would allow for a single communication flow between join assistant and server (JCE), in case JCE-related certificate information could be cached at the join assistant, which is optimal. He expected that this would cover ordinary operation; out-of-sync behavior would necessitate an additional communication flow, so as to recover from this anomaly. Upon question by TW, RS suggested that the initial sync operation could be used as bootstrap mechanism.
• RS suggested that there are lots of details/minutiae that need to be worked out, once we have agreement that this approach has indeed sufficient merit.

Incremental deployment aspects (item #3c of agenda)

• On the RoLL mailing list, so-called incremental deployment scenarios were brought up (e.g., by Peter van der Stok). With RPL, a joining node would only join a tree, where each node hereof would already be part of the network. For applications such as building control, one would prefer a more "random" network configuration approach. Here, the idea is that as long as the new node is able to find the root, it should be possible to enroll, no matter whether each node on the communication path to the root is already part of the network, as MR suggested is currently the case with RPL. An example scenario would be if the newbee node talks to the root via a configuration tool, where the latter two devices would communicate, e.g., via cellular traffic. Question is whether we can accommodate this scenario.
• KP suggested that the only requirement is that there is indeed a communication path between the joining node and the server (JCE). MR suggested that there is no implicit assumption that communication between join assistant and PCE would be private. TW was curious why this topic was brought up. RS suggested that it would be good to limit interdependencies between routing protocol and join protocol, e.g., to support wider use case scenarios. Here, this would include "crazy" scenario where one would set up a large network, where one would sprinkle the room with unsecured nodes that only provide connectivity during set-up. This would allow use of any communication protocol during set-up and removal of "connectivity-assist" devices after configuration is finished and using RPL only once this step has finished. RS suggested that the so-called join priority parameter in 802.15.4e-2012 might be a potential hurdle (since it essentially encodes the length of the shortest path to the DODAG route, using historical tree-like set-up info). TW suggested that it would be possible to completely discard the join priority parameter in practice, so that this would not be a problem.

Input 6tisch security to other 6tisch drafts (item #4a, #4b of the agenda)

• YO mentioned that he had provided some feedback on the email by Pascal Thubert on join process and had commented that this section should be less specific and that he had reservations about specific notions, such as ULA addresses. RS volunteered to provide input to the terminology draft and the architecture draft, so as to remove roadblocks by end of week. The idea here would be that the level of detail would reflect consensus as reached to-date.
• RS mentioned that there were some other inter-dependencies, e.g., with the minimal draft, but that Xavier Vilojasana had already responded to comments submitted just prior to Christmas (Dec 19, 2014).

AOB --- Conf call scheduling

Next week's conf call is Wed January 15, 2015, 11am EST. There is no schedule for subsequent weeks yet; not urgent, but to be discussed next week.

[end of call: 5.56pm EST]