Dear all: Please find the minutes of the 6TiSCH meeting. Deepest thanks to our faithful note takes and jabber scribes who made this possible. Agenda and Meeting information
Meeting : IETF 98; Tuesday, March 28, 2017 (CST) Time : 9:00-11:30, Tuesday Morning session I Location : Room Zurich C, Chicago Swisshotel Concourse Level Chairs : Pascal Thubert <[email protected]> Thomas Watteyne <[email protected]> (remote) Michael Richardson <[email protected]> (acting) 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 (10mn) (Chairs) * Note-Well, Blue Sheets, Scribes, Agenda Bashing [ 5min] * draft-ietf-6tisch-minimal-21, draft-ietf-6tisch-terminology-08, progress vs. charter [ 5min] * Security (75min, lead by Michael) * Presenting the drafts and the flow between them (Michael) [20min] * draft-ietf-6tisch-dtsecurity-secure-join-01 (Michael) [15min] * draft-ietf-6tisch-minimal-security-02 (Mališa) [15min] * draft-richardson-6tisch-join-enhanced-beacon-01 [10min] * draft-richardson-6tisch-minimal-rekey-01 [10min] * 6top protocol draft-ietf-6tisch-6top-protocol-03 (Xavi) [15min] * Service Function 0 draft-ietf-6tisch-6top-sf0-03 (Diego) [15min] * Architecture draft-ietf-6tisch-architecture-11 (Pascal) [10min] * News from IEEE 802.15.4 (Pat) [15min] * Detnet backhaul draft-wang-detnet-backhaul-architecture-00 (Lun) [10min] * Any Other Business (Chairs) [ 5min] Resources * agenda: https://datatracker.ietf.org/meeting/98/agenda/6tisch/ * presented slides: https://www.ietf.org/proceedings/98/slides/slides-98-6tisch-aggregated-slides-06.pdf Summary _This summary is also posted in the INT area wiki, https://trac.ietf.org/trac/int/wiki/IETF98 The Working Group meeting went smoothly and according to agenda, started and completed in time. All the expected slots took place except for the last one on detnet-backhaul-architecture which was informative to the group. The group is ready to call for adoption for the 6P and SF0 documents, with restrictions. The first restriction is the lack of feedback information from SF on whether the panel of capabilities from 6P is sufficient to achieve all the needs to an abstract SF. This will be alleviated by experience from the interop test in Prague so we expect to be ready then. Also remarks on the lack of definition of the service interface between SF and 6P, e.g. pointing on the responsibility of the timeouts and the values incurred. The largest piece of the meeting dealt with security. The framework was presented in which the minimal security based on PSK can be seen as an optional portion of the larger flow that starts with private keys / certificates and fits within the ANIMA framework. A status was given on related work in other WG and at the IEEE. Volunteers * notetaker 1: Dominique Barthel * notetaker 2: Geraldine Texier * notetaker 3: Francesca Palombini * notetaker 4: Alexander Pelov * notetaker 5: Tero Kivinen * notetaker 6: Xavi Vilajosana * notetaker 7: Pascal Thubert * Jabber scribe 1: Diego Dujovne * Jabber scribe 2: Ines Robles * Jabber scribe 3: Michael Richardson Minutes * [09.01] (expected: 09.00) meeting starts * Thomas calling in from Paris * [09.03] (expected: 09.00) Intro and Status (10mn) (Chairs) * [09.03] (expected: 09.00) Note-Well, Blue Sheets, Scribes, Agenda Bashing [ 5min] * Pascal goes through agenda: * 70 min dedicated to security, will be able to do some work instead just present slides. * -minimal: Xavi now integrated all comments/reviews. -21 should go to IESG * [??.??] (expected: 09.05) draft-ietf-6tisch-minimal-21, draft-ietf-6tisch-terminology-08, progress vs. charter [ 5min] * mcr: plans for future plugtest ? * Thomas: yes, at Prague, probably 14 and 15 July, or after meeting. Physical meeting but tools for online testing. At the next interim meeting we'll discuss the scope of the interop. Likely -minimal, 6top, minimal sec. * we'll have an expert team to write the test description * Kerry: 6lo plugtest as well? Pascal: will see. * Suresh: -minimal underwent major review, many reviewers provided comments. Going to RFC editors. was approved a week ago. * [09.12] (expected: 09.10) Security (75min, lead by Michael) * presented at Detnet and ANIMA yesterday. Will repeat intro anyway. * [09.13] (expected: 09.10) Presenting the drafts and the flow between them (Michael) [20min] * goal: explain how the drafts fit together. * every 2 weeks phone meetings * new Doodle poll. If you couldnt make it to the past times, cast your vote for better times. * security considerations in ROLL actually applies to all LLNs * zero-touch: designed for networks that need to scale to huge number of nodes * the two security drafts were adopted after last IETF meeting * -enhanced-beacon: could not wait for -minimal, wrote ED usage description in separate draft * new terminology used: pledge - join registrar/coordinator - join proxy * took some terms form ANIMA. E.g. MASA Manufacturer Auhtorised Signing Autority * sets PSK if manufacturers knows which customer the device is shipped to. * Michael goes through decision tree for Pledge node to join. Hearing first EB can be very long, consumes energy. Subir: reason for going back in decision tree? mcr: if heared EB from wrong network * table of constraints: Michael interestsed in knowing other contraints that migh have been missed * * high level explanation of PSK and RPK cases. For FPK, needs to do EDHOC first (see ACE presentation) * Thomas: re. time to join. you can optimize many things, we are talking about seconds not minutes though. one of the constraints is that you get all the nodes to join roughly at the same time ("flood of join"). One use-case: when installing a network in a plant, booting the router last, every nodes will join at the same time * Benjamin Damm: ? mcr: bring question to the list, it's a difficult one. One example is two "identical" parts were swapped during shipment to two customers. "Just" need to redo pre-provisioning, not swap the part. How? * * [09.34] (expected: 09.30) draft-ietf-6tisch-dtsecurity-secure-join-01 (Michael) [15min] * status of the document: reduced this to the scope of the zero-touch, pushed some content to -minimal or other * Thomas: will we have an opportunity to talk about IP-IP vs. CoAP? mcr: good question, let's take that at the end. * will use CBOR Web Token as a voucher, will reuse a lot of code (COSE, CBOR already in place) * ANIMA so far not using CBOR, negociation going-in to unify. * presentation of anima document. Revocation not needed. * Max: you can find this in the notes from Anima meeting * Suresh: regardin one and zero-touch: what is going to be the update of one vs the other? mcr: goal to make the on-the-wire mechanism as close as possible. Expect to see devices that are both-capable. You can see that the differences are not big right now (Ack for bandwith control). * one difference is rate of requests: if Pledge drives the timing and many pledges, not much control. Il JCR drives its own rate, can control. * Suresh: at some point you still have to choose between those two. mcr: if you have a manifacturer that can put a PSK in it for you, you can do that. If you have a large number of devices or many manifacturers, you may want to go to one touch instead. * Thomas: or you can have a configuration step * Suresh: question still remains. What if you have one mechanism? Is it possible to reduce these two processes into one? * mcr: trying to build a protocol that allows you to deal with different cases: if we have the PSK, we can do the simplest thing, otherwise we can do this other thing. For example, might have a PSK for network A, and if deployed in network B, still ok since has a DevID. * Suresh: . * mcr: proposal by Goran, but doesn't have a home yet. * mcr goes through questions listed at ANIMA. * Please help articulate the benefit of using of CWT instead of adding PKCS7. * Open Issues * pictures ideal outcome, with convergence between 6Tisch, ANIMA , * [09.56] (expected: 09.45) draft-ietf-6tisch-minimal-security-02 (Mališa) [15min] * status: -02 includes major editorial restructuring, stabilizes the Join Process * this is one touch scenario draft * presentation of the join process * security handshake: this is the current version, and is not set in stone * Mohit: security hanshake, said could use EDHOC. Why rely on EDHOC if using P SK? * Malisa: in case of PSK it's optional to run EDHOC, if you require perfect forward secrecy you can run EDHOC with PSK, in case of RPK it's mandatory. * mcr: 3a (refer to message in the slides) (AAA) is optional when you don't use PSK. * Join Proxy operated as CoAP proxy in previous version of draft. Now new CoAP option to carry state between Proxy and Server, * could do IP-in-IP but proble is 3 IP headers, how about compression. * Pascal: provide example on the list for discussion. If all prefixes same as LBR, might be able to compress. * Carsten: could you present the status of this doc (incl. Join Proxy) at CoRE meeting end of the week? mcr: Friday morning. Malisa can make it. * Thomas: re. IP-in-IP vs. CoAP: CoAP can use well-known resources, saves a lot of exchanges that we have to do with IP-in-IP. * mcr: I dont think we have to do all that: specifically, the address of JRC could be LL-anycast, and I don't think that there any other addresses that the pledge needs to know. * describes how nonce and key are generated in OSCOAP at the pledge and at the JRC * Mohit: which values provide enthropy? Malisa: we are using the OSCOAP mechanism, we only use it in our case. Mohit: ok, will check with authors and carry forward on the mailing list. * Pascal: Interested in the discussion about the nonce transport because LoRaWAN seems to use similar mechanism so if real pb would like to know! * [10.16] (expected: 10.00) draft-richardson-6tisch-join-enhanced-beacon-01 [10min] * Diego presents. * Draft meant to add join information into EB to make joining more efficient. * beware that EB is not encrypted, should not put here stuff that should not be seen by attacker, e.g. PIO. * Erik: it is not clear what this Network ID is. mcr: hash of DODAG id. Issue is that it's constant across time. As long as connected to same root. * Malisa: why is PAN ID not enough? mcr: we might decide that we always use a constant PAN ID, maybe it is enough. Diego: a combination of both * Thomas: Ask same question about PAN ID. PAN ID might be the simplest way. * Subir: slide 3. How do you identify JCE? mcr: This is from the Join Proxy. L2 address and ... * Benjamin: Frequency bands/channels to use. How does it get to know about it? mcr: not an IETF problem. * Diego: asking for comments about adoption. * Pascal: interest in the document. Should this document be adopted at some point by this WG? (about two in favour), (nobody against), (two have read document) * Samita: ? Diego: * mcr: next presentation will respond to Samita's question. * [10.28] (expected: 10.10) draft-richardson-6tisch-minimal-rekey-01 [10min] * Michael presents new draft. Presentation about the concept behind it. Uses CoMI. * when node receives draft with a given key in table, will start sending traffic with this same key. * Mohit: do keys have key id? mcr: yes, on the wire * allows to eliminate malicious node off the network, but may take a long time because need to rekey all the other nodes, that may be sleepy and will keepy accepting previous keys for some time. * Kerry Lynn: are there requirements that nodes wake up every n days? mcr: if you dont wake up every time and then you would lose desyncronisation AND you would loose the keys as well, so it's not a big addition to the requirements. * Interested in adopting this, using CoMI (possibly CoMI co-author) * [10.34] (expected: 10.25) 6top protocol draft-ietf-6tisch-6top-protocol-03 (Thomas replacing Xavi) [15min] * stable document. About distributed 6TiSCH cell allocation. * few cahnges from previous version. Most notable is relocate command to improve on delete+create cell. * authors believe the draft is ready, but few unknows: relation with SF, missing functionalities? * will know from 6TiSCH plugtest event in July. * Pascal: ask for in depth reviews, in particular from an allocation expert. Diego, Charlie will review this document. * Pascal: after review, will ask for last call. * Thomas (as chair): would feel more confortable moving it to last call if all the pieces fit together, in particular feedback from implementors about 6P+SF0 * [10.40] (expected: 10.35) Scheduling Function 0 draft-ietf-6tisch-6top-sf0-03 (Diego) [15min] * this draft is about a simple scheduling function. * following discussion at IETF97, adopted one mechanism for bandwith estimation. * Packet Delivery Ratio estimation computed on last 10 packet transmission. Is 10 a good value? * Timeout: Yasuyuki proposed algorithm. See discussion on mailing list (Dec 2016 onward). * Thomas: algorithm already implemented in 6P. The 6top draft says timeout value is left to the SF, because it's the only entity in the node that has the full view. diego: we are thinking about the whole transaction, instead of a timeout for each of the exchanges. Now you have to calculate the worst timeout between all the exchanges, which is very long. Pascal: let's take that to the mailing list. * discussion on cell relocation: oprions are * when PDR gets significantly worse that average for all cells * constant relocation to number of random cells (<did I get this right?>) * leave it to implementation * Tengfei: For the PDR_THRESHOLD, each cell is provisioned by different SFs, so as long as the cell is related by the corresponding SF, which is running on one side, there is no issue for interoperability. (Copied over from jabber) Thomas Requested to start a Thread on the ML on that Malisa on mic: there is a 6tsich simulator available on the bitbucket page that is convenient for simulating this sorts of algorithms. please take a look. * Muhammad Majhal (yyy univ UK): ? Thoams: TSCH link layer provides duty cycling. * PAscal: this draft should ship together wth 6top. But pobably as informational, and make second version as standards track when we have more experience * Malisa (from jabber): there is a 6tsich simulator available on the bitbucket page that is convenient for simulating this sorts of algorithms. please take a look. * [11.00] (expected: 10.50) Architecture draft-ietf-6tisch-architecture-11 (Pascal) [10min] * considerationa about "tracks". Also provided in Detnet draft. A 6TiSCH is not just a serial sequence of cells along a path. Can include replication/elimination. * published draft at BIER to describe how this path replication (using Arc routing) works. * Tests have been performed to combine BierTE mechanism with tracks. A bitmap tells the path to take. * The bitmap indicate the paths that failed or not, enabeling an OAM mechanism and a control loop * Kerry Lynn: how does this compare to FEC? Pascal: we are mostly aiming at protecting against node failure; TSCH is pretty good at reducing link failure probability. * Pascal: take advantage of inherent broadcasting of radio to do "bi-casting", by having two receivers and one transmitter per cell. This increases reliability. * Also expose node multiple parents to RPL root (in non-storing mode), shows the full structure. Root can find shorter pathes. Effectively reduces latency. * Recap: tracks are much more than sequence of cell. * Tengfei: we are conducting large-scale experiments of 6P SF0 on the IoT-lab, with 100-nodes runnign openWSN. will contribute results to the group verifying the current of 6p and SF0 work. * Malisa: working on 6TiSCH simulator, on BitBucket. Will contribute the results to the group. Explore the code and contribute. * Pascal: please write that in the mailing list * [11.15] (expected: 11.00) News from IEEE 802.15.4 (Pat) [15min] * 15.4q: new low power PHY, has Amplitude Shift Keying. Not backward comptabible. * 15.4t: 2Mbps, backward compatible with current radios. * next 15.4 revision will integrate 6 amendments and include corrigenda. * 15.9: Information Elements for Key Management Protocols. o 15.10: layer 2 routing. Meant to support "large scale" networks (node count in the thousands). Randy Turner asked what is large scale, Charlie answered thousand o 15.12: upper layer over 15.4. Defines concept of profiles (e.g. for WiSun or Thread). * Muhammad: 15.6 ? Pat: 15.6 is medical Body Area Network. MAC similar to 15.4. But nobody at 15.6 asked 15.12 to consider their techno * Carsten: Is this all done? Pat: no it's underway right now. We do need help. * Bob: 15.6 has a limited stack architecture, star topology, very isolated approach to many things, very closed, trying to put 15.6 in discussion is challenging at best, talking about 15.7 would be much better. * Need participation from this group. * [xx.xx] Detnet backhaul draft-wang-detnet-backhaul-architecture-00 (Lun) [10min] * skipped for lack of time * [11.29] (expected: 11.25) Any Other Business (Chairs) [ 5min] * Samita: please come to 6lo * [11.30] (expected: 11.30) meeting ends
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
