Mališa Vučinić <[email protected]> wrote: mcr> I'd say that you always do this with any new key if you mcr> have no keys. mcr> I don't think we need a flag. mcr> In fact, even for the "0th key", you would start using it mcr> as soon as you see mcr> something that passes with that key, such as mcr> authenticating the Beacon that mcr> you used to find the Proxy in the first place.... > Authenticating a beacon that was received long time ago would require > the pledge to store the beacon(s) for potentially an extensive > period... I don't think we need to do that.
No, I'm not suggesting one keeps it for along time.
What I'm saying is that, just after getting the Join Response, a pledge now has
some set of keys. It will have an authentication key. It could immediately
authenticate the Beacon that it used to find the Proxy. That does a few things:
1) validate the Beacon!
2) since the key successfully validates the Beacon, it proves that the key the
pledge got is a current key, and so the key would be marked as activated.
Of course, if the pledge doesn't have enough ram to keep the beacon around, then
it shouldn't do that. It can validate the next beacon instead.
> Essentially:
> - 6LBR: installs the new key, starts using it for outgoing traffic
> immediately, removing old keys, if any.
> - joined node and pledge: installs the new key, keeps using the old
> keys for outgoing traffic until it receives incoming traffic secured
> with the new key, with all L2 security checks passed. In the special
> case of a pledge, there shouldn't be any outgoing traffic before it
> decrypts DIO(s) and selects a preferred parent.
Exactly.
--
] 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
