Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH

Rene Struik <rstruik.ext@gmail.com> Tue, 17 February 2015 21:44 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3DA1A8A6B for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 13:44:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.59
X-Spam-Level:
X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=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 kbeq0SftWzjc for <6tisch-security@ietfa.amsl.com>; Tue, 17 Feb 2015 13:43:57 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190CC1A0102 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 13:43:57 -0800 (PST)
Received: by mail-ig0-f176.google.com with SMTP id hl2so32660039igb.3 for <6tisch-security@ietf.org>; Tue, 17 Feb 2015 13:43:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=N74JTXXSZMaSzPNMWa6YMHebjNgpJhqTIX1zml5ms3w=; b=oxRzunwLuShEsm+uChpnzBE2nVxOK9fMJGzWaFgzOJXlfvKp4u10r8m/V4nEqGGtvv vKYNuW+P3L8kfEibPs4TrAjEXcm7lhziu0q6C6/xzzZK9O/0uQBXPmgf/HXVV7NeZaZL D73JFHZR/YOWM0EXpJnYrQcVX0ibW3+sKeR/nagLCNsxlPkBCQHiC/7TsPPcliHXAMhU 1bAnCww+pT0Ki6v6xXvl3SoIGJfnmXKfEF6Dzv0Tv1NU7JutKgLLXk+UvpEa9dCaP5JQ u0yTyVWk8lRWluRW64DM6lqj5fI5jNi6cSGljlYUBmjBXVY7eIgVtlR4aQw3Xi0SQQrM 5G2w==
X-Received: by 10.50.78.232 with SMTP id e8mr30505786igx.5.1424209436325; Tue, 17 Feb 2015 13:43:56 -0800 (PST)
Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by mx.google.com with ESMTPSA id h19sm10759209igq.10.2015.02.17.13.43.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Feb 2015 13:43:55 -0800 (PST)
Message-ID: <54E3B604.5010803@gmail.com>
Date: Tue, 17 Feb 2015 16:43:32 -0500
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Jonathan Simon <jsimon@linear.com>
References: <54B5BA30.9020200@gmail.com> <54BD58F5.1040500@gmail.com> <54BDF1EF.1020300@gmail.com> <54BECA04.2060409@gmail.com> <54BECEA8.5060908@gmail.com> <54BFC61B.50004@gmail.com> <54C6763B.2070204@gmail.com> <54C8FD34.5040307@gmail.com> <54D98E01.4090103@gmail.com> <8E377EDE-074F-472E-B397-86F29AEDEB19@imag.fr> <54E37CD5.7090405@gmail.com> <4EDC1B3D-8E75-4FA8-8B3E-E458B3A9CAA8@imag.fr> <54E3A4D2.8090907@gmail.com> <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com>
In-Reply-To: <63410C6A-3545-4A24-B83C-F24E7D3A93A4@linear.com>
Content-Type: multipart/alternative; boundary="------------010605050302020100010205"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch-security/gHEoWiVCrTLdciVeUOEgaWH8wBQ>
Cc: Malisa Vucinic <Malisa.Vucinic@imag.fr>, 6tisch-security@ietf.org
Subject: Re: [6tisch-security] (simplified explanation of formulae) Re: Latency aspects of TSCH
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Feb 2015 21:44:00 -0000

Hi Jonathan:

Well, given the example on Slide 5 re DTLS with pre-shared keys, time 
latency is mainly driven by communication delays (due to TSCH 
scheduling) and computational delays are relatively marginal in 
comparison (the conclusion applies public-key based approaches as well). 
Please also see the eight month old (June 11, 2014) message with a 
similar conclusion: 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00153.html

BTW - there is no need to generate or test prime numbers, since it would 
be suicidal to consider RSA.

Best regards, Rene

