[6tisch] minutes IETF91 6TiSCH WG meeting

[Thomas Watteyne <[e-mail]>]

All,

You will find a first draft of the IETF91 6TiSCH WG meeting minutes at:
- http://www.ietf.org/proceedings/91/minutes/minutes-91-6tisch
- https://bitbucket.org/6tisch/meetings/wiki/141113_ietf91_honolulu
- copy-paste below

Please review those and reply comments to this thread.

Cut-off date for revised (final) minutes is *12/26/2014*.

Thomas

---

Minutes IETF 91 WG meeting, 13 November 2014, 6TiSCH WG

Note: timestamps in HST.
Information

Meeting        :   IETF 91 Thursday, 13 November 2014Time           :
 0900-1030 HST Thursday Morning Session I (90min)Location       :
Hibiscus room, Hilton Hawaiian Village, Honolulu, Hawaii, USAChairs
     :   Pascal Thubert <[e-mail]>
                   Thomas Watteyne
<[e-mail]>Responsible AD :   Ted Lemon
<[e-mail]>URLs           :
http://tools.ietf.org/wg/6tisch/
                   https://datatracker.ietf.org/wg/6tisch/
                   https://www.ietf.org/mailman/listinfo/6tisch
                   https://bitbucket.org/6tisch

Scribes

