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
