- tor-relays - lists.torproject.org

Re: [tor-relays] Port-Based Best-Fit Circuit Selection
by Tim 20 Sep '14

20 Sep '14

[Edit: Convert to end-posting & fix quote levels] On 18 Sep 2014, at 10:40 , Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: > On Wednesday 17 Sep 2014 22:40:36 Tim wrote: > >> On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: >> >>> On Tuesday 16 Sep 2014 17:36:41 Toralf F?rster wrote: >>> >>> On 09/16/2014 03:35 AM, Paritesh Boyeyoko wrote: >>> >>>> Hello -- >>>> So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not >>>> also have port-based entrance policies? I >>>> >>>> >>>> Beside the general answer (probably "NO") - you mean something, which cannot be handled by a firewall ? >>>> >>> >>> >>> @Toralf Correct, this has nothing to do with firewalls. This is more about better utilisation of slow circuits/relays by deliberately choosing to push relatively lightweight traffic across them. IRC and XMPP do not need 10Mbit/s circuits, not even close. I'm not sure how Tor clients choose the relays they use to build a circuit, and I do realise that a) there are probably more slow relays than fast ones b) attempting to pre-build both a "fast circuit" and a "slow circuit" will reduce the number of candidates for each. I'm just looking for ways to drive more traffic across slow relays. :) >> >> >> >> Paritesh, >> >> >> I think it might help to make a distinction between latency (delay) and throughput (capacity), both of which are affected by router speed: >> >> >> IRC, XMMP and SSH need low latency circuits, which are mostly correlated with high bandwidth relays. >> >> >> Web Browsing (HTTP/S) and similar generally need both low-ish latency and high throughput, also correlated with high bandwidth relays. >> >> >> File Downloads (HTTP/S, BitTorrent) can cope with high latency as long as the throughput is high (and the reliability is sufficient, but that's another matter). >> >> >> But I can't actually see much need for high latency, low throughput relays - are there many protocols that would find that useful? (SMTP is the only one that comes to mind.) >> >> >> T > > > Hi Tim -- > > Very good points, and yes most likely the mail protocols would be candidates for "slow", high > latency circuits. > > However, there may be another class of relays that's overlooked - many VPS providers sell VPSes > with low data caps, even on fast connections (100Mbit/s). There are two ways to address this: > > a) traffic accounting: the relay hibernates until the next reset > b) throttling so that the data cap for the month isn't prematurely reached. > > I'd imagine that most relay operators with such VPS packages will choose to throttle and keep the > relay up and running continuously rather than having it hibernate (I know I've had to do this in the past). > The actual connection is fast enough to not suffer real latency issues, it's just the relay doing the throttling > - do you think throttling to 0.5Mbit/s or 1Mbit/s will create issues of high latency? > > I'm about to go and read the Conflux paper: > > "In this paper, we present Conflux, a dynamic traffic-splitting approach that assigns traffic to an overlay path > based on its measured latency. Because it enhances the load-balancing properties of the network, Conflux > considerably increases performance for clients using low-bandwidth bridges." > > This would obviously create better utilisation of circuits as a whole, so it may well make my idea totally redundant. :) > > Cheers, > > -- > Paritesh Boyeyoko Paritesh, For fast Tor relays with low data caps, the general advice is I've heard is two-fold: * enable AccountingMax, which will hibernate the router when the bandwidth is used up, and * disable directory caching to save (upload) bandwidth (AccountingMax does this automatically when it's configured) This means that the network has many fast routers each covering some of the day/week/month, rather than many slow routers for the entire month. (It also uses the entire bandwidth quota more efficiently - what if the calculated bandwidth limit is too low?) Tor seems to need more fast routers to reduce latency, because there is a long tail of slower routers which can provide significant capacity when needed. T

3 2

Torservers.net relays not updated yet?
by Nusenu 19 Sep '14

