torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2024-11-26 19:30:32 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

prop340: Change the ntorv3 data format

Browse Source 
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>
This commit is contained in:
David Goulet 2023-05-11 12:48:45 -04:00
parent 21d7e9a41f
commit 8961bb4d83
1 changed files with 24 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
proposals/340-packed-and-fragmented.md
View File

@ -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