Please find below the minutes of the 6TiSCH Security conf call as of 
January 6, 2015, 5pm EST.

Minutes 6TiSCH Security conf call, Tue January 5, 2015, 5-6pm EST
{note taker: Rene Struik}
{recording: see 6tisch bitbucket list}
{slides discussed (and referenced in minutes): no slides this time }

1. Attendance:
Michael Richardson, Malisa Vucinic, Yoshi Ohba, Thomas Watteyne, Kris 
Pister, Rene Struik

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

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

4. 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.

5. 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.

6. 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).

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


On 1/6/2015 11:48 AM, Rene Struik wrote:
> Dear colleagues:
>
> Happy New Year!
>
> According to the agreed-upon 6tisch security conf call schedule, we 
> will resume the conference call series today, Tue Jan 6, 2015, 5pm EST.
>
> I propose we continue the discussion where we left off prior to 
> Christmas (essentially, item 3c below), except that we may have a 
> short presentation first (item #2).
>
> Agenda:
> 1) administrativia {agenda bashing/minutes}
> 2) {still to be confirmed} presentation Giuseppe Piro
> 3) join protocol details
> -- a) (done) status update MAC behavior
> -- b) (brief!) recap of routing/communication flow aspects
> -- c) incremental deployment aspects
> 4) input 6tisch security to other 6tisch documents
> -- a) terminology draft
> -- b) architecture draft
>
> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The 
> next call, on January 6, 2014) is also at 5pm EST (see schedule till 
> half of January 2015)}.
> Note: next week's call is on Wed Jan 14, 2015, 11am EST.
>
> Dial-in info at end of this email.
>
> Best regards,
>
> Rene

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363