> Actually no. I think EBs are actually very good and cheap way to keep
> up in sync in network. The only thing required from them in that case
> is that they have real key protecting them (i.e. no well-known keys).

Now this *is* a real mistake, and provides a false sense of security.
If multiple vendors need to ship products that have a secret key in
firmware, that key will not remain secret for long.  If you depend on
it for security, that's a false sense of security.
If the key is generated randomly for each network, that's fine, but
then how do the new nodes join?  Either they get programmed with
the randomly generated key for the particular network that they want
to join (which is not an acceptable solution to most end users) or
they don't rely on a secret key during the joining phase.  Once through
the joining phase they get one or more L2 keys that are random and
secret for that network.  If you want to beacon with that key to maintain
sync, fine.  But don't think that your global EB PSK is going to remain
secret - it won't.

ksjp

On 5/4/2015 5:57 AM, Tero Kivinen wrote:
Kris Pister writes:
  >> I think that the confusion here is in thinking that EBs are involved
  >> in normal network operation.  They are not.

  > I have understood that draft-ietf-6tisch-minimal plans to use them
  > also in normal operation.

The text in minimal-06 reads
"EBs should not in general be used for synchronization."

In -07 we should certainly change that to caps. I'm guessing that
Tero would argue that it should be MUST NOT instead of SHOULD NOT. I
would agree.
Actually no. I think EBs are actually very good and cheap way to keep
up in sync in network. The only thing required from them in that case
is that they have real key protecting them (i.e. no well-known keys).

The current minimal already says you can use pre-configured keys, or
key management protocols to create keys, so for those use cases the
EBs can use real keys, and in that case you can use them for
syncronization.

Only problem with using EBs in time syncronization comes when someone
uses unsecured EBs or EBs "protected" using well-known keys.

I note that draft-ietf-6tisch-tsch-06 generally describes this
process well, but does include one sentence which should be removed:
"Nodes can keep synchronization exclusively by exchanging EBs." This
either needs to be explicitly not allowed, or Charlie has to go back
to square one.
In some networks using EBs is completely valid option.

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to