Subject: [6tisch] a little puzzle

From: Kris Pister <[email-masked]>
Date: Wed, 22 Apr 2015 10:15:46 -0700

Alice and Bob make wireless temperature sensors that run a 6tisch stack.
Charlie owns a nationwide chain grocery store and is rolling out 6tisch 
everywhere.
Zelda sells wireless toys that use 802.15.4e.
Mallory is always lurking.

Charlie needs to decide if and how to use message integrity checks on 
enhanced beacons.
He thinks that he has three options:
1) don't use MICs on EBs.
2) use MICs on EBs, with a secret key
3) use MICs on EBs, with a well-known key

Charlie does some testing of option 1, and finds that when there is a 
Zelda's Toy Shop
near one of his stores, his networks take a *really* long time to join.  
It seems that
Zelda's toys send 15.4e EBs too, and they send a lot of them.  The 
sensors that
Alice and Bob sell spend a lot of time and battery energy trying to join 
the wrong network.
Charlie would really like something better than option 1.

Charlie decides to use option 2, a MIC with a secret key, and it works 
great!  The sensors
ignore EBs from Zelda's, and only respond to EBs from his networks. He 
asks Alice and Bob
if they are willing to install that secret key before they ship the 
sensors to his various
stores, and he's such a big customer that they say sure.  He is driving 
an industry standard.

But then Charlie gets worried.  He's probably going to end up buying 
sensors from
Aaron, Abu, Acacia, and Ada as well.  How will he keep his key secret?  
Eventually
someone will find it or leak it, and then there will be a big news story 
"Charlie's
Markets Hacked!"  He imagines himself trying to explain to reporters 
that the
MIC key on the EB is just there for network segregation and message 
integrity.
He imagines that wouldn't go very well, so he decides option 2 is out.  
Maybe
he can just publish the MIC key in the standard?

But if Charlie uses option 3, a well-known key, Mallory will be able to 
spoof EBs.
Of course, if he uses no MIC at all, Mallory will also be able to spoof EBs.

What should Charlie do?

ksjp

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 23 Apr 2015 05:14:25 +0200

Kris,

can you explain me

"Charlie does some testing of option 1, and finds that when there is a
Zelda's Toy Shop
near one of his stores, his networks take a *really* long time to join.  It
seems that
Zelda's toys send 15.4e EBs too, and they send a lot of them.  The sensors
that
Alice and Bob sell spend a lot of time and battery energy trying to join
the wrong network.
Charlie would really like something better than option 1."

why if there is no authentication it takes longer that if there is
authentication? I understand that if a network sends a lot of EBs other
networks will receive the frames despite there is authentication or not.
 if there is no authentication a node parses the EB and decides to join or
not. If the nodes uses a MIC it has to receive the packet as well and check
the MIC then decides to join or not. In both cases the nodes receive a lot
of EBs so the situation is similar (the only difference is that if we use
MIC and the node can decode it the node knows that it is allowed to join
that network).

I only see benefit if the MIC is used as a filter and this is done
automatically by the hw.

regards,
Xavi

2015-04-22 19:15 GMT+02:00 Kris Pister <[email-masked]>:

> Zelda's toys send 15.4e EBs too, and they send a lot of them.  The sensors
> that
> stores, and he's such a big customer that they say sure.  He is driving an
> industry standard.
>
> Markets Hacked!"  He imagines himself trying to explain to reporters that
> the
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Simon Duquennoy <[email-masked]>
Date: Thu, 23 Apr 2015 09:07:11 +0200

Dear all,

As I'm new to this list I apologize in advance if I'm missing the obvious.

My general impression is that using MIC for network segregation only is
overkill.
* How about defining a 6TiSCH-specific IE (with an ID from the "unmanaged"
space) to uniquely identify vendors?
* If I were Charlie and really needed security, I would ask Alice and Bob
to provide their sensors with a pre-deployment key setup mechanism, and use
a pre-shared secret key.

Best regards,
Simon Duquennoy

On Thu, Apr 23, 2015 at 5:14 AM, Xavier Vilajosana <
[email-masked]> wrote:

>  if there is no authentication a node parses the EB and decides to join
> or not. If the nodes uses a MIC it has to receive the packet as well and
> check the MIC then decides to join or not. In both cases the nodes receive
> a lot of EBs so the situation is similar (the only difference is that if we
> use MIC and the node can decode it the node knows that it is allowed to
> join that network).
>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 23 Apr 2015 09:31:53 +0200

