[6tisch] Time Synchronization

Tero Kivinen <kivinen@iki.fi> Tue, 09 February 2016 12:52 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F200D1A8A7F for <6tisch@ietfa.amsl.com>; Tue, 9 Feb 2016 04:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EM_ejWXYM-1X for <6tisch@ietfa.amsl.com>; Tue, 9 Feb 2016 04:52:22 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi []) (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 9DB091A8A7B for <6tisch@ietf.org>; Tue, 9 Feb 2016 04:52:21 -0800 (PST)
Received: from fireball.acr.fi (localhost []) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u19CqH22029905 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Feb 2016 14:52:17 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u19CqHKc029009; Tue, 9 Feb 2016 14:52:17 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22201.57601.154531.754070@fireball.acr.fi>
Date: Tue, 9 Feb 2016 14:52:17 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Oliver Hahm <oliver.hahm@inria.fr>
In-Reply-To: <20160209103531.GA7336@hobbykeller.org>
References: <20160209103531.GA7336@hobbykeller.org>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 12 min
X-Total-Time: 27 min
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/LGiH-JD92zA4Gp3mD1WER-QuAfI>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: [6tisch] Time Synchronization
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 09 Feb 2016 12:52:24 -0000

Oliver Hahm writes:
> Probably I miss something obvious here, but I just stumbled about two things
> in RFC7554 and Minimal that seem to be contradicting at a first glance:
> RFC7554 in A8 states: "Nodes can keep synchronization exclusively by
> exchanging EBs." However, draft-ietf-6tisch-minimal-14 in section 6 states:
> "EBs MUST NOT be used for time synchronization."
> Can anyone enlighten me how to interpret this? May EBs be used for time
> synchronization or not?

In the TSCH there is two ways to do time synchronization:
acknowledgment-based and frame-based (see section of

Enhanced beacons are broadcast messages, thus they are not
acknowledged, so acknowledgment-bsaed synchronization cannot be used.

On the other hand Frame based could be used for the Enhanced beacons,
but the problem is that if Enhanced beacons are not authenticated with
proper secret key, the attacker could perhaps send beacons in wrong

I.e., it is better to use the acknowledgment-based node syncronization
using properly generated link keys, or if using Frame-based
authentication, use frames which use some other key than K1, and thats
why the minimal draft says that Enhanced Becaons are not used for time