Michael Richardson writes: > > Tero Kivinen <[email protected]> wrote: > > It depends what your environment is. If the joining process is > > happening only once when the network is set up, then running 10 > > messages during that is not a problem. If it happens every time you > > move from one room to another (i.e your remote controller joins the > > 6tisch network in the room to control the lights), then doing it > > quickly with 4 messages might be better. > > The joining process runs once.
Once per which timeframe? Once per lifetime of the device? Once per while the device is connected to the same network? Once per while being synced to the network? > This is in the architecture document. Really? Where? > 6tisch is not, btw, about remote controllers in a home, so it's > important to use reasonable use cases. It would be, but where are those defined. It seems that every time I talk with people I get different use case requirements. For example if the joining process is run once by the lifetime of the device, it does not matter how many frames we send and receive. If you run joining process every time you join the network, for example after you were out of radio range, or after power outage, or even after sleeping so long, that you lost sync, then frame countes are much more important. > But, in that case, the remote control would have been provisioned with a > locally significant certificate (not RPK) which a 802.15.9 KMP could use > (with a 4 message exchange) to establish new per-peer pairwise (does 802.15.9 > have a better word for that, btw?) keys. 802.15.9 uses the 802.15.4 terminology, i.e. link keys, vs group keys: link key: A secret key that is shared between precisely two devices. group key: A key that is known only to a set of devices. > (However, I don't know if I'd care to do per-peer pairwise keying for a > homenet: I'd might prefer a network-wide K2, and a protocol to rekey K2 > weekly, or whenever my house guests leave.) Usually to be able to rekey group keys, you need to have pairwise key, which can be used to protect the group keys when you send them to devices which are still part of the network. And you actually still need to rekey K1 also, as anybody who knows it, can mess up the network completely. As the TSCH IEs are only sent inside the EBs, if you want to change them while network is running, everybody must listen EBs and act if they change. If attacker knows K1 he can send fake EBs which will for example change the slotframe length or channel offset, causing devices not to hear each other (if sent to some devices, not everybody). Slotframes can be added and removed while the TSCH network is running, so this is expected to work. I do not think timing information (TSCH Timeslot IE) or the channel hopping information (Channel hopping IE) should be changed while the network is running, even though I do not think 802.15.4 or the 6tisch documents forbid that... -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