Xavi,

If I read Kris' e-mail correctly, in option 1, Charlie's nodes attempt to
join Zelda's network (i.e. they synchronize and ask the JCE, or equivalent,
to join). Since Zelda's network cannot authenticate Charlie's node, it gets
rejected. Charlie's node then tries again by listening for EBs. Because
Zelda's toys send so many beacons (they are little robots with motors
drawing 1A of current, so the little bit of extra current because of a
large number of EBs doesn't matter), Charlie's node attempts to join
Zelda's network much more often that its own. Charlie's nodes waste a lot
of energy trying over and over, until they finally join Charlie's network.

Thomas

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 23 Apr 2015 09:36:24 +0200

Hi Thomas,

sorry, but I still do not see the benefit :) .. In both case 1 and case 2
Zelda's network will be sending a lot of EBs and Charlie's nodes will be
receiving that EBs. In both cases Charlie node will be receiving more EBs
from Zelda's network than from Charlie's network. This will be slowing down
the join procedure.

I understand that Zelda's network JCE will reject Charlie's nodes when
trying to join if MIC is not correct. However, when Zelda's network send
EBs, they are broadcast and Charlie's nodes must receive them anyway. So
the difference seems slight and only from the JCE side not from Charlie's
nodes which will be still trying to parse a lot of EBs.

am I missing something?
X

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 23 Apr 2015 10:02:33 +0200

Kris,

Nice little puzzle. Let me throw in my 2c.

*PANIDs & MIC keys*

In practice, I see two mechanisms for a node to filter EBs: PANid (2B) and
MIC key (16B)

   - PANIDs. The IEEE802.15.4 header contains a PANID, a 2-byte number.
   Charlie, Zelda and the other could set they networks to different PANIDs. A
   receiving radio will simply drop any packet which has a destination PANID
   set to a value different than the one if was configured on. This is easy
   to do, but comes IMO with a couple of drawbacks. First, there are only
   65534 PANDS available, so collisions are possible. Second, and more
   importantly, this doesn't prevent a 6TiSCH node from mistaking a
   IEEE802.15.4 frame created by some (possibly proprietary protocol) for an
   EB. And finally, nodes can be made "PANID-agile": the joining node scans
   all PANIDs looking for a nearby 6TiSCH networks, so PANID-based
   discrimination doens't help here
   - MIC keys. I that context, the MIC is simply a 4-8 byte "super CRC"
   which essentially is calculated differently depending the key used. Through
   this mechanism, a node can detect with great confidence (keys are 16 bytes
   long) that this packet is indeed an EB sent by a 6TiSCH network.

In that context, I would favor MIC keys, possibly in conjuction with
PANIDs, although the contribution of the latter is smaller.

*But what are we talking about?*

Before giving my answer to your puzzle, I'd like to somehow limit its
scope, and highlight the security+efficiency implications.

Security in Charlie's network is of paramount importance, and the
discussion we're having about EBs has very little to do with the security
of the network. When a joining node hears one of Charlie's EBs, the only
thing it can do is start a joining process. This, as we discuss in the
security DT, probably means contacting the network's JCE to ask to join.
The *only* thing we are talking about here is how to prevent a joining node
from initiating a joining process with the wrong network. Why? Because that
network will reject the node, and the node will have to re-try to another
network. In reality, we're mostly talking about coexistence between
networks, and speeding up the joining process.

Under no circumstance can anything of what we're discussing allow a joining
node to wrongfully join a network.

*My answer to the puzzle*

So here are my answer to the puzzle: I would leave the options open.

Option 1 (no MIC), IMO makes no sense. CCM* is needed for any other
traffic, so its available to us. The cost of calculating a MIC is
negligiable compared to the cost of communication that it would be foolish
not to take advantage of it.

Choosing between Option 2 (secret key) and Option 3 (well-known key)
depends on the application, and there are very valid arguments for both. In
your puzzle, I believe Charlie and Zelda would make different choices.
- Zelda's toys have to network quickly, possibly with other manufacturers.
If I were Zelda, I would use a MIC key which is well-known, possibly
written in the standard. If an "evil toy" attempts to join Zelda's network,
it will be able to synchronize to the network and initiate a joining
procedure with Zelda's JCE, but will get rejected. The energy/bandwidth
wasted because of this is not a problem for Zelda's toys, whose motors are
drawing 3-6 orders of magnitude more than their radio.
- Charlie's networks are completely optimized, and Charlie doesn't want to
constantly be receiving join requests from nodes (malicious or not) who
have no business joining its network. So Charlie uses a secret MIC key.
Charlie might even implement some key rotation mechanism for that key.
Charlie understands that all of this is only to avoid non-authorized nodes
to attempt to join the network. The JCE is the real gate keeper to the
network, and authenticating to it is done through a totally different
mechanism.

