Re: [6tisch] Updates to minimal-security-06

[Mališa Vučinić <[e-mail]>]

On Thu, Mar 22, 2018 at 5:39 PM Michael Richardson <[e-mail]>
wrote:

>
> Mališa Vučinić <[e-mail]> 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