[tor-relays] growing guard probability on exits (2020-10-15)

[Mike Perry]

On 10/16/20 3:49 AM, nusenu wrote:
> lets see when this graph stops growing
> https://cryptpad.fr/code/#/2/code/view/1uaA141Mzk91n1EL5w0AGM7zucwFGsLWzt-EsXKzNnE/present/

Yes let's keep an eye on this. I doubt it is directly related, but it
could be a side effect.

However, I suspect that the KIST change will most affect Guards,
especially those used by loud clients. It will allow them to handle much
more traffic from loud clients, and probably get higher consensus values
as a result.

> why is this relevant?
> It puts more entities into an end-to-end correlation position than there used to be
> https://nusenu.github.io/OrNetStats/#tor-relay-operators-in-end-to-end-correlation-position

I share this concern. It seems plausible and even likely to me that
Exits are more likely to be surveilled than non-Exits, which makes them
more dangerous to use in both entry and exit positions. Additionally,
the use of an Exit in the Guard position leaks information, since you
will never use that Exit to connect anywhere, and this is visible over a
long period of time, leading to Guard discovery.

I want to remove the ability for Exits to become Guards entirely. In
addition to the correlation and Guard discovery issues, it has
historically caused much excess complexity for load balancing.

If Exits can't also become Guards, the load balancing equations become
way more legible and no longer have the "poorly defined constraint"
problem. This means the complicated scarcity cases from the solution go
away:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/265-load-balancing-with-overhead.txt#L51

> and it might also decrease exit traffic on exits when a tor client
> chooses an exit as guard

Hrm... this will be a function of how many clients choose that Exit.
This process will take months, because of the long guard rotation
period. If we keep flapping in and out of Exits-as-Guards, they are
unlikely to accumulate many clients.

The guard rotation period is another source of load balancing pain.

For outstanding issues with our attempt at solving it, see:
https://gitlab.torproject.org/tpo/core/tor/-/issues/16255

-- 
Mike Perry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20201016/336cac3d/attachment.sig>