Minutes Webex 04 November 2014, 6TiSCH Security Task Force

Attending:

• Thomas Watteyne
• Michael Richardson
• Jonathan Simon
• Kris Pister
• Pascal Thubert

In this call we returned to getting section 3 ready for proposing as part of the 6tisch architecture. This resulted in the post at: http://www.ietf.org/mail-archive/web/6tisch/current/msg02690.html

These minutes describe how we got to this text.

We returned to the question:

• how do we get communication between the joining node and the JCE?
  • IP-IP tunnel between join assistant and JCE
  • use pre-existing DODAG, DAO sent up to parent and DODAG root, informing existence
  • second DODAG. non-storing
  • (not exclusive) 6TiSCH track for join traffic

We discussed the last item for awhile in the context of Deterministic Ethernet and other 6tisch track allocations. We discussed how we could use the track and QoS features to either protect the network from DDoS from joining nodes, or alternatively, lower the time for a network to form by allocating more bandwidth.

We came back to the question: "does the JCE have connectivity to joining node?" (and how)

After much discussion we came to the conclusion in the 2014-11-04 discussion that we would use the existinng DODAG, even if it was a storing DODAG.

• MR: part of goal is to prevent DoS. If we agree that in general in a 6TiSCH network, we can replace networks with 6TiSCH tracks, that's a possibilty. We can add QoS on those tracks. Maybe we don't need to think too hard about option 4.

Near the end of the discussion a new option was proposed, which is to not have the joining node join the DODAG (the Join Assistant would send a DAO on behalf of the joining node), but rather for the JCE to use loose source routing to reach the Joining Node. The JCE would send via the Join Assistant, and it would get that address from the DAR message that the 6LBR would share.

At the end of this meeting, mcr took the action to update the document, which was included in the text pointed to above.

Just prior to the 6tisch WG meeting at IETF91, it was pointed out that the we couldn't, according to specification, put link local addresses into the RH2, because their link scope would be unclear. We are investigating what other options we have, because the resulting system has very little state per joining node.