Re: [core] coap discovery

Christian Amsüss <christian@amsuess.com> Tue, 17 August 2021 17:19 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 DD5733A231B for <core@ietfa.amsl.com>; Tue, 17 Aug 2021 10:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 d6LIOBSnPShF for <core@ietfa.amsl.com>; Tue, 17 Aug 2021 10:19:50 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811BE3A2376 for <core@ietf.org>; Tue, 17 Aug 2021 10:19:47 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7D30540104; Tue, 17 Aug 2021 19:19:43 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2C23AD0; Tue, 17 Aug 2021 19:19:42 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:8d88:bd61:7974:fcd3]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id F2BB446; Tue, 17 Aug 2021 19:19:41 +0200 (CEST)
Received: (nullmailer pid 3885988 invoked by uid 1000); Tue, 17 Aug 2021 17:19:41 -0000
Date: Tue, 17 Aug 2021 19:19:41 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Peter van der Stok <stokcons@bbhmail.nl>, core@ietf.org
Message-ID: <YRvvrdUIms4EHc+a@hephaistos.amsuess.com>
References: <4795365b6cd768eb1b9500e0e96736b4@bbhmail.nl> <YRuwIjlxDtfygpq/@hephaistos.amsuess.com> <8819.1629217674@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sJI7M/WI5299mUK0"
Content-Disposition: inline
In-Reply-To: <8819.1629217674@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/GOxsw_phXMYbOmFCPuoOjurC3_E>
Subject: Re: [core] coap discovery
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: Tue, 17 Aug 2021 17:19:56 -0000

On Tue, Aug 17, 2021 at 12:27:54PM -0400, Michael Richardson wrote:
> Because, it is CoAP in DTLS in stuff.

Ah, so it's now with DTLS and that makes it messy. OK, can live with
that.

> Between Pledge and Register, it is supposed to look like CoAP-in-DTLS.
> 
> Between Pledge and Join Proxy, it's CoAP-in-DTLS (over IPv6-LL)
> Between Join Proxy and Register, it's CoAP-in-DTLS-in-"CBORUDP" (over ULA/GUA).
> 
> The "CBORUDP" provides for a stateless (i.e. stored in the network) record
> of where the packets come from.

So a bit like HTTP's CONNECT, and because there's CoAP as a transport
and since 8974 it has extended tokens, it can be stateless. Got it.
(Will this be specified for standalone use? I don't know to think of it
yet, but it's definitely intriguing).

If I've formed the right mental model here, there's two things that the
proxy can discover on the register (where 2001:db8:1:: might be the
actual network, and 2001:db8:2:: the network that's inside the UDP
tunnels -- may be the same addresses but may be not):

* The endpoint of the CoAP UDP service:
  <coap://[2001:db8:1::1]/udp>;rt=cborudp (or ;rt=brski-yyy)

* The endpoint of the actual registration service:
  <coap://[2001:db8:2::1]/j>;rt=...
  (or is it just <coap://6tisch.arpa/j>;rt=... ?)

If so, and if the analogy from 9031 holds, then what the proxy needs to
discover is the /udp endpoint. To that endpoint, it does talk CoAP, so
it's perfectly legitimate to discover it as a CoAP resource. Of the
inside traffic, or its relation to the outside resource, no statement
even needs to be discovered.

(There might be interesting material in this for
core-protocol-indication in that now we have a metadatum of a transport,
that is, through which tunneling endpoint its hidden address can be
reached, but that's more for theoretical observation; for practical one
I think that discovering the CBORUDP entry point would suffice).

HTH
c

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