July 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

Re: [tor-relays] tor-relays Digest, Vol 18, Issue 1
by Christian 13 Sep '12

13 Sep '12

Hi Roger, > Who owns that socket file? /var/run/tor/control is owned by debian-tor. > Anything else in that other default config file? The tor-service-defaults-torrc file contains: DataDirectory /var/lib/tor PidFile /var/run/tor/tor.pid RunAsDaemon 1 User debian-tor ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie Log notice file /var/log/tor/log > > ORPort 443 NoListen > > > ORPort 0.0.0.0:9090 NoAdvertise > > > ORPort [::]:9090 IPv6Only NoAdvertise > > > > Is this ipv6 bind attempt the one causing problems? > > > > The ipv6 bind attempt was a try to solve the problem. Problem persists with and without ipv6 bind attempt. Thanks a lot! christian > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Failed to parse/validate config: failed to bind one of the > listener ports (Christian) > 2. Re: Failed to parse/validate config: failed to bind one of > the listener ports (Roger Dingledine) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 01 Jul 2012 06:14:19 +0200 > From: Christian <brightsidedarkside(a)t-online.de> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Failed to parse/validate config: failed to bind > one of the listener ports > Message-ID: <1341116059.2767.42.camel(a)delusions.local> > Content-Type: text/plain; charset="UTF-8" > > Hi Nick, hi Jean, > > thanks a lot for your fast reaction. I was at my parents' place for a > week, that's why I'm a little late. > > First, I tried port 9001, but in fact it is a port forwarding on the > router from 443 to 9090. > > Following, I post the terminal output when using the given torrc and the > torrc file itself. > Really, no logs are created, independent of the logging options. > The socket unlink issue happens since I use tor and that's for a while > now - it never affected functionality. > Yes, I'm into psychiatric symptoms. A friend of mine uses monsters' > names from films. ;-) > > Again, thanks a lot for your help! > > Thankfully > > christian > > ca@delusions:~$ sudo service tor restart > [sudo] password for ca: > * Stopping tor daemon... > [ OK ] > * Starting tor > daemon... > Jul 01 06:00:13.321 [warn] Could not unlink /var/run/tor/control: > Permission denied > Jul 01 06:00:13.321 [warn] Failed to parse/validate config: Failed to > bind one of the listener ports. > Jul 01 06:00:13.321 [err] Reading config failed--see warnings above. > > [fail] > ca@delusions:~$ > > > > The torrc (complete to prevent me from confusing, but slightly spoiled > by my mail client with line breaks - RunAsDeamon is set by another > default config file): > > > ## Configuration file for a typical Tor user > ## Last updated 22 April 2012 for Tor 0.2.3.14-alpha. > ## (may or may not work for much older or much newer versions of Tor.) > ## > ## Lines that begin with "## " try to explain what's going on. Lines > ## that begin with just "#" are disabled commands: you can enable them > ## by removing the "#" symbol. > ## > ## See 'man tor', or https://www.torproject.org/docs/tor-manual.html, > ## for more options you can use in this file. > ## > ## Tor will look for this file in various places based on your platform: > ## https://www.torproject.org/docs/faq#torrc > > ## Tor opens a socks proxy on port 9050 by default -- even if you don't > ## configure one below. Set "SocksPort 0" if you plan to run Tor only > ## as a relay, and not make any local application connections yourself. > #SocksPort 9050 # Default: Bind to localhost:9050 for local connections. > #SocksPort 192.168.0.1:9100 # Bind to this adddress:port too. > > ## Entry policies to allow/deny SOCKS requests based on IP address. > ## First entry that matches wins. If no SocksPolicy is set, we accept > ## all (and only) requests that reach a SocksPort. Untrusted users who > ## can access your SocksPort may be able to learn about the connections > ## you make. > #SocksPolicy accept 192.168.0.0/16 > #SocksPolicy reject * > > ## Logs go to stdout at level "notice" unless redirected by something > ## else, like one of the below lines. You can have as many Log lines as > ## you want. > ## > ## We advise using "notice" in most cases, since anything more verbose > ## may provide sensitive information to an attacker who obtains the > logs. > ## > ## Send all messages of level 'notice' or higher > to /var/log/tor/notices.log > #Log notice file /var/log/tor/notices.log > ## Send every possible message to /var/log/tor/debug.log > Log debug file /var/log/tor/debug.log > ## Use the system log instead of Tor's logfiles > #Log notice syslog > ## To send all messages to stderr: > #Log debug stderr > > ## Uncomment this to start the process in the background... or use > ## --runasdaemon 1 on the command line. This is ignored on Windows; > ## see the FAQ entry if you want Tor to run as an NT service. > #RunAsDaemon 1 > > ## The directory for keeping all the keys/etc. By default, we store > ## things in $HOME/.tor on Unix, and in Application Data\tor on Windows. > #DataDirectory /var/lib/tor > > ## The port on which Tor will listen for local connections from Tor > ## controller applications, as documented in control-spec.txt. > #ControlPort 9051 > ## If you enable the controlport, be sure to enable one of these > ## authentication methods, to prevent attackers from accessing it. > #HashedControlPassword > 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C > #CookieAuthentication 1 > > ############### This section is just for location-hidden services ### > > ## Once you have configured a hidden service, you can look at the > ## contents of the file ".../hidden_service/hostname" for the address > ## to tell people. > ## > ## HiddenServicePort x y:z says to redirect requests on port x to the > ## address y:z. > > #HiddenServiceDir /var/lib/tor/hidden_service/ > #HiddenServicePort 80 127.0.0.1:80 > > #HiddenServiceDir /var/lib/tor/other_hidden_service/ > #HiddenServicePort 80 127.0.0.1:80 > #HiddenServicePort 22 127.0.0.1:22 > > ################ This section is just for relays ##################### > # > ## See https://www.torproject.org/docs/tor-doc-relay for details. > > ## Required: what port to advertise for incoming Tor connections. > #ORPort 443 > ## If you want to listen on a port other than the one advertised in > ## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as > ## follows. You'll need to do ipchains or other port forwarding > ## yourself to make this work. > ORPort 443 NoListen > ORPort 0.0.0.0:9090 NoAdvertise > ORPort [::]:9090 IPv6Only NoAdvertise > > ## The IP address or full DNS name for incoming connections to your > ## relay. Leave commented out and Tor will guess. > #Address noname.example.com > > ## If you have multiple network interfaces, you can specify one for > ## outgoing traffic to use. > # OutboundBindAddress 10.0.0.5 > > ## A handle for your relay, so people don't have to refer to it by key. > Nickname BrightSideDarkSide > > ## Define these to limit how much relayed traffic you will allow. Your > ## own traffic is still unthrottled. Note that RelayBandwidthRate must > ## be at least 20 KB. > ## Note that units for these config options are bytes per second, not > bits > ## per second, and that prefixes are binary prefixes, i.e. 2^10, 2^20, > etc. > #RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps) > #RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps) > > ## Use these to restrict the maximum traffic per day, week, or month. > ## Note that this threshold applies separately to sent and received > bytes, > ## not to their sum: setting "4 GB" may allow up to 8 GB total before > ## hibernating. > ## > ## Set a maximum of 4 gigabytes each way per period. > #AccountingMax 4 GB > ## Each period starts daily at midnight (AccountingMax is per day) > #AccountingStart day 00:00 > ## Each period starts on the 3rd of the month at 15:00 (AccountingMax > ## is per month) > #AccountingStart month 3 15:00 > > ## Contact info to be published in the directory, so we can contact you > ## if your relay is misconfigured or something else goes wrong. Google > ## indexes this, so spammers might also collect it. > ContactInfo Sides of the moon <brightsidedarkside AT t-online dot de> > ## You might also include your PGP or GPG fingerprint if you have one: > #ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com> > > ## Uncomment this to mirror directory information for others. Please do > ## if you have enough bandwidth. > #DirPort 9030 # what port to advertise for directory connections > ## If you want to listen on a port other than the one advertised in > ## DirPort (e.g. to advertise 80 but bind to 9091), you can do it as > ## follows. below too. You'll need to do ipchains or other port > ## forwarding yourself to make this work. > #DirPort 80 NoListen > #DirPort 127.0.0.1:9091 NoAdvertise > ## Uncomment to return an arbitrary blob of html on your DirPort. Now > you > ## can explain what Tor is if anybody wonders why your IP address is > ## contacting them. See contrib/tor-exit-notice.html in Tor's source > ## distribution for a sample. > #DirPortFrontPage /etc/tor/tor-exit-notice.html > > ## Uncomment this if you run more than one Tor relay, and add the > identity > ## key fingerprint of each Tor relay you control, even if they're on > ## different networks. You declare it here so Tor clients can avoid > ## using more than one of your relays in a single circuit. See > ## https://www.torproject.org/docs/faq#MultipleRelays > ## However, you should never include a bridge's fingerprint here, as it > would > ## break its concealability and potentionally reveal its IP/TCP address. > #MyFamily $keyid,$keyid,... > > ## A comma-separated list of exit policies. They're considered first > ## to last, and the first match wins. If you want to _replace_ > ## the default exit policy, end this with either a reject *:* or an > ## accept *:*. Otherwise, you're _augmenting_ (prepending to) the > ## default exit policy. Leave commented to just use the default, which > is > ## described in the man page or at > ## https://www.torproject.org/documentation.html > ## > ## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses > ## for issues you might encounter if you use the default exit policy. > ## > ## If certain IPs and ports are blocked externally, e.g. by your > firewall, > ## you should update your exit policy to reflect this -- otherwise Tor > ## users will be told that those destinations are down. > ## > ## For security, by default Tor rejects connections to private (local) > ## networks, including to your public IP address. See the man page entry > ## for ExitPolicyRejectPrivate if you want to allow "exit enclaving". > ## > #ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more > #ExitPolicy accept *:119 # accept nntp as well as default exit policy > ExitPolicy reject *:* # no exits allowed > > ## Bridge relays (or "bridges") are Tor relays that aren't listed in the > ## main directory. Since there is no complete public list of them, even > an > ## ISP that filters connections to all the known Tor relays probably > ## won't be able to block all the bridges. Also, websites won't treat > you > ## differently because they won't know you're running Tor. If you can > ## be a real relay, please do; but if not, be a bridge! > BridgeRelay 1 > ## By default, Tor will advertise your bridge to users through various > ## mechanisms like https://bridges.torproject.org/. If you want to run > ## a private bridge, for example because you'll give out your bridge > ## address manually to your friends, uncomment this line: > #PublishServerDescriptor 0 > > User debian-tor > > > > tor-relays-request(a)lists.torproject.org: > > Send tor-relays mailing list submissions to > > tor-relays(a)lists.torproject.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > or, via email, send a message with subject or body 'help' to > > tor-relays-request(a)lists.torproject.org > > > > You can reach the person managing the list at > > tor-relays-owner(a)lists.torproject.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of tor-relays digest..." > > > > > > Today's Topics: > > > > 1. Re: Failed to parse/validate config: failed to bind one of > > the listener ports (Nick Mathewson) > > 2. Re: Failed to parse/validate config: failed to bind one of > > the listener ports (Jean Trolleur) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 26 Jun 2012 11:59:22 -0400 > > From: Nick Mathewson <nickm(a)freehaven.net> > > To: tor-relays(a)lists.torproject.org > > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > > bind one of the listener ports > > Message-ID: > > <CAKDKvuyeEBDEO6rrbqVQSZcOy_cbeuGWMX2gisUjjETk0VgJEw(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Sat, Jun 23, 2012 at 7:38 PM, Christian > > <brightsidedarkside(a)t-online.de> wrote: > > > Hi dear fellows, > > > > > > I'm sorry to use again this way of addressing my problem as in Vol 17, > > > Issue 5. It will be the last time. Promise. > > > > > > I can't find any solution on the web. > > > When starting tor, it always reads "Failed to parse/validate config: > > > failed to bind one of the listener ports". > > > > Hm. It really should be saying something more than that on startup; > > there should be a message right before that about *why* it couldn't > > parse or validate the ports. > > > > I just tried the ORPort combination you listed there, and it seemed to > > work out okay for me. It might be easier to diagnose if you could > > upload your entire torrc, and the entire output of starting Tor up to > > the point where it says "failed to parse/validate config:" > > > > hth, > > -- > > Nick > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 26 Jun 2012 15:18:42 -0500 > > From: Jean Trolleur <sigtstp(a)gmail.com> > > To: tor-relays(a)lists.torproject.org > > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > > bind one of the listener ports > > Message-ID: > > <CAPN5qOdaMr==8D-kTz01cAZDHrDXSGuh5T+3DVfscJLx8jLgZA(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Try: > > > > ORPort 443 > > ORListenAddress 0.0.0.0:9001 > > > > On Sat, Jun 23, 2012 at 6:38 PM, Christian > > <brightsidedarkside(a)t-online.de> wrote: > > > Hi dear fellows, > > > > > > I'm sorry to use again this way of addressing my problem as in Vol 17, > > > Issue 5. It will be the last time. Promise. > > > > > > I can't find any solution on the web. > > > When starting tor, it always reads "Failed to parse/validate config: > > > failed to bind one of the listener ports". > > > > > > Furthermore, there are only empty logfiles, independent of the > > > configuration of the logs option "notice". > > > > > > Has anyone else this kind of problem? > > > > > > This is my ORPort section: > > > ORPort 443 NoListen > > > ORPort 0.0.0.0:9090 NoAdvertise > > > > > > I even can't make a control port accessible for e.g. arm running on the > > > same machine, although I didn't use it before. > > > > > > Client functionality is not working either. No connections through tor. > > > > > > Tor is configured as a bridge, my OS is Ubuntu lucid 10.04 and Tor's > > > version is 2.3.17-beta-1~lucid+1. > > > > > > It just worked until the upgrade to the new version through torproject's > > > repository. > > > > > > I really do have forwarded external port 443 to port 9090 on my machine. > > > > > > It nearly has me left in broken state dying. > > > > > > I checked for new requests concerning apparmor allowance, but there were > > > only the ability to chown and access to /sys/devices/system/cpu/ which I > > > granted both. > > > > > > I'm not so really competent with computers and therefore grateful for > > > any help. > > > Strange. No error logs, no function, no topic on the web.. > > > > > > Kind regards, > > > > > > christian > > > > > > > > > _______________________________________________ > > > tor-relays mailing list > > > tor-relays(a)lists.torproject.org > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > ------------------------------ > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > End of tor-relays Digest, Vol 17, Issue 8 > > ***************************************** > > > > > ------------------------------ > > Message: 2 > Date: Sun, 1 Jul 2012 05:14:22 -0400 > From: Roger Dingledine <arma(a)mit.edu> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > bind one of the listener ports > Message-ID: <20120701091422.GB8804(a)moria.seul.org> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jul 01, 2012 at 06:14:19AM +0200, Christian wrote: > > Really, no logs are created, independent of the logging options. > > That's expected -- it's because logs are parsed in the same step as > binding the sockets, and it never gets to the 'setting up the logs' part. > > > The socket unlink issue happens since I use tor and that's for a while > > now - it never affected functionality. > > Who owns that socket file? > > > The torrc (complete to prevent me from confusing, but slightly spoiled > > by my mail client with line breaks - RunAsDeamon is set by another > > default config file): > > Anything else in that other default config file? > > > ORPort 443 NoListen > > ORPort 0.0.0.0:9090 NoAdvertise > > ORPort [::]:9090 IPv6Only NoAdvertise > > Is this ipv6 bind attempt the one causing problems? > > --Roger > > > > ------------------------------ > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > End of tor-relays Digest, Vol 18, Issue 1 > *****************************************

