Re: [6lo] Iotdir last call review of draft-ietf-6lo-fragment-recovery-07

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

Hello Erik

Many thanks for your in-depth review!

Let's see below:

> Section 4.3 seems to silently assume that all fragments of a datagram go
> through the same intermediate hops. This should at a minimum be made
> explicit.

This is in fact inherited from the parent https://www.ietf.org/id/draft-ietf-6lo-minimal-fragment-05.html 

Minimal says:
   "The routing decision is made
   on the first fragment, which has all the IPv6 routing information.
   The first fragment is forwarded immediately and a state is stored to
   enable forwarding the next fragments along the same path."
A lot other things are inherited as well.

Suggestion is to make a small paragraph that summarizes it in the intro and point at minimal.
What about:

"

   [I-D.ietf-6lo-minimal-fragment] specifies the general behavior that
   all FF techniques including this specification follow, and presents
   the associated caveats.  In particular, the routing information is
   fully indicated in the first fragment, which is always forwarded
   first.  A state is formed and used to forward all the next fragments
   along the same path.  The datagram_tag is locally significant to the
   Layer-2 source of the packet and is swapped at each hop.

"

> But does the intended deployments satisfy such an assumption?

Note that the term "path" is really vague. Thinking RAW for a minute, you'll see that as long as the first fragment flows a RAW diverse path, then the following fragments can use any subset of that path. 
I can add a section like

"
6.4.  Applying Recoverable Fragmentation along a Diverse Path

   The text above can be read with the assumption of a serial path
   between a source and a destination.  Section 4.5.3 of the "6TiSCH
   Architecture" [I-D.ietf-6tisch-architecture] defines the concept of a
   Track that can be a complex path between a source and a destination
   with Packet ARQ, Replication, Elimination and Overhearing (PAREO)
   along the Track.  This specification can be used along any subset of
   the complex Track where the first fragment is flooded.  The last
   RFRAG Acknowledgment is flooded on that same subset in the reverse
   direction.  Intermediate RFRAG Acknowledgments can be flooded on any
   sub-subset of that reverse subset that reach back to the source.
"

> Drawing in section 5.1 shows an 8 byte datagram_tag but the text says it is 16
> bits. That's inconsitent.

Fixed. The format changed and I missed this.

> 
> I'd like to understand the issues and protection against reuse of the
> datagram_tag. Since this is rewritten on each hop and the hops can be routers
> forwarding at high rate, even 16 bits can cycle very quickly.

This format is for LoWPANs. The assumption is that a node can hold only a few packets in memory. The FF allows to forward more than that but there's still a limit.
The datagram_tag is allocated by each node when it forwards a new fragment. I can add text that if all 256 are already in use the intermediate node needs to reject the next packet or abort an existing session in both directions.
Proposal: add the case explicitely in the following text that was mostly preexisting:

"

   The other way around, the receiver might need to abort the process of
   a fragmented packet for internal reasons, for instance if it is out
   of reassembly buffers, already uses all 256 possible values of the
   datagram_tag, or if it keeps receiving fragments beyond a reasonable
   time while it considers that this packet is already fully reassembled
   and was passed to the upper layer.  In that case, the receiver SHOULD
   indicate so to the sender with a NULL bitmap in a RFRAG
   Acknowledgment.  The RFRAG Acknowledgment is frowarded all the way
   back to the source of the packet and cleans up all resources on the
   way.  Upon an acknowledgment with a NULL bitmap, the sender endpoint
   MUST abort the transmission of the fragmented datagram with one
   exception: In the particular case of the first fragment, it MAY
   decide to retry via an alternate next hop instead.
"

Also in the security section:

"
The process of recovering fragments does not appear to create any
   opening for new threat compared to "Transmission of IPv6 Packets over
   IEEE 802.15.4 Networks" [RFC4944] beyond the change of size of the
   datagram_tag.  By reducing to 8 bits, the tag will wrap faster than
   with [RFC4944].  But for a constrained network where a node is
   expected to be able to hold only one or a few large packets in
   memory, 256 is still a large number.  Also, the acknowledgement
   mechanism allows ot clean up the state rapidly once the packet is
   fully transmitted or aborted.

"

> 
> The document should presumably specify how the receiver knows it has
> received all the fragments in 6.0; as I understand the sequence number can

Added:
"
   [I-D.ietf-6lo-minimal-fragment] indicates that the receiving endpoint
   stores "the actual packet data from the fragments received so far, in
   a form that makes it possible to detect when the whole packet has
   been received and can be processed or forwarded".  How this is
   computed in implementation specific but relies on receiving all the
   bytes up to the datagram_size indicated in the first fragment.  An
   implementation may receive overlapping fragments as the result of
   retries after an MTU change.
"

> not be used for this but instead the receiver needs to check that it has
> received every byte offset from zero to datagram_size at least once. (The
> refragmenting due to MTU changes makes this complex.) Question: If the
> receiver has already received from byte range once and receives a subset of
> that range again (due to a retransmission after MTU change) is the receiver
> supposed to do something to compare the content being the same for the
> repeated byte range?

Yes this could happen in theory. This has security implications. In particular rewriting data in the first fragment may alter the IP or transport headers. 
But then as discussed in the minimal fragment, the FF is not end to end and a firewall is expected to operate in the reassembled packet, so there's little value rewriting.
I modified the security section as follows:

"
8.  Security Considerations

   The considerations in the Security sections of [I-D.ietf-core-cocoa]
   and [I-D.ietf-6lo-minimal-fragment] apply equally to this
   specification.
"

To reflect the discussion on overlapping fragments therein.


> 
> Note that for IP fragmentation we have determined that overlapping
> fragments can be used to fool firewalls. I don't know to what extent that is an
> issue for this fragmentation. Perhaps that should be mentioned in the security
> considerations section?

Yes, I did that in the minimal and now inherit it by reference. My take is that in this case this is not such an issue since the fragmentation is not end to end and probably the firewall operates on the reassembled packet not the 6lowpan fragments.

> 
> Section 6.1.1 seems to make the assumption that a packet with sequence zero
> is only transmitted once, hence I don't understand how this will work when it
> is lost and then retransmitted by the sender.
> 

Suggestion to add at the end of 6.1.1:
"
   The first fragment may be received a second time, indicating that it
   did not reach the destination and was retried.  In that case, it
   SHOULD follow the same path as the first occurrence.  It is up to
   sending endpoint to abort a transmission and then retry it from
   scratch, which may build an entirely new path.

"

> Nits:
> Section 2.3 defines 5 terms but all of "LLN" are unused. I suggest the unused
> terms be removed to avoid any confusion. Yet other terms like "LSP" are not
> defined.
> 

All Fixed : )

I published 08 with the above proposals. Please let me know if that addresses the issues or if we need more work.

Again; many thanks Erik!

Pascal