Re: [6lowapp] Multicast, do we need it

["Don Sturek" <[e-mail]>]

Hi Cullen,

For the Smart Metering solution, we made the following assumptions:
1)   The Utilities would like to trust the minimum number of devices
2)   Biggest "bang for the buck" (meaning the devices which consume the most
electricity) are Heating and Air Conditioning (by a wide margin).
3)   Utility would like to get additional savings but that can be through
"Energy Management Systems".  Those devices on one side are utility trusted
and on the other side interface to untrusted devices in the home (like the
lighting devices you mentioned).
4)   Utilities would like to see security certificates in trusted devices.
The security bar for untrusted devices is much lower (many times, a simple
shared security key with AES-128 encryption is plenty good on the untrusted
devices according to companies I have talked with producing home automation
products).
5)  The utilities have ways to verify when the Energy Management System is
told to save 20% of usage, agrees it can, and tells the untrusted devices to
optimize usage to save 20%.  The meter in the premise will tell whether the
20% was actually saved or not.

The uptake on this:  The requirements for trusted utility devices (which I
think are far fewer in number) are quite different from untrusted devices.

Don


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Cullen Jennings
Sent: Saturday, October 31, 2009 10:34 AM
To: [e-mail]
Subject: [6lowapp] Multicast, do we need it


So we have a use case now where a light switch gets flicked and  
several lights are perceived by humans as coming on at the same time.

A few people have explained to me that the way we need to meet this is  
the switch multicasts the on command to the lights.

This brings up two questions, reliability and security.

On reliability, I'm assuming we would send an unreliable multicast  
"on" command followed by a reliable unicast "on" command to each light  
individually. Any light that missed the multicast command would be  
delayed until they got the unicast command. Is this assumption correct  
on one way to deal with the reliability issues for things that need  
it? Do people have something else in mind? I could care less what the  
approach is but I want to be able to explain, at a sketch level, what  
the plan is to meet this use case.

Now on to the security. Multicast security, particularly with very  
short messages if obviously solvable but not trivial security issue.  
As far as I can tell, this use case would force us to have a object  
security model. I don't pretend to be a security person in the  
slightest so hopefully I won't get the next part too wrong but someone  
who has a clue can correct me. Say were doing AES in CBC mode with a  
96 byte MAC - It seems that the object will need to have somewhere in  
the order of:

IV 16 bytes
Mac 12 bytes
Key identifiers 4 bytes
time or sequence replay protection 4 bytes
Various version code points 4 bytes
Padding 1 to 16 bytes

The smallest message possible is already looking like 56 bytes. One  
can argue any of these numbers up or down but my point is, I don't  
know if our effective MTU is 40,50,60, 128, or 1200. Various people  
have asserted all the above numbers and I understand that the real  
answer is not going to be hard and fast and it all depends. But it  
seems like we might be in the range where it's feasible to use CMS,  
perhaps with AES in CBC mode with HMAC-SHA-96 and some sort of scheme  
wit unicast challenge response to set up a sliding sequence counter  
window for replay protection or perhaps AES with CTR mode might be  
able to make it smaller. I'm not proposing this group would do this  
type of security work, I imagine we would go find it in something  
existing but this is just a back of envelope calculation on the lower  
bound of object security approach.

And this brings up a a whole other issue, how to do replay protection  
on multicast messages. Clearly replaying the "unlock door" command  
would not be good. I have a hard time imaging anyone being keen on  
synchronized time between the devices.

I've also seen that whatever discovery protocol is done might also  
need to use some secure multicast.

So I am working on the assumption that we need multicast and we need  
object security inside it. And that this complicated out lives  
particularly if we want the messages to be small. Do folks agree this  
assumption? If folks agree, any ideas on what existing security  
standards we can use. I'd probably start by looking at what could be  
done with CMS. IS that a good starting point? One or two people  
suggested to me that we could use EAP but I don't know if they meant  
for this or something else.

So as always, back to my usual questions, what is it people want to do  
for any of this. If there looks like there might be agreement, I can  
try and figure out what would be needed in the charter.








_______________________________________________
6lowapp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowapp