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

[Marco Tiloca <[e-mail]>]

Hello Mališa, Michael,

Thanks for this discussion, I think this is a good summary of the problem.

Just to stress that the full-fledged approach, by making also
slotOffsets unpredictable rather than static (i.e. obviously
predictable) further greatly decreases the attack surface, since a
now-random jammer would be forced to guess both channels and timeslots
of target node(s). On the other hand, it's surely undesirable when
keeping latency at bay is a priority and a criterion of the original
scheduling function.

So, I agree that we can better think of what recommending in Section
6.3, and under which assumptions. In case: i) the original scheduling
function is not oriented to latency optimization; and ii) it is
acceptable for nodes to experience collisions during
COJP_REKEYING_GUARD_TIME upon network rekeying; then permuting also the
slotOffsets should IMHO still be the preferable thing to do and recommend.

Best,
/Marco

On 4/4/19 11:38 PM, Mališa Vučinić wrote:
> 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 across slotframe iterations. Don’t really like it
> though for the reason of breaking the scheduling function.
>
> As a reminder, in minimal-security we resorted to the current rekeying
> mechanism and not the one using the exact timestamp in the future when
> the whole network switches to new keys in order to avoid having to
> know the network notion of time at the JRC.
>
> Mališa
>
>> On 4 Apr 2019, at 19:33, Mališa Vučinić <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>> 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 schedule, this means that during
>> COJP_REKEYING_GUARD_TIME a node would need to follow two schedules,
>> one with the old permutation key and one with the new one. The
>> problem in following two schedules for COJP_REKEYING_GUARD_TIME is
>> that draft-tiloca-6tisch-robust-scheduling-01 recommends both the
>> slotOffset and the channelOffset be permuted so that it may occur
>> that there can be a collision in slotOffset between the new and the
>> old schedule.
>>
>> The problem that draft-tiloca-6tisch-robust-scheduling solves seems
>> to be the predictability of the channel on which a transmission is
>> going to take place. With that in mind, I have second thoughts about
>> the recommendation on permuting the slotOffset, especially taking
>> into account that this will break any scheduling function that
>> optimizes for latency, as discussed in Section 6.3.
>>
>> Mališa
>>
>>
>>> On 4 Apr 2019, at 17:40, Michael Richardson <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>> Can you see how the old/new key issue interacts poorly with the permuted
>>> schedule?
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se