Mališa Vučinić <[email protected]> wrote: > The JRC would need to guess how long it may take for it to reach every > node in the network. I think that it makes sense that the JRC does not > need to be aware of network specifics. Instead, it can update the key > of the 6LBR last, signaling that it should start using it. Other nodes > get the key before, but don't use it until they see it in the network. > Makes sense?
I made a pull request with this text, which was from the rekeying
document. I am not happy with the text yet.
### Rekeying
A node MAY have multiple L2 keys, identified by different secKeyId. The
"kid" in the Join Response tells the node which key to update.
A particular key slot is considered active, and all transmitted traffic should
be sent
using the active key.
Nodes decrypt any packets for which they have keys: both older and new keys.
Upon receipt of a packet which is encrypted (or authenticated in the
case of a broadcast) with a secKeyId larger (taking consideration that
secKeyId wraps at 254) than the active slot causes the node to change active
slot pairs.
This mechanism permits the JRC to provision new keys into all the nodes
while the network continues to use the existing keys. When the JRC is
certain that all (or enough) nodes have been provisioned with the new
keys, then the JRC causes a packet to be sent using the new key. This
can be the JRC sending the next Enhanced Beacon or unicast traffic using
the new key if the JRC is also a regular member of the LLN.
The frame goes out with the new keys, and upon receipt (and decryption)
of the new frame all receiving nodes will switch to the new active key.
Beacons or unicast traffic leaving those nodes will then use the new
key, which causes an update of additional peers, and the network will
switch over in a flood-fill fashion.
> In the case of classical Observe, this would be a CON Observe
> notification, followed by an empty ACK from the client.
> In the case a joined node exposes a resource (e.g. /j) that the JRC
> POSTs to, the ACK would be piggybacked with the 2.04 Created response.
I'm unclear if you want to stick with OBSERVE, or if you want to expose
a management interface.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
