Subject: Re: [Roll] security update?

From: [email-masked]
Date: Wed, 1 Apr 2009 09:42:55 -0500

Kris,

I think having network security is an important requirement of ROLL. 
However, my opinion is it's too early to mandate network security to be 
always 'turned on'.  Empirical testing on 802.15.4 based systems show 33 
to 50% degradation in network performance when security was turned 'on'. 
This is primarily due to needing to decrypt and re-encrypt every packet at 
every hop.  If the security model only encrypts the pay load, then it 
needn't be decrypted/encrypted at each hop.  Furthermore the AES integrity 
code can chew up up to 16 bytes of the available 802.15.4 80 byte payload

Secondly, we would not want security turned 'on' while in the 
'configuration' mode.  We have a strong requirement for zero-based 
configuration.  Having to add network and application keys and installing 
trust centers just to get a temperature sensor working in a vacant 
building is a bit overkill.

I think the default 'out-of-the-box' security profile should be 'off'. 
Once the device is configured and on the operational network, I have no 
issue with requiring encryption and authentication if it doesn't impinge 
on the constrained processing power or the payload size.

Jerry

Kris Pister <[email-masked]> 
Sent by: [email-masked]
03/26/2009 08:39 AM

To
ROLL WG <[email-masked]>
cc

Subject
[Roll] security update?

Since we weren't able to get an update on the security draft at this 
meeting, perhaps we could get an email summary?

I'm confident that we can come up with a good routing protocol, and I'm 
100% certain that the networks it serves will be attacked.  We need to 
come up with something that is strong, but simple enough that everyone 
uses it by default.  My strong preference would be that security is an 
intrinsic part of the routing protocol, and can't be "turned off".

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

---

From: Kris Pister <[email-masked]>
Date: Wed, 01 Apr 2009 10:57:50 -0700

Jerry -  I'm hopeful that we can come up with something that is 
light-weight enough that people won't notice the impact, and so the 
default will be to leave it on.  That's a challenge, I realize, and even 
if we achieve it, some people will still want to leave security off.

I'm pretty surprised by some of your numbers.  In the systems that I'm 
familiar with, security adds only a few percent at most to the overall 
energy/time/bw cost.
Can you share any of the details of the experiments that showed a 33-50% 
hit due to security?  The AES engine on most 15.4 chips can generate or 
verify a MIC for less than the energy cost of sending or receiving a 
single bit over the radio.  Even in software on an 8 bit processor it's 
still a small fraction of the communication cost, for radio systems 
anyway.  Maybe it's different for PLC?
I would imagine that we'd use at most a 4 byte MIC, perhaps even 
smaller.  That does cut into payload space, but it would be on the whole 
IP packet - for small packets it wouldn't be a problem, and for big 
packets they're going to be fragmented anyway.

I'm in complete agreement on the need for an operation mode with 
zero-configuration.  The challenge will be to come up with something 
that still gives some degree of protection there.  I'll know we've 
succeeded if we can convince you that it's ok!

ksjp

[email-masked] wrote:
>  However, my opinion is it's too early to mandate network security to 
> be always 'turned on'.  Empirical testing on 802.15.4 based systems 
> show 33 to 50% degradation in network performance when security was 
> turned 'on'.  This is primarily due to needing to decrypt and 
> re-encrypt every packet at every hop.  If the security model only 
> encrypts the pay load, then it needn't be decrypted/encrypted at each 
> hop.  Furthermore the AES integrity code can chew up up to 16 bytes of 
> the available 802.15.4 80 byte payload
>
> configuration.  Having to add network and application keys and 
> installing trust centers just to get a temperature sensor working in a 
> vacant building is a bit overkill.
>
>  Once the device is configured and on the operational network, I have 
> no issue with requiring encryption and authentication if it doesn't 
> impinge on the constrained processing power or the payload size.
>
> Jerry
>
>
>
>
>
>
> *Kris Pister <[email-masked]>*

---

From: JP Vasseur <[email-masked]>
Date: Thu, 2 Apr 2009 07:45:22 +0200

Hi,

On Mar 31, 2009, at 3:21 PM, Tzeta Tsao wrote:

> Hi Kris, All,
>
> We are indeed working on an update to the security draft and will
> present it once the revision is in shape. At the same time, I welcome,
> and I believe other authors, too, any comments and suggestions.
>

