[6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

[Michael Richardson <[e-mail]>]

I read draft-tiloca-6tisch-robust-scheduling-01.

I found this to be an interesting way to both announce the schedule, and yet,
hide it.  Very well done.

I have some initial comment about the section 3.1 about the adversary.
I wondered about why someone would do this.  What's the benefit.

It occured to me that an important point about the selective jamming is that
an attacker can mess with a competitors network while still permitting their
own network to operate!  That might be worth adding.

The document seems well written, although I'd like to have some example keys
and show how they permute things in practice so that implementors can
validate their work.

The additions to CoJP seems well done, I'm so glad we changed that to a hash
From an array :-)

If the permutation is replaced whenever the network key is changed,
which means that the permutation is going to change!  This means that some
nodes could be on the new permutation while others are on the old.

A thought to deal with this is that the new permutation is not used until the
node switches to the new keys.  EXCEPT that the adjacent nodes will now not
be listening at the right time, won't hear traffic encrypted with the new
key, and won't change over themselves.   Authenticated enhanced beacons would
perhaps help here.  Maybe I'm wrong about this problem.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-