Subject: [6tisch-security] Security group goals

From: Jonathan Simon <[email-masked]>
Date: Thu, 26 Feb 2015 14:32:43 -0800

So just to restate the problem I think we’re trying to solve:

Goal: We want to specify what is needed to get a new device’s 6TOP layer securely configured such that it can participate in a 6TiSCH network.  

The bulk of the discussion to date seems to focus on how to determine whether the device should be allowed to be on the 6TiSCH network.   What is the minimal (i.e. smallest number of packets to do) set of things we need in order to accomplish the goal?  We can then build on that minimal approach to solve more domain specific problems as needed.

-- 
Jonathan Simon

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 26 Feb 2015 23:34:30 +0100

+1

That's my understanding.

On Thu, Feb 26, 2015 at 11:32 PM, Jonathan Simon <[email-masked]> wrote:

> Goal: We want to specify what is needed to get a new device’s 6TOP layer
> securely configured such that it can participate in a 6TiSCH network.
>
> The bulk of the discussion to date seems to focus on how to determine
> whether the device should be allowed to be on the 6TiSCH network.   What is
> the minimal (i.e. smallest number of packets to do) set of things we need
> in order to accomplish the goal?  We can then build on that minimal
> approach to solve more domain specific problems as needed.
>
> --
> Jonathan Simon
>
>
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>

---

From: Kris Pister <[email-masked]>
Date: Thu, 26 Feb 2015 14:40:05 -0800

Do we have a list of requirements that we're trying to satisfy? Some 
that I can
think of:
* I have a home system.  I'm happy to let anyone give/get 6tsch links 
because of
reason X. [bad - we need to make it look like this but not be that open?]
* I install fire or security sensors in office buildings.  No one 
without specific
credentials gets squat.
* I am a member of IndustryConsortiumX selling home/office/industrial 
automation
products.  Anyone with ICX certs gets some minimal connectivity.

The amount of connectivity might vary.  Lowest connected state might be 
access
to the Minimal draft slotted aloha slot.  Higher levels can come later.

ksjp

On 2/26/2015 2:32 PM, Jonathan Simon wrote:
> Goal: We want to specify what is needed to get a new device’s 6TOP 
> layer securely configured such that it can participate in a 6TiSCH 
> network.
>
> whether the device should be allowed to be on the 6TiSCH network. 
>   What is the minimal (i.e. smallest number of packets to do) set of 
> things we need in order to accomplish the goal?  We can then build on 
> that minimal approach to solve more domain specific problems as needed.
>
> -- 
> Jonathan Simon
>
>
>

---

From: Kris Pister <[email-masked]>
Date: Thu, 26 Feb 2015 14:45:29 -0800

Note that there is also a customer requirement for speed.  If I'm 
installing a network,
I may only be able to put one mote up every few minutes, and security 
overhead
is not likely to be a problem.  But when the power fails, or someone 
reboots the
gateway, or for whatever reason the network needs to reform, then even 
seconds
per mote is going to be an unacceptable delay for some applications.
If I have 500 motes talking to a single gateway doing lighting control 
or process
automation, I'm not going to be very happy if my security overhead 
causes the
network to take 2000 seconds to reform.

ksjp

On 2/26/2015 2:40 PM, Kris Pister wrote:
> The amount of connectivity might vary.  Lowest connected state might 
> be access

---

From: Rene Struik <[email-masked]>
Date: Thu, 26 Feb 2015 21:17:38 -0500

Hi Kris:

 From Malisa Vucinic's information, time latencies can be expected to be 
primarily due to communication delays due to TSCH scheduling and not so 
much due to computational delays. In other words, I do expect that 
network (re)formation cost would not materially depend on whether 
security is switched on or off.

I do see lots of merit in having more than one server/JCE/PCE component, 
so as to "cut the depth of network trees" and, thereby, reduce delays 
(where those server components would be inter-connected via a speedier 
channel).

Best regards, Rene

[excerpt of email to 6tisch security list as of Feb 17, 2015: 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00434.html]

Well, given the example on Slide 5 re DTLS with pre-shared keys, time 
latency is mainly driven by communication delays (due to TSCH 
scheduling) and computational delays are relatively marginal in 
comparison (the conclusion applies public-key based approaches as well). 
Please also see the eight month old (June 11, 2014) message with a 
similar 
conclusion:http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.html