1 1

Re: [tor-relays] task-6329 / tor relays stats patch
by Karsten Loesing 03 Aug '12

03 Aug '12

Hi Michael, I'm cc'ing tor-relays for the discussion here, because I figured if you're okay with sharing the patch, you're probably also okay with a public discussion of it. :) On 7/21/12 4:19 PM, Michael Zeltner wrote: > Hi Karsten, > > On my way out, and I would otherwise forget but here you go, maybe you'd like > this. > > Best from Metalab/Vienna, > Michael Thanks for sending the patch! Most of it looks good, but I took out the --family-for-fp option which, I think, isn't entirely correct. This option looks for relays having the given fingerprint in their family line, but it doesn't cross-check if the given relay has those relays in its family line, too. The option also doesn't look at nicknames (of relays with the Named flag) in family lines, which means it might miss some family members. Oh, and it would be really cool to have a -F or --by-family option to aggregate by families. I wonder if we should do the whole family-calculating business inside Onionoo and add a family_number field which has the same number for relays in the same family. The script could then look up the family number of the given relay and display all relays with that family number. Would that make sense? Want to extend the script once Onionoo has such a field? Thanks! Karsten

2 4

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Andrew Beveridge 02 Aug '12

02 Aug '12

On Mon, Jul 23, 2012 at 9:22 PM, Roger Dingledine <arma(a)mit.edu> wrote: > Hello Andrew, > > I wanted to draw your attention to a thread I've started on the tor-relays > list: > https://lists.torproject.org/pipermail/tor-relays/2012-July/001433.html > > Hi Roger, I'm not too familiar with mailing lists, so hopefully I'm not top posting or replying in the wrong place here. I'm simply replying to your email in Gmail with a CC to the tor-relays list. Sorry for the late reply, I've been away with no internet access for the past week. > In short, we have a funder who wants to sponsor more and faster Tor > exits, and we're brainstorming about how to use the money in a way that > makes the network stronger but also doesn't screw up the "community" > side of the Tor relay operator community. The first step is collecting > facts about the current fast Tor exit relays. > > Great! I've not been vocal in the Tor community before now, but I'd like to start, and I'm certainly happy to share my experience / thoughts. > - What do you currently pay for hosting/bandwidth, and how much bandwidth > do you get for that? > This is a complicated question, because I run a single Tor exit in a VPS on my company dedicated server. I run a local company doing computer repair and web development, and lease a single dedicated server from OVH (more specifically, Kimsufi) for a total of £64 a month (inc. VAT). That gets me the Kimsufi 16G dedicated server, a RIPE block of 4 extra IPs, and an external 2TB HDD. 100Mbit pipe, 10TB/month bandwidth. £0.87/TB if I go over that, so if I were to max out the bandwidth for an entire month, using around 30TB traffic, I would have to pay about £18 on top for the extra bandwidth. However, according to the OVH manager I never seem to go anywhere near the traffic limit, despite having had the exit set to use 50Mbit/s constantly for the past 3 months. As far as I'm concerned, it costs me nothing to run this exit node - my company needs the dedicated server regardless, and none of the ~50 websites I host use enough traffic to be affected by the fact that my server is using half it's available bandwidth for Tor. In an ideal world, I would rent a second Kimsufi server just for Tor purposes, which would cost £36/month (Kimsufi 16G) + £4/month (RIPE block). Therefore, if I were to participate in this experiment, I would say *£40 GBP / month* would get *10TB of 100 Mbit/s* exit traffic. Additional *20TB* traffic could be purchased for *£18 / month*, which would bring the maximum cost to *$92 USD / month.* > - Is it a stable hosting situation? For example, how do they handle > abuse complaints so far? > This is an important one, because OVH are not Tor-friendly. In fact, they aren't very friendly in general! Several people told me it was very foolish to run an exit node on an OVH server, since as soon as OVH get even a whiff of a complaint, they are quick to suspend. All my company-hosted websites are hosted on a second redundant server with another ISP so I'm not worried if OVH do find out and take that route and cut me off. I'm also not worried about legal issues, as I have positioned myself as a web-hosting customer of my own PLC, with terms and conditions absolving my PLC of any legal risks. In the off chance some legal authority were to come to my flat in britain, they would find no electrical equipment to seize as I own only a single laptop and it usually lives in my car or partners house anyway! As I have only been running this exit for 3 months, I am far from an authoritative voice on the issue of abuse complaints, but the most important thing is definitely SWIP as far as I can see it - the IP address I use for the exit is one from the RIPE block I lease and as such the abuse email is my own. I've had about 20 abuse report emails so far, all automated (by the looks of things) from some system within the brazilian government, following an Sqlmap SQL injection scan/attack on a few government sites. I replied to the first one with the standard template, got no reply, haven't worried about it since. I reckon if OVH found out I was running an exit they would be likely to cut me off fairly swiftly, but they don't seem to pay much attention to Kimsufi customers since it is their budget range with very slow (week+ per ticket) support and presumably low margins. I think that and me as the primary abuse contact for the IP mean it's likely to stay up for a while. If I do get any hassle, I'll defend it as far as I can from a business perspective, but if they don't give in I'll likely just cancel it and open a new Kimsufi lease - I very much doubt anyone is checking new invoices for similar details to past customers. > - Is your hosting situation one where it could make sense for us to > reimburse your bandwidth costs? (Some people have a deal through their > employer, friend, etc where they don't pay for hosting.) > I don't think so - as explained above, at present I don't pay a penny, but I can only offer about half of my available bandwidth as the server is used for many purposes. If I were to participate in this experiment, it would probably mean purchasing another Kimsufi just for this, and the cost of the server itself would be what I would be looking for financial help with. > - Are you in a position to get more bandwidth if you pay more? At what > rates? We're most interested in sponsoring >=100mbit relays. > Unfortunately the Kimsufi servers are capped at 100Mbit regardless of whether you want to pay more. OVH obviously have Gbit and 10Gbit servers available, but they are too expensive for this. There are obviously far better alternatives for higher bandwidth servers - a quick look tells me I could get a 1Gbit dedicated server with 100TB traffic from Leaseweb for €99 ($121) / month, so obviously if the money is there, more bandwidth and traffic can be had. I guess it boils down to how many people you can get interested in this - if plenty, lots of 100Mbit servers is presumably better than a few 10Gbit ones for the money as it aids network diversity, even if (worst case) they are all hosted by the same provider. > - Do you have other locations in mind where you would run another exit > relay if you didn't have to pay for it? > Definitely! As far as I'm concerned, I am not worried about legal issues as long as I can purchase hosting through my business and SWIP the IP, and I have plenty of free time to spend configuring servers and responding to abuse emails, so if I had the money I would happily be running exit nodes in any country I could find a hosting provider in - money is the hurdle for me. > - What else should we be asking here? :) > One thing which I haven't seen discussed yet is how funding would actually be connected with operators - I'm not sure if you were thinking about the funder(s) directly sending money to operators, or if The Tor Project Inc would be acting as a middleman? What money transfer mechanisms would be safe to use, how would you verify that the money was going to the right person, would The Tor Project Inc receive invoices directly from hosting companies or would operators email copies of invoices to someone and then some money would turn up in their bank accounts? What about PayPal, etc? Just a few thoughts :) Thanks! > --Roger Thanks for inviting me to share my thoughts on this! -Andrew

