Subject: [6tsch] minutes webex 5 July 2013

From: Thomas Watteyne <[email-masked]>
Date: Fri, 5 Jul 2013 11:13:19 -0700

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>:
   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

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 7 Jul 2013 19:10:36 -0700

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

---

Note: timestamps in PDT.

   1. Xavi Vilajosana
   2. Thomas Watteyne

   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

Minutes

         RAM requirements not that high for crypto. We need to look at
the system
         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.

   - *[09.06]* Meeting ends

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

>       - Key Management Framework. 3 Phase currently described in the
>       draft, suggestion to add Phase 0:
>          security with the neighbor node. Authentication server used by each mote.
>          authentication and key establishement. No need to contact autentication
>          server.
>             compromised. If a node is compromised, all of the keys need to be updated.
>          - *[Rene]* Not sure if remember (must check). Think asymetric
>          and symetric keying in two separate profiles.
>          requirements. We can imagine a case where only one profile is used. Not
>          - *[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
>       - 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.
>          particular one to discuss the algorithm for a node to detect that there are
>          collision in a cell.
>          6TSCH networks in the same radio space, de-synchronized by 5ms, their cells
>             - *[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
>             - To 6top? We can have a quick call on the ML 6top seems to
>             be good.
>       - merge Orlando repo inside the meetings repo so meetings will end
>       up being webex + ietf meetings.
>          - *[Pascal]* A month from now we will have a working group page
>          so maybe it is not needed.
>       - *[09.05]* AOB
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 9 Jul 2013 07:59:15 +0000

Thomas,  thanks as usual for the minutes. Having missed the call, it allowed me to keep tuned ;)

I have some comments/questions about the BoF in Berlin, in details about  the following points of the last call:
*        >>It would be good if Maria Rita, Xavi, Qin, could present.
*        [MR] I will be glad to present, if you think I am the right one :) According to the suggested agenda (copied below), for sure I could take care of 1.a (and provide an overview of 15.4e TSCH) - and 1.d (if needed).
*        Does this work for you?
****************************************************
1.      problem statement [30min]

     *   what is IEEE802.15.4e TSCH? (a key to deterministism and scalability)    10mn
     *   what is missing? (mostly the cement as opposed to the building blocks)  15mn
     *   Why is this a problem? (multiple proprietary solutions, costly, limited scope) 3mn
     *   Status of 6TSCH group  (drafts, ML audience, calls, tracking with BB ...)  2mn

  1.  discussion of the charter [30min]

     *   background and introduction (existing work demonstrates feasibility) 5mn
     *   description of WG (we have participants skilled in the art)                   5mn
     *   work items (we reuse as much as we can from existing IETF work)    10mn
     *   non-milestone work items (we demonstrate our will to coexist within regulations) 2mn
     *   external work to other WG (6MAN, PCE, ROLL?)  3mn
*        ******************************************************************************
*        >> have a pre-meeting in Berlin, probably Monday afternoon or Tuesday morning.
*        [MR] It will be great if we can  fix ASAP when we want to meet because I  want to make sure I am around when needed. I am planning a 2-days trip (29-30 July).  Unfortunately I cannot stay in Berlin for the whole week.
*        >>Rename 6tus. To 6top? We can have a quick call on the ML 6top seems to be good. We need to do this ASAP.
*        [MR] we need to agree on the name ASAP, because I will have to update also the terminology draft, before publishing the new version.
*
*        Thank you!
*        Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Monday, July 08, 2013 4:11 AM
To: 6TSCH
Subject: Re: [6tsch] minutes webex 5 July 2013

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

---

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>: 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

*        [09.06] Meeting ends

On Fri, Jul 5, 2013 at 11:13 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
All,

FYI, all the minutes and slides are archived a https://bitbucket.org/6tsch/meetings/.

As usual, fix anything we might have missed directly in the e-mail and reply.

Thomas

---

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>: 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

*        [09.06] Meeting ends

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 9 Jul 2013 18:25:07 +0200

Maria Rita,

Thank you for the quick reply, and offering to cover 1.a, and maybe 1.d.

As for the pre-meeting, I agree, let's wrap up the date ASAP, certainly by
this week's call.

Finally, let me send a final call for the rename of 6tus to TOP to the ML.

