Subject: [6tisch-security] REMINDER links for 2014-06-02 6tisch security call

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Jun 2014 09:40:09 -0400

Michael Richardson <[email-masked]> wrote:
    > To remind the calls will return to Monday mornings at:
    > 7am PDT, 10am EDT, 1400 UTC.

WEBEX:
  https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908

Etherpad (tools.ietf.org copy is broken):
  https://etherpad.mozilla.org/m05IQXtaBn

Jonathan's original email:
   https://mailarchive.ietf.org/arch/msg/6tisch-security/BsaHCRCgVXGZcUw2_1yj-6VSCqk

the slides: https://mailarchive.ietf.org/a/mailarch/data/archive/6tisch-security/_attachments/pdf49MINbpdf

    > The plan is to come up with a table of contents for two
    > documents on the details of the packet flow/sizes/etc. for
    > the two possible mechanisms.   That will be item #1.

THIS WILL OCCUR ON ETHERPAD.

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

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 2 Jun 2014 13:48:23 +0000

I apologize, I can't make today's meeting. 

Michael

> -----Original Message-----
> From: 6tisch-security [mailto:[email-masked]] On Behalf
> Of Michael Richardson
> Sent: 02 June 2014 15:40
> To: [email-masked]
> Subject: [6tisch-security] REMINDER links for 2014-06-02 6tisch security call
> 
>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 2 Jun 2014 14:15:52 +0000

Same for meŠ. Nancy

On 6/2/14 6:48 AM, "Michael Behringer (mbehring)" <[email-masked]>
wrote:

>_______________________________________________
>6tisch-security mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6tisch-security

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Jun 2014 20:55:19 -0400

To remind; we will continue with the slides that Jonathan Simon posted 10
days ago, which are also at:
  http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfiZJLN6CKg0.pdf

-- The URL to access the webex, which will we use for audio only:
  https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908

-- we will use with the etherpad at:
  https://etherpad.mozilla.org/ras5RGrQLA

---

From: Rene Struik <[email-masked]>
Date: Mon, 09 Jun 2014 11:51:00 -0400

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 <[email-masked]>
> To: 	Michael Richardson <[email-masked]>, [email-masked]
>
>
>
> 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.
>>
>> -- 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:[email-masked]  [email-masked],
>> 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<[email-masked]>, Sandelman Software Works
> 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: Rene Struik <[email-masked]>
Date: Tue, 10 Jun 2014 10:41:36 -0400

Dear colleagues:

Assumptions:
- Joining node has a minimum schedule (with 101x15ms slotframe) and 
somehow was able to find a time slot to send a first join packet to a 
neighbor node (c-1).
- Computational and communication time latency for response packet from 
neighbor node to joining node is 15ms, 150ms, 750ms, or 5s (depending on 
device capabilities, implementation detail)
- Computational time latency for joining node to compute shared key is 
15ms, 150ms, 750ms, or 5s (depending on device capabilities, 
implementation detail)

So, now for question c-2 below:
- How does joining node find out when to open its receiver again, so as 
to receive response packet from neighbor node
- How does neighbor node find out when to receive second packet flow 
from joining node (i.e., after joining node computed shared key)
In particular, should the local schedule allocate multiples of 15ms 
(i.e., each timeslot), 150ms, etc. Obviously, the denser the schedule 
the fewer capacity in terms of #joining nodes that can be served?

So, perhaps, the background of my question c-2 is  now unambiguously 
clear...

==
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:
> 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).}
>
>> - 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).
>> - 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?).
>> 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 many other aspects, including certs, as you mentioned, 
>> more general security architecture, provisioning, etc., but below 
>> only deals with join.)
>>
>> 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

---

From: Rene Struik <[email-masked]>
Date: Tue, 10 Jun 2014 11:39:26 -0400

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.

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

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.