Thomas

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 23 Apr 2015 10:19:03 +0200

Simon,

Welcome to the list!!

> overkill.

I respectfully disagree :-) CCM* is in all motes, and auth+enc mod is used
on all data packets. On well designed chips, both the time and energy spent
for running CCM* is negligible.
I might be missing your point completely. Can you provide more info about
what you mean by overkill?

> space) to uniquely identify vendors?

I consider the MIC key to essentially play that role. Yet, instead of
sending a explicit field with a vendor identifier it is (e.g. in an IE),
the "vendor identifier" is used as a key for MIC.
If you want the IE to provide the same 16-byte "segregation power" than
CCM, is has to be 2+16 bytes long. A MIC is 4-8 bytes.
Using an IE doesn't prevent from mistaking a random IEEE802.15.4 frame in
the air for a vaid EB.

> to provide their sensors with a pre-deployment key setup mechanism, and use

This is similar to my conclusion a couple of e-mails ago in this thread,
although I need to insist that the key used for EB authentication doesn't
impact the "security" of your netwokr, as the ream gatekeeper is the JCE.

Thomas

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 23 Apr 2015 10:35:15 +0200

Xavi,

I think (?) I understand where we get confused.

In both case 1 and case 2 Zelda's network will be sending a lot of EBs and
> Charlie's nodes will be receiving that EBs.

Agreed.

> In both cases Charlie node will be receiving more EBs from Zelda's network
> than from Charlie's network.

Agreed.

> This will be slowing down the join procedure.

Not agreed, or not exactly :-) Many packets in the air (EBs or not) mean
occasional packet collision and MAC-level retransmissions, for sure.
But the main reason in this case for Charlie's mote to join slowly is that
is attempts to join Zelda's network: the mote hears Zelda's EB,
synchronizes to it, contacts Zelda's JCE to join, which rejects it. That
process might take tens of second, and it happens every time Charlie's mote
mistakes Zelda's EB for one of Charlie's.

> trying to join if MIC is not correct.

Agreed.

> However, when Zelda's network send EBs, they are broadcast and Charlie's
> nodes must receive them anyway. So the difference seems slight and only
> from the JCE side not from Charlie's nodes which will be still trying to
> parse a lot of EBs.

Agreed, regardless of what we come up with, Charlie's node needs to listen
for valid EBs, which involves parsing all packets it receives (maybe with a
little help of the HW). But it terms of delays, it's the "starting to join
the wrong network" that has the most impact.

right? wrong?

Thomas

On Thu, Apr 23, 2015 at 9:36 AM, Xavier Vilajosana <
[email-masked]> wrote:

>>>> near one of his stores, his networks take a *really* long time to
>>>> join.  It seems that
>>>> Alice and Bob sell spend a lot of time and battery energy trying to
>>>> join the wrong network.
>>>> someone will find it or leak it, and then there will be a big news
>>>> story "Charlie's

---

From: Simon Duquennoy <[email-masked]>
Date: Thu, 23 Apr 2015 10:37:21 +0200

> what you mean by overkill?

Fair enough. I find this overkill conceptually but on good chips this will
be cheap enough, agreed.

> Using an IE doesn't prevent from mistaking a random IEEE802.15.4 frame in

If you enforce checking of the vendor ID on incoming EB then you filter out
others' traffic don't you?
One point in favor of having an IE vs. MIC: it makes explicit that we do
segregation, nothing else. No-one will be mistaken thinking we're trying to
achieve security. For troubleshooting it may also be nice to be able to
sniff packets and see vendor IDs rather than having to deal with
(non-constant and cryptic) MICs.

Agreed.

Simon

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 23 Apr 2015 10:45:32 +0200

Simon,

For me, vendor IDs have to problems: (1) it's a pain to manage that space
and (2) what do you do if a company does NOT want to announce it's vendor
it in each EB.

Thomas

