Sure Pascal, I will review the new version as well :) Thank you,
Ines. On Tue, Nov 26, 2019 at 3:58 PM Pascal Thubert (pthubert) < [email protected]> wrote: > Just published 05, Ines, to address your last point. Please see section 6 > on security. > > There’s also a bunch of new text that was discussed with Dave Thaler but > could not be uploaded during draft cutoff. > > Maybe you’d want to look at that text too? > > > > Pascal > > > > *From:* Ines Robles <[email protected]> > *Sent:* mardi 26 novembre 2019 14:28 > *To:* Pascal Thubert (pthubert) <[email protected]> > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* Re: Iotdir last call review of > draft-ietf-6lo-minimal-fragment-04 > > > > 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
