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

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 04 April 2019 21:39 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 E82511201A1; Thu, 4 Apr 2019 14:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.92
X-Spam-Level:
X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 G5SZNeP-er6P; Thu, 4 Apr 2019 14:38:58 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 1E53912011A; Thu, 4 Apr 2019 14:38:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,309,1549926000"; d="scan'208,217";a="301858514"
Received: from lfbn-1-4128-78.w92-169.abo.wanadoo.fr (HELO mp341-pro.home) ([92.169.126.78]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Apr 2019 23:38:55 +0200
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Message-Id: <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3FF05691-B3C5-4810-9CB0-F4DCACCB0A0E"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 4 Apr 2019 23:38:54 +0200
In-Reply-To: <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr>
Cc: 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org, Marco Tiloca <marco.tiloca@ri.se>
To: Michael Richardson <mcr@sandelman.ca>
References: <5427.1554253601@localhost> <6ec51921-6dd6-78d4-9b5d-bde9ad40b35c@ri.se> <8081.1554386670@localhost> <B222C2F7-084F-4CBA-A55D-720619058D38@inria.fr> <10538.1554392453@localhost> <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/I5hwxWbXegHqSW9ZUmhQYNdWP7E>
Subject: Re: [6tisch] draft-tiloca-6tisch-robust-scheduling-01 --- rekeying permutation key
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: Thu, 04 Apr 2019 21:39:02 -0000

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ć <malisa.vucinic@inria.fr> 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
> 
> 
>> On 4 Apr 2019, at 17:40, Michael Richardson <mcr@sandelman.ca <mailto:mcr@sandelman.ca>> wrote:
>> 
>> Can you see how the old/new key issue interacts poorly with the permuted
>> schedule?
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch