[torspec] branch main updated (0bacc73 -> b4cfd28)
This is an automated email from the git hooks/post-receive script. dgoulet pushed a change to branch main in repository torspec. from 0bacc73 Merge branch 'tor-gitlab/mr/83' new 854cf53 tor-spec: TRUNCATED cell are not sent anymore new 647e767 Tweak dgoulet's explanation of TRUNCATE and DESTROY. new b4cfd28 Merge branch 'tor-gitlab/mr/81' The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: tor-spec.txt | 40 ++++++++++++++++++++++++++++------------ 1 file changed, 28 insertions(+), 12 deletions(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.
This is an automated email from the git hooks/post-receive script. dgoulet pushed a commit to branch main in repository torspec. commit 854cf535ca8225e295369a3fef253fa4e9f69235 Author: David Goulet <dgoulet@torproject.org> AuthorDate: Tue Jul 26 14:12:58 2022 -0400 tor-spec: TRUNCATED cell are not sent anymore In addition, this commit also changes the spec so no destroy reasons (error code) are propagated down or up the circuit in order to mitigate potential side channel risks. See https://gitlab.torproject.org/tpo/core/tor/-/issues/40649 for more details on why. Related to tor/#40623 Signed-off-by: David Goulet <dgoulet@torproject.org> --- tor-spec.txt | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index 3f03890..8dcb564 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1522,18 +1522,27 @@ 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 should, if they - are able, act as follows: the node closer to the OP should send a - RELAY_TRUNCATED cell towards the OP; the node farther from the OP - should send a DESTROY cell down the circuit. - - The payload of a DESTROY cell contains a single octet, describing the - reason that the circuit was closed. Similarly, the data of a - RELAY_TRUNCATED cell also contains this single octet "reason" field. When - sending a TRUNCATED or DESTROY cell because of another TRUNCATED or - DESTROY cell, the error code should be propagated. The origin of a circuit - always sets this error code to 0, to avoid leaking its version. + 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. + + 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. The error codes are: -- To stop receiving notification emails like this one, please contact the administrator of this repository.
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@torproject.org> 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.
This is an automated email from the git hooks/post-receive script. dgoulet pushed a commit to branch main in repository torspec. commit b4cfd28297f916e76189eef12d30630c1e51e0cc Merge: 0bacc73 647e767 Author: David Goulet <dgoulet@torproject.org> AuthorDate: Wed Jan 11 10:00:46 2023 -0500 Merge branch 'tor-gitlab/mr/81' tor-spec.txt | 40 ++++++++++++++++++++++++++++------------ 1 file changed, 28 insertions(+), 12 deletions(-) -- To stop receiving notification emails like this one, please contact the administrator of this repository.
participants (1)
-
gitolite role