Qualities of a good relay (Sean Saito)
I’m currently working with Dr. Virgil Griffith on Roster, a tor project that aims to reward relay operators with good relays. Right now we are brainstorming how to measure/quantify a good relay. Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users? Thanks, Sean
On Tuesday, June 23, 2015 9:07pm, saitosean@ymail.com said:
Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users?
A quality that can't be measured: resistence to intrusion. On second thought, that can be evaluated from outside to a certain extent. What ports on the server are open in addition to the OrPort/DirPort? Can the OS be fingerprinted to reveal an unsupported (and therefore unpatched) version? I worry about those relays with a heroic uptime. How is it that they haven't needed to reboot in, say, nine months? No security updates to the kernel or glibc in all that time? Really? In these days when governments, with their expertise and multi-billion-dollar budgets, get infiltrated I wonder how easy it would be get some monitoring malware onto machines that run Tor relays. That seems a lot more likely to me than the scare stories about the NSA/GCHQ running a lot of nodes themselves. https://atlas.torproject.org/#details/7489E8EDD0B8B68C8A2CB31D2B56B6572091DA...
...an excellent point Robert
From: swsnyder@snydernet.net Sent: Tue, 23 Jun 2015 22:09:48 -0400 (EDT)
I worry about those relays with a heroic uptime. How is it that they haven't needed to reboot in, say, nine months? No security updates to the kernel or glibc in all that time? Really?
In these days when governments, with their expertise and multi-billion-dollar budgets, get infiltrated I wonder how easy it would be get some monitoring malware onto machines that run Tor relays. That seems a lot more likely to me than the scare stories about the NSA/GCHQ running a lot of nodes themselves.
How about the inverse question, what are some properties of a *less valuable* relay? Answers to this also help. One that comes to mind is one <100 kbps. What the minimum floor for a valuable relay these days? Second, I've also heard discussion that Amazon EC2 relays are relatively non-helpful. But I've never had this confirmed one way or the other. -V
On 24 June 2015 at 03:09, Steve Snyder <swsnyder@snydernet.net> wrote:
On Tuesday, June 23, 2015 9:07pm, saitosean@ymail.com said:
Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users?
A quality that can't be measured: resistence to intrusion.
On second thought, that can be evaluated from outside to a certain extent. What ports on the server are open in addition to the OrPort/DirPort? Can the OS be fingerprinted to reveal an unsupported (and therefore unpatched) version?
Open ports can be very misleading. My tor relay runs on one machine behind some nat with only the needed ports redirected. Other ports you would see open on my IP would be from different machines.
Steve Snyder:
On Tuesday, June 23, 2015 9:07pm, saitosean@ymail.com said:
Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users?
A quality that can't be measured: resistence to intrusion.
Just a quick thought: A good question to ask in this regard might be "is this server dedicated to tor only or are there other services (like web-servers, MTAs etc.) running as well? The "purer" the relay, the (according to this heuristic) less likely it is to be infected with some kind of malware.
On Wed, Jun 24, 2015 at 01:07:28AM +0000, saitosean@ymail.com wrote:
Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users?
As mentioned in the other replies, "consistently runs a recent enough version of Tor" is a great one. Something about exit policy also seems wise. I wonder if having a ContactInfo counts? I certainly have a little moment of dread when I run across a relay that doesn't have its Contactinfo set. Also, OS diversity might be a nice quality to look at. You might find Mike's Torflow paper interesting here: https://blog.torproject.org/blog/torflow-node-capacity-integrity-and-reliabi... In particular, a relay that doesn't have permission from its OS to use enough file descriptors is going to be bad news. Similarly, a relay is less good if it rate limits to the point that it often has cells queued up waiting for the next interval to arrive (so that's not just declared bandwidth, but actual resulting performance in practice). Those are both the sort of thing that need active probing though. --Roger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I’m currently working with Dr. Virgil Griffith on Roster, a tor project that aims to reward relay operators with good relays.
Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users?
What are you generally aiming for: 1) a current rating (snapshot) or 2) a rating that accumulates over time (like in distributed computing/BOINC projects)? or 1 + 2? For the rest of this email I'm assuming you go for (2). Start with what matters most: - - Reward people for their total pushed traffic. You could use it as the base value that gets multiplied by other diversity/configuration factors. - - Reward people running relays for a longer time. (use a relay's age) - - bandwidth According to Roger one fast relay is more useful than many small relays. Use bandwidth history (not advertised bandwidth). - - Does the exit policy allow rare destination ports? more=better (excluding *:25) - - Does the relay's declared family match the effective family? bigger diff = less good Once [1] is implemented this will be really easy to check for. [1] https://trac.torproject.org/projects/tor/ticket/16276 - - IPv6 connectivity IPv6 enabled = better - - Does the torproject want to reward non-announced 'exit_addresses'? (as defined by onionoo) - - Has the relay a contactinfo set? non-empty is better Certain people will scream "don't force people to disclose their email addresses or link them to their relays". I agree, but I'd say it is easy enough to create a new email address for this purpose and people can also specify arbitrary strings there (still more valuable than empty contacts if used consistently or created by following a certain scheme). - - Reward people running more than one relay. You could simply use len(effective family) for that. more relays = better (until they reach some upper bound sum(CW) value?) We don't want families to become to big in terms of CW fraction. In practices you might ignore "the upper bound limit" since it is unlikely that many ops will hit it anyway. And if more than one strives for it the competition solves the problem itself. Patch Level / Tor version / Supported Tor Handshake Types - - Is the relay running a tor version - 'recommended' as per consensus and - free from known vulnerabilities (that is unfortunately not a perfect overlap with 'recommended' as per dir auths) and - the latest version of one of the stable/supported version - using the latest Does the torproject want to reward ops for running current alphas? You probably want some but not all of the relays running alphas so this is probably not suitable for automatic metrics. Diversity Judging by the latest paper on that topic it is good to start many guards near your users (in terms of how many ASes need to be traversed) and many exits near popular destinations, but I'm still judging by another very simple approach that actually runs counter to that: starting relays where there are none or few (by CW) is rated as better than starting a new guard in the country where most users are. So things to weight in for a quality measurement could be: - - /16 netblock (by CW fraction, relay count) - - country/region/city (by CW fraction, relay count (less important than CW) and flags) - - AS (by CW fraction, relay count (less important than CW) and flags) Lower CW fr./ relay count in CC/AS is better. goal: spread relays across the world Examples: - X added/runs a relay in a country and/or AS that had none or very few before. - X added/runs an exit relay in a country and/or AS that had none or very few before (no matter how many non-exits there are) Then you could "give out" rewards like "X started the first relay in country/AS Y". - - OS (by CW and relay count) rare OS = better (until people start to spoof their reported OS ;) The calculation could look like this: a new exit started, after 24 hours it did 700MB in a very common AS/country/netblock, on Linux, with no contactinfo, with a great open exit policy, running an unsupported tor version, declared+effective family=0 .... factors (purely invented): exit relay factor: 2.7 common AS factor: 0.7 common cc factor: 0.8 common netblock factor: 0.6 common OS: 0.9 unsupported tor version: 0.1 family len 0: 1 ... 700 * 2.7 * 0.7 * 0.8 * 0.6 * 0.9 * 0.1 * 1 * ... = X points after 24 hours the relay is relocated to a rare AS/country/netblock, changed its OS to OpenBSD and runs the latest tor version, effective family changed to 2 and did 900MB more. exit relay factor: 2.7 AS factor: 1.4 cc factor: 1.5 netblock factor: 1.7 OS factor: 2.5 recommended tor version: 1 family len 2: 1.05 .. points from day 1 + 900 * 2.7 * 1.4 * 1.5 * 1.7 * 2.5 * 1 * 1.05 ... multipliers will have to be dynamically calculated as the tor network changes. I would love to see something like this implemented. I'm really looking forward to your results. -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViq88AAoJEFv7XvVCELh0Wg4QALiAX3jeyCc/q5Gsfv0+zJh2 4oTdNkK1kHHIJ3aLZdgW4NE8xYnB0g+PrPQfOM6r4k+6RYlDrVBfblImUAKar9bG q/t3tIgY7JT1t8tpmEk13SCgv0UFYYYSqykxjyIrdKgqAbcSiFTpw8TwjFZoTPcA keacAsHxC83IllUmW3at3DBYrARiI7mTYxdHYnSaz5uQgLkn7RqZMR7lIILynJFX 55PFJZHVo11hw13vo//w8cNk2pVWqf3yivoqjNwOsrPqoy2OgkGBxiYX7q1Mvb3k XQ3iTAvjhmWNJlUSchBh73CUFaNfSkj0AwCrtV6CQFQfqP1Jy9iBMjBnHS1EQjoX KO6c0q+Ewl7k/DKLjJncT3OUfdBEg1ON5QUlComvyprvu+RimdQ7EQVKNC7aaDgD LfaxhwzT3cISaAvfocf/paVsAbHgjSKTyNEAPtLxF9xrqwoU+r5vmp/qpdgHh16U shKY9A9avmuJ8lwJx+UACZ8LoklOoykWSoBVwBUL21uuEWFOI5Y9EpY3Oi3SQnxY urD97cXkT5ecTMnYwq7475ueBrIsEzb7aHkR4LJIKXDXVmBUpRHDfV5+uP6rNb6K Q2YFEBm5PfMrvG3RAgoM0qJaYRAb1phtUYYhnfhL17hIUca5hs4emarfUb1oshZs 8r22I8pHNyZmmiG2lSTp =atVx -----END PGP SIGNATURE-----
Hi Sean, On 06/24/2015 03:07 AM, saitosean@ymail.com wrote:
Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users?
George posted some ideas a while ago: https://lists.torproject.org/pipermail/tor-dev/2014-July/007181.html I also remember another list of "diversity criteria" that someone posted, but I can't remember who or in which thread. -- Moritz Bartl https://www.torservers.net/
On 06/25/2015 05:12 PM, Moritz Bartl wrote:
Besides the obvious requirements of a good relay (e.g. speed, geo-diversity, constant uptime), what qualities make a relay valuable to the Tor network and its users? George posted some ideas a while ago: https://lists.torproject.org/pipermail/tor-dev/2014-July/007181.html I also remember another list of "diversity criteria" that someone posted, but I can't remember who or in which thread.
Not the one I'm looking for, but also relevant: https://lists.torproject.org/pipermail/tor-dev/2013-June/004996.html -- Moritz Bartl https://www.torservers.net/
participants (9)
-
Alan Turing -
I -
Moritz Bartl -
nusenu -
Pascal Terjan -
Roger Dingledine -
saitosean＠ymail.com -
Steve Snyder -
Virgil Griffith