Qin, You are right. Hence the ability to change the MIC key if you want to.
Thomas On Thu, Apr 23, 2015 at 7:05 PM, Qin Wang <[email protected]> wrote: > Hi Thomas and Xavi, > > I agree that with the a well-known key based MIC, some useless "start to > join" can be avoided. However, it is under the assumption that there is no > other 6tisch networks, right? If there are more than one 6tisch networks in > the same area, and all of them use the well-known key based MIC to > authentication, then the authentication will not save anything, right? > > Thanks > Qin > > > > On Thursday, April 23, 2015 8:30 PM, Xavier Vilajosana < > [email protected]> wrote: > > > Hi Thomas, > > now things are clear. If the "starting to join" is the bottleneck then I > agree with you and I come up to the same conclusion. > > thanks for the clarification. At least for me now there is no doubt about > it. > > regards, > Xavi > > 2015-04-23 10:35 GMT+02:00 Thomas Watteyne <[email protected]>: > > Xavi, > > I think (?) I understand where we get confused. > > In both case 1 and case 2 Zelda's network will be sending a lot of EBs and > Charlie's nodes will be receiving that EBs. > > > Agreed. > > > In both cases Charlie node will be receiving more EBs from Zelda's network > than from Charlie's network. > > > Agreed. > > > This will be slowing down the join procedure. > > > Not agreed, or not exactly :-) Many packets in the air (EBs or not) mean > occasional packet collision and MAC-level retransmissions, for sure. > But the main reason in this case for Charlie's mote to join slowly is that > is attempts to join Zelda's network: the mote hears Zelda's EB, > synchronizes to it, contacts Zelda's JCE to join, which rejects it. That > process might take tens of second, and it happens every time Charlie's mote > mistakes Zelda's EB for one of Charlie's. > > I understand that Zelda's network JCE will reject Charlie's nodes when > trying to join if MIC is not correct. > > > Agreed. > > > However, when Zelda's network send EBs, they are broadcast and Charlie's > nodes must receive them anyway. So the difference seems slight and only > from the JCE side not from Charlie's nodes which will be still trying to > parse a lot of EBs. > > > Agreed, regardless of what we come up with, Charlie's node needs to listen > for valid EBs, which involves parsing all packets it receives (maybe with a > little help of the HW). But it terms of delays, it's the "starting to join > the wrong network" that has the most impact. > > right? wrong? > > Thomas > > On Thu, Apr 23, 2015 at 9:36 AM, Xavier Vilajosana < > [email protected]> wrote: > > Hi Thomas, > > sorry, but I still do not see the benefit :) .. In both case 1 and case 2 > Zelda's network will be sending a lot of EBs and Charlie's nodes will be > receiving that EBs. In both cases Charlie node will be receiving more EBs > from Zelda's network than from Charlie's network. This will be slowing down > the join procedure. > > I understand that Zelda's network JCE will reject Charlie's nodes when > trying to join if MIC is not correct. However, when Zelda's network send > EBs, they are broadcast and Charlie's nodes must receive them anyway. So > the difference seems slight and only from the JCE side not from Charlie's > nodes which will be still trying to parse a lot of EBs. > > am I missing something? > X > > 2015-04-23 9:31 GMT+02:00 Thomas Watteyne <[email protected]>: > > Xavi, > > If I read Kris' e-mail correctly, in option 1, Charlie's nodes attempt to > join Zelda's network (i.e. they synchronize and ask the JCE, or equivalent, > to join). Since Zelda's network cannot authenticate Charlie's node, it gets > rejected. Charlie's node then tries again by listening for EBs. Because > Zelda's toys send so many beacons (they are little robots with motors > drawing 1A of current, so the little bit of extra current because of a > large number of EBs doesn't matter), Charlie's node attempts to join > Zelda's network much more often that its own. Charlie's nodes waste a lot > of energy trying over and over, until they finally join Charlie's network. > > Thomas > > 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
