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

[Tero Kivinen <[e-mail]>]

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]