Subject: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Apr 2019 21:06:41 -0400

I read draft-tiloca-6tisch-robust-scheduling-01.

I found this to be an interesting way to both announce the schedule, and yet,
hide it.  Very well done.

I have some initial comment about the section 3.1 about the adversary.
I wondered about why someone would do this.  What's the benefit.

It occured to me that an important point about the selective jamming is that
an attacker can mess with a competitors network while still permitting their
own network to operate!  That might be worth adding.

The document seems well written, although I'd like to have some example keys
and show how they permute things in practice so that implementors can
validate their work.

The additions to CoJP seems well done, I'm so glad we changed that to a hash
From an array :-)

If the permutation is replaced whenever the network key is changed,
which means that the permutation is going to change!  This means that some
nodes could be on the new permutation while others are on the old.

A thought to deal with this is that the new permutation is not used until the
node switches to the new keys.  EXCEPT that the adjacent nodes will now not
be listening at the right time, won't hear traffic encrypted with the new
key, and won't change over themselves.   Authenticated enhanced beacons would
perhaps help here.  Maybe I'm wrong about this problem.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 4 Apr 2019 09:04:34 +0200

Hi Michael,

Thank you very much for your review!

We'll definitely take into account your comments for the next version.

Please, find also some answers inline.

Best,
/Marco

> I found this to be an interesting way to both announce the schedule, and yet,

<MT>
Thanks!
</MT>

> own network to operate!  That might be worth adding.

<MT>
It's a very good point! We'll add this as an attack motivation in
Section 3.1.
</MT>

> and show how they permute things in practice so that implementors can

<MT>
Right, we will produce an example, possibly as an Appendix referred at
the end of Section 4.
</MT>

> perhaps help here.  Maybe I'm wrong about this problem.

<MT>
This seems to deserve some more text in the Security Considerations of
Section 6.2, such as the following points.

The new link keys and permutation keys are expected to be distributed
together, just like for the described provisioning through the CoJP Join
Response, possibly through the same procedure described in [1].

After a rekeying process is completed, a node should indeed start using
the new permutation keys once switched to the new link keys only, i.e.
after it has discarded the old key material as per the handling of the
"link-layer key set" in [2].

If a node A discards the old key material (considerably) before a node
B, they will be temporarily unaligned. That is, node B would temporarily
secure outgoing messages still using the old key material [2] that A
does not own anymore, and would still permute its schedule the old way.

Eventually, B will also discard the old key material, e.g. after
receiving and successfully security processing an incoming message
secured with the new key material [2], of course though while still over
its old-fashion-permuted schedule. Here enhanced beacons authenticated
with the new key material seem to help. Also, a local upper bound can be
enforced through a parameter similar to COJP_REKEYING_GUARD_TIME [2].
Then, the two nodes will be aligned again on both processing secure
messages and permuting their schedule.

What do you think?

[1]
https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.2
[2]
https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4

</MT>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Apr 2019 10:04:30 -0400

Marco Tiloca <[email-masked]> wrote:
    >> A thought to deal with this is that the new permutation is not used
    >> until the node switches to the new keys.  EXCEPT that the adjacent
    >> nodes will now not be listening at the right time, won't hear traffic
    >> encrypted with the new key, and won't change over themselves.
    >> Authenticated enhanced beacons would perhaps help here.  Maybe I'm
    >> wrong about this problem.

    > <MT> This seems to deserve some more text in the Security
    > Considerations of Section 6.2, such as the following points.

    > together, just like for the described provisioning through the CoJP
    > Join Response, possibly through the same procedure described in [1].

yes, that's fine, but you have skipped the communications that will occur
*during* the rekey, when some nodes have new keys and some are still using
older keys.

I was looking for some text from 6tisch-minimal that explains how the rekey
actually occurs.

Malisa, it seems like this text has been lost.
Or did we move this process to another document?

The issue Marco is that use of the new key is signaled by receipt of a packet
that uses the new key.  The sending node will have already switched to a new
permuation, while the receiving node will still be on the old schedule.

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 4 Apr 2019 16:52:10 +0200

Should be covered in https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4.2 <https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4.2>

Mališa

> On 4 Apr 2019, at 16:04, Michael Richardson <[email-masked]> wrote:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Apr 2019 14:59:40 +0000

I concur with Michael, this is interesting work.

Note that 
1) It is possible to commute only a subset of the channel offsets at a given time offset. This reduces the number of nodes that need to know about the swap and thus the exposure to a leakage.
2) security is not the only reason why swapping is useful. As you know, under constant conditions, pairs of nodes will suffer from multipath fading on some channels and not on others. Once this has been observed, it is possible to do a selective swap to avoid the particular channels that affect a particular pair of nodes. 
3) I have IPR on that sort of stuff (USPTO 9,673,856); it is not exactly the method you propose but close enough. Just in case I'll ask to publish terms.

All the best,

Pascal

