Re: [Last-Call] Iotdir last call review of draft-ietf-6lo-minimal-fragment-04

[Ines Robles <[e-mail]>]

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) <
[e-mail]> 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 <[e-mail]>
> *Sent:* mardi 26 novembre 2019 14:28
> *To:* Pascal Thubert (pthubert) <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *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) <
> [e-mail]> 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
>
>