All, please provide some feed-back to the authors.

Just so you know, we are also looking at other contributors to help  
there. This is a key
WG item and we do want to address these aspects in parallel with the  
routing design
effort and clearly not at the last minute.

> I share the view that security should be an integral part of a ROLL
> protocol, but not an after-the-fact extension. In fact, even  
> considering
> such diversified applications and capabilities of the LLN devices, I
> still hope this working group will come to the consensus that the
> stipulation should be such that an implementation of a ROLL protocol  
> may
> choose not to conform rather than be given the choice of reduced
> security services.

Security requirements do vary with the applications and can range from  
none to high
level of security. Thus the routing protocol must be designed to turn  
on or off several of
the security features.

Thanks.

JP.

> Regards,
> Tzeta
> Kris Pister wrote:
>> I'm confident that we can come up with a good routing protocol, and
>> I'm 100% certain that the networks it serves will be attacked.  We
>> need to come up with something that is strong, but simple enough that
>> everyone uses it by default.  My strong preference would be that
>> security is an intrinsic part of the routing protocol, and can't be
>> "turned off".
>>
>> ksjp

---

From: Kris Pister <[email-masked]>
Date: Thu, 02 Apr 2009 11:04:56 -0700

Tzeta - there is a lot of great stuff in your document, and our 
challenge is to distill it down to a minimal set of things to put into 
the first draft of the protocol.
So far only "MUST"s are
* MUST verify the liveliness of both principals of a connection;
* MUST verify message freshness;
* MUST verify message sequence and integrity
* If a LLN employs multicast and/or anycast, it MUST secure these 
protocols with the services listed in this sections. Furthermore, the 
nodes MUST provide adequate physical tamper resistance to ensure the 
integrity of stored routing information.

and then two SHOULDs:
* SHOULD provide payload encryption
* SHOULD provide privacy

With that as background, how do you feel about using something similar 
to OSPF authentication as a starting point?  The security contents would 
be something like:
<flags>, <optional fields>
and conceptually at least the flags might be:
0 no authentication - no optional fields, probably no overhead at all if 
we can use 1 bit in the header
1 well-known key - no configuration necessary, optional fields contain MIC
2 shared key - configured, optional fields contain nonce counter, MIC
3 public key - no configuration necessary, optional fields contain certs 
and/or signature

Does this seem like at least a framework to start with?

ksjp

JP Vasseur wrote:
>> protocol, but not an after-the-fact extension. In fact, even considering
>> stipulation should be such that an implementation of a ROLL protocol may

---

From: Tzeta Tsao <[email-masked]>
Date: Thu, 02 Apr 2009 17:43:28 -0400

Kris,

In a way, we may say that the mechanism used in OSPF, or RIP, reflects
generally accepted practice in this field, which allows no
authentication; if it eventually becomes the consensus of the ROLL WG,
we will have to change the language from MUSTs to SHOULDs in the
security framework draft.

But I need to point out that the current Internet has so much human
effort devoted to its management, while in contrast, it is a stated goal
that a LLN should have minimal or even be autonomous; I wonder if that
does not prompt for a need of more security for LLNs?

Regards,
Tzeta

Kris Pister wrote:
> to OSPF authentication as a starting point?  The security contents
> would be something like:
> 0 no authentication - no optional fields, probably no overhead at all
> if we can use 1 bit in the header
> 3 public key - no configuration necessary, optional fields contain
> certs and/or signature
>
>> Security requirements do vary with the applications and can range
>> from none to high

---

From: JP Vasseur <[email-masked]>
Date: Fri, 3 Apr 2009 07:13:49 +0200

Hi Tzeta,

> does not prompt for a need of more security for LLNs?

How do you come up with the conclusion that minimal configuration  
implies
more security ?

Thanks.

JP.

>> 1 well-known key - no configuration necessary, optional fields  
>> contain
>> MIC

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 3 Apr 2009 10:59:40 +0100

> implies more security ?

I thought his possible (he says "I wonder") conclusion was a need for
more security, not achieving more security. While I'm not sure it's
the minimal configuration that's the only reason why, a scenario where
devices are distributed without either human attendance or continual
monitoring certainly raises some difficult security issues.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: JP Vasseur <[email-masked]>
Date: Mon, 6 Apr 2009 08:49:20 +0200

