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
- [6tisch-security] suggested agenda for 6tisch sec… Rene Struik
- [6tisch-security] Suggested agenda for 6tisch sec… Rene Struik
- Re: [6tisch-security] Suggested agenda for 6tisch… Michael Richardson
- [6tisch-security] Suggested agenda for 6tisch sec… Rene Struik
- Re: [6tisch-security] Suggested agenda for 6tisch… Thomas Watteyne
- [6tisch-security] reminder -- 6tisch security cal… Rene Struik
- [6tisch-security] (minutes of Tue Jan 5, 2015, 5p… Rene Struik
- [6tisch-security] (minutes of Tue Dec 16, 2014, 5… Rene Struik
- [6tisch-security] (w/ slight correction) Fwd: (mi… Rene Struik
- Re: [6tisch-security] reminder -- 6tisch security… Thomas Watteyne
- Re: [6tisch-security] (minutes of Tue Jan 5, 2015… Michael Richardson
- [6tisch-security] (minutes of Wed Jan 14, 2015, 1… Rene Struik
- [6tisch-security] reminder -- 6tisch security cal… Rene Struik
- Re: [6tisch-security] reminder -- 6tisch security… Michael Richardson
- [6tisch-security] (result homework assignment I v… Rene Struik
- Re: [6tisch-security] (result homework assignment… Rene Struik
- [6tisch-security] (Important -- 6tisch security c… Rene Struik
- [6tisch-security] (updated agenda) Re: (Important… Rene Struik
- Re: [6tisch-security] (Important -- 6tisch securi… Michael Richardson
- [6tisch-security] (minutes 6tisch security call T… Rene Struik
- [6tisch-security] (minutes 6tisch security call T… Tero Kivinen
- [6tisch-security] reminder -- 6tisch security cal… Rene Struik
- [6tisch-security] (minutes 6tisch security call T… Rene Struik
- [6tisch-security] Reminder -- 6tisch security cal… Rene Struik
- [6tisch-security] Latency aspects of TSCH Malisa Vucinic
- Re: [6tisch-security] Reminder -- 6tisch security… Rene Struik
- Re: [6tisch-security] Reminder -- 6tisch security… Thomas Watteyne
- [6tisch-security] (simplified explanation of form… Rene Struik
- Re: [6tisch-security] (simplified explanation of … Malisa Vucinic
- Re: [6tisch-security] (simplified explanation of … Rene Struik
- Re: [6tisch-security] (simplified explanation of … Jonathan Simon
- Re: [6tisch-security] (simplified explanation of … Rene Struik
- Re: [6tisch-security] (simplified explanation of … Jonathan Simon
- Re: [6tisch-security] (simplified explanation of … Giuseppe Piro
- Re: [6tisch-security] (simplified explanation of … Malisa Vucinic
- Re: [6tisch-security] (simplified explanation of … Giuseppe Piro
- Re: [6tisch-security] (simplified explanation of … Giuseppe Piro
- Re: [6tisch-security] Latency aspects of TSCH Michael Richardson
- Re: [6tisch-security] (simplified explanation of … Michael Richardson
- Re: [6tisch-security] Latency aspects of TSCH Malisa Vucinic
- [6tisch-security] Reminder -- 6tisch security cal… Rene Struik
- Re: [6tisch-security] Reminder -- 6tisch security… Rene Struik
- [6tisch-security] (minutes 6tisch security call T… Rene Struik
- [6tisch-security] (minutes 6tisch security call F… Rene Struik
- [6tisch-security] (minutes 6tisch security call F… Rene Struik
- Re: [6tisch-security] Reminder -- 6tisch security… Thomas Watteyne
- [6tisch-security] (problem with WebEx link) Re: R… Rene Struik
- Re: [6tisch-security] (problem with WebEx link) R… Rene Struik
- Re: [6tisch-security] (problem with WebEx link) R… Thomas Watteyne