Best regards, Rene

On 2/26/2015 5:45 PM, Kris Pister wrote:
>>> The bulk of the discussion to date seems to focus on how to 
>>> determine whether the device should be allowed to be on the 6TiSCH 
>>> network.   What is the minimal (i.e. smallest number of packets to 
>>> do) set of things we need in order to accomplish the goal?  We can 
>>> then build on that minimal approach to solve more domain specific 
>>> problems as needed.
>>>
>>> -- 
>>> Jonathan Simon
>>>
>>>
>>>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 27 Feb 2015 15:48:07 +0000

This reminds me of the security profiles we discussed at ISA100. Multiple
network with different security levels may indeed co exist.

With 6TiSHC, RPL builds instances that lead to gateways, which are
associated to some networks and operations.

So it could be cool to be able to associated cells with instances, and
authorize a device in an instance, which gives it access to the associated
cells.

Cheers,

Pascal

From: 6tisch-security [mailto:[email-masked]] On Behalf Of
Kris Pister
Sent: jeudi 26 février 2015 23:40
To: [email-masked]
Subject: [6tisch-security] customer requirements (Re: Security group goals)

Do we have a list of requirements that we're trying to satisfy?  Some that I
can
think of:
* I have a home system.  I'm happy to let anyone give/get 6tsch links
because of
reason X. [bad - we need to make it look like this but not be that open?]
* I install fire or security sensors in office buildings.  No one without
specific
credentials gets squat.
* I am a member of IndustryConsortiumX selling home/office/industrial
automation
products.  Anyone with ICX certs gets some minimal connectivity.

ksjp

The bulk of the discussion to date seems to focus on how to determine
whether the device should be allowed to be on the 6TiSCH network.   What is
the minimal (i.e. smallest number of packets to do) set of things we need in
order to accomplish the goal?  We can then build on that minimal approach to
solve more domain specific problems as needed.

-- 

Jonathan Simon

---

From: Kris Pister <[email-masked]>
Date: Fri, 27 Feb 2015 09:50:44 -0800

Pascal - I agree that it would be nice to have a very flexible way of 
binding L2 resources
to different instances with different security properties, sort of like 
unix file permissions.

Can we agree that this is a harder problem and we don't need to solve it 
right now?
Certainly it is not a requirement to address the three scenarios below.

ksjp

On 2/27/2015 7:48 AM, Pascal Thubert (pthubert) wrote:
>
> This reminds me of the security profiles we discussed at ISA100. 
> Multiple network with different security levels may indeed co exist.
>
> authorize a device in an instance, which gives it access to the 
> associated cells.
>
> Cheers,
>
> Pascal
>
> *From:*6tisch-security [mailto:[email-masked]] *On 
> Behalf Of *Kris Pister
> *Sent:* jeudi 26 février 2015 23:40
> *To:* [email-masked]
> *Subject:* [6tisch-security] customer requirements (Re: Security group 
> goals)
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Kris Pister <[email-masked]>
Date: Fri, 27 Feb 2015 09:58:40 -0800

Rene -  I'm assuming that security computational delays are zero. You 
are correct that
latencies are primarily due to TSCH scheduling.  If you can do security 
processing without
needing any TSCH communication, then your statement below may be correct.
Unfortunately, most of what I've seen proposed recently in this group 
will in fact
require a crippling amount of TSCH traffic, and lead to literally hours 
of delay in
network formation for large networks.

If that is the only option that we give to end users, then they will in 
fact just switch
off security.  We will have failed.

ksjp

On 2/26/2015 6:17 PM, Rene Struik wrote:
> I do expect that network (re)formation cost would not materially 
> depend on whether security is switched on or off.

---

From: Rene Struik <[email-masked]>
Date: Fri, 27 Feb 2015 13:40:16 -0500

Hi Kris:

Do you have a pointer to what triggers your concern?

"Unfortunately, most of what I've seen proposed recently in this group 
will in fact require a crippling amount of TSCH traffic, and lead to 
literally hours of delay in network formation for large networks."

Best regards, Rene

On 2/27/2015 12:58 PM, Kris Pister wrote:
> latencies are primarily due to TSCH scheduling.  If you can do 
> security processing without
> If that is the only option that we give to end users, then they will 
> in fact just switch