Re: [core] Interest in defining CoAP over Unix Domain sockets?

Christian Amsüss <christian@amsuess.com> Thu, 15 June 2023 11:53 UTC

Return-Path: <christian@amsuess.com>
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 25E6FC14CE36 for <core@ietfa.amsl.com>; Thu, 15 Jun 2023 04:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 YNBI6mNsogmE for <core@ietfa.amsl.com>; Thu, 15 Jun 2023 04:53:17 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318FAC14CE2C for <core@ietf.org>; Thu, 15 Jun 2023 04:53:15 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.1/8.17.1) with ESMTPS id 35FBrDY7026312 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2023 13:53:13 +0200 (CEST) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 7076722F98; Thu, 15 Jun 2023 13:53:12 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.lan [IPv6:2a02:b18:c13b:8010::32b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 37AE1244CC; Thu, 15 Jun 2023 13:53:12 +0200 (CEST)
Received: (nullmailer pid 9310 invoked by uid 1000); Thu, 15 Jun 2023 11:53:11 -0000
Date: Thu, 15 Jun 2023 13:53:11 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>
Cc: core@ietf.org
Message-ID: <ZIr7p/t2jw7NILUW@hephaistos.amsuess.com>
References: <004601d90ee3$dd59df80$980d9e80$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="2ptUpSCckEeBcG3E"
Content-Disposition: inline
In-Reply-To: <004601d90ee3$dd59df80$980d9e80$@jpshallow.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/P0OQhWYNUjx4GewtqeZ29cE9aKM>
Subject: Re: [core] Interest in defining CoAP over Unix Domain sockets?
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, 15 Jun 2023 11:53:20 -0000

Hi Jon, list,

On Tue, Dec 13, 2022 at 11:13:01AM -0000, Jon Shallow wrote:
> There has been a request for supporting CoAP over Unix Domain sockets -
> primarily for a reverse proxy which is secured to the outside world but
> wants to distribute the CoAP traffic internally [...]

I agree this is a valuable use case.

I don't agree that we'd necessarily need to provide URIs for these: It
might make sense to make this a proxy-only hop. This would mean that

* the Uri-Host and Uri-Port options don't have default values (maybe
  it's an error to assume any value unless they are explicit), and/or
* it is mandatory to set Proxy-Scheme, Uri-Host (and, if different from
  the scheme's default), Uri-Port.

Implementations would probably want to do this anyway, for otherwise
the server would not know which address the client assumes to be the
Base URI, and experience deploying WebDAV behind reverse proxies shows
that that's problematic.

If the (socket) server decides to ignore those options, it may do so
with the same caveats with which a regular server would ignore a
Uri-Host (I don't know the list of caveats, and it's likely subtle, but
at least it's something people already do or do not ignore).

---

That being said, what other open questions are there? Off the top of my
head,

* The transport is reliable. Do we need MID and message types? (We
  stripped them for RFC8323 protocols)
* The transport is ordered. Do RFC8323's rule about Observe being empty
  in responses apply?
* The client can open the socket multiple times. Should it do so when
  sending multiple requests? If so, it we could also do away with
  tokens. (Admittedly I'm a sucker for token-less transports; the
  practical answer is probably still "no" for performance reasons).

I've always assumed that the UDP-to-socket thing is acting a proxy here,
with all the rights and responsibilities (like, the transport has no
MTU, thus applications may respond with arbitrarily large messages, and
the proxy will blockwise for them -- but also, unknown proxy-unsafe
options are showstoppers). If we go full same-wire-format, there is an
alternative: Treat this not like a proxy but like a port forwarder, and
open the socket anew for every new client. Then, it could forward even
completely unparsable messages. In that scenario, it may make sense to
send a signaling message first to tell the server what the actual
addresses (and characteristics like MTU) are.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom