Mališa Vučinić <[email protected]> wrote: >> If we could delay the switch to the new schedule until *after* >> COJP_REKEYING_GUARD_TIME has elapsed, then that might work. >> Alternatively, if we could number the rekeys then a EB could signal >> the switch to the new schedule some time after the keys are changed.
> Not sure about that the exact switch after COJP_REKEYING_GUARD_TIME
> would work, different nodes receive the new keys at different instants
> so it would be hard to sync them. I like better the trigger with an EB,
> it originates at 6LBR that is trusted and the frame can be
> authenticated by the nodes that have installed the new keys.
So we need to add a permutation index to the key update that
robust-scheduling provides, and then it needs to allocate a
IE value.
Oh: chairs, I think we should adopt this document. I know you didn't ask
yet. I think it's useful enough to make it part of the base architecture!
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
