[core] draft-groupcomm-proxy: reverse proxies & URI embedding

Esko Dijk <esko.dijk@iotconsultancy.nl> Thu, 02 June 2022 09:26 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 DFEDEC157B54 for <core@ietfa.amsl.com>; Thu, 2 Jun 2022 02:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=iotconsultancy.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTzJ50tWg1-O for <core@ietfa.amsl.com>; Thu, 2 Jun 2022 02:26:17 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::71d]) (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 88215C157B45 for <core@ietf.org>; Thu, 2 Jun 2022 02:26:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hk4/JF8tjy4V2aFy2Dlet5lXSdpGSgOamXQdTut9Ozr0zTSVzBuByoaP/oMnA5nva8b5vZfVXJiMSSA+SWHPdAq9qtqrcL0RVSsMGmL1gM50URxYUiiQyrkZnYiHce9WEP6d5vV70/nzK0VwW/9U/vczFMxxwmxUMxsWykFCwZB13PmK/pfSkv49xr1m0uOON2i6G0UR/W5xrS7Eh09Na9IXEruM+p3bQQMhEaW40xRnFcGZCB615fTT1iTDV6W16s4C37SuzXi9qZUj/0CXYLBPKyYVsQcgU4WMTUqbLCyn0HLVKPeLdjiCjEzYaCl349WeHXAFknOGwVllLX+XeQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=A4ddiBbXLoxnUy1nJlPFn8yzHY1h3nnI3XaasKBUHRo=; b=Hd1yphmLCNhLpMHOlk6X0PWnsuZDllKhEdkgRWCQi3oaC6D/0SZVwPHStTbXdoL49afHW++ucIWj5mQZjymK+G9gTFN9I32vSznFAVt+u01kFFhpvoG5j+N3k4mXv+nQ2+Q1kVYRb5boptLp7OUJQnY2MqGponGVK59q6+a/7MZMUyBkSYAU+QDzRnu04Ha2aWxHgg+CGEtKzFEQg+ojdtelwBz9Ph/DxcJB+EjebRy7KXD1OeilY31lvpIpgcEyPxmw8D7WIHI54hDxExZc8tDQqZWhuZVPC5gAg/i6K3+OGjOEao0mTDyQ2LJoDe+GF5qc+j8FoYVWzFX9gxkXBg==
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=A4ddiBbXLoxnUy1nJlPFn8yzHY1h3nnI3XaasKBUHRo=; b=CiM1cWuKZ0EpuJ2a+Ez+qlffsc+pbwQUinKvdXwt9yuz4+ZUepv2S6ndP3h65SASxpUBZ4mpjuhgsIy4O0augS0/oMzeaVmvjGNZTyvtaGgiglDkeTHHulZ8zjRtI1B5CNqEBkzAzm4T2cQ9CL+vkMHziJD/gMPTcHzNrQaASaQ=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by AM7P190MB0598.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:11c::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.12; Thu, 2 Jun 2022 09:26:10 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::d19a:a24c:bd5c:95da]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::d19a:a24c:bd5c:95da%9]) with mapi id 15.20.5314.012; Thu, 2 Jun 2022 09:26:10 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: core <core@ietf.org>
CC: Christian Amsüss <christian@amsuess.com>, Marco Tiloca <marco.tiloca@ri.se>
Thread-Topic: draft-groupcomm-proxy: reverse proxies & URI embedding
Thread-Index: Adh2X90cKroSyKpVR/SCpmaLj7oB5A==
Date: Thu, 02 Jun 2022 09:26:10 +0000
Message-ID: <DU0P190MB19784C8ED1D37EDBF4E0E7E0FDDE9@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5256c5fa-aaab-4e10-b658-08da4479ee76
x-ms-traffictypediagnostic: AM7P190MB0598:EE_
x-microsoft-antispam-prvs: <AM7P190MB059823E2FE5BA7AC9F9C1CC9FDDE9@AM7P190MB0598.EURP190.PROD.OUTLOOK.COM>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: D15eT7cyYqK8905ODnKJKWJBv7W0fFzw8R5EgjGA0FIYZmciPBoW1t5yz1oFeK/vb8yH0I/1X9vIAakfIS0ubbUZd79m++Pww+IqqYF4Rz7xQbR/2nRYFh67D5eQRRRMfJNMphDIK5ykxRiOy1GyVpKTANgDg42Yil5n0bPBKwCLZHhsLiGHcB0ihisTmDPv+Iu6kszIz9L+hgARHe4mM3hrF22/40nqBfKpTRQoBqAS3a0qT9KEjoxHGXWjOZRjKKFZV5HK+8r/EmYMGWU++z50WfsZudceOei20XXKesp4Z8FyvTfa34bIF3q+/ge9rNSVom2vyCcIM3Tll89yKnwF2Hkye7W4hf1B1Pfw+A+/nutjK8V261j+7Bkebo2IzuTttG/DKy7QqaR7pcgfIZa1dXzO7JZWC0IwQ8p+e8xpwJOQ8G/ha7dgyKsEGNQ4mNqbNxb9srRI3i2I+3LJFdZjEnxze9vtJmCZsBHdZUp8Gi00IkanlNWByf2IQNylzAlhQ7Epx2+1H3vi74Gc+vOwxel3BV/Do7Mebd39F1DDDn/E/K9eD4ytif6k5LPcrZ56rFvcDpQ3zIp6zOZO4ihbGk/E7Qy4Rja3/o3NTpDpVgznjMrAsefTmhmVYkF+kzE5evDeqfT1HGwnjGC6dPEe4yFn/TI/qxPbR33QIunj0+GkffhSVpW3AYmHNJnQN8fFMlh8m66larAvHgnRJ91HqduGhFmCo79Nv+vgk769LmayTmTge5AimyFGRuIre4tpJLAOskoxeDn8ilODg0V46WhxPgXsyEJCVqNPREc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0P190MB1978.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230001)(366004)(136003)(376002)(396003)(39830400003)(346002)(38070700005)(64756008)(83380400001)(122000001)(186003)(5660300002)(8676002)(4326008)(38100700002)(8936002)(52536014)(33656002)(55016003)(2906002)(44832011)(316002)(66476007)(66946007)(86362001)(966005)(66446008)(76116006)(66556008)(41300700001)(9686003)(6506007)(7696005)(54906003)(166002)(71200400001)(508600001)(6916009); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0: dnf+6SLCm0nbaF0xCPm3vlw1dAAYdLXER9eLcS2wCBSRLJlrDTbgne88G33mInnoRo5coR7gfZEtsR8qfkmdt706hwJh9F1Ljducd1/1lsmnHKgI5Iw4X+OFu/vGG6yjP/oiHm1tEZrgwpoO2DhkMw/206wk4KzLKqxOwzMH5OAc/pLgT1tBKvRuXXwy7zSsRVKAiwUG+9wa/MCjxQpuypE2BIUda/a9m0KcGA4lrJvEgsXDvLXy58SLnhqAV2lDzmnAao2z9wM1V0iSquLKhsxPnZaOK9SCTz7KQBvGXgD/Zdyk67M9xyHH2qY+0Un7rm70B7d9nsMpMlN/GWVYc3ApJcRq4pKc2bFLO1DsNcPxObF1vNbz2GXLHgyjEY3SMSomy/POxALNvNhIQXFNUHqBkXE/H0WFk3t3NxbbyKfM+yVj3pVcNbWkeH7IpSKdmR2WdlUQECuU3s+Zz7tEImhtBenaBC2S5V8Te2hvPrOb9aNLnGcNw469fb7ewtWPR6CG420X9EBWnUKbghQp1qHhVCqHyeEd4S9+PRToPuJoOLrymGYbsaU2NyaH0xjB6kHT8trqe7ka1HK+NHF/zLZOUeU03ZTCBKDUgUDeqWyUa/1I8rcM+QIfFnGva84lA6FTsXl9nqy8bPN851Eau9t33S0caOCCYFLh9xrqHlQ/bpHUxsN2SKYUVVgebj+oRCFyWMzs1JEGWcz5BlZ26RZ0H6QrnTg3YNMMlWHblVcQ0CfTB7wscfpojk73ySCODMzQ0dGcQhRwEiChXQVwdU5OOSZUJr3rZc3c7uRY0d6HQ9ysXnYUJRFbv+PD+v2w91nH+PfHLPaWqhnRwMZBggUXmjAfhJcsuJOJa/suN6Fgt+H5gSidloqfT2V2zykbV4WomLGKpmP4NLa8MJ66lXIspUaZ0XKGD7loU1Viw8+yR0TUUwarbKzoZwgENsreQ6IOV+eha3U8pOkohoh8GhG7jHP0VIQf8AJ7+xFvrqBnRiKqGliLdVMsmYOWKBQ+l9QKhQyBxClJbwxsAoSC1UQYJ5900YW/oVEXwOB1Na11OYk0RvzEOJ+cRxMdYUHARehWZmO0HL5EEdbfgJtXyTgyDEOUFSpVby8Jq4kzmDd8db4U0XkxSrZIo0B3+DRMw1EiYFUk9cQJ85ovSdGsjBUc7d2AaBulCWkAO1HKjmbiKd51Pj+YJbKC8nAmkRIK2NaXttxtNa/euw2glI6VPCZ2zr52LoXzORT8TNPIWTPVgbOtpROJwd3gAtSJb+IrqTQ3nORiB1xs3ugTrML6d9oimybLR0xMtf9lUZp4qGdotLxbN75cZWKBxr/Wdtu013nhwj/hb6mJTP7UAqbikRW9q4l6wg5keyQdbkDz6XyxGykwV1GmpsgLRYNgC9VGbW4FomJXsbWGQed2UbDH/0FEpHrx3RBcKIj8CZzOwv9QSuY5fdg/B2RO+dXLg7S5W1nNN5es3NT20A/KzVeRWPfuEyRSg5GZgUAZYlLi8I4tFRj/Uu2deWWJrIM/IX2mDa11mbJbbXcFK7OUhkJSKg/EBkfYWFo4uxQgIFbe2OESKouSy6YeC6Zpa8xeo2QtHQ7HJRPCPXipMo+qitvuQpY3Ll13JKW51shZRjJ0UwnGO47FWeMM34Lom4YZSBRDWGJbHlc9DHIUdJO1slLcLEquCk5F+/SY1G3/a2zYb1xHFWsizMdHXQ6Gs+yydkNKe/vyt7T56x6VnkVfc44/fY3FxBMNVJSUs/sFLsEYk4yNjmVXzPSQ3S5q6OULYu0o3u5TgCia
x-ms-exchange-antispam-messagedata-1: JyfvazirReFcy2ZQo7lL/c4zG6C5RyyW9N0=
Content-Type: multipart/alternative; boundary="_000_DU0P190MB19784C8ED1D37EDBF4E0E7E0FDDE9DU0P190MB1978EURP_"
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0P190MB1978.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 5256c5fa-aaab-4e10-b658-08da4479ee76
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2022 09:26:10.8366 (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: wzOyDfJB1Jb0J2J8ACa+It+mgSVK9BrbAPgF1GGfKGc4bTT9gknJo7fD1chlq+UF5SHRtu3z0byK1Sq8QEGvtm+4EV1BHc6dfl98hJcbkFk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7P190MB0598
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/rDgw56FPGvEOGBL2lW7kYtXkoqU>
Subject: [core] draft-groupcomm-proxy: reverse proxies & URI embedding
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 02 Jun 2022 09:26:23 -0000

Hi all,

During last interim we discussed some potential issues in the use of a reverse proxy for group communications, see https://datatracker.ietf.org/doc/html/draft-tiloca-core-groupcomm-proxy-06#appendix-A.1 . This example is based on URI mapping as used for RFC 8075 for a HTTP client that wants to access a CoAP resource.

Just to clarify, there are at least these 2 categories of ‘reverse proxy usage’ cases possible:


  1.  Client’s application process is well aware that it is using a reverse-proxy. Client’s HTTP/TC/IP stack is not aware that it is accessing a reverse proxy: for its purposes, it looks just like an origin HTTP server.  The HTTP stack may just be some default or off-the-shelf component, e.g. a Javascript library, or a HTTP stack embedded in a Wi-Fi module.
  2.  Client’s application process is not aware of any reverse-proxy functionality. It just received a URI to resolve from some external input (e.g., a user typing or scanning a QR code) and it tries to perform the request as usual thinking it will get only HTTP response. Similarly, the HTTP stack is not aware that it’s accessing any proxy. The application process just receives the (single) HTTP response and stores it or may send it to the user, or another external process.

What many people think about when they hear “reverse proxy” is case 2; however case 1 also has some practical usefulness. Now for the HTTP client case of RFC 8075 both cases could be supported, if I remember correctly.

Suppose now the HTTP client becomes a CoAP client as in the Appendix A.1 example. Then the feedback in the interim meeting was if I recall correctly, that the CoAP client wouldn’t work correctly. In both cases 1/2, the application process would only receive the very first response (out of multiple) and use it, ignoring the rest. And considering the transaction as closed, freeing the token value that was used. That means the client might re-use the token for a next request even while for the first request the proxy is still sending back responses to the client. (Client then associates responses to the wrong request, potentially – bad!)

So I recall from the discussion that necessarily the client has to be aware that it is talking to a ‘group communication’ proxy , to apply the right token processing and expiry. And the best way to guarantee that is by requiring the client to include the Multicast-Timeout option. Is that correct?

Now the next question is, if this CoAP client is aware of the proxy and must anyhow include the Multicast-Timeout option so it already has dedicated code to do that, why doesn’t this client then use the standard Forward Proxy functionality of CoAP?  There’s no need anymore to embed for example the CoAP URI into the URI path as in the example A.1 , because the client could just use a Proxy-URI option which would make the proxy a “Forward Proxy” instead of a reverse proxy. Any views on this?  If this argument holds then we could just remove any reverse proxy examples and say the client has to invoke the standard CoAP proxy methods in its request.

Best regards
Esko