Pascal,
The protection against transmission errors on EBs rely on the CRC in PSDU,
right?
ThanksQin
On Wednesday, May 6, 2015 6:34 PM, Pascal Thubert (pthubert)
<[email protected]> wrote:
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
