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@torproject.org 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@torproject.org --- 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