Subject: [6tisch-security] Reminder -- 6tisch security call *tomorrow*, Tue Feb 10, 2015, 4.30pm EST (includes dial-in info)

From: Rene Struik <[email-masked]>
Date: Mon, 09 Feb 2015 23:50:09 -0500

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

On 1/28/2015 10:16 AM, Rene Struik wrote:
> Dear colleagues:
>
> Please find below the minutes of the 6TiSCH Security conf call as of 
> January 27, 2015, 9-10am EST.
>
> Minutes 6TiSCH Security conf call, Wed January 27, 2015, 9-10am EST
> {note taker: Rene Struik}
> {recording: not available (Michael Richardson had control, but was not 
> on the call}
> {discussion material (referenced in minutes): this time, no posted 
> collatoral}
>
> 1. Attendance:
> Tero Kivinen, Yoshi Ohba, Rene Struik
>
> 2. Agenda
> The suggested updated agenda was approved.
> Suggested agenda:
> 1) administrativia {agenda bashing/minutes}
> 2) prep for IETF-92 in Dallas
> 3) AOB
>
> 3. Minutes
> The minutes of the previous 6TiSCH security conference call (Thu 
> January 22, 2015) were approved.
>
> 4. Prep for IETF-92 in Dallas {more of a 6tisch security various 
> "varia" discussion really}
> YO asked what happened with the output of the join process overview 
> text discussed during last week's call. RS mentioned that Pascal 
> Thubert included this in the 6tisch architecture draft (Section 13 - 
> Security Considerations) and would issue 
> draft-ietf-6tisch-architecture-05 for WGLC some time this week.
>
> RS mentioned that at the IETF-92 meeting in Dallas in March, the  
> 6tisch group would presumably recharter and include more 
> security-related milestones into the revised charter. He thought it 
> would be useful to have a 6tisch security draft by that meeting that 
> could serve as baseline.
>
> TK provided some more insight into the 802.15.4rev effort. He 
> suggested that there would be 1-2 more letter ballots, followed by the 
> start of sponsor ballot around end of March 2015, with anticipated 
> conclusion of the work around July-August this year. RS commented that 
> this schedule seemed quite aggressive, considering historical 
> timelines of IEEE 802.15 efforts. TK mentioned that according to Bob 
> Heile (Chair IEEE 802.15) the 802.15rev draft would only be available 
> in the 802.15 private member area or to those people participating in 
> person in an actual IEEE 802 meeting. Therefore, it does not seem 
> possible to make a draft available to interested parties in the 6tisch 
> community who did not meet those criteria (as previously suggested).
>
> 5. AOB
> RS suggested to cancel the 6tisch security call of next week and 
> reconvene two weeks from now, which was agreed upon. _Next call will 
> take place Tue Feb 10, 2015, 4.30pm EST._
>
> RS mentioned he had received feedback from Kris Pister and Yoshi Ohba 
> on draft-struik-6tisch-security-architectural-considerations-01 
> (posted January 9, 2015). Before updating the draft, he would like to 
> see more people give this a look. He invited people to use the now 
> cancelled slot of next week's call to review this draft...
>
> [call ended @9.23am EST]
>
>
> On 1/26/2015 12:15 PM, Rene Struik wrote:
>> Dear colleagues:
>>
>> Just a quick reminder that we have a 6TiSCH security conf call 
>> tomorrow, Tue January 27, 2015, 9am EST. I expect this to be a short 
>> call.
>>
>> Suggested agenda:
>> 1) administrativia {agenda bashing/minutes}
>> 2) prep for IETF-92 in Dallas
>> 3) AOB
>>
>> The dial-in info is below.
>>
>> Best regards, Rene
>>
>> _B) Dial-in information:_
>> English : New York Time 6tisch security
>> Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
>> Meeting number:   641 709 118
>> Meeting password: joinjoin
>> Audio connection:
>>        1-877-668-4493 Call-in toll free number (US/Canada)
>>        1-650-479-3208 Call-in toll number (US/Canada)
>>
>> Access code: 641 709 118
>> Meeting link:
>>          https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6
>>
>> The etherpad we have used is at:
>>         http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt
>>
>>
>>
>>
>> On 1/21/2015 10:30 AM, Rene Struik wrote:
>>> Dear colleagues:
>>>
>>> Giuseppe Piro offered to give a presentation on MAC security 
>>> aspects, resulting in the updated agenda below. Dial-in info at 
>>> bottom of email.
>>>
>>> Remember: 6tisch security call is now tomorrow, Thu Jan 21, 2015, 
>>> 1pm EST, with duration not to exceed one hour. Please call-in on 
>>> time and test your speaker/mike beforehand.
>>>
>>> Suggested updated agenda:
>>> 1) administrativia {agenda bashing/minutes} [4 min]
>>> 2) 6tisch security conf call schedule moving forward [1 min]
>>> 3) input 6tisch security to architecture draft [15 min]
>>> -- RS to present result homework assignment of last call
>>> 4) presentation Giuseppe Piro re MAC security [30 min]
>>> 5) prep for IETF-92 in Dallas [10 min]
>>> 5) AOB
>>>
>>> Link to suggested text (item #3 above):
>>> https://drive.google.com/file/d/0B2a6Ilxu1XfCbVhfd0ZONXoxc00/view?usp=sharing
>>>
>>> On 1/20/2015 4:54 PM, Rene Struik wrote:
>>>> Dear colleagues:
>>>>
>>>> Due to connectivity problems, those on the 6tisch security call 
>>>> today concluded that it was best to reschedule the call.
>>>>
>>>> The rescheduled 6tisch security call will take place this Thursday, 
>>>> January 22, 2015, 1-2pm EST.
>>>> (Please note that this is only once; schedule moving forward will 
>>>> otherwise remain the same)
>>>>
>>>> Agenda and dial-in info remain the same (please scroll down).
>>>>
>>>> Best regards, Rene
>>>>
>>>>
>>>> On 1/20/2015 4:35 PM, Rene Struik wrote:
>>>>> I posted the document on Google drive, see weblink below.
>>>>>
>>>>> https://drive.google.com/file/d/0B2a6Ilxu1XfCa3RyZzlZb3RRREk/view?usp=sharing
>>>>>
>>>>> On 1/20/2015 1:13 AM, Rene Struik wrote:
>>>>>> Dear colleagues:
>>>>>>
>>>>>> Please find attached my analysis of the three text proposals. I 
>>>>>> hope this helps in zooming in on consensus text.
>>>>>>
>>>>>> I will present this in more detail as item #3 on the agenda for 
>>>>>> the 6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST.
>>>>>>
>>>>>> We can discuss this in more detail during that call (I won't have 
>>>>>> much time beforehand).
>>>>>>
>>>>>> Best regards, Rene
>>>>>>
>>>>>> [excerpt of minutes of 6tisch security conf call as of January 
>>>>>> 14, 2015, 11am-12pm EST]
>>>>>> TW asked whether RS could review the three text proposals 
>>>>>> currently on the table and suggest a way forward that takes into 
>>>>>> account consensus and what was discussed during the call. RS 
>>>>>> agreed to take this on as homework assignment, with target to 
>>>>>> report back on this to the group by the end of Monday next week 
>>>>>> (January 19, 2015).
>>>>>>
>>>>>> On 1/19/2015 2:20 PM, Rene Struik wrote:
>>>>>>> Dear colleagues:
>>>>>>>
>>>>>>> Just a quick reminder that we have a 6TiSCH security conf call 
>>>>>>> tomorrow, Tue January 20, 2015, 4.30-5.30pm EST.
>>>>>>>
>>>>>>> Suggested agenda:
>>>>>>> 1) administrativia {agenda bashing/minutes}
>>>>>>> 2) 6tisch security conf call schedule moving forward
>>>>>>> 3) input 6tisch security to architecture draft
>>>>>>> -- RS to present result homework assignment of last call
>>>>>>> 4) prep for IETF-92 in Dallas
>>>>>>> 5) AOB
>>>>>>>
>>>>>>> For dial-in info, please see bottom of this email.
>>>>>>>
>>>>>>> As to item #2 above, if you wish to weigh-in, please do respond 
>>>>>>> to the Doodle poll by end of *today*, see 
>>>>>>> https://doodle.com/q63844gqd59urrae.
>>>>>>>
>>>>>>> Best regards, Rene
>>>>>>>
>>>>>>> -------- Forwarded Message --------
>>>>>>> Subject: 	reminder -- 6tisch security call *tomorrow*, Wed Jan 
>>>>>>> 14, 2015, 11am EST (dial-in info at bottom)
>>>>>>> Date: 	Tue, 13 Jan 2015 19:37:04 -0500
>>>>>>> From: 	Rene Struik <[email-masked]>
>>>>>>> To: 	tisch-security <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dear colleagues:
>>>>>>>
>>>>>>> Just a quick reminder that we *do* have a conf call tomorrow, 
>>>>>>> Wed Jan 14, 2015, 11am EST.
>>>>>>>
>>>>>>> Currently, the main agenda item is item #4b of last week: input 
>>>>>>> to the 6tisch architecture draft. It would also be good to have 
>>>>>>> some more comments on the draft I posted.
>>>>>>>
>>>>>>> Minutes of calls later tonight (sorry - extremely busy). For 
>>>>>>> conf call dial-in info, see bottom of email.
>>>>>>>
>>>>>>> Best regards, Rene
>>>>>>>
>>>>>>> ==
>>>>>>> Note: next week's call is on Wed Jan 14, 2015, 11am EST.
>>>>>>>
>>>>>>> On 1/6/2015 11:48 AM, Rene Struik wrote:
>>>>>>>> Dear colleagues:
>>>>>>>>
>>>>>>>> Happy New Year!
>>>>>>>>
>>>>>>>> According to the agreed-upon 6tisch security conf call 
>>>>>>>> schedule, we will resume the conference call series today, Tue 
>>>>>>>> Jan 6, 2015, 5pm EST.
>>>>>>>>
>>>>>>>> I propose we continue the discussion where we left off prior to 
>>>>>>>> Christmas (essentially, item 3c below), except that we may have 
>>>>>>>> a short presentation first (item #2).
>>>>>>>>
>>>>>>>> Agenda:
>>>>>>>> 1) administrativia {agenda bashing/minutes}
>>>>>>>> 2) {still to be confirmed} presentation Giuseppe Piro
>>>>>>>> 3) join protocol details
>>>>>>>> -- a) (done) status update MAC behavior
>>>>>>>> -- b) (brief!) recap of routing/communication flow aspects
>>>>>>>> -- c) incremental deployment aspects
>>>>>>>> 4) input 6tisch security to other 6tisch documents
>>>>>>>> -- a) terminology draft
>>>>>>>> -- b) architecture draft
>>>>>>>>
>>>>>>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris 
>>>>>>>> time. {The next call, on January 6, 2014) is also at 5pm EST 
>>>>>>>> (see schedule till half of January 2015)}.
>>>>>>>> Note: next week's call is on Wed Jan 14, 2015, 11am EST.
>>>>>>>>
>>>>>>>> Dial-in info at end of this email.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Rene
>>>>>>>>
>>>>>>>> -------- Forwarded Message --------
>>>>>>>> Subject: 	Suggested agenda for 6tisch security call of *today*, 
>>>>>>>> Tue December 16, 2014, 5pm EST (dial-in info at bottom)
>>>>>>>> Date: 	Tue, 16 Dec 2014 09:21:20 -0500
>>>>>>>> From: 	Rene Struik <[email-masked]>
>>>>>>>> To: 	tisch-security <[email-masked]>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Dear colleagues:
>>>>>>>>
>>>>>>>> I propose we continue the discussion where we left off last week.
>>>>>>>>
>>>>>>>> Agenda:
>>>>>>>> 1) administrativia {agenda bashing/minutes}
>>>>>>>> 2) join protocol details
>>>>>>>> -- a) (brief!) status update MAC behavior
>>>>>>>> -- b) continuation of routing/communication flow aspects {last 
>>>>>>>> week, we did not finish the only two slides on this
>>>>>>>> 3) input 6tisch security to other 6tisch documents
>>>>>>>>
>>>>>>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris 
>>>>>>>> time. {The next call, on January 6, 2014) is also at 5pm EST 
>>>>>>>> (see schedule till half of January 2015)}.
>>>>>>>>
>>>>>>>> Dial-in info at end of this email.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Rene
>>>>>>>>
>>>>>>>> -------- Forwarded Message --------
>>>>>>>> Subject: 	suggested agenda for 6tisch security call of 
>>>>>>>> tomorrow, Tue December 9, 2014, 9am EST (dial-in info at bottom)
>>>>>>>> Date: 	Mon, 08 Dec 2014 17:16:40 -0500
>>>>>>>> From: 	Rene Struik <[email-masked]>
>>>>>>>> To: 	tisch-security <[email-masked]>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Dear colleagues:
>>>>>>>>
>>>>>>>> For last week's Tue Dec 2, 2014, 9am EST conf call I prepared 
>>>>>>>> some material and posted prior to the call. During the call, we 
>>>>>>>> discussed all MAC-related aspects relevant for the join 
>>>>>>>> protocol and did not discuss higher-layer aspects I prepared 
>>>>>>>> material for yet. I suggest we continue the systematic 
>>>>>>>> discussion of last week and take that topic on now.
>>>>>>>>
>>>>>>>> This leads to the following suggested agenda for this week 
>>>>>>>> (essentially a continuation of last week's one):
>>>>>>>>
>>>>>>>> Same as last week's, except with
>>>>>>>> #1a-b) focus on routing/communication flow related aspects join 
>>>>>>>> protocol;
>>>>>>>> #2a): confirm concensus on MAC (as discussed last week) and 
>>>>>>>> routing/communication flow aspects
>>>>>>>> #2c) {as consequence of two items above} what to squeeze into 
>>>>>>>> architecture draft
>>>>>>>>
>>>>>>>> The detailed agenda and dial-in info is below (#A, resp. #B).
>>>>>>>>
>>>>>>>> Best regards, Rene
>>>>>>>>
>>>>>>>> _A) Suggested agenda Tue Dec 9, 2014, 9am EST call_
>>>>>>>>
>>>>>>>> Proposed agenda:
>>>>>>>>
>>>>>>>> 0) Agenda bashing
>>>>>>>>
>>>>>>>> 1) Join protocol details
>>>>>>>>
>>>>>>>>     a) desired properties
>>>>>>>>     b) realizable properties
>>>>>>>>
>>>>>>>>     #1a-b) focus on routing/communication flow related aspects
>>>>>>>>     join protocol (we discussed MAC-related join-relevant
>>>>>>>>     aspects during the conf call of Tue Dec 2, 2014, 9am EST).
>>>>>>>>     For slides, see
>>>>>>>>     https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing
>>>>>>>>     (same slides as sent out prior to Dec 2, 2014, 9am EST call)
>>>>>>>>     Relevant slides: Slides 23-25 (contained in entire slide
>>>>>>>>     deck (ppt), but also in excerpt (pdf))
>>>>>>>>
>>>>>>>> 2) Next steps:
>>>>>>>>         a) consensus on 1#a and 1#b
>>>>>>>>
>>>>>>>>     #2a): confirm consensus on MAC (as discussed last week) and
>>>>>>>>     routing/communication flow aspects
>>>>>>>>     #2c) {as consequence of two items above} what to squeeze
>>>>>>>>     into architecture draft
>>>>>>>>
>>>>>>>>         b) form tiger team to work out details
>>>>>>>>             - project phases
>>>>>>>>             - communication of sub-results
>>>>>>>>         c) what to squeeze into architecture draft, etc.
>>>>>>>>
>>>>>>>> I will prepare material to facilitate discussion on 1) and 2), 
>>>>>>>> to be discussed during the call.
>>>>>>>>
>>>>>>>> _B) Dial-in information:_
>>>>>>>> English : New York Time 6tisch security
>>>>>>>> Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
>>>>>>>> Meeting number:   641 709 118
>>>>>>>> Meeting password: joinjoin
>>>>>>>> Audio connection:
>>>>>>>>        1-877-668-4493 Call-in toll free number (US/Canada)
>>>>>>>>        1-650-479-3208 Call-in toll number (US/Canada)
>>>>>>>>
>>>>>>>> Access code: 641 709 118
>>>>>>>> Meeting link:
>>>>>>>>          https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6
>>>>>>>>
>>>>>>>> The etherpad we have used is at:
>>>>>>>>         http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> email:[email-masked]  | Skype: rstruik
>>>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> email:[email-masked]  | Skype: rstruik
>>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> email:[email-masked]  | Skype: rstruik
>>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>>>>
>>>>>
>>>>> -- 
>>>>> email:[email-masked]  | Skype: rstruik
>>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>>>
>>>>
>>>> -- 
>>>> email:[email-masked]  | Skype: rstruik
>>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>>
>>>
>>> -- 
>>> email:[email-masked]  | Skype: rstruik
>>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>
>>
>> -- 
>> email:[email-masked]  | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>
> -- 
> email:[email-masked]  | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Malisa Vucinic <[email-masked]>
Date: Mon, 16 Feb 2015 17:14:11 -0800

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 <[email-masked]> 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:

---

From: Rene Struik <[email-masked]>
Date: Tue, 17 Feb 2015 08:25:34 -0500

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call *today*, 
Tue February 17, 2015, 9am EST.

As you may recall, I put as tentative item on the agenda of last week's 
call "time latency aspects" of the join protocol . Thomas Watteyne 
volunteered to take on this topic for this week's call.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects (Thomas Watteyne)
3) AOB

==
The schedule for the next few 6tisch security conference calls is as 
follows:
Tue Jan 20th: 4.30pm EST
Tue Jan 27th: 9am EST
Tue Feb 3rd: 4.30pm EST
Tue Feb 10th: 4.30pm EST
Tue Feb 17th: 9am EST
Tue Feb 24th: 9am EST
Tue Mar 3rd: 4.30pm EST

On 2/9/2015 11:50 PM, Rene Struik wrote:
> tomorrow, Tue February 10, 2015, 4.30pm EST.
>
> 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:
>> {recording: not available (Michael Richardson had control, but was 
>> not on the call}
>> suggested that there would be 1-2 more letter ballots, followed by 
>> the start of sponsor ballot around end of March 2015, with 
>> anticipated conclusion of the work around July-August this year. RS 
>> commented that this schedule seemed quite aggressive, considering 
>> historical timelines of IEEE 802.15 efforts. TK mentioned that 
>> according to Bob Heile (Chair IEEE 802.15) the 802.15rev draft would 
>> only be available in the 802.15 private member area or to those 
>> people participating in person in an actual IEEE 802 meeting. 
>> Therefore, it does not seem possible to make a draft available to 
>> interested parties in the 6tisch community who did not meet those 
>> criteria (as previously suggested).
>>
>> 5. AOB
>>>>> The rescheduled 6tisch security call will take place this 
>>>>> Thursday, January 22, 2015, 1-2pm EST.
>>>>>>> We can discuss this in more detail during that call (I won't 
>>>>>>> have much time beforehand).
>>>>>>>
>>>>>>> Best regards, Rene
>>>>>>>
>>>>>>>>> I propose we continue the discussion where we left off prior 
>>>>>>>>> to Christmas (essentially, item 3c below), except that we may 
>>>>>>>>> have a short presentation first (item #2).
>>>>>>>>>
>>>>>>>>> Agenda:
>>>>>>>>> Subject: 	Suggested agenda for 6tisch security call of 
>>>>>>>>> *today*, Tue December 16, 2014, 5pm EST (dial-in info at bottom)
>>>>>>>>> some material and posted prior to the call. During the call, 
>>>>>>>>> we discussed all MAC-related aspects relevant for the join 
>>>>>>>>> join protocol;
>>>>>>>>>     #2a): confirm consensus on MAC (as discussed last week)
>>>>>>>>>     and routing/communication flow aspects

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 17 Feb 2015 14:48:36 +0100

Rene,

Thanks for the reminder.

*Agenda*

Today's discussion about latency will be illustrated by the excellent
slides Malisa Vucinic put together (thanks!!), and which were sent to the
mailing in:
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00427.html

As such, the agenda should be updated to:

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) time latency aspects (Malisa Vucinic, Thomas Watteyne)
3) AOB