On Thu, Apr 23, 2015 at 10:37 AM, Simon Duquennoy <[email-masked]> wrote:

>> I respectfully disagree :-) CCM* is in all motes, and auth+enc mod is
>> used on all data packets. On well designed chips, both the time and energy
>> spent for running CCM* is negligible.
>> * How about defining a 6TiSCH-specific IE (with an ID from the
>>> "unmanaged" space) to uniquely identify vendors?
>>>
>>
> If you enforce checking of the vendor ID on incoming EB then you filter
> out others' traffic don't you?
>>> * If I were Charlie and really needed security, I would ask Alice and
>>> Bob to provide their sensors with a pre-deployment key setup mechanism, and
>>> use a pre-shared secret key.
>>
>>
>>>>  if there is no authentication a node parses the EB and decides to
>>>> join or not. If the nodes uses a MIC it has to receive the packet as well
>>>> and check the MIC then decides to join or not. In both cases the nodes
>>>> receive a lot of EBs so the situation is similar (the only difference is
>>>> that if we use MIC and the node can decode it the node knows that it is
>>>> allowed to join that network).
>>>>
>>>>> Charlie owns a nationwide chain grocery store and is rolling out
>>>>> 6tisch everywhere.
>>>>> stores, and he's such a big customer that they say sure.  He is
>>>>> driving an industry standard.
>>>>>
>>>>> Aaron, Abu, Acacia, and Ada as well.  How will he keep his key
>>>>> secret?  Eventually
>>>>> He imagines that wouldn't go very well, so he decides option 2 is
>>>>> out.  Maybe
>>>>> But if Charlie uses option 3, a well-known key, Mallory will be able
>>>>> to spoof EBs.

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 23 Apr 2015 14:29:58 +0200

Hi Thomas,

now things are clear. If the "starting to join" is the bottleneck then I
agree with you and I come up to the same conclusion.

thanks for the clarification. At least for me now there is no doubt about
it.

regards,
Xavi

2015-04-23 10:35 GMT+02:00 Thomas Watteyne <[email-masked]>:

>> In both cases Charlie node will be receiving more EBs from Zelda's
>> network than from Charlie's network.
>
>
> Agreed.
>
>
>>> If I read Kris' e-mail correctly, in option 1, Charlie's nodes attempt
>>> to join Zelda's network (i.e. they synchronize and ask the JCE, or
>>> equivalent, to join). Since Zelda's network cannot authenticate Charlie's
>>> node, it gets rejected. Charlie's node then tries again by listening for
>>> EBs. Because Zelda's toys send so many beacons (they are little robots with
>>> motors drawing 1A of current, so the little bit of extra current because of
>>> a large number of EBs doesn't matter), Charlie's node attempts to join

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Apr 2015 16:48:36 +0300

> 3) use MICs on EBs, with a well-known key

But the best option is to use option 4

4) Use MICs on EBs, with a secret key distributed during the joining
   process, and add vendor specific IE to identify the network.

In this case the EBs are authenticated with MIC, but when the Alice
and Bob's devices try to connect it they do not know the key, so they
cannot verify the authentication information, but as the frames are
not encrypted they can still see the vendor specfic IE, and check that
it matches what they expect it to match.

This way they will be able to filter out EBs which they want to hear.
I.e. after finding the EB which has suitable IE they start joining
process  to that network. During that joining process they will get
the secret key used to protect the EBs and secret key used to protect
the normal data traffic.

After that they can use the draft-ietf-6tisch-minimal to talk to the
network, and they can use it securely as they can now authenticate the
IEs sent in the EBs, and they know Mallory cannot fake those, as
Mallory does not know the secret key, so they do not need to do any
other protocol.

If they would be using the option 3, they cannot trust anything EBs
have, thus they cannot use draft-ietf-6tisch-minimal at all, as
Mallory could mess up the network very easily by just sending few EBs
with wrong data in IEs.

Also now as the Charlie has IE which is used to separate the networks
from each other, when it makes new network used for its cashier
machines, and it does not want to share the cashier machine keys with
the temperature sensors it wants to use different keys, and it also
wants to make sure that the temperature sensors do not needlessly try
to join the other network, he can just use different content for that
IE. Also as the those two networks use different secret keys, both
networks can trust the data sent on their EBs. This EB secret key is
different for every site, and might even be rekeyed every now and
then.