19 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi torservers, since you haven't updated most of your relays to address [1] released on 2014-07-28 yet, I was wondering if everything is ok? collective vacation? Since you are operating a significant chunk of the tor network's bw - timely patching is appreciated. The tor network is currently at 64% of the bandwidth being served by relays running a recommended version according to torstatus.blutmagie.de. I updated a previous metrics feature request so we might see nice graphs about patching progress in the future [2]. [1] https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html [2] https://trac.torproject.org/projects/tor/ticket/6856#comment:2 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT7+R/AAoJEDcK3SCCSvoeevcP/06Jg2ubrbbD+SKe32necCd2 OCp4auBI3M8LjxVwJMaMi1aBW81Y513shnghYvAVLRe8NCFuem0mnWfeZq6fjrqd kKvksRhCUo2ERK7covRaoVJ8Aqs37MDJh7B48v/FYcbQYbeRIw6+OUmysC6qMPvP gi+ReWFL77kW4hAK+05z6VeaBq6FfKA8L2FRF12ahtGokCO9BnPM1DijHnA4kLJG Fh2YxbWegd5wVna3PJrubjyJ5ANHM0L5pS0dPZZNobat7Sdrux7dhLo2VdHqZFT5 etykHjc18iJhm7z0r4qjYo58gEAx9CebTqdq2w22TBQFnXPaEt9oPktpdG1Q+Ba+ wPiOOBODyngqSUICD6LRGFq3L9Xa+1RrxORD+d+XmsrGhire+83BLkxDZ/JqUB0Z ZY4NEc13tTQqxPfqB6yQyU/XjTPl45zYWsaAxBjzX/AqoXgkwAQkBwdpFrUeu0O3 UiHe4DLhYtcoeOJjisqfl8t7xbyi5TduKfFH10Erglr3WX/OJ/Pau1N/tDtNqey8 GbrZSXVtv0ch7T31Cp6hYrZwxYnucUBcotcOX01+k158zpI5wv87WCwpc9ncDO3t Oj8ORAL/MbgtYh0JaE1wIP0zSuhhWY2Y+qzdXnTwoYMbfDNnLUjcgZzbZNOhEu+E Y3LfuCsT+DI5TpwIp6tK =FZKz -----END PGP SIGNATURE-----

3 9

RELAY_EARLY tor network update status (CVE-2014-5117)
by Nusenu 18 Sep '14

18 Sep '14

(if you are on the CC list of this email you are probably one of the tor relay operators running one of the 10 fastest vulnerable [CVE-2014-5117] relays on the tor network. Please upgrade your tor relay) > The tor network is currently at 64% of the bandwidth being served by > relays running a recommended version according to torstatus.blutmagie.de. > I updated a previous metrics feature request so we might see nice > graphs about patching progress in the future [2]. Since we are seeing active RELAY_EARLY attacks again (or new buggy tor implemantations) I was wondering what the current update stats look like. ~85%* of the tor network's bandwidth is provided by patched relays. (~66% 0.2.4.23, ~11% 0.2.5.6-alpha, ~7% 0.2.5.7-rc) *) according to data from torstatus.blutmagie.de 10 fastest relays still running a vulnerable version: https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036… https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB… https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FD… https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B03… https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A89684… https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A… https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA… https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A… https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A… https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BE…

3 2

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running relay
by Dan Hanley 18 Sep '14

18 Sep '14

