[6lowapp] Multicast, do we need it

[Cullen Jennings <[e-mail]>]

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.