> -----Original Message-----
> From: 6tisch <[email-masked]> On Behalf Of Marco Tiloca
> Sent: jeudi 4 avril 2019 09:05
> To: Michael Richardson <[email-masked]>; [email-masked]
> Cc: [email-masked]
> Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying
> permutation key
> 
> Hi Michael,
> 
> > I found this to be an interesting way to both announce the schedule,
> > and yet, hide it.  Very well done.
> 
> <MT>
> Thanks!
> </MT>
> 
> >
> > It occured to me that an important point about the selective jamming
> > is that an attacker can mess with a competitors network while still
> > permitting their own network to operate!  That might be worth adding.
> 
> <MT>
> It's a very good point! We'll add this as an attack motivation in Section 3.1.
> </MT>
> 
> > The document seems well written, although I'd like to have some
> > example keys and show how they permute things in practice so that
> > implementors can validate their work.
> 
> <MT>
> Right, we will produce an example, possibly as an Appendix referred at the end
> of Section 4.
> </MT>
> 
> 
> > The additions to CoJP seems well done, I'm so glad we changed that to
> > a hash From an array :-)
> >
> > which means that the permutation is going to change!  This means that
> > some nodes could be on the new permutation while others are on the old.
> >
> > nodes will now not be listening at the right time, won't hear traffic encrypted
> with the new
> After a rekeying process is completed, a node should indeed start using the
> new permutation keys once switched to the new link keys only, i.e.
> after it has discarded the old key material as per the handling of the "link-layer
> key set" in [2].
> 
> If a node A discards the old key material (considerably) before a node B, they
> will be temporarily unaligned. That is, node B would temporarily secure
> outgoing messages still using the old key material [2] that A does not own
> anymore, and would still permute its schedule the old way.
> 
> Eventually, B will also discard the old key material, e.g. after receiving and
> successfully security processing an incoming message secured with the new
> key material [2], of course though while still over its old-fashion-permuted
> schedule. Here enhanced beacons authenticated with the new key material
> seem to help. Also, a local upper bound can be enforced through a parameter
> similar to COJP_REKEYING_GUARD_TIME [2].
> Then, the two nodes will be aligned again on both processing secure messages
> and permuting their schedule.
> 
> 
> What do you think?
> 
> 
> [1]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Apr 2019 11:40:53 -0400

Mališa Vučinić <[email-masked]> wrote:
    > Should be covered in
    > https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-8.4.2

right! It was hard to find this burried in that point.

Can you see how the old/new key issue interacts poorly with the permuted
schedule?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 4 Apr 2019 19:33:01 +0200

My understanding is that the problem in the permuted schedule arises during COJP_REKEYING_GUARD_TIME after nodes in the network started using the new keys, but have still kept the old key in case someone has not yet switched. When coupled with a rekeyed permutation key to calculate the schedule, this means that during COJP_REKEYING_GUARD_TIME a node would need to follow two schedules, one with the old permutation key and one with the new one. The problem in following two schedules for COJP_REKEYING_GUARD_TIME is that draft-tiloca-6tisch-robust-scheduling-01 recommends both the slotOffset and the channelOffset be permuted so that it may occur that there can be a collision in slotOffset between the new and the old schedule.

The problem that draft-tiloca-6tisch-robust-scheduling solves seems to be the predictability of the channel on which a transmission is going to take place. With that in mind, I have second thoughts about the recommendation on permuting the slotOffset, especially taking into account that this will break any scheduling function that optimizes for latency, as discussed in Section 6.3.

Mališa

> On 4 Apr 2019, at 17:40, Michael Richardson <[email-masked]> wrote:
>

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 4 Apr 2019 23:38:54 +0200

It seems i have permuted slotOffset and channelOffset below :-) This may be a piste if slotOffset permutation is kept but there would likely be problems for nodes with higher bandwidth requirements and many cells in the schedule to guarantee zero slotOffset collisions in one own’s schedule across slotframe iterations. Don’t really like it though for the reason of breaking the scheduling function.

As a reminder, in minimal-security we resorted to the current rekeying mechanism and not the one using the exact timestamp in the future when the whole network switches to new keys in order to avoid having to know the network notion of time at the JRC.

Mališa

> On 4 Apr 2019, at 19:33, Mališa Vučinić <[email-masked]> wrote:
> 
>> On 4 Apr 2019, at 17:40, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 5 Apr 2019 10:17:15 +0200

Hello Pascal,

Thanks a lot for your review, feedback and pointers to further
applicability of this approach.

Best,
/Marco

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 5 Apr 2019 10:29:50 +0200

Hello Mališa, Michael,

Thanks for this discussion, I think this is a good summary of the problem.

Just to stress that the full-fledged approach, by making also
slotOffsets unpredictable rather than static (i.e. obviously
predictable) further greatly decreases the attack surface, since a
now-random jammer would be forced to guess both channels and timeslots
of target node(s). On the other hand, it's surely undesirable when
keeping latency at bay is a priority and a criterion of the original
scheduling function.

