Re: [6lo] [6tisch] Thomas' review of draft-thubert-6lo-forwarding-fragments-04

[Tero Kivinen <[e-mail]>]

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. 
-- 
[e-mail]