Re: [6lo] WG Last Call: draft-ietf-6lo-minimal-fragment-01

Dear Pascal,

Many thanks for your feedbacks! 

Best,
Giorgos

> On Jun 21, 2019, at 17:05, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> Hello Georgios
> 
> Many thanks for your review, please see below:
> 
>>   In Figure 1, a packet forwarded by node A to node B is cut into nine
>>   fragments, numbered 1 to 9.  Each fragment is represented by the '#'
>>   symbol.  Node A has sent fragments 1, 2, 3, 5, 6 to node B.  Node B
>>   has received fragments 1, 2, 3, 6 from node A.  Fragment 5 is still
>>   being transmitted at the link layer from node A to node B.
>> 
>> 
>> [GP] Isn’t it more straightforward to consider 1, 2, 3 and 4 been sent,
>> 5 is still being transmitted, while, 6, 7, 8 and 9 to be transmitted?
>> Otherwise, there are concerns, why fragments 5 and 6 before 4?
>> Fragment 4 was transmitted earlier and was not successful?
> 
> I guess it's an implementation thing. It is possible that a retry is queued at the top of the xmit queue and that the next fragment is already there now.
> The first fragment must be successfully transmitted first, because the next hop would not know what to do with a non-first fragment arriving first. I added a word on that in the limitations.
> All the other fragments could be sent in any order.

I see the scenario. Thx.

> 
>>   A fragmentation header is added to each fragment; it indicates what
>>   portion of the packet that fragment corresponds to.  Section 5.3 of
>>   [RFC4944] defines the format of the header for the first and
>>   subsequent fragments.  All fragments are tagged with a 16-bit
>>   "datagram_tag", used to identify which packet each fragment belongs
>>   to.  Each fragment can be uniquely identified by the source and
>>   destination link-layer addresses of the frame that carries it, and
>>   the datagram_tag.
>> 
>> [GP] This is not entirely true, right? This is yet, another limitation
>> of RFC 4944. There is no guarantee that two different source nodes
>> (A and B) may pick up the same “datagram_tag”, and send their
>> fragments to C, and then C when sending to D, will have two fragments
>> with same tags, and the same source and destination link-layer addresses.
> 
> But then with RFC 4944 there is no relaying fragment so there is no point in RFC 4944 to consider that case.

True!

> The rule above is correct and the reason we swap the tag in node C is to keep it true so we do not end up in the situation that you describe.

Correct, thx.

>> 
>>   VRB overcomes the limits listed in Section 2.  Nodes don't
>> 
>> [GP] don’t —> do not
> 
> done
> 
> 
>>   No Per-Fragment Routing:  All subsequent fragments follow the same
>>       sequence of hops from the source to the destination node as
>>       fragment 1.
>> 
>> [GP] Maybe a clarification could be added in the last limit, i.e., that
>> only the fragment 1 has the sources and destination addresses.
> 
> Proposed to change to
> "
> No Per-Fragment Routing:  All subsequent fragments follow the same
>    sequence of hops from the source to the destination node as the
>    first fragment, because the IP header is required to route the
>    fragment and is only present in the first fragment. A side effect 
>    is that the first fragment must always be forwarded first.
> “

Seems good to me.

> 
>> 4.  Security Considerations
>> 
>>   An attacker can perform a DoS attack on a node implementing VRB by
>> 
>> [GP] DoS is not defined earlier
> 
> Added
> 
> 
> Again, many thanks Georgios.
> 
> All the best,
> 
> Pascal
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo