1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 140630_webex_security

View History

Minutes Webex 30 June 2014, 6TiSCH Security Design Team

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Thomas Watteyne
  2. Pascal Thubert

Present (alphabetically)

  1. Giuseppe Piro
  2. Jonathan Simon
  3. Michael Richardson
  4. Pat Kinney
  5. Patrick Wetterwald
  6. Maik Seewald
  7. Max Pritikin
  8. Pascal Thubert
  9. Rene Struik
  10. Thomas Watteyne

Recording

Minutes

  • [07.04] Meeting starts

    Pascal starts recording

  • [Michael] reminds note well
  • [Michael] Would like to discuss routability for the joining node. Can a joining node have a route to PCE directly, or does it need a tunnel from proxy. If we need an application-layer proxy, we should be very clear about that.
  • [Michael] We discussed in February that joining traffic might be overwhelming.
  • [Michael] Let's open the floor. Please state your opinion about whether we want/can afford end to end activity
  • [Pascal] In an industrial factory setting it's unlikely admins will let you have direct Internet access. Communication with PCE is normally affordable. Necessary to have proxy. Connectivity to the PCE from the device is mandatory.
  • [Giuseppe] <no answer>
  • [Jonathan] It depends on traffic level and what exactly we are talking about, and at what stage. The hope is that we minimize the number of steps for-end-to end communication. At some point, device will have to talk to PCE.
  • [Michael] It could be a proxy at L5, or L3. Believe simpler solution with end-to-end. What would the criteria be for simpler?
  • [Jonathan] Hard to have arbitrary criteria. Don't want a situation where motes are waiting for something to happen and cannot maintain synchronization. At other extreme, where L2 connectivity, if the connectivity not laid in yet, large latency. Don't want system which is not scalable.
  • [Pat] PCE is critical, so joining device has to have connectivity to PCE.
  • [Michael] question is, when talks to PCE, does it do so by talking to the PCE directly, or does it for instance use a proxy mechanism through adjacent node
  • [Pat] Will need some more time to think about
  • [Patrick]
  • [Thomas] <...> routing or not
  • [Pascal] Did not answer the correct question, <...>
  • [Michael] 2 alternatives:
    • layer 3 connectivity for joining node to the PCE. very WHART-like, no additional mechanism
  • [Max] just for <...>
  • [Michael] PCE will be able to manage the BW pretty well, since it is responsible for pushing scheduling information
  • [Michael] if we assume that node can reach PCE, how? Can be as simple as IP-IP tunnel.
  • [Max] any different in the security between two approaches?
  • [Michael] if we have HTTP-proxy like, we can use commands "connect", to start (D)TLS.
  • [Max] Given that end-to-end can be established to either mechanism. Gut feel is that the L3 e2e mechanism is simpler.
  • [Michael] biggest downside for end to end is unwanted traffic. Or joining node would tie up too much routing resources.
  • [Michael] instead or proxy, let's say "nearby node helping"
  • [Pat] would like to change answer. In ISA100, ADV node acts as proxy until node has joined. Once that's done, network manager gives it a slot through which node can talk to manager. ADV proxy is only there until device has joined. If network manager is constrained, it can handle the request from the new node when it is time for it to talk to manager.
  • [Jonathan] The only real shortcut for the proxy is performance. For example, shortcutting the need for certificate to come all the way from the PCE. Depending on how this join flow looks, maybe role of proxy is not that critical.
  • [Michael] We discussed this 2 weeks ago, made decision to leave options open.
  • [Thomas] looking at DTLS relay draft, is this what we are discussing?

    http://tools.ietf.org/html/draft-kumar-dice-dtls-relay-01

  • [Michael] Looks like we fit into draft-kumar-dice-dtls-relay-01 pretty well.
  • [Michael] Concerns about resource consumption. Two resources: (1) BW and (2) routing resources
  • [Michael] Is there some way that, regardless of whether has E2E or relay, convergence of routing traffic could have impact on BW of system. Question: what mechanisms do we have to limit the BW allocated.
  • [Thomas] If we use a relay, we can toggle the relay on/off.
  • [Michael] Essentially msg to relay on off?
  • [Thomas] Yes, or throttle
  • [Michael] Do we have mechanism for that in 6TiSCH
  • [Thomas] none, but simple commands to add.
  • [Rene] Sent e-mail to MLs about draft-kumar-dice-dtls-relay-01, loose end is that it does not include any mechanism to throttle the BW.
  • [Thomas] 2 things which look orthogonal:
    • security aspect: how does a node join, e.g. through DTLS relay
    • limiting the amount of traffic. These can be made independent.
  • <...>
  • [Michael] Other aspect about a joining node is whether it is visible in routing infrastructure. If we assume a relay case, we need some state on the relay and PCE. If we use IP-IP, we require more BW.
  • [07.44] <...>
  • [Michael] Conclusion is that routing may not be as critical in the storing mode.
  • [Michael] How do people feel about routing information into the network?
  • [Rene] Are you suggesting that you want to have routing information before authentication step is finished?
  • [Michael] correct, but would have a constraint on being only in joining cells. Would have no access to network key, and could talk only to relay.
  • [Michael] cannot talk with other nodes than relay, since doesn't have network L2 key.
  • [Thomas] <...>
  • [Michael] on any other mechanism, we would be creating state on the neighbor.
  • [Michael] somebody would need to absorb joining traffic
  • [Thomas] what are the next steps for the 6TiSCH security work?
  • [Michael] would like to write up what we discussed during the last 3 weeks. Specific options, and get reaction whether reflects what we have discussed. Second question: is this an appropriate set of trade-offs between resources in neighbor, PCE and BW?
  • [Thomas] is your plan to write something before draft 7/4 cutoff?
  • [Michael] yes, although will be hard before Friday.
  • [Michael] Propose that this is last call before IETF. Proposing get this draft, will post notification to the list.
  • [Michael] at IETF90 6TiSCH WG meeting, would like 10min of slide time and 5min of questions
  • [Pascal] OK
  • [07.55] Meeting ends

Updated