Hello from the Paris airport,
Thomas

On Tue, Jul 9, 2013 at 9:59 AM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Thomas,  thanks as usual for the minutes. Having missed the call, it
> allowed me to keep tuned ;)****
>
> ** **
>
> I have some comments/questions about the BoF in Berlin, in details about
> the following points of the last call:****
>
> **·        **>>It would be good if Maria Rita, Xavi, Qin, could present.**
> **
>
> **·        **[MR] I will be glad to present, if you think I am the right
> one J According to the suggested agenda (copied below), for sure I could
> take care of 1.a (and provide an overview of 15.4e TSCH) – and 1.d (if
> needed).****
>
> **·        **Does this work for you?****
>
> ********************************************************
>
> 1.      problem statement [30min] ****
>
>     1. what is IEEE802.15.4e TSCH? (a key to deterministism and
>       scalability)    10mn****
>       2. what is missing? (mostly the cement as opposed to the building
>       blocks)  15mn****
>       3. Why is this a problem? (multiple proprietary solutions, costly,
>       limited scope) 3mn****
>       4. Status of 6TSCH group  (drafts, ML audience, calls, tracking
>       with BB …)  2mn ****
>
>   ****
>
>    1. discussion of the charter [30min] ****
>
>
>     1. background and introduction (existing work demonstrates
>       feasibility) 5mn****
>       2. description of WG (we have participants skilled in the
>       art)                   5mn****
>       3. work items (we reuse as much as we can from existing IETF
>       work)    10mn****
>       4. non-milestone work items (we demonstrate our will to coexist
>       within regulations) 2mn****
>       5. external work to other WG (6MAN, PCE, ROLL?)  3mn ****
>
>  **·        **
> ******************************************************************************
> ****
>
> **·        **>> have a pre-meeting in Berlin, probably Monday afternoon
> or Tuesday morning.****
>
> **·        **[MR] It will be great if we can  fix ASAP when we want to
> meet because I  want to make sure I am around when needed. I am planning a
> 2-days trip (29-30 July).  Unfortunately I cannot stay in Berlin for the
> whole week.****
>
> **·        **>>Rename 6tus. To 6top? We can have a quick call on the ML
> 6top seems to be good. We need to do this ASAP.****
>
> **·        **[MR] we need to agree on the name ASAP, because I will have
> to update also the terminology draft, before publishing the new version.**
> **
>
> **·        **** **
>
> **·        **Thank you!****
>
> **·        **Maria Rita****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Monday, July 08, 2013 4:11 AM
> *To:* 6TSCH
> *Subject:* Re: [6tsch] minutes webex 5 July 2013****
>
> ** **
>
> All,****
>
> ** **
>
> 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)****
>
> **·        **
>  *[57min]*****
>  Slides****
> **·        **slides_130705_webex.ppt<https://bitbucket.org/6tsch/meetings/src/ceaae60071b8d2b0890c629a9fdae867c1f37391/130705_webex/slides_130705_webex.ppt?at=master>:
> 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.
> Can be multiple hops away. installs credentials for P2 or P3.****
>
> **·        **P2: Link establishment. Neighbor nodes do two-party
> 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
> 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
> 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
> 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.
> 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
> 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
> 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
> 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 <
> [email-masked]> wrote:****
>
> All,****
>
> ** **
>
> You will find the minutes of the last webex below.****
>
> ** **
>
> https://bitbucket.org/6tsch/meetings/.****
>
> ** **
>
> Thanks to Xavi for taking notes!****
>
> ** **
>
> 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)****
>
> **·        **
>  *[57min]*****
>  Slides****
> **·        **slides_130705_webex.ppt<https://bitbucket.org/6tsch/meetings/src/ceaae60071b8d2b0890c629a9fdae867c1f37391/130705_webex/slides_130705_webex.ppt?at=master>:
> 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.
> Can be multiple hops away. installs credentials for P2 or P3.****
>
> **·        **P2: Link establishment. Neighbor nodes do two-party
> 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
> 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
> sure if realistic with the 8kB RAM requirements.****
>
> **·        ***[Subir]* Suggesting removethe 8kB requirements?****
>
> **·        ***[Rene]* We have to anticipate use cases on very large
> 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.
> 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
> 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
> 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
> 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****
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>