Re: [core] Review of draft-ietf-core-groupcomm-bis-03

Esko Dijk <esko.dijk@iotconsultancy.nl> Fri, 04 June 2021 07:39 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6F3A2D93 for <core@ietfa.amsl.com>; Fri, 4 Jun 2021 00:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=iotconsultancy.nl
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 VeHPKALbxjnv for <core@ietfa.amsl.com>; Fri, 4 Jun 2021 00:39:15 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10134.outbound.protection.outlook.com [40.107.1.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D743A2D91 for <core@ietf.org>; Fri, 4 Jun 2021 00:39:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FNHIliEGvJZdyAy0TH6/CKJeuT9c4pqXzv26tJESqNKhmpGFi4VavHNoef10Hgj1MHUz9Mg/MgIaAEST18j4iKBrRNKelLINpbwtcAkObwzzt3B8rhhyzhUNgA4gp6dKTt8Xm1wU4vW2jKNL6T+DjtLBMv3inU33TilkAHagNwotDDVCIKUiZwkQ0geUT29RCwRI38tUKKsD1iZInJbwnpr6FFRW46XaHCRXgBPU8aT2vhEWJ61pRheQ18f9tNrorj8Flv/XhZvcOytX8KJq7TYGPJNuRSDvY/OawVbp/GDYuN953Wyk79tvU4h6WO3A7iwLwuUh/v///feUnpnWPg==
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=ezgfYo6enUkOTFTmYKYtrWpa1pM8qT701mvlw+JnD4Y=; b=lXDs5X5NKKzHRXOAg1vYpe3SNaN7WZCFq887PHujbzSU4wmJG+nKj+Avcy0iLKzZNsg0CQz5J7dmvt0NqhATM7flvXifvOug3uQ96YctrpL9aytDBuyYMD7+AQ0X5ctEoBAbThfcUgkWe5kp8rwiRFwA19QXxePZDzKY1jQjKuJzzQ+Wad5q2NqgeuuCUUIJgiPrcsmlrnLxdtnrov08mZqU+cuGb464ei/lELSecpLLYuukPKr537dgWK3X8GM/teSJCbyJ1Tugv5BTlSZFltnUJKJ42E02bACWx0PXYYRBK23NWzxz/cjlvGqhNXTza0ndUQP6WUYOu5omlCdXaw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ezgfYo6enUkOTFTmYKYtrWpa1pM8qT701mvlw+JnD4Y=; b=QQ7fl9EESgS1dgG//443P9YLMZGetUQWZZ8FGG3SSy1u2quMozdTkTsoLtllRKc/EkKa0vor+UV/8NcaYgt74pxCOUdo/8eyo+MiIffZJRdt1H3AmJaoOoNb9DcozJIbRDHf70Uy2jT07mijX/qSDatzePIfLYxxaeggHETR7Fc=
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0708.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:198::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.22; Fri, 4 Jun 2021 07:39:10 +0000
Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::cc31:ad15:16ab:a540]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::cc31:ad15:16ab:a540%7]) with mapi id 15.20.4195.024; Fri, 4 Jun 2021 07:39:10 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: Review of draft-ietf-core-groupcomm-bis-03
Thread-Index: AQHXCwSqc4rdNewjlUGtn83ROTnvRasBRjGA
Date: Fri, 4 Jun 2021 07:39:10 +0000
Message-ID: <AM8P190MB097960B13960FFDB72974EE4FD3B9@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
References: <E0959F68-0966-4628-94D3-F9B64F47A84C@ericsson.com>
In-Reply-To: <E0959F68-0966-4628-94D3-F9B64F47A84C@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=iotconsultancy.nl;
x-originating-ip: [85.147.167.236]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 021c9289-5630-47ad-3e66-08d9272bd7c7
x-ms-traffictypediagnostic: AM0P190MB0708:
x-microsoft-antispam-prvs: <AM0P190MB0708AA29483AC35E7788987CFD3B9@AM0P190MB0708.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pccGelVO+u5HQSKVd4SMJP92LVg0/+vlIwTN4KRu+UiPpLmBTU41PP7H5iMWF+DUzz1dK5BMkdjxrL8yZb/Y+WuY2NVDFxr43sG61Ar5R9Kj9KKSHuLDa9HUINNyYsGnFpLnMnyLcSISV0YwHgNfiaZY4pTR3RGWLovpPUSdZ1FruIrCl3agg3cLL8vV8vZO3yjrR9L2wXNfnOEBK/w8YJq98yEro+IOdeuWPG2SnPkZyvsWRlfRHTsCahp4d5Ay5YLNZwLP/Hz4YlieY5jq/pg72owndpTIDAbi/wAVkMgd2yeu+ktERxclzQKbUshtZyT8pkpuSJXeNjXaMUd+QenTYbr33HTeRVTeID8kkkwKSRl3Aa7dvRz2HlRS4Sf2PafASnRb00KwW5hEmZ3ktjjA5Oks5WmaUAj+1gXLg0kZa3BCBSspKtm9DzqY1OOM21bx3aRl9mrdWaUEwq7taRWNkDgKlxAczLG/BNO+Djpm7cKFYcAA7BiYb5gjY6GqJ1jeuBuMRm7GgpgruVQXAy2T2d+MvdS9guk8qSzs7/WW/I1opVE6KNyOx8eemJhTPG9QdyS9YfaUjmGRD7F0R24wzi1FkAh5JUB2/mASAdGfCPu/UmIoHQHlgOd7JGv0zWfRukMH4F3r+S9aKkegXFznNTHEYT4/wjik/I3CTsNz/j4op41GSPdjeSCIlsPtMcZgv7yEKQtx44UDu1NPAw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(136003)(346002)(376002)(396003)(39830400003)(66446008)(33656002)(66556008)(316002)(64756008)(66476007)(66946007)(76116006)(86362001)(8936002)(66574015)(83380400001)(55016002)(9686003)(53546011)(6506007)(110136005)(5660300002)(8676002)(186003)(26005)(44832011)(38100700002)(2906002)(122000001)(71200400001)(7696005)(966005)(52536014)(478600001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?MllSeGcveGs5YzB4N2RKWWxCSG1kbWZnb290dTlCRkxJRnAvVjRubHJlM2Rl?= =?utf-8?B?emVNZUpVM2xBZFVCZEZrUTR6ZXRQQzVJU3dGRkRDa2h4Njg4ZVpuZlViL0J0?= =?utf-8?B?U2QrYXllSVpYN3EwNzlJakZNMDZlQlNCVkVqdE1QOUdrb2pCNzA3ZGpoQTNV?= =?utf-8?B?UmpnR21zbXl6Z3NBUWpkMkIrQlNpcWxxUTlzZ0kyZ2pXVU0vb1dIMTRxbkdj?= =?utf-8?B?dVRzTHlsYmxCUStOU2lUSzdOTjNXNmswYmZJeExnUjVMVTZsWk91MmRzK3gx?= =?utf-8?B?SWNZTHNCd2pSTU1TNHJvQTI5Z1R2T1RnVUl0THJ5NUN6enpjb0FJRHJhRXYr?= =?utf-8?B?VVphbmNRTE40anlXc0NHZUhOa21YLy84b2tUd1p3UEJxdENLaHk2bFZpSGQz?= =?utf-8?B?b0RaK0ZjMkh1d0dqSzZEdFN1WCtZSnlxWHNHTWEzdVpwSktzdXNaU2N3Y090?= =?utf-8?B?V201RVF6N2hOY3BmSG9mbEUzWnIwaGhlVnVmVmJFM1ZMaE03aVFGVE1UZnBr?= =?utf-8?B?K2t2dmEzQlZ1WExzK2VjUGdqbTRrK3BXb3BIWGJMVkd1MGM3aWQ1bUhCSy9G?= =?utf-8?B?c01YM1ZVOWM5RVVTeDJvWS8rQXdzbncySXc5blY1bHlFVzk2WEpOeVFNSFZO?= =?utf-8?B?eEQxYjdNMlBUNnZXMS90blJ3cW4vbnpuSmJ1WGpUbzFqUEkwUWVGTlJpaFFE?= =?utf-8?B?UmhNcmJyRm5HWFdBMVhycVpnNlY1aWhzcnR6NEliSWVDcSt4SlF2cG53RUJi?= =?utf-8?B?Rkh1MlBINEorbkJ2RDBSK0ZOU2RKT2haNkp5VHA4T1h5NWhYQUQvRnBIMllq?= =?utf-8?B?N0I3b25iSkNUYkNYakc3T285ME05a2QvUHVJak5Sc2dZbjNPZzAxT00yU2FR?= =?utf-8?B?MkxpYk1yZkJ3a3hLZnJIQlFPdFovTldkZUM5anZHVG5YTHFRUyt0YktzKzJv?= =?utf-8?B?Z1ZLTGRzbjJTUW15ZC9IZVN6ZENBc0R6QUtuUXdmZHpYWk1PcDVrcHFEM1pm?= =?utf-8?B?aGxCL0tnbHpaYkkrcTRFSkdiV3lyMWFEMWtaci9DempNTkQvQTlUaElCSno3?= =?utf-8?B?UEFDVzZ4eC9HZkNJdURkYTcwM3NpUDdCaVlvckNrSmRoNVhzWUgyNjhyVjRk?= =?utf-8?B?ZHpqZEFWUTg5Wk9TU0tZNkEvVGJJVVVLRlB1L0tNMXlYSFd6NVZKK0Z2SXFN?= =?utf-8?B?aG9yMGhpUzArWEhHVnhwRVc5c3h0S1ZJNjB1cG9lb0l6bFpEOUd6enB1b2xX?= =?utf-8?B?bmorZFZNb2JjMWhDMCtIT1NBVnFpZHZBaFd2bVMwNE9OWkdMTk8ydUhUN2l4?= =?utf-8?B?V0J5UWFmQzZGMG1TWUQvT1BHd3RBWEFuY1hJN1VUZ29SeHVZSGtrRG1teEVC?= =?utf-8?B?QzZWb1FLVWpwclBWOWJGNk5DMHFnc2FzQnJ1MXZmbWpGMHZyZkdIMEk0R2sx?= =?utf-8?B?QjEzZjdhWDVXSlg1eVU1WmcxMFBhNTk3UGpBb2lGcGFya05pakNlSlBIdTdF?= =?utf-8?B?M1ZMTW9rR2tQclQ5UG1abEtHTm9DWWRvWU1peG9qc2o0VHlQbXQyQnRFZXlS?= =?utf-8?B?RVNZQjNVaU5kOCt2UThmdU9uQ0xDT0N5Y1VQUWhubUhLeGNVaEV3eTUwRG1X?= =?utf-8?B?VVkrSTRUQ2VGQjcrMk9EWHdUZldSWXJWaUIwa0JFUHdWSE44U1ZacXNjRGtB?= =?utf-8?B?YXFONElkU203NFhhdmxUVjBjUU55MFZaRVZGdGFlY05HZTZFRkUwOER2a2xD?= =?utf-8?Q?3Rk1MKRYs87NxTSOW5gN4FJMIwwOYToxfT9BRIv?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 021c9289-5630-47ad-3e66-08d9272bd7c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2021 07:39:10.6005 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kKEtzZbaERzkRezuzxC6yp4VP8FLG/gQQVYAaGM813ChBBM2W+6cBxpUiECop3xbHcsnXV8Y1kROcKHRqAaCpwijqFenS48WrWrTAFlay1Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0708
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/pS4O6xZXkpTxWJdARq12hkDEspM>
Subject: Re: [core] Review of draft-ietf-core-groupcomm-bis-03
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jun 2021 07:39:21 -0000

Thanks John for your review!

Sorry it took a while to respond; this was due to other work.

> - It seems unclear to me exactly how this updates RFC 7252. Do everything in RFC 7252 still apply, or are some multicast parts replaced? In such case which parts?

Yes, that's not always fully clear and the introduction only summarizes this. I've created new issue (https://github.com/core-wg/groupcomm-bis/issues/20) for this and proposal to add a section 1.3 to explain this in enough detail.

> - The document seems a bit too locked to "UDP/IP multicast" for my taste. RFC 7252 left things much more open with statements like "by default, are transported over UDP". CoAP is now popular in many environment without UDP/IP and the same will/is true for Group CoAP. I don't see any reason why most of the things in the document could not easily be used with broadcast, geocast, unicast, and non-IP multicast. Maybe you could soften it down a bit so people wanting to use Group CoAP over Foo can still claim they are doing group CoAP draft-ietf-core-groupcomm-bis.

That seems useful; a new issue is created (https://github.com/core-wg/groupcomm-bis/issues/21) to explore this further and if possible, generalize the aspects that aren't necessarily dependent on UDP/IP multicast.

> The current document only mention amplification in some specific cases. I think the draft needs to expand on the text in RFC 7252

Expanding a bit on this text sounds useful, as we can now point to Group OSCORE as the specific means to "cryptographically authenticate" a multicast message.
(issue created https://github.com/core-wg/groupcomm-bis/issues/22)  Also the cryptographic authentication can be used in combination with other measures like limiting the scope of the multicast group.

> A reader of draft-ietf-core-groupcomm-bis might think that Group OSCORE and Echo is enough to stop amplification, which is not the case. Echo only helps a bit by limiting the size of the responses but not the number of responses. An attacker can spoof the source IP of the request and a smart attacker would send it to a resource that supports multicast requests. Not sure Group OSCORE helps much at all as an attacker can take an existing group request and change the source IP. 

We can clarify that even with Echo, responses are sent. If the attacker you mention captures a valid group request and replays it, I assume that most servers will silently discard the replayed message because they have already received the original valid group request. Maybe some servers that missed the first original group request will still respond (e.g. with Echo because the server detected an IP address change of the client groupmember and it wants to verify that 'new' IP address). But I expect this will only be a minority of servers, reducing the amplification effect. So the combination of Echo and Group OSCORE should help a great deal.
Or did you have another scenario in mind?  (e.g. a valid group request is captured by an on-path attacker, and replayed to groupmember servers so that none of the servers actually see the original message?)

Best regards
Esko

-----Original Message-----
From: core <mailto:core-bounces@ietf.org> On Behalf Of John Mattsson
Sent: Thursday, February 25, 2021 00:28
To: mailto:core@ietf.org
Subject: [core] Review of draft-ietf-core-groupcomm-bis-03

Review of draft-ietf-core-groupcomm-bis-03

I think this looks very well-written. I read through most of the document quickly and found very little to comment about.

- It seems unclear to me exactly how this updates RFC 7252. Do everything in RFC 7252 still apply, or are some multicast parts replaced? In such case which parts?

- The document seems a bit too locked to "UDP/IP multicast" for my taste. RFC 7252 left things much more open with statements like "by default, are transported over UDP". CoAP is now popular in many environment without UDP/IP and the same will/is true for Group CoAP. I don't see any reason why most of the things in the document could not easily be used with broadcast, geocast, unicast, and non-IP multicast. Maybe you could soften it down a bit so people wanting to use Group CoAP over Foo can still claim they are doing group CoAP draft-ietf-core-groupcomm-bis.

- I think group CoAP needs quite a bit more text on aplification attacks and DoS. There has been several negative articles regarding CoAP and DDoS in the last years. Group CoAP with it's 1 requests and N responses is a amplification in itself. Multicast Observe is even worse, 1 requests and N^2 responses. Multicast can however not be used on the public Internet which limits any attacks. The current document only mention amplification in some specific cases. I think the draft needs to expand on the text in RFC 7252:

 "This specification attempts to reduce the
   amplification effects of multicast requests by limiting when a
   response is returned.  To limit the possibility of malicious use,
   CoAP servers SHOULD NOT accept multicast requests that can not be
   authenticated in some way, cryptographically or by some multicast
   boundary limiting the potential sources.  If possible, a CoAP server
   SHOULD limit the support for multicast requests to the specific
   resources where the feature is required."

A reader of draft-ietf-core-groupcomm-bis might think that Group OSCORE and Echo is enough to stop amplification, which is not the case. Echo only helps a bit by limiting the size of the responses but not the number of responses. An attacker can spoof the source IP of the request and a smart attacker would send it to a resource that supports multicast requests. Not sure Group OSCORE helps much at all as an attacker can take an existing group request and change the source IP. 

Cheers,
John

-----Original Message-----
From: core <mailto:core-bounces@ietf.org> on behalf of "mailto:internet-drafts@ietf.org" <mailto:internet-drafts@ietf.org>
Reply to: "mailto:core@ietf.org" <mailto:core@ietf.org>
Date: Monday, 22 February 2021 at 17:51
To: "mailto:i-d-announce@ietf.org" <mailto:i-d-announce@ietf.org>
Cc: "mailto:core@ietf.org" <mailto:core@ietf.org>
Subject: [core] I-D Action: draft-ietf-core-groupcomm-bis-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments WG of the IETF.

        Title           : Group Communication for the Constrained Application Protocol (CoAP)
        Authors         : Esko Dijk
                          Chonggang Wang
                          Marco Tiloca
	Filename        : draft-ietf-core-groupcomm-bis-03.txt
	Pages           : 58
	Date            : 2021-02-22

Abstract:
   This document specifies the use of the Constrained Application
   Protocol (CoAP) for group communication, using UDP/IP multicast as
   the underlying data transport.  Both unsecured and secured CoAP group
   communication are specified.  Security is achieved by use of the
   Group Object Security for Constrained RESTful Environments (Group
   OSCORE) protocol.  The target application area of this specification
   is any group communication use cases that involve resource-
   constrained devices or networks.  This document replaces RFC7390,
   while it updates RFC7252 and RFC7641.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-groupcomm-bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-groupcomm-bis-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
core mailing list
mailto:core@ietf.org
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
mailto:core@ietf.org
https://www.ietf.org/mailman/listinfo/core