October 2012 - tor-relays - lists.torproject.org

Call for discussion: turning funding into more exit relays
by Roger Dingledine 09 Jan '13

09 Jan '13

For a few years now, funders have been asking if they can pay Tor to run more relays. I kept telling them their money was better spent on code and design improvements: https://blog.torproject.org/blog/why-tor-is-slow https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/Performance since a) network load would just grow to fill whatever new capacity we have, especially if we don't deal with the tiny fraction of users who do bulk downloads, and b) reducing diversity of relay operator control can harm anonymity. But lately the Tor network has become noticeably faster, and I think it has a lot to do with the growing amount of excess relay capacity relative to network load: https://metrics.torproject.org/network.html?graph=bandwidth&start=2010-06-0… At the same time, much of our performance improvement comes from better load balancing -- that is, concentrating traffic on the relays that can handle it better. The result though is a direct tradeoff with relay diversity: on today's network, clients choose one of the fastest 5 exit relays around 25-30% of the time, and 80% of their choices come from a pool of 40-50 relays. https://trac.torproject.org/projects/tor/ticket/6443 Since extra capacity is clearly good for performance, and since we're not doing particularly well at diversity with the current approach, we're going to try an experiment: we'll connect funding to exit relay operators so they can run bigger and/or better exit relays. If we do it right (make more faster exit relays that aren't the current biggest ones, so there are more to choose from), we will improve the network's diversity as well as being able to handle more users. We've lined up our first funder (BBG, aka http://www.voanews.com/) and they're excited to have us start as soon as we can. They want to sponsor 125+ fast exits. ---------------------------------------------------------------------- Open questions we need to decide about: 1) What exactly would we pay for? I think the right way to do it is to offer to reimburse bandwidth/hosting costs -- I don't want to get into the business of paying people to run relays, and I don't want people to be trying to figure out how to "profit". That leads to all sorts of horrible incentive structures. More broadly, we should keep in mind that the primary cost of running an exit relay is effort, not dollars: it takes dedication to find an ISP who will host it, and to hold that ISP's hand when an abuse complaint arrives. Or said another way, hosting costs are in many cases not the biggest barrier to running an exit relay. I think we should aim to constrain ourselves to talking about >=100mbit exits, assuming that turns out to give us enough choices. That said, we don't want to concentrate bandwidth too much in any given relay, so we should limit the amount we'll reimburse per relay. 2) Should we fund existing relays or new ones? The worst failure mode here would be that we screw up the current community of relay operators. That's why it's extra important to keep them involved at each step of this discussion. I think the right answer is probably a balance of reimbursing costs from current exits and encouraging new exits to appear. Before we can get more precise though, we need to get a handle on how many current fast exits there are, and what their constraints are (whether their hosting situation could give them more bandwidth, whether they're paying now or getting a deal through a friend/employer, etc). Even then, there are interesting further questions like: - Should we prefer big collectives like torservers, noisetor, CCC, dfri.se, and riseup (which can get great bulk rates on bandwidth and are big enough to have relationships with local lawyers and ISPs), or should we prefer individuals since they maximize our operator diversity? I think "explore both approaches" is a fine first plan. - For existing relays who pay for hosting, should we prefer that our money go to covering their existing costs (and then we encourage them to save their money for use, say, after this experiment finishes), or should we aim to add additional funding so the relay can use more bandwidth? I'd say it comes down to the preferences of the relay operator. That said, if we have plenty to choose from, we should pick the relays that will make the network grow -- but we should take extra care to avoid situations where operators in the first category say "well, fine" and shut down their relay. More generally, we need to consider sustainability. Our current exit relay funding is for a period of 12 months, and while there's reason to think we will find continued support, the Tor network must not end up addicted to external funding. So long as everybody is running an exit relay because they want to save the world, I think we should be fine. 4) What exactly do we mean by diversity? There's network diversity (AS / upstream network topology), organization and operator diversity, jurisdictional (country) diversity, funding diversity, data-center diversity, and more. We've started to answer some of these questions at https://trac.torproject.org/projects/tor/ticket/6232 https://blog.torproject.org/blog/research-problem-measuring-safety-tor-netw… but this research topic will need ongoing attention. I'd love to get to the point where our diversity metrics can recommend network locations that best improve the various diversity scores. 5) How much "should" an exit relay cost? Since we're aiming for diversity, we can't send all our volunteers to the same cut-rate German VPS provider. After all, much of the work in setting up an exit relay is finding a good provider that doesn't already host a bunch of Tor relays. But if we declare that we'll reimburse $50/month for 100mbit, we're going to attract a different set of volunteers -- and a different set of network locations -- than if we reimburse $100/month for 100mbit. We need to learn about current bandwidth pricing: I know there are 10 cheap hosting places that will tolerate exit relays, but are there 200? And do all of those 200 turn out to overlap diversity-wise? Initial guesses appreciated. I'm inclined toward the $100 number to give our volunteers more flexibility. If we want to reimburse on a monthly basis, how do we handle situations where the ISP wants a longer-term contract? I think the answer will come down to how many choices we have. 6) How exactly should we choose which exit relay operators to reimburse? It might be premature to speculate until we better understand what choices are available to us. But I think the answer must include doing it in a way that encourages continued growth of the relay operator _community_. People who are active in the Tor community, and well-known to many other people, should be part of the answer. At the same time, we should be willing to put some of the money into trying out new places and people, especially if they're in good locations diversity-wise. The broader answer is that we as a community need to figure out a good answer here. I definitely don't want it to be "Roger picks people in an opaque way". But I also don't want the answer to be "anybody on the Internet who offers to take our money". Maybe we should put together a consortium of current Tor activists who run fast exits? 7) How do we audit / track the sponsored relays? How should we check that your 100mbit relay is really working? What do we measure to confirm its capacity? To a first approximation I'm fine assuming that nobody is going to try to cheat (say, by colluding with an ISP to write legit-looking invoices but then just split the money). But as the plan scales, we need good ways to track statistics on how many relays are being sponsored and how much bandwidth they're providing (so funders can see how effective their money is), and what fraction of the overall network these sponsored relays are (to keep an eye on the diversity questions). 8) Legal questions? Tor exit relays raise plenty of legal questions already, especially when you consider jurisdiction variety. But reimbursing relays introduces even more excitement, such as: - Does such a relay operator end up in a different situation legally? - Does the overall Tor network change legal categories in some country, e.g. becoming a telecommunications service when it wasn't before? - Does The Tor Project Inc incur new liabilities for offering this money? Tor has a history of creating fascinating new challenges for legal scholars, and this exit relay funding experiment will be no exception. I believe if we position it correctly, we won't really change the legal context. But I encourage people to investigate these questions for their jurisdiction. ---------------------------------------------------------------------- Next steps: I'm going to do a short blog post pointing to this thread, since many interested parties aren't on tor-relays yet. Then I'll send individual emails to exit relay operators pointing them to it and asking for their feedback (on the list or private, whichever they prefer). I'll also try to get some sense of how much their hosting costs, whether they'd want to participate in our experiment, whether they're in a position to ramp up to a faster connection, etc. Once we have some concrete facts about how many current exit relays want to participate, how many new volunteers want to help, and how many ISPs could handle more exit relays and at what prices, we'll be in a better position to decide how to proceed. --Roger

