Re: [6lo] Fragment recovery, shepherd writeup: one minor point

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 21 October 2019 08:52 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 8DC22120154 for <6lo@ietfa.amsl.com>; Mon, 21 Oct 2019 01:52:38 -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=es4O/KKY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=omtmx6Yg
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 vqF0Ou9P9Y_g for <6lo@ietfa.amsl.com>; Mon, 21 Oct 2019 01:52:36 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D3312008A for <6lo@ietf.org>; Mon, 21 Oct 2019 01:52:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3874; q=dns/txt; s=iport; t=1571647956; x=1572857556; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bxpt7bQbkqf/8FElArvNq1GvXmkSdRetaRU2A4Wrspw=; b=es4O/KKYVJECHkVHI07BH81KMbCocuyKSJdLxnC3X00FtefYfVaIe114 0C0isiPNLt+fBF+DlaKsFl4/KLUcG2L4YFfWnjBJ/NbV5bjB3W5q58Lf5 mHOG+myKrTvAyGQFblc7i6YEYUVTETftpcebuZvHNtVsa6Bg2CQuH+oVF A=;
IronPort-PHdr: =?us-ascii?q?9a23=3AxDGnyB1qbbjCUrPhsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAACHcK1d/4oNJK1lDgwBAQEBAQE?= =?us-ascii?q?BAQEDAQEBAREBAQECAgEBAQGBagIBAQEBCwGBSlAFgUMgBAsqh20DilWCXJg?= =?us-ascii?q?CglIDVAkBAQEMAQEtAgEBhEACgxUkNwYOAgMJAQEEAQEBAgEFBG2FLQyFSwE?= =?us-ascii?q?BAQEDEigGAQE3AQsEAgEIEQQBAR8QMh0IAgQBDQUIGoVHAy4BAqMgAoE4iGG?= =?us-ascii?q?CJ4J+AQEFhQsYghcJgTYBhRWEMIJJGIFAP4ERRoJMPoRHg0CCLIlIlRqOC24?= =?us-ascii?q?KgiSQRYR8mUyONZlGAgQCBAUCDgEBBYFoI4FYcBWDJ1AQFIFQg3OKGDt0gSm?= =?us-ascii?q?PHAEB?=
X-IronPort-AV: E=Sophos;i="5.67,323,1566864000"; d="scan'208";a="354549650"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Oct 2019 08:52:35 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x9L8qYWA010971 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Oct 2019 08:52:34 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 21 Oct 2019 03:52:34 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 21 Oct 2019 04:52:33 -0400
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 21 Oct 2019 04:52:33 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kHCO90TKTZRcZwwFQ1cpzLatccRZe6/8fHHqmcgdc1m9Slr9XwUGtKCd1qJXqqmN2JHmeJWEjKz7yXKlOMGr5PmxAkSdU0v7tu4hotREUjueAwH2pwzPF1BgiupKzINdH2BFvVRpYEt8vdWUDNbNMbj74m1xpLpq7myBF2n2CrNy/DUyeDj84a6G7O71oAURXxviOd4NWFFcIKj4nLsDVm7rjSLrd2sm6HuBXdLZ1PBDgJ5Tmi2wALk3LOw9cLwu+9oHD/ceYQx1FPW5hp4Ns5xf0Z+/sRtNfWyRmdFeJwXocDVFbllkeUyOreoLgjw0zWEnESNP1sJgDwe8zThB7w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M28K2RsyF+LeUvO/Z6XCp8S+ZEXEO4k6CBz+L0jzSHc=; b=dGU/PITtiVL5WHM2Rxv4+dKKlOj7q7V47wV/Pu0tMXxdgsUCaKiaAu5tyZB+WCY9vnV1BoqbyuZof9XlTuylqu4AZXH5NQz8t6uudjikTZqgLqC5bwH/NUQ/01gyulHzOAliFbYnLd3w+bc4mF7RoZwtEJtcKIp8FUOQ6ypUd7PK2w0FLNxB6kHM7bJjz5BHaCmCE1YUMnX7akGgHb6Jo3OOdjv7dRhauqyntxjOC24WWRZ+Pd3gI/jHotgSBI5+Cy+s24H1IXMJOEny5WfoKsBocCdDMT5xSBMvPP/d0sM9A/2VS/2Aj/KQbeZRlhLpL1venrBiepkoZzO6CAwUug==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
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=M28K2RsyF+LeUvO/Z6XCp8S+ZEXEO4k6CBz+L0jzSHc=; b=omtmx6YgrkdSJrVwCEuMyaa11Gcbdc8BFs8oO2mXiCE+O63xp0hLlQXi9h7vo+OM6uUSf/tzhZ8wqOz0rrWEmGKz0JrW/EASkBvDP+2/tTt9BHHxDJASAhgVKErLIJVSPgLXPmyfp5YMNkvHiECyobyf2cVh4IsiyfkQVWsDCvA=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4160.namprd11.prod.outlook.com (20.179.151.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.18; Mon, 21 Oct 2019 08:52:31 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920%6]) with mapi id 15.20.2347.028; Mon, 21 Oct 2019 08:52:31 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carles Gomez Montenegro <carlesgo@entel.upc.edu>, "Suresh@kaloom.com" <Suresh@kaloom.com>
CC: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Fragment recovery, shepherd writeup: one minor point
Thread-Index: AQHVh1k4ThzYzx3X40+MAt1KMJdmf6dkv1dg
Date: Mon, 21 Oct 2019 08:52:29 +0000
Deferred-Delivery: Mon, 21 Oct 2019 08:51:53 +0000
Message-ID: <MN2PR11MB356574D0A2B2992A5948146ED8690@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <0cf67636415db934b7b49ed02ee85887.squirrel@webmail.entel.upc.edu>
In-Reply-To: <0cf67636415db934b7b49ed02ee85887.squirrel@webmail.entel.upc.edu>
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: [2001:420:44f3:1300:fc9e:730:2c16:4060]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 897377d4-6c78-4ac8-ac98-08d75604026f
x-ms-traffictypediagnostic: MN2PR11MB4160:
x-microsoft-antispam-prvs: <MN2PR11MB4160CD403DC6B605898BEBC4D8690@MN2PR11MB4160.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0197AFBD92
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(346002)(366004)(396003)(13464003)(199004)(189003)(486006)(74316002)(102836004)(86362001)(25786009)(446003)(11346002)(53546011)(476003)(6116002)(6506007)(7736002)(186003)(305945005)(2906002)(2171002)(8676002)(229853002)(99286004)(4326008)(6436002)(7696005)(46003)(561944003)(76176011)(9686003)(81156014)(81166006)(14454004)(478600001)(6246003)(55016002)(2501003)(8936002)(316002)(66556008)(66476007)(64756008)(66946007)(52536014)(33656002)(5660300002)(110136005)(14444005)(71200400001)(71190400001)(256004)(66446008)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4160; 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: BCL:0;
x-microsoft-antispam-message-info: thIqO3NZwMi1McSsrP7jKsYNOn+67lS4FkgxCNJy9QDJ7sLNo/Dsn6vrmsMx4AZaw/EtfHHSj4twF4F3P4YxRcWursOKGJkbSKH+Bw947RYQlcgtnGiqX9nC6sInwWK0vlyTnzsN2lyUlr8gLpKssX9GdyHmZ37aDzQMlIab9KIys6aMxoOO6lxvfxbQFvAZlft7ZE0eiNZTS8j5O6FV5Ek8Fi5jJlQ7tPUN/2o1XEXmVUj72E5PG2YLqmEfzIOS6JuDVn2ls+YXWH9kzkw69rjF2vgf/GHFVFKl5ZPV2bZTqCrS5welmmjZ3yG4ACOa+xT0WVaHYk5IZxedzEtQpcOazmxs40aJyUFMRyHVlSZRs7t/g/+ASAV2R8Q2ysvfqhuspHlI9+0OSL2vnFpt2OA8r1wzH+uHRiv+/Cxqhwo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 897377d4-6c78-4ac8-ac98-08d75604026f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2019 08:52:31.5036 (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: tPn2WO/HdY44kEquS9SoB2jEMZ8isS3ddIMb6br41U0XJzNWPRuKdMaVCR8yaVOhez9d7YL96P/RQEfmM7poTQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4160
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/DuSYmtjdHD4kvB_lFAC7bgWGpIg>
Subject: Re: [6lo] Fragment recovery, shepherd writeup: one minor point
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: Mon, 21 Oct 2019 08:52:39 -0000

I see your point Carles.

You'll note that the abstract reference is minimal and that the LWIG draft is an implementation technique. There might be others. The ref that you indicate shows that we ARE NOT doing what the LWIG draft says. 

STD track RFC do not generally dictate implementation and do not discuss internals beyond an abstract view. We're on the way to get a number of DISCUSS'es during IESG review. Same as the ref to the minimal fragment I think we could really use Suresh's advice.

If it's just me I'd rather not make the proposed change but rather move the lwig draft to the informational references and make the following change:


Current 
   
   The technique of Virtual Recovery Buffers inherited from
   [I-D.ietf-6lo-minimal-fragment] may be used to perform a Denial-of-
   Service (DoS) attack against the intermediate Routers since the
   routers need to maintain a state per flow.  Note that as opposed to
   the VRB described in [I-D.ietf-lwig-6lowpan-virtual-reassembly] the
   data that is transported in each fragment is conserved and the state
   to keep does not include any data that would not fit in the previous
   fragment.


New

   The technique of Virtual Recovery Buffers inherited from
   [I-D.ietf-6lo-minimal-fragment] may be used to perform a Denial-of-
   Service (DoS) attack against the intermediate Routers since the
   routers need to maintain a state per flow.  The VRB implementation 
   technique described in [I-D.ietf-lwig-6lowpan-virtual-reassembly] 
   allows to realign which data goes in which fragment which causes
   the intermediate node to store a portion of the data, which adds an
   attack vector, which is not present with this draft.  With this draft, the
   data that is transported in each fragment is conserved and the state
   to keep does not include any data that would not fit in the previous
   fragment.


What do you think?

Pascal

-----Original Message-----
From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>; 
Sent: dimanche 20 octobre 2019 17:15
To: Pascal Thubert (pthubert) <pthubert@cisco.com>;
Cc: 6lo@ietf.org
Subject: Fragment recovery, shepherd writeup: one minor point

Hello Pascal,

While preparing my shepherd write-up for the 6lo fragment recovery draft,  I noticed one minor detail that I would like to bring to your attention.

In -05, draft-ietf-lwig-6lowpan-virtual-reassembly was added as a reference. I think it is a bit odd that this document is mentioned for the first time only at the end of the Security considerations section (note that this reference is in fact a normative reference).

My proposal is updating the second paragraph of Section 1, and the last paragraph of Section 2.4, so that draft-ietf-lwig-6lowpan-virtual-reassembly is also introduced there.

For example, for Section 2.4, it could be something along the lines of:

CURRENT:
   "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
   introduces the concept of a Virtual Reassembly Buffer (VRB) and an
   associated technique to forward fragments as they come, using the
   datagram_tag as a label in a fashion similar to MPLS.  This
   specification reuses that technique with slightly modified controls.

NEW:
   "LLN Minimal Fragment Forwarding" [I-D.ietf-6lo-minimal-fragment]
   introduces the concept of a Virtual Reassembly Buffer (VRB) and an
   associated technique to forward fragments as they come, using the
   datagram_tag as a label in a fashion similar to MPLS. The technique is
   described in [I-D.ietf-lwig-6lowpan-virtual-reassembly].  This
   specification reuses that technique with slightly modified controls.

... and something similar might work also for Section 1.

What do you think?

Thanks,

Carles (as the document shepherd)