*Etherpad*

During the meeting, I propose we use the following Etherpad:
http://etherpad.tools.ietf.org:9000/p/6tisch-security?useMonospaceFont=true

*Connection details*

They remain unchanged:

See you in 15min,

Thomas

---

From: Rene Struik <[email-masked]>
Date: Tue, 17 Feb 2015 12:39:33 -0500

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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Dear colleagues:
>>
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

---

From: Malisa Vucinic <[email-masked]>
Date: Tue, 17 Feb 2015 12:17:13 -0800

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 <[email-masked]> 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". 
> 
> -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).
> 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 09 Feb 2015, at 20:50, Rene Struik <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Dear colleagues:
>>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/6tisch-security <https://www.ietf.org/mailman/listinfo/6tisch-security>
> 
> 
> -- 
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Tue, 17 Feb 2015 15:30:10 -0500

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:
> 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 <[email-masked] 
>> 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".
>>
>> 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).

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 17 Feb 2015 13:23:10 -0800

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 <[email-masked]> 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
> 
> http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3vah6

---

From: Rene Struik <[email-masked]>
Date: Tue, 17 Feb 2015 16:43:32 -0500

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:
> * 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 <[email-masked] 
>> 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:
>> 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
>>
>>>> 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 
>>>> -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).
>>>>
>>>> (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).
>>>> 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.(
>>>>
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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:

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 17 Feb 2015 14:04:13 -0800

Rene - Thanks. 

I agree that RSA is absurd in this context, but as I mentioned in one of the calls, some of the base standards use RSA signatures, e.g. RFC6550 (RPL) calls out RSA with SHA-256, so 
a) I’m not sure what people are thinking in terms of shared key establishment (hopefully not RSA), and
b) we will need at some point to explicitly call out where we are using other crytpo suites.  