25 59

Deploy relays using hidden exit IP's?
by grarpamp 29 Nov '12

29 Nov '12

Shouldn't some exit relays (funded or not) be deployed to use an exit IP that is different from it's advertised exit IP in order to prevent a simplistic form of blocking based on scraping the descriptor set? I think this can happen if the default route is out another interface or secondary address. Something of that nature.

10 14

Map of Tor Relays updated
by Moritz Bartl 28 Oct '12

28 Oct '12

Hi, I updated my small Python script that visualize Tor relays on Google Maps/Earth and OpenStreetMap. You can see the results generated today here: - All relays (2668): http://maps.burningsilicon.net/index.php?url=https%3A%2F%2Fwww.torservers.n… http://maps.google.com/maps?q=http:%2F%2Fwww.torservers.net%2Fmisc%2Ftormap… - Exits only (786 plus 153 "fast" exits >2MB/s) http://maps.burningsilicon.net/index.php?url=https%3A%2F%2Fwww.torservers.n… http://maps.google.com/maps?q=http:%2F%2Fwww.torservers.net%2Fmisc%2Ftormap… - Screenshot Exits only: https://www.torservers.net/misc/tormap/tormap.png - Download KML, eg. for use in Google Earth (works best): https://www.torservers.net/misc/tormap/tormap.kml https://www.torservers.net/misc/tormap/tormap-exitsonly.kml - Script: https://github.com/moba/tormap Colors: Red: Exits >2MB/s, Green: Exits <2MB/s, Yellow Star: Stable middle nodes >2MB/s, Yellow: Stable middle nodes <2MB/s, White: Other (unstable) I used the Maxmind GeoIP CityLite database. The markers might give a false impression of accuracy. Most IPs can only be tracked to city level (or even region), ie. the markers are somewhat near, not necessarily at the real location of the relay. -- Moritz Bartl https://www.torservers.net/

