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

[Esko Dijk <[e-mail]>]

Hi Christian,

Thanks for the clarifying notes on the proposal - that's indeed what I intended. So I'll try to integrate this view into the draft!

Regards
Esko

-----Original Message-----
From: Christian Amsüss <[e-mail]> 
Sent: Tuesday, June 14, 2022 15:38
To: Esko Dijk <[e-mail]>
Cc: core <[e-mail]>; Marco Tiloca <[e-mail]>
Subject: Re: draft-groupcomm-proxy: reverse proxies & URI embedding

Hello Esko,

(going with the second mail first because that's quick to answer, and
may suffice):

>   1.  Forward Proxy
>      *   Client MUST include Multicast-Timeout option in its CoAP request.
>      *   Client includes the usual CoAP options to construct the proxy URI, using Proxy-Uri or Proxy-Scheme etc.
>      *   Proxy constructs the group communication request URI based on above options.
>   2.  Reverse Proxy
>      *   Client MUST include Multicast-Timeout option in its CoAP request.
>      *   By the above option it follows that the client is aware of accessing a proxy and that its code is prepared to correctly handle multiple CoAP responses to 1 request.
>      *   Client includes the usual CoAP option to access a resource on the server/proxy, i.e. Uri-Path, Uri-Query and in rare cases Uri-Host/Uri-Port.
>      *   The reverse proxy has its own, custom, logic of constructing the groupcomm request URI i.e. deciding which resource leads to which groupcomm request.

I agree with the proposal, noting that

* I understand "client is aware of accessing a proxy" to roughly mean
  "is aware that this behaves like a multicast proxy request" (but
  doesn't necessarily need to do anything else about this being a
  proxy), and

* I understand the MUST as "MUST in order to gain multicast forwarding".

  If the option is absent, the proxy may exhibit a configured unicast
  behavior, or refuse proxying, eg. with 4.00 Bad Request,
  Content-Format: application/consise-problem-details+cbor, payload
  {'multicast-resource': 10} indicating a realistic timeout value)



That probably suffices; the rest is merely arguing for why I see it that
way.


On Thu, Jun 02, 2022 at 09:26:10AM +0000, Esko Dijk wrote:
> 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.

I think that's only appropriate for an HC proxy: HTTP clients generally
don't accept non-HTTP URIs even if they could just forward them into an
HTTP proxy whose `request-line` ABNF formally accepts non-HTTP URIs.
CoAP was specifically designed not to have that limitation, and thus
doesn't need that workaround.

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

Yes.

I recommend taking a mindset in which this is not about "proxy" but
about the address having the "is a multicast destination" property
(which is implicit in IP when using a multicast address in UDP, and
explicitly indicated in basically-unicast situations by
Multicast-Timeout) -- but given that the main user of this option is
proxies, it might be easier writing to just talk of proxies.

An example of using this in a non-proxy environment is when there is
name based virtual hosting, and a server could respond to `GET
coap://ip-address/.well-known/core Multicast-Timeout:1` with the WKCs of
all its virtual hosting servers, each with a Response-Forwarding option
indicating the adequate host name -- I doubt anyone would want to
implement it that way, but if you like to have a mental example of how a
multicast requests works in a non-proxy situation, there it is.

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

I think that's because both

* a URI is easier to transport (say, in a QR code) than a URI with the
  information about which proxy to use (even if it's only a bit of
  information that says to send it to wherever the name resolves), and

* the forward proxy a client uses is more a matter of system
  configuration, whereas the URI to go to is user guided. An application
  may allow "untrusted sources" to set the URI to derefernce, but not to
  set the proxy to use.

Note that due to the Multicast-Timeout property being elective, a client
can just be prepared to receive multicast addresses without any further
indication. An application could thus have an input field "entry points"
that accepts any number of URIs, some of which may be multicast, and
just send a Multicast-Timeout if there is doubt anywhere that something
could maybe respond thusly.

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

I'd welcome the examples going away -- after all, this is a corner case.
If the text manages to describe all relevant properties of the options
in a sufficiently generic way, a two-line statement about the options
working the same way when the client expects that multicast-like
responses can be returned from a request that does not carry a proxy
option.

BR
c

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