> 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 
> 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).
>> 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").
>>
>> network. I am particularly interested in detailed deliberations on 
>> the three questions on this item that came to my mind here.
>>
>>> 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).
>>>
>>> w/HART where only non-local communication flows (between joining 
>>> node and network manager) would be
>>> 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:
>>> Pascal Thubert asked "when network would explode with join". Note 
>>> RS: the following questions come to mind:
>>> - 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).
>>> 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.
>>>
>>> With w/HART, the join process only interacts with the network 
>>> manager (62591, Annex A.3, Fig. A.1) for

---

From: Kris Pister <[email-masked]>
Date: Tue, 10 Jun 2014 11:23:34 -0700

At some level, the answer is that the security should not care how the 
MAC layer is doing its job,
as long as the packets get through.  But I agree that it is useful to 
see how all of this is going to
work together.
In the case of minimal, the MAC layer doesn't need to "find" anything.  
Once it has heard an EB,
it knows that every N slots there will be a TX/RX cell that it can use.  
If it has nothing to send, it
MUST listen.  If it sends and collides, there is a backoff strategy and 
it tries again.  Again, this
is all transparent to the security processing.
The choice of N determines latency, power, available BW, etc.  Best 
case, motes in the same
RF space can send one packet every N*T_slot seconds.  Lots of papers 
have been
written about the bad things that happen if you try to shove too much 
traffic through a
network with limited resources.  Minimal will look like slotted aloha, 
(possibly with some
slightly better performance from preamble capture, maybe CCA, ...), 
namely a normalized
maximum goodput of GP=1/e with an offered load of G=1.  Running any 
aloha-like network
near that maximum is very dangerous (chaotic collapse ensues unless 
higher layers are smart),
so a practical useful normalized goodput of 0.2 is more realistic and 
more energy efficient.

If N=20, and T_slot=10ms, the network will happily support 
0.2/(N*T_slot) = 1 packet per second
among all motes in the same RF space.  If N=101 and T_slot=15ms, then 
it's closer to 1 packet
every 8 seconds.  That means that it will take a *long* time for a large 
dense network to form, which
is why we call it "minimal" instead of "optimal" :)
Something in the N=10...100 slots is still probably fine for, e.g., a 
simple static home network.

ksjp

On 6/10/2014 7:41 AM, Rene Struik wrote:
> - Computational and communication time latency for response packet 
> from neighbor node to joining node is 15ms, 150ms, 750ms, or 5s 
> (depending on device capabilities, implementation detail)
> - How does joining node find out when to open its receiver again, so 
> as to receive response packet from neighbor node

---

From: Rene Struik <[email-masked]>
Date: Tue, 10 Jun 2014 16:50:03 -0400

Hi Kris:

Thanks for the quick feedback.

When designing a security protocol, one has to consider not just 
cryptographic properties, but also implementation cost, such as energy 
cost, RAM/ROM usage, and computational and communication time latency. 
Thus, while one might argue that "security should not care how the MAC 
layer is doing its job", this only seems to hold true if one is not 
interested in non-crypto performance metrics. To implementation-specific 
metrics mentioned above, one should add potential impact of traffic that 
seems to be legitimate, but in hindsight does not turn out to be that 
way (both in terms of denial-of-service attacks, keeping state, etc.). 
Hence, my question.

So, communication aspects may be quite interesting to consider in 
detail, e.g., in the context of message relay (see, e.g., DICE WG 
mailing list, May 30, 2014, 10:29am EDT ---
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00252.html):
>> So, I am still interested in getting more insight as to how the relay 
>> on/off switch would work in practice (which was the question in my 
>> original email of Tue [snippet copied below]). A description of 
>> device join operations would help (say, with operational network of 
>> 1000 nodes with diameter 20 hops, where one wishes to add a newbee 
>> node A at neighbor B, where B is 10 hops away from network manager T).
 From what you suggested below, if one takes slotframe of N=101 
timeslots of T_slot=15ms, then "goodput" of 1 packet per 8 seconds seems 
feasible. Does this mean that if one has a network manager 10 hops away 
(my DICE example above), that the communication latency from joining 
node to and from the network manager is 2*10*8 seconds =160 seconds or 
roughly 2 1/2 minutes and with that between neighbors this is 2*1*8 = 16 
seconds? If so, the communication cost seem to far outstrip any other 
time latency cost (including that due to computational overhead). Please 
correct me if I am wrong here.

If this is so, this begs the question as to coming up with tricks to 
squeeze more "bang for the buck" out of TSCH schedules, in case one 
executes a join protocol. As an example, if one does not use ACK'ed 
messages (which seems possible with interactive protocols) but - instead 
- squeezes an extra frame into that particular time/channel slot in the 
TSCH matrix, one seems to be able to potentially improve time latency by 
a factor 2x and get enormous time latencies of 2 1/2 minutes, resp. 16 
seconds, down to 80, resp. 8 seconds.

This is just to illustrate that there is more to security design than 
meets the eye at first.

Any thoughts?

Rene

On 6/10/2014 2:23 PM, Kris Pister wrote:
> In the case of minimal, the MAC layer doesn't need to "find" 
> anything.  Once it has heard an EB,
> it knows that every N slots there will be a TX/RX cell that it can 
> use.  If it has nothing to send, it
> MUST listen.  If it sends and collides, there is a backoff strategy 
> and it tries again.  Again, this
> every 8 seconds.  That means that it will take a *long* time for a 
> large dense network to form, which
>> - Computational time latency for joining node to compute shared key 
>> is 15ms, 150ms, 750ms, or 5s (depending on device capabilities, 
>> implementation detail)
>>
>> c-1) how does joining  node find a time slot to send first join 
>> packet to neighbor node (presumably, this would require listening for 
>>> the time, intention was to agree to align flows with that used 
>>> there, as motivated in the same email below).}
>>>
>>> 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
>>>
>>>> ii) passing configuration parms from network manager to joining 
>>>> node (keys, links, frame links) and neighbor report from joined 
>>>> node to network manager.
>>>>
>>>> (centralized solution). With centralized tree-like solution, lots 
>>>> of traffic happens close to the root, thus potentially amplifying 
>>>> 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.
>>>>
>>>> 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).
>>>>
>>>> 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
>>>>
>>>>

---

From: Kris Pister <[email-masked]>
Date: Tue, 10 Jun 2014 17:39:09 -0700

Rene - I completely agree with the systems approach to designing the 
security
protocol, but I'm not sure that there is anything in your email that is 
security-specific.
You have pointed out that N=101, Tslot=15ms is not going to work well 
for big
networks, for reasons of security flows as well as any other 
communication flow.
I agree with your conclusion that we need more bandwidth in an 8 hop network
than is provided by 101*15ms.  Some improvement can be had with smaller N,
but a much better approach is to assign dedicated bandwidth using 6top+...

The calculation on 8 hop latency is more subtle than just 8x the one-hop 
packet
interval, but no version of the calculation is going to look good with 
minimal and
101*15ms, so you're right on that one.

Eschewing link-layer ACKs and squeezing in an extra frame into the slot 
is the
first step down a path that leads to insanity and despair.  My vote 
would be to
stick with what the 15.4e standard says that we can do.

ksjp

