There are two seperated discussions going on in this thread. @Malisa, if you agree, let's split the thread. I have clarifying questions about both.
*About OBSERVE* The issue raised is that, during the join request/response exchange between the pledge and the JRC, the JRC never learns the IPv6 address of the pledge (thanks to the Stateless-Proxy CoAP option). This means that, if the join request is carried by a CoAP FETCH message with Observe, the JRC has no means of addressing the joined node when the Observe triggers. Doing a second GET with Observe once the pledge has joined defeats the purpose of going for FETCH. Any other option? *About COSE_Key* The issue raised is that, during a rekey of key K2 by the JRC, the JRC cannot specify an ASN from which the new key is to be used. A strong requirement is for a node NOT have a node rejoin for each rekey. Must we use the COSE_Key structure? Is the the message sent by the JRC containing the new key end-to-end ACK'ed, i.e. does the JRC know it got received? Thomas On Sat, Mar 24, 2018 at 11:36 PM, Michael Richardson <[email protected]> wrote: > > Mališa Vučinić <[email protected]> wrote: > mcr> I think that the mechanism that was explained at: > mcr> https://tools.ietf.org/html/draft-richardson-6tisch- > minimal-rekey-02# > mcr> section-4 > > mcr> is a better workable solution. Deploy all the new keys (it may > take some > mcr> days on sleep networks), and then have nodes switch when they see > traffic > mcr> 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. > > Exactly. > It does not have to change significantly what you have, it just has to > include the (new) keyIndex. > > > 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. > > I agree, we don't need COMI, just the text about when to start using the > new key. > Shall I suggest some text it github? > > > 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". > > I'd say that you always do this with any new key if you have no keys. > I don't think we need a flag. > > In fact, even for the "0th key", you would start using it as soon as you > see > something that passes with that key, such as authenticating the Beacon that > you used to find the Proxy in the first place.... > > > - 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 > > Yes. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- ________________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Analog Devices Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com ________________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
