Subject: [Roll] LLN routing different end-customers data

From: <[email-masked]>
Date: Tue, 21 Oct 2008 19:07:58 +0200

Hello all,

The question has been raised among the authors of the "Urban sensor network routing requirements", but it might pertain to other market segments as well, so here it is :

My take is that an urban sensor network infrastructure might support applications for different end users, potentially owning their private sensor nodes. It seems legitimate that they will only be willing to participate in forwarding their own data (because their nodes are likely to be battery powered). In contrast, the "backbone" composed of less power-constrained devices (maybe owned by a main contractor or service provider) would forward the traffic of all users.
Is this case also envisaged in the building automation or other contexts?

To accomodate for this case, shall we have some language that some nodes may elect to only participate in forwarding some flows? Or can we keep mum on this in the routing requirements if nothing is written that precludes it?
Is anybody willing to offer his/her views on the implications on routing security?

Thanks for your insights, and best regards
Dominique

Dominique BARTHEL
France Télécom Division R&D		TECH/MATIS
28 chemin du Vieux Chêne			e-mail : [email-masked]
38243 Meylan Cedex			voice : (+33) 4 76 76 45 22
France					

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: [email-masked]
Date: Tue, 21 Oct 2008 13:27:00 -0500

Yes, the Building Automation community has a similar but different 
problem.  Here due to the constraints of the wireless network (e.g. ZigBee 
at 240kbps), vendors don't necessarily want to allow their devices to be 
routing devices for others under the fear that their network and processor 
bandwidth might be severely tapped.  Remember that sensor/controller 
devices are primarily mission critical application devices that perform 
routing as a secondary function.  In existing wireless sensor networks 
(e.g. ZigBee) this is handled as a security issue.  That is, if I own the 
network key, I will only hand it out to devices I know are well-behaved 
and dovetail with my application.

I would think in ROLL, we would need this same type of functionality, but 
I would hope it's not a routing issue.  We wouldn't want to load down a 
device to make on-the-fly routing decisions about which nodes it can 
route..  I would much prefer to leave it a security issue.  Once a device 
has security clearance and is a part of the WPAN, it can then route 
through any other routing device already on the WPAN.

<[email-masked]> 
Sent by: [email-masked]
10/21/2008 12:11 PM

To
<[email-masked]>
cc

Subject
[Roll] LLN routing different end-customers data

Hello all, 
The question has been raised among the authors of the "Urban sensor 
network routing requirements", but it might pertain to other market 
segments as well, so here it is :
My take is that an urban sensor network infrastructure might support 
applications for different end users, potentially owning their private 
sensor nodes. It seems legitimate that they will only be willing to 
participate in forwarding their own data (because their nodes are likely 
to be battery powered). In contrast, the "backbone" composed of less 
power-constrained devices (maybe owned by a main contractor or service 
provider) would forward the traffic of all users.
Is this case also envisaged in the building automation or other contexts? 
To accomodate for this case, shall we have some language that some nodes 
may elect to only participate in forwarding some flows? Or can we keep mum 
on this in the routing requirements if nothing is written that precludes 
it?
Is anybody willing to offer his/her views on the implications on routing 
security? 
Thanks for your insights, and best regards 
Dominique 
Dominique BARTHEL
France Télécom Division R&D             TECH/MATIS 
28 chemin du Vieux Chêne                        e-mail : 
[email-masked] 
38243 Meylan Cedex                      voice : (+33) 4 76 76 45 22 
France                                  
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Kris Pister <[email-masked]>
Date: Tue, 21 Oct 2008 16:54:22 -0700

I agree with Jerry.  I do think that there is an important difference in 
perspective between commercial WSN deployers and the "typical" IETF 
person (if such a person exists :) )
Talking with Pascal about routing, he said CIA, and I immediately 
thought, along the same lines as Jerry, "yes that's right - 
confidentiality, integrity, authenticity - lock down the network with 
solid crypto and you don't need to worry about routing attacks".  But 
that's not at all what Pascal was thinking.  To him, it meant 
Capability, Innocuousness, and Anonymity.  I'll let him elaborate if he 
wants to, but basically the idea was to let anyone who wants to join the 
party, and just try to minimize their damage if they choose not to play 
nice.

