Merge branch '340-tweak' into 'main'

prop340: Tweaks, clarifications, open questions.

See merge request tpo/core/torspec!170

1 files changed, 54 insertions, 3 deletions

diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md
index 6c27fcd..da0cbdb 100644
--- a/proposals/340-packed-and-fragmented.md
+++ b/proposals/340-packed-and-fragmented.md
@@ -69,8 +69,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
@@ -118,7 +119,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
@@ -149,6 +153,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.
 
@@ -187,12 +194,56 @@ 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
 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, 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`.
 
 Data messages may not be fragmented.  (There is never a reason to do