[tor-relays] pinning relay keys to IPs (or not)

Yawning Angel yawning at schwanenlied.me
Sun Jul 26 18:23:36 UTC 2015


On Sun, 26 Jul 2015 21:09:13 +0300
s7r <s7r at sky-ip.org> wrote: 
> We need to confirm this: is a relay holding TLS connections to the
> majority of the other relays?

This is another metrics needed thing.  In general, at any given
time, any relay should be prepared to be able to open or accept a
connection to any other relay/bridge, because circuit failures are
extremely unhealthy for the network and anonymity.

As the number of users tends towards infinity, the number of concurrent
TLS connections on a given relay will increase till it caps out at 1 per
every other node in the network (plus destinations if Exit, clients if
Guard), because the path selection will work out such that at least one
user will pick a path that involves every possible relay pair.

So in a magical more anonymous future, yes, relays will hold TLS
connections to the majority of other relays.  The growth won't be
linear since the path selection is based on consensus weight, so having
nifty metrics to graph trends here will be useful, since as you noted
in your example we aren't at that point yet.

> On a relay with over 100 days of uptime (middle relay) Stable, HSDir,
> etc. I have (# netstat -a | wc -l) 1942 connections. Another one, with
> less uptime just has 548 connections. These relays have a small
> consensus weight. A guard with good consensus weight has much more,
> but anyway under the ~6400 (total number of relays in the consensus).

There are consumer grade routers that would not be able to sustain the
small example due to NAT session tracking limitations.  This is sad,
relays behind such devices will do bad things to the network.

See https://trac.torproject.org/projects/tor/ticket/15482#comment:26
and the linked tor.stackexchange.com question, and the follow up
discussion for practical issues caused by such devices.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150726/367a426c/attachment.sig>


More information about the tor-relays mailing list