[tor-commits] [torspec] 02/02: prop340: Change the ntorv3 data format

[gitolite role via tor-commits <tor-commits@xxxxxxxxxxxxxxxxxxxx>]

This is an automated email from the git hooks/post-receive script.

dgoulet pushed a commit to branch main
in repository torspec.

commit 8961bb4d83fccb2b987f9899ca83aa430f84ab0c
Author: David Goulet <dgoulet@xxxxxxxxxxxxxx>
AuthorDate: Thu May 11 12:48:45 2023 -0400

    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@xxxxxxxxxxxxxx>
---
 proposals/340-packed-and-fragmented.md | 33 ++++++++++++++++++++++++---------
 1 file 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
 

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits