On Thu, Apr 23, 2015 at 10:19 AM, Thomas Watteyne < [email protected]> wrote:
> Simon, > > Welcome to the list!! > > My general impression is that using MIC for network segregation only is >> overkill. > > > I respectfully disagree :-) CCM* is in all motes, and auth+enc mod is used > on all data packets. On well designed chips, both the time and energy spent > for running CCM* is negligible. > I might be missing your point completely. Can you provide more info about > what you mean by overkill? > Fair enough. I find this overkill conceptually but on good chips this will be cheap enough, agreed. > > * How about defining a 6TiSCH-specific IE (with an ID from the "unmanaged" >> space) to uniquely identify vendors? >> > > I consider the MIC key to essentially play that role. Yet, instead of > sending a explicit field with a vendor identifier it is (e.g. in an IE), > the "vendor identifier" is used as a key for MIC. > If you want the IE to provide the same 16-byte "segregation power" than > CCM, is has to be 2+16 bytes long. A MIC is 4-8 bytes. > Using an IE doesn't prevent from mistaking a random IEEE802.15.4 frame in > the air for a vaid EB. > If you enforce checking of the vendor ID on incoming EB then you filter out others' traffic don't you? One point in favor of having an IE vs. MIC: it makes explicit that we do segregation, nothing else. No-one will be mistaken thinking we're trying to achieve security. For troubleshooting it may also be nice to be able to sniff packets and see vendor IDs rather than having to deal with (non-constant and cryptic) MICs. > >> * If I were Charlie and really needed security, I would ask Alice and Bob >> to provide their sensors with a pre-deployment key setup mechanism, and use >> a pre-shared secret key. > > > This is similar to my conclusion a couple of e-mails ago in this thread, > although I need to insist that the key used for EB authentication doesn't > impact the "security" of your netwokr, as the ream gatekeeper is the JCE. > Agreed. Simon > Thomas > > > On Thu, Apr 23, 2015 at 9:07 AM, Simon Duquennoy <[email protected]> wrote: > >> Dear all, >> >> As I'm new to this list I apologize in advance if I'm missing the obvious. >> >> My general impression is that using MIC for network segregation only is >> overkill. >> >> >> Best regards, >> Simon Duquennoy >> >> >> On Thu, Apr 23, 2015 at 5:14 AM, Xavier Vilajosana < >> [email protected]> wrote: >> >>> Kris, >>> >>> can you explain me >>> >>> "Charlie does some testing of option 1, and finds that when there is a >>> Zelda's Toy Shop >>> near one of his stores, his networks take a *really* long time to join. >>> It seems that >>> Zelda's toys send 15.4e EBs too, and they send a lot of them. The >>> sensors that >>> Alice and Bob sell spend a lot of time and battery energy trying to join >>> the wrong network. >>> Charlie would really like something better than option 1." >>> >>> why if there is no authentication it takes longer that if there is >>> authentication? I understand that if a network sends a lot of EBs other >>> networks will receive the frames despite there is authentication or not. >>> if there is no authentication a node parses the EB and decides to join >>> or not. If the nodes uses a MIC it has to receive the packet as well and >>> check the MIC then decides to join or not. In both cases the nodes receive >>> a lot of EBs so the situation is similar (the only difference is that if we >>> use MIC and the node can decode it the node knows that it is allowed to >>> join that network). >>> >>> I only see benefit if the MIC is used as a filter and this is done >>> automatically by the hw. >>> >>> regards, >>> Xavi >>> >>> 2015-04-22 19:15 GMT+02:00 Kris Pister <[email protected]>: >>> >>>> Alice and Bob make wireless temperature sensors that run a 6tisch stack. >>>> Charlie owns a nationwide chain grocery store and is rolling out 6tisch >>>> everywhere. >>>> Zelda sells wireless toys that use 802.15.4e. >>>> Mallory is always lurking. >>>> >>>> Charlie needs to decide if and how to use message integrity checks on >>>> enhanced beacons. >>>> He thinks that he has three options: >>>> 1) don't use MICs on EBs. >>>> 2) use MICs on EBs, with a secret key >>>> 3) use MICs on EBs, with a well-known key >>>> >>>> Charlie does some testing of option 1, and finds that when there is a >>>> Zelda's Toy Shop >>>> near one of his stores, his networks take a *really* long time to >>>> join. It seems that >>>> Zelda's toys send 15.4e EBs too, and they send a lot of them. The >>>> sensors that >>>> Alice and Bob sell spend a lot of time and battery energy trying to >>>> join the wrong network. >>>> Charlie would really like something better than option 1. >>>> >>>> Charlie decides to use option 2, a MIC with a secret key, and it works >>>> great! The sensors >>>> ignore EBs from Zelda's, and only respond to EBs from his networks. He >>>> asks Alice and Bob >>>> if they are willing to install that secret key before they ship the >>>> sensors to his various >>>> stores, and he's such a big customer that they say sure. He is driving >>>> an industry standard. >>>> >>>> But then Charlie gets worried. He's probably going to end up buying >>>> sensors from >>>> Aaron, Abu, Acacia, and Ada as well. How will he keep his key secret? >>>> Eventually >>>> someone will find it or leak it, and then there will be a big news >>>> story "Charlie's >>>> Markets Hacked!" He imagines himself trying to explain to reporters >>>> that the >>>> MIC key on the EB is just there for network segregation and message >>>> integrity. >>>> He imagines that wouldn't go very well, so he decides option 2 is out. >>>> Maybe >>>> he can just publish the MIC key in the standard? >>>> >>>> But if Charlie uses option 3, a well-known key, Mallory will be able to >>>> spoof EBs. >>>> Of course, if he uses no MIC at all, Mallory will also be able to spoof >>>> EBs. >>>> >>>> What should Charlie do? >>>> >>>> ksjp >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
