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. * How about defining a 6TiSCH-specific IE (with an ID from the "unmanaged" space) to uniquely identify vendors? * 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. 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
