Subject: [6tisch] Comments on draft-ietf-6tisch-minimal-security-06

From: Tengfei Chang <[email-masked]>
Date: Mon, 9 Jul 2018 15:44:15 +0200

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. Hence I have two questions:
1. in what case JRC or some entity will send such packet?
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).

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)

Is there anything else we should also add?

Tengfei

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria

---

From: Mališa Vučinić <[email-masked]>
Date: Tue, 17 Jul 2018 18:28:54 +0200

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 <[email-masked]> wrote:

> 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:

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

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?

> Another comment, you talked before, is the required parameters for the
> 6LBR pledge.
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!

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.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 17 Jul 2018 23:24:58 +0300

Mališa Vučinić writes:
> 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.

If JRC restarts and looses track who is in the network, then it cannot
send updaes, as it does not know who is in the network. I.e., in that
case all nodes need to rejoin.

On the other hand if JRC wants to clean up some address space, for
example if it has given out lots of short address without expirity
time, and then it cannot take those address back to use ever even if
the node has already been silent for few weeks. In that case if it
does the rekey of the network then after the old keys are no longer in
use anywhere it can start reusing the short addresses for those nodes,
it did not send key update for.

It cannot use the fact that node did not ack the key update sent to it
to indicate that node has gone from the network, as it is possible
that the ack got lost, even when the key update actually reached the
node. So it needs to have list of nodes it will send key updates, and
those it does not send it, are something it can remove from the
address pool after the key update. 
-- 
[email-masked]

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 17 Jul 2018 17:36:23 -0700

Hi Malisa and Tero,

Thanks for answering my question! It is clear to me!

> another Join Request, if it has already completed the join process sometime
> before and obtained the L2 encryption keys?
>

My question is exactly what you rephrased :-)

Tengfei

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 18 Jul 2018 12:55:50 +0200

> My question is exactly what you rephrased :-)

For example, if the node goes to sleep for some prolonged period of time
(think energy-harvesting nodes), or falls out of sync, and the L2 keys have
changed in the meantime. Node can detect this by not being able to
authenticate EBs.

Or also, in the draft, we mandate the node to do this if its short address
expired, before JRC was able to send a Parameter Update Request message
with the new address.

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 18 Jul 2018 13:07:39 +0200

> case all nodes need to rejoin.

How do we detect that JRC restarted at 6LBR if JRC is in the Cloud? I guess
we need to assume that the JRC knows the address of 6LBR upon restart and
can contact it, but this is then related to the issue Jim Schaad raised on
reuse of Partial IVs on the application layer.

If JRC rekeys *only* the 6LBR who starts using the new key for all outgoing
traffic, all the nodes in the network will fall out of sync which will
force them to rejoin, obtain new key and new short addresses. Seems to be
sufficient?

> it did not send key update for.

So I guess this would be equivalent to the case of expelling a node from
the network, i.e. rekeying everyone but that node.

> address pool after the key update.

Agreed.