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

From: Dave Thaler via Datatracker <[email-masked]>
Date: Wed, 06 Nov 2019 15:09:56 -0800

Reviewer: Dave Thaler
Review result: Ready with Issues

The title implies the document specifies a forwarding mechanism, but it does
not, it merely provides discussion of two mechanisms in other docs (RFC 4944
and draft-ietf-lwig-6lowpan-virtual-reassembly). I would recommend at least
changing the title to be more clear as to the purpose of the doc.

Technical confusion
-------------------
1) Page 3 says the reassembly buffer contains "the link-layer address that node
B uses to forward the
   fragments".  I cannot tell whether this is referring to B's link-layer
   address that it received the fragment on, or B's link-layer address that it
   uses as a source link-layer address for forwarding it on, or the link-layer
   address of the next hop to which B forwards.

2) Page 3 also says the reassembly buffer contains "the link-layer address of
the next hop that is resolved
   on the first fragment".  I found this similarly confusing.  What does it
   mean to resolve something "on" the first fragment?  Does it mean "during
   processing of the first fragment"?  Maybe I missed it, but I couldn't find
   in RFC 4944 anywhere that says that it would do next-hop resolution before
   the datagram can be reassembled.  That would seem like a waste, if the
   fragments are then discarded (e.g., due to timer expiry) without actually
   doing any forwarding.

3) Section 3 talks about "MAC address" specifically whereas section 1 always
talked about the more
   generic "link-layer address".  Why the inconsistency?

4) Section 3 talks about "a 1280-byte reassembly buffer for each packet", but
section 2.2 talks assumes
   a "1 kB reassembly buffer".  1k != 1280 bytes.  Why the inconsistency?

5) Section 3 explains that "the first fragment must always be forwarded first",
but does not explain
   what the behavior is if a fragment other than the first fragment is received
   before the first fragment. Figure 1 shows that the fragments can be received
   out of order, since there fragment 6 is received before 5, which is received
   before 4.   Presumably it is either queued or dropped.  If it's queued, then
   section 4 is insufficient, which talks about an attacker generating a large
   number of bogus "fragment 1" fragments, since if you queue the first
   fragment received even if it's not "fragment 1", then the same attack
   presumably exists, it's not specific to "fragment 1" packets.

Grammatical nits:
-----------------

Abstract has "... to forwarding ...", which should be "to forward" or "for
forwarding"

Abstract has "to the virtual Reassembly Buffer", which seems incorrect both in
terms of capitalization (since sectoin 3 has VRB) and grammar.  Suggest "to
using virtual reassembly buffers".

Section 1, first paragraph: "though possibly" is likely a typo for "through
possibly"

Section 1, 6th paragraph: "a same datagram" is oddly worded.  Suggest either "a
datagram" or "the same datagram"

Section 2.2, grammar issue in "Assuming 1 kB reassembly buffer".  Either
"buffers" plural or "Assuming a ..."

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 7 Nov 2019 11:23:17 +0000

Hello Dave

Many thanks for being so reactive 😊

Please see below

> -----Original Message-----
> From: Dave Thaler via Datatracker <[email-masked]>
> Sent: jeudi 7 novembre 2019 00:10
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Intdir last call review of draft-ietf-6lo-minimal-fragment-04
> 
> Reviewer: Dave Thaler

A suggestion would help : ) 

Does "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network" go the right way?

> 
> Technical confusion
> -------------------
> 1) Page 3 says the reassembly buffer contains "the link-layer address that
> node B uses to forward the

The latter. B needs to send all the fragments with the same source link-layer address because that's part of the index for the datagram in C. Proposed change:
"
the Link-Layer address that node B uses as source to forward the fragments

"

>    fragments are then discarded (e.g., due to timer expiry) without actually

RFC 4944 reassembles and then routes. We make the routing decision on the first fragment before we receive the second fragment, forward the first fragment and store that state. Unsure how to reword, your suggestion would be appreciated.

>    generic "link-layer address".  Why the inconsistency?

Fixed to "link-layer address" consistently.

>    a "1 kB reassembly buffer".  1k != 1280 bytes.  Why the inconsistency?

Fixed to
"                                                                           Assuming a reassembly buffer
   for a 6LoWPAN MTU of 1280 bytes as defined in section 4 of [6LoWPAN],
   typical nodes only have enough memory for 1-3 reassembly buffers.
"

>    presumably exists, it's not specific to "fragment 1" packets.

6LoWPAN does not mandate that all the fragments are sent in order, thus Fig1. But fragment 1 is sent first 
Quoting section 5.5 of Rfc 4944
"
                                                                   The first link fragment
   SHALL contain the first fragment header as defined below.

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 0 0 0|    datagram_size    |         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 4: First Fragment

   The second and subsequent link fragments (up to and including the
   last) SHALL contain a fragmentation header that conforms to the
   format shown below.

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1 1 1 0 0|    datagram_size    |         datagram_tag          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |datagram_offset|
      +-+-+-+-+-+-+-+-+

                      Figure 5: Subsequent Fragments
"

The first fragment is the one with the IPv6 address of the destination that enables to find the next hop that the other fragments will use. So it is always available before a fragment can be forwarded. So it is easy to mandate that we forward it first. 
If we do that then the only way for a next fragment to arrive first is that the first fragment was lost in the transmission by the previous node. The first fragment may be queued for retries in the previous hop but that's a really bad idea.

Proposal:

* we add text on the above to clarify
* we mandate that on a link with ARQ, the node only forwards a next fragment if the first was acknowledged.
* we clarify that a next fragment that is received with no state from a first fragment for that datagram should be dropped.

> Grammatical nits:

done
> using virtual reassembly buffers".

I think we meant to the VRB draft. Applied your recommendation in the meantime:
"
This method reduces the latency and increases end-to-end reliability in route-over forwarding.
It is the companion to using virtual reassembly buffers which is a pure implementation technique.

"
Does that read well?

> Section 1, first paragraph: "though possibly" is likely a typo for "through
Fixed

> Section 1, 6th paragraph: "a same datagram" is oddly worded.  Suggest either
> "a datagram" or "the same datagram"

Yes French uses "a" to mean like any old datagram but still the same one; fixed : )

> "buffers" plural or "Assuming a ..."

Fixed as discussed above

Many thanks Dave. I'll be waiting for you answer on the open issues above before publishing.

Take care

Pascal