Re: [Lwip] [core] Proxies and observations: "All options MUST be identical"
Christian Amsüss <c.amsuess@energyharvesting.at> Mon, 13 November 2017 17:43 UTC
Return-Path: <c.amsuess@energyharvesting.at>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C012946B; Mon, 13 Nov 2017 09:43:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I5MEwUgeWRE; Mon, 13 Nov 2017 09:43:18 -0800 (PST)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE121200F3; Mon, 13 Nov 2017 09:43:18 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5FB5C488EF; Mon, 13 Nov 2017 18:43:16 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 9931744; Mon, 13 Nov 2017 18:43:15 +0100 (CET)
Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6345531; Mon, 13 Nov 2017 18:43:15 +0100 (CET)
Received: (nullmailer pid 5334 invoked by uid 1000); Mon, 13 Nov 2017 17:43:14 -0000
Date: Mon, 13 Nov 2017 18:43:14 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: Klaus Hartke <hartke@projectcool.de>
Cc: lwip@ietf.org, "core@ietf.org WG" <core@ietf.org>
Message-ID: <20171113174314.7ohihr724xaxrp7l@hephaistos.amsuess.com>
References: <20171113165421.d23nmwklwjfwxaem@hephaistos.amsuess.com> <CAAzbHvaNvodqVfu+cD3K2JijSn=4nQB2mZRnRSV81bq+r0AFsw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="7arkkdv2cdxc2sfe"
Content-Disposition: inline
In-Reply-To: <CAAzbHvaNvodqVfu+cD3K2JijSn=4nQB2mZRnRSV81bq+r0AFsw@mail.gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/_N58_03zKNRIoy1RyldgXn8H9dY>
Subject: Re: [Lwip] [core] Proxies and observations: "All options MUST be identical"
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2017 17:43:20 -0000
Hello Klaus, thanks for your reply. On Mon, Nov 13, 2017 at 06:23:59PM +0100, Klaus Hartke wrote: > If it's a new observation, then the client should not use a token that > is still in use. RFC 7252 Section 5.3.1: > > The client SHOULD generate tokens in such a way that tokens currently > in use for a given source/destination endpoint pair are unique. My hypothetical client was using the "but I already cancelled, it's not in use any more, didn't you get the NON?" defense -- but fair point. > In case a server (or proxy in the role of a server) receives an > observation request with a token that is still in use, it must kill > the existing observation. RFC 7641 Section 4.1: > > [...] > > So the server already doesn't enforce the client requirement. Hmpf, that would mean that a correct proxy would treat an OSCORE re-registration with new (encrypted) ETag set as a new observation. It would determine that the old observation is over, cancel its observation to the origin server and start a new one, presumably (under the abovementioned) using a new token. Should work, but it's a new observation at the origin. A very smart proxy might even notice that rather than cancelling the observation, it can start the new one on the same token and thus do both cancellation and new registration in a single packet (making things magically smoother), but that might be considered smart to the extent of specification abusal. A less smart proxy might even decide to let the old observation cancel itself by forgetting it and open the new one, resulting in two simultaenous registrations at the origin -- not ideal, but maybe tolerable. Do you think there is a practical way around this that is not "OSCORE observations can never be renewed (can never have a bit different, thus no new nonce, no new freshness and no new ETags), and to renew an OSCORE observation you have to cancel the old one and register a new one"? Best regards Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [Lwip] Proxies and observations: "All options MUS… Christian Amsüss
- Re: [Lwip] Proxies and observations: "All options… Carsten Bormann
- Re: [Lwip] [core] Proxies and observations: "All … Klaus Hartke
- Re: [Lwip] [core] Proxies and observations: "All … Christian Amsüss
- Re: [Lwip] [core] Proxies and observations: "All … Klaus Hartke