And yes, Mallory can still send fake EBs with same IE content, trying
to trick the temperature sensors to join his network, but as the
joining process authentication fails, the temperature sensors will not
join his network, but try to find better network i.e the real network.

> Of course, if he uses no MIC at all, Mallory will also be able to spoof EBs.

And if Mallory can spoof EBs he can easily mess up the network
completely. This also means that devices cannot use
draft-ietf-6tisch-minimal as they cannot trust anything that is sent
in the EBs, so some other protocol is used to know even the shared
slots used to talk to anybody.

> What should Charlie do?

Use option 4...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Apr 2015 16:53:04 +0300

> For me, vendor IDs have to problems: (1) it's a pain to manage that

Why? You allocate Company OUI for Charlie (even when it does not make
devices), or you can even allocate one for some alliance. After that
whatever you put after that is your companies problem. Btw, most of
the companies who are already making devices for 802.15.4 have OUI
anyways, as it is needed for MAC addresses.

Of course if the network separation is big issue, we can also allocate
generic IE for this purposes. 

> and (2) what do you do if a company does NOT want to announce
> it's vendor it in each EB.

It does that already in the extenedd address of the device. And even
when it does not, secrecy does not help in security, meaning it is
very easy to fingerprint the devices to find out who made it...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Apr 2015 17:04:53 +0300

Thomas Watteyne writes:
> PANIDs & MIC keys
> 
> In practice, I see two mechanisms for a node to filter EBs: PANid (2B) and MIC
> key (16B)
> 
>   * PANIDs. The IEEE802.15.4 header contains a PANID, a 2-byte number.
>     Charlie, Zelda and the other could set they networks to different PANIDs.
>     A receiving radio will simply drop any packet which has a destination
>     PANID set to a value different than the one if was configured on. This is 
>     easy to do, but comes IMO with a couple of drawbacks. First, there are
>     only 65534 PANDS available, so collisions are possible. Second, and more

PAN ID cannot be used to identify networks before you join to them.
They are only used after you have joined the network to separate
multiple networks working on the same area. I.e. when the PAN
coordinator sets up the network he finds "free" PAN ID and starts
using that. If he at any point hears someone using the same PAN ID, he
will notice there is PAN ID collision and change his PAN ID to
something else. What this PAN ID collision and changing of PAN ID
means for TSCH network is bit fuzzy for now. It is one of those issues
we are discussing in the maintenance work, as PAN ID conflict
resolution is mandatory feature of 802.15.4, but this allows very easy
way to make easy DoS attacks against networks.

>   * MIC keys. I that context, the MIC is simply a 4-8 byte "super CRC" which
      	  	       		    	   	    ^^^
4-16 bytes, lengths are 32, 64 or 128-bits, i.e. 4, 8, or 16 bytes
long. 

>     essentially is calculated differently depending the key used. Through this
>     mechanism, a node can detect with great confidence (keys are 16 bytes

Keys are 16 bytes long, but if the MIC sent is only 4 bytes, then
there is 2^32 propability that random packet will have correct mic...

For the network separator IE, the length does not need to be that
long, it can be made unique in other ways. For example if we already
use unique allocation of OUIs, and then add company internal ID to
that, we might use 5 byte content for the IE. 

> In that context, I would favor MIC keys, possibly in conjuction with PANIDs,
> although the contribution of the latter is smaller.
> 
> But what are we talking about?
> 
> Before giving my answer to your puzzle, I'd like to somehow limit its scope,
> and highlight the security+efficiency implications.
> 
> Security in Charlie's network is of paramount importance, and the discussion
> we're having about EBs has very little to do with the security of the network.

As long as it does not use draft-ietf-6tisch-minimal, which will
require EBs to be secure. 

> When a joining node hears one of Charlie's EBs, the only thing it can do is
> start a joining process. This, as we discuss in the security DT, probably
> means contacting the network's JCE to ask to join. The *only* thing we are
> talking about here is how to prevent a joining node from initiating a joining
> process with the wrong network. Why? Because that network will reject the
> node, and the node will have to re-try to another network. In reality, we're
> mostly talking about coexistence between networks, and speeding up the joining
> process.

Yes. And for that network identifier IE is much better way than MIC.

> My answer to the puzzle

I do not think the option 3 is useful in any case where any security
is needed. Effectively option 3 is exactly same as option 1 in
security, and in that case you rule out draft-ietf-6tisch-minimal for
that network.
-- 
[email-masked]

---

From: Kristofer PISTER <[email-masked]>
Date: Thu, 23 Apr 2015 10:04:24 -0700

> If I were Charlie and really needed security,
Charlie is very concerned with security.  He is driving a standard that
will use X.509 certificates during the join process, with an end state
that involves randomly generated secret keys for all network traffic, with
separate keys at L2 and for end-to-end DTLS sessions.

> I would ask Alice and Bob to provide their sensors with a pre-deployment
key setup mechanism, and use a pre-shared secret key.
Indeed, I think that defining and using that mechanism is what the
discussion is about.
Charlie has convinced Alice and Bob to add X.509 certs in their devices.
They will be able to enter into DTLS sessions (or whatever else
is decided to be preferred).  The question is how do they send in that very
first "client hello" message.  EBs provide the mechanism for a
node already in the network (the JA) to say "I will be listening at this
time on this channel".  They do not do anything else in a 6tisch minimal
network.

ksjp

---

From: Qin Wang <[email-masked]>
Date: Thu, 23 Apr 2015 17:05:39 +0000 (UTC)

Hi Thomas and Xavi,
I agree that with the a well-known key based MIC, some useless "start to join" can be avoided. However, it is under the assumption that there is no other 6tisch networks, right? If there are more than one 6tisch networks in the same area, and all of them use the well-known  key based MIC to authentication, then the authentication will not save anything, right?
ThanksQin 

     On Thursday, April 23, 2015 8:30 PM, Xavier Vilajosana <[email-masked]> wrote:

 Hi Thomas,
now things are clear. If the "starting to join" is the bottleneck then I agree with you and I come up to the same conclusion.
thanks for the clarification. At least for me now there is no doubt about it.
regards,Xavi
2015-04-23 10:35 GMT+02:00 Thomas Watteyne <[email-masked]>:

Xavi,

In both case 1 and case 2 Zelda's network will be sending a lot of EBs and Charlie's nodes will be receiving that EBs.

Agreed. 
In both cases Charlie node will be receiving more EBs from Zelda's network than from Charlie's network.

Agreed. 

Not agreed, or not exactly :-) Many packets in the air (EBs or not) mean occasional packet collision and MAC-level retransmissions, for sure.But the main reason in this case for Charlie's mote to join slowly is that is attempts to join Zelda's network: the mote hears Zelda's EB, synchronizes to it, contacts Zelda's JCE to join, which rejects it. That process might take tens of second, and it happens every time Charlie's mote mistakes Zelda's EB for one of Charlie's.

I understand that Zelda's network JCE will reject Charlie's nodes when trying to join if MIC is not correct.

Agreed. 
However, when Zelda's network send EBs, they are broadcast and Charlie's nodes must receive them anyway. So the difference seems slight and only from the JCE side not from Charlie's nodes which will be still trying to parse a lot of EBs.

Agreed, regardless of what we come up with, Charlie's node needs to listen for valid EBs, which involves parsing all packets it receives (maybe with a little help of the HW). But it terms of delays, it's the "starting to join the wrong network" that has the most impact.
right? wrong?
Thomas
On Thu, Apr 23, 2015 at 9:36 AM, Xavier Vilajosana <[email-masked]> wrote:

Hi Thomas,
sorry, but I still do not see the benefit :) .. In both case 1 and case 2 Zelda's network will be sending a lot of EBs and Charlie's nodes will be receiving that EBs. In both cases Charlie node will be receiving more EBs from Zelda's network than from Charlie's network. This will be slowing down the join procedure. 
I understand that Zelda's network JCE will reject Charlie's nodes when trying to join if MIC is not correct. However, when Zelda's network send EBs, they are broadcast and Charlie's nodes must receive them anyway. So the difference seems slight and only from the JCE side not from Charlie's nodes which will be still trying to parse a lot of EBs.
am I missing something?X
2015-04-23 9:31 GMT+02:00 Thomas Watteyne <[email-masked]>:

Xavi,
If I read Kris' e-mail correctly, in option 1, Charlie's nodes attempt to join Zelda's network (i.e. they synchronize and ask the JCE, or equivalent, to join). Since Zelda's network cannot authenticate Charlie's node, it gets rejected. Charlie's node then tries again by listening for EBs. Because Zelda's toys send so many beacons (they are little robots with motors drawing 1A of current, so the little bit of extra current because of a large number of EBs doesn't matter), Charlie's node attempts to join Zelda's network much more often that its own. Charlie's nodes waste a lot of energy trying over and over, until they finally join Charlie's network.
Thomas
On Thu, Apr 23, 2015 at 5:14 AM, Xavier Vilajosana <[email-masked]> wrote:

