PWK writes: > Tero; I understand your scenario, and I also believe that all WAN/LAN/PAN > wireless networks should always use security.
Agree, but looking at the current usage that does not seem to be true, and looking at things like issues found while making revision there are not that many implementor who have implemented security, as they would have noticed those issues if they actually would have implemented them. Or they just implemented something, and didn't really care that the specification was not specifying things exatly... > But to further analyze your scenario, since 802.15.4 LP-WAN is star > topology based, in your example A<=>B would be one network and C<=>D > would be another network. Section 5.5 Network topologies of 802.15.4-2015 do say that IEEE 802.15.4 LR-WPAN operates in either of two topologies: the star topology or the peer-to-peer topology. So 802.15.4 is not only star topology... Also this is still issue with star topology, as two nodes might send fragments to the coordinator at the same time, and as TID is allocated by the sender only, and coordinator does not have ability to reject incoming FSCD IE. When the coordinator parses that FSCD IE it has most likely already sent an Ack back to the frame, and if the TID it got in the FSCD IE is overlapping with some other fragment exchange it has already going on, there is nothing it can do. Even if it parses the FSCD IE before sending the ACK, it is supposed to send ACK back because it did receive the frame properly. > Prior to staring they would have looked to see if there were other > networks set up on the channel, therefore one would have used > another channel (as you noted). Not really. They would look for free enough channel. If there is not too much traffic on the channel they try when forming the network, they can pick that channel. And some other networks could also end up using the same channel. And there might even be some TSCH or similar channel hopping networks using the same channel. > By the way, the scenario you choose is similar to two networks > choosing the same PAN ID and allocating the same short addresses to > nodes that are in range of both networks. PAN ID conflicts are handled by the 802.15.4 using the PAN ID Conflict notification command, which will cause the one of PANs to renumber to use some other PAN ID. The PAN does not necessarely move to the other channel, it can still stay on the same channel. > Secondly, your scenario assumes that they both send the Fragment Sequence > Context Description at almost the same time, which is very unlikely for two > networks so close together. They do not need start at the same time, it is enough if one of them is faster, and passes the other. I.e., A starts ending frames, but is very slow and can only send one frame every 500 ms, and it has 20 frames to send, so total time of sending the fragment will be 10 seconds. C is must faster and can send back to back frames, meaning it can send frames every 10 ms or so, so it can finish its 20 frame transaction in 200 ms. If the C starts its transaction while A is doing its fragment transaction, then both B and D will receive those frame, and B will reject the frames having the fragment number smaller than what A has already sent, but after C passes A it will accept rest of the fragments from the C. > If they were “out-of-sync” then B or D would have > received a fragment out of sync, so if Frak policy zero was in use, reception > of an out-of-order fragment would have resulted in termination of the > transaction. The other two policies would have resulted in a condition where B > or D would have received a fragment out of sequence that was already correctly > received, so it would have discarded that fragment, while the other would have > received a fragment number ahead of its time and would have accepted it. > > Finally, for the last case, I will also propose a text change in the next > revision that when the frame is reassembled, the standard policy of checking > the FCS and sending ACKs is used. That might help somewhat, but I think there is too much issues with the current LECIM fragmentation with the fact that it does not have addressing fields, that fixing it is not really worth of the effort. It is better to pick the fragmentation from the 802.15.9 and use that instead. -- [email protected] _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
