Hi Thomas, See inline.
Mališa On Mon, Mar 26, 2018 at 9:00 AM Thomas Watteyne <[email protected]> wrote: > 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? > This discussion is now under the thread: *Observe for rekeing (was: Updates to minimal-security-06).* I agree with your summary. Right now we are discussing whether the joined node can expose a resource (e.g. /j), that the JRC can POST to and update the key as it knows implicitly joined node's IPv6 address. > *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? > Moving the discussion about the rekeying mechanism to the thread: *Rekeying for minimal-security (was: Updates to minimal-security-06).* > > 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
