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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
