Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
On Thu, Dec 22, 2016 at 2:07 PM, Rana wrote: > If there is such a wiki I will be happy to submit my reports, I am not aware > of one. Please see and contribute to the following... https://trac.torproject.org/projects/tor/wiki/doc/HardwarePerformanceCompendium > Also, based on this thread the people who may take action and decisions seem > to be convinced that home relays are of no or very little use to Tor. For > this reason, whether they are right or not, I am not sure we should bother > beyond the unstructured discussion in this thread. If the source code and network technically permits any given node, it is valid for discussion. I've often suggested that all node selection and testing / ranking / node trust pki metrics / geoip / etc all be left as subscription style services and/or configurable parametrics for clients to choose from or configure themselves. With some default "Tor Project" set shipped as fine for most users, in which Tor Project acts as one such supplier of such params. That leave only malacting nodes and 'net useful' nodes up to dirauths themselves. With 'useful' being no excuse to not make efforts to scale networks to the next level. ie: Networks like Phantom just distribute a DHT list of nodes, so conceivably if and how you use them is up to you. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is AES-NI enabled in tor?
Patrice: > From that I thought Tor used already OpenSSL but it wasn't installed. :S You had OpenSSL library installed as a shared object libcrypto.so to which tor is dynamically linked. Though you didn't have /usr/bin/openssl aka "OpenSSL command line tool". This is pretty common setup. > I bought this board with this CPU (incl. AES-NI support) because I > thought it would give a benefit. It's better to stick with more common techniques for ciphers, not with AES-specific. I mean vectorized operations in modern CPUs like AVX, AVX2, AVX512, NEON and even SSE3. Tor is gradually migrating to ChaCha20 instead of AES as stream cipher. ChaCha20 runs on vectorized operations in time comparable to AES with AES-NI and faster than AES w/o AES-NI since AES doesn't support vectorized operations. Also it's better to use different platforms in light of recent discussion about Intel ME and just because Tor needs diversity on all levels. :) -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] atx.name relays: MyFamily update required
Hi Josef, thanks for adding your 3 relays to the tor network! Please do not forget to set the MyFamily parameter in your torrc files so tor clients are not using your non-exit and exit relays at the same time in a single circuit. If you need help with configuring MyFamily, let us know. Since you are running tor 0.2.5.12 you might also want to consider updating to the recently released version 0.2.9.8. happy relaying, nusenu https://github.com/nusenu/ansible-relayor https://github.com/ornetstats/stats https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] MyFamily update required
pa011: > How can I best find out which ones bring me on your second one? - search for your all your relays on atlas.torproject.org. - open every of your relays in a new tab - look for orange colored family members (they represent misconfigured/asymmetric configurations) if there are none, make sure the number of blue lines in 'family members' is equal to the number of relays you run -1. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] potentially_dangerous_relaygroups explained
> thanks for your great work - lets assume for a second I would be with > several relays on both of you lists: > > https://raw.githubusercontent.com/ornetstats/stats/master/o/main_exit_operators.txt > > > https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt > > How can I best find out which ones bring me on your second one? https://github.com/ornetstats/stats wrote: > "dangerous" in the sense that a tor client might has a chance to use > more than one of these relays in a single circuit at the entry and > exit position these relays are aggregated based on contact > information if their groupsize is bigger than their effective family > size and they are operated in more than one /16 network block they > are listed this list might contain false-positives (contact > information is not authenticated) I hope that makes it clearer. > Whats the number in the column MyFamilyCount - how added up? MyFamilyCount or better effectiveFamilyCount is the number of effective family member elements +1 as reported by onionoo.torproject.org or said in another way: the number of blue lines seen on atlas.torproject.org in the family members section +1 signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] snaptor relays: MyFamily update required
Np - it was an issue with my update script ;-) Cheers Mark B Snaptor.co.uk (non commercial) > On 22 Dec 2016, at 23:03, nusenu wrote: > > thanks for fixing it! > > +---+---+ > | nickname | MyFamilyCount | > +---+---+ > | SnapExitBULG | 10. | > | SnapExitMOLD | 10. | > | SnapExitUS| 10. | > | SnapTorBANG | 10. | > | SnapTorCAN| 10. | > | SnapTorFr | 10. | > | SnapTorRelay1 | 10. | > | SnapTorSNPR | 10. | > | SnapTorSTRAS | 10. | > +---+---+ > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-relays Digest, Vol 71, Issue 93
Thank you! That was already the answer. :) You will not see anything in logs until this value isn't good and was adjusted by tor. For details, see compute_real_max_mem_in_queues() function in /src/or/config.c. Cheers, Patrice ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is AES-NI enabled in tor?
Please don't mix multiple questions into one thread. Sorry, my bad. Tor does not implement crypto itself (mostly) and relies on a cryptolibrary (which is OpenSSL/LibreSSL/etc) instead. Thus you should check if AES-NI is enabled in your cryptolibrary. An excerpt from StackOverflow answer [1] about it: $ openssl speed -elapsed -evp aes-128-cbc $ OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-128-cbc "Output of the first line should be significantly faster than the second." If there is no AES-NI enabled in "OpenSSL" these two should give similar results. I couldn't do that test. OpenSSL was not installed. After I installed it I could perform that test and it was positive. Here is the output: $ openssl speed -elapsed -evp aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 33370007 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 13118341 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 3915543 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 1029134 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 130438 aes-128-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Sep 23 17:53:23 2016 options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 177973.37k 279857.94k 334126.34k 351277.74k 356182.70k $ OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-128-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 6232419 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 1776077 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 454887 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 114409 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 14327 aes-128-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Sep 23 17:53:23 2016 options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128-cbc 33239.57k37889.64k38817.02k39051.61k 39122.26k But it is a little confusing for me because there is this line in the logs: Tor 0.2.9.8 (git-a0df013ea241b026) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. From that I thought Tor used already OpenSSL but it wasn't installed. :S I bought this board with this CPU (incl. AES-NI support) because I thought it would give a benefit. N.B. AES-NI is not a feature of*motherboard* - it's CPU instructions (NI stands for "New Instructions"). I simply forgot that. ;) Cheers, Patrice ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] snaptor relays: MyFamily update required
thanks for fixing it! +---+---+ | nickname | MyFamilyCount | +---+---+ | SnapExitBULG | 10. | | SnapExitMOLD | 10. | | SnapExitUS| 10. | | SnapTorBANG | 10. | | SnapTorCAN| 10. | | SnapTorFr | 10. | | SnapTorRelay1 | 10. | | SnapTorSNPR | 10. | | SnapTorSTRAS | 10. | +---+---+ signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] MyFamily update required
Hi nusenu, thanks for your great work - lets assume for a second I would be with several relays on both of you lists: https://raw.githubusercontent.com/ornetstats/stats/master/o/main_exit_operators.txt https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt How can I best find out which ones bring me on your second one? Whats the number in the column MyFamilyCount - how added up? Best regards Paul only example - not me... > +-+-+---+--+ > | first_seen | IP | MyFamilyCount | exit | > +-+-+---+--+ > | |9. |0 | > | |9. |0 | > | |8. |1 | > | | NULL |0 | > +-+-+---+--+ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
If there is such a wiki I will be happy to submit my reports, I am not aware of one. Also, based on this thread the people who may take action and decisions seem to be convinced that home relays are of no or very little use to Tor. For this reason, whether they are right or not, I am not sure we should bother beyond the unstructured discussion in this thread. -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of grarpamp Sent: Thursday, December 22, 2016 8:37 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP On Thu, Dec 22, 2016 at 4:59 AM, Rana wrote: > A 20 mbps Pi relay has been reported here, still under-utilized. All these reports of this or that made in piles of random email ... serves no one past the typical few day participant convos. So please people... submit all your hardware speed reports to the wiki in some organized tabular and broken out for descriptive commentary doco fashion so others can refer to it as a useful resource. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is MaxMemInQueues recognized my tor? (was: A Question about aes-ni and the use of RAM.)
Patrice: > And my other question is, does tor recognize this option? >> MaxMemInQueues 7000 MByte It does, see the man page or the source code. > Because I see nothing in the logs. > I am not 100% sure but I think tor gave a feedback when I used this > option in the earlier versions. You will not see anything in logs until this value isn't good and was adjusted by tor. For details, see compute_real_max_mem_in_queues() function in /src/or/config.c. -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
On Thu, Dec 22, 2016 at 4:59 AM, Rana wrote: > A 20 mbps Pi relay has been reported here, still under-utilized. All these reports of this or that made in piles of random email ... serves no one past the typical few day participant convos. So please people... submit all your hardware speed reports to the wiki in some organized tabular and broken out for descriptive commentary doco fashion so others can refer to it as a useful resource. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is AES-NI enabled in tor? (was: A Question about aes-ni and the use of RAM)
Please don't mix multiple questions into one thread. Patrice: > does anyone know if the aes-ni support of the motherboard is used by > default? (I saw nothing in the logs.) Tor does not implement crypto itself (mostly) and relies on a cryptolibrary (which is OpenSSL/LibreSSL/etc) instead. Thus you should check if AES-NI is enabled in your cryptolibrary. An excerpt from StackOverflow answer [1] about it: $ openssl speed -elapsed -evp aes-128-cbc $ OPENSSL_ia32cap="~0x202" openssl speed -elapsed -evp aes-128-cbc "Output of the first line should be significantly faster than the second." If there is no AES-NI enabled in "OpenSSL" these two should give similar results. N.B. AES-NI is not a feature of *motherboard* - it's CPU instructions (NI stands for "New Instructions"). [1] http://stackoverflow.com/questions/25284119/how-can-i-check-if-openssl-is-support-use-the-intel-aes-ni -- Ivan Markin ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
-Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of David Serrano Sent: Thursday, December 22, 2016 7:36 PM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP On 2016-12-22 19:24:25 (+0200), Rana wrote: >> >> 2. "Residential lines in particular ... hardware caves when too many >> connections are open in parallel" - this appears to be plain >> incorrect. [...] ith 1300 simultaneous connections. >His statement is right. 1300 connections are not a lot. I used to have a symmetric 20 megabytes/second line and the router provided by my ISP would reboot when reaching around 3600 >connections. Happily, they provided FTTH so I was able to put a linux box instead of said router and reach 13k conns. You are a part of a minuscule group of people who have a 160 mpbs symmetric connection to the home, and the first one I run into in my life. I therefore doubt that your example is relevant to the discussion - almost everybody else on the planet does not have this kind of bandwidth to the home, and cannot saturate a $35 Raspberry Pi with his Tor traffic because their bottleneck is ISP bandwidth, not hardware. Which was my point. -- David Serrano PGP: 1BCC1A1F280A01F9 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
On 2016-12-22 19:24:25 (+0200), Rana wrote: > > 2. "Residential lines in particular ... hardware caves when too many > connections are open in parallel" - this appears to be plain incorrect. [...] > ith 1300 simultaneous connections. His statement is right. 1300 connections are not a lot. I used to have a symmetric 20 megabytes/second line and the router provided by my ISP would reboot when reaching around 3600 connections. Happily, they provided FTTH so I was able to put a linux box instead of said router and reach 13k conns. -- David Serrano PGP: 1BCC1A1F280A01F9 signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
@Sebastian, Thank you for the detailed presentation of your arguments against the use of residential relays. While many (probably most) of the points you made are convincing and, coming from a DirAuth operator, difficult for me to contest, I would like to refer to those of them that seem to be less firm to me (I am not referring to the "political support" argument here, my points are purely technical): 1. If DirAuths are no longer the bottleneck , and the bottleneck shifted to the distribution of information about new relays, maybe it is the next problem that should be looked at and resolved by the Tor developers. 2. "Residential lines in particular ... hardware caves when too many connections are open in parallel" - this appears to be plain incorrect. A Pi based relay was recently reported here by @balbea that has 20%/60% CPU/memory utilization, respectively, 21 mbps (measured) peak/900 kbps (measured) average utilization by Tor, with 1300 simultaneous connections. The speed @balbea could squeeze out of his residential ISP is pretty amazing and, despite my call on this forum for further examples, unbeated and, to the best of my knowledge, all but unprecedented. And that's at 60% utilization of the bottleneck resource - the memory and the obvious under-utilization by Tor. If anybody's residential relay "caves" he should get a $35 Raspberry Pi and - yay - no more caving hardware. 3. "the connection (which most often is asymmetric, with less upload capacity than down) were any near saturated using the internet would become a horribly slow and unpleasant experience" - I see no problem whatsoever to engineer the use of bandwidth to 50% or 40% of the peak down BW available to the relay, so that this problem will never happen. After all, every Tor instance does a bandwidth self-test and knows what's its peak down capacity. So this appears to be a non-issue (or maybe an issue that was "neglected by design"). So again, many of your arguments are convincing but there appears to be room for re-engineering the parts of Tor that deal with small relays, to get a greater benefit from them. Moreover, there seems to be a disconnect between what I read, including on official Tor site, and the true state of affairs with small relays as presented by you. You are obviously a knowledgeable guy, and a member of the team that actually runs Tor and makes decisions. This makes me take your statement that running a small bridge is actually harmful, very seriously. Therefore, based what you say, my logical conclusion is as follows: the best thing for Tor would be as many people as possible running exits; but since this is beyond the risk most people are willing to take, the next best thing is running a BIG and stable guard or a BIG and stable bridge. The lowest priority is a bandwidth-wise small (even if stable) residential relay or a small bridge, to the extent that these (the small ones) are not really needed and are actually likely to do damage by overloading the Tor descriptor distribution mechanism or screwing up the way people use bridges, respectively. Which makes me wonder - why aren't there clear guidelines on Tor site about this? I have read there (I do not remember on which page) the following recommendation (or rather, a call for action with an exclamation mark): "If you cannot be an exit, be a relay. If you cannot be a relay, be a bridge!" This is obviously addressed to people who do not have intimate knowledge of Tor and may be just about to make a decision to run a node. Nobody tells them that they should not run a bridge or a relay if they are on residential premises, let alone that this could actually do more damage than good. Rana ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
Hi there, I am one of the directory authority operators, so while I don't claim to know what the collective community wants, I am one of the people who are asked to make these decisions. > On 22 Dec 2016, at 10:25, Rana wrote: > > So my question to the community is as follows: does the Tor community want > these small, cheap relays scattered in large quantity around the world, or > not? Executive Summary: On balance, the very small relays do not contribute enough resources compared to the associated costs to be worthwhile. Details below. > I realize there could be pros and contras. Among the contras there could be > (for example) many small relays overloading the dirauths. I would like to > hear more about the contras. The dirauths are indeed a bottleneck in the Tor relay ecosystem, as they have to reguarly contact each relay, measure its bandwidth, check for malicious behaviour etc. But the dirauths are doing fine. The load my dirauth receives is negligible compared to what it could handle. There's a much bigger contributing factor here, however: The information about all relays must be made available to all clients, in a somewhat synchronized fashion. Tor has recently improved its design in this regard massively with the introduction of microdescriptors, and since then it's become somewhat more tolerable to have many small relays. In the past, we allowed relays in the network that were a net drain on available bandwidth, because just distributing their key material used up more bandwidth than they provided in total. Residental lines in particular are typically very bad choices for relays, because they are much more prone to fluctuations in available bandwidth, the hardware caves when too many connections are open in parallel, and if the connection (which most often is asymmetric, with less upload capacity than down) were any near saturated using the internet would become a horribly slow and unpleasant experience. This last point is also the reason why any time you build any kind of network, you overprovision like crazy. The de-cix (largest internet exchange currently in existence) has a peak traffic that exceeds the average by a factor of roughly 1.75. The connected capacity is larger by a factor of 3.5. This is just so that you don't experience service degradation, and it's very common in computer networking. In the past, Tor was massively overloaded and very slow to use, which was a very real obstacle to getting it used, even in places that heavily censor or surveill internet usage. I have a relay on a symmetric 1gbit/s connection, yet the average traffic I push with that relay is just 16MB/s per direction. It is a non-exit relay, if it were used to exit I suspect it would maybe double or quadruple that utilization, but probably get noewhere near line capacity. If more people wanted to make use of it they could, but currently they don't - that's OK, there's no obligation for the Tor network to fill my relay with traffic that it shouldn't get. It is not just the small relays that don't get as much traffic as they could handle. > Among the pros there could be increased security and anonymity, as it would > take adversaries a bigger effort to infiltrate the network by establishing > rogue relays. Also could be invaluable as bridges to help people under > repressive regimes overcome censorship. Tor is gradually getting killed there. To me, the biggest pro is that the number of relay operators, of people who care enough to support the Tor network, is great politically. It's awesome that so many people want to help by providing some of the bandwidth they pay for. It's amazing that Exit operators make their connections endpoints of a public network. Robustness of the network is a comparatively much smaller factor. Needing to re-distribute information about changed IP adresses is a major hurdle towards bridge adoption. We've actually found that large bridges runnning one of the obfuscation protocols have massively higher chances of being useful than small and unreliable bridges, which is why Isis, the bridge db and bridge authority operator, has asked us not to recommend people run bridges on their small residental connections. I want to dispute the claim that unreliable relays (those either too slow or changing their IP too often to be used as Guards) contribute much anonymity-wise. The biggest protection you get is from your guard, and if you need to roll the dice more often (to pick a new guard more often), the chance that you pick one that is controlled by an adversary of yours increases. > My general impression is that the current DirAuth and bwauths policies are > stuck at some old paradigm where small bandwidth relays are dismissed without > good reason, and tons of bandwidth gains and especially diversity and > anonymity benefits are foregone The reasons I have presented above are good enough for me, personally. It seems I am not alone in this assessment. Perhaps I have been a
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
pussy 2016年12月22日 17:59，"Rana" 写道： > @Andreas > ... > >> I realize there could be pros and contras. Among the contras there > could be (for example) many small relays overloading the dirauths. I would > like to hear more about the contras. > >A Pi running at its line speed isn't exactly a small relay. > > Of course it isn't. A 20 mbps Pi relay has been reported here, still > under-utilized. > > ... > > Additional info about my experiment: I have just fired up an additional > relay on Pi Zero. That's a fucking $9 Tor relay, including flash card and > case. Looks like an oversized USB stick and plugs directly into a USB port > of a computer. No need even for power supply. > > >Why wouldn't you run the relay directly on the connection/powering > computer? > > As I said, it is an experiment to see if this is working at all and what's > the performance. Also, it was easy - I could use my PC to ssh into the Pi > via the USB port, and am running a relay through the same port, so no > tinkering with hardware. Eventually the Tor relay stick could be plugged > directly into a USB port of a home router, I believe that there are some > that have such ports. > > >Also, is the external USB network interface included in the pricing > calculation? > > What external USB network interface? Pi Zero has a micro USB connector. > All that is needed is a standard USB cable, not even OTG one, I fished an > old one from my junkbox. If you want you can add a whopping $1 to the cost > :) > > If you mean microUSB-to-Ethernet adaptor, that's $1.96 on eBay: > > http://www.ebay.com/itm/1pc-Micro-USB-2-0-to-Ethernet-10- > 100-RJ45-Network-LAN-Adapter-Card-uk-/262593720059?hash= > item3d23ce2efb:g:jHwAAOSwU-pXvqrT > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
@Andreas ... >> I realize there could be pros and contras. Among the contras there could be >> (for example) many small relays overloading the dirauths. I would like to >> hear more about the contras. >A Pi running at its line speed isn't exactly a small relay. Of course it isn't. A 20 mbps Pi relay has been reported here, still under-utilized. ... > Additional info about my experiment: I have just fired up an additional relay > on Pi Zero. That's a fucking $9 Tor relay, including flash card and case. > Looks like an oversized USB stick and plugs directly into a USB port of a > computer. No need even for power supply. >Why wouldn't you run the relay directly on the connection/powering computer? As I said, it is an experiment to see if this is working at all and what's the performance. Also, it was easy - I could use my PC to ssh into the Pi via the USB port, and am running a relay through the same port, so no tinkering with hardware. Eventually the Tor relay stick could be plugged directly into a USB port of a home router, I believe that there are some that have such ports. >Also, is the external USB network interface included in the pricing >calculation? What external USB network interface? Pi Zero has a micro USB connector. All that is needed is a standard USB cable, not even OTG one, I fished an old one from my junkbox. If you want you can add a whopping $1 to the cost :) If you mean microUSB-to-Ethernet adaptor, that's $1.96 on eBay: http://www.ebay.com/itm/1pc-Micro-USB-2-0-to-Ethernet-10-100-RJ45-Network-LAN-Adapter-Card-uk-/262593720059?hash=item3d23ce2efb:g:jHwAAOSwU-pXvqrT ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
On Thu, 22 Dec 2016 11:25:11 +, Rana wrote: ... > I realize there could be pros and contras. Among the contras there could be > (for example) many small relays overloading the dirauths. I would like to > hear more about the contras. A Pi running at its line speed isn't exactly a small relay. ... > Additional info about my experiment: I have just fired up an additional relay > on Pi Zero. That's a fucking $9 Tor relay, including flash card and case. > Looks like an oversized USB stick and plugs directly into a USB port of a > computer. No need even for power supply. Why wouldn't you run the relay directly on the connection/powering computer? Also, is the external USB network interface included in the pricing calculation? - Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
So my question to the community is as follows: does the Tor community want these small, cheap relays scattered in large quantity around the world, or not? I realize there could be pros and contras. Among the contras there could be (for example) many small relays overloading the dirauths. I would like to hear more about the contras. Among the pros there could be increased security and anonymity, as it would take adversaries a bigger effort to infiltrate the network by establishing rogue relays. Also could be invaluable as bridges to help people under repressive regimes overcome censorship. Tor is gradually getting killed there. My general impression is that the current DirAuth and bwauths policies are stuck at some old paradigm where small bandwidth relays are dismissed without good reason, and tons of bandwidth gains and especially diversity and anonymity benefits are foregone Additional info about my experiment: I have just fired up an additional relay on Pi Zero. That's a fucking $9 Tor relay, including flash card and case. Looks like an oversized USB stick and plugs directly into a USB port of a computer. No need even for power supply. CPU utilization - negligible, total memory utilization (including Tor) 20%. No need to waste $35 on a Pi 3 which is grossly underutilized by the DirAuths. -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of Rana Sent: Thursday, December 22, 2016 10:58 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP @Patrice: Yes both relays started with brand new identities and the one that is now clinically dead (nickname ZG0) has been wiped out and restarted with a new fingerprint AND a new IP address as I have a dynamic one and I rebooted my router to get a new one). Did not help, so obviously this has everything to do with the network and how dirauths/bwauths test the connection and vote, and absolutely nothing to do with the identity of the relay See my previous messages to confirm that this has absolutely nothing to do with the capabilities of the Pi, which are a gross overkill for the use of (nickname) GG2 that the dirauths and bwauths allow. -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of Patrice Sent: Thursday, December 22, 2016 2:57 AM To: tor-relays@lists.torproject.org Subject: [tor-relays] @Rana - with reference to: Unwarranted discrimination of relays with dynamic Hi, I`ve read your post and questions, also about your 2 Raspberry PIs with the same setting but different locations. I thought about it and my question is: Did these to PIs got a new fresh identity on day zero? If not, it`s worth a try, probably. Kill the old identities and let them by. My fundamental idea is (and that`s why I am writing this): Does my behaviour with the relay (restarting, upgrading, not be onlinening) effect the measurement and therefore the throughput of my relay? Cheers, Patrice ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP
@Patrice: Yes both relays started with brand new identities and the one that is now clinically dead (nickname ZG0) has been wiped out and restarted with a new fingerprint AND a new IP address as I have a dynamic one and I rebooted my router to get a new one). Did not help, so obviously this has everything to do with the network and how dirauths/bwauths test the connection and vote, and absolutely nothing to do with the identity of the relay See my previous messages to confirm that this has absolutely nothing to do with the capabilities of the Pi, which are a gross overkill for the use of (nickname) GG2 that the dirauths and bwauths allow. -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of Patrice Sent: Thursday, December 22, 2016 2:57 AM To: tor-relays@lists.torproject.org Subject: [tor-relays] @Rana - with reference to: Unwarranted discrimination of relays with dynamic Hi, I`ve read your post and questions, also about your 2 Raspberry PIs with the same setting but different locations. I thought about it and my question is: Did these to PIs got a new fresh identity on day zero? If not, it`s worth a try, probably. Kill the old identities and let them by. My fundamental idea is (and that`s why I am writing this): Does my behaviour with the relay (restarting, upgrading, not be onlinening) effect the measurement and therefore the throughput of my relay? Cheers, Patrice ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
