Hi Tengfei, Thanks for your review! See my responses and proposed resolutions inline.
Mališa On Mon, Jul 9, 2018 at 3:44 PM Tengfei Chang <tengfei.ch...@inria.fr> wrote: > Hi Malisa, > > I just reviewed the draft and have several comments below. > > *Comment 1: * > *----------------------* > In section 9.3.2 when describing link-layer key set: > > *When 6LBR receives this* > *parameter, it MUST remove any old keys it has installed from the* > *previous key set and immediately install and start using the new* > *keys for all outgoing and incoming traffic. When a non-6LBR node* > *receives this parameter, it MUST install the keys, use them for* > *any incoming traffic matching the key identifier, but keep using* > *the old keys for all outgoing traffic. A non-6LBR node accepts* > *any frames for which it has keys: both old and new keys. Upon* > *reception and successful security processing of a link-layer frame* > *secured with a key from the new key set, a non-6LBR node MUST* > *remove any old keys it has installed from the previous key set.* > *From that moment on, a non-6LBR node MUST use the keys from the* > *new key set for all outgoing traffic.* > > I understand this is for the case when a packet containing the* > link-layer key set parameter* is received, how the node should handle it. > This sounds to me like there is a proactive packet from JRC requesting to > update the key settings. > Yes. > Hence I have two questions: > 1. in what case JRC or some entity will send such packet? > For example if a JRC detects that some node in the network misbehaves, generates large amount of traffic, is misconfigured or similar. The JRC would then simply need to rekey the network, providing the new key to every node except the one that it wants to see expelled. Then, Tero on another thread also mentioned a couple of cases where this is necessary, e.g. if JRC restarts. Finally, note also the good cryptographic practice on rotating the keys for security reasons: e.g. to limit the amount of traffic encrypted under a given key; in case the old key was compromised for any reason, etc. > 2. if the parameter is from a Join response corresponding to a Join > request sent by the node before, (this implied by Table 2: Join Response > map labels), then what's the reason a node needs to send Join request if it > already has key configured (not the PSK). > I don't fully understand. Do you mean in which case would a node send another Join Request, if it has already completed the join process some time before and obtained the L2 encryption keys? > Maybe this is just for me that I don't understand the background of this > paragraph. But I just ask in case not. > > *Comment 2:* > *----------------------* > Another comment, you talked before, is the required parameters for the > 6LBR pledge. > Table 2 listed the parameters in the configuration object. It's generally > for non-6LBR pledge. > I made a pre-list for those parameters that required by 6LBR pledge. They > are from the information that EB should carry. > > 1. time slot template > 2. channel hopping template > 3. number of slotframes > > - slotframe handler > - slotframe length > - number of links > - link information (slotoffset, channeloffset, type) > > Thanks for bringing this up. As discussed off-line, I agree with this change as it would enable the bootstrapping of a 6LBR pledge, at a very low cost. When discussing this with Xavi Vilajosana, he raised a point that adding these parameters relevant only to the 6LBR pledge would reduce the readability of the spec for people who just care about implementing the non-6LBR pledge. As a resolution, I propose to define separate data structures for when 6LBR pledge joins and when non-6LBR pledge joins, instead of mixing all the parameters together in a Configuration structure. Let me know if this works! Is there anything else we should also add? > I will bring this up tomorrow during the meeting to ask for WG input if there are any other parameters that could be useful for 6LBR joining.
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