When I first started selling WSN vision, I imagined a serene world of 
shared resources.  To each mote according to its need, from each 
according to its ability, and the withering away of the network 
management entity.  When I stopped selling vision and started selling 
products, my mote world view shifted dramatically to the right! :)

I don't know what the right answer is.  I'd like to see the serene 
vision happen, but I can't picture how it's possible.

ksjp

[email-masked] wrote:
> problem.  Here due to the constraints of the wireless network (e.g. 
> ZigBee at 240kbps), vendors don't necessarily want to allow their 
> devices to be routing devices for others under the fear that their 
> network and processor bandwidth might be severely tapped.  Remember 
> that sensor/controller devices are primarily mission critical 
> application devices that perform routing as a secondary function.  In 
> existing wireless sensor networks (e.g. ZigBee) this is handled as a 
> security issue.  That is, if I own the network key, I will only hand 
> it out to devices I know are well-behaved and dovetail with my 
> application.
>
> I would think in ROLL, we would need this same type of functionality, 
> but I would hope it's not a routing issue.  We wouldn't want to load 
> down a device to make on-the-fly routing decisions about which nodes 
> it can route..  I would much prefer to leave it a security issue. 
>  Once a device has security clearance and is a part of the WPAN, it 
> can then route through any other routing device already on the WPAN.
>
>
>
>
> *<[email-masked]>*
> participate in forwarding their own data (because their nodes are 
> likely to be battery powered). In contrast, the "backbone" composed of 
> less power-constrained devices (maybe owned by a main contractor or 
> service provider) would forward the traffic of all users.
>
> To accomodate for this case, shall we have some language that some 
> nodes may elect to only participate in forwarding some flows? Or can 
> we keep mum on this in the routing requirements if nothing is written 
> that precludes it?
>
> *Dominique BARTHEL*
> *France Télécom** **Division R&D             TECH/MATIS*
> 28 chemin du Vieux Chêne                        e-mail :_ 
> [email-masked]
> ------------------------------------------------------------------------
>

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 29 Oct 2008 15:31:37 +0100

Hi Krister 

I understand the concern of security in industrial plants and the like. 

Home control is a more price sensitive market and the potential interest of someone to turn on a light in a private home may be lower. 

Therefore, I suggest that routers and end nodes MAY support encryption, authentication and the like.
For price reasons, I would expect that only border routers, door locks and the like would implement security.
It MUST be possible to design low-cost devices running ROLL. Obviously, secure routing MUST be used all the way if
a packet requires secure routing.

br. Anders

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: 22. oktober 2008 01:54
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] LLN routing different end-customers data

I agree with Jerry.  I do think that there is an important difference in perspective between commercial WSN deployers and the "typical" IETF person (if such a person exists :) )
Talking with Pascal about routing, he said CIA, and I immediately thought, along the same lines as Jerry, "yes that's right - confidentiality, integrity, authenticity - lock down the network with solid crypto and you don't need to worry about routing attacks".  But that's not at all what Pascal was thinking.  To him, it meant Capability, Innocuousness, and Anonymity.  I'll let him elaborate if he wants to, but basically the idea was to let anyone who wants to join the party, and just try to minimize their damage if they choose not to play nice.

When I first started selling WSN vision, I imagined a serene world of shared resources.  To each mote according to its need, from each according to its ability, and the withering away of the network management entity.  When I stopped selling vision and started selling products, my mote world view shifted dramatically to the right! :)

I don't know what the right answer is.  I'd like to see the serene vision happen, but I can't picture how it's possible.

ksjp

	Yes, the Building Automation community has a similar but different problem.  Here due to the constraints of the wireless network (e.g. ZigBee at 240kbps), vendors don't necessarily want to allow their devices to be routing devices for others under the fear that their network and processor bandwidth might be severely tapped.  Remember that sensor/controller devices are primarily mission critical application devices that perform routing as a secondary function.  In existing wireless sensor networks (e.g. ZigBee) this is handled as a security issue.  That is, if I own the network key, I will only hand it out to devices I know are well-behaved and dovetail with my application. 
	
	I would think in ROLL, we would need this same type of functionality, but I would hope it's not a routing issue.  We wouldn't want to load down a device to make on-the-fly routing decisions about which nodes it can route..  I would much prefer to leave it a security issue.  Once a device has security clearance and is a part of the WPAN, it can then route through any other routing device already on the WPAN. 

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

10/21/2008 12:11 PM 

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

Subject

	Hello all, 

	Dominique BARTHEL 

	France                                  _______________________________________________

________________________________

---

From: Kris Pister <[email-masked]>
Date: Thu, 30 Oct 2008 10:14:04 -0700

Anders - I understand the concern over price.  Hopefully we can come up 
with a security approach that does not have a significant impact on 
price.  I just hate the idea of seeing a fledgling industry show up on 
the front page of the newspaper "Hackers take over lighting networks".  
If it becomes easy to turn on and off the lights in private residences 
using your cell phone or PC, you know that kids will start doing it just 
for fun, and then we'll have to go in and fix the security 
retroactively.  Ick.

ksjp

Anders Brandt wrote:
> Home control is a more price sensitive market and the potential 
> interest of someone to turn on a light in a private home may be lower.
>
> It MUST be possible to design low-cost devices running ROLL. 
> Obviously, secure routing MUST be used all the way if
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Kris Pister
> *Sent:* 22. oktober 2008 01:54
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [Roll] LLN routing different end-customers data
>
> I agree with Jerry.  I do think that there is an important difference 
> in perspective between commercial WSN deployers and the "typical" IETF 
> Capability, Innocuousness, and Anonymity.  I'll let him elaborate if 
> he wants to, but basically the idea was to let anyone who wants to 
> join the party, and just try to minimize their damage if they choose 
> not to play nice.
>
>> applications for different end users, potentially owning their 
>> private sensor nodes. It seems legitimate that they will only be 
>> willing to participate in forwarding their own data (because their 
>> nodes are likely to be battery powered). In contrast, the "backbone" 
>> composed of less power-constrained devices (maybe owned by a main 
>> contractor or service provider) would forward the traffic of all users.
>>

---

From: "Anders Brandt" <[email-masked]>
Date: Fri, 31 Oct 2008 09:03:19 +0100

Kris,
 
Sure - I agree that we should come up with a "sufficiently secure" solution to prevent kiddies from playing with the stuff.
On the other hand, we do not necessarily have to be safe from watercooled CPU key attacks in the home control domain.
 
- Anders

From: Kris Pister [mailto:[email-masked]] 
Sent: 30. oktober 2008 18:14
To: Anders Brandt
Cc: [email-masked]
Subject: Re: [Roll] LLN routing different end-customers data

Anders - I understand the concern over price.  Hopefully we can come up with a security approach that does not have a significant impact on price.  I just hate the idea of seeing a fledgling industry show up on the front page of the newspaper "Hackers take over lighting networks".  If it becomes easy to turn on and off the lights in private residences using your cell phone or PC, you know that kids will start doing it just for fun, and then we'll have to go in and fix the security retroactively.  Ick.

ksjp

Anders Brandt wrote: 

	Hi Krister 

	br. Anders

	

	ksjp

		

10/21/2008 12:11 PM 

To

Subject

		Hello all, 

		Dominique BARTHEL

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Oct 2008 16:07:29 +0100

Can¹t agree more. Security in LLN is of utmost importance in many
environments: industrial, Smart Grid, Building, ... This is one of our WG
item.

On 10/30/08 6:14 PM, "Kris Pister" <[email-masked]> wrote:

> Anders - I understand the concern over price.  Hopefully we can come up with a
> security approach that does not have a significant impact on price.  I just
> hate the idea of seeing a fledgling industry show up on the front page of the
> newspaper "Hackers take over lighting networks". If it becomes easy to turn on
> and off the lights in private residences using your cell phone or PC, you know
> that kids will start doing it just for fun, and then we'll have to go in and
> fix the security retroactively.  Ick.
> 
> ksjp
> 
> Anders Brandt wrote:
>>    
>>   
>> 
>> Hi Krister 
>>   
>> 
>> Home control is a more price sensitive market and the potential interest of
>> someone to turn on a light in a private home may be lower.
>>  
>> 
>>  It MUST be possible to design low-cost devices running ROLL. Obviously,
>> secure routing MUST be used all the way if
>> perspective between commercial WSN deployers and the "typical" IETF person
>> (if such a person exists :) )
>> Talking with Pascal about routing, he said CIA, and I immediately thought,
>> along the same lines as Jerry, "yes that's right - confidentiality,
>> integrity, authenticity - lock down the network with solid crypto and you
>> don't need to worry about routing attacks".  But that's not at all what
>> Pascal was thinking.  To him, it meant Capability, Innocuousness, and
>> Anonymity.  I'll let him elaborate if he wants to, but basically the idea was
>> to let anyone who wants to join the party, and just try to minimize their
>> damage if they choose not to play nice.
>>  
>> When I first started selling WSN vision, I imagined a serene world of shared
>> resources.  To each mote according to its need, from each according to its
>> ability, and the withering away of the network management entity.  When I
>> stopped selling vision and started selling products, my mote world view
>> shifted dramatically to the right! :)
>>  
>> I don't know what the right answer is.  I'd like to see the serene vision
>> happen, but I can't picture how it's possible.
>>  
>> ksjp
>>  
>>>  Yes, the Building Automation community has a similar but different problem.
>>> Here due to the constraints of the wireless network (e.g. ZigBee at
>>> 240kbps), vendors don't necessarily want to allow their devices to be
>>> bandwidth might be severely tapped.  Remember that sensor/controller devices
>>> are primarily mission critical application devices that perform routing as a
>>> secondary function.  In existing wireless sensor networks (e.g. ZigBee) this
>>> is handled as a security issue.  That is, if I own the network key, I will
>>> only hand it out to devices I know are well-behaved and dovetail with my
>>> application. 
>>>  
>>>  I would think in ROLL, we would need this same type of functionality, but I
>>> would hope it's not a routing issue.  We wouldn't want to load down a device
>>> to make on-the-fly routing decisions about which nodes it can route..  I
>>> would much prefer to leave it a security issue.  Once a device has security
>>> clearance and is a part of the WPAN, it can then route through any other
>>> routing device already on the WPAN.
>>>  
>>>  
>>>  
>>>  
>>>    
>>> <mailto:[email-masked]>
>>>  Sent by: [email-masked] 10/21/2008 12:11 PM
>>>   To 
>>> The question has been raised among the authors of the "Urban sensor network
>>> routing requirements", but it might pertain to other market segments as
>>> well, so here it is :
>>>  
>>> 
>>> participate in forwarding their own data (because their nodes are likely to
>>> be battery powered). In contrast, the "backbone" composed of less
>>> To accomodate for this case, shall we have some language that some nodes may
>>> elect to only participate in forwarding some flows? Or can we keep mum on
>>> this in the routing requirements if nothing is written that precludes it?
>>>  
>>>

---

From: "Miguel Sanchez" <[email-masked]>
Date: Fri, 31 Oct 2008 17:58:42 +0100

Hi Dominique,

> Is anybody willing to offer his/her views on the implications on routing

Ownership of a node in practical (and may be in legal) terms gives
full power over the node behavior: what type of traffic they'll be
forwarding or not. It seems to me that a company will only be willing
to forward traffic from other devices if it makes sense to them.

Security framework needs to allow node owner/admin not to forward
undesired traffic. The way I see it this comes down to authorization.
Each node needs to get network authorization to be able to transmit
traffic onto a network. Each network needs to get authorization to be
able to forward traffic onto another network (I'm thinking here on a
similar idea as the Autonomous System on the Internet, those who own
each network make the rules for it).

Does it make sense?

Regards,

Miguel Sánchez