On Thu, Mar 22, 2018 at 5:39 PM Michael Richardson <[email protected]> wrote:
> > Mališa Vučinić <[email protected]> wrote: > > in the network. Other than adding the Observe option, together with > the > > new link-layer key we also need to carry the ASN at which this key is > > scheduled to be rolled out. What COSE parameter the ASN will be > > I disagree with this method. > > I think that the mechanism that was explained at: > > https://tools.ietf.org/html/draft-richardson-6tisch-minimal-rekey-02#section-4 > > is a better workable solution. Deploy all the new keys (it may take some > days on sleep networks), and then have nodes switch when they see traffic > with the new key. > Thanks, Michael, for the reminder on this document, I have to say that I forgot about it.. IIUC, the issue you have with the mechanism I proposed is that the JRC in some cases may not know how long it could take to deploy the keys so that it cannot properly set the ASN. I think that's a valid concern and that it would indeed be better if we could decouple the JRC from the inner network specifics as much as possible. One of my goals with this extension to minimal-security is to remove any need for an additional protocol between the 6LBR and the JRC. 6LBR can act as any other pledge before triggering the network formation process by sending a Join Request itself. The only additional parameter that the 6LBR needs in respect to the pledges is the IPv6 address of the JRC and this can be done during one-touch provisioning. Once it receives the Join Response, 6LBR can start advertising the network by using the link-layer keys it received. To do this and support rekeying with your proposal, we need to differentiate between "start using this key" and "install the key but don't start using it until you see it being used in the network", for 6LBR and joined nodes to follow, respectively. We can likely do this by extending the COSE_Key map with an additional parameter for this purpose, which I prefer to pulling in the whole COMI machinery, as is suggested in the minimal-rekey draft. Essentially, the process would be: - the JRC deploys the new key(s) to all the nodes except to the 6LBR. - nodes will install them, but keep using the old keys because the new COSE_Key parameter is set to "install the key but don't start using it until you see it being used in the network". - deploy the key to the 6LBR, with the COSE_Key parameter set to "start using now". - once a node sees the new key being used and the replay protection and the authenticity check at L2 passes, it removes the old keys and starts using the new key for all outgoing traffic What do you think? Mališa -- Mališa
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
