Subject: [core] coap discovery

From: Peter van der Stok <[email-masked]>
Date: Fri, 13 Aug 2021 09:24:34 +0200

Hi CORE WG,

We met a problem with the specification of "join-proxy" used for the 
BRSKI protocol in ANIMA,

The join-proxy provides the connection between a new device (called 
pledge) and the registrar that authorizes the access to the network
for the pledge.
The join-proxy is an authorized node that can route messages to the 
Registrar.
The join-proxy also provides coap services on the network.
The pledge has only link-local acccess to a neighbour join-proxy

The pledge sends a link-local DTLS coap request to a resource on the 
join-proxy accessable via a non-coap port on the join-proxy.
The join-proxy copies the messages received on that port and sends them 
on to a non-standard discoverable port of the Registrar.
The join-proxy resources on the join-proxy are discoverable with  rt= 
brski_xxx

The pledge discovers the join-proxy resources and their non-standard 
port with coap discovery.

The protocol between join-proxy and Registrar is not coaps but an UDP 
protocol that forwards the coaps messages to the Registrar.
However, the join-proxy discovers the Registrar port by discovering a 
related coap resource and its port on the Registrar with rt = brski-yyy

Question:
Is this a legitimate use of coap discovery to discover the non-standard 
ports on join proxy and Registrar?

thanks for comments, or suggestions,

Peter
-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
tel NL: +31(0)492474673     F: +33(0)468839947

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 17 Aug 2021 14:48:34 +0200

Hi Peter,

> ports on join proxy and Registrar?

If that protocol is really not CoAP, it can be legitimately discovered,
but should IMO be indicated with a different protocol than coap, say
<brski://registrar-ip:port/registrar-resource>;rt=brski-yyy

However, just to get a better understanding, why is the protocol through
which the CoAP messages are forwarded between the join-proxy and the
registrar neither CoAP nor a new CoAP transport? (Just sounds like it'd
be working around the very shortcomics of CoAP proxies that RFC8974
resolved). Is this protocol described anywhere so far?

BR
c

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Aug 2021 12:27:54 -0400

Christian Amsüss <[email-masked]> wrote:
    > However, just to get a better understanding, why is the protocol
    > through which the CoAP messages are forwarded between the join-proxy
    > and the registrar neither CoAP nor a new CoAP transport? (Just sounds
    > like it'd be working around the very shortcomics of CoAP proxies that
    > RFC8974 resolved). Is this protocol described anywhere so far?

Because, it is CoAP in DTLS in stuff.

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.

In RFC9031, which uses OSCORE, and therefore has security *above* CoAP,
rather than security *below* CoAP, we use the CoAP (extended) token for the state.
(RFC8974).

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 17 Aug 2021 19:19:41 +0200

> 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.

> 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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Aug 2021 21:47:50 -0400

Christian Amsüss <[email-masked]> wrote:
    >> The "CBORUDP" provides for a stateless (i.e. stored in the network)
    >> record of where the packets come from.

    > yet, but it's definitely intriguing).

It's not like HTTP CONNECT.
It's a reverse proxy.  The destination is forced by the proxy.
In order to remove the memory state of the proxy, we store in the network.
For (EDHOC)/PSK-OSCORE over CoAP, the proxy can mess with CoAP options.
But, DTLS keeps us from doing that.

    > tunnels -- may be the same addresses but may be not):

Just to clarify, there is no IP header inside the tunnel.

    > <coap://[2001:db8:1::1]/udp>;rt=cborudp (or ;rt=brski-yyy)

yeah.

    > discover is the /udp endpoint.

    > To that endpoint, it does talk CoAP, so

No, that's not the case.  To the proxy, it speaks "cborudp".

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 18 Aug 2021 10:35:32 +0200

Ok, then I misunderstood; next attempt. Would it look roughly like this,
then?

+-----------+-------------+---------+----------------------+
| IP header | UDP header  | CBORUDP | DTLS containing CoAP |
+-----------+-------------+---------+----------------------+

where CBORUDP is some self-delimited prefix in which the proxy encodes
the pledge's address (probably opaque to the register), and by itself
doesn't care what precisely is encapsulated in it.

In that case, I'd advertise it either as

    <cborudp://[ip]:port>;rt=cborudp

which just announces that there is some service of that kind without
saying what can be done with it (although a more precise rel or rt may
say that), or as

    <coaps+cborudp://[ip]:port/j>;rt=some...join

which'd indicate that coaps can be transported through that and that
there is a /j resource available. This'd help the proxy to advertise an
own `<coaps://[fe80::...]/j>;rt=some..join` resource which it doesn't on
its own control, but still provides for in its reverse proxy capacity.
(Given that resource is probably not discovered, that may be of little
use).

For me, either would work; announcing a <coaps://[ip]:port/j> would IMO
be misleading if no requests really arrive there through CoAP on DTLS
directly on UDP.

BR
c

-- 
Build a man a fire, and he'll be warm for a day. Set a man on fire, and
he'll be warm for the rest of his life.
  -- Terry Pratchett (attributed)

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 18 Aug 2021 10:51:10 +0200

HI Christian,

very close indeed.

I would prefer:

for advertizing /j in another context as well.

My worries concern the impact on coap and the effort needed to 
standardize coaps+cborudp, remembering former efforts
concerning tcp and coap.

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Aug 2021 11:52:11 +0200

On 2021-08-18, at 10:35, Christian Amsüss <[email-masked]> wrote:
> CBORUDP

Is “CBOR” the main feature of that subprotocol?
Maybe we can find a better name.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Aug 2021 07:03:16 -0400

> Is “CBOR” the main feature of that subprotocol?  Maybe we can find a
    > better name.

Yeah, that's a terrible name, but we didn't make up anything else, because we
didn't think we needed to name it.  That's probably a goof.  names are always important.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Aug 2021 07:06:19 -0400

Yes, that's essentially it.
Although the "DTLS containing CoAP" is actually embedded in the CBOR.
But then, each of the things are embedded in the thing to the left.

>    <cborudp://[ip]:port>;rt=cborudp

Aside from the name, I hate having to make up a new scheme.

> be misleading if no requests really arrive there through CoAP on DTLS

Agreed.