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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 21 June 2019 15:06 UTC

Return-Path: <pthubert@cisco.com>
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 D6765120114 for <6lo@ietfa.amsl.com>; Fri, 21 Jun 2019 08:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=T9c8m7bo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=h7yo8/vR
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 81-OHyYjAROt for <6lo@ietfa.amsl.com>; Fri, 21 Jun 2019 08:06:06 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD0C120071 for <6lo@ietf.org>; Fri, 21 Jun 2019 08:06:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4524; q=dns/txt; s=iport; t=1561129566; x=1562339166; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=02q5IvVakst16n/wiU5ZGFeCEnNaqnte4FBMpbDNDQ0=; b=T9c8m7bojDSvaO7+H0yTC71I2pnPoGKCw9d4ACdXxohMg5LsaCA09Vs8 MM9yY6Iy7/R4tScsAqzfqw17w4vtFbfBfQcw/txozJPSx92oSkv/wxXEq Nvx1Slb6nJXljnlqeKwxwTV1mrGkgkJnNNltv2HVNRSuRZ92Vrb+l89CZ 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3Apy1p+BR/qIUHrT0WDEhC7U9iRNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAADs8Qxd/5ldJa1bCg4OAQEBBAE?= =?us-ascii?q?BBwQBAYFTBwEBCwGBQyQsA4E/IAQLKAqEDINHA4RSig+CW5c4gS6BJANUCQE?= =?us-ascii?q?BAQwBAS0CAQGEQAIXgkcjNAkOAQMBAQQBAQIBBW2KNwyFSgEBAQECARIREQw?= =?us-ascii?q?BASUSAQQLAgEIGgImAgICMBUQAgQBDQ0ahGsDDg8BApxtAoE4iF9xgTGCeQE?= =?us-ascii?q?BBYR9GIIRCYEMKAGEcIQkgkkXgUA/gVeCFzU+hBkFKIMIMoImjkqaVWUJAoI?= =?us-ascii?q?Siy6IToIohwyKDIQGjSWWfwIEAgQFAg4BAQWBUDiBWHAVgyeCQYNwihg7coE?= =?us-ascii?q?pjByBMAGBIAEB?=
X-IronPort-AV: E=Sophos;i="5.63,400,1557187200"; d="scan'208";a="359309968"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Jun 2019 15:06:04 +0000
Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5LF633W014608 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 21 Jun 2019 15:06:03 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Jun 2019 10:06:02 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Jun 2019 10:06:02 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 21 Jun 2019 11:06:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=02q5IvVakst16n/wiU5ZGFeCEnNaqnte4FBMpbDNDQ0=; b=h7yo8/vReKKO0qpCXaPpMRiCeZQaBo3OQIRADTvlcf8Uw+6dPS1FwLlkJCI5XB/vVvUHMvObxJ5HaiDCWHNlni/3mz5oq/K5uCdQn0GkaqgmT0n1QLQFSaxXaNP1YWkeDhaMl1emtTr1byMF3zMk7LerS7dCUiB+A26UJVKduXw=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4189.namprd11.prod.outlook.com (20.179.150.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 21 Jun 2019 15:06:01 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::7cc2:b440:8820:f0fc%7]) with mapi id 15.20.1987.014; Fri, 21 Jun 2019 15:06:01 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Georgios PAPADOPOULOS <georgios.papadopoulos@imt-atlantique.fr>, "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: WG Last Call: draft-ietf-6lo-minimal-fragment-01
Thread-Index: AQHU/168hdAKQy/jE0yJdjbd+0w1LaamfyrQ
Date: Fri, 21 Jun 2019 15:05:44 +0000
Deferred-Delivery: Fri, 21 Jun 2019 15:04:46 +0000
Message-ID: <MN2PR11MB3565DD57331E96E45634817FD8E70@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <3821d72b6775aa954dec6f8bbb3723f8.squirrel@webmail.entel.upc.edu> <40213847.7967367.1556633374177.JavaMail.zimbra@imt-atlantique.fr>
In-Reply-To: <40213847.7967367.1556633374177.JavaMail.zimbra@imt-atlantique.fr>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [173.38.220.33]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 17c66817-c230-4e7e-d477-08d6f659f94b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4189;
x-ms-traffictypediagnostic: MN2PR11MB4189:
x-microsoft-antispam-prvs: <MN2PR11MB4189AF849C05E0C535D3B631D8E70@MN2PR11MB4189.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0075CB064E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(396003)(346002)(376002)(199004)(189003)(256004)(305945005)(7736002)(186003)(26005)(99286004)(81156014)(81166006)(7696005)(8936002)(8676002)(33656002)(102836004)(76176011)(6506007)(229853002)(476003)(478600001)(14444005)(446003)(11346002)(74316002)(486006)(6116002)(6436002)(66066001)(3846002)(52536014)(71200400001)(5660300002)(71190400001)(53936002)(2171002)(4326008)(6666004)(55016002)(110136005)(6246003)(25786009)(9686003)(14454004)(86362001)(73956011)(66556008)(64756008)(66446008)(66476007)(76116006)(2906002)(68736007)(66946007)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4189; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: NJxS3sHskxEU6kq5RLjJOvQWEXVUpED4yjHRUuHBiXQw4LjMjoi8lKUUspIuy4z5F7vIXwos2rliHb7WydEPtsbaKtzkla78HW+FKRsVVwxVyAkF3U1v626WjuCTMmIfB6Nguqc8Vooxgld3EzE7VAXCkn9ez0x+clnb6SXZy8KG3WTocLYJtl2gOI8lDgjpW9E+vHtVD+9HgnF1IG1FFwYq5C0dMKMQmamHO7AiklGOP0f79CyJeSftup2iazD17vP+Msdtl+1IMuaChNMWw8PgSOInd44t+8CXvf7S22PmMnpCOqRxYa9HciuKnAEnYuhHzjIBs4N9O2w1tDq+zQkKDbBc14Q2OvzTWEehbLkmRtgfQum+rqb4wq07XuZt4N+UkG/g+6YSXEg07JIHLtG4cSIOM3pqFnJ9w8UfHfM=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 17c66817-c230-4e7e-d477-08d6f659f94b
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2019 15:06:01.1913 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4189
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/IpjKsc2TM2ehAZWIJo8rKPJGDqI>
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:06:10 -0000

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.
 
 


>    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.
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.
 





> 
>    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.
"


> 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