IETF Logo Mail Archive

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

Mališa Vučinić <malisa.vucinic@inria.fr> Mon, 20 September 2021 10:15 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1223A3A03EF for <6tisch@ietfa.amsl.com>; Mon, 20 Sep 2021 03:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Elz7YACA9dSW for <6tisch@ietfa.amsl.com>; Mon, 20 Sep 2021 03:15:31 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290C83A0303 for <6tisch@ietf.org>; Mon, 20 Sep 2021 03:15:30 -0700 (PDT)
IronPort-HdrOrdr: A9a23:HHNpHKvKFHzyVQC8Wnb0ktC37skDGdV00zEX/kB9WHVpm6uj+fxG88566faZslsssRIb9uxoRpPgfZq0z/ccirX5Vo3PYOCJggGVEL0=
X-IronPort-AV: E=Sophos;i="5.84,326,1620684000"; d="p7s'?scan'208,217";a="529355152"
Received: from wifi-eduroam-85-246.paris.inria.fr (HELO smtpclient.apple) ([128.93.85.246]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2021 12:15:27 +0200
From: Mališa Vučinić <malisa.vucinic@inria.fr>
Message-Id: <618FD3B4-2935-4D9E-9F96-B63454890B50@inria.fr>
Content-Type: multipart/signed; boundary="Apple-Mail=_E12861D9-C405-4F81-810A-ABCE96F0F924"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 20 Sep 2021 12:15:27 +0200
In-Reply-To: <YUhQp3wQ6O3qXp6R@hephaistos.amsuess.com>
Cc: Michael Richardson <mcr@sandelman.ca>, 6tisch@ietf.org
To: Christian Amsüss <christian@amsuess.com>
References: <YUcakTFqibo5wEfe@hephaistos.amsuess.com> <102718.1632080924@dooku> <YUhQp3wQ6O3qXp6R@hephaistos.amsuess.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/al6IIWGhMrTI6lPU8pUwAD_37R0>
Subject: Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Sep 2021 10:15:36 -0000

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 <christian@amsuess.com> wrote:
> 
> Hello Michael,
> 
> On Sun, Sep 19, 2021 at 03:48:44PM -0400, Michael Richardson wrote:
>>> have the discussions in the development of CoJP ever sidetracked to its
>>> applicability for non-TSCH setups?
>> 
>> not really.
> 
> thanks, that's good to know too.
> 
>> 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.
> 
> 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
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch

v2.23.0 | Report a Bug | By Email