Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Esko Dijk <esko.dijk@iotconsultancy.nl> Fri, 03 April 2020 12:38 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 5896D3A174A for <core@ietfa.amsl.com>; Fri, 3 Apr 2020 05:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.onmicrosoft.com
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 UU2nCutyD-nX for <core@ietfa.amsl.com>; Fri, 3 Apr 2020 05:38:22 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2096.outbound.protection.outlook.com [40.107.22.96]) (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 3BA423A10C3 for <core@ietf.org>; Fri, 3 Apr 2020 05:38:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UtUqIsfGVxycqFrsigHJS1QRJeSflOa6VAvAz4qeXJVz9+9uPE7Z12dRYAlQw1rCsxFb5yaZgD0r/0VoZ43AOu/UC4ICuU6bm6St6LvMv3U7jV3vI6eO1gXg71hSt7QYH+HONDbcyv2UpWU8sK9Z6vTrL/v9CIJvbFiSqU5byIQNW0Qxi6ygGvyJynrD2FCoJrt8DvhDgYZZeSjEQZbM9ZCAasMWF9GBX1QCi2wZ3jChWPSwBjboXW9EPmZBUPZ2hpSqW8AsKtvuhDQowaI0xLEcMR8Lfz94GVecfgHWca0x320mrY31v03pPbf8g8y4BXQdo9V3K3jhlK51mjjlRg==
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=1ephWU0aflFqpK76B5Y5mh4eyg6oV4rb2yqGmfTzVjA=; b=c7rvJCO7OzwQJKsNGRZKl8eWHBai4YAsMmKukimy7pxEBeFO7/aAVJs8wBU8HYBoUktOFYAFuNUfdLCRjvFOTOFJqhsdrAT+EcAM5bYe3iVnIDYsvqRNI/jzehqwaAXiKrnEsykrevL2SEgKZhVNEf18Clhc4uDl5/qzvfrNPIrZgN/lt9CXli5gDjb6RUNWO1BlcTjMOqdHZn+vgz7nARg/vtlj9hLa62cLJ/JqDyopoMldPvDIBcOOO1j0Q7e+FUft3Of++EDwdiQG6RJdQzk+/c6UfU2gSKqT3VXQ6+ZHa+sBTMy5KQbXEETmsyBVKLfdpuOtCB1PM2xRRQQg9g==
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=iotconsultancynl.onmicrosoft.com; s=selector2-iotconsultancynl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1ephWU0aflFqpK76B5Y5mh4eyg6oV4rb2yqGmfTzVjA=; b=MjpoiESydQ5bFE3b85YyimDFIzfGSckp7WZV1T34XZuTpYI7V73yVLm7+Bov3vjtk3ihkhiPwYCezajkurq+gJ8c2dJBvRQxZ3u0KOnHb/Us+e6/E+gK6PqqIv+GVwbJAz+psZOdHZZUVhKdOTr6Z3r4JqL2CcTlttNpvK7xhTU=
Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM (10.161.62.28) by AM5P190MB0561.EURP190.PROD.OUTLOOK.COM (10.161.66.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 12:38:18 +0000
Received: from AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f]) by AM5P190MB0275.EURP190.PROD.OUTLOOK.COM ([fe80::8c96:a66b:e170:bf8f%3]) with mapi id 15.20.2878.018; Fri, 3 Apr 2020 12:38:18 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Jim Schaad <ietf@augustcellars.com>, 'Achim Kraus' <achimkraus@gmx.net>, 'Thomas Fossati' <tho.ietf@gmail.com>, 'Klaus Hartke' <hartke@projectcool.de>
CC: "core@ietf.org" <core@ietf.org>
Thread-Topic: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top
Thread-Index: AQHWBAJ4QQxxhgNVoE6+AM1rLNkaVahcnYmAgAAdZICABcLe8IAAHjWAgABVYQCAAP5CIIAADCeAgAAkYYCAAE/IAIAAUBuAgADFdpCAAIJoAIABVUGg
Date: Fri, 3 Apr 2020 12:38:18 +0000
Message-ID: <AM5P190MB02756F537F757941D123AF17FDC70@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM>
References: <580bb0f4-89c4-2d11-b17b-520ddfe89c33@gmx.net> <000501d60452$c96cfa00$5c46ee00$@augustcellars.com> <1e74313a-d258-622f-d43e-ff1fa8f7d06d@gmx.net> <AM5P190MB027536259A44102F7AB9E058FDC80@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <CAAzbHvbeEyws+wVchovoVTK=WutWoHCNcfv8LrpxmshLxJ_w+Q@mail.gmail.com> <011301d6077c$b5d347b0$2179d710$@augustcellars.com> <AM5P190MB0275218BA7C801E50C8353F0FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <CAObGJnOscTtyeQ+qvD0N0w_TD2JfV8h9+=zf=bz-jrr7LWhD2Q@mail.gmail.com> <CAAzbHvaJy9WfMOzzKhczreuZBcbA5TDQ5ThtGMT7eVj2Jf83gQ@mail.gmail.com> <CAObGJnOcP_FxNuORqAvpBE-P+nRdPjxcXVdb-VTN5in5obanmw@mail.gmail.com> <02ec5628-3f7d-ff5d-620c-c0a90a4b89b0@gmx.net> <AM5P190MB02755F6BA4AFF11C3BFC5F18FDC60@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <020701d60907$fb3ba720$f1b2f560$@augustcellars.com>
In-Reply-To: <020701d60907$fb3ba720$f1b2f560$@augustcellars.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl;
x-originating-ip: [2001:1c02:3103:6d00:48bf:f11d:8f40:12c4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0f4eeeaf-591d-49b6-54ed-08d7d7cbe321
x-ms-traffictypediagnostic: AM5P190MB0561:
x-microsoft-antispam-prvs: <AM5P190MB05618FDA0EDD28B3C14CDD4DFDC70@AM5P190MB0561.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0362BF9FDB
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM5P190MB0275.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(376002)(39830400003)(396003)(346002)(136003)(366004)(8936002)(71200400001)(52536014)(110136005)(186003)(4326008)(5660300002)(86362001)(316002)(44832011)(9686003)(66446008)(2906002)(76116006)(508600001)(81166006)(966005)(6506007)(33656002)(64756008)(7696005)(66476007)(55016002)(81156014)(8676002)(66556008)(53546011)(66946007); DIR:OUT; SFP:1102;
received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LUERJC+IABD8g6x3yLnQOaL5KmKggGybvj9q1ke+9fGxL7hNJ8SUv6A+ajwDUAPc1d2diU2SbQU7E4zCdm67Pnyf/oQWK/AngOe0lZDutoAH5Jwt9m6NMwKZBRON6SEdAIBQv5jlte8Biji51X790TQ+rwGRMpo09xAbu9NZXTZUdCvEAPrw8ipnMILaKhHpbo/xR6vW7DFnxM2DgTLsSSGaiKEghL3UyeYmuOt8JRRhGlM0n8BDWWGc696JM/pN98ET9qasKDkSijlgaca/dXIQb9VfI/D1O0g1f55e8/LELTBYnotlUgUe+jRbALcN6/ZIP0R2hZ+NWilA77pOauEXaUMOvwZxu5e2RqukuUuPTkmYZ8zWUXEkydd9PoVia/fYa+Jvlw186MOujkZjo8+bWBtm9E1YaVqc3kyv01wL2t6r1X4gI2V8mu+stDAydcP3wwaJ9mULQIkOHIE5VznScoOydH4fRxdbeAToasHaWMDxac6Vc2RxBYq9Y8NJz1kFPFDodiJ5iehwwn87Ag==
x-ms-exchange-antispam-messagedata: XjZ1ur5Yzc7FSMsbFr4ssCnma5lYtMG3vrhGp4LXDtUAEyx1kwm4Vga3WdixLL9ifYG+qADsKpOENvDnTOpo1CFL18Q9ZlPxlu+rG3KAJL0U4f/TO4GKCt+F3XzwoErgRR93VHbY+SNZbTjdXVGHHrFxpNcMwNu6JVs7D3eWQTp8YUUVSi6+Vc0m1cCcD46vToxL4P9Z5YNGOXFsuK3FtA==
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-Network-Message-Id: 0f4eeeaf-591d-49b6-54ed-08d7d7cbe321
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 12:38:18.4180 (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: KIPKY9FBUstwTM5trd/PatZbG8SPgbNiVhJPt5FS+cCWDwsJlyQQJm/1k5r/FZiHNs5O5TWCQ7iPQ0lvPrZtSoiI8QZm7OrC7di74K2V3CY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5P190MB0561
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/hCNyF4Hm24yXCcLhTY3esC-Mg9o>
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top
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, 03 Apr 2020 12:38:28 -0000

Hello Jim,

Could you clarify your point further? 
- what is a bad idea - having a dedicated port with dedicated for handling multicast requests?  Or the subsequent "internal routing" of the request to the unicast server at a different port? Or both?
- what is a "multicast channel" , do you mean an endpoint bound to a multicast address ?

> some resources may only want to be on a single multicast address even if the server is listening on multiple unicast addresses

Sure, you can also have a dedicated server on say port :9999 that listens to multicast destination addresses only, because it is bound only to a multicast address not a unicast address. This dedicated server can then handle resources that only are to be accessed via multicast.
But in this case, there's no "internal routing" needed to another server inside the node because the resource is only hosted at say port :9999.

> The IP address is different for a multicast vs a unicast message received at the server.  This needs to be the distinction

But the case the Achim indicated is that the server may not be able to detect whether a request came in via unicast of multicast. So this cannot be the distinction, e.g. in the following case:
1) CoAP server at port 5683 is bound to unicast address U
2) at same node, same CoAP server at port 5683 is bound to multicast address M

