Hum... But then, if the JN does not know K1, how can it validate the MIC? Do we have another way to protect against transmission errors on EBs?
Cheers, Pascal > -----Original Message----- > From: 6tisch [mailto:[email protected]] On Behalf Of Michael Richardson > Sent: mercredi 6 mai 2015 04:07 > To: [email protected] > Subject: Re: [6tisch] Shipping minimal > > > Tero Kivinen <[email protected]> wrote: > >> But, 6tisch (minimal) is not targetted at that kind of use. > >> It's targetted at industrial users that need deterministic work. > > > I have always wondered for what this 6tisch is meant for, as everybody > > seems to have different requirements. Some say, we cannot do > > provisoning as nobody touches the devices before they are installed. > > This is not true in industrial users, there they can do provisioning > > before sending them to factory. > > They *can*, but they don't want to... too much $$$$. > The contractors who install the devices haven't the skills, and the > subcontractors, are often not actually trusted. This is actually in parts of > the > industrial requirements for ROLL (RFC5673) and was in draft-ietf-roll-rpl- > industrial-applicability-02.. that lead to 6tisch. > > > There was complains that neighbour toy > > store messes up networks for new devices, but for deterministic work > > you do not care about the bootstarpping phase, as that is only one > > time operation etc. > > Tom Phinney gave two examples from the refining situation. > The first part was that pieces of the refinery are often sold or leased to > competitors. That means that the entire sensor network needs to go through a > new bootstrap without being disassembled, and needs to do this in the midst of > another network. > > The toy store could well have two or three networks. > 1) the control network for the building/mall. > 2) the control network for the toy store itself. > 3) the actual junk actually being sold in the toy store. > > > All of this of course makes discusissons about issues hard, as > > everybody is talking about different things. > > True. > > >> Minimal is further targetted at well... interop. > > > If it is only for interop, there is no point of publishing it as RFC > > at all. If so then I do not care whether there is well-known key put > > in to the internet-draft. > > I don't know if it will have a life beyond the interop. > > >> Let me put it differently: Bluetooth didn't specify a default key, and > didn't > >> do enrollment for headsets sanely, and now the "K1" *and* "K2" keys are > "0000" > >> We can't keep people from doing stupid things. > > > Yes. On the other hand for most headsets you need to put them in > > pairing mode before they initiate setup and I think they exchange some > > kind of random keys during that phase that is then used later... > > I see your point. > > > No we dont. > > > The K1 can be completely random, and the joining node does not need to > > know it. > > > I repeat: > > > The K1 can be completely random and the joining node does not > > need to know it. > > > Only device who really needs to know the K1 is the device sending out > > EBs, as he needs it to be able to calculate the MIC... > > So, really, we don't need to use K1 on the EBs at all, is your point. > Therefore there is no point in having EBs authenticated at all.... > > >> If K1 has to be provisioned, then K2 will get set at the same time, > >> and K1 and K2 will get set to "0000". > > > The K1 and K2 can both be generated by running KMP during the joining > > process. The K1 will protect the EBs and every coordinator sending EBs > > in the network should use the same key to provide data integrity for > > EBs. If EBs are not used at all after the initial bootstrap phase > > (which some people seem to say will happen), then this K1 protection > > does not provide anything. > > Agreed... which is why Kris argues for using it for something else. > > > On the other hand on some networks I can see some real uses for EBs > > also after the initial bootstrap, but those uses will require the EBs > > to integrity protected for those devices who are already part of > > network. > > Good... I'd like to hear more. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works -= > IPv6 IoT consulting =- > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
