Re: [6tisch] 6tisch join requirements for 6top

[Tero Kivinen <[e-mail]>]

Michael Richardson writes:
> So I am assuming that some of these details would go into the YANG model as
> additional fields.  Some, such as what ciphers to use, we might initially
> "default" to AES-CCM, assuming that if there an option, it's an upgrade, and
> a new YANG model would include the bit to turn it on.

In 15.4 there is only one cipher, i.e. AES-CCM*. There is 7 security
levels for it, but they just affect whether the payload is encrypted
and how long MIC (message integrity code) is added to the frame.

> 1) There are multiple senders.

Is there going to be multiple multicast keys also, or just one network
wide broadcast key. Do we need to support rekeying of the key, i.e. do
we want to exclude someone from the group and distribute the key only
to those we should be part of the new group. 

> 2) There is a mesh, and not all nodes have a direct connection to the root.

How is the mesh forwarding be done. Or is there any mesh forwarding,
i.e. can node X send frame to node Y, which is not in direct
communication range? If so how will it get forwarded. Is the
forwarding done on the upper layer, or so? When node X is sending
frame to node Y, does it uses node Y's address on the frame when
sending the frame out or what? 

> 3) I imagine that the root (6LBR) has to own the key.

With key you mean here what? Public key to authenticate the root, or
multicast key, or what?

>     > You could for example specify that the pan coordinator "owns" the
>     > multicast key, so he will take care of rekying etc, and the Key Source
>     > field of the auxiliary security header specifies him.
> 
> I don't think we have a specific pan coordinator in 6tisch.

Each 15.4 network has one PAN coordinator and can have multiple
coordinators. The first node creating the network will work as PAN
coordinator for the network.

I.e. if you have two 15.4 devices talking to each other, one of them
must be fully functional device (FFD) and act as PAN coordinator and
other one connects to it.

The PAN coordinator it the device who assigns the short addresses for
the devices, if you want to use them. 

>     > For example using Key Identifier Mode 1 (everybody set their
>     > macDefaultKeySource to match the extended address of the pan
>     > coordinator) and specifying that Key Index 0x10-0x1f is used for this
>     > multicast group (this would allow 16 groups so pan coordinator can
>     > create new key, and every time he sees someone using old key, he can
>     > send them new key, and ask them to delete old one).
> 
> I'm confused by why we would have to set the macDefaultKeySource to
> match the pan coordinator. Probably, I don't know what that field
> controls.

The macDefaultKeySource is used instead of the KeySource in the frame,
when Key Identifier Mode 1 is used. I.e. it is used to compress the
KeySource field in the frame. Many setups use star topology and in
that case all communication is between the leaf node and the PAN
coordinator. When the device associates with the network it will know
the extended address of the PAN coordinator and then it can configure
macDefaultKeySource with that address. After that the PAN coordinator
can send packets out by simply omitting the whole source address field
(i.e. using source address mode of NONE, which means the whole source
address fields are left out), and it can also use Key Indentifier Mode
1 which means the KeySource field in the auxiliary security header is
just one byte of Key Index. The recipient will then know from these
that this frame is from PAN coordinator, and as they know the extended
address of the PAN coordinator, and it is configure in the
macDefaultKeySource PIB for them, then they process the frames.

On the other direction when sending packet to the PAN coordinator,
they can leave the destination address away (i.e. packet goes to PAN
coordinator), and they can use the same group key own by the PAN
coordinator (i.e Key Identifier Mode 1), and then they just include
their own extended address or short address in the source addressing
fields of the header.

So most of these complications in the 15.4 are because of saving bits
on the air... 

> It would be nice if the pan coordinator could see all the transmissions, but
> that won't be the case; the join coordinator will have to refresh the keys.

So I assume your setup is that you have multiple coordinators, which
send out beacons and each device associates with one of those
coordinators, and the coordinators then talk the PAN coordinator using
some mechanism outside the scope of 15.4 to do the short address
assignment and group key management. 
-- 
[e-mail]