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

[Esko Dijk <[e-mail]>]

Hi all,

Since I did not see any views on this matter, I’ll just propose a way forward for groupcomm-proxy :-)

We can define then the 2 types of proxy:


  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.

Regards
Esko

From: core <[e-mail]> On Behalf Of Esko Dijk
Sent: Thursday, June 2, 2022 11:26
To: core <[e-mail]>
Cc: Christian Amsüss <[e-mail]>
Subject: [core] draft-groupcomm-proxy: reverse proxies & URI embedding

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