Jonathan

On Feb 17, 2015, at 1:43 PM, Rene Struik <[email-masked]> wrote:

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

---

From: Giuseppe Piro <[email-masked]>
Date: Wed, 18 Feb 2015 21:03:48 +0100

Hi Malisa,

I've three little comments about the 5-th slide of your presentation
http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfWPK_6ZrxPI.pdf

   1. note that a timeslot of 10ms may not be enough for addressing all the
   L2 security procedures. Well, it depends from the selected security level..
   but in general they always require more computational capabilities
   2. in a multi hop scenario, your estimation (i.e., 40 ms) should be
   valid if slots are properly allocated in the slotframe (maybe consecutively
   each other). Hence the assumption of "random scheduling" should not be more
   valid
   3. probably we need more than 3-4 frames for transmitting a certificate

​Basing from these comments, please, let me know if my understanding was
wrong or not.

Then, w.r.t certificates, could you please provide more details in order to
justify the size fitting in 3-4 frames ?

Best Regards and thanks a lot for your attention
Giuseppe

On Tue, Feb 17, 2015 at 11:04 PM, Jonathan Simon <[email-masked]> wrote:

> Rene - Thanks.
>
> I agree that RSA is absurd in this context, but as I mentioned in one of
> the calls, some of the base standards use RSA signatures, e.g. RFC6550
> (RPL) calls out RSA with SHA-256, so
> 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://cp.mcafee.com/d/FZsS820A721J5xdxeVEVop76XCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVKObx1DS7-LOpEVuv79ZuVtddcQsY-eov79YJteOaqJQnel3PWApmU6CQjr9K_9TLuZXTLsTsS02BYTu00U9BZzoD8P-02NOsGm9BWvpKcFBIIT6fMDyJ2dXELIY3zsqjyT8HTxYMkh4-ndIL8CzBwS2_id41FrsDaBypuDSrzapoQKCy0QkkAGIv9SnE6y3MZo_orelo6y2HFEwtH5lI_vd59Ew1vF6y0aXfUmb6y07_qt3h1lQQg0Ao4wKrusdC6lo>
>
> * 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
>
> 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).
>  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
>
> 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".
>
> 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.(
>
>
> hopefully be useful for evaluating different proposals for the join process
> once there are more details on message sizes involved.
>
>  Regards,
> Malisa
>
>
>
>
> 6tisch-security mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch-security <http://cp.mcafee.com/d/FZsS73hJ5xdxeXZSbCXCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVJTSdpZx_HYCed7bVEV7cZuVtd4sZP2apEVv76zDBHEShjlKehVkffGhBrwqrhdECXYyUqekSrzD3hOCrKr9PCJhbcatbVKY01MjlS67OFek7qUVelb4OZfIT6kONJOsGm9BWvpKcFByV2Hsbvg5i-rL00jrdT3hPsS2_id41FrsDaBypuDSrzapoQKCy0QkkAGIv9SnE6y3MZo_orelo6y2HFEwtH5lI_vd59Ew1vF6y0aXfUmb6y07_qt3h1lQQg0Ao4wKrusdJB_Z>
>
>
>
> --

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: g <http://telematics.poliba.it/piro>iuseppepiro.com

---

From: Malisa Vucinic <[email-masked]>
Date: Wed, 18 Feb 2015 16:08:58 -0800

Hi Giuseppe,

Thanks for your comments. See my answers inline.

Best,
Mališa

> On 18 Feb 2015, at 12:03, Giuseppe Piro <[email-masked]> wrote:
> 
> Hi Malisa,
> 
> http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfWPK_6ZrxPI.pdf <http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfWPK_6ZrxPI.pdf>
> 
> note that a timeslot of 10ms may not be enough for addressing all the L2 security procedures. Well, it depends from the selected security level.. but in general they always require more computational capabilities
I agree that the lower end devices with a pure software implementation of AES and CCM* could have difficulties fitting everything in 10ms timeslot but since we have hardware acceleration available on a wide range of platforms this should not be a problem. 

> in a multi hop scenario, your estimation (i.e., 40 ms) should be valid if slots are properly allocated in the slotframe (maybe consecutively each other). Hence the assumption of "random scheduling" should not be more valid
This is 40 seconds over 5 hops, not milliseconds, however strange that may sound. Consider two radio neighbors A and B performing the handshake: A’s MAC layer receives the first DTLS packet to transmit (Client Hello) at a random instant in the schedule. With the random schedule and no queuing delay, it will take the infamous 1 + L/(C+1) timeslots before this is received at B. It will be the same in the other direction since B’s TX cell is also randomly scheduled (we are effectively making the second assumption from Jonathan’s email here). For 15 L2 frames carrying different DTLS datagrams in both directions (C dedicated cells for each TX, both ends), this will be 15 times the delay of a single frame. For multihop, since the randomly generated schedule is common for all nodes in the mesh, the average delay until a frame received at an intermediate hop will be forwarded to the following one is the same. So effectively, we just need to add them up and assuming the same number of dedicated cells between all pairs on the path we get the multiplication by H. Does that make sense?  

> probably we need more than 3-4 frames for transmitting a certificate 
> ​Basing from these comments, please, let me know if my understanding was wrong or not. 
> 
> Then, w.r.t certificates, could you please provide more details in order to justify the size fitting in 3-4 frames ? 

So 3-4 frames relates to an optimistic estimate of compressed ECC certificates (see discussion  http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00222.html <http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00222.html>). We may need more but, to me, transmitting 1.5K certificates in both directions over multiple hops smells like a disaster which we ought to avoid. Î

> On Tue, Feb 17, 2015 at 11:04 PM, Jonathan Simon <[email-masked] <mailto:[email-masked]>> wrote:
> Rene - Thanks. 
> 
> On Feb 17, 2015, at 1:43 PM, Rene Struik <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 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 <http://cp.mcafee.com/d/FZsS820A721J5xdxeVEVop76XCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVKObx1DS7-LOpEVuv79ZuVtddcQsY-eov79YJteOaqJQnel3PWApmU6CQjr9K_9TLuZXTLsTsS02BYTu00U9BZzoD8P-02NOsGm9BWvpKcFBIIT6fMDyJ2dXELIY3zsqjyT8HTxYMkh4-ndIL8CzBwS2_id41FrsDaBypuDSrzapoQKCy0QkkAGIv9SnE6y3MZo_orelo6y2HFEwtH5lI_vd59Ew1vF6y0aXfUmb6y07_qt3h1lQQg0Ao4wKrusdC6lo>
>> 
>>> On Feb 17, 2015, at 12:30 PM, Rene Struik <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>> Hi Malisa:
>>>> 
>>>>>> On 17 Feb 2015, at 09:39, Rene Struik <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>> 
>>>>>> Hi Malisa:
>>>>>> 
>>>>>>> https://www.ietf.org/mailman/listinfo/6tisch-security <http://cp.mcafee.com/d/FZsS73hJ5xdxeXZSbCXCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVJTSdpZx_HYCed7bVEV7cZuVtd4sZP2apEVv76zDBHEShjlKehVkffGhBrwqrhdECXYyUqekSrzD3hOCrKr9PCJhbcatbVKY01MjlS67OFek7qUVelb4OZfIT6kONJOsGm9BWvpKcFByV2Hsbvg5i-rL00jrdT3hPsS2_id41FrsDaBypuDSrzapoQKCy0QkkAGIv9SnE6y3MZo_orelo6y2HFEwtH5lI_vd59Ew1vF6y0aXfUmb6y07_qt3h1lQQg0Ao4wKrusdJB_Z>
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> cell: +1 (647) 867-5658 <tel:%2B1%20%28647%29%20867-5658> | US: +1 (415) 690-7363 <tel:%2B1%20%28415%29%20690-7363>
>>>> 
>>>> 
>>>> -- 
>>>> cell: +1 (647) 867-5658 <tel:%2B1%20%28647%29%20867-5658> | US: +1 (415) 690-7363 <tel:%2B1%20%28415%29%20690-7363>_______________________________________________
>>>> http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3vah6 <http://cp.mcafee.com/d/avndygQ73gOrhojojK_tyVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrtZzmvovW_9zzhO-qehPfnKnjh7fsMyCqenNNEVVqWdAkRrzAul3PWApmU6CQjq9K_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SPtMQsTdwLQzh0qmT9OFoCnFZCUOCmdbFEwd559aH7OtBW1EwYfmfS6PBm1EwGWq87qNlrfTPhiq80nWhEw2KP-5yNEw1_SDgQgltd409618bCTD3vah6>
>>> 
>> 
>> 
>> -- 
>> cell: +1 (647) 867-5658 <tel:%2B1%20%28647%29%20867-5658> | US: +1 (415) 690-7363 <tel:%2B1%20%28415%29%20690-7363>
> 
> Giuseppe Piro, PhD
> email: [email-masked] <mailto:[email-masked]>
> phone: +39 080 5963301
> web: g <http://telematics.poliba.it/piro>iuseppepiro.com <http://iuseppepiro.com/>

---

From: Giuseppe Piro <[email-masked]>
Date: Thu, 19 Feb 2015 10:09:55 +0100

Malisa, thanks for the clarifications.

On Thu, Feb 19, 2015 at 1:08 AM, Malisa Vucinic <[email-masked]>
wrote:

>    1. note that a timeslot of 10ms may not be enough for addressing all
>    the L2 security procedures. Well, it depends from the selected security
>    level.. but in general they always require more computational capabilities
>
> I agree that the lower end devices with a pure software implementation of
> AES and CCM* could have difficulties fitting everything in 10ms timeslot
> but since we have hardware acceleration available on a wide range of
> platforms this should not be a problem.
>
>
Ok. I know that hardware-based solutions could reduce the amount of time
required complete l2 security tasks. We have to verify that "this should
not be a problem" :-) . Anyway, I'm in line with your idea.

>
>    1. in a multi hop scenario, your estimation (i.e., 40 ms) should be
> This is 40 seconds over 5 hops, not milliseconds, however strange that may
> sound. Consider two radio neighbors A and B performing the handshake: A’s
> MAC layer receives the first DTLS packet to transmit (Client Hello) at a
> random instant in the schedule. With the random schedule and no queuing
> delay, it will take the infamous 1 + L/(C+1) timeslots before this is
> received at B. It will be the same in the other direction since B’s TX cell
> is also randomly scheduled (we are effectively making the second assumption
> from Jonathan’s email here). For 15 L2 frames carrying different DTLS
> datagrams in both directions (C dedicated cells for each TX, both ends),
> this will be 15 times the delay of a single frame.
>
For multihop, since the randomly generated schedule is common for all nodes
> in the mesh, the average delay until a frame received at an intermediate
> hop will be forwarded to the following one is the same. So effectively, we
> just need to add them up and assuming the same number of dedicated cells
> between all pairs on the path we get the multiplication by H. Does that
> make sense?
>
>
​
Sure, it was been my misunderstanding, thanks.

>
>    1. probably we need more than 3-4 frames for transmitting a certificate
>
>
> Then, w.r.t certificates, could you please provide more details in order
> to justify the size fitting in 3-4 frames ?
>
>
> So 3-4 frames relates to an optimistic estimate of compressed ECC
> certificates (see discussion
> http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00222.html).
> We may need more but, to me, transmitting 1.5K certificates in both
> directions over multiple hops smells like a disaster which we ought to
> avoid. Î
>
> ​

Thanks for the pointer. I agree that compressed certs
​are more suitable in this context.

​

All the best,
Giuseppe

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: telematics.poliba.it/piro

---

From: Giuseppe Piro <[email-masked]>
Date: Thu, 19 Feb 2015 10:11:06 +0100

>> This is 40 seconds over 5 hops, not milliseconds, however strange that
>> may sound. Consider two radio neighbors A and B performing the handshake:
>> A’s MAC layer receives the first DTLS packet to transmit (Client Hello) at
>> a random instant in the schedule. With the random schedule and no queuing
> For multihop, since the randomly generated schedule is common for all
>> nodes in the mesh, the average delay until a frame received at an
>> intermediate hop will be forwarded to the following one is the same. So
>> effectively, we just need to add them up and assuming the same number of
>> dedicated cells between all pairs on the path we get the multiplication by
>> H. Does that make sense?
>>
>>
> ​
>

​

All the bes
​t

​
Giuseppe

---

From: Michael Richardson <[email-masked]>
Date: Sun, 22 Feb 2015 19:43:19 -0500

> process once there are more details on message sizes involved.

My understanding of your analysis is that it assumes a random schedule, and
that it assumes that there is no bandwidth allocated between the 6LBR and the
Join Assistant.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 22 Feb 2015 19:45:30 -0500

Jonathan Simon <[email-masked]> wrote:
    > 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.

The only time I know that we need to test for primes is when looking at g^x
values for a DH exchange that would be part of PFS.  Is there another time?

---

From: Malisa Vucinic <[email-masked]>
Date: Sun, 22 Feb 2015 21:18:15 -0800

> On 22 Feb 2015, at 16:43, Michael Richardson <[email-masked]> wrote:
> 
> 
> My understanding of your analysis is that it assumes a random schedule,

Yes, that is correct.

> and

Why would that be an assumption? It works for any pair of nodes in the mesh including the 6LBR and the JA. For instance, for a given bandwidth allocated between the 6LBR and the JA it estimates what can you expect in terms of latency on that path with a random schedule.

---

From: Rene Struik <[email-masked]>
Date: Mon, 23 Feb 2015 14:29:41 -0500

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call 
*tomorrow*, Tue February 24, 2015, 9am EST.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) implementation aspects (w/. HW considerations)
3) time latency aspects (continuation)
4) AOB

The dial-in information is the same as usual -- please scroll down.

Rene

==

-------- Forwarded Message --------
Subject: 	Re: Reminder -- 6tisch security call *today*, Tue Feb 17, 
2015, 9am EST (includes dial-in info)
Date: 	Tue, 17 Feb 2015 08:25:34 -0500
From: 	Rene Struik <[email-masked]>
To: 	tisch-security <[email-masked]>

Dear colleagues:

Suggested agenda:

==