On 2/17/2015 4:23 PM, Jonathan Simon wrote:
> It is also worth noting that it is implicit in the calculation that:
>
> * the the devices in question always have available buffers such that 
> there isn’t a lot of backoff
> * that any security related processing can happen before any 
> subsequent steps that rely on said processing occur.  This may not be 
> true for ECC operations or generation and testing of large primes.
>
> Jonathan
>
> On Feb 17, 2015, at 12:30 PM, Rene Struik <rstruik.ext@gmail.com 
> <mailto:rstruik.ext@gmail.com>> wrote:
>
>> Hi Malisa:
>>
>> In fact, I think my note on approximation of reals by rational 
>> numbers was too pessimistic: my two-line argument for the 1/(C+1) 
>> density formula should hold in general.
>>
>> Two further notes:
>> a) It seems one can easily extend the argument to cases where one 
>> inserts some "don't care" timeslot (Rx/Tx by any device) and include 
>> those in the C tally (if there are no clashes in access to that cell).
>> b) I think random scheduling is not really optimum, since there are 
>> wide variations in latency from the average. For more deterministic 
>> time latencies, one might want to look into schemes that have a much 
>> smaller variance.
>>
>> Best regards, Rene
>>
>> On 2/17/2015 3:17 PM, Malisa Vucinic wrote:
>>> Hi Rene,
>>>
>>> Thanks for confirming my calculation.
>>>
>>> I agree that theoretically this assumes infinite number of timeslots 
>>> in a slotframe but I believe it should be accurate enough for C << L.
>>>
>>> Regards,
>>> Malisa
>>>
>>>> On 17 Feb 2015, at 09:39, Rene Struik <rstruik.ext@gmail.com 
>>>> <mailto:rstruik.ext@gmail.com>> wrote:
>>>>
>>>> Hi Malisa:
>>>>
>>>> I had a closer look at the slides you presented at the 6TiSCH 
>>>> security call this morning, Feb 17, 2015.
>>>>
>>>> Slide 3 presents time latency numbers in case of a random TSCH 
>>>> schedule with C cells per slotframe, where the slotframe length is 
>>>> L time slots. I was trying to come up with an easy explanation for 
>>>> your time latency figure of ~ 1/(C+1)  the slotframe length between 
>>>> receiving a frame and sending a response in the next available 
>>>> dedicated "sending cell".
>>>>
>>>> It turns out one can do this without any nontrivial math. See below.
>>>>
>>>> Assumptions:
>>>> -w.l.o.g., receipt by A of frame from B ("A <--B") is at time zero 
>>>> (since schedule repeats)
>>>> -sending schedule of A: t cells, dividing up the unite line [0,1] 
>>>> in intervals of length L1, L2, ..., L{t+1}.
>>>> - t>0 (o.w., A is mute).
>>>>
>>>> Observe that any schedule of t cells corresponds 1-1 with a 
>>>> partitioning of the unit line [0,1]. Moreover, if (L1,L2, ..., 
>>>> L{t+1}) is a schedule, then so is any permutation hereof. As a 
>>>> result, the average size of the first segment over all schedules is 
>>>> (L1+ .... + L{t+1})/(t+1)=1/(t+1): simply add up the first segment 
>>>> of the schedules (L1,L2, ..., L{t+1}), (L2,L3, ..., L{t+1}, L1), 
>>>> ..., (L{t+1},L1, ..., Lt).
>>>> The result follows (take t:=C).
>>>>
>>>> Note: this assumes one has infinity many timeslots in a slotframe, 
>>>> so that one can approximate rational numbers by real numbers and 
>>>> one can ignore Li=Lj occurrences.(
>>>>
>>>>
>>>> On 2/16/2015 8:14 PM, Malisa Vucinic wrote:
>>>>> Hi all,
>>>>>
>>>>> I prepared a couple of slides on latency aspects with TSCH that 
>>>>> can hopefully be useful for evaluating different proposals for the 
>>>>> join process once there are more details on message sizes involved.
>>>>>
>>>>> Regards,
>>>>> Malisa
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 09 Feb 2015, at 20:50, Rene Struik <rstruik.ext@gmail.com 
>>>>>> <mailto:rstruik.ext@gmail.com>> wrote:
>>>>>>
>>>>>> Dear colleagues:
>>>>>>
>>>>>> Just a quick reminder that we have a 6TiSCH security conf call 
>>>>>> tomorrow, Tue February 10, 2015, 4.30pm EST.
>>>>>>
>>>>>> I have not seen any email traffic the last two weeks, nor any 
>>>>>> more feedback on the draft document I posted on Fri January 9th.
>>>>>>
>>>>>> I put as tentative item on the agenda "time latency aspects" of 
>>>>>> the join protocol. I will send out a more definitive agenda 
>>>>>> tomorrow around noon EST. Please send agenda request to me prior 
>>>>>> to that time.
>>>>>>
>>>>>> Suggested agenda:
>>>>>> 1) administrativia {agenda bashing/minutes}
>>>>>> 2) time latency aspects
>>>>>> 3) AOB
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 6tisch-security mailing list
>>>>> 6tisch-security@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/6tisch-security
>>>>
>>>>
>>>> -- 
>>>> email:rstruik.ext@gmail.com  | Skype: rstruik
>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>>
>>
>>
>> -- 
>> email:rstruik.ext@gmail.com  | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>> _______________________________________________
>> 6tisch-security mailing list
>> 6tisch-security@ietf.org <mailto:6tisch-security@ietf.org>
>> http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3vah6
>


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363