Re: [tor-relays] Negative impact of MaxOnionsPending 250?
On Thu, 26 Jul 2012 17:11:17 +0200 Moritz Bartl mor...@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 * ** ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
On Mon, 30 Jul 2012 18:51:35 -0400 Steve Snyder swsny...@snydernet.net allegedly wrote: Allowing exits from ports 80 and 443 will always carry the risk of abuse complaints. It would be better to retain 80 and 443 as exit ports and just block traffic to the Google/Yahoo/AOL/etc. mail servers but I don't how that could be done with their respective load-balancing schemes. IP address based policy is tricky to use when large systems can use wide address ranges. And these addresses change over time. Question for tor developers. How hard would it be to change the logic (and syntax) of exit policy in tor to allow domain based formulations like: reject *.gmail.com reject *aol.com etc. Mick - blog: baldric.net fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 Note that I have recently upgraded my GPG key see: http://baldric.net/2012/07/20/gpg-key-upgrade/ - signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
On 31.07.2012 12:21, mick wrote: Question for tor developers. How hard would it be to change the logic (and syntax) of exit policy in tor to allow domain based formulations like: reject *.gmail.com reject *aol.com We see webmail based spam reports from all kinds of addresses. The better approach is to use ISPs that don't get upset by such reports. -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
Hi Roger, On Mon, Jul 23, 2012 at 02:58:54PM -0400, Roger Dingledine wrote: 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. You might also consider matching operator investment in a relay (similar to employer charity donation matching programs that exist in the States). I would continue to be willing to contribute my own money even with sponsor dollars, but with matching my relay would be able to take more advantage of the economics of scale. In addition, if the funding suddenly dries up, the exit node doesn't immediately die, it just goes back to the original capacity I'm comfortable funding myself. \t ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to protect yourself from network scanning
I've thought about constructing iptables rules to limit the number of SYN packets for the same host per second or such Multiple flows to the same host don't really bother routers of any class. Old routers choke when looking up many hosts in the routing table. So your proposed rules against port-scanning single hosts wouldn't help. Unless each SYN to a host is generated from multiple Tor-based IP-scanner's, in which case your node or Tor would probably be underwater from the parallel scans anyways. Is there a known proper way to protect yourself from being used as a network scan relay? You can't really implement rules to block IP-scanning because you'll just take yourself offline. Which is exactly what ISP's do when their router falls over. The problem is fixed at the source, not the dest. In the TCP only case of Tor, best you can easily do is 'reject *:port' the ports being scanned, thus denying service to the scanner's Tor client and thus emitting no such traffic yourself. If it's well-known ports, such is life for your relay. I am hosting a 3-5MB/s tor exit relay ... does not want to route network scanning traffic since it is a severe load to their routers. If they can't deal with a single host doing IP-routing lookups, sounds like they need to replace their 10yr old Crisco routers or exit the biz. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to protect yourself from network scanning
2012/7/31 grarpamp grarp...@gmail.com: I've thought about constructing iptables rules to limit the number of SYN packets for the same host per second or such Multiple flows to the same host don't really bother routers of any class. Old routers choke when looking up many hosts in the routing table. So your proposed rules against port-scanning single hosts wouldn't help. Unless each SYN to a host is generated from multiple Tor-based IP-scanner's, in which case your node or Tor would probably be underwater from the parallel scans anyways. Or perhaps their network is perfectly able to take that, but their staff is unwilling to look beyond « I recieved a mail on abuse@ » ... ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
On Wed, Jul 25, 2012 at 06:32:30PM +0200, Julian Wissmann wrote: we've got an offer for 10GBit unmetered@750?, which is kind of sweet spot performance/buck wise and I guess, that it could handle 8-12 Tor nodes performance wise to satisfy the pipe. It would be a large number of high performance nodes run by just one operator, though, so I'm unsure if it really is that great idea :-( I think 10gbit is too big for the current Tor network. The total bandwidth of the network is something like 24gbit currently: https://metrics.torproject.org/network.html#bandwidth and it's more like 10gbit if you just count exits. So it makes sense to get a bunch of 1gbit spots (to offset the couple of 1gbit spots we have already), but I think 10gbit would make things too uneven at this point. --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
On Thu, Jul 26, 2012 at 12:01:13PM -0400, Steve Snyder wrote: 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. 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. Yep. Note that I raised the minimum to 30KB/s a year or so back: https://www.torproject.org/docs/tor-doc-relay Here are the current cutoffs for flags from moria1's perspective: Jul 31 18:50:01.000 [info] Cutoffs: For Stable, 656736 sec uptime, 509452 sec MTBF. For Fast: 32768 bytes/sec. For Guard: WFU 94.512%, time-known 691200 sec, and bandwidth 128000 or 133912 bytes/sec. Meaning if you don't have 32KB/s advertised in your relay descriptor, you won't get the Fast flag and most clients will ignore you. 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. You're using the wrong numbers (the 40-50 relays are just for the exit position, and there are only ~920 relays with the Exit flag), but your point is right. Karsten made this graphic earlier to show that the top 50 exits account for 78.9% of the exit weights: https://trac.torproject.org/projects/tor/attachment/ticket/6443/exit-proportions.png Is there any justification for a low-bandwidth Tor node? We could imagine alternate designs like Mashael's multipath design that spreads Tor flows across multiple circuits: http://www.cacr.math.uwaterloo.ca/techreports/2011/cacr2011-29.pdf But currently, no, tiny nodes are not particularly helpful. There's an open research question as to whether they even hurt. Or more specifically, what the performance curve looks like if we dump the X% slowest relays: https://trac.torproject.org/projects/tor/ticket/1854 I had originally imagined doing network simulations with Shadow or Experimentor to help answer #1854, but it's proving particularly tough to get an accurate network model at that level: https://shadow.cs.umn.edu/about/papers/tormodel-cset2012.pdf And if so, what is the practical minimum bandwidth needed to actually see any traffic? Actually, even these tiny relays see traffic. That's because of the sheer number of Tor clients out there -- if enough clients make enough circuits, some of them will be through the small relays. The question is whether the bandwidth cap on them makes that circuit especially no fun to use, relative to what you'd get if we squeezed all the users onto a smaller number of higher-bandwidth relays. My guess is raising the min bw for the Fast flag to 50KB or even 100KB would reduce the variance in torperf performance: https://metrics.torproject.org/performance.html?graph=torperfsource=moriafilesize=1mb#torperf --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
On Thu, Jul 26, 2012 at 07:34:14PM +0100, mick wrote: 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. Forgive me, but what do they want in return? (He who pays the piper...) Part of BBG's job is to make sure that everybody in the world can reach their content for Voice of America, Persian News Network, etc. Certain countries censor those websites, so they need tools like Tor that let people reach their websites anyway. The individuals we're working with at BBG are sympathetic to the notion that security is an important component of circumvention: https://svn.torproject.org/svn/projects/articles/circumvention-features.html But when centralized-design tools like Ultrasurf put all their energy into performance and little into security: https://blog.torproject.org/blog/ultrasurf-definitive-review this disparity in performance overshadows the disparity in security, making it harder for them to justify recommending Tor. So they want to make the Tor network more pleasant for their users. So long as we don't lose track of the fact that anonymity loves company (we need Tor to work well for all sorts of users in all sorts of locations), it's a great match. --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
On Fri, Jul 27, 2012 at 05:49:34AM -0400, Motoko Kusanagi wrote: I am very interested in running 100 Mbit (maybe even more) exit nodes at 100$/month, however, a question immediately comes to mind: When we say 100Mbit exit node, do we imply really unmetered traffic at 100 Mbit, or do we mean semi-reasonable traffic limit at 100Mbit speed. Really unlimited, in my experience, oftentimes turns out to be somewhat problematic. I don't think we necessarily need to have the 100mbit all to ourselves (see the other discussions here about shared connections), but I think it needs to be able to push a good fraction of 100mbit throughout the month. So something that can handle 20-30TB/mo is in the right ballpark. Note that many of our current 100mbit nodes are actually gbit nodes that try to limit themselves to a long-term average (95th percentile) of 100mbit. I could arrange for 50-100 100Mbit exit nodes running 24/7, with a traffic limit somewhere between 1 and 4 terabytes (will need to scrutinize my current contract and do some math). Arranging for such a number of honestly unlimited traffic at 100Mbit speed would be...significantly more problematic. 4TB/mo is good for a 10mbit connection, but not good for a 100mbit connection. You'll end up either needing to hibernate for 80% of the month, or rate limit your relays down a lot. That said, we don't need 50-100 100mbit exit relays from any single group. Just 5-10 would be nice. Maybe that makes the capacity issue easier? --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-assistants] Call for discussion: turning funding into more exit relays
On Sun, Jul 29, 2012 at 03:05:32PM +0100, Andrew Beveridge wrote: - 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. Sounds like you should bump it up to 100mbit then. ;) You can see on http://atlas.torproject.org/#details/FA02311AF49EB663CA2685A8604C403A9E10E6E3 that there are periods where your rate limiting is bottlenecking traffic. 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.* Sounds like a good price. And even though everybody says OVH is unsuitable, it looks worth continuing to try in this case. Maybe we can encourage you to run the new one as you describe, but also bump up the bandwidth on the first one. As you say, it's unlikely that you'll actually max out the transit all the time. 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. Yes, a SWIP seems increasingly critical for stable exits. 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. I say we set this one up and see how it goes. In your spare time, please do continue to look for other opportunities. You should probably compare notes with Moritz, Julian, et al here about places you find. 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 :) I definitely don't want Tor to be in the middle of the transactions -- if Tor pays the bills directly, that's too much like being the relay operator. One nice situation would be for you to produce receipts showing expenses, and then we reimburse those costs. It requires fronting a bit of money on your part, but that's part of saving the world, yes? :) Ultimately, we're also going to want to look into reducing overhead on Tor's side from sending out money. If we have to write and mail 50 checks every month, that's going to waste a lot of somebody's time. Maybe that means Paypal is the way to go. Maybe it means we send some money in bulk to Zwiebelfreunde, and they do intra-Europe wire transfers to the other Europeans (though I admit maybe that just shifts the time-wasting). Lots of options there. What would be best for you? All of this said, don't go out and start spending money quite yet. We should figure out these logistics first. And Tor should get a bit more of a handle on what this diversity thing should mean. And I should get buy-in from other Tor people for my plans here. :) --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org
Re: [tor-relays] Call for discussion: turning funding into more exit relays
Is there any justification for a low-bandwidth Tor node? Other than the diversity of having more nodes around... seems from discussions here that slower nodes see less users. Which means they're not as likely to be blocked by content providers for user misbehavior. This can be valuable for the legit users who manually pick slower nodes to see if they can get through. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