2 1

How to diagnose lack of traffic on bridge?
by Steve Snyder 26 Oct '12

26 Oct '12

I have a bridge that gets no traffic. I don't mean "hardly any" traffic; I mean none. The contents of bridge-stats are always empty except for the date, which advances once per day. In the state file the last date, apart from daily accounting entries, is a EntryGuardAddedBy entry from 09 Sep 2012. Yeah, that's six weeks ago. The log file contains only a weekly notice of log file rotation and a daily notice of bandwidth self-test. I never see errors or even warnings in the log. My bridge is not unstable. It has been running continuously for the last 25 days, which is pretty typical for this bridge. I understand that bridges can be identified and their IP addresses blocked. But I am not lacking traffic just from China, or just from Iran, or just from any other entity. It doesn't seem likely that my IP address has been blacklisted by *everybody*. I am also aware that the bridge authorities seem to favor handing out some addresses more than others. Really, though, this IP address is never given out at all? What are the odds of that? On the rare occasions that I restart the bridge, I see in the log that my ORPort is reachable from outside and that my server descriptor is being published. That's nice. Also, I am running the current stable version of Tor, so it is not a matter of obsolete software. How can I diagnose the failure of my bridge to garner any traffic? Thanks.

4 5

Need help: High capacity exit relay does not get traffic
by tor-admin 25 Oct '12

25 Oct '12

Hi, I am operating two 1 GBit/s servers which host 7 exit nodes. One server is located in GB with torland1 https://atlas.torproject.org/#details/4E377F91D326552AAE818D5A17BC3EF79639C… torland2 https://atlas.torproject.org/#details/332895D092C2524A3CDE8F6E1498FFE665EBF… torland1 is configured to run at maximum bandwidth, torland2 runs trottled to ensure not to exceed the 100TB contractual traffic limit. The nodes on this server get traffic as expected and are at the top of the Blutmagie Tor Status http://torstatus.blutmagie.de/index.php?SR=Bandwidth&SO=Desc. The second server is located in RO and hosts torland3 https://atlas.torproject.org/#details/E5DB403858511BB166405E4C43776D933A7B8… torland4 https://atlas.torproject.org/#details/E0D2F8B2A18516A5C935477B06048D7BD2E7E… torland5 https://atlas.torproject.org/#details/D2F1745C11843BC5AF09CB9D4027AD2BE5F1B… torland6 https://atlas.torproject.org/#details/43F9022028F8AB0F7420F702CB079DF0CA0C8… The configuration for the GB and RO nodes is: Nickname TorLandX ORPort 443 DirPort 80 Address a.b.c.d ORListenAddress a.b.c.d DirListenAddress a.b.c.d OutboundBindAddress a.b.c.d RelayBandwidthRate 30 MBytes # max 30 RelayBandwidthBurst 100 MBytes # max 100 MaxOnionsPending 250 NumCPUs 4 On both servers AES-NI is used by openssl. Although the server in RO has the same configuration, same operating system and a similar hardware, it does not get traffic as the server in GB. At the moment Atlas shows for torland3-6 only an advertised bandwidth rate of less the 3 MB/s. The GB node torland1 shows more than 30 MB/s. In order to test if there are any traffic limits I did several speed tests by doing up and downloads of a large 4GB iso image. Downloading simultaneously with 10 curl instances from different debian mirrors I measured around 1 GBit/s. To measure upload I stored the debian 4GB iso image on the webserver of the RO server and used curl on the GB server to download it from RO. The maximal measured upstream speed on the RO server was around 750 Mbit/s. Therefore I looks for me as there are no traffic limits inplace by my ISP or their upstream. One of the servers operated by Torservers.net is located in the same data center and runs wau, gorz and sofia at high speed. I am wondering why the directory authorities only measure such a small fraction of the available bandwidth for the RO nodes. Because I am paying personally for the server I would like to get most out of the server. Can someone who runs a tor authority please help me to understand what is the reason for the low observed bandwidth. Thanks, Torland

