Clone wiki

meetings / 130705_webex

Minutes Webex 05 July 2013, 6TSCH group

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Xavi Vilajosana
  2. Thomas Watteyne

Present (alphabetically)

  1. Alfredo Grieco
  2. Guillaume Gaillard
  3. Pascal Thubert
  4. Pouria Zand
  5. Rafa Marin-Lopez
  6. Raghuram Sudhaakar
  7. Rene Struik
  8. Subir Da
  9. Thomas Watteyne
  10. Tina Tsou
  11. Xavi Vilajosana
  12. Yoshihiro Ohba

Recording

Slides

Agenda

  • Approval minutes last call [1min]
  • Update presentation esIoT [1min]
  • draft-ohba-6tsch-security-00 [10min]
  • Simulator [10min]
  • Description of PCE [10min]
  • Preparing for the BOF [25min]
  • Re-organization Bitbucket [2min]
  • AOB [1min]

Minutes

  • [08.05] Meeting starts
    • Thomas goes over the agenda.
    • Very full agenda today.
  • [08.08] Approval minutes last call
    • Thomas asks for approval last week's minutes

      no major comments. Agenda approved.

  • [08.08] Update presentation esIoT
    • Maria Rita where she presented a paper on 6TSCH at http://www.esiot.com/ in Taiwan on 07/04/2013.
    • Thomas attended through Skype.
    • Maria Rita gave an excellent overview of what 6STCH is doing.
    • Her slides are very good, can be used as a basis for further presentations.
    • Slides availble here
  • [08.10] draft-ohba-6tsch-security-00
    • Yoshihiro presents http://tools.ietf.org/html/draft-ohba-6tsch-security-00.

      This is the official presentation of the draft.

    • draft submitted 06/24/2013.
    • Background:
      • ZigBee IP CSMA/CA MAC, has a common network key shared by all nodes in the mesh.
      • TSCH uses a 5-byte ASN counter as part of the CCM* nonce.
    • This draft provides a solution for key management in 6TSCH networks
    • Key Management Framework. 3 Phase currently described in the draft, suggestion to add Phase 0:
      • P0: Commisioning. What to put in a node before deployment?
      • P1: Boostrap. Starts when device is at its final location. (Re)installs credentials used for P2 and P3. Possibly no link layer security with the neighbor node. Authentication server used by each mote. Can be multiple hops away. installs credentials for P2 or P3.
      • P2: Link establishment. Neighbor nodes do two-party authentication and key establishement. No need to contact autentication server.
      • P3: After we study the application layer requirements, we can add more information.
    • Presents example sequence on slide
      • dashed arrows show phase 1. Node 0 is Auth Server.
      • solid arrows show P2 and P3.
    • P1 and P2 KMP requirements. depending on feedback and discussion, we can revise
      • P1 requirements:
        • suport mutual authentication
        • suport stateless authentication
        • secure credential distribution
      • P2 requirements:
        • 8 requirements.
    • Yoshihiro presents slide on P2 example phase with certificates
      • each node exchanges its CCM* key
    • candidate KMPs:
      • for P1: PANA, because of several issues presented later
      • for P2: several options
        • assymetric key credentials are used.
    • PANA overview
    • recent discussion on ML:
      • EB protection
        • Need to be protected to not have attacks by forging EBs.
        • several candidate solutions.
      • multiple profiles:
        • There was a comment that solution might be too heavyweight for very constrained devices. Do we need profiles?
        • Profile A: what we have now in the draft
        • Profile B: common CCM* key. In this case, no device can be compromised. If a node is compromised, all of the keys need to be updated. Only applicable for small sized networks.
    • discussion
      • [Pascal] how are profiles used in ISA100?
      • [Rene] Not sure if remember (must check). Think asymetric and symetric keying in two separate profiles.
      • [Pascal] We want to have a superset of ISA100 does.
      • [Rene] It is important to think about the long-term requirements. We can imagine a case where only one profile is used. Not sure if realistic with the 8kB RAM requirements.
      • [Subir] Suggesting removethe 8kB requirements?
      • [Rene] We have to anticipate use cases on very large network. RAM requirements not that high for crypto. We need to look at the system cost as a whole. Flexibility of deployment might decrease if you require multiple device profiles, where less expensive devices may result in higher deployment cost (e.g., due to human involvement) and, thereby, higher system cost. Not a purely technical discussion.
  • [08.35] Simulator
    • Xavi shares his screen and presents simulator.
    • Open-source, hosted at https://bitbucket.org/6tisch/simulator
    • Added possibility for motes to re-allocate cells when collisions are detected.
    • Shows case with a 50 fully-meshed node network (i.e. neighborhood) with a random number of cells scheduled between motes. Detection is done by selecting bad cell in a bundle, and choose another cell randomly.
    • Network converges rather slowly now, but can be tuned by threshold to detect collision.
    • Measurements we can now make: how long before the schedule is collision-free? How many time we change one cell?
    • The simulator allows you to see the number of collisions for a cell.
    • Implemented different topologies, to study more realistic networks.
    • next step: want do we want to measure with this simulator?
    • discussion
      • [Pascal] we should start multiple thread on the ML. In particular one to discuss the algorithm for a node to detect that there are collision in a cell.
      • [Pascal] Interesting use case: if there are two independent 6TSCH networks in the same radio space, de-synchronized by 5ms, their cells will overlap, causing lots of schedule changes.
      • [Xavi] You're very welcome to play with the simulator and implement more features. Ticketting system (https://bitbucket.org/6tisch/simulator/issues) used to track features to be implemented
      • [Pascal] It would be nice to have a HOWTO
      • [Xavi] Code is commented. Will work on a README.
  • [08.45] Description of PCE

    This point will not be addressed during this call.

  • [08.45] Preparing for the BOF
    • Thomas presents 4 slides on http://tools.ietf.org/html/rfc5434
      • Goals of the BOF.
        • demonstrate that we have an agreement on the five points:
          • there is a problem that needs solving
          • IETF is the right place to solve it
          • we have a critical mass of people who can work on it
          • scope is well defined and understood
          • WG has a reasonable probability of having success *Preparing:
        • identify areas of agreement and disagreement
        • come up with consensus charter *Problem statement:
        • we need to go back to the charter. We have to be able to explain the problem.
        • the only goal is to show there is a problem and how we can solved
      • At the BOF
        • Agenda of the BOF has to focus on defending the need of the WG.
        • Present the problem to the public.
        • Audience needs to be convinced. We should not ask too many questions.
        • Avoid discussions about solution.
        • Avoid having too long presentation about solutions.
    • Proposed agenda (we have 1h30)
      • problem statement [30min]
        • what IEEE802.15.4e TSCH?
        • what is missing
        • quick overview of the status of the group
      • charter [30min]
        • we can follow the structure of the charter
        • [Pascal] we need to convince people that there is something that needs to be done. Convince that it can be done. show that this is a problem we can solve in a limited time.
      • drafts
        • idea is to show the activity of the group, not to discuss technical options.
    • TODO list before the BOF:
      • Ask on the ML who will be in Berlin.
      • Agree on ML who is going to talk about what during the BOF.
        • We will be looking for volunteers.
        • It would be good if Maria Rita, Xavi, Qin, could present.
      • Rehearsal at the call next week.
      • have a pre-meeting in Berlin, probably Monday afternoon or Tuesday morning.
        • quick doodle poll for meeting before meeting
      • Rename 6tus.
        • To 6top? We can have a quick call on the ML 6top seems to be good.
        • We need to do this ASAP.
      • JP Vasseur accepted to help on PCE.
  • [09.02] Re-organization Bitbucket
    • merge Orlando repo inside the meetings repo so meetings will end up being webex + ietf meetings.
    • prepare skeleton for berlin meeting.
    • Discussion:
  • [09.05] AOB

    No additional issues raised.

  • [09.06] Meeting ends

Updated