# Minutes IETF 89 WG meeting, 06 March 2014, 6TiSCH WG # Note: timestamps in GMT. Venue ----- * Thursday, March 6, 2014, 1300-1500 GMT * Buckingham room, Hilton London Metropole, London, UK Taking notes _(using Etherpad)_ ------------------------------- 1. Dominique Barthel 1. Xavi Vilajoana Jabber ------ * Room: xmpp:6tisch@jabber.ietf.org * Logs: http://jabber.ietf.org/logs/6tisch/ * Jabber scribe: Guillaume Gaillard Recordings ---------- * audio recording: http://www.ietf.org/audio/ietf89/ietf89-buckingham-20140306-1300-pm1.mp3 [mp3, 64MB] * Jabber logs: http://www.ietf.org/jabber/logs/6tisch/2014-03-06.html Material -------- * Consolidated Slides: http://www.ietf.org/proceedings/89/slides/slides-89-6tisch-0.pdf Minutes ------- * About 40 attendees * [13:02] Intro and Status (Chairs) * Note-Well, Blue Sheets, Scribes, Agenda Bashing * Thomas introduces the session, objectives, agenda > No issues raised about agenda. Agenda approved. * 6TiSCH charter recap (Pascal Thubert) * Charter mostly to create an architecture to put together pieces created in various IETF groups and elsewhere. * Produce an information model for the management of a TSCH network. * Produce a "minimal 6TiSCH configration" with static TSCH schedule and RPL as the routing protocol. * 6TiSCH milestones recap * adopted 4 WG documents during IETF88 (Vancouver) * next steps is to adopt * 6top document * data model for CoAP * Next year have architecture draft and minimal draft as RFC * [13:09] Overall Architecture and Context * [13:09] (Maria-Rita Palattella) * Maria Rita not in the room, Pascal Thubert standing in * definition of "chunk" added: a portion of the slotframe known globally. Will help future work with dynamic scheduling. Basically grouping timeslots for the purpose of allocation. * CDU matrix: Channel Distribution Usage. Different from the node schedule. * [13:12] (Pascal Thubert) * published version -01 recently * added text about chunk management. Partitioning of big matrix. Decided that only parents in RPL graph can allocate chunks, then use slots from the chunk to talk to children. Leaf nodes only inherit slots from parents. * Related work at the IETF: * 6man: ARO option that needs to be propagated over the backbone. Flow label: currently IP flow encapsulated at entering the RPL domain to be allowed to carry the Hop-by-Hop option. Could be made simpler if 6man allows an exception for that. * 6lo: 6TiSCH is based on traditional 15.4 MAC with small payloads. Getting reports that fragment recovery is needed, as anticipated. * transport area: Deterministic DSCP (presentation by Shitanshu Shah scheduled at end of session) * Related work at IEEE (Pat Kinney) * Vice-chair IEEE802.15, former chair of initial IEEE802.15.4-2003. * Many amendments to IEEE802.15.4, including since IEEE802.15.4e. * 6TiSCH interest group at IEEE formed in November 2013. * Goal is to help the development of 6TiSCH from the IEEE side. Propose amendments, etc, at IEEE to better support the work at 6TiSCH. * Many things to be done together with IETF 6TiSCH WG. One first example is the management of Information Element (IE) identifier space, for example for 6top-to-6top communication. * Create an study group in February 2014. Pascal Thubert is a member. * Combine new technologies aligned to industrial standards. * Interest on technologies such as 6TiSCH, RPL, CoAP, XMPP, MQTT * [Carsten Bormann] Please add 6LoWPAN to the related work. MQTT is not part of the IETF. New activity around authorization, ACE. * [Samita Chakrabarti] Please add 6lo to the list of related work. * Pascal re-iterates that 6TiSCH will adopt work from other WGs such as 6lo. * [Subir Das to Pat Kinney] Anybody responsible for relationship between IEEE and ISA? * [Pat Kinney] Yes, I'm that person. * [Pascal] Next items to cover * 6LoWPAN and RPL have diverged over time * missing: redistribute 6LoWPAN ND into RPL. efficient-ND draft proposes to introduce TID. This would close the gap. * missing; redistributing RPL in ND: RPL root advertising DAO state as ARO. * shows how a leaf node registers through 6LR, 6LBR, 6BBR to the Internet. * Working on the flows to join RPL network with the classical network. * Started a design team for the security architecture, separate weekly phone calls. * [13:31] Information and Data Models [Xavi Vilajosana and Qin Wang] * [Xavi] There used to be a very large document (>100 pages). At last meeting, suggestions to create a data model. Created two drafts out of it: * one interface draft * one sublayer draft * [13:33] (Xavi Vilajosana) * second version of the draft * shows representation of MIB. * both soft and hard cell types. Could not be added into 15.4e, so had to add it here. * new concept of chunk. * management command list. Compared to previous document, removed all security-related commands, and added commands to manage chunks. * [13:37] (Qin Wang) * shows content of draft: * 6TiSCH Operation Sublayer (6top) Overview * 6top Commands * 6top Communication Protocol * Statistics * Monitoring * Main change is flag for cells. "how to use" section went into the architecture draft. * Security commands are related 15.4e, removed from 6top. * Separated out flags for cells and link options. * Next steps: * broadcast cell flag on receive side. * Chunk support, a few 6top-6top communication issues. * Planned to get early reviews from the YANG people in August. * [Pascal] Call for adoption of interface draft through hums. > outcome: good level of hums in favor for, no hums against. * [Pascal] Will confirm on the mailing list. * [Qin] Currently three parts in data model: 6top, 15.4 and 15.4e. The upper layer might need to access the 15.4 PIB or 15.4e PIB. Two possible approaches: put 15.4 and 15.4e PIBs merged into 6top, or keep it outside. * [Pat Kinney] 6top draft contains an interface called "delegation", which looks like a pass-through. Think that is a good approach. Would not encourage proxy for that interface, since we wouldn't gain anything. * [Pascal Thubert] Drawback is that we'll have to change 6top every time something changes below. * [Pat Kinney] Totally agree, stay away from those problems. * [Kuor Hsin Chang] Why separate 15.4 and 15.4e? They will eventually be all part of 15.4. * [Pat Kinney] revision IEEE802.15.4-2014 will include amendments, including IEEE802.15.4e. * [13:53] Security discussions: summary and outlook (Michael Richardson, Michael Behringer) * Quick dive into security. Will show a few options and invite for opinions. * Two requirements on authorization w.r.t. a mote joining * the mote need to know that it is joining the right network * the network need to know whether the mote is allowed to join * authorization for a PCE: authorized sessions. The PCE should be authorized to write the schedule to the mote. * 2 options exist: * Option 1: use same approach as ZigBeeIP. Using PANA running over UDP, and use EAP-TLS. Session between new mote and its neighbor. Neighbor then relays it up to PANA Authorization Agent. EAP may get put in radius packet. This is common approach in AAA space, except that we have limited data/code space; it uses EAP-TLS, which is an adaptation for TLS to run over unreliable networks. Did this with CoAP-DTLS. Major plus of this approach is that code is running with this approach. The contents are not small, but the work is done. * Option 2: use same WirelessHART, or ISA100. Essentially YANG over CoAP protocol living right above IEEE802.15.4e. Joins a network using well-known key. Communication back-and-forth between new node and authorization agent which reaches into new node and modifies a number of objects related to security. Authorization agent handles key management. Same GET/PUT requests used for the actuator. Quite common that nodes on the network is super-user. We could do this with our protocols. A new mote starts off, joins with well-known L2 key (better than no key), RPL DIS to look for parents, DIO back from parents, pick a parent, and send in RPL DAO (suggests non-storing network since doesn't use any RAM and more secure that storing). RPL layer L3 security mechanisms, so RPL traffic is signed. You can sign that DAO which is unicast to the root. Somehow certificate in the DAO. Root contacts the authentication server which accepts the node. As part of the ACK, starts a DTLS-CoAP session. Throuhg DTLS-CoAP session, send YANG-based network parameters. Question about security commands in YANG models. Mote knows who the network is; network knows who the mote is. PCE got a ticket (produced by ACE WG), which allows the PCE to update the schedule * There is a document co-authored by Michael Behringer (draft-pritikin-bootstrapping-keyinfrastructure-00) which indicates what is in the certificates that provided by the mote and network. Authorization for the network is often implicit. If explicit, there might be an ACL. If node is identified on the network, it implies it is the network it intended to join. Uses 802.1AR, in which vendor states whether owns this node; based upon the certificate trust, the node attaches to the correct network. * We now need to identify which security model we like. Add YANG resource if needed. * Discussion: * [Bob Moskowitz] which type of 802.1AR certificates are you using? We have to manage all the different PKIs from all the different vendors in the network. Suggest look into 1AR. * [Michael Richardson] Question for Michael Behringer. To the mote we can provide a single set of information I believe. * [Subir Das] Assumption is that vendor owns. Within the security group, we did discuss this aspect, and we really want to discuss this. * [Pat Kinney] ISA and WHART use out-of-band provisioning, keys are in place when node joins the network. * [Thomas Watteyne]: extremeley important work, thank you Micahel, lets continue on the mailing list. * [Michael Richardson] We need to decide between option 1 and 2. * [14:12] Report on plugfest * overview and goals (Xavi Vilajosana) * review minimal 6TiSCH draft, participants pitch, interop/demos, discusssions. * several demonstrations and interoperation, some with "minimal 6TiSCH", one demo from Cisco Sysems and Linea Technology/Dust Networks showing a full network involving motes and switches. * Invites participants to come present. * presentation of outcome * Pere Tuset (Open University Catalunya) * Introduces new OpenMote open hardware * Runs OpenWSN open-source implementation * Communicates with other types of nodes. * Can be used as traffic sniffer * see http://openmote.com/ * Oleg Hahm (RIOT community) * RIOT is OS for IoT, open-source, available on GitHub * ported OpenWSN over RIOT. Ran on the IoT-Lab mote (see next presenter). * Showed communication between pure OpenWSN and OpenWSN over RIOT. * Cedric Adjih (INRIA) * shows IoT-Lab node (Cortex M3, Atmel 15.4 radio) running OpenWSN. * Are builing a large experiment platform that can be accessed remotely over the Internet. * New version (Future Internet of Things, FIT) will augment the older SensLab (http://senslab.info) platform. * In-door GPS signal replication for fine time distribution. * Nicola Accettura (Univ Bari) * Showed implementation of DeTAS distributed scheduling algorithm on OpenWSN (on TelosB motes). * Nodes express their bandwidth requirements up the collection tree, PCE distributes allocation back down. * Thomas Watteyne (Linear Tech/Dust Networks) and Pascal Thubert (Cisco Systems) * joint demo involving backbone router and SmartMesh IP network. * Federate meshes without renumbering nodes. * ND-proxying for motes, multicast filtered out to avoid draining batteries, backbone router transparent to the way the mesh operates. * Tengfei Chang (UC Berkeley) * Minimal 6TiSCH demo * Lessons learnt (Xavi Vilajosana) * Wireshark dissectors needed. Effort started but not final yet. * Discussion about minimal draft: that number of slots and slotframe are static. Make them configurable? We need in-depth study to determine recommended values. * Thomas thanks Xavi and all participants for this effective and exciting event. * [14:32] Unchartered drafts * [14:32] (Diego Dujovne) * Draft defines a plug-in module (called On-The-Fly, or OTF) for distributed and dynamic scheduling in a 6TiSCH network. * OTF module talks to 6top. Eventually may talk to same module in other node. * Various possible policies: reactive, predictive, and hybrid. Comparison table on advantages and drawbacks of each. * Default algorithm as a proposal (input from Prof. Pister) * missing parts: * Statistics for bundles * Define interface between OTF and 6top * [Thomas] Is the 6top interface as specified today enough to support OTF? * [Diego] Yes. * [Pascal] This work does not mean that allocation can only be local. Future work may include other approaches. * [14:44] (Giuseppe Piro) * Identify security considerations, key management protocol. * Next version of draft in a few weeks. Will use IEs to exchange data between nodes. * Feedback requested. Will work with Security Task Force. * [Bob Moskowitz] Key management protocol is subtle. Get with those who have the scars, get advice from experienced developers on the field. * [Subir Das] Authors of different security draft maybe should meet together and define profiles and practical use cases * [Subir Das] What is the time frame where the security work should be defined? * [Thomas Watteyne] Security is everywhere. Not in the charter at this time but important to start right away. * [Thomas Watteyne] Would like to ask the security task force to read these drafts and see how we merge/proceed. * [Subir Das] Different aspects (bootstrapping, operation, ...) * [Pascal Thubert] When we submit the first architecture we need to have a view of what the security architecture will be. * [Yoshihiro Ohba] Is the plan to include security architecture in the main architecture document? * [Pascal Thubert] We can say what our vision is in the architecture draft, not the overall security architecture. * [Bob Moskowitz] Hard work, it take a long time. * [Robert Cragie] Agree with Yoshihiro. * [Subir Das] as a WG we should not submit the architecture draft without including the security vision. Need to really think on that. Need to enforce that part. * [Michael Richardson] I had never idea of what a security architecture is. We need to know what the threads are, we new the tools we have to protect against that threads, and we know the CCM architecture. We need to identify the constraints of the systems we are addressing. This needs to be stated. * [Robert Cragie] Generalize it first. * [15:00] (Shitanshu Shah) > By lack of time, need to push this presentation to a later meeting. * [15:01] Any Other Business > No other business raised. * [15:02] Meeting ends