Clone wiki

meetings / 190325_ietf104_prague

Minutes, IETF 104 6TiSCH WG Meeting

Note: these minutes are formatted using Markdown

Agenda and Meeting information

Meeting        :   IETF104 Monday, March 25, 2019 (CET)
Time           :   11:20-12:20 Monday Morning session II (60min)
Location       :   Congress Hall 3, Hilton Prague
Chairs         :   Pascal Thubert
                   Thomas Watteyne
Responsible AD :   Suresh Krishnan
Live minutes   :
Live feeds     :

Other URLs     :

11:20 Intro and Status                       (Chairs)            [10mn] 
   * Note-Well, Blue Sheets, Scribes, Agenda Bashing
   * Status Documents
   * Status 6lo / ROLL
   * Milestones
   * Action Plan

11:30 Architecture
   * draft-ietf-6tisch-architecture         (Pascal Thubert)    [ 5mn] 

11:35 Minimal Security
   * draft-ietf-6tisch-minimal-security     (Malisa Vucinic)    [10mn] 

11:45 Dynamic Scheduling
   * draft-ietf-6tisch-msf                  (Tengfei Chang)     [10mn] 
   * draft-tiloca-6tisch-robust-scheduling  (Marco Tiloca)      [ 5mn]

12:00 Misc
   * OpenBenchmark - Continuous delivery benchmarking for 6TiSCH 
                                            (Bozidar Skrbic)    [ 5mn] 
   * Showing the outcome from hackathon     (Tengfei Chang)     
                                            (Malisa Vucinic)    [ 5mn]
12:10 Michael's drafts
   * draft-ietf-6tisch-enrollment-enhanced-beacon               [ 5mn] 
   * draft-ietf-6tisch-dtsecurity-zerotouch-join                [ 5mn]

Any Other Business                          (Chairs)            [ QS ]



  • notetaker 1: Dominique Barthel
  • notetaker 2: Fabrice Theoleyre
  • notetaker 3: Xavi Vilajosana
  • Jabber scribe: Tengfei Chang

Action items

  • Pascal and Suresh to discuss the status of draft-ietf-6tisch-architecture; it is now Proposed Standard, may change.
  • Tengfei to publish a new version of draft-ietf-6tisch-msf. Target deadline: 8 April 2019.
  • Yasuyuki Tanaka, Thomas Watteyne, Fabrice Theoleyre to review new version of draft-ietf-6tisch-msf after Tengfei publishes it. Target deadline: 23 April 2019.
  • Xavi Vilajosana, Tengfei Chang, Pascal Thubert to review draft-tiloca-6tisch-robust-scheduling. Target deadline: 25 April 2019.


