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 protected]> 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 protected]>:
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.
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 protected]> 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 protected]>:
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 protected]> 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 protected]>:
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
