[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec] 02/03: Tweak dgoulet's explanation of TRUNCATE and DESTROY.
This is an automated email from the git hooks/post-receive script.
dgoulet pushed a commit to branch main
in repository torspec.
commit 647e7675f9b8ce56f37dae9935857c68797e148d
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
AuthorDate: Wed Jan 11 09:25:00 2023 -0500
Tweak dgoulet's explanation of TRUNCATE and DESTROY.
---
tor-spec.txt | 45 ++++++++++++++++++++++++++-------------------
1 file changed, 26 insertions(+), 19 deletions(-)
diff --git a/tor-spec.txt b/tor-spec.txt
index 8dcb564..25a12a7 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -1522,27 +1522,34 @@ see tor-design.pdf.
version of Tor if a) they have sent relay cells through that node,
and b) they aren't sure whether those cells have been sent on yet.]
- When an unrecoverable error occurs along one connection in a circuit, the
- nodes on either side of the connection MAY, if they are able, act as
- follows: the node closer to the OP can send a RELAY_TRUNCATED cell towards
- the OP or a DESTROY cell to the previous OR.
-
- An OP, upon receiving a RELAY_TRUNCATED, should send forward a DESTROY cell
- in order to entirely teardown the circuit.
+ When an unrecoverable error occurs along one a circuit, the nodes
+ must report it as follows:
+ * If possible, send a DESTROY cell to ORs _away_ from the client.
+ * If possible, send *either* a DESTROY cell towards the client, or
+ a RELAY_TRUNCATED cell towards the client.
+
+ Current versions of Tor do not reuse truncated RELAY_TRUNCATED
+ circuits: An OP, upon receiving a RELAY_TRUNCATED, will send
+ forward a DESTROY cell in order to entirely tear down the circuit.
+ Because of this, we recommend that relays should send DESTROY
+ towards the client, not RELAY_TRUNCATED.
NOTE:
- In tor version >= 0.4.5.13, 0.4.6.11 and 0.4.7.9, upon receiving a DESTROY
- cell from upstream of the circuit, an OR won't send a RELAY_TRUNCATED to
- the OP but instead will send a DESTROY down the circuit in order to signal
- every intermediary ORs to stop queuing data on the circuit. Before that,
- the delay between the OP receiving the RELAY_TRUNCATED cell and sending a
- DESTROY cell upward would create queuing pressure on the intermediary ORs.
-
- The payload of a DESTROY and RELAY_TRUNCATED cell contains a single octet,
- describing the reason that the circuit was closed. The emitter of such cell
- should use the right reason found below however it should NEVER be
- propagated downward or upward due to potential side channel risk. An OR
- receiving a DESTROY should use the DESTROYED reason for its next cell.
+ In tor versions before 0.4.5.13, 0.4.6.11 and 0.4.7.9, relays would
+ handle an inbound DESTROY by sending the client a RELAY_TRUNCATED
+ message. Beginning with those versions, relays now propagate
+ DESTROY cells in either direction, in order to tell every
+ intermediary ORs to stop queuing data on the circuit. The earlier
+ behavior created queuing pressure on the intermediary ORs.
+
+ The payload of a DESTROY and RELAY_TRUNCATED cell contains a single
+ octet, describing the reason that the circuit was
+ closed. RELAY_TRUNCATED cells, and DESTROY cells sent _towards the
+ client, should contain the actual reason from the list of error codes
+ below. Reasons in DESTROY cell SHOULD NOT be propagated downward or
+ upward, due to potential side channel risk: An OR receiving a DESTROY
+ command should use the DESTROYED reason for its next cell. An OP
+ should always use the NONE reason for its own DESTROY cells.
The error codes are:
--
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