[tor-commits] [torspec] 04/05: Prop329: Document Snowflake exemption to Guard restriction.

[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 7ea74b99bd6ef356feb8f66a23ff985c9b056f69
Author: Mike Perry <mikeperry-git@xxxxxxxxxxxxxx>
AuthorDate: Wed May 17 21:29:05 2023 +0000

    Prop329: Document Snowflake exemption to Guard restriction.
---
 proposals/329-traffic-splitting.txt | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/proposals/329-traffic-splitting.txt b/proposals/329-traffic-splitting.txt
index 63d7aab..93655f0 100644
--- a/proposals/329-traffic-splitting.txt
+++ b/proposals/329-traffic-splitting.txt
@@ -275,7 +275,21 @@ Status: Needs-Revision
 
   To link exit circuits, two circuits to the same exit are built, with
   additional restrictions such that they do not share Guard or Middle
-  relays. When each circuit is opened, we ensure that congestion control
+  relays. This restriction applies via specific relay identity keys,
+  and not IP addresses, families, or networks. (This is because the purpose
+  of it is to avoid sharing a bottleneck *inside* relay circuit queues;
+  bottlenecks caused by a shared network are handled by TCP's congestion
+  control on the OR conns).
+
+  Bridges also are subject to the same constraint as Guard relays;
+  the C-Tor codebase emits a warn if only one bridge is configured, unless
+  that bridge has transport "snowflake". Snowflake is exempt from this
+  Guard restriction because it is actually backed by many bridges. In the
+  bridge case, we only warn, and do not refuse to build conflux circuits,
+  because it is not catastrophic that Bridges are shared, it is just
+  sub-optimal for performance and congestion.
+
+  When each circuit is opened, we ensure that congestion control
   has been negotiated. If congestion control negotiation has failed, the
   circuit MUST be closed. After this, the linking handshake begins.
 
@@ -307,6 +321,17 @@ Status: Needs-Revision
   use Prop340, we will have to raise the limit on number of intros per
   client circuit to 2, here, at intropoints).
 
+  When rendezvous circuits are built, they should use the same Guard,
+  Bridge, and Middle restrictions as specified in 2.2, for Exits. These
+  restrictions SHOULD also take into consideration all Middles in the path,
+  including the rendezvous point. All relay identities should be unique
+  (again, except for when the Snowflake transport is in use). The one
+  special case here is if the chosen rendezvous points by a client
+  are the same as the service's guards. In this case, the service SHOULD
+  NOT use different guards, but instead stick with the guards it has.
+  The reason for this is that we do not want to create the ability
+  for a client to force a service to use different guards.
+
   The first rendezvous circuit to get joined SHOULD use Proposal 340 to
   append the RELAY_BEGIN command, and the service MUST answer on this
   circuit, until RTT can be measured.

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