Subject: [6lo] Fragment recovery, shepherd writeup: one minor point

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Sun, 20 Oct 2019 17:14:59 +0200

Hello Pascal,

While preparing my shepherd write-up for the 6lo fragment recovery draft, 
 I noticed one minor detail that I would like to bring to your attention.

In -05, draft-ietf-lwig-6lowpan-virtual-reassembly was added as a
reference. I think it is a bit odd that this document is mentioned for the
first time only at the end of the Security considerations section (note
that this reference is in fact a normative reference).

My proposal is updating the second paragraph of Section 1, and the last
paragraph of Section 2.4, so that
draft-ietf-lwig-6lowpan-virtual-reassembly is also introduced there.

For example, for Section 2.4, it could be something along the lines of:

CURRENT:
   "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
   introduces the concept of a Virtual Reassembly Buffer (VRB) and an
   associated technique to forward fragments as they come, using the
   datagram_tag as a label in a fashion similar to MPLS.  This
   specification reuses that technique with slightly modified controls.

NEW:
   "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
   introduces the concept of a Virtual Reassembly Buffer (VRB) and an
   associated technique to forward fragments as they come, using the
   datagram_tag as a label in a fashion similar to MPLS. The technique is
   described in [I-D.ietf-lwig-6lowpan-virtual-reassembly].  This
   specification reuses that technique with slightly modified controls.

... and something similar might work also for Section 1.

What do you think?

Thanks,

Carles (as the document shepherd)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Oct 2019 08:52:29 +0000

I see your point Carles.

You'll note that the abstract reference is minimal and that the LWIG draft is an implementation technique. There might be others. The ref that you indicate shows that we ARE NOT doing what the LWIG draft says. 

STD track RFC do not generally dictate implementation and do not discuss internals beyond an abstract view. We're on the way to get a number of DISCUSS'es during IESG review. Same as the ref to the minimal fragment I think we could really use Suresh's advice.

If it's just me I'd rather not make the proposed change but rather move the lwig draft to the informational references and make the following change:

Current 
   
   The technique of Virtual Recovery Buffers inherited from
   [I-D.ietf-6lo-minimal-fragment] may be used to perform a Denial-of-
   Service (DoS) attack against the intermediate Routers since the
   routers need to maintain a state per flow.  Note that as opposed to
   the VRB described in [I-D.ietf-lwig-6lowpan-virtual-reassembly] the
   data that is transported in each fragment is conserved and the state
   to keep does not include any data that would not fit in the previous
   fragment.

New

   The technique of Virtual Recovery Buffers inherited from
   [I-D.ietf-6lo-minimal-fragment] may be used to perform a Denial-of-
   Service (DoS) attack against the intermediate Routers since the
   routers need to maintain a state per flow.  The VRB implementation 
   technique described in [I-D.ietf-lwig-6lowpan-virtual-reassembly] 
   allows to realign which data goes in which fragment which causes
   the intermediate node to store a portion of the data, which adds an
   attack vector, which is not present with this draft.  With this draft, the
   data that is transported in each fragment is conserved and the state
   to keep does not include any data that would not fit in the previous
   fragment.

What do you think?

Pascal

-----Original Message-----
From: Carles Gomez Montenegro <[email-masked]> 
Sent: dimanche 20 octobre 2019 17:15
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Fragment recovery, shepherd writeup: one minor point

Hello Pascal,

While preparing my shepherd write-up for the 6lo fragment recovery draft,  I noticed one minor detail that I would like to bring to your attention.

In -05, draft-ietf-lwig-6lowpan-virtual-reassembly was added as a reference. I think it is a bit odd that this document is mentioned for the first time only at the end of the Security considerations section (note that this reference is in fact a normative reference).

My proposal is updating the second paragraph of Section 1, and the last paragraph of Section 2.4, so that draft-ietf-lwig-6lowpan-virtual-reassembly is also introduced there.

CURRENT:

NEW:

What do you think?

Thanks,

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Oct 2019 13:43:50 +0000

Dear Carles:

I pushed an 06 that passes the doc to xml2rfc v3, and moves the ref to the LWIG implementation to informational.
Please note that the main reason of the text about it is to indicate that it is non-compatible with this draft. 
For that reason it was actually strange to make it a normative reference, many thanks for spotting it..

All the best;

Pascal

-----Original Message-----
From: Carles Gomez Montenegro <[email-masked]> 
Sent: dimanche 20 octobre 2019 17:15
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: Fragment recovery, shepherd writeup: one minor point

Hello Pascal,

CURRENT:

NEW:

What do you think?

Thanks,

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 21 Oct 2019 15:53:17 +0200

Dear Pascal,

Thanks for the new draft version.

Your update looks good to me!

Cheers,

Carles

> .... and something similar might work also for Section 1.
>
> What do you think?
>
> Thanks,
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>