> monitoring certainly raises some difficult security issues.

This is exactly my point. This is not the 0-config requirement that  
requires more security.
Of course 0-config with high security requirements is more challenging.

Cheers.

JP.

---

From: Tzeta Tsao <[email-masked]>
Date: Mon, 06 Apr 2009 12:31:42 -0400

> Of course 0-config with high security requirements is more challenging.
Hi JP, All:

It may be true that 0-config itself does not call for more security.

It is the additional requirement of autonomous operation that deployed
LLN devices
will not have either human attendance or continual monitoring that
prompts the
question of whether these devices need more security.

LLNs of smaller number of devices may or may not have a problem of
getting human
intervention when disasters occur; LLNs with tens of thousands of
devices cannot
rely on such procedures. The model of having an operator going up to a
router to
reconfigure is not widely applicable to LLNs. It is mission critical for
certain types of
LLNs to be secure out-of-the-box, even for their entire life-cycle, without
reconfiguration.

Would people, especially who work on smaller sized LLNs, offer some insight.

Regards,
Tzeta

---

From: Robert Kavaler <[email-masked]>
Date: Mon, 06 Apr 2009 22:22:54 -0700

Our application consists of a relatively small number of sensors and 
routers in any given cluster (maybe 50 sensors, 4 repeaters, 1 access 
point is a typical cluster).  We had two issues when we implemented 
security: key distribution and the number of keys required.

We used a simple scheme based on private keys and a NONCE. The idea of 
being secure out of the box is a difficult one because somehow you need 
to get at least one key (in our case two) into each unit before it is 
deployed.  For our application, once a sensor is deployed you cannot get 
to it again, ever (they are embedded in the roadway). One can insert a 
private key into each unit and ship these keys along with the units so 
that any peer might be able to communicate with the unit.  Unfortunately 
this didn't work for a couple reasons: first our customers did not like 
the idea that even we knew the key for each unit and second this method 
requires that a router have a list of keys, one for each sensor that it 
must talk with. The customer ended up installing their own keys with 
some special hardware we developed.

The second issue is defining the total number of keys involved. We opted 
for a one key per application approach. One application was the 
routing/configuration/synchronization application. For us, these three 
applications are embedded in the same packet.  This application uses a 
single key for all sensors, repeaters and access points in a given 
cluster (a PAN). The second application was our reporting application, 
which would encrypt "data" packets with a per sensor key. Thus each 
sensor had two keys, each repeater and access point had one key, and the 
processing application, which ran on a external server, had lots of keys 
(the peers of the sensor keys).

Robert Kavaler
www.sensysnetworks.com

---

From: [email-masked]
Date: Tue, 7 Apr 2009 08:36:09 -0500

Tzeta,

Per your request, here are my comments on LLNs being installed in 
Commercial Buildings...

Most automation companies install sensors and controllers into a building. 
 These devices may be installed over a fairly wide time frame, yet must 
somehow be able to easily coalesce into a single LLN all operating under a 
single parameter set.  This coalescence of various geographical (e.g. 
Floor 1, Floor 2, Floor 2) and logical building functions (Fire, Security, 
HVAC) is difficult process further complicated by the need to address 
network security issues.  These devices are typically not customizable 
prior to delivery to the site.  They are shrink-wrapped clones that differ 
only be their unique MAC address.

In the commercial building sector, devices must come 'out of the box' with 
no security turned 'on'.  This allows for tradesmen (electricians) to 
install the devices into a partially constructed building and verify 
operation without requiring sophisticated on-site device programming of 
network and link keys.  We also cannot count on any IT devices (DHCP, L2 
switches, L3 routers, AAA servers) being previously installed and 
operational.

Once the system is totally constructed the need for network security is 
variable based on the building occupant(s).  For example a single tenant 
owner occupied office building has little security threat and hence need 
little to no active security policy in place.  A multi-tenant facility 
will require a higher layer of security to isolate the individual building 
occupants.  A pharmaceutical or military facility will require a very high 
level of security.  This security policy must be deployable from a central 
location since (as Robert Kavalar also points out in the urban market) 
many of these devices are now hidden under dry wall or above the ceiling 
grid.

So in summary, for the commercial building sector, we need devices that 
can be installed with no security, ramped up to various levels of security 
once operational that must be downloaded with the security policy from a 
centralized source.  This centralized source most often will not be 
available during the installation phase.