2 2

Announcing the Walla Walla Project
by admin 23 Oct '12

23 Oct '12

Hi, I'm representing the Walla Walla Project, a volunteer initiative that aims to support the Tor network by contributing (exit-)relays and bridges to the network, and I would like to quickly announce today's (initial) launch of our humble project to the Tor relay operator mailinglist. Without any further ado, our project website is available at http://wallawallaproject.org/ We certainly very much welcome questions, comments and suggestions! Have a great day. On behalf of the Walla Walla Project team, Thomas

5 10

Running relay on OpenBSD ulimit problems
by Gijs 18 Oct '12

18 Oct '12

Hey guys, I just created a new relay on my new firewall box thats running openbsd, however I'm running into issues with ulimits: Failing because we have 991 connections already. Please raise your ulimit -n. I tried editing login.conf (might be doing it wrong) to no avail Anyone able to help me out ? Gijs

2 2

openBSD question.
by sharon dvir 12 Oct '12

12 Oct '12

sorry to bother you guys, and i hope its not a dumb repeated question. but which of the two following options is preferred for an exit node on openBSD? - run the Tor package available through the openBSD repositories, which is 2.2.35 but probably been reviewed by the openBSD team. or - compile and use 2.2.39 which is not as obsolete? thanks

3 2

interesting sequence of messages
by Scott Bennett 10 Oct '12

10 Oct '12

I'm running 0.2.4.3-alpha and had to restart it during the night due to a system crash. As it was starting up, it put out the following sequence of messages. Oct 08 00:38:44.616 [notice] We now have enough directory information to build circuits. Oct 08 00:38:44.616 [notice] Bootstrapped 80%: Connecting to the Tor network. Oct 08 00:38:45.728 [notice] Bootstrapped 85%: Finishing handshake with first hop. Oct 08 00:38:46.130 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Oct 08 00:38:46.359 [notice] Bootstrapped 90%: Establishing a Tor circuit. Oct 08 00:38:48.930 [notice] Our directory information is no longer up-to-date enough to build circuits: We have only 1868/2874 usable descriptors. Oct 08 00:38:48.930 [notice] I learned some more directory information, but not enough to build a circuit: We have only 1868/2874 usable descriptors. Oct 08 00:38:49.495 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Oct 08 00:38:49.495 [notice] Bootstrapped 100%: Done. Oct 08 00:38:49.830 [notice] I learned some more directory information, but not enough to build a circuit: We have only 1917/2874 usable descriptors. Oct 08 00:38:50.062 [notice] I learned some more directory information, but not enough to build a circuit: We have only 2013/2874 usable descriptors. Oct 08 00:38:50.142 [notice] I learned some more directory information, but not enough to build a circuit: We have only 2108/2874 usable descriptors. Oct 08 00:38:50.229 [notice] We now have enough directory information to build circuits. Oct 08 00:38:51.476 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Oct 08 00:39:03.079 [notice] Performing bandwidth self-test...done. The above really are nothing new, but just a really clear example of the screwiness of some common messages. In particular, the "no longer up-to-date enough to build circuits" and "learned some more directory information, but not enough to build a circuit" messages apparently are issued at times and under conditions contrary to the textual content of those messages. Let's examine the sequence shown above. 1) tor claims to have enough information to build a circuit. 2) It begins doing so by establishing the first hop of a testing circuit. 3) The testing circuit connects to my tor's own ORPort, so... 4) it builds a circuit to publish a descriptor and publishes it. 5) In less than 5 seconds from the time tor had enough directory information to build circuits, enough of that information has expired that tor no longer can build circuits. 6) tor fetches some descriptors, but still claims not to be able to build circuits. 7) tor announces that it has build a client-side circuit and pronounces that its startup is 100% complete. 8) tor continues to fetch three more batches of descriptors, saying that it still needs more to be able to build circuits, even after having claimed to have just built another one. I conclude from the above that the text of the messages claiming not to have enough directory information to build circuits is in error and should be revised to reflect the actual situation and events more accurately. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