Now in this case if a request comes in via multicast group M destined  to port 5683, the server handling this cannot tell whether it was unicast or multicast. And if a unicast request comes in to destination address U and port 5683, the server cannot tell also whether that was unicast or multicast.

By setting it up like this instead that problem is avoided:
1) CoAP server at port 5683 is bound to unicast address U
2) at same node, same CoAP server at port 9999 is bound to multicast address M
Then the server at port 5683 treats everything as unicast. (Because it is not bound to a multicast address, it won't receive any multicast requests directly.)
And the server at port 9999 treats everything as multicast. (And this endpoint 9999 handles most requests by internally redirecting to server :5683, but only for those resources where multicast is allowed. Some request for multicast-only resources it can handle itself directly.)

So the above "workaround" seems handy for cases where a server at one specific UDP cannot itself determine the endpoint the request came in from (could be either multicast like M or unicast like U).

@Achim maybe you could comment if I've understood your use case properly.  To me the above seems more secure than trusting that a client will include a "This is multicast" CoAP Option in an honest way, which could easily be misused.

thanks
Esko

-----Original Message-----
From: Jim Schaad <ietf@augustcellars.com> 
Sent: Thursday, April 2, 2020 18:02
To: Esko Dijk <esko.dijk@iotconsultancy.nl>nl>; 'Achim Kraus' <achimkraus@gmx.net>et>; 'Thomas Fossati' <tho.ietf@gmail.com>om>; 'Klaus Hartke' <hartke@projectcool.de>
Cc: core@ietf.org
Subject: RE: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Esko,

That idea strikes me as a very bad idea.   If you build your code on this basis you will fall over the first time you come across a multicast channel which uses the same port as the unicast server.   The IP address is different for a multicast vs a unicast message received at the server.  This needs to be the distinction as well as the fact that some resources may only want to be on a single multicast address even if the server is listening on multiple unicast addresses.

Jim


-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of Esko Dijk
Sent: Thursday, April 2, 2020 1:23 AM
To: Achim Kraus <achimkraus@gmx.net>et>; Thomas Fossati <tho.ietf@gmail.com>om>; Klaus Hartke <hartke@projectcool.de>
Cc: core@ietf.org
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hello Achim,

(see also my response to Jim)
Using the UDP port number to detect a multicast request vs a unicast request sounds like a good use case. Just curious - I assume the security aspect requirements of RFC 7252 are taken care of in this use case?

That is, a proper client sends its multicast requests always to port :9999 and the server treats these as multicast requests (e.g. only allow the request for specific resources).
A malicious client may sends its multicast request to port :5683 to bypass the above checks. I assume the server doesn't respond to this request, because the multicast address is not bound to port 5683 but to say 9999 only.
If the CoAP server at port 5683 cannot distinguish between unicast/multicast that would be a bad situation and the security requirements of RFC 7252 are not met.

Esko

-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of Achim Kraus
Sent: Wednesday, April 1, 2020 22:28
To: Thomas Fossati <tho.ietf@gmail.com>om>; Klaus Hartke <hartke@projectcool.de>
Cc: core@ietf.org
Subject: Re: [core] RFC 7252 - 8.2 - Multicast - Request / Response Layer, page 67, top

Hi,

>> +---------------+                +-----------------+
>> |               |    request    _|_                |
>> |               |        .---> /   \   224.0.1.187 |
>> |              _|_      /      \___/ --.   :9999   |
>> | 192.168.0.1 /   \ ---´         |      \          |
>> |   :54321    \___/ <---.       _|_     /  rewrite |
>> |               |        \     /   \ <-´           |
>> |               |         `--- \___/ 192.168.0.100 |
>> |               |    response    |         :5683   |
>> +---------------+                +-----------------+
>>        Client                           Server

Nice diagram.

> Not sure why you would also want to rewrite the transport endpoint?

I tried to follow the discussion.
The idea to change the port as well enables java (and I guess some more) to differentiate between multicast and unicast requests. Jim also mentioned, that it enables the use of multiple servers on the same host.
I have not enough experience with multicast in different environments to see, if that may cause more trouble (e.g. firewall etc.). I would guess, that some  implementations will just offer that variant, at least as configurable option (I would try do so for Californium).
So my favorite for now is just implement it and see, what the user's feedback will be.

If that idea gets declined (may be by negative feedback of users), I still think, that there is a demand for other means to distinguish between multicast and unicast requests. Maybe, either the usage of the uri-host option or a new option will help.

This maybe considered as "too pragmatically", but on the other side I also don't see the "great benefit" in insist not to change the port.

best regards
Achim

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