Hope this helps.

Jerry Martocci

Tzeta Tsao <[email-masked]> 
Sent by: [email-masked]
04/06/2009 11:32 AM

To
JP Vasseur <[email-masked]>
cc
"Dearlove, Christopher \(UK\)" <[email-masked]>, ROLL WG 
<[email-masked]>
Subject
Re: [Roll] simple security (Re:  security update?)

Hi JP, All:

LLNs to be secure out-of-the-box, even for their entire life-cycle, 
without
reconfiguration.

Would people, especially who work on smaller sized LLNs, offer some 
insight.

Regards,
Tzeta

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 7 Apr 2009 14:44:30 +0100

JPV
> Of course 0-config with high security requirements is more
challenging.

Which means that in at least some ROLL scenarios you have
- High security requirements.
- Serious threats (e.g. due to unattended devices).
- Zero or limited pre-configuration.
- A desire/need for decentralisation.

I think challenging is a good word.

(I could have added a fifth point of limited resources to use
on the problem.)

---

From: Kris Pister <[email-masked]>
Date: Tue, 07 Apr 2009 08:37:20 -0700

Jerry - good input.  I have one correction and one opinion:
 >> devices must come 'out of the box' with no security turned 'on'.

I completely agree with the need for 0-config on security.  We ship into 
an industry in which (customer quote) "the only tools the installer 
knows how to use are a sledge hammer and a blowtorch." :)
This does NOT mean that the networks must have no security.  There are 
simple security mechanisms that allow such networks to be built with 
0-config, and still maintain many/most/all of the desired security 
properties.

 >> office building has little security threat and hence need little to 
no active security policy in place

In my opinion, it won't take hackers very long to figure out that they 
can have a lot of fun taking over HVAC and lighting systems in office 
buildings.  It won't take very many such takeovers before 1) everyone 
demands more security, or 2) people abandon the technology altogether.

ksjp

[email-masked] wrote:
> Most automation companies install sensors and controllers into a 
> building.  These devices may be installed over a fairly wide time 
> frame, yet must somehow be able to easily coalesce into a single LLN 
> all operating under a single parameter set.  This coalescence of 
> various geographical (e.g. Floor 1, Floor 2, Floor 2) and logical 
> building functions (Fire, Security, HVAC) is difficult process further 
> complicated by the need to address network security issues.  These 
> devices are typically not customizable prior to delivery to the site. 
>  They are shrink-wrapped clones that differ only be their unique MAC 
> address.
>
> In the commercial building sector, devices must come 'out of the box' 
> with no security turned 'on'.  This allows for tradesmen 
> (electricians) to install the devices into a partially constructed 
> building and verify operation without requiring sophisticated on-site 
> device programming of network and link keys.  We also cannot count on 
> any IT devices (DHCP, L2 switches, L3 routers, AAA servers) being 
> previously installed and operational.
>
> Once the system is totally constructed the need for network security 
> is variable based on the building occupant(s).  For example a single 
> tenant owner occupied office building has little security threat and 
> hence need little to no active security policy in place.  A 
> multi-tenant facility will require a higher layer of security to 
> isolate the individual building occupants.  A pharmaceutical or 
> military facility will require a very high level of security.  This 
> security policy must be deployable from a central location since (as 
> Robert Kavalar also points out in the urban market) many of these 
> devices are now hidden under dry wall or above the ceiling grid.
>
> So in summary, for the commercial building sector, we need devices 
> that can be installed with no security, ramped up to various levels of 
> security once operational that must be downloaded with the security 
> policy from a centralized source.  This centralized source most often 
> will not be available during the installation phase.
>
> Hope this helps.
>
> Jerry Martocci
>
>
>
>
>
> *Tzeta Tsao <[email-masked]>*
> 	"Dearlove, Christopher \(UK\)" <[email-masked]>, ROLL 
> WG <[email-masked]>
> Subject
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Tue, 7 Apr 2009 13:41:22 -0500

Agreed. 

My comments were based on our existing products.  I don't have a problem 
if out-of-the box security is turned on if it's with a well-known network 
key.  Maybe when a device is in 'ad hoc' mode (as would be done durng 
commissioning) it can run open, but in 'infrastructure' mode it must have 
at least a network key.