> > > I have just received a slightly more positive reply: "At present, our GeoIP data provider classes Tor nodes as proxies, regardless of whether or not they're an exit node. We understand that there is room for improvement in this model, since non-exit relays do not present traffic on behalf of other users. We have asked our provider to give us a way of differentiating Tor exit nodes from non-exit relays, to allow us to block exit nodes only." So perhaps they will make a change... certainly reporting the issue seems to raise its importance :-) atb Dan > 5. Re: BBC and UK Lottery blocking ip addresses running relay > nodes (Chris Whittleston) > ---------- Forwarded message ---------- > From: Chris Whittleston <csw34(a)cam.ac.uk> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 01:40:31 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay nodes > Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt > though, it seems like they still don't get the difference between using Tor > as a client and running a relay, so this isn't the end of the road there. > You are going to have to rely on them wanting to actually think about it > though. > > If all else fails, you could always try to simply report the issue again > using the form I linked before, but this time just don't mention Tor at all > and see if you get a different customer service person... > > http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 > > I suspect you'll end up having to explain that you're running a relay in > the end anyway, but you never know. > > Chris > > On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: > >> Stephen Mollett: >> > [...] >> > "Thank you for contacting the BBC iPlayer support team. >> > >> > "I understand you’re experiencing problems accessing BBC iPlayer as >> > you’re told that you are outside of the UK. >> > >> > "Please note that if you run TOR, then I’m afraid as per our development >> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >> > continue to use TOR then your IP address may be blacklisted against UK >> > only services across bbc.co.uk." >> > >> > I made a point of stating explicitly in my original case filing that I >> > run a middle relay and that no traffic exits from my node to the BBC's >> > website or to anywhere else, along with a link to my node's stats on >> > blutmagie confirming the (non-)exit policy. >> > [...] >> >> Hi Stephen, >> >> I'm not sure whether I'm surprised at the BBC or not! >> >> It is a shame if they seem to be doing blanket blocking of Tor relay IP >> addresses. I suppose this >> ( >> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >> ) >> has /some/ relevance. >> >> The problem is obviously convincing a organisation like the BBC to treat >> individual IP addresses different from other Tor relay IP addresses (and >> whether they should be doing that at all). Although it seems Chris >> Whittleston obviously managed it! Maybe you simply got 'the wrong person >> at the other end'. Personally, I would continue to pursue this with them! >> >> --Matt >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > *Dr Chris Whittleston 栗主* > Department of Chemistry > University of Cambridge > Lensfield Road, Cambridge, CB2 1EW > Email: csw34(a)cam.ac.uk > Tel: +44 (0)1223 336423 > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

3 2

Where to report relay warnings
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, I also found a lot of the mentioned log entries. The comment from Arma within the ticket is just right "Bonus points for using the name in the NSA document" Rofl :-) -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Where to report relay warnings
by Jens Müller 18 Sep '14

18 Sep '14

Hi there My relay logged the following warning this morning: Sep 18 04:52:58.387 [Warning] Received an inbound RELAY_EARLY cell on circuit 2147511747. Closing circuit. Please report this event, along with the following message. Sep 18 04:52:58.388 [Warning] upstream=85.159.214.57:9003 Now, I have checked the FAQs but didn't found any information where to report this, so I hope you can help me out. Thank you already and kind regards Jens

2 1

Bridge Offer
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, If there is still not enough bridge capacity available after a few people already offered their help, i would be able to help with 400 Mbit (no traffic limit). -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Fwd: Call for a big fast bridge (to be the meek backend)
by Mike Perry 18 Sep '14

18 Sep '14

Forwarded from tor-dev to here, in case any relay operators missed this: ----- Forwarded message from David Fifield <david(a)bamsoftware.com> ----- Date: Mon, 15 Sep 2014 19:12:23 -0700 From: David Fifield <david(a)bamsoftware.com> To: tor-dev(a)lists.torproject.org Subject: [tor-dev] Call for a big fast bridge (to be the meek backend) User-Agent: Mutt/1.5.23 (2014-03-12) The meek pluggable transport is currently running on the bridge I run, which also happens to be the backend bridge for flash proxy. I'd like to move it to a fast relay run by an experienced operator. I want to do this both to diffuse trust, so that I don't run all the infrastructure, and because my bridge is not especially fast and I'm not especially adept at performance tuning. All you will need to do is run the meek-server program, add some lines to your torrc, and update the software when I ask you to. The more CPU, memory, and bandwidth you have, the better, though at this point usage is low enough that you won't even notice it if you are already running a fast relay. I think it will help if your bridge is located in the U.S., because that reduces latency from Google App Engine. The meek-server plugin is basically just a little web server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek… Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it. My PGP key is at https://www.bamsoftware.com/david/david.asc if you want to talk about it. David Fifield _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- End forwarded message ----- -- Mike Perry

