Re: [6tsch] minutes webex 5 July 2013

[Thomas Watteyne <[e-mail]>]

All,

Please find below an updated version of the minutes of last meeting.
Changes are highlighted in blue. Thanks Rene for spotting this!

This new version replaces the previous one, and is also the one archived at
https://bitbucket.org/6tsch/meetings/wiki/130705_webex.

Thomas

---

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

   - Webex recording (audio+slides,streaming)
   -
   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=69696887&amp;rKey=5ee52e950ccc11e9<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69696887&rKey=5ee52e950ccc11e9>
    *[57min]*

Slides

   - slides_130705_webex.ppt<https://bitbucket.org/6tsch/meetings/src/ceaae60071b8d2b0890c629a9fdae867c1f37391/130705_webex/slides_130705_webex.ppt?at=master>er>:
   slides shared during the call

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.
   - *[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
         - Protocol for Carrying Authentication for Network Access (PANA)
         - http://tools.ietf.org/html/rfc5191
         - Extensible Authentication Protocol(EAP) over UDP
         - two extensions:
            - in ZIP, relay element in defined
            - http://tools.ietf.org/html/rfc6345
            - http://tools.ietf.org/html/rfc6786
         - PANA stateless relay operation.
            - joining node is PaC (PANA Client)
            - parent node is PRE (PANA Relay Element)
               - PANA relay message contains joining node's IP and port,
               allow stateless relaying of PANA message
            - 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/6tsch/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/6tsch/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:
         - *[Thomas]* Updated "About 6tsch" section of
         https://www.ietf.org/mailman/listinfo/6tsch to contain link to
         bitbucket?
         - *[Pascal]* A month from now we will have a working group page so
         maybe it is not needed.
      - *[09.05]* AOB

   No additional issues raised.

   - *[09.06]* Meeting ends



On Fri, Jul 5, 2013 at 11:13 AM, Thomas Watteyne <[e-mail]
> wrote:

> All,
>
> You will find the minutes of the last webex below.
>
> FYI, all the minutes and slides are archived a
> https://bitbucket.org/6tsch/meetings/.
>
> Thanks to Xavi for taking notes!
>
> As usual, fix anything we might have missed directly in the e-mail and
> reply.
>
> Thomas
>
> ---
>
> 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
>
>    - Webex recording (audio+slides,streaming)
>    -
>    https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=69696887&amp;rKey=5ee52e950ccc11e9<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69696887&rKey=5ee52e950ccc11e9>
>     *[57min]*
>
> Slides
>
>    - slides_130705_webex.ppt<https://bitbucket.org/6tsch/meetings/src/ceaae60071b8d2b0890c629a9fdae867c1f37391/130705_webex/slides_130705_webex.ppt?at=master>er>:
>    slides shared during the call
>
> 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.
>    - *[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
>          - Protocol for Carrying Authentication for Network Access (PANA)
>          - http://tools.ietf.org/html/rfc5191
>          - Extensible Authentication Protocol(EAP) over UDP
>          - two extensions:
>             - in ZIP, relay element in defined
>             - http://tools.ietf.org/html/rfc6345
>             - http://tools.ietf.org/html/rfc6786
>          - PANA stateless relay operation.
>             - joining node is PaC (PANA Client)
>             - parent node is PRE (PANA Relay Element)
>                - PANA relay message contains joining node's IP and port,
>                allow stateless relaying of PANA message
>             - 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 lookg at the
>          system cost as a whole. Flexibility of deployment might decrease if you
>          require more expensive devices due to more strict requirements.. Not a
>          purely technical discussion.
>       - *[08.35]* Simulator
>       - *Xavi* shares his screen and presents simulator.
>       - Open-source, hosted at https://bitbucket.org/6tsch/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/6tsch/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:
>          - *[Thomas]* Updated "About 6tsch" section of
>          https://www.ietf.org/mailman/listinfo/6tsch to contain link to
>          bitbucket?
>          - *[Pascal]* A month from now we will have a working group page
>          so maybe it is not needed.
>       - *[09.05]* AOB
>
>    No additional issues raised.
>
>    - *[09.06]* Meeting ends
>
>