On 6/10/2014 1:50 PM, Rene Struik wrote:
> interested in non-crypto performance metrics. To 
> implementation-specific metrics mentioned above, one should add 
> potential impact of traffic that seems to be legitimate, but in 
> hindsight does not turn out to be that way (both in terms of 
> denial-of-service attacks, keeping state, etc.). Hence, my question.
>
>>> So, I am still interested in getting more insight as to how the 
>>> relay on/off switch would work in practice (which was the question 
>>> in my original email of Tue [snippet copied below]). A description 
>>> of device join operations would help (say, with operational network 
>>> of 1000 nodes with diameter 20 hops, where one wishes to add a 
>>> newbee node A at neighbor B, where B is 10 hops away from network 
>>> manager T).
> timeslots of T_slot=15ms, then "goodput" of 1 packet per 8 seconds 
> seems feasible. Does this mean that if one has a network manager 10 
> hops away (my DICE example above), that the communication latency from 
> joining node to and from the network manager is 2*10*8 seconds =160 
> seconds or roughly 2 1/2 minutes and with that between neighbors this 
> is 2*1*8 = 16 seconds? If so, the communication cost seem to far 
> outstrip any other time latency cost (including that due to 
> computational overhead). Please correct me if I am wrong here.
>
> messages (which seems possible with interactive protocols) but - 
> instead - squeezes an extra frame into that particular time/channel 
> slot in the TSCH matrix, one seems to be able to potentially improve 
> time latency by a factor 2x and get enormous time latencies of 2 1/2 
> minutes, resp. 16 seconds, down to 80, resp. 8 seconds.
>
>> At some level, the answer is that the security should not care how 
>> the MAC layer is doing its job,
>> network with limited resources.  Minimal will look like slotted 
>> aloha, (possibly with some
>>> somehow was able to find a time slot to send a first join packet to 
>>> a neighbor node (c-1).
>>> (i.e., each timeslot), 150ms, etc. Obviously, the denser the 
>>> schedule the fewer capacity in terms of #joining nodes that can be 
>>> served?
>>>
>>> packet to neighbor node (presumably, this would require listening 
>>> for Enhanced Beacon, but details on schedule in terms of time and 
>>>> 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 
>>>>> - 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).
>>>>> 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).
>>>>> 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 
>>>>> authorization messages. Note RS: question is whether ACE could 
>>>>> play a role here (current charter discussions seem to be endless, 
>>>>> There are lots of other things we should consider, outside the 
>>>>> join protocol realm.
>>>>>
>>>>> 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).
>>>>>

---

From: Rene Struik <[email-masked]>
Date: Wed, 11 Jun 2014 10:23:01 -0400

So, perhaps, this leads us back to the original #c-2 question: how to 
get this dedicated bandwidth on the local joining node - neighbor level 
(how to determine suitable capacity, how to assign) and, perhaps, 
consider non-local capacity assignment aspects as well. More detailed 
question would be whether this dedicated bandwidth would be 
on-the-fly/on-demand or static.

 From the example metrics (N=101, Tslot=15ms) below, it seems that we 
can already conclude that communication latency considerations should 
heavily influence security protocol design, in the sense that non-local 
communications should be minimized (my item #c and preamble to my 
outstanding issue list).

==
Some improvement can be had with smaller N, but a much better approach 
is to assign dedicated bandwidth using 6top+..

Best regards, Rene

On 6/10/2014 8:39 PM, Kris Pister wrote:
> protocol, but I'm not sure that there is anything in your email that 
> is security-specific.
> The calculation on 8 hop latency is more subtle than just 8x the 
> one-hop packet
> Eschewing link-layer ACKs and squeezing in an extra frame into the 
> slot is the
>> cryptographic properties, but also implementation cost, such as 
>> energy cost, RAM/ROM usage, and computational and communication time 
>> latency. Thus, while one might argue that "security should not care 
>> how the MAC layer is doing its job", this only seems to hold true if 
>> one is not interested in non-crypto performance metrics. To 
>> hops away (my DICE example above), that the communication latency 
>> from joining node to and from the network manager is 2*10*8 seconds 
>> =160 seconds or roughly 2 1/2 minutes and with that between neighbors 
>> this is 2*1*8 = 16 seconds? If so, the communication cost seem to far 
>>> as long as the packets get through.  But I agree that it is useful 
>>> to see how all of this is going to
>>> work together.
>>> written about the bad things that happen if you try to shove too 
>>> much traffic through a
>>> so a practical useful normalized goodput of 0.2 is more realistic 
>>> and more energy efficient.
>>>
>>> among all motes in the same RF space.  If N=101 and T_slot=15ms, 
>>> then it's closer to 1 packet
>>> Something in the N=10...100 slots is still probably fine for, e.g., 
>>> a simple static home network.
>>>
>>> ksjp
>>>
>>>> - How does joining node find out when to open its receiver again, 
>>>> so as to receive response packet from neighbor node
>>>> - How does neighbor node find out when to receive second packet 
>>>> flow from joining node (i.e., after joining node computed shared key)
>>>> So, perhaps, the background of my question c-2 is  now 
>>>> unambiguously clear...
>>>>
>>>> ==
>>>>> 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).}
>>>>>
>>>>> 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").
>>>>>
>>>>> 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 
>>>>>> 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
>>>>>> 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:
>>>>>> 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?
>>>>>> negotiation need, but unclear whether this has been looked into 
>>>>>> in detail).
>>>>>> 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?).
>>>>>> (keys, links, frame links) and neighbor report from joined node 
>>>>>> to network manager.
>>>>>> It may have merit if we could use similar communication flows 
>>>>>> with 6tisch, i.e., keep most traffic local to the joining device, 
>>>>>> 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).
>>>>>>

