Michael, See inline.
Mališa On Thu, May 10, 2018 at 8:05 PM Michael Richardson <[email protected]> wrote: > > I see that you have an IANA registry for the Join Request and Join Response > key values. These tables need to have names and the IANA instruction needs > to ask them to create the tables, and then to populate them with the table > From section 9. > May I also suggest: > 1) instead of "unsigned integer", that we just say integer. > 2a) that the 1-byte positive and negative integers may be allocated by IETF > Standard. > 2b) that the 2-byte, 3-byte and 4-byte positive integers may be allocated > by IANA > First Come First Served ( > https://tools.ietf.org/html/rfc8126#section-4.4) > 2c) that the 2-byte, 3-byte and 4-byte negative integers be reserved for as > an experimental range. > > > 9.2.1.1. Link-Layer Key > This probably needs an IANA Registry, even if it is closed to just IETF > Standard Action. > > (I can write text next week on this) > Yes, this is all fine with me. If you could provide a PR on the latest minimal-security-06 branch, that would be great! > > Did you see my "new-key-start" branch from last week, btw? > Yes, just worked on this today. I cherry-picked two of your commits but reorganized the text heavily. CBOR objects are now a separate subsection, two new CoAP messages for "parameter update exchange" are defined. The Parameter Update message (CoAP POST from JRC to the joined node) carries the same CBOR object as the Join Response. This is the conclusion of the discussions I had with Christian. I generalized the rekeying text so that it falls under the processing rules of the CBOR Link-Layer Key parameter. The first join of a pledge just becomes a special case but there is a distinction between the 6LBR and non-6LBR nodes. I don't see how the JRC that is not colocated with the 6LBR can trigger the sending of a link-layer frame secured with the new keys... Here is the relevant commit, check it out: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/968a9450dde7c93849d6bec278fe28522e9c4c76 > > On to 6LBR stuff: > As a special case, when the pledge is configured to play the role of > the 6LBR, and 6LBR is not co-located with the JRC, the pledge > additionally needs to be provisioned with: > > okay, so I understand the situation. I think that such a 6LBR probably > have > two interfaces, one of them Ethernet, and that it does a join over > ethernet. > (It would probably also do a join request over 15.4 as well, since it might > have no idea what's where) > Yes, another interface for the 6LBR to join is an assumption that we need to state clearly. > > I'm fine with that, but in that case, we need to tell such a pledge how to > find a Join Proxy and/or the actual JRC. At present, we use the 15.4 > specific Enhanced Beacon. There a bunch of options: > 1) DHCPv6 > 2) GRASP > 3) mDNS (DNS-SD) > 4) RA option > In the current text somewhere in the one-touch section, there is simply a requirement that 6LBR needs to be provisioned with the IPv6 address of the JRC. Then, it can contact it over CoAP/IPv6 directly using global addressing. I still need to do some changes to CoAP message mapping to cover this case clearly, but I don't think another protocol is necessary. Of course, the current text does not preclude the use of another protocol for that purpose. > > -- > ] 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
