Minutes for 6TISCH at IETF-91
minutes-91-6tisch-2
| Meeting Minutes | IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG | |
|---|---|---|
| Date and time | 2014-11-13 19:00 | |
| Title | Minutes for 6TISCH at IETF-91 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2014-11-24 |
minutes-91-6tisch-2
# Minutes IETF 91 WG meeting, 13 November 2014, 6TiSCH WG # Note: timestamps in HST. Information ----------- ``` Meeting : IETF 91 Thursday, 13 November 2014 Time : 0900-1030 HST Thursday Morning Session I (90min) Location : Hibiscus room, Hilton Hawaiian Village, Honolulu, Hawaii, USA Chairs : Pascal Thubert <pthubert@cisco.com> Thomas Watteyne <watteyne@eecs.berkeley.edu> Responsible AD : Ted Lemon <ted.lemon@nominum.com> 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:6tisch@jabber.ietf.org) * Ines Robles Resources, Recordings and Logs ------------------------------ | what | where | |-----------------------|---------------------------------------------------------------------------------------------------| | Wiki | https://bitbucket.org/6tisch/meetings/wiki/141113_ietf91_honolulu | | Presented Slides | https://datatracker.ietf.org/meeting/91/materials.html#6tisch | | Audio 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_0 | | Jabber Logs | http://www.ietf.org/jabber/logs/6tisch/2014-11-13.html | Agenda ------ 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.