[6tisch] minutes IETF97 6TiSCH WG meeting

[Thomas Watteyne <[e-mail]>]

All,

Please find below the minutes of the 6TiSCH WG meeting @IETF97.

The full minutes are also published at
https://bitbucket.org/6tisch/meetings/wiki/161117_ietf97_seoul and
https://datatracker.ietf.org/doc/minutes-97-6tisch/.

The summary is p[ublished at https://trac.ietf.org/trac/int/wiki/IETF97.

Please raise anything we might have missed.

We will approve these minutes at the next interim meeting (date to be
annouced soon).

The chairs.

----

Minutes, IETF 97 6TiSCH WG MeetingAgenda and Meeting information

Meeting        :   IETF97 Thursday, November 17, 2016 (KST) Time
    :   9:30-11:00, Thursday Morning session I Location       :   Park
Ballroom 1, Conrad SeoulChairs         :   Pascal Thubert
<[e-mail]>
                   Thomas Watteyne
<[e-mail]>Responsible AD :   Suresh KrishnanURLs
    :   http://tools.ietf.org/wg/6tisch/
                   https://datatracker.ietf.org/wg/6tisch/
                   https://www.ietf.org/mailman/listinfo/6tisch
                   https://bitbucket.org/6tisch
Intro and Status                              [5min] (Chairs)

   Note-Well, Blue Sheets, Scribes, Agenda Bashing
New charter and status docs                   [10min] (Chairs)

   * Status minimal, 6LoRH, 802.15 IE
   * Milestones
Dynamic Scheduling

   * <draft-ietf-6tisch-6top-protocol>                [20min]
     (Xavier Vilajosana)

   * <draft-ietf-6tisch-6top-sf0>                     [15min]
     (Diego Dujovne via meetecho)
Security

   * <draft-vucinic-6tisch-minimal-security>          [15min]
     (Malisa Vucinic)

   * <draft-richardson-6tisch-dtsecurity-secure-join> [20min]
     (Michael Richardson)
Any Other Business                                     [5min]
     (Chairs)

Resources

   - agenda: https://datatracker.ietf.org/meeting/97/agenda/6tisch/
   - presented slides: (
   https://datatracker.ietf.org/meeting/97/session/6tisch/
   - recording audio+video+chat:
   http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_6TISCH&chapter=chapter_1

Summary

*This summary is also posted in the INT area
wiki, https://trac.ietf.org/trac/int/wiki/IETF97
<https://trac.ietf.org/trac/int/wiki/IETF97>.*

The Working Group meeting went smoothly and according to agenda,
started and completed in time.
A status was given on related work in other WG and at the IEEE.
It is expected that the IETF IE identifier will be granted.

About draft-ietf-6tisch-minimal.
A recommendation to remove well known keys and a todo to ask for an
early sec dir review.

About draft-ietf-6tisch-6top-protocol.
Got new implementers feedback, asking limited changes.
The work depends on the allocation of an IETF IE by the IEEE ANA.
draft-kivinen-802-15-ie, the draft that presents the need and the
expected utilization of an IETF IE, is mostly complete and due to IESG
telechat in a few weeks.
Once the request is posted to IEEE, we can expect a rapid turn-around
and that the IETF IE will be granted before YE2016, which matches the
expected date for WGLC for this document.

About draft-ietf-6tisch-6top-sf0.
A few questions are still open, such as the source of the time slots
that are to be granted.
Chairs to do a formal request to have feedback from implementers.

About draft-vucinic-6tisch-minimal-security.
New draft describing the end of the join process once the key is obtained.
Depends on work at CORE on OSCOAP.
Will be integrated as the second phase of the 6TiSCH join.
No opposition to WG adoption in the room, chairs to call for adoption on the ML.

About draft-richardson-6tisch-dtsecurity-secure-join.
Work of the security design team, well advanced.
Inherits from ANIMA, and can be seen as the first and optional phase
of the join process.
One critical decision remains to be made, whether the FSM is in the
JCE or in the device.
No opposition to WG adoption in the room, chairs to call for adoption on the ML.

Action items

   - Chairs to call for implementation and feedback for
   draft-ietf-6tisch-6top-sf0.
   - Chairs to call for adoption of the security drafts
   (draft-vucinic-6tisch-minimal-security,
   draft-richardson-6tisch-dtsecurity-secure-join)
   - WG to Consider progressing the terminology so unblock minimal.
   - AD to ask for an early sec dir review of draft-ietf-6tisch-minimal.

Volunteers

   - notetaker 1: Dominique Barthel
   - notetaker 2: Geraldine Texier
   - notetaker 3: Francesca Palombini (promoted!)
   - notetaker 4: Alexander Pelov
   - notetaker 5: Tero Kivinen
   - notetaker 6: Xavi Vilajosana
   - notetaker 7: Yasuyuki Tanaka
   - notetaker 8: Pascal Thubert
   - Jabber scribe: Ines Robles

Minutes

   - [09.30] (expected 09.30) Meeting starts
   - [09.30] (expected 09.30) intro (Thomas Watteyne)
      - reminds of Note Well.
      - presents agenda. bashing?

      No issues raised, agenda approved.

      - [09.32] (expected 09.35) WG status (Pascal Thubert)
      - documents
         - draft-minimal
            - *[Suresh]* just did his review. Some comments, like
            redefinition from terminology doc, inconsistency, a few
questionable
            SHOULDs.
            - *[Pascal]* will this be held by terminology doc?
            - *[Suresh]* it can still progress through IESG, will then be
            in waiting state at the exit.
            - *[Suresh]* also huge section to define Rank that was already
            defined in RPL. Make sure this doc only defines the
increments, if any.
            - *[Tero]* this doc specifies default keys. This is discouraged.
            - *[Tero]* minimal testing now done, should remove well-known
            keys and defaut passwords that were meant for interop testing.
            - *[Suresh]* can send this doc for early Sec Dir review, to
            Tero for example!
            - *[Xavi]* the text does say it's only for interop testing
         - -6top-protocol
         - SF0: the architecture is stable, text is missing about tracks
         - SF1 won't be discussed this time but in next IETF
      - non 6TiSCH docs
         - ROLL and 6lo: Paging dispatch and Routing Dispatch passed IESG
         - Backbone router doc is split during the 6lo session
      - Milestones
         - goal is to release 6top by end of year
         - SF0 may slip by a couple of months
      - action plan
         - complex action item on security: work on join process. Trying to
         make this a 2-stage approach
         - *[Michael]* plan for plugfest before the Prague meeting July
         2017?
         - *[Thomas]* We will have a plugfest in July at IETF99 in Prague.
         None a priori before that.
      - [09.44] (expected 09.45) draft-ietf-6tisch-6top-protocol (Xavi
   Vilajosana)
      - much activity on mailig list.
      - New in this -03 version:
         - type field
         - cellOptions
         - cell suggestion in ADD response,
         - best effort number of cells in LIST response
      - draft seams stable - call for implementors comments
      - presentation of the cellOptions bitmap, it enables to specify what
      kind of cell is needed (TX, RX, Shared)
      - the cellOptions field is added in 6P ADD Request and 6P DELETE
      Request
         - in DELETE, if no cell lists provided, all cells of type
         described in CellType field will be deleted
      - suggestion field in response reduces the number of request attempts
      - do you think anything is missing?
      - *[Thomas]* Offline feedbacks from implementors, some changes are
      needed:
         - remark 1:
            - when issuing a LIST command, you can ask for 10 cells, but
            the neighbor returns the number of cells that fit in the
packet, e.g. 6.
            - your last request needs to contain an empty list so you know
            it's the end of the list of cells, since the neighbor is
required to answer
            with at least one cell.
            - This means there is always going to be one extra LIST request.
            - the suggestion is to add an "end of list" return code which
            the neighbor answers when its returning the last cells.
            - comments/
            - *[Xavi]* seems very reasonable, very small change
         - remark 2:
            - initially, a mote could only request TX cells to its
            neighbor, now can request anything
            - this means having two generation numbers (GAB,GBA) doesn't
            mean much anymore.
            - *[Xavi]* agrees, it has been discussed on the mailing list,
            having a single counter is probably enough
         - *[Pascal]* before we proceed with next draft, could we have an
   update about Tero's draft of having an IETF IE identifier?
      - *[Suresh]* the draft will be on the Dec 15 telechat
      - *[Pascal]* Bob, once the telechat is over, how much time until we
      get the IEEE allocation of an IETF IE ID?
      - [Bob] 24 to 48 hours. Send the request to Pat Kinney and myself, we
      can expedite.
   - [09.58] (expected 10.05) draft-ietf-6tisch-6top-sf0 (Diego Dujovne,
   Meetcho)
      - version -02
      - why this cell estimation algorithm: originally thought applications
      would request bandwidth. Now we estimate outgoing traffic.
      - the outgoing traffic growth only is used to estimate the traffic
      requirement
      - we don't assume RPL on top. We don't know where incoming traffic is
      going
      - alternative 1: is what is done now, some of the allocated cells are
      used and some are empty
      - alternative 2: adds a fix number of over-provisionning
      - alternative 3: not included in version 02, use a number of
      effective cells and an overprovisionning
      - question to the room, should we use alt 3?
      - *[Thomas]* I know people have implemented Alternative 3 at scale,
      but did not provide public feedback
      - *[Pascal]* please do provide feedback. Fixed overprovisioning on a
      large number of bundles is a large number of overprovisioned cells.
      - *[Pascal]* there are situations where another approach would be
      better (shared pool for overprovisioning)=> alternative 4
      - *[Diego]* this alternative 4 can be discussed on the mailing list
      - *[Xavi]* Pascal's proposal makes sense, but may too be complex for
      a minimal SF, would be good for SF2, SF3, etc.
      - *[Xavi]* percentage of overprovisioned cells might be better that
      fixed absolute number
      - *[Pascal]* let's continue the discussion on the mailing list
      - we no longer estimate number of required cells based on PDR
      - cell allocation policy, back to using original on-the-fly
      scheduling, threshold value is defined by implementer
      - the value of the number of softcells to schedule is left to the
      choice of the implementor
      - Timeout calculation: long discussion. Proposal to keep MAC and 6P
      ACK/timeouts independent
      - Ask for feedback o this proposal
      - since 6P now allows different type of cells on the SF, which ones
      to use? in SF0, only Tx cells.
      - *[Thomas]* this was discussed recently on the mailing list, it has
      been decided to keep in simple and just use TX cells
      - compliance to 6P requirements is almost done. missing timeout (6P
      ACK will simplify task to achieve this). Satistics to compute PDR.
      - performance evaluation: paper published IEEE Sensors Journal.
      Simulation only. Ask for input from implementers.
      - Cell relocation: SF0 proposes to trigger a cell relocation when it
      achieves PDR 20% less than the average of the rest of the allocated cells
      - Proposes an atomic DELETE/ADD command (a "RELOCATE" command) to do
      relocation efficiently (1 request rather than 2)
      - asks for comments
      - Diego asks for feedbacks from the implementations, on the algorithm
      and on the alternatives
      - *[Thomas]* thanks for these changes, which are perfectly in-line
      with what was discussed in Berlin
      - *[Thomas]* the next step for this draft is clearly to receive more
      feedback from the implementors. Chairs will issue a formal request for
      implementation and feedback on the ML.
   - [10.21] (expected 10.20) draft-vucinic-6tisch-minimal-security (Malisa
   Vucinic)
      - *[Thomas]* Some context. There has been a lot of work on security,
      including through the 6TiSCH Security Design Team. 2 drafts will be
      presented that are complementary. They are two steps of the same secutiry
      solution.
      - draft about join process: how is a node securely admitted in the
      6TiSCH network
      - three entities:
         - JN: joining node
         - JA: joining assistant (neighbor of JN, already in network)
         - JCE: join coordination entity (central authority which
         coordinates joining, a computer at the edge of the network)
      - One touch assumption: we start with the JN having a shared PSK or
      RPK or cert with the PCE
      - end state of the join protocol: a secure session between the JN and
      the JCE through which the JCE configures:
         - the K2 key (see draft-minimal)
         - the short address of the JN
      - *[Thomas]* want to stress that this short-address allocation
      replaces the 15.4 association. This means the JCE is responsible for
      ensuring unique short addresses are being distributed in the network.
      - to stress the limits of the bandwidth when using 6TiSCH -minimal,
      conducted initial simulations on OpenWSN
      - scenario: 30 nodes deployed in a room (fully meshed), DAGroot is
      started last
      - question: how long does the join process take depending on (1) the
      minimal schedule used and (2) the number of round-trips
      - in this setup, join process takes in the order of 10min, increases
      fast as more round-trip exchanges are needed
      - *[Subir]*: Why does this take 7 minutes? which part takes more
      times?
      - *[Malisa]* This is not the worse case but the join time
      - *[Thomas]* I see 2 key takeaways:
         - the 6top protocol is important as it reduces the join time by
         offloading the shared cell
         - the number of round-trips required is extremely important, it's
         unrealistic to assume 10 or so round trips
      - *[Thomas]* we want a really lean initial handshake otherwise
      joining takes too long
      - *[Subir]* this is useful, more data it would be even more useful
      - *[Peter]* Do you randomize your exchange?
      - *[Malisa]* Yes, 1 minute
      - *[Thomas]* These results do not scare me, this is what is expected,
      just great to put them on a slide. This is when 6TiSHC-minimal is used,
      i.e. no 6top protocol. There are many things that can be done to
      significantly speed up the join process, for example sending RAs in IEs.
      - *[Alex]* duration of a slot?
      - *[Malisa]* 10ms, i.e. there are 100 slots per second
      - Goal is to minimize the number of exchanges. In case of PSK, single
      round trip is enough.
      - Join protocol: the JN waits for the enhanced beacon then do the
      Neighbor Discovery
      - *[Pascal]* the ND exchange is only to acquire a local address
      - security handshake is optional for PSK and mandatory for RPK/Cert.
      It uses EDHOC protocol (ECC over CoAP).
      - implemented using CoAP:
         - JN is a CoAP client
         - JA is a CoAP Proxy
         - JCE is a CoAP server
      - goes through nonce generation algorithm, key generation algorithm
      - *[Pascal]* What is the size of sequence numbers used?
      - *[Malisa]* It's CBOR so it's variable (starting at 1B and
      increasing).
      - *[Alex]* CBOR int types up to 64 bits
      - *[Pascal]* was asking about maximum size, so that roll-over is very
      rare. We should recommend use of 4 bytes, for example.
      - *[Thomas]* this means that the JN does not hear the DIOs before and
      it just talks to the JA on local link
      - *[Malisa]* yes
      - *[Laurent]* size of messages? see numbers on slide 11. 16/26 bytes
      for req/answ
      - *[Tero]* about nonce, slide 9, always generates the same key if
      same sender ID are used?
      - *[Thomas]* no, nonce changed for each (re)join
      - *[Tero]* use of ASN as nonce is a problem. If network restarted,
      same nonce at the same time.
      - *[Malisa]* we are talking about end-to-end JN-JCE protection, not
      link layer.
      - *[Tero]* ok
      - *[Francesca]* Looked at CBOR, maximum sequence number byte-length
      is 7B for the MTI algorithm
      - *[Pascal]* Francesca, can you give us an update about the OSCOAP
      work presented yesterday at CORE?
      - *[Francesca]* the draft was adopted as WG doc at last IETF meeting
      and seems to be ready, a call for implementations has been issued
      - *[Thomas]* we're overtime. Let's discuss this on the mailing list
   - [10.46] (expected 10.35)
   draft-richardson-6tisch-dtsecurity-secure-join (Michael Richardson)
      - goal is to align ANIMA, netconf and 6TiSCH WG on this. Trying to
      account for constrained devices, e.g. reduce number of round-trips.
      - describes each group's reference architecture. Similar roles, but
      some opposite flow directions.
      - goes through roles: MASA, JCE, JA
      - prescribes zero-touch process
      - list of current issues
         - needs TCP, really? maybe use CoAP, COMI
         - EDHOC vs DTLS
         - need to coordinate with 6TiSCH-minimal
         - RA in IE. RA only, not full IP-in-IE. Also some network ID? For
         nodes that have been sleeping long and are looking for beacons to
         synchronize.
      - *[Pascal]* there is a DNA solution that can be use, but I like the
      use of the DODAG ID more
         - where should this work be done? Anima, Metconf, 6TiSCH? will
         discuss it with relevant ADs.
      - Would like a consensus on the "outgoing" (PCE->Pledge) method. Has
      an influence on the state machine and on who is responsible for the
      certificate lifetime, should it be the light object? the advantage of the
      "outgoing" method is that it is not its responsibility.
      - *[Pascal]* one minute questions
      - *[Subir]* does this proposal provide additional features to the
      draft presented by Malisa just earlier?
      - *[Michael]* Malisa's draft is the simpler "on-touch" case where
      security credentials are already present. This draft deals with
getting the
      credentials there.
      - *[Michael]* there will be a security DT call on November 29,
      encourage people to join that.
      - *[Pascal]* the two drafts are complementary, the call for adoption
      will be made on both document.
      - *[Pascal]* please hum now if you this the two drafts should be
      adopted

      hums

      - *[Pascal]* please hum now if you this the two drafts should NOT be
      adopted

      no hums

      - *[Subir]* would suggest to have only one security approach
      - *[Thomas]* this is exactly the case, there are just two phases in
      this solution, which the drafts detail
      - *[Pascal]* will call for adoption on the mailing list and carry on
      work
   - [11.03] (expected 10.55) Any Other Business?

   No further issues raised.

   - [11.03] (expected 11.00) Meeting ends


-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________