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