From 5bbec305dfb6c2a7ad46177c4c0ddd0c055808da Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 3 Oct 2023 11:14:50 -0400 Subject: pro340: Lightly clarify introduction of header formats. --- proposals/340-packed-and-fragmented.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md index 74af5ca..880647c 100644 --- a/proposals/340-packed-and-fragmented.md +++ b/proposals/340-packed-and-fragmented.md @@ -67,8 +67,9 @@ The `body` MUST contain exactly 493 bytes as cells have a fixed size. ## New relay message packing -We define this new format for a relay message which has to fit within one -relay cell. However, the body can be split accross many relay cells: +We define this new format for a relay message. We require that +both header parts fit in a single RELAY cell. +However, the body can be split across many relay cells: ``` Message Header -- cgit v1.2.3-54-g00ecf From 9810d5f71f3e5fb985da9a1aca9c05ebf9cfbbd4 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 3 Oct 2023 11:15:50 -0400 Subject: prop340: Note that we plan to change our migration approach. --- proposals/340-packed-and-fragmented.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md index 880647c..65a8d03 100644 --- a/proposals/340-packed-and-fragmented.md +++ b/proposals/340-packed-and-fragmented.md @@ -117,7 +117,10 @@ is encoded. If any of them is invalid, the circuit MUST be destroyed. An unrecognized `command` is considered invalid and thus MUST result in the circuit being immediately destroyed. -## Negotiation +## Negotiation (OBSOLETE) + +> We do not want to do it this way. Instead, we want to use the system +> described in the forthcoming proposal, "xxx-protovers-again.md". This message format requires a new `Relay` subprotocol version to indicate support. If a client wants to indicate support for this format, it sends the @@ -148,6 +151,9 @@ The client MUST reject the handshake and thus close the circuit if: ## Migration +> Note: This differs from what we decided was our new best-practices. +> Should we make this disableable at all? + We add a consensus parameter, "streamed-relay-messages", with default value 0, minimum value 0, and maximum value 1. -- cgit v1.2.3-54-g00ecf From c42bc9eb93990af822dad1ab886b7f333e1de55b Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 3 Oct 2023 11:16:12 -0400 Subject: prop340: Clarify RELAY_EARLY implications and add a parameter. I think this reflects our discussions on tor#40840. I had thought that this parameter existed, but it turns out that it doesn't. --- proposals/340-packed-and-fragmented.md | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md index 65a8d03..a473c3f 100644 --- a/proposals/340-packed-and-fragmented.md +++ b/proposals/340-packed-and-fragmented.md @@ -192,6 +192,38 @@ rendezvous circuits that we currently need to fragment or pack. The `RELAY_EARLY` status for a command is determined based on the relay cell in which the command's _header_ appeared. +Thus, a relay MUST close a circuit if the cell containing the _first_ +fragment of an `EXTEND` message is not `RELAY_EARLY`, and MUST allow +but NOT require `RELAY_EARLY` to be set on other cells. + +This implies that a client only _needs_ to set `RELAY_EARLY` on the cell +containing the _first_ fragment of an EXTEND message, but that it MAY +set RELAY_EARLY on other cells, in order to prevent traffic fingerprinting. + +(Note: As now, relays and clients MUST destroy any circuit upon seeing a +`RELAY_EARLY` message in the inbound direction.) + +> In our implementation, clients will continue to set `RELAY_EARLY` on +> the first N cells of each circuit, as we do today. + +> Note that this description allows us to take two approaches when +> we eventually _do_ support fragmented `EXTEND` messages. We can +> either set the `RELAY_EARLY` flag on the cell containing the first +> fragment only, or we can continue to set it on the first N cells +> sent on each circuit. Both will work fine, assuming that the +> limit of `RELAY_EARLY` cells is adjustable. This brings us to: + +#### Making the `RELAY_EARLY` limit adjustable + +We add the following parameter, to support an eventual migration to +longer extend cells, in case we decide to take the second approach in +our note above. + + "max_early_per_circ" -- Relays MUST destroy any circuit on + which they see more than this number of RELAY_EARLY cells. + Min: 5. Max: 65535. Default: 8. + + ### Handling `SENDME`s SENDME messages may not be fragmented; the body and the command must -- cgit v1.2.3-54-g00ecf From 77569cbf430ad686ec2c0422fae96747cbdc1d71 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 3 Oct 2023 11:16:57 -0400 Subject: prop340: Start a conflux section, and note an issue. --- proposals/340-packed-and-fragmented.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md index a473c3f..3f0742e 100644 --- a/proposals/340-packed-and-fragmented.md +++ b/proposals/340-packed-and-fragmented.md @@ -230,6 +230,22 @@ SENDME messages may not be fragmented; the body and the command must appear in the same cell. (This is necessary so authenticated sendmes can have a reasonable implementation.) +### Interaction with Conflux + +Fragmented messages may be used together with Conflux. Specifically, +we allow fragments from a single message to be sent on separate +legs of a single circuit bundle. + +> TODO: Mike, David, how would this actually work? +> +> It seems to me that it would require us to send a +> RELAY_CONFLUX_SWITCH message between two fragments of another +> message... but our framing protocol described above in "New relay +> mesage packing" does not provide a way to put a message between two +> fragments of another message. + + + ### An exception for `DATA`. Data messages may not be fragmented. (There is never a reason to do -- cgit v1.2.3-54-g00ecf From 3789c8786114021df87898a380131e8aa724d59f Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Wed, 1 Nov 2023 21:07:48 -0400 Subject: prop340: Clarify "interaction with conflux" --- proposals/340-packed-and-fragmented.md | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md index 3f0742e..822ba05 100644 --- a/proposals/340-packed-and-fragmented.md +++ b/proposals/340-packed-and-fragmented.md @@ -232,19 +232,15 @@ can have a reasonable implementation.) ### Interaction with Conflux -Fragmented messages may be used together with Conflux. Specifically, -we allow fragments from a single message to be sent on separate -legs of a single circuit bundle. - -> TODO: Mike, David, how would this actually work? -> -> It seems to me that it would require us to send a -> RELAY_CONFLUX_SWITCH message between two fragments of another -> message... but our framing protocol described above in "New relay -> mesage packing" does not provide a way to put a message between two -> fragments of another message. - - +Fragmented messages may be used together with Conflux, but we do not +allow fragments from a single method to be sent on separate legs of +a single circuit bundle. + +That is to say, it is an error to send a CONFLUX_SWITCH message if +the SeqNum would leave any other circuit with an incomplete message +where not all framgents have arrived. Upon receiving such an +erroneous message, parties SHOULD destroy all circuits in the +conflux bundle. ### An exception for `DATA`. -- cgit v1.2.3-54-g00ecf