8 10

How to protect yourself from network scanning
by amki 01 Aug '12

01 Aug '12

Hiho, I am hosting a 3-5MB/s tor exit relay but as of today my hoster has closed my server because of network scanning. Is there a known proper way to protect yourself from being used as a network scan relay? I've thought about constructing iptables rules to limit the number of SYN packets for the same host per second or such, but I'm not sure if this is allowed or will get me flagged as a bad exit node. My hoster is quite ok with us generating some abuse complaints per month, but does not want to route network scanning traffic since it is a severe load to their routers. Any help would be appreciated Cheers amki -- "Whatever the reason you're on Mars, I'm glad you're there, and I wish I was with you." - Carl Sagan

5 5

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Steve Snyder 01 Aug '12

01 Aug '12

Roger Dingledine arma at mit.edu Mon Jul 23 18:58:54 UTC 2012 [snip] >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. [snip] From what I see on the TorStatus pages (torstatus.all.de, blutmagie.de) about a third of the roughly 3000 relays listed are at or below 64KB/sec of demonstrated bandwidth. No doubt some of these are soon-to-be-high-bandwidth servers that are just ramping up, and some are nodes having transitory networking problems. It seems reasonable to assume, though, that most of these low-bandwidth nodes are intentionally low-bandwidth, perhaps on the basis of the Tor doc stating a 20KB/sec minimum. With "80% of their choices come from a pool of 40-50 relays" that leaves a 20% chance for the remaining 2950 nodes. A case for low-bandwidth nodes can be made as a means to dissuade anticipated routing (due to pool size), but it seems from the stats quoted above that there is little chance that 2000+ of these 3000 nodes will ever carry Tor traffic, and thus can be ignored for purposes of traffic analysis. Is there any justification for a low-bandwidth Tor node? And if so, what is the practical minimum bandwidth needed to actually see any traffic?

