Thanks for the clarification. I still have a couple of misunderstandings, see inline.
Mališa On Thu, Jul 19, 2018 at 12:47 AM Tero Kivinen <[email protected]> wrote: > Mališa Vučinić writes: > > Thanks Tero for the proposal. Is the current "key_usage" registry enough > to > > fully configure the security tables for the non-index modes? > > I guess so. I mean in most cases the KeyIdModes 1-3 are similar, i.e., > multicast/broadcast keys which are owned by somebody. In the KeyIdMode > 1 the owner is implicit (usually coordinator or similar well known > node on the network), in case of KeyIdModes 2 and 3 it is explicit. So > any of those modes can be used with any ke > y usage. > Ok, I understand this better now, thanks! > > For pairwise (KeyIdeMode 0) things are bit different, for example > sending beacons using pairwise keys is not really useful. So for > pairwise keys key usages like 6TiSCH-K2-* are something that are > usuful. > I see what you mean. Essentially, key usage will in this case signal to the node that it should use this pairwise key to send DATA and ACKs. But my question is related to the signaling of the destination peer. You say: For KeyIdMode 0 (pairwise keys), the key_index is set to 0, and key_source is omitted. The key_index 0 is invalid for other modes, and KeyIdMode 0 do not have key_index, so this will allow us to transmit pairwise keys between the peers (the addresses needs to be taken from the MAC header). I don't understand the part where "addresses need to be taken from the MAC header". Node A has neighbors B, C, D, and it receives a pairwise Link_Layer_Key from the JRC. It needs to know to what node it will use that key to transmit to: B, C, or D. The JRC should in this case, I suppose, send 3 different keys, each with a different "destination". I am missing this destination part. Similar when node A receives a frame, if it comes from B, it decrypts it with the corresponding key that the JRC indicated for node B. Is my understanding correct? If no, discard the text below :-) If so, we would just need to use "key_source" in this case as well, renamed perhaps, to carry the address of the destination peer. All the other modes that you proposed seem still to work. The proposed change for KeyIdMode 0 is : "key_index" is set to 0, "key_source" is present. Can you confirm this works?
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