So, I agree that we can better think of what recommending in Section
6.3, and under which assumptions. In case: i) the original scheduling
function is not oriented to latency optimization; and ii) it is
acceptable for nodes to experience collisions during
COJP_REKEYING_GUARD_TIME upon network rekeying; then permuting also the
slotOffsets should IMHO still be the preferable thing to do and recommend.

Best,
/Marco

On 4/4/19 11:38 PM, Mališa Vučinić wrote:
> It seems i have permuted slotOffset and channelOffset below :-) This
> may be a piste if slotOffset permutation is kept but there would
> likely be problems for nodes with higher bandwidth requirements and
> many cells in the schedule to guarantee zero slotOffset collisions in
> one own’s schedule across slotframe iterations. Don’t really like it
> though for the reason of breaking the scheduling function.
>
> As a reminder, in minimal-security we resorted to the current rekeying
> mechanism and not the one using the exact timestamp in the future when
> the whole network switches to new keys in order to avoid having to
> know the network notion of time at the JRC.
>
> Mališa
>
>> On 4 Apr 2019, at 19:33, Mališa Vučinić <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> My understanding is that the problem in the permuted schedule arises
>> during COJP_REKEYING_GUARD_TIME after nodes in the network started
>> using the new keys, but have still kept the old key in case someone
>> has not yet switched. When coupled with a rekeyed permutation key to
>> calculate the schedule, this means that during
>> COJP_REKEYING_GUARD_TIME a node would need to follow two schedules,
>> one with the old permutation key and one with the new one. The
>> problem in following two schedules for COJP_REKEYING_GUARD_TIME is
>> that draft-tiloca-6tisch-robust-scheduling-01 recommends both the
>> slotOffset and the channelOffset be permuted so that it may occur
>> that there can be a collision in slotOffset between the new and the
>> old schedule.
>>
>> The problem that draft-tiloca-6tisch-robust-scheduling solves seems
>> to be the predictability of the channel on which a transmission is
>> going to take place. With that in mind, I have second thoughts about
>> the recommendation on permuting the slotOffset, especially taking
>> into account that this will break any scheduling function that
>> optimizes for latency, as discussed in Section 6.3.
>>
>> Mališa
>>
>>
>> [email-masked] <mailto:[email-masked]>

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Apr 2019 14:15:19 -0400

Mališa Vučinić <[email-masked]> wrote:
    > using the new keys, but have still kept the old key in case someone has

It's not just during that time, but from the time it receives the new keys
until it switches to the new key and permutation.  If it would listen on both
permutations, I guess it would work.

The problem is that the rekey for a node does not start until it receives
traffic with the new key.  If it's not listening at the right time (and right
channel), then it will never receive such a packet.

If we could delay the switch to the new schedule until *after*
COJP_REKEYING_GUARD_TIME has elapsed, then that might work.
Alternatively, if we could number the rekeys then a EB could signal the
switch to the new schedule some time after the keys are changed.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Apr 2019 14:22:54 -0400

Mališa Vučinić <[email-masked]> wrote:
    > the whole network switches to new keys in order to avoid having to know
    > the network notion of time at the JRC.

Also so that the many unicast conversations needed to do the rekey can be spread
across a large amount of time, letting the JRC reach out to even very sleepy
nodes.

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 5 Apr 2019 23:10:08 +0200

> across a large amount of time, letting the JRC reach out to even very sleepy

Good point indeed, sleepy nodes may miss the reception slots and appear disconnected but as long as they are in the network they will eventually get the CoJP Parameter Update Request and the new keys, assuming JRC implements the default retransmission mechanism.

Mališa

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 5 Apr 2019 23:10:16 +0200

> On 5 Apr 2019, at 20:15, Michael Richardson <[email-masked]> wrote:
> 

Not sure about that the exact switch after COJP_REKEYING_GUARD_TIME would work, different nodes receive the new keys at different instants so it would be hard to sync them. I like better the trigger with an EB, it originates at 6LBR that is trusted and the frame can be authenticated by the nodes that have installed the new keys.

Mališa

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Apr 2019 18:24:05 -0400

Mališa Vučinić <[email-masked]> wrote:
    >> Alternatively, if we could number the rekeys then a EB could signal
    >> the switch to the new schedule some time after the keys are changed.

    > Not sure about that the exact switch after COJP_REKEYING_GUARD_TIME
    > would work, different nodes receive the new keys at different instants
    > so it would be hard to sync them. I like better the trigger with an EB,
    > it originates at 6LBR that is trusted and the frame can be
    > authenticated by the nodes that have installed the new keys.

So we need to add a permutation index to the key update that
robust-scheduling provides, and then it needs to allocate a
IE value.

Oh: chairs, I think we should adopt this document.  I know you didn't ask
yet.  I think it's useful enough to make it part of the base architecture!