Hello 6TiSCH, As agreed at the IETF 106 meeting, I start this thread to support the continuation of the 6TiSCH WG and the work on this document.
https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling The draft describes how 6TiSCH nodes can efficiently and pseudo-randomly alter their original schedule at each slotframe. The resulting schedule is robust and not vulnerable to selective jamming attack, while remaining consistent as well as collision-free. Appendix A shows a step-by-step example output from the proof-of-concept implementation at [1]. After the presentation at IETF 104, the draft was well received, and got three positive reviews from Michael [2], Tengfei [3] and Pascal [4]. Reviewers' comments were addressed in the latest v -02 presented at IETF 105. An open point concerns the renewal of keying material to permute the schedule. The current draft discusses how such keys can be distributed to a pledge by relying on CoJP (Section 5), and redistributed to current nodes in case of rekeying (Section 6.2). As to the actual switch from old to new permutation keys at the current nodes, a discussion on the list with Malisa and Michael set the ground for a good approach to work on. The last message on that topic is at [5]. At IETF 105, this work was put on hold, without proceeding to check for WG adoption as requested by the authors. The reasons were: i) possible termination of the WG later in 2019; ii) possible better belonging of this work to IEEE rather than IETF. Building on what mentioned at the mic at IETF 106 [6]: 1) I do believe that this document belongs to the IETF and its 6TiSCH WG. The described solution intervenes precisely on the original schedule, available from 6top or alternative protocols. Simply, the permuted schedule is then used instead of the original one. Hence, the proposed approach can be implemented above the MAC. 2) While IEEE 802.15.4 itself might be extended to similarly permute the schedule, there is no chance that 802.15.4 will take care of management/renewal of the necessary permutation keys. This would of course limit and endanger the whole approach altogether. Instead, in 6TiSCH we can build on CoJP and the Parameter Update message from the JRC used for link-layer traffic keys, to also provide and renew the permutation keys (see above). @Suresh: you asked about the document separating the schedule permutation from the key management. This is in fact already the case, as Section 4 describes the schedule permutation, while Section 5 describes the provisioning of the permutation keys to a pledge upon its joining. The rekeying is now discussed in the small Section 6.2. If we continue elaborating on the actual switch from old to new permutation keys (see above), that point can definitely become an earlier functional section of its own. In summary, I am not in favor of closing 6TiSCH down yet, and I would especially like to continue the work on this document, whose merits have been recognized in the list, also by three positive reviews. At the same time, as clarified above, I do believe that the IETF is its most appropriate home, at the 6TiSCH WG. Looking forward to your feedback and hopefully to progressing this work. Thanks, /Marco [1] https://gitlab.com/crimson84/draft-tiloca-6tisch-robust-scheduling/tree/master/test [2] https://mailarchive.ietf.org/arch/msg/6tisch/AmdYIZJqwnLYkzXcyejWAfPRAGw [3] https://mailarchive.ietf.org/arch/msg/6tisch/676O-xcWvHxRLjL-sSHQswS3mCk [4] https://mailarchive.ietf.org/arch/msg/6tisch/a-SyZZWVluoTf-N8ky_D7Hu4lis [5] https://mailarchive.ietf.org/arch/msg/6tisch/GdgNqNFGpcTRLCm4BI1O6BS36OE [6] https://etherpad.ietf.org/p/notes-ietf-106-6tisch?useMonospaceFont=true -- Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
