[torspec] branch main updated (ca400dc -> 103c772)
This is an automated email from the git hooks/post-receive script. dgoulet pushed a change to branch main in repository torspec. from ca400dc rend-spec: Document how the cross-certificates (don't) work. new c6d10a9 prop340: Move stream_id to body becoming a per command value new 0fc6d07 More verbage in prop340 about the stream_id transition. new 103c772 Merge branch 'tor-gitlab/mr/102' The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: proposals/340-packed-and-fragmented.md | 61 ++++++++++++++++++++++++++++------ 1 file changed, 51 insertions(+), 10 deletions(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.
This is an automated email from the git hooks/post-receive script. dgoulet pushed a commit to branch main in repository torspec. commit c6d10a93489e817efd48498dc9cb2f03480d052b Author: David Goulet <dgoulet@torproject.org> AuthorDate: Wed Jan 11 10:14:19 2023 -0500 prop340: Move stream_id to body becoming a per command value Signed-off-by: David Goulet <dgoulet@torproject.org> --- 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] -- To stop receiving notification emails like this one, please contact the administrator of this repository.
This is an automated email from the git hooks/post-receive script. dgoulet pushed a commit to branch main in repository torspec. commit 0fc6d07d88f0af8d87b12df4cd9890eabc5e6547 Author: Nick Mathewson <nickm@torproject.org> AuthorDate: Fri Feb 3 13:01:24 2023 -0500 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 -- To stop receiving notification emails like this one, please contact the administrator of this repository.
This is an automated email from the git hooks/post-receive script. dgoulet pushed a commit to branch main in repository torspec. commit 103c7720c0e6c16d2e964dfebc566f47053ef121 Merge: ca400dc 0fc6d07 Author: David Goulet <dgoulet@torproject.org> AuthorDate: Mon Feb 6 09:03:51 2023 -0500 Merge branch 'tor-gitlab/mr/102' proposals/340-packed-and-fragmented.md | 61 ++++++++++++++++++++++++++++------ 1 file changed, 51 insertions(+), 10 deletions(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.
participants (1)
-
gitolite role