Kris,
can you explain me
"Charlie does some testing of option 1, and finds that when there is a Zelda's Toy Shopnear one of his stores, his networks take a *really* long time to join.  It seems that
Zelda's toys send 15.4e EBs too, and they send a lot of them.  The sensors that
Alice and Bob sell spend a lot of time and battery energy trying to join the wrong network.
Charlie would really like something better than option 1."
why if there is no authentication it takes longer that if there is authentication? I understand that if a network sends a lot of EBs other networks will receive the frames despite there is authentication or not.  if there is no authentication a node parses the EB and decides to join or not. If the nodes uses a MIC it has to receive the packet as well and check the MIC then decides to join or not. In both cases the nodes receive a lot of EBs so the situation is similar (the only difference is that if we use MIC and the node can decode it the node knows that it is allowed to join that network).
I only see benefit if the MIC is used as a filter and this is done automatically by the hw.
regards,Xavi
2015-04-22 19:15 GMT+02:00 Kris Pister <[email-masked]>:

Alice and Bob make wireless temperature sensors that run a 6tisch stack.
Charlie owns a nationwide chain grocery store and is rolling out 6tisch everywhere.
Zelda sells wireless toys that use 802.15.4e.
Mallory is always lurking.

Charlie needs to decide if and how to use message integrity checks on enhanced beacons.

Charlie does some testing of option 1, and finds that when there is a Zelda's Toy Shop
near one of his stores, his networks take a *really* long time to join.  It seems that
Zelda's toys send 15.4e EBs too, and they send a lot of them.  The sensors that
Alice and Bob sell spend a lot of time and battery energy trying to join the wrong network.
Charlie would really like something better than option 1.

Charlie decides to use option 2, a MIC with a secret key, and it works great!  The sensors
ignore EBs from Zelda's, and only respond to EBs from his networks. He asks Alice and Bob
if they are willing to install that secret key before they ship the sensors to his various
stores, and he's such a big customer that they say sure.  He is driving an industry standard.

But then Charlie gets worried.  He's probably going to end up buying sensors from
Aaron, Abu, Acacia, and Ada as well.  How will he keep his key secret?  Eventually
someone will find it or leak it, and then there will be a big news story "Charlie's
Markets Hacked!"  He imagines himself trying to explain to reporters that the
MIC key on the EB is just there for network segregation and message integrity.
He imagines that wouldn't go very well, so he decides option 2 is out.  Maybe
he can just publish the MIC key in the standard?

But if Charlie uses option 3, a well-known key, Mallory will be able to spoof EBs.
Of course, if he uses no MIC at all, Mallory will also be able to spoof EBs.

What should Charlie do?

ksjp

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 24 Apr 2015 00:49:43 +0200

> way to make easy DoS attacks against networks.

I haven't seen text about networks changing PANids on-the-fly when someone
else is using it, but that's a separate discussion.

> 4-16 bytes, lengths are 32, 64 or 128-bits, i.e. 4, 8, or 16 bytes

agreed

> there is 2^32 propability that random packet will have correct mic...

agreed.

> PANIDs,
> scope,
> discussion

Why? If I receive a EB which I cannot authenticate, I reject it exactly the
same way I would reject an EB with a netid IE I don't like,

> security, and in that case you rule out draft-ietf-6tisch-minimal for

We're been over this so many times.... The well-known key does not offer
you any security, i.e. it's security value is the same as option 1, but it
gives you the convenience of early network segragation when a new node
heard a bunch of EBs...

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 24 Apr 2015 00:51:32 +0200

Qin,

You are right. Hence the ability to change the MIC key if you want to.

Thomas

On Thu, Apr 23, 2015 at 7:05 PM, Qin Wang <[email-masked]> wrote:

> Hi Thomas and Xavi,
>
> I agree that with the a well-known key based MIC, some useless "start to
> join" can be avoided. However, it is under the assumption that there is no
> other 6tisch networks, right? If there are more than one 6tisch networks in
> the same area, and all of them use the well-known  key based MIC to
> authentication, then the authentication will not save anything, right?
>
> Thanks
> Qin
>
>
>