Problems Setting up Bridge Relay on AWS
by freeflow＠mail.md 06 Oct '12

06 Oct '12

Hi! I recently set up a bridge relay on my home broadband connection. Unfortunately my ISP is restricting bandwidth during what it refers to as "peak hours", usually between 16:00 & 00:00 each day. This is obviously having a detrimental affect on my bridge relay as both upstream & downstream bandwidth is severely limited during these times. So I decided to set up a bridge relay on AWS, using the documentation at https://cloud.torproject.org/#get_started During the set-up process I've experienced 2 separate problems which I've described below. These are the actions I've taken: 1) I've successfully registered my account with AWS. 2) I've navigated my web browser to https://cloud.torproject.org/#get_started 3) At the above mentioned web page I've chosen: Obfsproxy Bridges (required ports: 22, 443, 52176) eu-west-1-Ireland 4) The pre-configured image is selected, and I'm directed to the AWS Management Console. When I arrive on the AWS Management Console page my web browser (Firefox 15.0.1) presents me with a "Warning: Unresponsive Script" dialogue box. The dialogue box explains, "A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete. Script: https://images-na.ssl-images-amazon.com/images [snip]... I chose to persevere & clicked "Continue" on the "Warning: Unresponsive Script" dialogue box. After being presented with another "Warning: Unresponsive Script" dialogue box I arrive at the "Choose an AMI" pane of the "Request Instances Wizard" which displays the pre-configured settings. It's at this stage that I begin to get confused... I've attempted to use the "Step-by-Step" instructions provided at https://cloud.torproject.org/#get_started The "Step-by-Step" instructions state, "Simply follow the steps as illustrated below, and your bridge will up and running in just a couple of minutes." With regard to the "Choose an AMI" pane the "Step-by-Step" instructions suggest, "Click "Continue". (No changes needed here.)" There doesn't appear to be an option to continue beyond the first pane (Choose an AMI), the only available option that I can see is to cancel (top right corner of the Choose an AMI/Request Instances Wizard pane). This takes me to the "Amazon EC2 Console Dashboard". However, because nothing has been set up, the EC2 Console Dashboard quite correctly informs me that there are no instances running. On the left-hand side of the Amazon EC2 Console Dashboard is the "Navigation" pane listing "Instances" & "Images" (including AMIs). So, I can see some of the required components that are incorporated into the "Request Instances Wizard" but I lack the experience to set up my AWS manually. So, more confusion! On the plus side the Amazon EC2 Console Dashboard does inform me that I've selected my chosen region which it reports is up & running. Maybe a "Continue" option isn't being displayed in the "Choose an AMI" pane because of the above-mentioned "Unresponsive Script" dialogue box, or maybe there's some other way to move through the "Request Instances Wizard" that I'm unaware of? I'm currently running java version 1.7.0_07 from Oracle Corporation on 12.04.1 LTS precise. I have no experience of setting up anything like an AWS so any help would be much appreciated & hopefully I can succeed in setting up my bridge relay! Best regards!

2 5