---

From: Rene Struik <[email-masked]>
Date: Thu, 12 Jun 2014 11:00:23 -0400

Dear colleagues:

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

Rene

On 6/10/2014 11:39 AM, Rene Struik wrote:
> 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)
> should be unsecured. In particular, this should neither attempt to use 
> a "well-known key".
b)
> 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
>
> The ASN field contains the 5-octet Absolute Slot Number corresponding 
> to the timeslot in which the
> beacons are heard. The PAN coordinator's join priority is zero. A 
> lower value of join priority indicates that

---

From: Michael Richardson <[email-masked]>
Date: Sat, 14 Jun 2014 15:26:56 -0400

Rene Struik <[email-masked]> wrote:
    > 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.

    > Pascal Thubert asked "when network would explode with join". Note RS: the
    > following questions come to mind:

    > schedule that would create a common time window where two devices would

The joining node listens for an Enhanced Beacon (which arrives on all
frequencies I've just read).

The EB are sent by neighbours at times when they are set to be Tx.
The EB are not at the beginning of the slotframe, which I had previously
assumed.  The EB contains a relative timestamp telling the node when the
slotframe was to have started.

http://tools.ietf.org/html/draft-watteyne-6tisch-tsch-00, section A.11.

Does this resolve this issue?

http://tools.ietf.org/wg/6tisch/trac/ticket/13

http://tools.ietf.org/wg/6tisch/trac/ticket/14

---

From: Rene Struik <[email-masked]>
Date: Sat, 14 Jun 2014 18:12:35 -0400

Hi Michael:

 From the minimal draft, it seems that enhanced beacons SHOULD be sent 
every 10 seconds. Since in that draft, each slotframe is 101 x 15ms = 
1.515s, this seems to suggest there are huge "holes" in sending of EBs. 
Moreover, it is not clear whether the "should" language refers to a 
maximum time window or an interval length.

Even if an enhanced beacon is sent every slotframe at the first timeslot 
(i.e., in a scenario without "holes"), this means that the EB cycles 
through all frequencies in 16 slotframe lengths, or 16 x 1.515 = 24.24 s 
(assuming all frequencies are indeed active). Now, how does one 
guarantee that the joining device actually "hits" such an enhanced 
beacon? If the joining node listens on different channels itself, it may 
never see an enhanced beacon of another device (e.g., if they are just 
"following each other" in lockstep, which is very well possible). The 
only way a joining node may "get lucky" seems to be when listening on a 
fixed channel for a long time and hoping it would hear something. If the 
neighbor is sending stuff on all frequencies and the function "F" 
(channel frequency mapping of draft-watteyne-6tisch-tsch-00, Section 
A.7) is the identity function, then if it would listen long enough (the 
24.24s or roughly half a minute above), then it would encounter an EB. 
If the "hole" scenario of the minimal draft plays out, it may have to 
listen much longer (moreover, the formula for the channel frequency 
mapping may not result in any guarantees that each channel frequency 
will indeed occur then). If the neighbor does have some channel 
frequencies blocked or different devices have different "F" functions, 
the situation seems to be very unclear.

I hope this provides some evidence that it is unclear how one could 
"hit" an enhanced beacon of a neighboring node. What I described above 
does not deal with "negotiating"/"finding" a time slot/channel combo 
where the joining device would actually send its first message (and at 
the same time have some assurances that the EB-originator is still 
listening to it).

Best regards, Rene

[excerpt of draft-ietf-6tisch-minimal-00, Section 3]
Enhanced Beacons Configuration and Content [IEEE802154e] does not define 
how often or which EBs are sent. The choice of the duration between two 
EBs needs to take into account whether EBs are used as the only 
mechanism to synchronize devices, or whether a Keep-Alive (KA) mechanism 
is used in parallel. For a simplest TSCH configuration, a mote SHOULD 
send an EB every 10s. For additional reference see 
[I-D.watteyne-6tisch-tsch] where different synchronization approaches 
are summarized.

---

From: Rene Struik <[email-masked]>
Date: Sat, 14 Jun 2014 18:18:03 -0400

On 6/14/2014 6:12 PM, Rene Struik wrote:
> 1.515s, this seems to suggest there are huge "holes" in sending of 
> EBs. Moreover, it is not clear whether the "should" language refers to 
> a maximum time window or an interval length.
>
> Even if an enhanced beacon is sent every slotframe at the first 
> timeslot (i.e., in a scenario without "holes"), this means that the EB 
> cycles through all frequencies in 16 slotframe lengths, or 16 x 1.515 
> = 24.24 s (assuming all frequencies are indeed active). Now, how does 
> one guarantee that the joining device actually "hits" such an enhanced 
> beacon? If the joining node listens on different channels itself, it 
> may never see an enhanced beacon of another device (e.g., if they are 
> just "following each other" in lockstep, which is very well possible). 
> The only way a joining node may "get lucky" seems to be when listening 
> on a fixed channel for a long time and hoping it would hear something. 
> If the neighbor is sending stuff on all frequencies and the function 
> "F" (channel frequency mapping of draft-watteyne-6tisch-tsch-00, 
> Section A.7) is the identity function, then if it would listen long 
> enough (the 24.24s or roughly half a minute above), then it would 
> encounter an EB. If the "hole" scenario of the minimal draft plays 
> out, it may have to listen much longer (moreover, the formula for the 
> channel frequency mapping may not result in any guarantees that each 
> channel frequency will indeed occur then). If the neighbor does have 
> some channel frequencies blocked or different devices have different 
> "F" functions, the situation seems to be very unclear.
>
> Enhanced Beacons Configuration and Content [IEEE802154e] does not 
> define how often or which EBs are sent. The choice of the duration 
> between two EBs needs to take into account whether EBs are used as the 
> only mechanism to synchronize devices, or whether a Keep-Alive (KA) 
> mechanism is used in parallel. For a simplest TSCH configuration, a 
> mote SHOULD send an EB every 10s. For additional reference see 
>> packet to

---

From: Michael Richardson <[email-masked]>
Date: Sun, 15 Jun 2014 15:30:13 -0400

Rene Struik <[email-masked]> wrote:
    > I hope this provides some evidence that it is unclear how one could "hit"
    > an enhanced beacon of a neighboring node. What I described above does not
    > deal with "negotiating"/"finding" a time slot/channel combo where the
    > joining device would actually send its first message (and at the same time
    > have some assurances that the EB-originator is still listening to it).

I understand your analysis.  I assume that the radio people have this under control.
What is the implication to the security of the various join protocols?

---

From: Kris Pister <[email-masked]>
Date: Sun, 15 Jun 2014 14:05:53 -0700

Rene -
   when a mote listens for EBs in order to synchronize to the network, 
it can either sit on a
single channel and listen, or change channels with a random dwell time 
per channel
that is long compared to a timeslot.  In either of these two cases, the 
time that a mote needs
to listen before it gets synchronized is given by (see attached paper on 
TSMP):

Tsynch = CA/(NPD)
C is the number of channels used
A is the interval between advertisements (EBs) sent by each neighbor
N is the number of neighbors
P is the packet delivery ratio (1-PER)
D is the radio duty cycle of the joining node

ksjp

---

From: Rene Struik <[email-masked]>
Date: Sun, 15 Jun 2014 18:15:59 -0400

Hi Michael:

There is more to security protocols than cryptographic properties - see 
my email of June 10, 2014, 1:50pm EDT (excerpt copied below, for your 
convenience).

BTW - as already said in my message of yesterday, Sat June 14, 2014, 
6:12pm EDT, we also need to "flag" how to set up a temporary channel 
between the joining node and its neighbor, etc. Hence, my item #c was 
about relationship between "join protocol and network":

[excerpt of email RS as of June 10, 2014, 1:50pm EDT]

---

From: Michael Richardson <[email-masked]>
Date: Sun, 15 Jun 2014 22:10:38 -0400

We had a very productive call last week.
Rene has started getting some feedback on the issues that are open.

Agenda for tomorrow:
  1. work on trust/cryptographic details of Joining-Node -> PCE message.
     does it need to be signed?

  2. 6top ideas for PCE->joining node protocol. Will this work as stock
     CoAP/DTLS, or do we need a proxy to help us?

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 16 Jun 2014 00:17:02 -0700

Rene,

Can you confirm that Kris' response answers your question about the
expected duration for  a node to hear an EB?

Per your question, I don't understand what you mean by " \"flag\" how to
set up a temporary channel". The formation of a TSCH PAN is described in
Section 5.1.2.6 of IEEE802.15.4e-2012, and involved:
- nodes already in the network regularly send EB. EB contain the current
ASN, as well as number of slot frames and timeslot, all encoded in IEs.
- the joining node uses the time of arrival and the ASN IE to synchronizes
to network
- the joining node uses the timeslots indicated in the IE to communicate
with the neighbor, through which is receives further configuration. How the
latter part happens is out of scope of IEEE802.15.4e-2012. 6TiSCH aims at
defining the mechanism of establishing this, securely.

For completeness, below is are the excerpts from IEEE802.15.4e-2012 which
should answer your question.

Although it is important to have a system-level approach, I still don't
clearly see the implication for security. I believe it can safely be
summarized as "one a node synchronizes to the network, it knows how to
speak to the node sending the EB".

Thomas

<excerpt>
A TSCH PAN is formed when a device, usually the PAN coordinator, advertises
the presence of the network by sending Enhanced Beacons.
[...]
Once the listening device has heard a valid Enhanced Beacon [...] the
device is synchronized to the network.
[...]
Typically at this point the device will go through a procedure to allocate
additional communication resources (slotframes and links) to the joining
device. This procedure may include a security handshake to mutually
authenticate the joining device, configure encryption keys, and configure
routing information. The mechanism and rules for setting up these
additional communication links and configure other policies would normally
be defined in a higher layer standard—the content of these messages is
beyond the scope of this document.
</excerpt>

On Sun, Jun 15, 2014 at 3:15 PM, Rene Struik <[email-masked]> wrote:

> Hi Michael:
>
> There is more to security protocols than cryptographic properties - see my
> email of June 10, 2014, 1:50pm EDT (excerpt copied below, for your
> convenience).
>
> between the joining node and its neighbor, etc. Hence, my item #c was about
> relationship between "join protocol and network":
>
> seems to be legitimate, but in hindsight does not turn out to be that way
> (both in terms of denial-of-service attacks, keeping state, etc.). Hence,
> my question.
>
>

---

From: Rene Struik <[email-masked]>
Date: Mon, 16 Jun 2014 09:45:04 -0400

Hi Thomas:

Once again, it is crucial to consider how the joining protocol fits into 
the underlying 802.15.4e/TSCH-based network: protocol details, time 
latencies, interaction of higher-layer security and MAC security do 
matter (a lot).

As already suggested in my email of June 10, 2014, 11:39am EDT (see 
weblink below and snippet), the joining node cannot rely on the ASN 
entry of its neighbor for frame security (item #a below). Hence, the 
newbee node (at least initially) can only hope for synchronization to 
its neighbor (and not the network manager or such). The same is true for 
initial scheduling.

I did not have the chance yet to have a look at the "DSN 2008" paper 
Kris Pister forwarded yesterday evening (Sun June 15, 2014, 5:05pm EDT) 
-- sorry, it was also a Sunday in Toronto. Will try and give this a look 
soon, though.

Please note that I am trying to get an idea of time latencies, which 
seem *huge*. If this is indeed correct, one should aim at ways of 
minimizing these.

http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00154.html
a)
b)
> beacons are heard. The PAN coordinator’s join priority is zero. A 
> the device is the preferred one to connect to. The beaconing device’s 

