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

It seems i have permuted slotOffset and channelOffset below :-) This may be a piste if slotOffset permutation is kept but there would likely be problems for nodes with higher bandwidth requirements and many cells in the schedule to guarantee zero slotOffset collisions in one own’s schedule

Re: [6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01

Hi Tengfei, Thanks for these questions. 1. We're not protecting against selective jamming on the minimal cell indeed. This is a tricky problem, because beacons must include enough information for nodes to find out when to tx/rx for the join procedure, and a not-joined-yet node can do it then so

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

My understanding is that the problem in the permuted schedule arises during COJP_REKEYING_GUARD_TIME after nodes in the network started using the new keys, but have still kept the old key in case someone has not yet switched. When coupled with a rekeyed permutation key to calculate the

[6tisch] Review on draft-tiloca-6tisch-robust-scheduling-01

Hello Authors, I just reviewed the draft. It reads pretty good for me! I only found a tiny typo error in Eq.1 where the 'c' is not defined actually, I believe you mean 'chOff'. Besides, I have two questions referring the usage of minimal cell. 1. What if the selective jamming applied on the

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

Mališa Vučinić wrote: > Should be covered in > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4.2 right! It was hard to find this burried in that point. Can you see how the old/new key issue interacts poorly with the permuted schedule? -- ]

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

I concur with Michael, this is interesting work. Note that 1) It is possible to commute only a subset of the channel offsets at a given time offset. This reduces the number of nodes that need to know about the swap and thus the exposure to a leakage. 2) security is not the only reason why

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

Should be covered in https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4.2 Mališa > On 4 Apr 2019, at 16:04, Michael Richardson wrote: > > I was looking for some text from

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

Marco Tiloca wrote: >> 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

[6tisch] [CFP] [Deadline approaching] GOODTECHS 2019 - Track Session in Serious Games to Improve Quality of Life, 25/09 - 27/09, Valencia, Spain

-Apologies if you received this CFP multiple times- Deadline approaching! * Call for Papers *GoodTechs 2019 *Track Session in Serious Games to Improve Quality of Life *

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

Hi Michael, Thank you very much for your review! We'll definitely take into account your comments for the next version. Please, find also some answers inline. Best, /Marco On 4/3/19 3:06 AM, Michael Richardson wrote: > I read draft-tiloca-6tisch-robust-scheduling-01. > > I found this to be an