4 3

Re: [tor-relays] Negative impact of MaxOnionsPending 250?
by Scott Bennett 31 Jul '12

31 Jul '12

On Thu, 26 Jul 2012 17:11:17 +0200 Moritz Bartl <moritz(a)torservers.net> wrote: >We sometimes see "Your computer is too slow to handle this many circuit >creation requests!" on our servers. Scott Bennett suggested to set >MaxOnionsPending to 250 instead of the default of 100, which at least >makes the warnings disappear. [1] > >I am thinking about modifying out torrc template we use as as basis for >all servers. What is the negative impact of setting MaxOnionsPending to >250? Should we instead reduce the bandwidth as suggested in the warning? I don't think so. To the best of my recollection, I've only seen this message in recent versions of tor when it appeared that my node had been chosen for one or more high-volume hidden service operations, where the traffic volume in B/s was still fairly low, yet the number of connections had suddenly climbed to an unusually high level. The data throughput capacity vastly exceeded the actual traffic, but the onionskin-decoding load was sometimes, but probably not continually, very high until the hidden service(s) either shut down or changed their advertised information in the hidden service directory. To lower my node's RelayBandwidth* values would most likely have little impact on the bottleneck. Raising MaxOnionsPending adds a little slack in the queue to handle the occasions where that activity is temporarily backlogged prevents dropped connections and allows operations to proceed normally with only minimal extra delays. Consider a delay of probably no more than a second at the outside and usually less versus the delay of building a new circuit to a hidden service due to a dropped connection. > >[1] https://lists.torproject.org/pipermail/tor-relays/2012-May/001352.html 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 * **********************************************************************

