Subject: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

From: Christian Amsüss <[email-masked]>
Date: Sun, 19 Sep 2021 13:10:09 +0200

Hello 6TiSCH group,

have the discussions in the development of CoJP ever sidetracked to its
applicability for non-TSCH setups?

Sure, there would be differences: The joined devices would need to keep
track of time in some way on their own (possibly less precise than for
ASNs; a confident upper bound suffices), and someone (the JRC?) would
need to confidently keep some absolute time of the key. But in total, my
gut feeling would be that one or two new values to the CoJP Parameters
registry could suffice to make CoJP usable for DSME, NBE or BE (CAP /
CSMA/CA) modes.

Doing these extensions is clearly out of scope of 6TiSCH, but pointers
to any previous discussion or evaluation, or opitions on the feasability
of such an undertaking would probably best be obtained from here.

Thanks in advance
Christian

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying

---

From: Michael Richardson <[email-masked]>
Date: Sun, 19 Sep 2021 15:48:44 -0400

> applicability for non-TSCH setups?

not really.

    > Parameters registry could suffice to make CoJP usable for DSME, NBE or
    > BE (CAP / CSMA/CA) modes.

I think that the CoJP worked very very hard to keep it at one round trip.

This is due to congestion concerns further up the RPL tree.
I don't perceive that these other technologies have this problem to the same
degree.

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

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 20 Sep 2021 11:13:11 +0200

Hello Michael,

> > applicability for non-TSCH setups?

thanks, that's good to know too.

> I don't perceive that these other technologies have this problem to the same

Running 6LoWPAN in other modes could still be RPL-based. The nodes close
to the BR would still see much traffic, though they might deal with it
differently than 6TiSCH. (Especially with the simpler modes, I expect
congestion to even have worse effects than with 6TiSCH).

Anyhow, there don't appear to be any parts that are particularly hard to
implement that could be dropped with a less strict one-roundtrip rule,
so overall it's still a good property.

I'll explore this further as time permits, and hope to at some point
come back asking for opinions on a concrete proposal.

Thanks
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 20 Sep 2021 12:15:27 +0200

Hi Christian,

As you could probably see from RFC9031, we did make an attempt to separate TSCH-specific from generally-applicable text, but we indeed never instantiated it for non-TSCH setups and additional parameters would need to be registered and described. I do concur that the biggest challenge I foresee at this point is the notion of time.

The use cases you mention are bound to 15.4 radios. Do you see this effort potentially useful for other low-power radio technologies?

Mališa

--
Mališa Vučinić
Research Scientist, Inria
Co-chair, IETF LAKE

> On 20 Sep 2021, at 11:13, Christian Amsüss <[email-masked]> wrote:
> 
> Hello Michael,
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 20 Sep 2021 12:54:22 +0200

On Mon, Sep 20, 2021 at 12:15:27PM +0200, Mališa Vučinić wrote:
> As you could probably see from RFC9031, we did make an attempt to
> separate TSCH-specific from generally-applicable text,

yes, thanks for that -- if that were not done, the endeavour would be a
lot harder.

> The use cases you mention are bound to 15.4 radios. Do you see this
> effort potentially useful for other low-power radio technologies?

I'm not sufficiently familiar with other technologies' security
mechanisms; I'm struggling enough with in-15.4 use.

I originally thought I'd just take a K1 and K2 and the existing key
usage table, but these are actually 6TiSCH specific. It'd be quite a
waste to repeat the 14 modes to say the same about any other MAC
(especially as using the K1/K2 separation probably makes sense there
too); maybe the other parameters can skew the semantics. ("If this
parameter is present, keys are used for 802.15.4 as in the given 6TiSCH-
key usage, but with the adaptations described in this document").

A non-802.15.4 network would certainly need new values there, I hope to
manage without to keep overhead low.

BR
c

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 20 Sep 2021 13:37:15 +0200

> On 20 Sep 2021, at 12:54, Christian Amsüss <[email-masked]> wrote:

> key usage, but with the adaptations described in this document").

I guess you refer to the usage of term “EB” i.e. Enhanced Beacon in the “Description” column in Table 6, values 0-8? This could have easily been replaced with just “Beacon” to keep applicability to the BE mode and/or noted with a sentence. I am not familiar with DSME mode, but from a quick glance over the 802.15.4-2015 std, I see that DSME uses the term “EB”, as well.

NBE mode obviously doesn’t need any of the usage values where beacons are mentioned, but values 9-14 should do it just fine. I might be missing something?

Other than that, there is the term “6TiSCH” used in all the names, but that doesn’t seem to be a technical issue.

So yes, I guess noting such details in your dcoument makes sense.

Mališa