All, We had a couple of side discussions during IETF 101 on the updates to the minimal security draft. We need to (1) support extensibility to allow future specs to add additional parameters to the join response structure, and it seems that (2) we can cover link-layer rekeying easily through the use of the FETCH CoAP method and Observe option in the Join Request.
To tackle (1) the proposal is to change the top-level CBOR array with a map, using an IANA registry of unsigned int for labels, typically adding one byte of overhead with each map element. This will allow easy extension by future specs. To tackle rekeying, the proposal is to use the FETCH CoAP method and add the Observe CoAP option in the request. FETCH is essentially a parametrized GET, allowing us to do Observe on the resource. The mechanism allows the JRC to asynchronously send a response to the nodes 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 transported is TBD. This mechanism will allow the JRC to change the network keys, and also exclude nodes from the network, since the responses are unicast. All of this goes over the OSCORE encrypted channel. One doubt I have is how does the JRC send the Observe response to the joined node, when the request came over a Join Proxy. Essentially, the JRC needs to send the response to the global IPv6 address of the joined node, that it never used before, but it is able to construct it, as it knows the network prefix and the node identifiers (EUI-64, short address). @Christian, is there any problem of doing this in terms of CoAP? @all, Please speak up if you have any objections or proposals. Mališas -- Mališa
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