I have the same guys installing our systems as you do.  We somehow have to 
lower the system complexity during the commission phase so we don't need a 
degreed IT professional installing our temperature sensors!!!

Jerry

04/07/2009 10:37 AM

To
[email-masked]
cc
Tzeta Tsao <[email-masked]>, "Dearlove, Christopher (UK)" 
<[email-masked]>, ROLL WG <[email-masked]>, 
[email-masked]
Subject
Re: [Roll] simple security (Re:  security update?)

I completely agree with the need for 0-config on security.  We ship into 
an industry in which (customer quote) "the only tools the installer knows 
how to use are a sledge hammer and a blowtorch." :)
This does NOT mean that the networks must have no security.  There are 
simple security mechanisms that allow such networks to be built with 
0-config, and still maintain many/most/all of the desired security 
properties.

>> office building has little security threat and hence need little to no 
active security policy in place

In my opinion, it won't take hackers very long to figure out that they can 
have a lot of fun taking over HVAC and lighting systems in office 
buildings.  It won't take very many such takeovers before 1) everyone 
demands more security, or 2) people abandon the technology altogether.

ksjp

Tzeta, 

Hope this helps. 

Jerry Martocci 

To

Hi JP, All:

Regards,
Tzeta

---

From: Kris Pister <[email-masked]>
Date: Tue, 07 Apr 2009 12:41:44 -0700

I can throw out a couple of ideas on how one might implement 0-config 
security.
My goal for the draft is to provide enough flexibility that people can 
implement the things that they want, without placing any burden on those 
who don't want.
The details of security policy are out of scope - we're not trying to 
prescribe anything - but the underlying mechanisms are in scope.

With that in mind, here are some examples of things that people might 
want to do.
* Association by physical contact.  Eaton has a nice solution on their 
Home Heartbeat system.  When you buy an off-the-shelf, 0-config, 
shrink-wrapped, 3rd party sensor for your home automation system, you 
just slide the new device across the surface of the "gateway", and 
security information is exchanged.  Done right, this provides 
essentially everything that you could want: IDs can be registered in 
access control lists, unique keys can be generated and installed in both 
devices, etc.  The "gateway" can be in a physically secure location.

* Association by RF proximity to the gateway.  As above, but without 
physical contact.  1-hop to a very low power transceiver (or near-field 
transceiver) in a physically secure location.

* Association by push-button.  Along the lines of cell-phone pairing 
with bluetooth ear-phone, having a button on one or more devices 
provides a mechanism to limit any open-air exchanges to a brief (seconds 
to minutes) period of time.

* Association by pre-installed certificates.  This requires PK, which 
requires roughly 10kB/1kB program/data, and roughly one second of 
processing time.  Prohibitively expensive for many applications, 
perfectly acceptable for others.

* Association by physical plug-in.  Like a cell-phone SIM card.

All of these mechanisms get used in different applications today.  Some 
of them will get used in LLNs.  We don't need to define much in RoLL to 
allow people to build higher-layer stuff like this on top of our protocol.

ksjp

Dearlove, Christopher (UK) wrote:
> JPV
>   
>> Of course 0-config with high security requirements is more
>>     
> challenging.
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 7 Apr 2009 13:09:13 -0700

Completely agree with Kris and all of the mechanisms he mentioned work  
and have been used for years. Though I do think that naming the goal  
"0-config" is a non-starter. The association process needs to have a  
human in the loop. Even for the simple case where no security is  
required, nodes still need to know what network to join. Maybe its  
better to say something along the lines of "1-step binary human  
interface config."

In some workflows it is possible to separate the person that  
physically installs the device from the one that associates the  
device. This is the only case where "0-config" makes any sense to me  
and it only makes sense from the view of the physical installer.

--
Jonathan Hui

On Apr 7, 2009, at 12:41 PM, Kris Pister wrote:

> I can throw out a couple of ideas on how one might implement 0- 
> config security.
> My goal for the draft is to provide enough flexibility that people  
> can implement the things that they want, without placing any burden  
> on those who don't want.
> The details of security policy are out of scope - we're not trying  
> to prescribe anything - but the underlying mechanisms are in scope.
>
> With that in mind, here are some examples of things that people  
> might want to do.
> * Association by physical contact.  Eaton has a nice solution on  
> their Home Heartbeat system.  When you buy an off-the-shelf, 0- 
> config, shrink-wrapped, 3rd party sensor for your home automation  
> system, you just slide the new device across the surface of the  
> "gateway", and security information is exchanged.  Done right, this  
> provides essentially everything that you could want: IDs can be  
> registered in access control lists, unique keys can be generated and  
> installed in both devices, etc.  The "gateway" can be in a  
> physically secure location.
>
> physical contact.  1-hop to a very low power transceiver (or near- 
> field transceiver) in a physically secure location.
>
> provides a mechanism to limit any open-air exchanges to a brief  
> (seconds to minutes) period of time.
>
> * Association by pre-installed certificates.  This requires PK,  
> which requires roughly 10kB/1kB program/data, and roughly one second  
> of processing time.  Prohibitively expensive for many applications,  
> All of these mechanisms get used in different applications today.   
> Some of them will get used in LLNs.  We don't need to define much in  
> RoLL to allow people to build higher-layer stuff like this on top of  
> our protocol.
>
> ksjp
>

---

From: Robert Kavaler <[email-masked]>
Date: Tue, 7 Apr 2009 14:03:21 -0700

For our application, we have have found that there is a flip side to
security. Security suggests that it is difficult, if not impossible, to put
a system into a state that the operator/designer does not wish that system
to be in. Said another way, you don't want to let someone hijack your
system. This is especially true if we are talking about security with
routing protocols.

One thing that we found works against most security schemes (for our system)
is recoverability. That is, if something has taken over your system either
intentionally, or if the system has been driven into a bad state because of
programming error or temporary hardware malfunction, we want to be able to
recover that system back to a working state without having to dig up
(literally) our sensors. For some small number of applications this is not
an issue, but for the vast majority of our customers this is a big issue.
The fact that we can recover "lost" sensors after an untrained technician
attempts to install our product, or that we can download new code to a
dysfunctional system to fix it has been a big advantage for us.

My feeling is that it is impossible to guard against all possible sources of
sensor corruption, so we have opted, in general, to make our system easily
visible and recoverable instead of making it "secure".

Let me give you one example of a difficulty associated with strict
security.  Our secure system uses a NONCE that contains a counter to prevent
a playback attack.  Both the transmitter of the packet and the receiver of
the packet must store the counter in nonvolatile memory. If that state is
corrupted then you may not be able to recover the sensor without further
corrupting the state, potentially to the point where the counter saturates
and bricks the sensor. Thus the desire for strict security has made the
device unrecoverable.

These issues can be resolved by layering security features, but I'm
suggesting that recoverability is a nice feature that might trump
traditional security.

Robert Kavaler
www.sensysnetworks.com

On Tue, Apr 7, 2009 at 12:41 PM, Kris Pister <[email-masked]>wrote:

> implement the things that they want, without placing any burden on those who
> don't want.
> With that in mind, here are some examples of things that people might want
> to do.
> * Association by physical contact.  Eaton has a nice solution on their Home
> Heartbeat system.  When you buy an off-the-shelf, 0-config, shrink-wrapped,
> 3rd party sensor for your home automation system, you just slide the new
> device across the surface of the "gateway", and security information is
> exchanged.  Done right, this provides essentially everything that you could
> want: IDs can be registered in access control lists, unique keys can be
> generated and installed in both devices, etc.  The "gateway" can be in a
> * Association by push-button.  Along the lines of cell-phone pairing with
> bluetooth ear-phone, having a button on one or more devices provides a
> mechanism to limit any open-air exchanges to a brief (seconds to minutes)
> period of time.
>
> requires roughly 10kB/1kB program/data, and roughly one second of processing
> time.  Prohibitively expensive for many applications, perfectly acceptable
> for others.
>
> All of these mechanisms get used in different applications today.  Some of
> them will get used in LLNs.  We don't need to define much in RoLL to allow
> people to build higher-layer stuff like this on top of our protocol.
>
> ksjp
>
>
> Roll mailing [email-masked]://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 7 Apr 2009 19:38:02 -0400

Date: Tue, 07 Apr 2009 12:41:44 -0700
   From: Kris Pister <[email-masked]>

   security information is exchanged.

I believe they do this by having a reed switch and a magnet
in the devices.  It's association by push button and RF
proximity, with a different kind of button.

                                  -Richard Kelsey