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

Marco Tiloca <marco.tiloca@ri.se> Fri, 05 April 2019 08:30 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 D66AC120391; Fri, 5 Apr 2019 01:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 OWDjrMIBaiMj; Fri, 5 Apr 2019 01:30:01 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40053.outbound.protection.outlook.com [40.107.4.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF891201BE; Fri, 5 Apr 2019 01:30:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d8/MwwXlDpmmWhJFOusKg0XuTMfTbJIux5Mv3/QfosM=; b=A507TSxVw6IY8CATiokcvEeWTxOsZq4ctgdA5k5rwZFC945nezMxH6HpJFohaVlHNqxJ6jUBtSaBTVEFcpEu6EmoQXpofTX5MAblu0bFFEqKowrEQrcCjK59hB2vVhekaF6vU/EHKpS7xDJK2a5jPBurskKaG4tkpRSdEG6oUmk=
Received: from VI1P189CA0023.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::36) by AM5P189MB0322.EURP189.PROD.OUTLOOK.COM (2603:10a6:206:20::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15; Fri, 5 Apr 2019 08:29:57 +0000
Received: from HE1EUR02FT023.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::209) by VI1P189CA0023.outlook.office365.com (2603:10a6:802:2a::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15 via Frontend Transport; Fri, 5 Apr 2019 08:29:57 +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=bestguesspass 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 HE1EUR02FT023.mail.protection.outlook.com (10.152.10.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1750.20 via Frontend Transport; Fri, 5 Apr 2019 08:29:56 +0000
Received: from [10.112.10.131] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 5 Apr 2019 10:29:56 +0200
To: =?UTF-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>, "Michael Richardson" <mcr@sandelman.ca>
CC: 6tisch <6tisch@ietf.org>, <draft-tiloca-6tisch-robust-scheduling@ietf.org>
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> <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr>
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: <35064ce6-b5a1-e757-08c0-7b5b00900c74@ri.se>
Date: Fri, 5 Apr 2019 10:29:50 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <0409CD02-8399-400D-AA84-17A2CB878418@inria.fr>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pd0IhZUlC3fglBwMytfnG7tSo5c3vbz3z"
X-Originating-IP: [10.100.0.158]
X-ClientProxiedBy: sp-mail-2.sp.se (10.100.0.162) To sp-mail-2.sp.se (10.100.0.162)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(2980300002)(189003)(199004)(26005)(235185007)(5660300002)(44832011)(65826007)(8676002)(81166006)(81156014)(58126008)(54906003)(110136005)(93886005)(106466001)(8936002)(16526019)(186003)(53936002)(2616005)(6116002)(106002)(68736007)(336012)(446003)(476003)(486006)(126002)(64126003)(65806001)(65956001)(236005)(4326008)(11346002)(54896002)(6306002)(74482002)(7736002)(2906002)(568964002)(6246003)(478600001)(36756003)(14444005)(966005)(31686004)(21480400003)(229853002)(606006)(22756006)(40036005)(31696002)(104016004)(76176011)(6666004)(356004)(71190400001)(33964004)(16576012)(16586007)(386003)(53546011)(77096007)(84326002)(86362001)(5024004)(3846002)(66574012)(97736004)(69596002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5P189MB0322; 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: cf8537e3-5352-40d5-3009-08d6b9a0e2dc
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4709054)(2017052603328)(7193020); SRVR:AM5P189MB0322;
X-MS-TrafficTypeDiagnostic: AM5P189MB0322:
X-Microsoft-Antispam-PRVS: <AM5P189MB03223576EAA53C0D0D4DD5F799510@AM5P189MB0322.EURP189.PROD.OUTLOOK.COM>
X-Forefront-PRVS: 0998671D02
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: lVRjuiuzp9EkHJxPo4W6XcbDbMSwZixesiyX49cyduCGCSU89oYL1P0e610iXqkpB5ofUiVTPhqwU+NJOutBiOHH9tzs2Xuu43JmrEY3EHV852hoc+SyBPkSAzH8mq2AwuR4cL94xud9z56Rpf5Ebv9a1AYZy/w00RHLSPlDCv3r9iz+TDmDVuTIC15yMrfZugvZkuDcTW+UBAJkOT5caJL7+BAu9Bc/IXqBkybJz+wfX1rHA1JAf9sktO0WfV/M1gpk+yJbjZLPyNhIvwE1BBvJq8AAYamCu9BcQC3QTsd9XDHZX6j6ipHhfzxrRildD1nDp5xCmcyxeArKBIAt2MX9+MeFnjVLd+xp77LOKaMH3nKPJ70RSu9/qkLpf6J0gG+RdpKuwtU/PI7GZobKAdJBrxL8YLnT6huEZHi2Sws=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2019 08:29:56.9367 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cf8537e3-5352-40d5-3009-08d6b9a0e2dc
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: AM5P189MB0322
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/flO6X5RZ7A5F9SQHC3NY8xIkllE>
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 08:30:05 -0000

Hello Mališa, Michael,

Thanks for this discussion, I think this is a good summary of the problem.

Just to stress that the full-fledged approach, by making also
slotOffsets unpredictable rather than static (i.e. obviously
predictable) further greatly decreases the attack surface, since a
now-random jammer would be forced to guess both channels and timeslots
of target node(s). On the other hand, it's surely undesirable when
keeping latency at bay is a priority and a criterion of the original
scheduling function.

So, I agree that we can better think of what recommending in Section
6.3, and under which assumptions. In case: i) the original scheduling
function is not oriented to latency optimization; and ii) it is
acceptable for nodes to experience collisions during
COJP_REKEYING_GUARD_TIME upon network rekeying; then permuting also the
slotOffsets should IMHO still be the preferable thing to do and recommend.

Best,
/Marco

On 4/4/19 11:38 PM, Mališa Vučinić wrote:
> 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
>> <mailto: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 <mailto:6tisch@ietf.org>
>> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
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