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

[PWK <[e-mail]>]

Tero; I understand your scenario, and I also believe that all WAN/LAN/PAN wireless networks should always use security.  

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.  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).  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. 

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.  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.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, SC chair
ISA100 co-chair, ISA100.20 chair
O: +1.847.960.3715
[e-mail] <mailto:[e-mail]>

On 7, Apr2017, at 4:48, Tero Kivinen <[e-mail]> wrote:

PWK writes:
> Actually, with 802.15.4 Layer 1 fragmenting, the source device sends
> the destination device a message containing the Fragment Sequence
> Context Description which includes (among other information) the
> source and destination addresses and a 6-bit transaction identifier
> which uniquely defines this fragment sequence.  The destination
> device must ACK this message before the fragment sequence starts.
> After that ACK, the source sends the fragments that include the
> transaction identifier but not the source and destination addresses.
> Any device receiving a fragment checks to see if the transaction
> identifier belongs to that device, if it doesn’t, the fragment is
> discarded.  In summary, multiple fragment sequences will not get
> mixed up since the Fragment Sequence Context Description maps the
> transaction identifier to the source and destination addresses. 

That is only true if you have two nodes on the channel.

If node A sends fragment sequence context description IE and sets up
fragmentation context with node B with TID of 0x00, and at the same
time node C decides to send fragmented packet to node D, the node C
will send similar frame to setup the fragmentation context with D, but
as those fragment sequence context description IE frames do have
addressing fields, only the intended targets will see them, thus only
B receives the FSCD from A and only D receives it from C. Thus C does
not have any idea which TIDs are in use, and it might also pick TID of
0x00.

Then when A sends a fragment with TID of 0x00, and without addressing
fields, both B and D will receive it and they both think it belongs to
them.

Similar when C sends fragments with TID 0x00 both B and D receive it
and both will add it to their reassembly queue.

If security is enabled then the problem is not as bad, as the MIC-32
of the fragment is calculated using nonce, which includes the sender
extended address, thus MIC-32 will fail if the sender is not the one
device assumes it is, thus node B will only accept fragments from A,
and all fragments sent by the C will have invalid MIC-32, thus they
will fail the authentication and will be dropped. Similarly with node
D.

If no security is used then there is nothing protecting the fragments,
thus they will get mixed up. In LECIM this is not problem (at least
that was told to me), because there is only one sender in one channel,
thus the recipient can know that frame is from that sender by just
receiving it on that channel.

Of course the security of the fragments was broken in the 4k, and it
was fixed in the 802.15.4-2015 version. In 4k the fragment counters
and the frame counters could overlap, thus it could generate same
nonce twice in some cases (i.e. frame number 0x00000001, and fragment
0x01 of frame number 0x000000 had same nonce or so).
-- 
[e-mail]