Kris, Nice little puzzle. Let me throw in my 2c.
*PANIDs & MIC keys* In practice, I see two mechanisms for a node to filter EBs: PANid (2B) and MIC key (16B) - PANIDs. The IEEE802.15.4 header contains a PANID, a 2-byte number. Charlie, Zelda and the other could set they networks to different PANIDs. A receiving radio will simply drop any packet which has a destination PANID set to a value different than the one if was configured on. This is easy to do, but comes IMO with a couple of drawbacks. First, there are only 65534 PANDS available, so collisions are possible. Second, and more importantly, this doesn't prevent a 6TiSCH node from mistaking a IEEE802.15.4 frame created by some (possibly proprietary protocol) for an EB. And finally, nodes can be made "PANID-agile": the joining node scans all PANIDs looking for a nearby 6TiSCH networks, so PANID-based discrimination doens't help here - MIC keys. I that context, the MIC is simply a 4-8 byte "super CRC" which essentially is calculated differently depending the key used. Through this mechanism, a node can detect with great confidence (keys are 16 bytes long) that this packet is indeed an EB sent by a 6TiSCH network. In that context, I would favor MIC keys, possibly in conjuction with PANIDs, although the contribution of the latter is smaller. *But what are we talking about?* Before giving my answer to your puzzle, I'd like to somehow limit its scope, and highlight the security+efficiency implications. Security in Charlie's network is of paramount importance, and the discussion we're having about EBs has very little to do with the security of the network. When a joining node hears one of Charlie's EBs, the only thing it can do is start a joining process. This, as we discuss in the security DT, probably means contacting the network's JCE to ask to join. The *only* thing we are talking about here is how to prevent a joining node from initiating a joining process with the wrong network. Why? Because that network will reject the node, and the node will have to re-try to another network. In reality, we're mostly talking about coexistence between networks, and speeding up the joining process. Under no circumstance can anything of what we're discussing allow a joining node to wrongfully join a network. *My answer to the puzzle* So here are my answer to the puzzle: I would leave the options open. Option 1 (no MIC), IMO makes no sense. CCM* is needed for any other traffic, so its available to us. The cost of calculating a MIC is negligiable compared to the cost of communication that it would be foolish not to take advantage of it. Choosing between Option 2 (secret key) and Option 3 (well-known key) depends on the application, and there are very valid arguments for both. In your puzzle, I believe Charlie and Zelda would make different choices. - Zelda's toys have to network quickly, possibly with other manufacturers. If I were Zelda, I would use a MIC key which is well-known, possibly written in the standard. If an "evil toy" attempts to join Zelda's network, it will be able to synchronize to the network and initiate a joining procedure with Zelda's JCE, but will get rejected. The energy/bandwidth wasted because of this is not a problem for Zelda's toys, whose motors are drawing 3-6 orders of magnitude more than their radio. - Charlie's networks are completely optimized, and Charlie doesn't want to constantly be receiving join requests from nodes (malicious or not) who have no business joining its network. So Charlie uses a secret MIC key. Charlie might even implement some key rotation mechanism for that key. Charlie understands that all of this is only to avoid non-authorized nodes to attempt to join the network. The JCE is the real gate keeper to the network, and authenticating to it is done through a totally different mechanism. Thomas On Wed, Apr 22, 2015 at 7:15 PM, Kris Pister <[email protected]> wrote: > 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
