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

["Pascal Thubert (pthubert)" <[e-mail]>]

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]<mailto:[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