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

Christian Amsüss <> Thu, 12 March 2020 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0F4C3A0C87 for <>; Thu, 12 Mar 2020 08:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.624
X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HbVpOBHWpEkN for <>; Thu, 12 Mar 2020 08:58:35 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E2D413A0C7C for <>; Thu, 12 Mar 2020 08:58:33 -0700 (PDT)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by (Postfix) with ESMTPS id DF9CE40028; Thu, 12 Mar 2020 16:58:31 +0100 (CET)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by (Postfix) with ESMTP id 16934DB; Thu, 12 Mar 2020 16:58:31 +0100 (CET)
Received: from (unknown [IPv6:2a02:b18:c13b:8010:29c1:94b7:fce6:3020]) by (Postfix) with ESMTPSA id 51352148; Thu, 12 Mar 2020 16:58:30 +0100 (CET)
Received: (nullmailer pid 378254 invoked by uid 1000); Thu, 12 Mar 2020 15:58:29 -0000
Date: Thu, 12 Mar 2020 16:58:29 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
To: Esko Dijk <>, Marco Tiloca <>
Cc: "" <>
Message-ID: <>
References: =?utf-8?q?=3CAM5P190MB02753814229668BC943A5C02FDFC0=40AM5P190MB0?= =?utf-8?q?275=2EEURP190=2EPROD=2EOUTLOOK=2ECOM=3E?=
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e"
Content-Disposition: inline
In-Reply-To: =?utf-8?q?=3CAM5P190MB02753814229668BC943A5C02FDFC0=40AM5P190MB?= =?utf-8?q?0275=2EEURP190=2EPROD=2EOUTLOOK=2ECOM=3E?=
Archived-At: <>
Subject: Re: [core] New draft-tiloca-core-groupcomm-proxy on proxied CoAP multicast operation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Mar 2020 15:58:39 -0000

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

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

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

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

* 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

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

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

Best regards, and thanks for working on that document

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