[Lwip] Examples of lock-step protocols
Christian Amsüss <christian@amsuess.com> Tue, 08 June 2021 14:52 UTC
Return-Path: <christian@amsuess.com>
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 3796A3A3303; Tue, 8 Jun 2021 07:52:16 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-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 nT3d-dKb44Km; Tue, 8 Jun 2021 07:52:13 -0700 (PDT)
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 68ACE3A1811; Tue, 8 Jun 2021 07:52:09 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4E04B40895; Tue, 8 Jun 2021 16:52:05 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C2A78D7; Tue, 8 Jun 2021 16:52:03 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [141.244.84.125]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 739C67D; Tue, 8 Jun 2021 16:52:03 +0200 (CEST)
Received: (nullmailer pid 2851787 invoked by uid 1000); Tue, 08 Jun 2021 14:52:02 -0000
Date: Tue, 08 Jun 2021 16:52:02 +0200
From: Christian Amsüss <christian@amsuess.com>
To: core@ietf.org
Cc: lwip@ietf.org, draft-ietf-ace-wg-coap-eap@ietf.org, draft-ietf-lake-edhoc@ietf.org
Message-ID: <YL+EEn5rNKp7aOP7@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="dsGaW19CM8c9MMe6"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/Brw7emRpMFffDIuUPvengLA33ZI>
Subject: [Lwip] Examples of lock-step protocols
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <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: Tue, 08 Jun 2021 14:52:16 -0000
Hello CoRE, hello implementers of lock-step authentication protocols on top of it, based on discussion around how to implement EAP on CoAP, and in parallel on EDHOC discussions (and triggered by Carsten's clarifying comment in today's ACE meeting), I've expanded the CoAP FAQ[1] by an item on how lock-step protocols are best done. (Full text below the mail). EAP is given as a best-practice example; to EDHOC it doesn't apply in full, and EDHOC does to an extent need to go its own way, especially as the connection identifiers are part of the running protocol (given they're used later on, eg. for OSCORE Sender-IDs), and need more expressitivity than just the UTF-8 strings usable inside paths. I don't think that there is any current LWIG document where it'd make sense to add it, but if so, please let me know and I'd try to fit it in. If you disagree or would like to add to it, please edit the wiki or just continue this thread. BR Christian [1]: https://github.com/core-wg/wiki/wiki/CoAP-FAQ -- prominent caveat: Answers are provided by various editors, can be conflicting, and do not necessarily reflect any working group consensus. Full text of the new item: Q: I'd like to run my lock-step protocol over CoAP (where one device sends a message, then the other sends a message, until some sequence is completed), and need a reliable way to not lose messages or get duplicate ones. How do I do that? A: In a typical and idiomatic solution, there is an entry point URI to which the client POSTs the first message. The server then sends the response in a 2.01 Created response as a payload, and indicates in Location-Path options where the next POST request should go. The client then POSTs the next message there, receives a new Location-Path. A typical (easy-to-debug) pattern of URIs for a given "service" would be /service/ as an entry point, with a random identifier (eg. 0f4ef9bc) used for the individual exchange, and a message counter. Thus, the first POST would go to /service/ containing the first message, the response would contain the second message and a Uri-Location of /service/0f4ef9bc/3. The third message would be sent to /service/0f4ef9bc/3, and the response would contain the fourth message and /service/0f4ef9bc/5 et cetera. This is never a rule, though -- in any such protocol, any server can pick completely arbitrary paths, and while the protocol may place constraints on the maximum length of the path, the client may not place assumptions on the path or read anything into it. The server can correlate and sort the messages by structuring the addresses used for them, and the client can correlate and sort the messages by the request-response matching (through the token) as it knows to which of its own messages it is the successor. The document draft-ietf-ace-wg-coap-eap provides an example of such an exchange. As many constrained servers do not implement message deduplication, such a scheme (relying on POST which is not on by default idempotent) can be difficult. These implementations can be accommodated for by specifying that the client may only send a request once to each received URI, and that duplicate messages are responded to with the latest sent message. Thus, the server can forego message deduplication on the CoAP layer for these resources, and the implementation would just need to check whether the message number encoded in the request URI is the expected next (in which case it's processed normally), or whether it's the one befoer (in which case the request payload is discarded, and the exchange's last state is used to send the last response again). (Even earlier messages can be discarded, and answered e.g. with a 4.04 Not Found). -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [Lwip] Examples of lock-step protocols Christian Amsüss