[core] Stateless Block1+2 proxy in echo-request-tag and stateless-proxy

Christian Amsüss <christian@amsuess.com> Tue, 03 March 2020 13:22 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D633A0CE8 for <core@ietfa.amsl.com>; Tue, 3 Mar 2020 05:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 Hqpfje5jXj0F for <core@ietfa.amsl.com>; Tue, 3 Mar 2020 05:22:32 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFED73A0CD6 for <core@ietf.org>; Tue, 3 Mar 2020 05:22:31 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0510A40118 for <core@ietf.org>; Tue, 3 Mar 2020 14:22:30 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 10F69DB for <core@ietf.org>; Tue, 3 Mar 2020 14:22:29 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:751e:639b:a0a8:6c84]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 4E29537 for <core@ietf.org>; Tue, 3 Mar 2020 14:22:28 +0100 (CET)
Received: (nullmailer pid 968303 invoked by uid 1000); Tue, 03 Mar 2020 13:21:07 -0000
Date: Tue, 03 Mar 2020 14:21:07 +0100
From: Christian Amsüss <christian@amsuess.com>
To: core@ietf.org
Message-ID: <20200303132107.GD568382@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="tEFtbjk+mNEviIIX"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5Pc92j3uriocjRVjyeo90fySEwc>
Subject: [core] Stateless Block1+2 proxy in echo-request-tag and stateless-proxy
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2020 13:22:40 -0000

Hello CoRE,

handling blockwise in a stateless fashion is hard, and previous
discussion[1] stalled a bit.

My current impression is that both echo-request-tag and stateless-proxy
expect the other document to say how it's actualy done (and both
documents should be released soon), and nobody is quite sure what *can*
be said at all.


There is one pretty clear-cut case where "the simple thing" works:

Client sends request with Block1 partial data, and the proxy attaches
Request-Tag identifying the original client.

Even the pure Block2 case is a bit doubtful -- I *think* that a
stateless proxy could just forward *safe* requests with Block2 in
request and/or response as long as there is no Block1 around, but I'm
not sure.

When Block1+Block2 comes in, it gets tricky, because

a) some argument is needed that a Request-Tag makes sense at all with
Block2 (it does, as it can be a legitimate leftover from a reassembly,
and can't be changed when going from the Block1 to the Block2 phase),
and

b) the proxy can't statelessly determine whether a late POST with
Block2:n message should have a Request-Tag (as it might belong to a POST
Block1:m messagee that had one), or not (because it might belong to a
POST with no mention of a Block option and thus no Request-Tag) -- at
least not without Request-Tagging *every* message which is clearly
excessive.

I think that a bit more than the clear-cut case can be salvaged, but
honestly am not much driven to make a scenario work for which our best
example is a SOAP exchange.

So, questions to the group:

* Which document should the procedure and limitations be described in
  (I'd suggest stateless, as the Block2 case needs reasoning that's
  unrelated to Request-Tag), and

* are there any better ideas than "Sorry, no stateless forwarding" for
  Block1+Block2 or non-safe Block2?

KR
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/pA1MIF4S0__mwvq3h2XLWybreWw


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