prop340: Change the ntorv3 data format

Reason behind this is to simplify the negotiation of this feature. A
ntorv3 handshake is in the fast path of circuit creation and minimizing
any parsing and on the wire binary size is a win.

Furthermore, this prevents us to go into a complex code path of version
negotiation where either side can be tricked into using another older
version.

We also do NOT expect to ever end up in a situation where one side sends
packed cells but not the other.

And so, this change simplifies everything and reflects the approach we
took with congestion control as well. Future change of packed/fragmented
relay cells will be possible through a new ntorv3 extension and a Relay
protover.

Signed-off-by: David Goulet <dgoulet@torproject.org>

1 files changed, 24 insertions, 9 deletions

diff --git a/proposals/340-packed-and-fragmented.md b/proposals/340-packed-and-fragmented.md
index 121be68..74af5ca 100644
--- a/proposals/340-packed-and-fragmented.md
+++ b/proposals/340-packed-and-fragmented.md
@@ -118,17 +118,32 @@ circuit being immediately destroyed.
 
 ## Negotiation
 
-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 following extension as part of its `ntor3`
-handshake:
+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
+following extension as part of its `ntor3` handshake:
 
-   RELAY_PROTOCOL
-     version    u8
+  EXT_FIELD_TYPE:
 
-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.
+    [03] -- Packed and Fragmented Cell Request
+
+This field is zero payload length. Its presence signifies that the client
+wants to use packed and fragmented cells on the circuit.
+
+The Exit side ntorv3 response payload is encoded as:
+
+  EXT_FIELD_TYPE:
+
+    [04] -- Packed and Fragmented Cell Response
+
+Again, the extension presence indicates to the client that the Exit has
+acknowledged the feature and is ready to use it. If the extension is not
+present, the client MUST not use the packed and fragmented feature even though
+the Exit has advertised the correct protover.
+
+The client MUST reject the handshake and thus close the circuit if:
+
+  - The response extension is seen for a non-ntorv3 handshake.
+  - The response extension is seen but no request was made initially.
 
 ## Migration