>> I think that the confusion here is in thinking that EBs are involved
>> in normal network operation. They are not.
> I have understood that draft-ietf-6tisch-minimal plans to use them
> also in normal operation.
The text in minimal-06 reads
"EBs should not in general be used for synchronization."
In -07 we should certainly change that to caps. I'm guessing that Tero
would
argue that it should be MUST NOT instead of SHOULD NOT. I would agree.
I note that draft-ietf-6tisch-tsch-06 generally describes this process well,
but does include one sentence which should be removed:
"Nodes can keep synchronization exclusively by exchanging EBs."
This either needs to be explicitly not allowed, or Charlie has to go
back to
square one.
ksjp
On 4/24/2015 5:24 AM, Tero Kivinen wrote:
Kristofer PISTER writes:
Charlie is excited to hear more about option 4! :)
Use MICs on EBs, with a secret key distributed during the joining
process, and add vendor specific IE to identify the network.
This seems like a chicken and egg problem. In order to get the
secret key for the EBs, you need to go through the joining
process...which starts with receiving an EB...
Yes, and the problem is what?
The EBs are MICed, but encrypted, which means that the device can
receive them and parse them.
During the active or passive scan when the device receives the secured
EB they will try to unsecure them, but even if they cannot, they will
store information from the EB, and they can still join the network:
>From 802.15.4-2011:
5.1.2.1.2 Active and passive channel scan
...
The information from the unsecured frame shall be recorded in
the PAN descriptor even if the status from the unsecuring
process indicated an error
...
Only difference in the 802.15.4rev-DF5 is that it talks about the
"frame to be unsecured" instead of "usecured frame", as the security
processing will not set the "unsecured frame" if the security
processing failed. The "frame to be unsecured" is the input to the
security processing.
I think that the confusion here is in thinking that EBs are involved
in normal network operation. They are not.
I have understood that draft-ietf-6tisch-minimal plans to use them
also in normal operation. I.e. if you do not want to have any
dedicated timeslots, and only want to keep track of the network, just
in case someone wants to talk to you, you listen the EBs and thats it.
Perhaps I am mistaken.
EBs are just used during joining, to get a new mote aware of the
existence of a network, so that it can go through the joining
process, and receive the secret keys that are used in normal network
operation.
Thats one use of them. They are also needed when you need to rejoin
the network to know the ASN. And also during the normal operation they
are used to keep track of time, i.e. if you are using frame-based time
synchronization you can sync your time when you receive EBs from your
time parent.
Having Mallory forge EBs does NOT mess up the existing network.
It will if he for example creates PAN ID conflit. On the other hand
currently he can do that even when he does not have proper keys, so
here protecting EBs will not help.
No mote which has joined the network is listening to EBs.
EBs are not used in synchronization of motes that are already in the
network, or anything else. EBs are just used to initiate the join
process, and nothing more.
Which parts of the 802.15.4 specification is saying that? I have not
found any text claiming EBs in TSCH to be limited for only that.
Once motes are joined to a network, they use a randomly generated
secret key (s) K2. They do not use EBs for anything.
That will limit TSCH networks to be very small networks. I.e. you
cannot have network with tens of thousands mostly listen only sleeping
sensor nodes in slow polling mode.
Networks with more than 65534 nodes is completely out of question as
to be able to allocate schedule you need to have short address, and
there is only 65k of those.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