3 2

Re: [tor-relays] Port-Based Best-Fit Circuit Selection
by Tim 18 Sep '14

18 Sep '14

On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: > On Tuesday 16 Sep 2014 17:36:41 Toralf F?rster wrote: >> On 09/16/2014 03:35 AM, Paritesh Boyeyoko wrote: >>> Hello -- >>> So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not >>> also have port-based entrance policies? I >> >> Beside the general answer (probably "NO") - you mean something, which cannot be handled by a firewall ? >> >> > > @Toralf > > Correct, this has nothing to do with firewalls. This is more about better utilisation of slow > circuits/relays by deliberately choosing to push relatively lightweight traffic across them. > IRC and XMPP do not need 10Mbit/s circuits, not even close. > > I'm not sure how Tor clients choose the relays they use to build a circuit, and I do realise that > > a) there are probably more slow relays than fast ones > b) attempting to pre-build both a "fast circuit" and a "slow circuit" will reduce the number of > candidates for each. > > I'm just looking for ways to drive more traffic across slow relays. :) Paritesh, I think it might help to make a distinction between latency (delay) and throughput (capacity), both of which are affected by router speed: IRC, XMMP and SSH need low latency circuits, which are mostly correlated with high bandwidth relays. Web Browsing (HTTP/S) and similar generally need both low-ish latency and high throughput, also correlated with high bandwidth relays. File Downloads (HTTP/S, BitTorrent) can cope with high latency as long as the throughput is high (and the reliability is sufficient, but that's another matter). But I can't actually see much need for high latency, low throughput relays - are there many protocols that would find that useful? (SMTP is the only one that comes to mind.) T

3 2

BBC and UK Lottery blocking ip addresses running relay nodes
by Dan Hanley 18 Sep '14

18 Sep '14

All I can see there was a previous thread related to this in June, but thought I'd add what I'm seeing to the discussion. After the *Data Retention and Investigatory Powers Bill (DRIP) *was rushed through parliament I decided to do my bit for the privacy cause and run a couple of Tor relays. I run one from my laptop at home and one from my desktop at work. Since doing this I have suffered deliberate disruption in service from the BBC and the National Lottery. A Tor relay is a node on The Onion Router network that traffic gets router through to anonymise where it originated from. ( https://www.eff.org/torchallenge/what-is-tor.html) Note that I am running middle relays, not exit relays, so the connection to the destination site will never come directly from one of my relay nodes. Neither have I used the Tor browser to access either site. *The BBC* Within 48 hours the http://bbc.co.uk website started redirecting me to the http://bbc.com international version. They seem to think I am no longer a licence payer, or perhaps conspiring to allow non licence payers to access their UK service. The redirect is based on my homes IP address, so all devices, laptop, phone, ipad etc get redirected. The redirect seems to trigger via Javascript, I can access http://www.bbc.co.uk with Javascript disabled. The international site recognises that my ip address is in the UK and refuses to let me access international content. The net result is that I and my family can no longer access either UK or international BBC content. *The National Lottery* The Lottery allows me to connect and browse their site but as soon as I try to make a purchase I get blocked: *Why is this odd:* Any of the popular IP checking sites/tools show that my address is located in the UK: e.g www.whatsmyip.com or https://who.is I am using two different ISPs (Zen and VirginMedia) neither can explain the behaviour. Contacting the lottery they blame the ISP, I have been unable to get a response from the BBC. Assuming I can believe the look up services and the ISPs that my IP addresses are still located in the UK, the only explanation I can come up with is that the BBC and the lottery are deliberately blocking ip addresses that are registered on the Tor network. Whether they do this independently or avail of a common third party is unknown. So the cost of trying to maintain privacy seems to be the loss of BBC and Lottery – which seems unfair. Regards Dan

4 4