Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-minimal-fragment-12: (with DISCUSS and COMMENT)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 23 March 2020 07:49 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 54D953A0894; Mon, 23 Mar 2020 00:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.601
X-Spam-Level:
X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=FVPqxB1h; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DeZIojG0
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 vC7NouWd4J3G; Mon, 23 Mar 2020 00:49:22 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435923A0891; Mon, 23 Mar 2020 00:49:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2558; q=dns/txt; s=iport; t=1584949762; x=1586159362; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=53ikVRNP2D/OnBB1ALkMLw9BybiEoqN6dfK1sg8c8hw=; b=FVPqxB1h7IpuSn9mj0Lz3i9ESvapzdQgmPp1ujTCUSj2V3mxIhOclchH dbddbhvD5AbiS+9rDde0TpGWw3uJYrl8L6FKGuhPi75uN6GZosrK94RV0 wdm40LWMnY5BHrpm6dkyGOHAiBD37EJKlertx0zsnEqrbnYwZshiaVrkG Y=;
IronPort-PHdr: =?us-ascii?q?9a23=3AtooiPBAbpURnfhzyJqfkUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D6DQCYaXhe/40NJK1cCg4QAQscgX2?= =?us-ascii?q?BUlAFgUQgBAsqh10DinCCX5gcglIDVAkBAQEMAQEtAgQBAYRFAoIkJDkFDQI?= =?us-ascii?q?DAQELAQEFAQEBAgEFBG2FVgyFYwEBAQECARIoBgEBNwEECwIBCDYFCzIlAgQ?= =?us-ascii?q?ODRqFUAMOIAGgXQKBOYhigieCfwEBBYUQGIIMCYE4hSCHDxqBQT+BEUeCTT6?= =?us-ascii?q?EHgQrg0GCLJA8oBUKgjyNMYlzm1mqfgIEAgQFAg4BAQWBaiGBWHAVgydQGA2?= =?us-ascii?q?OHQwXFYM7ihg9dIEpiyqCQwEB?=
X-IronPort-AV: E=Sophos;i="5.72,295,1580774400"; d="scan'208";a="736635756"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Mar 2020 07:49:20 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 02N7nKST014730 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 Mar 2020 07:49:20 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Mar 2020 02:49:19 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Mar 2020 03:49:18 -0400
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 23 Mar 2020 02:49:18 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DBWlp8Ha3Phhp+6JtSCfMQnhagMnEWuUrukZ3YvIMS5/J8qVfJDlQEcNraL2qb?= =?utf-8?q?/I9MohWz6Nj4nNpHpESUB5T+Clp7W4fYq95RH8hcuQK7FDpd76cpNy0uHZM+kCCpd?= =?utf-8?q?ZZS4OU4L7mc7tmrWOw66wBrW2Rt5AoVOLGdFE8oS4oVS2QZwRi4MLi1a01CIcdlOO?= =?utf-8?q?QHnfCuiABoK/3iykim9dqOEvjWPkToe3z3Zzg87mQ3Ey9S4Id3kX6J04ZbDQdKFFI?= =?utf-8?q?ZYbSj5XjTtlygv/j1cIIXeVDdxP+JQTzojI0O/GTwPSrIEV3hQygXvr6qlrmPoySf?= =?utf-8?q?FFjOISn4v9de0K4X3BJGA=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DG941wnh86KxwTI7+LOuMjL0P9RhJdEBxsbt31mq8Bp4=3D=3B_b=3DZ7NFie?= =?utf-8?q?iHQPIOa2Iaozyw4rm+pjmHu/S6DiAKhPV4L/e4qCo6luPK5H5dIJtiT5s6+n9wXVg?= =?utf-8?q?mm4Ia4U1DA44+kFi36aCIObUUtbxLG4bvxw4WvW00GP4Sa57CLhWCVhi2qD7IvqDJ?= =?utf-8?q?FWmuFTEPzwp/7ga8dO7BhE0bOzoCo/Ev6W2/1Ycfbk1JpUllG6J7epC6KDpBsCfGM?= =?utf-8?q?uLDqNjrDT/MNlyON6qqzbsALq6QkLdNQcauNd6WqUR7iesBeK87RjU6+AEv90w3Zx?= =?utf-8?q?Ws1Lk17lc8IwKmPDFG9Ikc8JhGqb9lOLE5yKCm22Vrl0IRkJKg/ki0/sFRdisl5sI?= =?utf-8?q?Ep7YxfdHNDg=3D=3D?=
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; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AM?= =?utf-8?q?essage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADC?= =?utf-8?q?heck=3B_bh=3DG941wnh86KxwTI7+LOuMjL0P9RhJdEBxsbt31mq8Bp4=3D=3B_b?= =?utf-8?q?=3DDeZIojG08MH/wtQKdF+HXnb8JUDcs89YKRzsPGRryh5c613BAd1lmENkcei3IP?= =?utf-8?q?XypH/Km55ZDKiPTjhmcBCepEarfg+yO+3lRr3bi7ve4HRHIG11EEP0ukMC1TK3zYX?= =?utf-8?q?OkW3pzu+IS1VQ4MEYAJ87toKaXX5hAqbo+9eY+m2houM=3D?=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB3853.namprd11.prod.outlook.com (2603:10b6:208:ea::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.22; Mon, 23 Mar 2020 07:49:17 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::113b:3127:ef12:ea7%7]) with mapi id 15.20.2835.021; Mon, 23 Mar 2020 07:49:17 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "carlesgo@entel.upc.edu" <carlesgo@entel.upc.edu>, "draft-ietf-6lo-minimal-fragment@ietf.org" <draft-ietf-6lo-minimal-fragment@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-minimal-fragment-12: (with DISCUSS and COMMENT)
Thread-Index: AQHV/9WvGAtSqpJOyEG7IegC943yL6hU5D6Q
Date: Mon, 23 Mar 2020 07:48:48 +0000
Deferred-Delivery: Mon, 23 Mar 2020 07:48:26 +0000
Message-ID: =?utf-8?q?=3CMN2PR11MB356520A915D9CB24704D5A86D8F00=40MN2PR11MB3?= =?utf-8?q?565=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
References: <158200315586.4970.7352556140284234422.idtracker@ietfa.amsl.com> =?utf-8?q?=3CMN2PR11MB3565B31565B3A19683651613D8E20=40MN2PR11MB3565=2Enampr?= =?utf-8?q?d11=2Eprod=2Eoutlook=2Ecom=3E?= <20200321230851.GY50174@kduck.mit.edu>
In-Reply-To: <20200321230851.GY50174@kduck.mit.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: [2a01:cb1d:4ec:2200:bd22:8c8b:66f:b58]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 116d18c5-ad7e-4ded-4bab-08d7cefeb0c3
x-ms-traffictypediagnostic: MN2PR11MB3853:
x-microsoft-antispam-prvs: =?utf-8?q?=3CMN2PR11MB3853D6901E3E7905ECA9C081D8F?= =?utf-8?q?00=40MN2PR11MB3853=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0351D213B3
x-forefront-antispam-report: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020=29=284636?= =?utf-8?b?MDA5KSgzNDYwMDIpKDM3NjAwMikoMzk2MDAzKSgxMzYwMDMpKDM2NjAwNCkoMzk4?= =?utf-8?q?60400002=29=28199004=29=2886362001=29=286916009=29=2852536014=29?= =?utf-8?q?=2866574012=29=28186003=29=2871200400001=29=289686003=29=28432600?= =?utf-8?b?OCkoNzY5NjAwNSkoNjUwNjAwNykoNTUwMTYwMDIpKDQ3ODYwMDAwMSkoNzYx?= =?utf-8?b?MTYwMDYpKDMzNjU2MDAyKSg4OTM2MDAyKSg4Njc2MDAyKSg4MTE1NjAxNCko?= =?utf-8?q?81166006=29=2866476007=29=2864756008=29=2866446008=29=282906002?= =?utf-8?b?KSgzMTYwMDIpKDU2NjAzMDAwMDIpKDY2NTU2MDA4KSg2Njk0NjAwNykoNjY2?= =?utf-8?q?6004=29=2854906003=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3853; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A: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: =?utf-8?q?TIolJOn9lOod/zW+Mg2QRlcgpGjJEIa?= =?utf-8?q?MN5Tk2KYNd02EAOG7tnlKfkMofqEpuDsduraPkyLdAy92P4eU4f/8mxCO/fDhwOzB?= =?utf-8?q?u7GWawumOvAvHviBfSMMbPAE1MlBsM/oOu6uu5A9uF7LafRJdU6xLBfkr2uZtjo1a?= =?utf-8?q?gWBmLGZrliqNbeIAPQIM2HXOetRcpsWl+ZFgy1xECaQK+rrCnggBbiuXI1LEknljv?= =?utf-8?q?mHiqfDUAj2ayC6ZBL4UqgSI9yQ/qOZam6AUv8WZAPVDbOlfsnAt4++E5uzg3yYY1m?= =?utf-8?q?Y14OMVt2/LgZy3BRUq95JwW/PoQ6hgml1/CperTQ43icY22D1TzjSP3QOGcSvU6f+?= =?utf-8?q?PIZ01yrCSs7g/znOArM381Z/xcp1AW89DAEJqh+3oRvjwlkirk1tV7e4SpnOgmbt/?= =?utf-8?q?Q3ZU3o6Kps/AhRIwoaitBanU6lD?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?+StTAkvsW1TsADICCgmYHSATdRDS7Q?= =?utf-8?q?HvMCJtpTNDGBHBNEvJ1VLuOJg2FTEAcP8kLQETioJBH55pNZGgqL4Vunk2ycaGsSj?= =?utf-8?q?a4D2agRES26tRxvSn4ZexcPi4Gmz6RQKtJ6iR4ocxTUEm9OVeWYvigLphO3qY2/Sm?= =?utf-8?q?Od+eBD7bSCuBauaoYLxm2+n+Rk87IG8jYYgW4rKKM+rKhsgwRZLPNA=3D=3D?=
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: 116d18c5-ad7e-4ded-4bab-08d7cefeb0c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2020 07:49:17.7849 (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: =?utf-8?q?T8D01hy5aoDd+KevfdGTb?= =?utf-8?q?KEfR8iQuWSutjgfiCiravqx0rsdaH8DpNjh+awGhd6oELmnawCEdWOcpj9lK20Bpg?= =?utf-8?q?=3D=3D?=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3853
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/7TengIXeBB8pMlWt99riDREWhic>
Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-minimal-fragment-12: (with DISCUSS and COMMENT)
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, 23 Mar 2020 07:49:30 -0000

Hello Benjamin:

Let's go then!

> >
> > So I suggest 'typically' instead of "if needed":
> > "
> >    Typically, Node A starts with an uncompressed packet and compacts the
> >    IPv6 packet using the header compression mechanism defined in
> >    [RFC6282].
> > "
> 
> That seems reasonable.  IIRC, my understanding at the time was that this
> scenario would only arise when fragmentation was performed at a different
> node than the original sender of the IP packet, which I expect to be rare in
> homogeneous LPWANs.

Sorry I confused you. For a packet sourced in the Internet, the border router does the compression at the ingress of the 6LoWPAN network. So it is not the original sender. But it is both the 6LoWPAN endpoint and the fragmenting endpoint.




> > I would have appreciated a suggestion here : ) does this work?
> > "
> >    *  Attacks based on predictable fragment identification values are
> >       also possible but can be avoided.  The datagram_tag SHOULD be
> >       assigned pseudo-randomly in order to defeat such attacks.  A
> >       larger size of the datagram_tag makes the guessing more difficult
> >       and reduces the chances of an accidental reuse while the original
> >       packet is still in flight, at the expense of more space in each
> >       frame.
> > "
> 
> Hmm, talking about a "larger size of the datagram_tag" (or wait, did we end up
> at "Datagram_Tag"?) feels odd since this document has fixed it at 16 bits.

Hum, not this doc but RFC 4944 which is described page 6. 
"
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
"
This doc does not impose anything per se, e.g. fragment recovery inherits from this but uses a smaller tag.


> Maybe:
> 
>    *  Attacks based on predictable fragment identification values are
>       also possible but can be avoided.  The datagram_tag SHOULD be
>       assigned pseudo-randomly in order to reduce the risk of such attacks.
>       Nonetheless, some level of risk remains that an attacker able to
>       authenticate to and send traffic on the network can guess a valid
>       Datagram_Tag value, since there are only 2^16 possible values.

Nice, I'd just change " only 2^16" with " a limited number of" to keep it generic

I'm continuing with your other mails based on -14.

Keep safe;

Pascal