Mališa Vučinić <[email protected]> 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
It's not just during that time, but from the time it receives the new keys until it switches to the new key and permutation. If it would listen on both permutations, I guess it would work. The problem is that the rekey for a node does not start until it receives traffic with the new key. If it's not listening at the right time (and right channel), then it will never receive such a packet. 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. -- 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
