Mališa Vučinić <[email protected]> wrote: > I did quite a bit of work in the document, including some CBOR wizardry, > and defined new parameters and IANA registries with the goal of
I see! Thank you.
> homogenizing the join for 6LBR and regular nodes. For now, I added an
> optional "network prefix" parameter in the Join Response, carrying the
IPv6
> prefix of the network for the 6LBR. If there are some pitfalls with this
> that I forgot, we can remove it. Similarly, I also added the "network
> identifier" parameter in the Join Response, carrying PAN ID for the
> 6LBR.
I don't quite understand the problem you are trying to fix here, let me come
back to this after I've read the diff again.
> Regarding CBOR, the top-level types in Join Request and Join Response are
> now all maps, but I removed the use of COSE_Key and COSE_Keyset and
defined
> our own structures in order to save bytes when transporting keys.
> Essentially, this means that we are flexible to add new parameters in the
> future in top-level Join Request and Join Response objects, but the inner
> objects are fully optimized and poorly extensible due to the use of arrays
> and uints.
This is really good work.
> I also worked out a new key signaling mechanism using a "key usage"
> parameter, where a single uint value from the registry specifies the IEEE
> 802.15.4 security level to be used and the appropriate frame types the key
> can be used with. The mechanism is flexible in that it allows us to
> transport a key that is both K1 and K2, separate K1 and K2, different
> security levels for each, and we can also define new combinations of
> security levels/frame types in future. The solution only supports KeyIndex
> mode of IEEE 802.15.4. Supporting other modes required mimicking 15.4
> security structures to configure the security module and would have
> required maps everywhere and extensive overhead. If you have any better
> idea how to add support for other keying modes of 802.15.4, let me
> know.
I don't think we need to support modes other than keyIndex, so I think that
this is fine.
> Feedback is welcome, I am continuing with the work on the rekeying
> mechanism that we discussed.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
