# Minutes, IETF 97 6TiSCH WG Meeting # Agenda and Meeting information ============================== ``` Meeting : IETF97 Thursday, November 17, 2016 (KST) Time : 9:30-11:00, Thursday Morning session I Location : Park Ballroom 1, Conrad Seoul Chairs : Pascal Thubert Thomas Watteyne Responsible AD : Suresh Krishnan URLs : 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 * [20min] (Xavier Vilajosana) * [15min] (Diego Dujovne via meetecho) Security * [15min] (Malisa Vucinic) * [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._ ``` 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: 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