Thank you very much Pascal for the fast response and explanations. Best,
Ines. On Tue, Nov 26, 2019 at 3:12 PM Pascal Thubert (pthubert) < [email protected]> wrote: > Many thanks Ines! > > > Questions: > > > > 1- In Section 1 that list the components of the reassembly buffer in > node B, > > should it contains the datagram_offset as well? > > Well each fragment has a offset and a length but there's only one datagram > size. Fragments are normally received in order but that's only a MUST for > the first fragment. So say fragments are received in any order. You'd need > to remember all the offsets. Whether the fragments are kept as received > with their meta including the offset or just pasted at the right place is > implementation dependent. > > > > > 2- In Section 1, where states: "...the actual packet data from the > fragments > > received so far, in a form that makes it possible to detect...", I think > it might be > > nice to add an example referring in which form, I mean: "...in a form > (e.g. ....) > > that makes it possible....", what do you think? > > > If an implementation wishes to check that it gets is all and that's > there's no overlap it can remember all the offsets and sizes. Or make a > linked list of the fragments as received. Or paste in a space that is big > enough and in a way that allows to scan for gaps. But we do not mandate > exactly if and how that's done. If we indicate one we seem to favor it and > I'm concerned that people would come up with a better idea and complain. > This is an internal of the implementation after all. > > > 3- draft-ietf-intarea-frag-fragile-17, section 3.7 states some security > > vulnerabilities for IP fragmentation (The mentioned document as well > defines > > virtual reassembly). Do you think that some of these vulnerabilities can > be > > applied to 6LOWPAN fragments? For example, attacks based on predictable > > 6LOWPAN fragment identification values. > > You're certainly right, Ines. Let me visit that and come back with an > update. > > All the best; > > Pascal >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
