IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 05 April 2019 18:15 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 633EE12047C; Fri, 5 Apr 2019 11:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 URWOu9SkwXuG; Fri, 5 Apr 2019 11:15:22 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB481201CC; Fri, 5 Apr 2019 11:15:22 -0700 (PDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id AACC838277; Fri, 5 Apr 2019 14:14:28 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id ED8F0FEC; Fri, 5 Apr 2019 14:15:19 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EB225DC7; Fri, 5 Apr 2019 14:15:19 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
cc: Marco Tiloca <marco.tiloca@ri.se>, 6tisch <6tisch@ietf.org>, draft-tiloca-6tisch-robust-scheduling@ietf.org
In-Reply-To: <5B3CDDA6-E057-4486-B2C2-3BD9E369F6D9@inria.fr>
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: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 05 Apr 2019 14:15:19 -0400
Message-ID: <31163.1554488119@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/MYQlJlLpmxwpWjhf4iQ60xsPnKM>
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: Fri, 05 Apr 2019 18:15:25 -0000

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

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.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email