On Thu, Apr 23, 2015 at 4:04 PM, Tero Kivinen <[email protected]> wrote:
> Thomas Watteyne writes: > > 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 > > PAN ID cannot be used to identify networks before you join to them. > They are only used after you have joined the network to separate > multiple networks working on the same area. I.e. when the PAN > coordinator sets up the network he finds "free" PAN ID and starts > using that. If he at any point hears someone using the same PAN ID, he > will notice there is PAN ID collision and change his PAN ID to > something else. What this PAN ID collision and changing of PAN ID > means for TSCH network is bit fuzzy for now. It is one of those issues > we are discussing in the maintenance work, as PAN ID conflict > resolution is mandatory feature of 802.15.4, but this allows very easy > way to make easy DoS attacks against networks. > I haven't seen text about networks changing PANids on-the-fly when someone else is using it, but that's a separate discussion. > > > * MIC keys. I that context, the MIC is simply a 4-8 byte "super CRC" > which > ^^^ > 4-16 bytes, lengths are 32, 64 or 128-bits, i.e. 4, 8, or 16 bytes > long. > agreed > > > 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. > > Keys are 16 bytes long, but if the MIC sent is only 4 bytes, then > there is 2^32 propability that random packet will have correct mic... > agreed. > For the network separator IE, the length does not need to be that > long, it can be made unique in other ways. For example if we already > use unique allocation of OUIs, and then add company internal ID to > that, we might use 5 byte content for the IE. > > > 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. > > As long as it does not use draft-ietf-6tisch-minimal, which will > require EBs to be secure. > > > 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. > > Yes. And for that network identifier IE is much better way than MIC. > Why? If I receive a EB which I cannot authenticate, I reject it exactly the same way I would reject an EB with a netid IE I don't like, > > > 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. > > I do not think the option 3 is useful in any case where any security > is needed. Effectively option 3 is exactly same as option 1 in > security, and in that case you rule out draft-ietf-6tisch-minimal for > that network. > We're been over this so many times.... The well-known key does not offer you any security, i.e. it's security value is the same as option 1, but it gives you the convenience of early network segragation when a new node heard a bunch of EBs... > -- > [email protected] >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
