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

From: Ines Robles via Datatracker <[email-masked]>
Date: Tue, 26 Nov 2019 04:28:08 -0800

Reviewer: Ines Robles
Review result: Ready

Document: draft-ietf-6lo-minimal-fragment-04
Review result: Ready
Review type: iotdir - Last Call review
Requested version for review: Current
Review Date: 2019-11-26
Reviewer: Ines Robles

Summary:

I believe the draft is technically good. This document is well written.

The document proposes a method to forwarding 6LoWPAN fragments in which a
forwarder do not to have to reassemble each packet in its entirety before
forwarding it, using the virtual Reassembly Buffer (VRB) implementation
technique. VRB overcomes the limits of doing per-hop fragmentation and
reassembly, such as Latency and Memory Management and Reliability. However, VRB
presents limits such as Non-zero Packet Drop Probability, No Fragment Recovery
and No Per-Fragment Routing.

I have few questions formulated at the end.

Major issues:Not Issues found

Minor issues: Not Issues found

Nits/editorial comments: Not Issues found

Questions:

1- In Section 1 that list the components of the reassembly buffer in node B,
should it contains the datagram_offset as well?

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?

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.

Thank you for this document,

Ines.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Nov 2019 13:11:50 +0000

Many thanks Ines!

> 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. 

> 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.

> 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

---

From: Ines Robles <[email-masked]>
Date: Tue, 26 Nov 2019 15:27:49 +0200

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-masked]> wrote:

> 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.
>
> >
> 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.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Nov 2019 13:57:51 +0000

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-masked]>
Sent: mardi 26 novembre 2019 14:28
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Iotdir last call review of draft-ietf-6lo-minimal-fragment-04

Best,

Ines.

On Tue, Nov 26, 2019 at 3:12 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Many thanks Ines!

All the best;

Pascal

---

From: Ines Robles <[email-masked]>
Date: Tue, 26 Nov 2019 17:07:29 +0200

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-masked]> wrote:

> There’s also a bunch of new text that was discussed with Dave Thaler but
> could not be uploaded during draft cutoff.
>
> *From:* Ines Robles <[email-masked]>
> *Sent:* mardi 26 novembre 2019 14:28
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: Iotdir last call review of
> draft-ietf-6lo-minimal-fragment-04
>
>
>