# Minutes, IETF 103 6TiSCH WG Meeting # Note: these minutes are formatted using Markdown. Agenda and Meeting Information ============================== ``` Meeting : IETF 103 Thursday 8 November 2018 Time : 16:10-18:10 Thursday Afternoon session II (120min) Location : Boromphimarn 3, Bangkok Marriott Marquis Queen's Park Hotel Agenda : https://datatracker.ietf.org/meeting/103/materials/agenda-103-6tisch Meeting Slides : https://datatracker.ietf.org/meeting/103/materials.html Etherpad : http://etherpad.tools.ietf.org/p/notes-ietf-103-6tisch?useMonospaceFont=true Meetecho : http://www.meetecho.com/ietf103/6tisch/ Audio stream : http://ietf103streaming.dnsalias.net/ietf/ietf1032.m3u Chairs : Pascal Thubert Thomas Watteyne Responsible AD : Suresh Krishnan WG URLs : http://tools.ietf.org/wg/6tisch/ https://datatracker.ietf.org/wg/6tisch/ https://www.ietf.org/mailman/listinfo/6tisch https://bitbucket.org/6tisch Intro and Status (chairs) * Note-Well, Blue Sheets, Scribes, Agenda Bashing [10min] * Status of the work, link with other WGs Chartered items * draft-ietf-6tisch-architecture [10min] (Pascal Thubert) goal: prepare WGLC * rfc8480 [5min] (Xavi Vilajosana, remote) goal: status on publication * draft-ietf-6tisch-msf * intro update (Simon Duquennoy) [5min] * simulation campaign (Yasuyuki Tanaka, remote) [15min] * experimental campaign (Tengfei Chang, remote) [15min] goal: discuss ongoing optimizations * draft-ietf-6tisch-minimal-security [25min] (Malisa Vucinic) goal: resolution of WGLC comments Unchartered items, time permitting * draft-tiloca-6tisch-robust-scheduling [15min] (Simon Duquennoy) goal: gathering WG interest and feedback * status of the 6lo fragmentation design team (Thomas) [5min] * AOB [QS] Total scheduled time 105/120min ``` Volunteers ========== * notetaker 1: **Dominique Barthel** * notetaker 2: **Georgios Papadopoulos** * Jabber scribe: **Malisa Vucinic** Action items ============ * editors of MSF (**Tengfei**) and minimal-security (**Malisa**) to read this doc and make sure it represents their draft well. * **Pascal** to merge terminology draft into architecture. Keep standards-track. * **Thomas** to shepherd architecture draft. * **Tengfei** to raise suggestions found with MSF on the ML, ensure get into MSF. * **Pascal** to organize an interim about MSF. * **Malisa** to discuss final changes to the minimal-security draft (no netid configuration of the JRC, configuration of the cap) on the ML * **Chairs** to open 1-week WGLC on changes in -09. Summary ======= (This summary is also posted in the INT area wiki, https://trac.ietf.org/trac/int/wiki/IETF103) During IETF103, the 6TiSCH WG has 1 WG meeting and 2 side meetings. The WG meeting covered 5 drafts: * `draft-ietf-6tisch-architecture` is almost ready. Pascal pushed -16 before the meeting. Pascal will merge `draft-ietf-6tisch-terminology` into `draft-ietf-6tisch-architecture` and publish -17. WGLC will be called and authors of the key 6TiSCH draft will be asked to review. * `rfc8480` was published. * `draft-ietf-6tisch-msf` was covered through 3 presentations: an intro and two "lessons learnt" presentations by 2 implementors (one by simulation using the 6TiSCH simulator, one by experimentation using OpenWSN). Performance is very good and matches the expectations, some lessons learnt already captured in Appendix E of `draft-ietf-6tisch-msf`. Authors will update the document based on these lessons learnt and ensure with implementors that all lessons learnt have been captured. * `draft-ietf-6tisch-minimal-security` is almost ready. It received 7 reviews during the last WGLC, all of which have been integrated, and which reviewers approve. Two final changes are still needed. Editor will discuss those on the ML, integrate them into a new version of the draft if consensus. Chairs will then open a 1-week WGLC only on those changes. * `draft-tiloca-6tisch-robust-scheduling` is new out-of-charter work which proposes a "cell shuffling" solution to prevent a selective jamming attack. The presentation was well received, the author are asked to provide more arguments about the importance of such attack. The first side meeting was bar BoF "Predictable and Available Wireless", organized by Pascal Thubert, in which we discusses the opportunity to apply 6TiSCH to other physical layers, in particular 802.11 WiFi. Discussions are continuing on a new mailing list https://www.ietf.org/mailman/listinfo/paw. The second side meeting was called to discuss EDHOC (draft-selander-ace-cose-ecdhe) and was attended by Jim Schaad (ace co-chair), Roman Danyliw (ace and secdispatch co-chair), Goran Selander, Francesca Palombini (EDHOC authors), Malisa Vucinic (6TiSCH security), Pascal Thubert and Thomas Watteyne (6TiSCH co-chairs). It was agreed that draft-selander-ace-cose-ecdhe would go through the secdispatch process to find the right home for it. The 6TiSCH WG agreed to produce a requirements document in end-of-year, and present that to a secdispatch interim meeting which will be held in January 2019. Minutes ======= * [16.11, expected 16.10] Meeting starts * [16.11, expected 16.10] Intro and Status (chairs) [10min] * Note Well, notetakers, jabber scribe, blue sheets. * security slides just added to the repo. * **Thomas** goes through agenda. Any suggestions fro change? none heard, agenda adopted. * **Pascal** gives the updates from IETF 102 meeting, on RFC8480, RFC8505 * ODVA looking at 6TiSCH for their low data rate Common Industrial Protocol * Thread looking at expanding from home to building automation. * There is a discussion and thoughts whether Thread could be converged with 6TiSCH * related work done in other WGs: 6lo, ROLL, CoRE. * [16.21, expected 16.20] draft-ietf-6tisch-architecture (**Pascal Thubert**) [10min] * kept up-to-date during the work at 6TiSCH. Question to publish it now that the work is completing. * structured into two big sections: high level architectue and finer details of 6TiSCH components * version 16 is published * **Pascal** proposes to go for WGLC for this draft, so that we do MSF now and then security. * **Thomas** suggest to wait for MSF and minimal security? * **Pascal** this one is ready, why wait? We know enough of MSF and minimal security for the purpose of this architecture document. * **Georgios** if new work is started after this is published, how will it get integrated? * **Pascal** this "story" is complete, we can close this document. If we start a new story later, we'll write about it. > **Action item**: editors of MSF (**Tengfei**) and minimal-security (**Malisa**) to read this doc and make sure it represents their draft well. * **Thomas** what about terminology? Do we push it together with this one? * **Pascal** yes, we'll publish terminology at the same time. * **Suresh**: many documents. Could we put terminology is this arch draft? Would this make sense? * **Pascal** This archi is very similar to the one from detnet, this document should in the standard track (Pascal changed it to standard track already) * **Suresh** is fine if stays standards track. * **Suresh** will you shepherd this doc, Thomas? * **Thomas** yes. * **Thomas** both docs are wrappers, one would read them both at the same time. > **Action item**: **Pascal** to merge terminology draft into architecture. Keep standards-track. * **Pascal** Thomas is on the author list. Cannot be shepherd. * **Suresh** Thomas is not an editor, I don't have an issue with Thomas being the shepherd. > **Action item**: **Thomas** to shepherd architecture draft. * [16.32, expected 16.30] rfc8480 (**Xavi Vilajosana**, remotely) [5min] * was published as RFC8480 on 5-Nov-2018. * Minor changes from the previous version. * Important clarification comment in Section 3.4.7 (see the details in slide 2) > No further questions from the room. * [16.35, expected 16.35] draft-ietf-6tisch-msf, intro update (**Simon Duquennoy**, remotely) [5min] * Simon is presenting the updates of this draft since IETF 102. No new content but fixing issues. * Many of the issues were raised from implementation by Yatch and Tengfei. * MSF is adopted as a WG document * **Thomas**: please detail what you need by DoS attach by autonomous cells and joining. * **Simon**: attacker can jam join cells. * **Thomas**: damage stays at the pledge, does not propagate into the network. * **Yatch**: issue is JP fills up its schedule with cells of the pledge. * **Malisa**: a no-brainer solution would be to have downlink traffic go in the shared cell. * **Malisa**: There are the statefull and stateless options to join the network * **Thomas**: continue discussion on the ML * [16.44, expected 16.40] draft-ietf-6tisch-msf, simulation campaign (**Yasuyuki Tanaka**, remotely) [15min] * Yasuyuki is preseting the updates of the 6TiSCH simulator * version 1.1.6 was released yesterday. * The purpose of the simulator is to get quick evaluation of the new ideas, before going to the experimental evaluation. * The simulator can be run over a computer cluster that allows faster evaluation. * simulator can use a connectivity trace acquired from a real environment. * The simulator shows very promising performance, since it was evaluated with OpenWSN, and they show similar results * **Yatch** details the lessons learned from the MSF draft. * **Thomas**: are you saying that with MSF-01, addition of dedicated cells is too slow? * **Yatch**: yes, due to collisions of the autonomous cells. Even in some cases, dedicated cell is not added at all? * **Thomas**: is this a consequence of the backoff? * **Yatch**: yes. * **Thomas**: the traffic is periodic or bursty? * **Yatch**: it is periodic * **Yatch**: frame pending bit not well described in IEEE802.15.4 standard, not sure our implementation is correct. * **Tero Kevinen**: action item in next week's IEEE meeting to clarify * **Lijo Thomas**: * **Yichoan**: can you detail connectivity traces from real deployment? * **Thomas**: runs sequence (RSSI, etc.) from database collected in real deployment, fixed topologies. * **Thomas**: Yatch, is Appendix E of the MSF-01 complete? * **Yatch**: yes * [17.03, expected 16.55] draft-ietf-6tisch-msf, experimental campaign (**Tengfei Chang**, remoteremotely) [15min] * Presents the experimental evaluation of MSF over OpenTestbed that is deployed in the Inria-Paris office buildings * Explains how the testbed works, the API, architecture, connectivity etc. * Presents the 6TiSCH implementation over OpenWSN, and then the OpenVisualizer option * The experimental results shows average PDR 99.14% with 3 number of retransmissions. One node responsible for most losses, needs investigation. * The topology comes with 38 nodes, with max 4 hops? * **Georges** are all nodes sources, even those which relay mesages? what kind of traffic? What was the slotframe size? * **Tengfei**: all nodes generate data. 37 data sources. 1 packet/min. Keep-alive frames on top of that (every 30 s if no other packet). Slotframe is 101 timeslots long. * Proposals from Tengfei: Only reserve autonomous cell to parent, Bring back the one managed Tx cell in additional to autonomous cell, Only send DIO when one managed Tx cell is installed * **Thomas**: does Appendix E contain all recommendations you're making or does it need additions? * **Tengfei**: some are not htere * **Thomas**: raise them on the ML so that they find their way into the MSF. > **Action item**: **Tengfei** to raise suggestions found with MSF on the ML, ensure get into MSF. * **Simon**: agree that maybe currently too much resource, could be allocated on demand * **Thomas**: what is the difference between current situation and your proposal, Simon? * **Simon**: no difference on the air. Only internal. * **Pascal**: lets make it to mailing list * **Thomas**: have you tried to consolidate your findings? Tengfei, do you find the same findings that Yatch does? * **Pascal**: let's have an interim dedicated to MSF > **Action item**: **Pascal** to organize an interim about MSF. * Questions from Jabber: Installing TX to RPL neighbors (RPL parents) * [17.27, expected 17.10] draft-ietf-6tisch-minimal-security (**Malisa Vucinic**) [25min] * updates of the minimal security draft. * WGLC before Montreal, 2 versions published since. * will present major issues here. * stateless proxy: work outsourced to CoRE. New CoAP option for extended token. Now stateless JP operation. * Second issue: Use of confirmable CoAP message for Join Request, retransmission handled by CoAP * Third: bandwidth cap. CoAP has a congestion control mechanism. All is in RFC7252. * **Pascal**: we need to see new ideas (no netid configuration of the JRC, configuration of the cap) would like to see this commented on the ML. > **Action item**: **Malisa** to discuss final changes to the minimal-security draft (no netid configuration of the JRC, configuration of the cap) on the ML * **Pascal**: with RPL, could get info about saturation of the Root, the available in DODAG through DIO packet * new "Error" CBOR structure to carry error code of previous request that failed. * when failure of JRC, new JRC that takes over could reuse nonce. Proposed resolution * sixth issue: blacklist parameter to reject pledges that keep sending requests. * seventh issue: Link_Layer_Key that supports all modes of 15.4 technology * **Malisa**: Tero could you check the answer to issue 7? * **Tero**: already dont, OK. * **Malisa**: do we need another WGLC? * **Thomas**: received lots of comments. Write on the ML the intended changes, discuss them. Then short WGLC. * **Suresh**: agrees with Thomas. Can also open new LC on part of the doc. > **Action item**: **Chairs** to open 1-week WGLC on changes in -09. * OSCORE blocking anyway for the moment. * **Suresh**: don't block this document because of OSCORE. * **Thomas**: about EDHOC, will talk with ACE chairs as we finish this meeting (meeting scheduling conflict) * [17.53, expected 17.35] draft-tiloca-6tisch-robust-scheduling (**Simon Duquennoy**, remote) [15min] * new work. Adversary could easily learn pattern of victim node and run selective jamming (to save energy or be less detectable). * Simon goes through attack algorithm and example. * Proposal to prevent the attack by construction. * uses a secret to permutate timeslot utiliszation pattern and channelOffset pattern. * **Yichoan**: this attack is targeting a single node. Attacker would target full network. * **Simon**: both cases exist. * **Yichoan**: why not full jamming? * **Simon**: to be un-noticed. * **Pascal**: bring this discussion to the mailing list. * **Simon**: will need to update this draft to reflect new version of minimal security. * feedback from the WG? Interest in this? * **Thomas**: it's a neat little trick, but is it a real attack? At bit more convinced after the discussion, as it could be an attack against a single node. * **Tero**: How can a joining node join if the cells to contact the JP continuously changes? * **Simon**: we do not shuffle slotframe. * [18.07, expected 18.09] AOB * no other business raised * [18.08, expected 18.10] Meeting ends