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
