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). -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