On 6/16/2014 3:17 AM, Thomas Watteyne wrote:
> Per your question, I don't understand what you mean by " \"flag\" how 
> to set up a temporary channel". The formation of a TSCH PAN is 
> described in Section 5.1.2.6 of IEEE802.15.4e-2012, and involved:
> - nodes already in the network regularly send EB. EB contain the 
> current ASN, as well as number of slot frames and timeslot, all 
> encoded in IEs.
> - the joining node uses the time of arrival and the ASN IE to 
> synchronizes to network
> - the joining node uses the timeslots indicated in the IE to 
> communicate with the neighbor, through which is receives further 
> configuration. How the latter part happens is out of scope of 
> IEEE802.15.4e-2012. 6TiSCH aims at defining the mechanism of 
> establishing this, securely.
>
> For completeness, below is are the excerpts from IEEE802.15.4e-2012 
> which should answer your question.
>
> Although it is important to have a system-level approach, I still 
> don't clearly see the implication for security. I believe it can 
> safely be summarized as "one a node synchronizes to the network, it 
> knows how to speak to the node sending the EB".
>
> Thomas
>
> <excerpt>
> A TSCH PAN is formed when a device, usually the PAN coordinator, 
> advertises the presence of the network by sending Enhanced Beacons.
> [...]
> Typically at this point the device will go through a procedure to 
> allocate additional communication resources (slotframes and links) to 
> the joining device. This procedure may include a security handshake to 
> mutually authenticate the joining device, configure encryption keys, 
> and configure routing information. The mechanism and rules for setting 
> up these additional communication links and configure other policies 
> would normally be defined in a higher layer standard—the content of 
> these messages is beyond the scope of this document.
> </excerpt>
>
>
>
> On Sun, Jun 15, 2014 at 3:15 PM, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Michael:
>
>     There is more to security protocols than cryptographic properties
>     - see my email of June 10, 2014, 1:50pm EDT (excerpt copied below,
>     for your convenience).
>
>     BTW - as already said in my message of yesterday, Sat June 14,
>     2014, 6:12pm EDT, we also need to "flag" how to set up a temporary
>     channel between the joining node and its neighbor, etc. Hence, my
>     item #c was about relationship between "join protocol and network":
>
>     energy cost, RAM/ROM usage, and computational and communication
>     time latency. Thus, while one might argue that "security should
>     not care how the MAC layer is doing its job", this only seems to
>     hold true if one is not interested in non-crypto performance
>     metrics. To implementation-specific metrics mentioned above, one
>     should add potential impact of traffic that seems to be
>     legitimate, but in hindsight does not turn out to be that way
>     (both in terms of denial-of-service attacks, keeping state, etc.).
>     Hence, my question.
>
>
>         Rene Struik <[email-masked]
>         <mailto:[email-masked]>> wrote:
>         Michael Richardson <[email-masked]
>         <mailto:[email-masked]>>, Sandelman Software Works
>     email: [email-masked] <mailto:[email-masked]> |
>     Skype: rstruik
>     cell: +1 (647) 867-5658 <tel:%2B1%20%28647%29%20867-5658> | US: +1
>     (415) 690-7363 <tel:%2B1%20%28415%29%20690-7363>
>
>     [email-masked] <mailto:[email-masked]>