(This summary is also posted in the INT area wiki,

During IETF104, the 6TiSCH WG had a WG meeting, and participated in the hackathon.

The WG meeting covered 6 drafts:

  • draft-ietf-6tisch-architecture has received early reviews. Input during the WG meeting was that the use of terminology should be more homogeneous. Suresh Krishnan asked to discuss with Pascal Thubert the intended status of the draft.
  • draft-ietf-6tisch-minimal-security has just passed a second WGLC. During this, an issue was raised, for which the Malisa Vucinic (editor) proposed 3 possible resolutions. Malisa Vucinic and Goran Selander (reviewer) will work together on a resolution, which Malisa will implement. Once the new version of the draft is published, the WG will push it to the IESG.
  • draft-ietf-6tisch-msf has received comments from 3 review. Tengfei Chang will publish a new version of the draft which integrates those comments, after which Yasuyuki Tanaka, Thomas Watteyne and Fabrice Theoleyre have agreed to review it. Once those reviews are integrated, a WGLC will be issued.
  • draft-tiloca-6tisch-robust-scheduling was presented for the second time to the WG, and now integrates changes from the previous presentation. Marco Tiloca asked for reviews: Xavi Vilajosana, Tengfei Chang and Pascal Thubert volunteered to do a review within a month.
  • An update of draft-ietf-6tisch-dtsecurity-zerotouch-join was presented by Michael Richardson, who flags the fact that some of that work is blocked by the fact that the EDHOC draft still doesn't have a home.
  • Michael Richardson also presented draft-ietf-6tisch-enrollment-enhanced-beacon. Author Diego Dujovne will edit the introductory text of the draft (which has been stable), after which a WGLC will be issued.

The WG meeting also highlighted three implementation-related elements:

  • the hackathon, to which the 6TiSCH WG participated with the OpenWSN implementation (, which now contains a dashboard to extract the implementation's performance
  • the 6TiSCH Open Data Action ( which aims at providing clear, unbiased, and continuous benchmarking of 6TiSCH implementations on institutional testbeds
  • the 6TiSCH simulator (, which implements the full stack; the latest release (1.1.9) was done at the IETF and comes with a nice UI


  • [11.21, expected 11.20] Meeting starts
    • Thomas reads the Note Well
    • Michael's presentation moved to the back of the agenda compared to the agenda slide shown.
      • online agenda up-to-date, only slide is outdated
    • Since IETF 103, several parts of the work has progressed out of 6TiSCH. RFC8505 has been published, OSCORE was accepted, EDHOC is still stalled.
    • Work at 6lo progressing rapidly, several drafts at last call. AP-ND passed WGLC.
    • Milestones. Still late, but not much.
    • Zero-touch late. Looking for co-authors to work on that.
    • Discussion about architecture. Reviewers comment about readibility of the draft. It is pointed that a next round of review is required.
    • Terminology and architecture have been merged
    • Suresh Krishnan: The detnet doc is stuck as it is being pushed to the standards track. Same may happen to the 6TiSCH architecture. To find a resolution.

      Action item: Pascal and Suresh to discuss the status of draft-ietf-6tisch-architecture; it is now Proposed Standard, may change.

  • [11:25, expected 11.25] draft-ietf-6tisch-architecture (Pascal Thubert)
    • Goal of architecture is to provide a high level architecture and positioning of components.
    • Some actions after reviews have caused reshuffling and reorganization of the draft.
    • Question is whether terminology document has to be merged to architecture.
    • Suresh: would like to have terminology in the same document as architecture.
    • Eliot Lear: reviewed the draft. The issue is that terms are being defined at the beginning and then somehow redefined in the text. Pascal did a review and this improved.
    • references should go to the back. The terminology references are at the beginning. According to Eliot Lear they should be at the end.
    • Pascal: if one wants to understand text, need to reed references before, that's why put upfront.
    • Eliot: readers are expected to chase the references down in the back.
    • Feedback from other readers is requested. Regarding section terminology.
    • Suresh: make sure that the terms are all there.
    • Next step for Pascal: remove the external references from terminology section. Extract terms needed from there
    • Suresh: correct; List terms in terminology section and point at definition in other documents
  • [11.36, expected 11.35] draft-ietf-6tisch-minimal-security (Malisa Vucinic)
    • discussion major issue brought up at the ML by Goran Selander.
    • version 9 published after Bangkok: quick summary here of the changes
    • OSCORE has been approved by IESG. There was a heavy dependency to minimal security.
    • added a parameter join rate. used by JRC to control the emission of EBs. To control the start/stop process of the network.
    • clarified use of blacklist.
    • Malisa goes through Goran's comments.
    • updated reference to section 7.5.1 at OSCORE to appending B.1.1
    • Issue brought up by Jim Schaad.
    • There is a failure possibility of the JRC. If the mutable parameters stored in the JRC are lost, while still the Database with the keys and node id are accessible.
    • The new nodes have preserved the mutable parameters. So there is a mismatch between JRC and Pledge nodes. Possible nonce reuse attack.
    • explains the case using a message sequence drawing. Failure of JRC, with PSKs preserved but sequence numbers are lost. Opens opportunity for replay attack.
    • attacker can replay initial join request, sent it to the JRC. if the JRC accepts it, the JRC cannot detect that reply. The JRC will respond and result on a nonce reuse. Losing confidentiality property.
    • 3 options described:
      • 1) challenge-response based on OSCORE as appending B.2 describes (one additional round-trip)
      • 2) design of a custom sequence number sync mechanism. Custom for 6TiSCH. additional round-trip.
      • 3) require that mutable parameters are stored together with immutable parameters. At every update they must be stored in the database.
    • Question to the WG regarding point 3, should this be used? is it realistic?
    • Thomas (contributor): you're saying option 2 does not provide enough advantage compared to 1 or 3?
    • would be custom to 6TiSCH and would require more security reviews.
    • Thomas: option 3 means if JRC fails, need to reprovision all motes. Is this correct?
    • correct.
    • Thomas: option 1 requires additional code, additional footprint, additional time to download.
    • correct.
    • Thomas: can we make option 1 optional?
    • Thomas: Do we need SHA1 or we can use other mechanism such as AES for the HKDF procedure?
    • Goran indicated that HKDF can rely on AES to save the SHA 2 code footprint by putting a wrapper to AES.
    • Goran Selander: HDKF algorithms shown in in table 12 of RFC8152.
    • Peter Van der Stock: why not find the highest used sequence number by asking all nodes?
    • Malisa: This is option 2.
    • Thomas: suggests to continue discussion on the ML.
  • [11.52, expected 11.45] draft-ietf-6tisch-msf (Tengfei Chang)
    • Clarified use of shared and non-shared autonomous cells
      • presentation of the non shared vs. shared autonomous cells for Join/6P Response/Request packets.
    • list of pending issues presented. Still there are few issues to be discussed.
    • During the join process the allocation of a autonomous cell. A malicious user may change EUI64 and try to fill in the memory/schedule of the JP with autonomous cells.
    • Malisa: in minimal security, we say that a separate entry should be allocated for nodes trying to join. Just reference that text.
    • Yatch: the join request will fill up the schedule anyways (memory). You need to mention this in the security considerations.
    • ok, will be addressed.
    • Malisa: Yatch saying the text generic enough so that pledge can be considered just a new neighbor.
    • Trickle timer with rate limiting is not clear how to be implemented. This will be changed by the trickle timer.
    • MSF version 02 implemented in the last OpenWSN version (REL-1.24.0). 40 mote running in Inria building in Paris.
    • Thomas: suggest to integrate comments, push new version and we'll go for WGLC.

      Action item: Tengfei to publish a new version of draft-ietf-6tisch-msf. Target deadline: 8 April 2019.

    • Pascal, calls for 2 reviewers once the next version is published.

      Action item: Yasuyuki Tanaka, Thomas Watteyne, Fabrice Theoleyre to review new version of draft-ietf-6tisch-msf after Tengfei publishes it. Target deadline: 23 April 2019.

  • [12.03, expected 11.55] draft-tiloca-6tisch-robust-scheduling (Marco Tiloca)
    • this draft is about an attack and its countermeasure. Attack is selective jamming, low-power and stealth.
    • As 6TiSCH is today, an attacker can learn the cell schedule easily and can launch a selective attack (already presented in Bangkok).
    • updates from -00 as a response of the questions/comments received in the previous IETF meeting
    • clarified adversary model.
    • Updated the key provisioning using the latest minimal security procedure
    • Need for reviews
    • Thomas: who read the draft? 10 hands
    • Thomas: who's willing to review?

      Action item: Xavi Vilajosana, Tengfei Chang, Pascal Thubert to review draft-tiloca-6tisch-robust-scheduling. Target deadline: 25 April 2019.

  • [12:08] Thomas, we need to do some real-time reordering of the agenda.
    • Hackathon report will go last.
  • [12.08, expected 12.00] OpenBenchmark (Bozidar Skrbic)
    • Motivation, there are many papers that evaluate 6TiSCH, but fail to provide realistic operation scenarios
    • Desire for constant performance evaluation as the standard evolves: reliable tool to compare implementations
    • all experimentation should be based in tests scenarios. Try to mimic real world scenarios
      • SODA project.
      • Define KPIs
      • Environment and conditions/ configuration should mimic real scenarios
      • Expose REST API and GUI
      • Automated tests, continuous integration, etc.
    • 3 different scenarios: home / building / industrial automation
    • 3 platforms (Ghent, Inria Saclay, Inria Paris)
    • more info at
  • [12.13, expected 12.15] draft-ietf-6tisch-dtsecurity-zerotouch-join (Michael Richardson)
    • Goal is to use protocols from other WGs.
    • BRSKI-19 responds to all WGLC requests
    • EST-COAPS document passed WGLC
    • EDHOC, no home for it. secdispatch interim was 2 weeks ago. No information about what is the progress on that direciton.
    • this parts are needed for a zerotouch document.
    • Looking for help/co-author.
    • Malisa: blocked by EDHOC. To decide if we go for DTLS path.
    • DTLS is too complex, packets are too long. Process is too slow. Trigs retransmit timers.
    • Malisa: Would be useful to have support from Security area and AD to progress in this work.
    • Goran: does not know results from secdispath. There will be news soon.
  • [12.13, expected 12.10] draft-ietf-6tisch-enrollment-enhanced-beacon (Michael Richardson)
    • received comments
    • posted a new document
    • content of EB is stable. How much intro text is needed? how much is needed to motivate.
    • Pascal: review from the room and the WGLC.
    • Diego is going to do introductory text. Problem so far not well described.
    • Pascal: the ROLL document describes the problem. Just point at that.
  • [12.20, expected 12.05] Hackathon (Tengfei Chang, Malisa Vucinic)
    • Update about hackathon
    • OpenWSN+SODA Bechnmark
    • Benchmark server configures motes remotely, sends packets
    • implemented performance benchmark for MSF. Dashboard available online from the link provided in the slides.
    • see
  • [12.22, expected 12.20] Any Other Business
    • No time.
  • [12.23, expected 12.20] Meeting ends