Etherpad (http://etherpad.tools.ietf.org:9000/p/notes-ietf-91-6tisch)

   - Dominique Barthel
   - Matthias Kovatsch

Jabber (xmpp:[e-mail])

   - Ines Robles

Resources, Recordings and LogswhatwhereWiki
https://bitbucket.org/6tisch/meetings/wiki/141113_ietf91_honoluluPresented
Slideshttps://datatracker.ietf.org/meeting/91/materials.html#6tischAudio
Recording
http://www.ietf.org/audio/ietf91/ietf91-hibiscus1and2-20141113-0900-am1.mp3
[mp3,
73MB]Meetecho Recording
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF91_6TISCH&chapter=chapter_0Jabber
Logshttp://www.ietf.org/jabber/logs/6tisch/2014-11-13.htmlAgenda

Published at https://datatracker.ietf.org/meeting/91/agenda/6tisch/.

Intro and Status                                   [3min]  (Chairs)
    Note-Well, Blue Sheets, Scribes, Agenda Bashing    6TiSCH milestones recap
Chartered Drafts                                  [35min]
    Goal: present latest changes and decide whether ready for WGLC.
    * <draft-ietf-6tisch-tsch-02>                  (5min)  (Maria Rita
Palattella)    * <draft-ietf-6tisch-minimal-03>              (15min)
(Xavi Vilajosana)    * <draft-ietf-6tisch-6top-interface-02>
(15min)  (Thomas Watteyne)
Liaison and Announcements                         [20min]
    * <draft-finn-detnet-problem-statement-01>    (10min)  (Norm Finn)
   * 6TiSCH ETSI Plugtest at IETF93              (10min)  (Miguel
Angel Reina Ortega)
Rechartering First Glance                         [10min]  (Chairs)
6TiSCH Security Discussion                        [20min]
    * <draft-richardson-6tisch--security-6top-03> (10min)  (Michael
Richardson)    *
<draft-struik-6tisch-security-architecture-elements-01>
                                  (10min)  (Rene Struik)
Any Other Business                                 [2min]

Minutes

   - attendance: ~50 people in the room, ~20 on meetecho
   - *[09.00]* Intro and Status (*Chairs*)
      - Thomas goes through the Note Well, announces scribed/jabber, hands
      out blue sheet
      - objective of the meeting:
         - Decide on WGLC stable I-Ds
         - Discuss state of WG work and re-chartering
         - Converge on security architecture
         - Announcements: detnet and 6TiSCH plugtest
      - *Thomas* presents agenda. Calls for issues and suggestions from the
      room.

      No issues raised. Agenda approved.

      - *[Pascal Thubert]* several milestones to reach in the next 2
      months. 3 drafts to go through WGLC this month.
   - *[09.05]* draft-ietf-6tisch-tsch-02 (*Maria Rita Palattella*, remotely)
      - provides information on TSCH for use in 6TiSCH
      - describes main features of MAC layer
      - Maria Rita describes the draft, history, goals, goes through the 6
      issues addressed by this new revision. This includes:
         - EB sent on same channel offset, but translates to different
         physical frequency across slot frames rotations.
         - "join priority": one byte to help the node select which network
         to join
         - several clarifications following Pascal's comments (e.g., will
         be part of 802.15.4-2015)
         - (issue #29) use of "mote" and "node" harmonized
         - highlights that changes are made following intensive discussions
         in the ML
      - *[Maria-Rita Palattella]* feels doc now stable and mature
      - *[Pascal Thubert]* announces revision in IEEE802.15.4. Proposal to
      add 2 bytes for RPL rank as a join priority. We can ask IEEE for that.
      Comments?
      - *[Mikko Saarnivala]* Should not be limited to RPL only, since there
      are other routing protocols.
      - *[Pascal Thubert]* OK. Do you think that the priority is enough?
      - *[Mikko Saarnivala]* 2 bytes will be preferable
      - *[Rene Struik]* Make sure revision will fit our needs.
      - *[Thomas Watteyne]* Please clarify.
      - *[Rene Struik]* Security behavior.
      - *[Pascal Thubert]* Study Group on security, pass on messages.
      - *[Chairs]* Who read the draft?

      6 hands raised

      - *[Thomas Watteyne]* Will request feedback on the mailing list and
      do last call after that.
   - *[09.15]* draft-ietf-6tisch-minimal-03 (*Xavi Vilajosana*, remotely)
      - *[Pascal Thubert]* this is about how to do RPL over a static
      schedule.
      - Important to finalize document quickly if want to be ready for
      plugtest next summer
      - *[Xavi Vilajosana]* status and history discussion, added security
      discussion and hop-by-hop / RPL Option compression based on 6lo
         - updated tables
         - Changed tables including default timings
         - Major change is addition of text on Security considerations (L2
         mechanism for minimal, shared keys, 6tisch draft for further details)
         - will point on the security document
      - *[Subir Das]* peer security might be use, what do you mean? MAY?
      - *[Xavi Vilajosana]* Yes, "might" should be "MAY"
      - *[Bob Moskowitz]* (chair IEEE802.15.9): IEEE802.15.9 is now in
      letter ballot. Moving toward transport. Significant issues with security
      state machine in the IEEE802.15.4 standard (e.g., frame counter), have a
      state machine on how it should work. Upcoming changes need to checked to
      understand how it works. Call for reviews. Tables are moving around in
      security PIB, needs to be reviewed. Diagram will be in there with state
      machine for inbound processing.
      - *[Thomas Watteyne]* Pat passed on some slides about the upcoming
      IEEE802.15.4 changes, available in the materials on this WG meeting. Feel
      free to review.

      http://www.ietf.org/proceedings/91/slides/slides-91-6tisch-8.pdf

      - *[Subir Das]* what do you mean "rather than a centralized one"?
      - *[Xavi Vilajosana]* refers to the mode where security is done in a
      peer-to-peer way, rather than through a centralized entity
      - *[Bob Moskowitz]* IEEE802.15.9 allows key management with
      peer-to-peer protocols.
      - *[Michael Richardson]* Security mechanisms are useless without key
      management process. There must be a "MUST be peer-to-peer". Recommend to
      not mention CCM*, etc. In this space, rather security protocols
as Bob just
      did. Say less but clearer for better interoperability.
      - *[Pascal Thubert]* This is not just IEEE802.15.4. Can be 802.1 as
      well.
      - *[Michael Richardson]* OK, then state that links that are not
      6TiSCH are not covered, and focus this document on 6TiSCH links.
      - *[Pascal Thubert]* DIO information is coming from the top, so more
      consideration is needed.
      - *[Michael Richardson]* the DODAG may extend beyond 6TiSCH, but
      don't specify their security mechanism.
      - *[Thomas Watteyne]* Chicken/egg problem between minimal and
      security design team. What is your recommendation?
      - *[Michael Richardson]* Main problem, where will minimal be
      deployed? Feels like in semi-managed network. What supporting
elements will
      be available in a minimal network? One can not have zero-touch
security in
      minimal, so keys and certificates have to be pre-configured. Can be used
      for keying for any protocol. But do not say CCM* etc. in the
minimal draft.
      - *[Bob Moskowitz]* by peer-to-peer, do you mean within radio reach?
      - *[Xavi Vilajosana]* Yes.
      - *[Bob Moskowitz]* because of fragmentation issues, IEEE802.15.9
      only works well over single radio hop.
      - <<Discussion between Michael and Bob on key management.>>
      - *[Robert Cragie]* agree with Bob, just mention "IEEE802.15.4
      securiy version X"
      - *[Xavi Vilajosana]* Agreed.
      - *[Max Pritikin]* Zero-touch must make sure we do not rely on
      pre-configured keying material.
      - *[Subir Das]* Just leave it as securing p2p.
      - *[Max Pritikin]* Need to define that key exchange happens, but not
      how it happens.
      - *[Randy Turner]* How to do this for an interop event?
      - *[Thomas Watteyne]* Agree this needs to be self-contained.
      - *[Xavi Vilajosana]* Open questions: What exactly should we do with
      security in minimal?
      - *[Chairs]* who has read the draft?

      5 hands

      - Who objects to WGLC?

      1 hand raised (Michael Richardson)

      - *[Michael Richardson]* There are still some gaps in the security
      definitions. It needs "another set of eyes" and editorial clarifications.
      - *[Pascal Thubert]* Aim for new revision in next two weeks and have
      WGLC at the end of the month.
   - *[09.40]* draft-ietf-6tisch-6top-interface-02 (Thomas Watteyne, on
   behalf of *Qin Wang*)
      - interface on how to interact with 6top layer from higher layers of
      the stack
      - Status overview, 3 changes:
         - variable types
         - monitoring
         - YANG validation and model
      - Status and history, met with the YANG doctors in Vancouver, update
      coming in a few days
      - important: we need reviewers to look at this document from the
      use-ability point of view: "if I have this interface, can I manage a TSCH
      network?"
      - changing the model once published is extremely difficult, attention
      should be taken at the maximum to do it right first hand
      - no security-related element for now, chicken and egg problem
      - *[Randy Turner]* These look like 15.4 MIB things. Exposing these
      blindly might not make sense in this forum.
      - *[Bob Moskowitz]* Current MAC PIB has some errors. Security is an
      upper-layer responsibility, which pushes decisions back down to use with
      individual packets. Information must be exposed to make
decisions. In your
      document, you have to say how you use it and how you want it to work,
      otherwise no interop.
      - *[Michael Richardson]* If I pick HIP are there still elements
      missing and HIP needs provisioning?
      - *[Bob Moskowitz]* no the KMP that makes this decisions. e.g.
      security level is a local policy (or maybe could be exchanged). Key index
      needs to be exchanged.
      - *[Michael Richardson]* Things that should be put in: identity to
      assert, public key/cert to use, protocol to use (HIP, IKE, ..). Do not
      specify when to re-key (lots of interop problems in the past). Should go
      through your interface: who you are, how you prove it, and how you
      communicate with your peers;
      - *[Rene Struik]* Puzzled by this discussion. 15.4 uses PSK. There is
      no dependency on public keys, identities, etc.
      - *[Thomas Watteyne]* How much do we provide a central entity
      (PCE/JCE). Conclusion: not blindly exposing, wait for security team.
      - *[Bob Moskowitz]* disagree with Rene, yet we are converging.
      KeyIdMode does not need to be exposed if policy is.
      - *[Thomas Watteyne]* good feedback, we know now what we should do.
      - *[Subir Das]* Is 6top layer trying to do the security management?
      - *[Thomas Watteyne]* Yes.
      - *[Subir Das]* If 6top is also going to do security management. This
      should be done differently.
      - *[Thomas Watteyne]* 52 MAC PIB attributes, which one to expose?
      will come up with the right selection.
      - *[Bob Moskowitz]* Yes, cross off none and all.
      - *[Thomas Watteyne]* lots of notions (soft cells, chunks, tracks,
      labels). They all take up resources in the nodes (RAM space,
etc). Shall we
      assume they are all present at all times? Or options.
      - *[Bob Moskowitz]* You should aim for modularity.
      - *[Michael Richardson]* What is the YANG feature?
      - *[Thomas Watteyne]* Discovery mechanism for the supported features.
      Features are like labels that identify supported functionalities.
      - *[Michael Richardson]* Minimal draft should specify what are the
      set of features that are mandatory.
      - *[Michael Richardson]* Querying for features can be cached, the PCE
      has plenty of energy. Unless there is a cost for having features that I
      don't see, you should have many features.
      - *[Randy Turner]* Is there another management entity to worry about?
      Especially coherency issues.
      - *[Thomas Watteyne]* good meeting with/about COMAN yesterday,
      multiple entities can be managing the nodes, they can live at different
      resources.
      - *[Bob Moskowitz]* What is the potential overlap with CoAP resource
      discovery?
      - *[Carsten Bormann]* all nodes that implement a resource discovery
      will offer the resources it provides. Discussed yesterday about
CoMI draft:
      2 Step sequence: 1-running the resource discovery .well-known, 2-go to
      <...> we are not going to have a lot of entry points.
      - *[Pascal Thubert]* those features do not prevent us from having the
      right design from the beginning. We have to do things right, even if we
      have features. What is in the data model needs to be supported later on,
      very difficult to remove.
      - *[Samita Chakrabarti]* Security DT is addressing common 15.4. If
      this is the case, this should leave at 6LoWPAN as this is more general.
      Offers to review and work together in the scope of both 6lo and 6TiSCH.
      - *[Thomas Watteyne]* The list in the slide is just a copy of all
      15.4 attributes, meant FYI.
      - *[Thomas Watteyne]* What should the protocol be to interact with
      the YANG model? Centralized: 6tisch-coap, core-comi, Distributed:
      neighbor-to-neighbor CoAPIE
      - Conclusion: Requests feedback from implementers.
      - *[Pascal Thubert]* who thinks this is not ready (after next
      revision) to go for last call?

      No hands raied.

      - *[Pascal Thubert]* Should there be a way to conserve bandwidth, an
      on/off button to enable a second slot in the -minimal slotframe
      - *[Thomas Watteyne]* Already possible through
      activatate/deactivating a second frame, it's already in the YANG model.
   - *[10:18]* draft-finn-detnet-problem-statement-01 (*Norm Finn* and *Pascal
   Thubert*)
      - held a BoF about DETNET (deterministic networking) on Monday

      http://tools.ietf.org/bof/trac/wiki/DetNet

      - goal is to reserve resource along a path. Requirement is
      reliability in the order of 10E-10, not possible on a single
existing link.
      Needs redundancy.
      - we probably need a controller to organize that. ISA100 and
      WirelessHART have this, controller learns about the links, pushes
      information into the nodes (label switching, for example)
      - not clear if something needs to be done between receiver and
      controller, between controller and end-points, etc.
      - one way is to have the path install itself from the end point, a la
      CCAMP
      - another way is have the controller talk to all devices involved in
      the path, directly.
      - next steps: decide to adopt the centralized architecture, flows
      from/to this controller.
      - It is about deterministic networks, so we go "down to the metal",
      close to the PHY, the buffers, etc
      - we should understand what DETNET is doing, inherent the results and
      use them in 6TiSCH mechanisms.
   - *[10:29]* 6TiSCH ETSI Plugtest at IETF93 (*Miguel Angel Reina Ortega*,
   remotely)
      - Miguel Introduces ETSI and ETSI plugtests
      - ETSI set globally applicable standards, non-for-profit
      organization, 700 members
      - "Center for Interoperability Testing" (CTI) active in many
      technologies, already partnered for CoAP and 6LoWPAN.
      - ETSI Plugtests enable to disambiguate standard text. Not
      commercial, free of charge. Some fees to recover costs. Founded
by European
      Commission (EC).
      - open to anyone who wishes to participate, to validate a standard.
      Results are reported to EC in anonymous fashion, NDA in place.
      - *[Alex Petrescu]* Industry does have strong interest to protect
      themselves through NDAs, but a side-effect is that people do not
talk about
      results. Is there a way to get the test results? Is it true that the
      results are under NDA?
      - *[Miguel Angel Reina Ortega]* The feedback with all issues and
      recommendations is fed back in an anonymous way and available.
Waiving the
      NDA is also possible.
      - *[Carsten Bormann]* we had plugtest from ETSI test that drove
      update. Really valuable. Same goes for 6LoWPAN plugtest.
      - *[Alex Petrescu]* different situations I expect, OK.
      - *[Miguel Angel Reina Ortega]* on organisation. Announce first
      6tisch plugtest. Targets IETF 93, 17--19 July 2015 (Thomas: do not book
      flights yet, not 100%)
      - *[Samita Chakrabarti]* There is also a 6lo plugtest planned, do you
      want to comment?
      - *[Miguel Angel Reina Ortega]* Yes, it is discussed, but not sure
      whether should be co-located with 6TiSCH or rather independent.
      - *[Samita Chakrabarti]* Let's take this discussion offline, together
      with 6TiSCH chairs; we have worked together before.
      - *[Pascal Thubert]* Big step up from the Plug*f*est , since
      Plugtests have higher quality and testing standards
   - *[10:52]* Rechartering First Glance (*Pascal Thubert*)
      - emphasizes original charter has "RPL routing over static schedule".
      - reviews charter milestones. Tight, but pretty much on track.
      December has "evaluate WG progress, propose new charter".
      - *[Bob Moskowitz]* IEEE802.15.10 produces a merged document, on
      mentor. Look at it and see if it applies to 6TiSCH.
      - *[Subir Das]* "architecture" doc. Is it done or which version is it
      done on?
      - *[Michael Richardson]* Work is not done, it started. Positive
      feedback might not be that useful, but negative feedback will
help to make
      the right choices.
      - security work is not chartered but is going strong
      - 6top layer management with CoAP, not chartered.
      - discussion going on on the mailing list regarding dynamic scheduling
      - *[Rene Struik]* Shouldn't there be more security drafts?
      - *[Thomas Watteyne]* Yes, typo on this slide, sorry.
      draft-struik-6tisch-security-architecture-elements for example will be
      presented later.
      - Promise of 6TiSCH was deterministic networking. Now DetNet ML
      started, looks at a broader picture. Pieces missing. Does the WG
believe we
      are ready to take up this new task?
      - *[Ted Lemon]* This WG has the clear need for this work. Flipping it
      over to DetNet might be a problem. You could investigate the items right
      now.
   - *[11:06]* draft-richardson-6tisch--security-6top-03 (*Michael
   Richardson*)
      - Michael asked in Toronto whether to take inspiration from ZigBee or
      WirelessHART (through application-level protocol). We are
looking at a push
      model, CoAP/DTLS-based.
      - Goal is to have a trust anchor. Network operator can recognize its
      nodes.
      - zero-touch operation. Other models possible through configuration.
      - Well-known beacon key encrypted (in a well-known way) to make sure
      it is 6TiSCH traffic
      - reserved join traffic slots to handle traffic by still unauthorized
      joining nodes (via join assistant)
   - *[11:16]* draft-struik-6tisch-security-architecture-elements-01 (*Rene
   Struik*)
      - use slides to see status updates
      - Network joining: focus on desired properties instead of flows
      - Mitigation of DoS attacks very important, since joining causes
      traffic over multiple hops
      - normal way to join network has 6 exchanges between node and router,
      and 4 between router and server. Want to optimize that: proposes
mechanism
      that has 5 and 2 respectively. Made possible by caching node info into
      router by server, requires occasional pushes.
      - Trades communication costs for memory for cached server information
      on the routers.
      - Focus is to get a protocol that is easy to analyze from a security
      point of view.
      - *[Sandeep Kumar]* Do you get PFS with the cache mode?
      - *[Rene Struik]* Not entirely, depends on whether you are on client
      of server side.
      - *[Sandeep Kumar]* Does the caching depend on the manufacturer? Are
      you caching all manufacturer's certificates?
      - *[Rene Struik]* No, caching is from JCE. JCE certificate needs to
      be on routers.
      - *[Max Pritikin]* We dropped the authentication of the router to
      check the node joins the correct network?
      - *[Rene Struik]* True, we need to authenticate both ways.
      - *[Pascal Thubert]* we have to cut the mic line.
   - *[11:31]* Any Other Business
      - *[Thomas Watteyne]* Slides available which summarize the
      IEEE802.15.4-2015 changes

      http://www.ietf.org/proceedings/91/slides/slides-91-6tisch-8.pdf

      - *[11:33]* Meeting ends.