[6tisch] Progressing draft-tiloca-6tisch-robust-scheduling

Marco Tiloca <marco.tiloca@ri.se> Wed, 04 December 2019 07:02 UTC

Return-Path: <marco.tiloca@ri.se>
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 D2D7F1200FB for <6tisch@ietfa.amsl.com>; Tue, 3 Dec 2019 23:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.onmicrosoft.com
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 xA641PbHlMmV for <6tisch@ietfa.amsl.com>; Tue, 3 Dec 2019 23:02:17 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00087.outbound.protection.outlook.com [40.107.0.87]) (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 A6B991200A4 for <6tisch@ietf.org>; Tue, 3 Dec 2019 23:02:16 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SijMJgeEeXG1QPdXU2k+K7GpsZxWxoLriNrMkQn0kJzlgIrBP+1SEjVLoeyPTIqNoR9zY2UjpafscuFfEgsh/8w+CFWl6CeBQhPldCnZzSd8I7DFvTxF+Rw8BxRPEcCCk4mxFqzk+xjmXdGvib9Nd8ePfZUWcuR/SuQW93aLqF6xFISeHpGKnt7WlZ5xu45s2e7k8sqJHO9HVCGEPXuccPsvmQOIatxsdJsuQ/b1BI6zA8rEnBUGIMwosmln8/7kZ4X0pgxcBLNJ6Mh08W8cQ816NZlFe4DUbDw42Tu5RZDhat0C9qZicztvkPNtXqxR+cZyMdx5cqSWSLPn9UaXVg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aQNqew0eWd9e56OMjkYd6nc+CW45ONq1udlIEY7qc54=; b=HaGeLz1MbUq3SRaIHPRzS1RHrfYyYuYTFQHOQZRE2E4V55QPB2yT8ySWwIZdrLkf7wKViOTNyRMf0kfa7WcfjLtLy9HiqqxUZ/etzUdkFMVB+71cK7aUZvX3vhJiJ+ve3VRBnoTRAy5ogzZBGrWwoLlC+RAlLxi0JSCEGsfaEcaxJimPKat9rA/kysqEQ3mW00s/hvHyIz4R++btI8pegcMe29YUX4K9/Rk1g0S8N6IYgzXGrKg2d9UdZAI6HuBbe3uaqzsXfqrDzmyN/b3fDwBn4+LqHNv71O1oRv1dyTe70ubexxUaD/ED+B3wBeLjbm73TpC2xXPtr4zuryUsBQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 194.218.146.197) smtp.rcpttodomain=ietf.org smtp.mailfrom=ri.se; dmarc=pass (p=none sp=none pct=100) action=none header.from=ri.se; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-RISEcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aQNqew0eWd9e56OMjkYd6nc+CW45ONq1udlIEY7qc54=; b=D0FgQCn8KuAEosmykT6B6wKuqRyHgevl8uJ3oazPUWt78LlSzoIHvN5kTPrn069esaCfLoBqCQ7HW8QNl17Wk2gcmF4FdngHaraoDryC7iyLQEh8sam8GhlkeR7dS3wIeYmYmcmPjYplzyviT8d5/Lxwg7urjIClSQ9kW+5s+r4=
Received: from HE1P189CA0011.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:53::24) by AM5P18901MB0177.EURP189.PROD.OUTLOOK.COM (2603:10a6:203:78::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.12; Wed, 4 Dec 2019 07:02:14 +0000
Received: from HE1EUR02FT054.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::208) by HE1P189CA0011.outlook.office365.com (2603:10a6:7:53::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2516.13 via Frontend Transport; Wed, 4 Dec 2019 07:02:14 +0000
Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=ri.se;
Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se;
Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT054.mail.protection.outlook.com (10.152.11.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.2495.18 via Frontend Transport; Wed, 4 Dec 2019 07:02:13 +0000
Received: from [10.8.0.2] (10.116.0.226) by sp-mail-1.sp.se (10.100.0.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1779.2; Wed, 4 Dec 2019 08:02:12 +0100
To: "6tisch@ietf.org" <6tisch@ietf.org>
From: Marco Tiloca <marco.tiloca@ri.se>
Openpgp: preference=signencrypt
Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA==
Message-ID: <45871c85-2feb-b816-cb16-2047a910ee02@ri.se>
Date: Wed, 4 Dec 2019 08:02:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CGwjoKMEm8LyCyegI5J2JNcNbHSDorOEE"
X-Originating-IP: [10.116.0.226]
X-ClientProxiedBy: sp-mail-3.sp.se (10.100.0.163) To sp-mail-1.sp.se (10.100.0.161)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(39860400002)(43544003)(189003)(199004)(235185007)(31686004)(5660300002)(65956001)(2906002)(31696002)(2616005)(6916009)(305945005)(33964004)(7736002)(26005)(16526019)(186003)(386003)(81166006)(336012)(58126008)(16586007)(21480400003)(8676002)(16576012)(568964002)(316002)(8936002)(81156014)(2351001)(66574012)(70206006)(22746008)(6116002)(3846002)(70586007)(106002)(6306002)(22756006)(36756003)(71190400001)(356004)(6666004)(86362001)(966005)(2501003)(44832011)(14444005)(478600001)(5024004)(5640700003)(40036005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P18901MB0177; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 75fa0a32-b67d-45a1-283d-08d77887e3f0
X-MS-TrafficTypeDiagnostic: AM5P18901MB0177:
X-Microsoft-Antispam-PRVS: <AM5P18901MB01770EBD94B9521FB45E88CA995D0@AM5P18901MB0177.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 0241D5F98C
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: ElwfzJBNo9QhrSOI0dWMOxyzorzid8nTttNObeUXhP19jw/4p7MDgoF+0z5M+G2jGqu0eC52ruFlbqczJ/9zNhuj7bIOsdZykXsiLdL8YzFnkF3x4hnR/OtVL59k/LG4JWzTFG705uf4G2o8AxC1sXiZW35k0+XdQqe7/G/ByKqTNjDq6hTw2L2+IRieHVMo0YHSMOfwxO+zyK61j8KFj2OC7UIpy1sbnIGyLgvkM5qEGXoJFDr68RKvSTY2Zi3mQV18NupHmpUDDKIbfTmUNBPza5Sncg9TVzRXsHpnVDl39dU4DX73iWvNHyVnpAgMZkqp0qSgAE/NBip8FezX6b98xz8FakUIXZJ0WBgJolvV+pSP50/JRcF0FqFtcszt3Be/K35TsAuvQkwIaEBAvfAZhfFLfxdXZGPJMbv6Om7+ICJ9iljTJ+D3wAALgxxOgPlkg6akFPE4mMLm9B4a2nKgLmdoOnRmKxb7Rdtlt7I0qmSdMMhUM+F/zMBaMk+nNmSdlr6AN3hPd62cuF6czxfpdJCkhaJWgT6VPoyjBac=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2019 07:02:13.5538 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 75fa0a32-b67d-45a1-283d-08d77887e3f0
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P18901MB0177
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/oWBD8fYBuA6lsmIyCiWUGhJ9Q-Y>
Subject: [6tisch] Progressing draft-tiloca-6tisch-robust-scheduling
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: Wed, 04 Dec 2019 07:02:21 -0000

Hello 6TiSCH,

As agreed at the IETF 106 meeting, I start this thread to support the
continuation of the 6TiSCH WG and the work on this document.

https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling

The draft describes how 6TiSCH nodes can efficiently and pseudo-randomly
alter their original schedule at each slotframe. The resulting schedule
is robust and not vulnerable to selective jamming attack, while
remaining consistent as well as collision-free. Appendix A shows a
step-by-step example output from the proof-of-concept implementation at [1].

After the presentation at IETF 104, the draft was well received, and got
three positive reviews from Michael [2], Tengfei [3] and Pascal [4].
Reviewers' comments were addressed in the latest v -02 presented at IETF
105.

An open point concerns the renewal of keying material to permute the
schedule. The current draft discusses how such keys can be distributed
to a pledge by relying on CoJP (Section 5), and redistributed to current
nodes in case of rekeying (Section 6.2). As to the actual switch from
old to new permutation keys at the current nodes, a discussion on the
list with Malisa and Michael set the ground for a good approach to work
on. The last message on that topic is at [5].


At IETF 105, this work was put on hold, without proceeding to check for
WG adoption as requested by the authors. The reasons were: i) possible
termination of the WG later in 2019; ii) possible better belonging of
this work to IEEE rather than IETF.

Building on what mentioned at the mic at IETF 106 [6]:

1) I do believe that this document belongs to the IETF and its 6TiSCH
WG. The described solution intervenes precisely on the original
schedule, available from 6top or alternative protocols. Simply, the
permuted schedule is then used instead of the original one. Hence, the
proposed approach can be implemented above the MAC.

2) While IEEE 802.15.4 itself might be extended to similarly permute the
schedule, there is no chance that 802.15.4 will take care of
management/renewal of the necessary permutation keys. This would of
course limit and endanger the whole approach altogether. Instead, in
6TiSCH we can build on CoJP and the Parameter Update message from the
JRC used for link-layer traffic keys, to also provide and renew the
permutation keys (see above).

