Subject: [solace] Slides posted for SAAG heads-up

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Nov 2012 12:45:57 -0500

The slides for my short report at tomorrow's SAAG meeting are up:

http://www.ietf.org/proceedings/85/slides/slides-85-saag-3.pdf

(Disclaimer: These are presentation slides, not a presentation by itself.
So they make sense primarily in combination with what I'm going to say.)

Grüße, Carsten

---

From: Rene Struik <[email-masked]>
Date: Wed, 07 Nov 2012 15:32:57 -0500

Hi Carsten:

Great to discuss some of these topics with SAAG. I believe it would have 
merit to take this on a more fundamental ITRF level, so as to prevent 
people throwing a single protocol at the topic area: all context needs 
to be defined here in a unified way. More importantly, though, this 
should become an effort aimed at wide-scale usability (the 50billion 
devices everyone seems to point to in presentations from time to time)

Some brief comments:
a) Deployment scenarios.
I believe it would be a mistake to limit oneself to a single use case 
scenario. The proverbial light switch-lamp use case comes to mind, which 
would suffer from the often made assumption that one has a single, 
homogeneous trust domain (rather than a heterogeneous trust domain 
setting, where device roles etc are dynamic) and from small network size 
(after all, if internet of things will have 50 billion devices in 2020, 
then the avg network size *must* be large). This was the original 
approach within ZigBee all the way back in 2003, which - in my mind - 
set back the whole life-cycle management topic for years. By now (2012), 
there have been lots of studies into more realistic use cases with 
large-scale deployment by user groups, which do assume one can procure 
devices from mutually untrusted vendors, have many transitions in the 
supply-chain, may buy/sell/dispose of subsystems, etc. This all points 
towards heterogeneous trust models and very dynamic device behavior, 
without requiring centralized control flows involving a manufacturer 
(the latter is also undesirable from a survivability perspective).
b) Trust life-cycle management.
Please note that trust lifecycle management requires both crypto and 
security protocols (mechanical constructs) and constructs that take care 
of authorization decisions (initial authorization, changes to device 
role mapping, device replacement, etc.). The latter seems 
under-emphasized on the slides. This should include questions as to how 
to initialize 50 billion devices for virtually $0 apiece.
c) Security objectives.
An objective such as "not subject to a mass scale attack" would be hard 
to quantify in terms of required cryptographic assurances. Moreover, it 
seems to miss the point that some of these highly constrained networks 
are suppose to safeguard critical infrastructure (municipal water 
supply, hurricane prediction systems, etc.). In my mind, it would be a 
mistake to make this an exercise in toning down normal security 
requirements (under the pretext that this is only for "non-serious 
applications" (lamp-switch scenario again)). If one wants to get mass 
scale deployment of the 50 billion devices mark, one cannot aim for 
"crappy, but good enough" solutions, since no one in a position of 
accountability would sign off on these (lifes and jobs on the line if 
something goes wrong, so to speak).

The good news is that most high-quality crypto that is also efficient 
and does not leave a huge implementation footprint is fast becoming a 
commodity (or is getting there). The bad news is that integration of 
individual crypto and security constructs *and* security policies that 
allow these to be woven into a unified, standardizable framework 
architecture is still far off from sufficient understanding, let alone 
support via standards (and often simply ruled out of scope, since a 
"convenient" way to lock out product from other vendors).

==

Weblink to NIST Cryptography for Emerging Technologies and Applications 
Workshop, Gaithersburg, MD, November 7-8, 2011
http://www.nist.gov/itl/csd/ct/ceta-workshop.cfm

A very old IETF draft of potential interest - with requirements, 
spelling out crypto + policy requirements, etc.
(true: 3yrs old draft [Nov 2009], but referring to needing a home with 
IETF in concluding section):
http://tools.ietf.org/pdf/draft-struik-6lowapp-security-considerations-00.pdf

On 11/7/2012 12:45 PM, Carsten Bormann wrote:
> _______________________________________________
> solace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/solace

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Nov 2012 16:38:54 -0500

Hi Rene,

good to hear from you.

Clearly, we cannot stop at exactly one usage scenario.
But I strongly believe we need to start with exactly one.
When we have the contributions for that, we can probably ask much better questions for the next round, where we will add scenarios.

The slides are indeed more for SAAG and less for people who would focus on the logistics of rolling out 50000000000 devices.
SOLACE clearly goes beyond security, or we could do it right there in the security area.

The security objectives slides are divided into one for the specific ones for a scenario and one for the general ones (one could say "motherhood and apple pie" if they were better understood).  Even if the specific ones can be toned down, we still have the general ones, and that includes avoiding susceptibility to mass attacks.  (This is one of the points that were made at the March SoS workshop.)  And that is, very much, the reason why compromising on security always leads to security compromises.

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Wed, 07 Nov 2012 22:10:44 +0000

> When we have the contributions for that, we can probably ask much better questions for the next round, where we will add scenarios.
+1. The premise for an effective usage scenario is that it is fully or 
at least well understood otherwise it is not a usage scenario. It is all 
very well theorising on a multitude of usage scenarios and saying they 
are all important but unless they are proven to be relevant and the 
particular issues are understodd, they lose their relevance as a usage 
scenario.
> SOLACE clearly goes beyond security, or we could do it right there in the security area.
+1.

---

From: Rene Struik <[email-masked]>
Date: Wed, 07 Nov 2012 18:29:38 -0500

_Dear colleagues:
_

_
_

_What about starting with the following use case scenario, which was one 
of the scenarios brought up by user community (Shell, in this case) in 
industrial control network setting?
_

_
_

_Scenario 1:_

·Plant X wants to install a wireless sensor network to measure 5 
pressure and 5 temperature points. One gateway. That gateway to connect 
to the legacy wired infrastructure. Plant X now has a DCS system with an 
Ethernet L2 network. Plant X likes to buy pressure instruments from 
vendor A, and temperature instruments from B. Gateways for G.

·Plant X uses contractor C for installation and commissioning.

Scenario 1b would now include realization that contractor C turns out 
not to be that trust worthy and threatens to throw installation info on 
the street, unless a $1m amount is being paid to an offshore account.

I believe this should not be "too theoretical" (??).

Rene

On 11/7/2012 5:10 PM, Robert Cragie wrote:
>> When we have the contributions for that, we can probably ask much 
>> better questions for the next round, where we will add scenarios.
> at least well understood otherwise it is not a usage scenario. It is 
> all very well theorising on a multitude of usage scenarios and saying 
> they are all important but unless they are proven to be relevant and 
> the particular issues are understodd, they lose their relevance as a 
> usage scenario.
>>
>> The slides are indeed more for SAAG and less for people who would 
>> focus on the logistics of rolling out 50000000000 devices.
>> The security objectives slides are divided into one for the specific 
>> ones for a scenario and one for the general ones (one could say 
>> "motherhood and apple pie" if they were better understood).  Even if 
>> the specific ones can be toned down, we still have the general ones, 
>> and that includes avoiding susceptibility to mass attacks.  (This is 
>> one of the points that were made at the March SoS workshop.)  And 
>> that is, very much, the reason why compromising on security always 
>> leads to security compromises.
>>
>> Grüße, Carsten
>>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Nov 2012 18:36:26 -0500

On Nov 7, 2012, at 18:29, Rene Struik <[email-masked]> wrote:

> industrial control

Too easy.

This is usually a highly controlled environment, where there already are defined business relationships.

Try a home occupied with a family with a 13-year old son, where the lifecycle later involves, say, a divorce and a foreclosure.

(I like the industrial scenario, but I think we should do that later.)

Grüße, Carsten

---

From: Rene Struik <[email-masked]>
Date: Wed, 07 Nov 2012 19:20:49 -0500

Hi Carsten:

If this sounds too easy, just because I put the word "industrial 
control" in the title, please abstract this a little bit and apply other 
nomenclature. If it is still too easy, then just provide a good 
description and a proposed approach and collect your price money. Then, 
we can move on to what you believe would be more difficult. I do claim 
that the scenario I described captures lots of aspects that are 
necessary to get to anything meaningful for internet of things 
scenarios. Not everything is a home scenario (plus: if all networks are 
home-size with debt-laden households, one never gets to the 50billion 
device numbers. Moreover, we also do not harness the power of wireless 
to assist in addressing huge societal problems).

What scenario do you suggest yourself: more than hub-and-spoke, all 
shrink-wrapped, I hope?

Rene

------- Original Message --------
Subject: 	Re: [solace] Slides posted for SAAG heads-up
Date: 	Wed, 7 Nov 2012 18:36:26 -0500
From: 	Carsten Bormann <[email-masked]>
To: 	Rene Struik <[email-masked]>
CC: 	[email-masked], [email-masked]

Too easy.

Grüße, Carsten

On 11/7/2012 6:29 PM, Rene Struik wrote:
>
> _Dear colleagues:
> _
>
> _
> _
>
> _What about starting with the following use case scenario, which was 
> one of the scenarios brought up by user community (Shell, in this 
> case) in industrial control network setting?
> _
>
> _
> _
>
> _Scenario 1:_
>
> pressure and 5 temperature points. One gateway. That gateway to 
> connect to the legacy wired infrastructure. Plant X now has a DCS 
> system with an Ethernet L2 network. Plant X likes to buy pressure 
> instruments from vendor A, and temperature instruments from B. 
> Gateways for G.
>
> not to be that trust worthy and threatens to throw installation info 
> on the street, unless a $1m amount is being paid to an offshore account.
>
>
>
>> +1. The premise for an effective usage scenario is that it is fully 
>> or at least well understood otherwise it is not a usage scenario. It 
>> is all very well theorising on a multitude of usage scenarios and 
>> saying they are all important but unless they are proven to be 
>> relevant and the particular issues are understodd, they lose their 
>> relevance as a usage scenario.
>>>
> email:[email-masked]  | Skype: rstruik

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Nov 2012 00:34:07 +0000

I think the point is you could choose any number of scenarios and 
providing they are well-researched and understood, any of them would 
serve as a starting point. Where it starts to go wrong IMHO is trying to 
start with a number of disparate scenarios and in the first analysis 
phase trying to distil some common understanding and architecture from 
all of them. I think it makes more sense to start with one and I think 
that Carsten's suggestion is more representative of the challenges 
facing device lifecycle and is therefore a good starting point.

I would then move forward in an incremental fashion whereby at each 
increment we:

 1. Introduce a new scenarios
 2. Aim to describe it using the architectural concepts developed for
    the previous scenarios
 3. Refine the architectural concepts

Robert

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Thu, 8 Nov 2012 02:35:21 +0000

Rob's suggestion sounds good to me. We need a starting point and then we can build on it later on.

Cheers
Sye Loong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: donderdag 8 november 2012 1:34
To: [email-masked]
Subject: Re: [solace] Slides posted for SAAG heads-up

I think the point is you could choose any number of scenarios and providing they are well-researched and understood, any of them would serve as a starting point. Where it starts to go wrong IMHO is trying to start with a number of disparate scenarios and in the first analysis phase trying to distil some common understanding and architecture from all of them. I think it makes more sense to start with one and I think that Carsten's suggestion is more representative of the challenges facing device lifecycle and is therefore a good starting point.

I would then move forward in an incremental fashion whereby at each increment we:

  1.  Introduce a new scenarios
  2.  Aim to describe it using the architectural concepts developed for the previous scenarios
  3.  Refine the architectural concepts
Robert
On 07/11/2012 11:36 PM, Carsten Bormann wrote:

On Nov 7, 2012, at 18:29, Rene Struik <[email-masked]><mailto:[email-masked]> wrote:

industrial control

Too easy.

Grüße, Carsten

solace mailing list

[email-masked]<mailto:[email-masked]>

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Rene Struik <[email-masked]>
Date: Wed, 07 Nov 2012 21:47:35 -0500

Hi all:

I was just commenting on discussion points to be presented with saag 
tomorrow and not trying to get into position-based arguing techniques on 
which scenario is "right" or "wrong". I presented a scenario that has 
proved highly relevant to a community with deep pockets (oil and gas 
industry, fast-moving consumer goods) and that is actionable 
(sufficiently concrete description to plot potential ways to accommodate 
this).

I do not want to get into any discussion whether someone else's 
foreclosed home property with divorced parents (out of this world, in 
Asian context, me thinks) scenario would be more appropriate. To address 
security needs for internet of things scenarios, one simply has to 
distill the technical triggers on devices and network elements and see 
how to accommodate any state transition appropriately (not that hard, in 
my own experience).

I would be happy if, after years, the topic area of trust lifecycle 
management for highly constrained networks would find a good home *and* 
would address the predominant technical topics required to lay a solid 
foundation towards this. If this would be the outcome, I would be happy 
to contribute. Hence, my note.

Have a good meeting.

Rene

On 11/7/2012 7:34 PM, Robert Cragie wrote:
> serve as a starting point. Where it starts to go wrong IMHO is trying 
> to start with a number of disparate scenarios and in the first 
> analysis phase trying to distil some common understanding and 
> architecture from all of them. I think it makes more sense to start 
> with one and I think that Carsten's suggestion is more representative 
> of the challenges facing device lifecycle and is therefore a good 
> starting point.
>
>> On Nov 7, 2012, at 18:29, Rene Struik<[email-masked]>  wrote:
>>
>>> industrial control
>> Too easy.
>>