Dear colleagues:

Any feedback, opinions on a) and b) appreciated.

Rene

On 6/10/2014 11:39 AM, Rene Struik wrote:
> Dear colleagues:
>
> Please find below some deliberations on outstanding item #c-3:
>
> With 802.15.4e-2012, the TSCH Synchronization IE (5.2.4.13) includes 
> the absolute slot number (ASN) and the Join Priority flag.
a)
> Since a newly joining device has no way to validate whether the ASN 
> entry advertised by the beaconing device corresponds to the one 
> maintained by the PAN coordinator and there is only one macASN entry, 
> joining nodes cannot rely on this ASN entry for frame security. As a 
> result, the first message from a newbee node to the neighbor device 
> should be unsecured. In particular, this should neither attempt to use 
> a "well-known key".
b)
> It is unclear how the join priority flag would help in facilitating 
> resource optimization when a newly joining device tries and join the 
> network. Perhaps, this flag was motivated by centralized solution 
> ideas, where every device joins via the PAN coordinator? Suggestion is 
> to completely ignore this joining priority flag.
>
> Best regards, Rene
>
> [excerpt of 802.15.4e-2012]
> The ASN field contains the 5-octet Absolute Slot Number corresponding 
> to the timeslot in which the
> enhanced beacon is sent. The ASN is used as the Frame Counter for 
> security operations if enabled. The 1-
> octet Join Priority field can be used by a joining device to select 
> among beaconing devices when multiple
> beacons are heard. The PAN coordinator's join priority is zero. A 
> lower value of join priority indicates that
> the device is the preferred one to connect to. The beaconing device's 
> join priority is the lowest join priority
> heard when it joined the network plus one.
> The TSCH Synchronization IE is used to construct enhanced beacons that 
> allow new devices to synchronize
> to a TSCH PAN.
>
>> ==
>> c) Join process impact on network:
>> Pascal Thubert asked "when network would explode with join". Note RS: 
>> the following questions come to mind:
>> c-1) how does joining  node find a time slot to send first join 
>> packet to neighbor node (presumably, this would require listening for 
>> Enhanced Beacon, but details on schedule in terms of time and 
>> channels seems incomplete [min-schedule suggests 101x15ms slotframe 
>> and "less than 10s repeat of EBs, but that leaves lots of dead time 
>> and does not suggest a schedule that would create a common time 
>> window where two devices would both be awake).
>> c-2)how does joining node negotiate a local schedule with neighbor 
>> node for execution of join protocol (draft-watteyne-6tisch-tisch-00 
>> refers to local schedule negotiation need, but unclear whether this 
>> has been looked into in detail).
>> c-3) for local traffic (joining node/neighbor), it seems Pascal 
>> Thubert's "exploding network" may not happen easily. Nevertheless, 
>> unclear what impact of "join priority flag TSCH 802.15.4e frames is 
>> [that seems to have been designed with legacy w/HART in mind 
>> (centralized solution). With centralized tree-like solution, lots of 
>> traffic happens close to the root, thus potentially amplifying 
>> congestion around root node (=network manager?).
>>
>> On 6/9/2014 11:51 AM, Rene Struik wrote:
>>> Dear colleagues:
>>>
>>> Please find below a reminder of the outstanding issues re the join 
>>> protocol, as I originally circulated three weeks ago, prior to our 
>>> call on Tue May 20, 2014. {As an aside, the week before that, on May 
>>> 12, 2014, we did discuss the w/HART join process protocol flows (at 
>>> the time, intention was to agree to align flows with that used 
>>> there, as motivated in the same email below).}
>>>
>>> While current discussions on w/HART protocol have been somewhat 
>>> interesting, I feel we should put urgent priority on tackling those 
>>> outstanding issues. So far, I have not seen any traffic on these 
>>> items from others, so please weigh-in (please include outstanding 
>>> item # in the subject line, e.g., "outstanding issue #c").
>>>
>>> Let us first tackle item #c) below on join process impact on the 
>>> network. I am particularly interested in detailed deliberations on 
>>> the three questions on this item that came to my mind here.
>>>
>>> When looking at this topic, I would like to encourage you to read 
>>> the email thread on the IETF DICE list re 
>>> draft-kumar-dice-dtls-relay-01, which is related to relaying  nodes 
>>> and potential DoS attacks. I initiated this discussion on May 27th, 
>>> with last posting on May 30th. See 
>>> http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00253.html.
>>>
>>> Best regards, Rene
>>>
>>> On 5/20/2014 9:45 AM, Rene Struik wrote:
>>>> Hi Michael:
>>>>
>>>> At the previous conf call of May 12, 2014, we discussed message 
>>>> flows of w/HART join process, as also alluded to in my email below 
>>>> (the specs could not be distributed due to copyright restrictions).
>>>>
>>>> In my mind, 6TiSCH protocol can use similar communication flows as 
>>>> w/HART where only non-local communication flows (between joining 
>>>> node and network manager) would be
>>>> i) passing join/authentication information from joining node to 
>>>> network manager (and back);
>>>> ii) passing configuration parms from network manager to joining 
>>>> node (keys, links, frame links) and neighbor report from joined 
>>>> node to network manager.
>>>>
>>>> MAIN OUTSTANDING ISSUES (in my mind):
>>>> a) Packet sizes:
>>>> get more info on packet sizes configuration parms, as w/HART uses. 
>>>> Note RS: during call, Tom Phinney suggested contacting Wally Bratt 
>>>> from HART Comm. Foundation for this).  Note RS: Shouldn't, e.g., 
>>>> Dust Networks have info on packet sizes/structure?; ISA SP100.11a 
>>>> metrics would also help, as would ZigBee 2.0 config parms. Does, 
>>>> e.g., Cisco have useful data points here?
>>>> b) Device Ids:
>>>> With industrial control, network manager would look up "tag name" 
>>>> device in pre-configured database. Details on tag name syntax, how 
>>>> assigned, and how bound to, e.g., EUI-64 are missing. Note RS: 
>>>> Perhaps, Tom Phinney could point at tag name syntax and lifecycle 
>>>> aspects here?
>>>> c) Join process impact on network:
>>>> Pascal Thubert asked "when network would explode with join". Note 
>>>> RS: the following questions come to mind:
>>>> - how does joining  node find a time slot to send first join packet 
>>>> to neighbor node (presumably, this would require listening for 
>>>> Enhanced Beacon, but details on schedule in terms of time and 
>>>> channels seems incomplete [min-schedule suggests 101x15ms slotframe 
>>>> and "less than 10s repeat of EBs, but that leaves lots of dead time 
>>>> and does not suggest a schedule that would create a common time 
>>>> window where two devices would both be awake).
>>>> - how does joining node negotiate a local schedule with neighbor 
>>>> node for execution of join protocol (draft-watteyne-6tisch-tisch-00 
>>>> refers to local schedule negotiation need, but unclear whether this 
>>>> has been looked into in detail).
>>>> - for local traffic (joining node/neighbor), it seems Pascal 
>>>> Thubert's "exploding network" may not happen easily. Nevertheless, 
>>>> unclear what impact of "join priority flag TSCH 802.15.4e frames is 
>>>> [that seems to have been designed with legacy w/HART in mind 
>>>> (centralized solution). With centralized tree-like solution, lots 
>>>> of traffic happens close to the root, thus potentially amplifying 
>>>> congestion around root node (=network manager?).
>>>> d) crypto protocol details of join protocol:
>>>> Note RS: I can solve this (close to optimal design already done 
>>>> [assuming I can do this "without hands tied behind the back"])
>>>> e) authorization/trust management:
>>>> it is here where binding of ids to public keys via certs and 
>>>> lifecycle aspects play a role, as well as syntax/semantics of 
>>>> authorization messages. Note RS: question is whether ACE could play 
>>>> a role here (current charter discussions seem to be endless, 
>>>> though). As has been brought up before, a potential instantiation 
>>>> of certs would be the use of 802.1ar certs, but this is certainly 
>>>> not the only way of doing things.
>>>>
>>>> There are lots of other things we should consider, outside the join 
>>>> protocol realm.
>>>>
>>>> ------- Original Message --------
>>>> Subject: 	Re: [6tisch-security] agenda(?) for call today
>>>> Date: 	Mon, 12 May 2014 09:53:37 -0400
>>>> From: 	Rene Struik <rstruik.ext@gmail.com>
>>>> To: 	Michael Richardson <mcr+ietf@sandelman.ca>, 
>>>> 6tisch-security@ietf.org
>>>>
>>>>
>>>>
>>>> Hi Michael et al:
>>>>
>>>> Another topic worth exploring more is the join protocol details.
>>>>
>>>> (There are many other aspects, including certs, as you mentioned, 
>>>> more general security architecture, provisioning, etc., but below 
>>>> only deals with join.)
>>>>
>>>> With w/HART, the join process only interacts with the network 
>>>> manager (62591, Annex A.3, Fig. A.1) for
>>>> -forwarded join from joining node to network manager;
>>>> -passing configuration parms from network manager to joining node 
>>>> (keys, links, frame links) and neighbor report from joined node to 
>>>> network manager.
>>>> All other communications are local, between joining device and 
>>>> neighbor (resp. with maintenance tool).
>>>>
>>>> It may have merit if we could use similar communication flows with 
>>>> 6tisch, i.e., keep most traffic local to the joining device, except 
>>>> for configuration parms exchange and authorization info passing.
>>>>
>>>> Most important consideration (from communication perspective) would 
>>>> be that non-local traffic would be minimized, as also w/HART does. 
>>>> From a marketing perspective, mimicking the communication flows 
>>>> w/HART already has would keep all time scheduling considerations 
>>>> for w/HART as currently there and 6TiSCH as to be detailed roughly 
>>>> the same. This would longer term help in pushing 6tisch-style 
>>>> security scheme to w/HART, since from a distance it looks the same 
>>>> (although trying to scrap the maintenance tool).
>>>>
>>>> Of course, this does not deal with the details of the joining 
>>>> protocol itself; only the flows.
>>>>
>>>> What about we look at some of the flows, and enumerate all issues 
>>>> that need to be addressed here, both from a security perspective 
>>>> and otherwise. We can then assign people to find missing 
>>>> information (I am esp. curious about how devices know when to 
>>>> send/receive and contributions of cycling efforts to total time 
>>>> latency).
>>>>
>>>> We could go over w/HART join flows during the call, to trigger 
>>>> these questions.
>>>>
>>>> Best regards, Rene
>>>>
>>>>
>>>> On 5/20/2014 8:26 AM, Michael Richardson wrote:
>>>>> To remind, we moved the call from the 19th to the 20th at 10am EDT.
>>>>> That's 90 minutes from this email.
>>>>>
>>>>> 1) notewell.
>>>>> 2) intros
>>>>> 3) Rene had some material to present?  Did it happen last week,
>>>>>     it seems not?
>>>>> 4) review of claim certificate process, vs EST with token.
>>>>>
>>>>> -- remember that the call is recorded, and the NoteWell applies.
>>>>>
>>>>> -- The URL to access the webex, which will we use for audio only:
>>>>>    https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908
>>>>>
>>>>> -- we will resume with the etherpad at:
>>>>>     http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security
>>>>>
>>>>> I'm at +1 613 276-6809, IM:mcr@xmpp.credil.org  ormcharlesr@gmail.com,
>>>>> if you need more than that to get in, or are having difficulties.
>>>>> Please make sure your audio works, and that you mute when not talking.
>>>>>
>>>>>
>>>>> --
>>>>> Michael Richardson<mcr+IETF@sandelman.ca>, Sandelman Software Works
>>>>>   -= IPv6 IoT consulting =-
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>> -- 
>> 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


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