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

"Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr> Fri, 21 June 2019 15:12 UTC

Return-Path: <georgios.papadopoulos@imt-atlantique.fr>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1741202F7 for <6lo@ietfa.amsl.com>; Fri, 21 Jun 2019 08:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTLBnKN3oOPu for <6lo@ietfa.amsl.com>; Fri, 21 Jun 2019 08:12:29 -0700 (PDT)
Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F4A1202FB for <6lo@ietf.org>; Fri, 21 Jun 2019 08:12:29 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 84633822D5; Fri, 21 Jun 2019 17:12:26 +0200 (CEST)
Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id TNNQmPWiGYjJ; Fri, 21 Jun 2019 17:12:25 +0200 (CEST)
Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 6F49E822CE; Fri, 21 Jun 2019 17:12:25 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr 6F49E822CE
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1561129945; bh=dBi6d8pqEd3K71+hQfuy7Q88MQv/IQDwLt2oBs5v8SI=; h=Mime-Version:From:Date:Message-Id:To; b=h99Tm23Z/597YDQqOSoPa+WMqmarGauU9UmaJHmK3pSfJY/cOp/IV08iiQQGHnaUX KBrB4bMVStmSprv5HzGNzcuEJj+hLCgr7wVNmOZm6EUeZtCfBFzx6v7rP8sJD0LBPB LSOEaPz2ayUwCkNeAmlb+2RaYl/dVJKBL0CtZykM=
X-Virus-Scanned: amavisd-new at zproxy110.enst.fr
Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id qqRsPmzwCkI9; Fri, 21 Jun 2019 17:12:25 +0200 (CEST)
Received: from [IPv6:2001:660:7301:3728:8121:ac7a:a2f2:90fe] (unknown [IPv6:2001:660:7301:3728:8121:ac7a:a2f2:90fe]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 40D80822BB; Fri, 21 Jun 2019 17:12:25 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>
In-Reply-To: <MN2PR11MB3565DD57331E96E45634817FD8E70@MN2PR11MB3565.namprd11.prod.outlook.com>
Date: Fri, 21 Jun 2019 17:14:46 +0200
Cc: Carles Gomez Montenegro <carlesgo@entel.upc.edu>, "6lo@ietf.org" <6lo@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A7D5C46-5336-4BB5-A29B-77E0E1D29A54@imt-atlantique.fr>
References: <3821d72b6775aa954dec6f8bbb3723f8.squirrel@webmail.entel.upc.edu> <40213847.7967367.1556633374177.JavaMail.zimbra@imt-atlantique.fr> <MN2PR11MB3565DD57331E96E45634817FD8E70@MN2PR11MB3565.namprd11.prod.outlook.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/BBRp14B_64N-rk5V2pYKMeu0BbI>
Subject: Re: [6lo] WG Last Call: draft-ietf-6lo-minimal-fragment-01
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2019 15:12:33 -0000

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