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.
> * 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.
> 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...
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.
> 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.
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
