Re: [core] New draft-tiloca-core-groupcomm-proxy on proxied CoAP multicast operation

[Esko Dijk <[e-mail]>]

Hello Christian,

Thanks for your review / skimming round! Please see our answers below marked "[GP]".

Regards
Esko

-----Original Message-----
From: Christian Amsüss <[e-mail]> 
Sent: Thursday, March 12, 2020 16:58
To: Esko Dijk <[e-mail]>; Marco Tiloca <[e-mail]>
Cc: [e-mail]
Subject: Re: [core] New draft-tiloca-core-groupcomm-proxy on proxied CoAP multicast operation

Hello Esko, hello Marco,
hello CoRE,

thanks for tackling this.

I'm only skimming over it in a first round, but a few things have come
up:

* Multicast-Signaling: Is this a CBOR unsigned integer or a CoAP uint?

[GP] Yes, that was indeed an oversight. We will change it to uint as it is totally fine for our scope.

* Response-Forwarding: Is this expected to be extensible to any other
  CoAP transport that may come up that supports multicast? The use of
  CBOR tags seems to imply that, but then there's the question of how
  the client would arrive at a URI for follow-up unicast communication.

  Have you considered just using values that'd go into Uri-Host in a
  follow-up request?

[GP] The use of CBOR tags was not on purpose to be prepared for future transports. It was more re-using a convention that was already there. But by doing it this way we are prepared for potential future transports, in which something else than an IPv4 or IPv6 or MAC address needs to be sent back to the client.
The current encoding is expected to be more efficient than providing an IP address as a Uri-Host string. The current encoding can also be re-used in a Uri-Host or Uri-Proxy Option sent towards a proxy, although the client needs to do some transcoding to get it into the string format used by CoAP.
If the client uses a direct unicast connection to reach the server (maybe this use case is less common?) then it doesn't use the returned IP address in the CoAP request; it will only use it in the destination IP address of the IP packet that is sent and then having it in a byte-by-byte format is quite useful.

* Why is the information about the client being behind a proxy
  forwarded? We don't to this in other proxying cases, and it just puts
  an additional burden on the origin server I don't see a compelling
  need for.

  From reading up to 5.3, I'd have expected that the proxy strip
  Multicast-Signaling when doing the actual multicast, and put back the
  Response-Forwarding option.

[GP]  Yes, that can also work - the Multicast-Signaling only goes up to the Proxy ; and the Proxy adds the IP address information to the response that's forwarded back to the client.
We opted for the current end-to-end solution to have the extra information (in both ways) secured so the Proxy can't tamper with it. (This works in combination with OSCORE.)
We see some pros and cons for both options. It would take some more analysis and discussion to decide which is best!


* At some point, as a WG we will need to think of whether we really want
  to have another option with Observe-like multiresponses; Block-wise
  and Observe being the two extensions so early everyone knew from
  RFC7252 they would come does put them into a special position.

  I do see the benefits of doing things this way -- it is way more
  efficient than anything I could think of that works across unaware
  proxies.

  If we see this as general enough to be one of the few ways to have
  longer-lived tokens, all is fine, and I am fine with that outcome, but
  would like to hear some WG discussion on whether we are as a group.
  In particular, that process should come up with some criterion of
  whether a mechanism is special enough to be another Observe.

  Otherwise, one option is to define a single one more generalized
  longlived-token mechanism that'd go along any option that starts an
  observationish process (and tells the proxy the eventual-consistency
  semantics of the request). Observe doesn't need that because it's been
  known all along, but if it weren't, it could be expressed in terms of
  that one option (plus its own option).

  If even that doesn't fly, the whole protocol would need to look very
  different (but I hope it won't come to that).

[GP] The concept of multiple responses (by the Proxy) to a client's request is already defined in RFC 7252 so it is not 'new' in that sense. The use of the Options as we define it, doesn't change that behavior.
Also in draft-ietf-core-groupcomm-bis we discuss the longer-lived Tokens issue; so that's inherently present in multicast situations (proxied or not).
Maybe we could use draft-ietf-core-groupcomm-bis to define the more general long-lived-token mechanisms? (Not sure yet what these would be, in general.)
This would require more discussion. Further input is welcome on what this generalized mechanism would look like.

* The proxy needs to authenticate the client, that's a sane requirement.

  In a situation where I alerady deploy OSCORE for E2E, it would be
  convenient to use OSCORE to protect the leg to the proxy as well.

  OSCORE rules that out per specification, but to my understanding
  that's not for technical reasons, but primarily due to how to
  everything is phrased as protecting and unprotecting a complete
  message rather than accessing options before and after unprotection.

  This would make a convincing use case for nested OSCORE, so I'd
  suggest thinking about this. It may help to describe it in terms of
  sending a message to a forward proxy; option classes might change in
  the course of that. (In particular, Uri-Host and OSCORE become Class E
  for that purpose).

[GP] Yes, we agree this looks like a very interesting use case for nested OSCORE protection. It appears to be feasible; we started doing some more analysis on this.

Best regards, and thanks for working on that document
Christian

[GP] Thanks again for this good feedback!

Best regards

Esko & Marco


IoTconsultancy.nl  |  Email/Skype: [e-mail] 



-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn