Subject: [6tisch-security] agenda(?) for call today

From: Michael Richardson <[email-masked]>
Date: Mon, 12 May 2014 07:18:15 -0400

My goal would be to continue the discussion about what the certificates
contain, and how/when/if to trust them.  However, I'm home with a sick
child today, and I don't know if I'll make the call; because I'm home
sick too!

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rene Struik <[email-masked]>
Date: Mon, 12 May 2014 09:53:37 -0400

Hi Michael et al:

Another topic worth exploring more is the join protocol details.

(There are many other aspects, including certs, as you mentioned, more 
general security architecture, provisioning, etc., but below only deals 
with join.)

With w/HART, the join process only interacts with the network manager 
(62591, Annex A.3, Fig. A.1) for
-forwarded join from joining node to network manager;
-passing configuration parms from network manager to joining node (keys, 
links, frame links) and neighbor report from joined node to network manager.
All other communications are local, between joining device and neighbor 
(resp. with maintenance tool).

It may have merit if we could use similar communication flows with 
6tisch, i.e., keep most traffic local to the joining device, except for 
configuration parms exchange and authorization info passing.

Most important consideration (from communication perspective) would be 
that non-local traffic would be minimized, as also w/HART does. From a 
marketing perspective, mimicking the communication flows w/HART already 
has would keep all time scheduling considerations for w/HART as 
currently there and 6TiSCH as to be detailed roughly the same. This 
would longer term help in pushing 6tisch-style security scheme to 
w/HART, since from a distance it looks the same (although trying to 
scrap the maintenance tool).

Of course, this does not deal with the details of the joining protocol 
itself; only the flows.

What about we look at some of the flows, and enumerate all issues that 
need to be addressed here, both from a security perspective and 
otherwise. We can then assign people to find missing information (I am 
esp. curious about how devices know when to send/receive and 
contributions of cycling efforts to total time latency).

We could go over w/HART join flows during the call, to trigger these 
questions.

Best regards, Rene

On 5/12/2014 7:18 AM, Michael Richardson wrote:
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363