1 0

Re: [tor-relays] Call for discussion: turning funding into more exit relays
by Zac Lym 30 Jul '12

30 Jul '12

This seems (to me) like an obvious suggestion, so my apologies if it's already been thought up. Why not establish a team/scoreboard system, like those used for distributed computing and BitCoin mining? This elegantly solves a few problems while with minimal resource commitment from the Tor organization. Most importantly, it's a way to pump money into the system without ruining the current atmosphere. Sponsors could easily buy some bandwidth or people can also just donate their own connections and join a particular team. The scoreboard is based on goodwill, not dollars spent. It also eliminates the hassle of setting prices, as teams can compete for dollars and bandwidth provided, essentially setting their own prices. The org could also setup a payment system, like we-pay, that the team admins can configure to deposit funds. It could be set as a proof of work system, paying after the bandwidth has been provided. This also allows a degree of control to prevent abuse from admins trying to juice stats by abusing some network infrastructure, like dummy trial accounts on hosting sites. A group admin could block specific hosts or the Tor project could remove an entire group. Finally, this could allow for the Tor project to create metrics based on things other than speed, akin to how Folding@home scores GPU and CPU contributions differently. Then the project can set anonymity goals for the network (such as location, ISP, backbone provider, etc) and the volunteers will adjust their patterns accordingly. Finally, I would like to strongly suggest taking a cut of all donations to pay for the new infrastructure and Tor research and development. I wouldn't want development to slow on Tor because donations are going to bandwidth instead. Indeed, I would prefer we spend a ton of money on the stenography efforts and usability. Anyway, thanks for the hard work! -Zach Lym

2 1

nickname to fingerprint
by Aichetou Med 28 Jul '12

28 Jul '12

hello tor community my question is : is there an "easy" way to translate relay nickname to fingerprint ? if not is it possible to download descriptors for some specific relays given "Digest" string from consensus file? i mean before launching tor. besides is there a reason for not showing the fingerprint in the consensus. thank you :)

2 1

Script to get top relays, AS and countries weights
by delber 27 Jul '12

27 Jul '12

Hi! Attached is a pretty simple Python script to compute some statistics about relays. Here's the doc: Usage: tor-relays-stats.py <output> [args ...] Where <output> is one of: - countries [FLAGS] relative percentage of the consensus in each countries - as-sets [FLAGS] [COUNTRIES] relative percentage of the consensus in each AS sets - top [COUNT] [FLAGS] [COUNTRIES] top relays according their place in the whole consensus Examples: - To get the top five exit nodes in France: tor-relays-stats.py top 5 Exit fr - To get weights of each AS of all relays in Germany: tor-relays-stats.py as-sets Running de Maybe it has flaws. Maybe it should land in some Git repository. I just felt it might be of interest to other folks. Feel free to comment and hack. -- delber

3 14