@Suresh: you asked about the document separating the schedule
permutation from the key management. This is in fact already the case,
as Section 4 describes the schedule permutation, while Section 5
describes the provisioning of the permutation keys to a pledge upon its
joining. The rekeying is now discussed in the small Section 6.2. If we
continue elaborating on the actual switch from old to new permutation
keys (see above), that point can definitely become an earlier functional
section of its own.


In summary, I am not in favor of closing 6TiSCH down yet, and I would
especially like to continue the work on this document, whose merits have
been recognized in the list, also by three positive reviews. At the same
time, as clarified above, I do believe that the IETF is its most
appropriate home, at the 6TiSCH WG.

Looking forward to your feedback and hopefully to progressing this work.

Thanks,
/Marco


[1]
https://gitlab.com/crimson84/draft-tiloca-6tisch-robust-scheduling/tree/master/test

[2] https://mailarchive.ietf.org/arch/msg/6tisch/AmdYIZJqwnLYkzXcyejWAfPRAGw

[3] https://mailarchive.ietf.org/arch/msg/6tisch/676O-xcWvHxRLjL-sSHQswS3mCk

[4] https://mailarchive.ietf.org/arch/msg/6tisch/a-SyZZWVluoTf-N8ky_D7Hu4lis

[5] https://mailarchive.ietf.org/arch/msg/6tisch/GdgNqNFGpcTRLCm4BI1O6BS36OE

[6] https://etherpad.ietf.org/p/notes-ietf-106-6tisch?useMonospaceFont=true

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se