From c6d10a93489e817efd48498dc9cb2f03480d052b Mon Sep 17 00:00:00 2001 From: David Goulet Date: Wed, 11 Jan 2023 10:14:19 -0500 Subject: prop340: Move stream_id to body becoming a per command value Signed-off-by: David Goulet --- proposals/340-packed-and-fragmented.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md index e7f08f4..0d83f67 100644 --- a/proposals/340-packed-and-fragmented.md +++ b/proposals/340-packed-and-fragmented.md @@ -66,12 +66,16 @@ Relay _messages_ now follow the following format: Header command u8 length u16 - stream_id u16 Body data u8[length] We require that "command" is never 0. +One big change from the current tor protocol is the missing `stream_id` which +we propose to move into the body because most commands set it to 0 because +they don't need it. Meaning that the `stream_id` becomes a value specified +per-command. + Messages can be split across relay cells; multiple messages can occur in a single relay cell. We enforce the following rules: @@ -191,8 +195,8 @@ cell. Here it is a BEGIN message. message header: command BEGIN [1 byte] length 23 [2 bytes] - stream_id (...) [2 bytes] message body + stream_id (...) [2 bytes] "www.torproject.org:443\0" [23 bytes] end-of-messages marker 0 [1 byte] @@ -215,8 +219,8 @@ across two relay cells. message header: command EXTEND [1 byte] length 800 [2 bytes] - stream_id 0 [2 bytes] message body + stream_id 0 [2 bytes] (extend body, part 1) [488 bytes] Cell 2: @@ -249,14 +253,13 @@ message in the same cell. message header: command BEGIN_DIR [1 byte] length 0 [2 bytes] - stream_id 32 [2 bytes] message body: - (empty) --- [0 bytes] + stream_id 32 [2 bytes] message header: command DATA [1 byte] length 25 [2 bytes] - stream_id 32 [2 bytes] message body: + stream_id 32 [2 bytes] "HTTP/1.0 GET /tor/foo\r\n\r\n" [25 bytes] end-of-messages marker 0 [1 byte] @@ -281,8 +284,8 @@ above; this is only an example of what parties need to accept.) message header: command DATAGRAM [1 byte] length 1200 [2 bytes] - stream_id 99 [2 bytes] message body + stream_id 99 [2 bytes] (datagram body, part 1) [488 bytes] Cell 2: @@ -307,16 +310,16 @@ above; this is only an example of what parties need to accept.) message header: command SENDME [1 byte] length 23 [2 bytes] - stream_id 0 [2 bytes] message body: + stream_id 0 [2 bytes] version 1 [1 byte] datalen 20 [2 bytes] data (digest to ack) [20 bytes] message header: command XON [1 byte] length 1 [2 bytes] - stream_id 50 [2 bytes] message body: + stream_id 50 [2 bytes] version 1 [1 byte] end-of-messages marker 0 [1 byte] -- cgit v1.2.3-54-g00ecf From 0fc6d07d88f0af8d87b12df4cd9890eabc5e6547 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Fri, 3 Feb 2023 13:01:24 -0500 Subject: More verbage in prop340 about the stream_id transition. Specifically: * Mention this change in the introduction. * Add a section explaining how to change tor-spec and related proposals. --- proposals/340-packed-and-fragmented.md | 48 ++++++++++++++++++++++++++++++---- 1 file changed, 43 insertions(+), 5 deletions(-) diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md index 0d83f67..6fb1ca5 100644 --- a/proposals/340-packed-and-fragmented.md +++ b/proposals/340-packed-and-fragmented.md @@ -33,6 +33,9 @@ This proposal combines ideas from [ntor v3](./332-ntor-v3-with-extra-data.md) and prepares for [next-generation relay cryptography](./308-counter-galois-onion). +Additionally, this proposal has been revised to incorporate another +protocol change, and remove StreamId from the relay cell header. + ## A preliminary change: Relay encryption, version 1.5 We are fairly sure that, whatever we do for our next batch of relay @@ -71,10 +74,9 @@ Relay _messages_ now follow the following format: We require that "command" is never 0. -One big change from the current tor protocol is the missing `stream_id` which -we propose to move into the body because most commands set it to 0 because -they don't need it. Meaning that the `stream_id` becomes a value specified -per-command. +One big change from the current tor protocol is something that is _not_ +here: we have moved `stream_id` into the body of the relay message of +those commands that need it. Messages can be split across relay cells; multiple messages can occur in a single relay cell. We enforce the following rules: @@ -96,7 +98,7 @@ Receivers MUST validate that headers are well-formed and have valid lengths while handling the cell in which the header is encoded. If the header is invalid, the receiver must destroy the circuit. -### Some examples + ## Negotiation @@ -113,6 +115,42 @@ The `version` field is the `Relay` subprotocol version that the client wants to use. The relay must send back the same extension in its ntor3 handshake to acknowledge support. + +## Specifying the message format with moved stream ID. + +Here, we'll specify how to adjust tor-spec to describe the `stream_id` +move correctly. + +Below, suppose that `Relay=V` denotes whatever version of the relay +message subprotocol denotes support for this proposal. + +For all relay message types that include a stream ID, we insert +the following at the beginning of their fields: + +>``` +> STREAM_ID [2 bytes] (Present when Relay protocol version >= V). +>``` + +We add a note saying: + +> STREAM_ID is part of many message types, when using Relay protocol +> version V or later. Earlier versions of the Relay protocol put +> STREAM_ID in the RELAY header. In those versions, the field is +> STREAM_ID omitted from the message. +> +> Except when noted, STREAM_ID may not be zero. + +The following message types take required stream IDs: `BEGIN`, `DATA`, `END`, +`CONNECTED`, `RESOLVE`, `RESOLVED`, and `BEGIN_DIR`, `XON`, `XOFF`. + +The following message type takes an *optional* stream ID: `SENDME`. +(*Stream-level sendmes are not a thing anymore with proposal 324, but I +want to give implementations the freedom to implement prop324 and this +proposal in either order.*) + +The following message types from proposal 339 (UDP) take required stream +IDs: `CONNECT_UDP`, `CONNECTED_UDP` and `DATAGRAM`. + ## Migration We add a consensus parameter, "streamed-relay-messages", with default -- cgit v1.2.3-54-g00ecf