[6tisch] Minutes Webex 27 May 2014, 6TiSCH Security Design Team

["Pascal Thubert (pthubert)" <[e-mail]>]

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1.  Thomas Watteyne
  2.  Pascal Thubert

Present (alphabetically)

  1.  Thomas Watteyne
  2.  Pascal Thubert
  3.  Michael Richardson
  4.  Giuseppe Piro
  5.  Jonathan Simon
  6.  Michael Behringer
  7.  Nancy Cam-Winget
  8.  Pat Kinney
  9.  Rene Struik
  10. Subir Das
  11. Tom Phinney
  12. Yoshihiro Ohba

Recording

  *   Webex recording<https://cisco.webex.com/ciscosales/lsr.php?RCID=29d3c286fdaa4c4e97d0e057044029f6>[69min]

Agenda

  1.  note well
  2.  intros
  3.  open issues summarized in: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
  4.  recap of draft-piro-
  5.  Wireless Hart -way --- how does the communication work?
  6.  how to summarize all of this to the working group
  7.  how to close this process up?

Action Items

  1.  Michael R. to create issues in the tracker for problems the group needs to address based on René's list

Minutes

  *   [7.04] Meeting starts
  *   Michael Richardson adds agenda item per Rene's suggestion (open issues)
  *   [7.05] note well applies, recording started
  *   [] outstanding issues:
     *   packet sizes
     *   device ID
     *   http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
  *   Michael Richardson: think we all agree, why this order?
  *   René Struik: no real reason with order, anything works
  *   René Struik: what to design a protocol and see what missing pieces, list based on calls, including call on Wireless HART, including tag name Tom Phinney identified.
     *   tad name
     *   packet size: how much non-security bytes can be keep in packet. Because of time scheduling, every packet costs latency. We need to see whether we are close to packet size limit.
     *   join process impact on network: when take mote out of box, how does it join the network. To some degree, unclear how this really happens with multiple channels and schedule
     *   protocol details: not so hard to do (crypto side), Security policy side: AR, access to network is determined by having certificate. If cert verifies, then by implication authorization. Different from ACL. different calls about 1AR; it's all about cert and particular CA.
     *   hence issues: worried we have had many calls, we have meeting in July. If we want to discuss a real protocol, what do need to create a protocol. Outstanding issues are missing pieces.
     *   other: l looked at HART, ZigBee, etc. Supposed we want the HART foundation to adopt, would be sad they refuse because too different. Maybe we could reuse flows from HART to a very large degree, then from a HART perspective, looks exactly the same. Would allows SDOs (e.g. HART) to move towards 6TiSCH long term.
  *   Michael Richardson: propose, go down room and see whether list is complete, or whether things are missing. Are there things on list as solved, and remove with list.
  *   Pascal Thubert: did you expect exhaustive? [non-crypto details are non defines]. packet size and number of packets. Match with the minimal support, in case of density impact of timers elapsing.
  *   Giuseppe Piro:
  *   Jonathan Simon: posted brief summary of HART join to 6TiSCH-sec group, including some of information. Joining process in Wireless HART, payload size are very on network header. Wireless HART has long/short address, graph or source routing, sizes change quite a bit. Summary: very short security handshake process because symmetric. sent a while ago proposal to use Pat Kinney. addresses issues such as how big flows are.
  *   Michael Richardson: can you find e-mail and paste in minutes: https://mailarchive.ietf.org/arch/msg/6tisch-security/s_LQeq8urO70A16rYnfEEXyjsts is recent message, and old message is:
  *   René Struik: remark: have not seen e-mail. Question what about total packet sizes, including configuration parameters. What needs to be together?
  *   Jonathan Simon: in e-mail, indicates contents on the different packets, including total. Can break out more is needed.
  *   Michael Behringer: problem is that don't know Wireless HART, coming from IP side. Needs to sit down and map to flows. we need to map out the flow in draft-pritikin, see what kind of info is exchanged and packet size. we can know what information is being exchanged. would need help from people who konw about e.g. packet iD. Useful?
  *   Michael Richardson: yes, would like to know how your diagrams are different from what posted already?
  *   Michael Behringer: yes, will have a loop.
  *   Giuseppe Piro: very important to understand size of packets during design of protocol. We are discussing size at MAC layer, can we consider fragmentations at MAC layer?
  *   Pat Kinney: 15.4e does not limit size of packets, the PHYs do. 15.4g have large size. Original PHYs remain at 127B.
  *   René Struik: why would we limit to 127B?
  *   Jonathan Simon: 4e designed to work on older PHY and 4g. Certainly the first TSCH implementations on older PHY limited to 127B.
  *   Michael Richardson: might be more efficient on 4g PHY, but we must assume that we wish to support older PHYs.
  *   Nancy Cam-Winget: trying to undeRené Struiktand: you can transmit one packet. In .11 there is fragmentation built into it. Does 15.4?
  *   Pat Kinney: no
  *   Michael Richardson: if we want to transmit a low payload, we need to fragment at adaptation layer, e.g. 6LoWPAN
  *   Subir Das: are we trying to design for old/new PHY.
  *   TW: we have to support legacy 15.4
  *   Pascal Thubert: agree. for the time being PHY includes legacy 15.4. we have fragmentation, whatever we can do to limit amount of data needs to be done, fragmentation needs to be done.
  *   Subir Das: sounds good, but are we restricting ourselves.
  *   TW: "old PHY" is not good name
  *   Jonathan Simon: newer PHYs have slower datarate
  *   Michael Richardson: back to Giuseppe Piro, more thoughts about crypto details?
  *   Giuseppe Piro: only MAC or also upper layers?
  *   Michael Richardson: probably the latter.
  *   Giuseppe Piro: have to think further, will provide later
  *   Nancy Cam-Winget: would break it down. there may be different sensitivities. From protocol details, we need to separate sessions establishment from provisioning.
  *   Michael Richardson: sessions establishment?
  *   Nancy Cam-Winget: how device connects to communicate securely. Provisioning; draft-pri could be more heavier weight on how device comes up and communicates securely.
  *   Michael Richardson: with provisioning, we also talk about distribution of TS schedule. Is that it?
  *   Nancy Cam-Winget: more
  *   Pat Kinney: didn't have time to go through this list in enough detail
  *   Subir Das: goes through list now, will comment on ML.
  *   TP: no response
  *   YO: joined late today, a bit out of context
  *   TW:
  *   Jonathan Simon: will send link to e-mail later
  *   Michael Richardson: I think we have found what we want to do, list is helpful. Preference is to do it the Wireless HART way, seems like an obvious and easily solved update. Don't expect reuse bit from Wireless HART, but only concepts.
     *   In my mind, of the 5 issues that Rene has brought up, packets sizes is important and needs to be documented, but not show-stoppers of any kind. We know that items will take more than 1 frame to deliver.
     *   device ID: aren't those replaceable by 1AR ID? can be make them look like Wireless HART tagbane. Not sure what problems is with 64bit.
  *   Jonathan Simon: for Wireless HART, nodes are mostly always address through 16-bit ID. there are other application-layer tags to address devices, bu=t may be out of scope. frames themselves have 16-bit address
  *   Michael Richardson: multicast behavior? i.e. turn on all of all hallway light bulbs.
  *   Jonathan Simon: not really, in general address all devices, or one. Not true multicast.
  *   Michael Richardson: Pascal is worried about AROs for joining. Part of the reason of ARO is to go from 8-byte EUI to short address you will be assigned one. We hae not discussed whether 16-bit is assigned, or random and using DAD
  *   Michael Richardson: assume Rene can solve cryptography protocols, but if we can use DTLS, we should. Assume is solved: we need to reuse DTLS.
  *   Michael Richardson: part e: just certificates, and doesn't matter? We need to be very clear of what kind of cert is in place and needs to be. That's where the difficult problem is.
  *   Michael Richardson: list is complete, but many of the items are probably solved
  *   René Struik: not sure DTLS fits with 6TiSCH. wants to know what latency, etc. DTLS doesn't give all properties.
  *   Michael Richardson: not an advocate of DTLS, would replace by other protocols, but CoAP over DTLS is a thing, and people in app space want to use it. Would be foolish to tell people to implement a second solution. not perfect, but good enough. About 100 tune-able things in DTLS to get many behavioRené Struik.
  *   Michael Richardson: how will we summarize to the WG, in the next 6 weeks before draft cutoff. What do we want to do?
  *   Pascal Thubert: would like to present the flows to the WG, show what happens. Also highlight shortcomings of DTLS.
  *   Michael Richardson: single answer. single answer with variations. e.g. 1X EAP-TLS is out?
  *   Pascal Thubert: hopefully not
  *   René Struik: could not hear
  *   Pascal Thubert: important it we make a choice like DTLS. interface between device and router. .can it be 1X or not, would like to see the flows for DTLS vs. EAP TLS vs Wireless HART to express what the options are.
  *   Michael Richardson: what level of detail?
  *   Pascal Thubert: we should see amount of messages and idea of what goes in there. what's in the device, rough message size etc...
  *   Michael Richardson: number of packets, size of packets, abstraction of contents.
  *   Pascal Thubert: size can be approximate, we need to know whether 1B of 100kB.
  *   Michael Richardson: how do we arrive at conclusion about EAP-TLS. how do we arrive at conclusion?
  *   René Struik: I don't understand how we have discussions. This is not a technical discussion. We went over this list.
  *   Michael Richardson: in list, don't see questions.
  *   René Struik: e.g. simple topic, join process impact on network. Some of these things should have a way of expressing it in 4e, right now some of these things. We have protocol flows, effectiveness is small. Why not go through it with systematic way.
  *   Michael Richardson: we cannot have a draft until we answer the question. draft-piro answers many
  *   René Struik: only focus on 15.4. Does not answer the question how a joining device joins, many many details. We need to have reached an overall architecture.
  *   Subir Das: let';s consider solutions are work on architecture.
  *   Jonathan Simon: believe that the 4e spec is very clear on how device synchronizes, how send upstream traffic to coordinator, and get information back if that's desired.
  *   René Struik: would be great
  *   Michael Richardson: should we turn those points in issues on issue tracker.
  *   René Struik: if e.g. we have EB and get ASN, that doesn't mean the ASN time is the right one. only when the device gets the ASN, can we inject it in the MAC table.
  *   René Struik: we need to move from initial state to synchronized ad security. how hears EB in 4e spec.
  *   Michael Richardson: device listens to EB, sync's, then send in a e.g. ARO
  *   René Struik: if node wants to send the first packets, we need to know where to send in. If we want to solve, would like to see how we're going to solve it.
  *   Michael Richardson: will turn points in issue tracker. Then we can track when things are solved. Trying to find process.
  *   Michael Richardson: would it be acceptable to walk through the issues next week, or should be leave for later on?
  *   René Struik: fine, doesn't need to be number 1 on agenda. Main point is whether we want to mimic Wireless HART.
  *   Michael Richardson: major architectural decision, we need to reach consensus issue. Highest level.
  *   TW: would it be useful to have
  *   Michael Richardson: AOB?
  *   René Struik: can get slides with protocol flows, need until end of weeks, include HART flows
  *   Michael Richardson: OK. Maybe put on bitbucket, whatever you like
  *   Pascal Thubert: we have seen a number of flows to get the idea of what different with Wireless HART: what you get, what you need. Then, people will identify what properties we needs. We then will identify a approach and comment on it. That's why interested in ARO.
  *   Michael Richardson: hard to hear you. repeat in e-mail?
  *   Pascal Thubert: Would like to see the flows, EAP/TLS, DTLS, Wireless HART and see variations between them. Then there is the ND ARO-based flows that Michael has ntrofuced in the ML, not sure whether this is the same as DTLS.
  *   Michael Richardson: AOB?

None other issues.

  *   Michael Richardson: will copy