Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21

"Pascal Thubert (pthubert)" <> Mon, 24 June 2019 08:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53A881200FE; Mon, 24 Jun 2019 01:20:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=b7MRzlZJ; dkim=pass (1024-bit key) header.b=Cv1rXQwb
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6WTMYdVPSYsj; Mon, 24 Jun 2019 01:20:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFFFC120048; Mon, 24 Jun 2019 01:20:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6348; q=dns/txt; s=iport; t=1561364427; x=1562574027; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HAzIYY9V5elj0jCrSO+WfeWX7BLw2M83ifiMa5MFags=; b=b7MRzlZJbHDUyKZETQvmuo6uWvjW1FYoZF7fbW8jTk2rQkTu7QrG1GHK r6KhqsWSlT3RZgnsLYHIX5kW0hGJqmMY/GoA/7BV0m52FZ+TRmgFJEZS1 MJviKFk8PLQU35eJlgl62XbFfTS8SKYRPEFMNDR/UNI08AWDtMiiWdtXe Q=;
IronPort-PHdr: 9a23:hRYVThIp56ZhdooywdmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.63,411,1557187200"; d="scan'208";a="290801253"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2019 08:20:25 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x5O8KPQF011553 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jun 2019 08:20:25 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 03:20:24 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 04:20:23 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 24 Jun 2019 03:20:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HAzIYY9V5elj0jCrSO+WfeWX7BLw2M83ifiMa5MFags=; b=Cv1rXQwbUNEjpsjamMaicDVdng1k6FodzGOkaMzdHg7OTRXWyBIsouhu4V5WOe+XVJvZBGemnI9PI6v+/Uce6vf8nRyRSzLNotV1yCC0M5jLFG399IRjur0YKneh3qRxz6E2ZHdCR2RzkKaOtDpDNAorgv8kYnszh7t/f9R2r8I=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Mon, 24 Jun 2019 08:20:22 +0000
Received: from ([fe80::1ce9:1582:146c:c50a]) by ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 08:20:21 +0000
From: "Pascal Thubert (pthubert)" <>
To: David Mandelberg <>, "" <>, "" <>, "" <>, Thomas Watteyne <>, Michael Richardson <>, Mališa Vučinić <>
Thread-Topic: secdir review of draft-ietf-6tisch-architecture-21
Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKaqVH6w
Date: Mon, 24 Jun 2019 08:20:12 +0000
Deferred-Delivery: Mon, 24 Jun 2019 08:20:04 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 860f3817-4efb-4bf8-531e-08d6f87cccf7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4126;
x-ms-traffictypediagnostic: MN2PR11MB4126:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 007814487B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(396003)(136003)(376002)(13464003)(199004)(189003)(55674003)(2906002)(55016002)(7696005)(2501003)(3846002)(81166006)(33656002)(478600001)(81156014)(102836004)(316002)(110136005)(8936002)(186003)(26005)(66066001)(68736007)(53546011)(6506007)(229853002)(99286004)(76176011)(6116002)(76116006)(9686003)(14444005)(305945005)(5660300002)(52536014)(476003)(256004)(486006)(7736002)(86362001)(25786009)(446003)(11346002)(6436002)(6246003)(73956011)(66476007)(66446008)(64756008)(66556008)(66946007)(71190400001)(71200400001)(8676002)(2201001)(6666004)(53936002)(74316002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4126;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Xrw4SOeHN6WTXwneIL493m4ec2th+pumq5Q5OoJWjrAljPubbn6xNAbsg5AReBWXSB+jzv4tQWhvmnPk/fNS1xH3kDgv5HNqFKy+6vYW/TcLLR726l21zDSPH77PMSnMAIqDMYfwLTGXBcpwzpYZUaESpOfpbzMUHQxQe9XJLY6971Iwg2ZUz6Bm/cxiJ/hAnLZn6r4VPlFRVNvoDGsaTGbxmNt4dY8N8ldLZJ5Tu962kyde89USAbTd5F8jNzbrH520xGTiPcpEsBee+DWMc7RtCnXw3+Du/GOqN5lRB7eIJxPNPWfog2Ph+WhDuwkyvftgUFkFACNTIY8pqCztTEWqx5lf1eB6Pc5Yc17EXys9I58bnGuC4zkhMOxQGt1vf1K/dxeB3oW+Qce++3X3hE7cLJZZh1y7Ehqe4FGRrYM=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 860f3817-4efb-4bf8-531e-08d6f87cccf7
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 08:20:21.5419 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4126
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Jun 2019 08:20:28 -0000

Hello David:

Many thanks for your review. I do hope that you found it interesting.

> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time
> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely
> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time
> synchronization done before the join process, and is there any way to exploit
> time synchronization in order to cause a node to join a malicious network?

This is really a MAC layer question for IEEE. I'm cc'ing Thomas who was one of the inventors of TSCH, as well as Michael and Malisa who led the join process study.

Time synchronization (date):
For all I know, the time sync is about giving a epoch time from which an Absolute Slot Number (ASN, expressed in slot duration e.g., 10ms) is derived.
ASN plays a key role as it is used in NONCE. An attack that one could think of would be to fool the new node into thinking that ASN is earlier. This could happen before the keys are exchanged, or if an authorized peer is compromised.
For the former, I'll defer to the others to answer fully how we protect the new comer. 
For the latter, 6TiSCH provides an additional protection since we derive time from a RPL parent. RPL has its own protections, some of them in the standard itself, some of them in zerotrust papers that need publishing. 

Time synthonization (precise tic, hourless)
This is the process whereby a node corrects its tic to realign with the parent. ASN is not changed but the drift of crystals is compensated.
An attacker could try to inject a sense of time that it slightly shifted to the point that the node lose sync with the rest of the network (the guard time is like an event horizon). Then again, RPL provides an additional protection on top of the MAC provisions.

In the meantime your remark reserves some text. Note that the dependency on time is inherited from DetNet and TSN, and DetNet has text about it that we can reference.

In conjunction with Andrew's review I'd propose:
    The operation of 6TiSCH Tracks inherits its high level operation from DetNet
    and is subject to the observations in section 5 of [ietf-detnet-architecture].
    As discussed there, measures  must be taken to protect the time 
    synchronization, and for 6TiSCH this includes ensuring that the ASN, which is
    used for the computation of NONCE, is not compromised. Also, the installation
    and maintenance of 6TiSCH Tracks depends in the availability of a controller
    with a PCE to compute and push them in the network. When that connectivity
    is lost, existing Tracks may continue to operate until the end of their
    lifetime, but cannot be removed or updated, and new Tracks cannot be
    installed. As with DetNet in general, the communication with the PCE must be
    secured and should be protected against DoS attacks, and the discussion on
    the security considerations defined for Abstraction and Control of Traffic
    Engineered Networks (ACTN) applies equally to 6TiSCH.

Does that sound good?


> -----Original Message-----
> From: David Mandelberg <>
> Sent: lundi 24 juin 2019 03:22
> To:;;
> Subject: secdir review of draft-ietf-6tisch-architecture-21
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> The summary of the review is Ready with nits.
> The review deadline for this was really short, so I didn't have a chance to read
> this as closely as I would have liked. That said, from skimming the document
> and reading the sections that looked most interesting, it looks pretty good. The
> security considerations section covers what I expected it to. I have only one
> question/concern:
> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time
> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely
> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time
> synchronization done before the join process, and is there any way to exploit
> time synchronization in order to cause a node to join a malicious network?