Hi folks,
In addition to the "get many fast exit relays" plan, that same funder (Voice of America) wants us to run a pile of fast stable unpublished bridges. We'll give the bridge addresses out manually to their target users over the coming months.
The constraints are: * 100mbit+ connectivity, though in practice I expect they will spend most of their time doing far less than that. * No more than 2 bridges per /24. If you're running fast (100mbit+) exits (which is more important), exits on that /24 count toward this 2. * No more than 7 bridges total per data center.
If you could set up 1 (or 2, or 20) and send me the address(es) privately, that would be grand.
We do have some funding for this, but I'm hoping that we can get enough volunteers so we can put the money toward more fast exits and better QA and build automation for the Tor bundles. So if you have good connectivity but can't run an exit, this is a great way to contribute.
The torrc lines we want include:
ORPort 443 # or whichever port you like BridgeRelay 1 PublishServerDescriptor 0 RelayBandwidthRate 11875 KB # or more RelayBandwidthBurst 12500 KB # or more
If you have 3+ IP addresses and want to get fancy, you might set OutboundBindAddress to a different IP address than you tell me, to avoid some of the bridge enumeration attacks listed at https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bri...
Later I might ask you to set up some sort of server-side pluggable transport like obfsproxy, but there's no rush on that.
Long-term, "get a bunch of fast bridges on individual static IP addresses" is not a very good plan. Instead, we plan to focus on borrowing whole netblocks from ISPs and other people who aren't using them, and redirecting the addresses en masse into a bridge. You can start playing around with this idea by using an iptables rule rather than a bridge: /sbin/iptables -t nat -A PREROUTING -p tcp -d 18.244.0.114 --dport 80 -j DNAT --to-destination 128.31.0.34:9032 if the bridge listens on 128.31.0.34:9032 and you want me to advertise the address 18.244.0.114:80.
Let me know if you have any questions or I can help clarify anything.
Thanks! --Roger
Roger Dingledine:
Hi folks,
In addition to the "get many fast exit relays" plan, that same funder (Voice of America) wants us to run a pile of fast stable unpublished bridges. We'll give the bridge addresses out manually to their target users over the coming months. (...)
We do have some funding for this, but I'm hoping that we can get enough volunteers so we can put the money toward more fast exits and better QA and build automation for the Tor bundles. So if you have good connectivity but can't run an exit, this is a great way to contribute. (...)
I might be overreacting (especially since nobody else replies), but doesn't that split up Tor users in (two) groups?
Instead of having a larger pool (of bridges) for anyone you ask for unpublished bridges which will be handed to "privileged" people.
Volunteers running unpublished bridges and giving them to friends in $restrictive_country is one thing and their private choice. The same is valid for a funder that pays for unpublished bridges. It appears fine to me that a funder can make such choices.
You ask volunteers to achieve a funders goal. Those might run a bridge already, but "un-publish" it. Less bridges for the rest. They could run relays and turn them into unpublished bridges. Less relays for anyone.
Running a relay or bridge (published) would be a better contribution IMO.
Some were "upset" about funding for exits, because the Tor Project could become dependent to the funding. 125+ exits is a huge number, but I didn't "distrust" your judgment. However now I'm upset that the unpublished bridges hurt the network. It's hurting the network to achieve a funders goal. To me that's the wrong way.
Please read "you" as "the Tor Project" and "your" as "the Tor Projects'", because I did not intend to address this to you, as Roger.
Regards, Sebastian
On Sun, Aug 12, 2012 at 09:58:54AM +0200, Sebastian G. <bastik.tor> wrote:
You ask volunteers to achieve a funders goal. Those might run a bridge already, but "un-publish" it. Less bridges for the rest. They could run relays and turn them into unpublished bridges. Less relays for anyone.
Running a relay or bridge (published) would be a better contribution IMO.
Hi Sebastian,
Thanks for starting the discussion.
I totally agree that running a big relay (exit or non-exit) is more directly useful to the Tor network than running one of these unpublished bridges.
We're in an interesting situation here, where we can use their bridge funding for other more important things if we don't spent it all on bridges. So maybe the subject should have been the more counterintuitive "Help fund Tor bundle usability by running a fast unpublished bridge".
Another option would be to give it to Moritz et al at torservers.net so they can run more fast exits -- at which point Moritz might end up sending a similar mail saying "Help us run more exit relays by running a fast unpublished bridge".
Now that I think about it, maybe the best way to phrase it would be as a matching donation: "Run a fast unpublished bridge with 2 IP addresses, and we have a funder who will match your donation by giving $200-300/mo to Tor." That's the reasoning that led me to say it's a great way to contribute to Tor if you can't run a fast relay yourself.
Another model I've been pondering is to offer people some funding to run a fast *non*-exit relay along with a pair of extra IP addresses for these unpublished bridges. But on the theory that exits are more scarce than non-exits (and I don't want to muddy the current exit experiment with even more money), I figured it would be better to separate the roles.
This discussion really goes back to a simple question: is it better to use our funding for more design and development, or for strengthening the network? For exit relays, I think choosing "strengthen the network" is a great and worthwhile experiment. But for bridges, since the current Tor transport and current bridge distribution strategies are not great, I think it's better to use funding for better designs and better code. I should note that I actually encouraged VoA to want unpublished bridges: if we set up fast bridges and published them via bridges.torproject.org today, they'd get blocked quickly in China.
I'm especially hoping to hear from volunteers for whom setting up a few extra bridges is basically free -- for example, those already running fast non-exit relays who have a few more IP addresses nearby. This is also a nice way for students at universities to get involved if they're not ready to run a fast public relay quite yet.
I hope that helps to explain. Sorry for exposing the internals of running a non-profit. But I think transparency is especially important here. :)
--Roger
On Mon, Aug 13, 2012 at 5:55 AM, Roger Dingledine arma@mit.edu wrote:
I'm especially hoping to hear from volunteers for whom setting up a few extra bridges is basically free -- for example, those already running fast non-exit relays who have a few more IP addresses nearby. This is also a nice way for students at universities to get involved if they're not ready to run a fast public relay quite yet.
--Roger
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I guess I fit into that category - the exit I run (mentioned previously in the exit funding thread) is on a server which has about 3 free IP addresses which I'm not using right now - I could easily use them as fast unpublished bridges if somebody explained briefly how.
On 13.08.2012 12:56, Andrew Beveridge wrote:
I guess I fit into that category - the exit I run (mentioned previously in the exit funding thread) is on a server which has about 3 free IP addresses which I'm not using right now - I could easily use them as fast unpublished bridges if somebody explained briefly how.
Thank you!
First, as you want to run both exit and bridge on one server, it will be useful to switch to a modified init script that makes it easier to handle multiple Tors:
cd /etc/init.d wget -O tor https://www.torservers.net/misc/config/initd-tor chmod +x tor
Example usage:
# ls /etc/tor tor0.cfg tor1.cfg tor2.cfg tor3.cfg # /etc/init.d/tor start # starts tor 0-3 # /etc/init.d/tor stop # stops tor 0-3 # /etc/init.d tor reload tor2 tor3 # /etc/init.d/tor stop tor1
Next, in /etc/tor, rename your current torrc to tor0.cfg and create a new file called tor1.cfg:
----- snip -----
## separate directories per tor process DataDirectory /var/lib/tor/bridge PidFile /var/run/tor/tor-bridge.pid Log notice file /var/log/tor/notices-bridge.log
Address 109.163.233.200 # your second external IP OutboundBindAddress 109.163.233.200 ORListenAddress 109.163.233.200:443
## default bridge port 443 ORPort 443
## private bridge PublishServerDescriptor 0
SocksPort 0 BridgeRelay 1 Exitpolicy reject *:*
----- snip -----
Roger Dingledine:
Hi Roger,
We're in an interesting situation here, where we can use their bridge funding for other more important things if we don't spent it all on bridges. So maybe the subject should have been the more counterintuitive "Help fund Tor bundle usability by running a fast unpublished bridge".
Another option would be to give it to Moritz et al at torservers.net so they can run more fast exits -- at which point Moritz might end up sending a similar mail saying "Help us run more exit relays by running a fast unpublished bridge".
Now that I think about it, maybe the best way to phrase it would be as a matching donation: "Run a fast unpublished bridge with 2 IP addresses, and we have a funder who will match your donation by giving $200-300/mo to Tor." That's the reasoning that led me to say it's a great way to contribute to Tor if you can't run a fast relay yourself.
Sounds all plausible to me.
Another model I've been pondering is to offer people some funding to run a fast *non*-exit relay along with a pair of extra IP addresses for these unpublished bridges. But on the theory that exits are more scarce than non-exits (and I don't want to muddy the current exit experiment with even more money), I figured it would be better to separate the roles.
Understandable.
This discussion really goes back to a simple question: is it better to use our funding for more design and development, or for strengthening the network? For exit relays, I think choosing "strengthen the network" is a great and worthwhile experiment.
I agree on the exits. Better design and more development could be beneficial to Tor.
But for bridges, since the current Tor transport and current bridge distribution strategies are not great,
In the long run you are right. New fast bridges *might* improve the situation for censored users, but that won't last very long.
I think it's better to use funding for better designs and better code.
Yes, that's much better over time.
I should note that I actually encouraged VoA to want unpublished bridges: if we set up fast bridges and published them via bridges.torproject.org today, they'd get blocked quickly in China.
They have fixed IP addresses which would result in permanently blocked bridges. I wonder how good the manual bridge distribution is.
When VoA is fine with spending their money for other stuff as long as their goal is achieved it's reasonable.
I'm especially hoping to hear from volunteers for whom setting up a few extra bridges is basically free -- for example, those already running fast non-exit relays who have a few more IP addresses nearby. This is also a nice way for students at universities to get involved if they're not ready to run a fast public relay quite yet.
That would be beneficial to Tor.
I hope that helps to explain.
For me it was helpful. I understood the goal in the first place, but was a little concerned. After all I guess spending money for design and code is more helpful than bridges for anyone.
Sorry for exposing the internals of running a non-profit. But I think transparency is especially important here. :)
I don't know why you feel sorry. Transparency is important for non-profit, at least for most I guess.
Sebastian
Sorry for exposing the internals of running a non-profit. But I think transparency is especially important here. :)
I don't know why you feel sorry. Transparency is important for non-profit, at least for most I guess.
Non-profit is just a tax and legal designation. After any necessary compliance with that, the degree of transparency, salaries paid, competitiveness, degree of being closely held, and indeed all other things... is completely variable.
On Monday, August 13. 2012, 00:55:45 Roger Dingledine wrote:
This discussion really goes back to a simple question: is it better to use our funding for more design and development, or for strengthening the network? For exit relays, I think choosing "strengthen the network" is a great and worthwhile experiment. But for bridges, since the current Tor transport and current bridge distribution strategies are not great, I think it's better to use funding for better designs and better code. I should note that I actually encouraged VoA to want unpublished bridges: if we set up fast bridges and published them via bridges.torproject.org today, they'd get blocked quickly in China.
My understanding of bridge detection was, that Chinas GFW is able to detect the Tor SSL handshake and does active bridge probing after a successful connection to a (for the GFW) unknown bridge IP. So they should be able to block any bridge publish or unpublished very quickly, if someone from behind the GFW connects to a bridge. Am I missing something?
Regards,
torland
On Tue, Aug 14, 2012 at 05:13:56PM +0200, tor-admin wrote:
My understanding of bridge detection was, that Chinas GFW is able to detect the Tor SSL handshake and does active bridge probing after a successful connection to a (for the GFW) unknown bridge IP. So they should be able to block any bridge publish or unpublished very quickly, if someone from behind the GFW connects to a bridge. Am I missing something?
We haven't made a big fuss about it, but Tor 0.2.3.17-beta uses a new ciphersuite in the ssl client hello, and I believe China's current DPI doesn't notice it.
https://lists.torproject.org/pipermail/tor-talk/2012-June/024511.html
The extra-fun part is that if a Tor 0.2.2 client connects to the bridge, it triggers the probing you describe (and thus the blocking). But if only Tor 0.2.3.17+ clients connect, no probing (and thus no blocking).
Obfsproxy's obfs2 protocol is way better at not getting blocked currently; but I'm holding out for an obfs3 release, with a new protocol that's harder to DPI for, before we push for a big rollout there.
--Roger
Hi everybody,
I'm not a tor expert but I am in China and have been using tor... I brought this up before and I still feel that tor would benefit from having special (entry)relays inside the GFW that have a reliable link to relays outside the GFW. Clients inside GFW could then always connect to these relays. Actually, probably tens of thousands of people have VPN connections and they could host such relays to provide access to clients, even such that might be completely blocked from accessing addresses outside the GFW, which, sadly, that is not so uncommon either.
Of course it would be great to reveal as little information as possible about such special relays in public... and continue to make the tor connections as un-conspicuous as possible
20 mbit fiber connections are rapidly becoming commonplace in China. VPNs are commonplace already and I think in the case of GFW the tor project could make use of this situation.
I'd love to see some sort of an easy deployable tor relay package that could listen on both the chinese and vpn address and relay traffic between the two...
or even develop a free tor-super-relay package with a dedicated built-in tor-exclusive vpn... ok maybe that's too much.. just a thought from a user
keep up the good work.
Loz
On Wed, Aug 15, 2012 at 4:32 AM, Roger Dingledine arma@mit.edu wrote:
On Tue, Aug 14, 2012 at 05:13:56PM +0200, tor-admin wrote:
My understanding of bridge detection was, that Chinas GFW is able to
detect
the Tor SSL handshake and does active bridge probing after a successful connection to a (for the GFW) unknown bridge IP. So they should be able
to
block any bridge publish or unpublished very quickly, if someone from
behind
the GFW connects to a bridge. Am I missing something?
We haven't made a big fuss about it, but Tor 0.2.3.17-beta uses a new ciphersuite in the ssl client hello, and I believe China's current DPI doesn't notice it.
https://lists.torproject.org/pipermail/tor-talk/2012-June/024511.html
The extra-fun part is that if a Tor 0.2.2 client connects to the bridge, it triggers the probing you describe (and thus the blocking). But if only Tor 0.2.3.17+ clients connect, no probing (and thus no blocking).
Obfsproxy's obfs2 protocol is way better at not getting blocked currently; but I'm holding out for an obfs3 release, with a new protocol that's harder to DPI for, before we push for a big rollout there.
--Roger
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Wed, Aug 15, 2012 at 11:55:55AM +0800, Lorenz Kirchner wrote:
I'm not a tor expert but I am in China and have been using tor... I brought this up before and I still feel that tor would benefit from having special (entry)relays inside the GFW that have a reliable link to relays outside the GFW. Clients inside GFW could then always connect to these relays. Actually, probably tens of thousands of people have VPN connections and they could host such relays to provide access to clients, even such that might be completely blocked from accessing addresses outside the GFW, which, sadly, that is not so uncommon either.
I guess, that would require a modification of the path selection on the clients side. Usually, Tor clients randomly pick relays weighted by bandwidth. Unless the Chinese relays would provide an enormous amount of bandwidth, they would barely get selected by clients which leads to a poor user experience.
Perhaps it's better to focus on improved bridge distribution strategies [0] and hard-to-block transport protocols [1]. Also, that would be a universal solution which would also help in other countries and not a specific - and probably hard to maintain - Chinese-only solution.
Of course it would be great to reveal as little information as possible about such special relays in public... and continue to make the tor connections as un-conspicuous as possible
I guess, the firewall operators would notice that quite soon when Chinese relays would start popping up in the consensus or am I missing something here? And as soon as something is in the consensus, it's particularly easy to block.
20 mbit fiber connections are rapidly becoming commonplace in China. VPNs are commonplace already and I think in the case of GFW the tor project could make use of this situation.
Aren't these 20 mbit only achievable with domestic traffic? I thought that international traffic gets throttled a lot in China?
I'd love to see some sort of an easy deployable tor relay package that could listen on both the chinese and vpn address and relay traffic between the two...
For what it's worth, I and a few others are running bridges with the brdgrd tool [1]. The tool rewrites the first announced window size of a bridge and hence "forces" the client to split its cipher list in two halves. That way, the firewall has not been able to recognize Tor so far. The handy thing is, it only requires modification of bridges and not clients.
Philipp
[0] https://blog.torproject.org/blog/bridge-distribution-strategies [1] https://www.torproject.org/docs/pluggable-transports.html.en [2] https://github.com/NullHypothesis/brdgrd
I guess, that would require a modification of the path selection on the
clients side. Usually, Tor clients randomly pick relays weighted by bandwidth. Unless the Chinese relays would provide an enormous amount of bandwidth, they would barely get selected by clients which leads to a poor user experience.
well compared to now the experience would be better, eventually the reachable Chinese relays would connect it just might take a while on first startup
Perhaps it's better to focus on improved bridge distribution strategies [0] and hard-to-block transport protocols [1]. Also, that would be a universal solution which would also help in other countries and not a specific - and probably hard to maintain - Chinese-only solution.
I think the solution is not a Chinese only solution as it would work anywhere where censorship actually exists
I guess, the firewall operators would notice that quite soon when Chinese relays would start popping up in the consensus or am I missing something here? And as soon as something is in the consensus, it's particularly easy to block.
I am not sure how it works but I have a feeling that the firewall operators have difficulties in blocking hosts inside their networks
Aren't these 20 mbit only achievable with domestic traffic? I thought that international traffic gets throttled a lot in China?
my experience is that I can actually get *up to* 20 mbit of international traffic, but realistically it is more like 10 mbit of reliable traffic, still ok I feel... the gfw mostly causes latency, inside gfw i can get ping times of around 4ms whereas ping through the VPN is about 250ms to the westcoast of the US.. that ping time has an effect on throughput I guess and also the bandwidth will can vary in what I guess are peak times..
Well if tor could provide a working system of bridges or whatever it would be great, but at the moment the censors are ahead..
Loz
Hi Loz,
On Wed, Aug 15, 2012 at 11:00:11PM +0800, Lorenz Kirchner wrote:
I guess, that would require a modification of the path selection on the clients side. Usually, Tor clients randomly pick relays weighted by bandwidth. Unless the Chinese relays would provide an enormous amount of bandwidth, they would barely get selected by clients which leads to a poor user experience.
well compared to now the experience would be better, eventually the reachable Chinese relays would connect it just might take a while on first startup
Yes, assuming the users would not give up out of frustration before :-) We can actually do the math: According to [0], at the moment the Tor network has an advertised bandwidth of 3000 MiB/s. Let's assume that all Chinese relays would account for 30 MiB/s. Even then, the probability of a Chinese relay being selected as first hop is only 30/3000 = 0.01 = 1%!
Perhaps it's better to focus on improved bridge distribution strategies [0] and hard-to-block transport protocols [1]. Also, that would be a universal solution which would also help in other countries and not a specific - and probably hard to maintain - Chinese-only solution.
I think the solution is not a Chinese only solution as it would work anywhere where censorship actually exists
Only if you assume that the censor is always having a hard time censoring content within its own borders. That might hold more-or-less true for China but not everywhere else, right? For example, what about the networks of a company or a small organization?
I guess, the firewall operators would notice that quite soon when Chinese relays would start popping up in the consensus or am I missing something here? And as soon as something is in the consensus, it's particularly easy to block.
I am not sure how it works but I have a feeling that the firewall operators have difficulties in blocking hosts inside their networks
That might be due to the fact that a lot of filtering (but not all of it) is going on in border ASes. There even is a research paper about that if you are interested [1].
However, there still remains a legal problem! You will have a hard time hiding the fact that you are operating a relay within China. And if this turns out to be a viable strategy, even more so. I suppose it wouldn't be too hard for the government to simply confiscate or shut down Chinese relays?
After all, I agree with you that it's an interesting strategy which would tackle the problem from a new angle and I would love to learn more about it. I just believe that right now we should spend the limited resources we have on bridge distribution and pluggable transports. It would surely be worth an experiment, though!
Philipp
[0] https://metrics.torproject.org/network.html#bandwidth [1] www.eecs.umich.edu/~zmao/Papers/china-censorship-pam11.pdf
On Thu, Aug 16, 2012 at 3:23 AM, Philipp Winter <identity.function@gmail.com
wrote:
Yes, assuming the users would not give up out of frustration before :-) We can actually do the math: According to [0], at the moment the Tor network has an advertised bandwidth of 3000 MiB/s. Let's assume that all Chinese relays would account for 30 MiB/s. Even then, the probability of a Chinese relay being selected as first hop is only 30/3000 = 0.01 = 1%!
How long does it take to make 100 circuit attempts?
However, there still remains a legal problem! You will have a hard time hiding the fact that you are operating a relay within China. And if this turns out to be a viable strategy, even more so. I suppose it wouldn't be too hard for the government to simply confiscate or shut down Chinese relays?
Yes, that is not impossible, but it depends how many relays there are and how easy it is to set them up.. The legal thing is interesting as I have yet to see any rules or laws that prohibit Chinese to circumvent censorship... afaik officially there is no censorship in China so it is difficult to accuse someone of circumventing it, however they most likely will find something else to accuse them of.
If there was a tor sub project producing say a widely available dd wrt image that is ready to go, I bet there would be thousands of keen Chinese getting their routers flashed just like many do it with their phones... every market here has some people who will jailbreak this and that. It seems to me that it would be a difficult task for the authorities to keep confiscating...
In my opinion it is not far fetched to expect to eventually see several tens of thousands of Chinese relays on VPN connections that could arguably even be exit relays. Wouldn't that help the tor bandwidth cause overall? Basically, ideally tor is providing the anonymity to safely share the existing circumvention systems (VPN) across all the internal networks... sort of thing
[1] www.eecs.umich.edu/~zmao/Papers/china-censorship-pam11.pdf
interesting paper, thanks
On Thu, Aug 16, 2012 at 09:51:03AM +0800, Lorenz Kirchner wrote:
Yes, assuming the users would not give up out of frustration before :-) We can actually do the math: According to [0], at the moment the Tor network has an advertised bandwidth of 3000 MiB/s. Let's assume that all Chinese relays would account for 30 MiB/s. Even then, the probability of a Chinese relay being selected as first hop is only 30/3000 = 0.01 = 1%!
How long does it take to make 100 circuit attempts?
That would depend on when your OS thinks, a TCP connection timed out. It could be quite a while if you count several seconds for each connection attempt.
Philipp
Hi Philipp
Perhaps it's better to focus on improved bridge distribution strategies [0] and hard-to-block transport protocols [1]. Also, that would be a universal solution which would also help in other countries and not a specific - and probably hard to maintain - Chinese-only solution.
But how would tor help people that do not have direct access to outside the gfw? actually many 'consumer' ISP in China now seem to have separate NATed networks that can't even connect to each other and they seem to route international requests if they allow them at all to special third-party providers who will handle the filtering (I guess)
I still feel that a kind of 'peering relay' is needed for speed and to allow access for those users at all...
On Wed, Aug 15, 2012 at 11:42:08PM +0800, Lorenz Kirchner wrote:
Perhaps it's better to focus on improved bridge distribution strategies [0] and hard-to-block transport protocols [1]. Also, that would be a universal solution which would also help in other countries and not a specific - and probably hard to maintain - Chinese-only solution.
But how would tor help people that do not have direct access to outside the gfw? actually many 'consumer' ISP in China now seem to have separate NATed networks that can't even connect to each other and they seem to route international requests if they allow them at all to special third-party providers who will handle the filtering (I guess)
I still feel that a kind of 'peering relay' is needed for speed and to allow access for those users at all...
At the same time, these "peering relays" would become some sort of choke point.
After all, outside its jurisdiction, the censor (mostly) only has technical control over the flow of information. Within its jurisdiction, however, we also have to deal with social and legal control. And I'm afraid that this is harder to defend against, than technical censorship.
Philipp
ON Saturday, August 11. 2012, 18:25:03 Roger Dingledine wrote:
The constraints are:
- 100mbit+ connectivity, though in practice I expect they will spend
most of their time doing far less than that.
- No more than 2 bridges per /24. If you're running fast (100mbit+)
exits (which is more important), exits on that /24 count toward this 2.
- No more than 7 bridges total per data center.
If you could set up 1 (or 2, or 20) and send me the address(es) privately, that would be grand.
If I ask my ISP for additional IPs, how do I check these constraints, given that I don't know other bridges/exits running at my ISP/DC.
Regards,
Torland
On Tue, Aug 14, 2012 at 08:25:40AM +0200, tor-admin wrote:
ON Saturday, August 11. 2012, 18:25:03 Roger Dingledine wrote:
The constraints are:
- 100mbit+ connectivity, though in practice I expect they will spend
most of their time doing far less than that.
- No more than 2 bridges per /24. If you're running fast (100mbit+)
exits (which is more important), exits on that /24 count toward this 2.
- No more than 7 bridges total per data center.
If you could set up 1 (or 2, or 20) and send me the address(es) privately, that would be grand.
If I ask my ISP for additional IPs, how do I check these constraints, given that I don't know other bridges/exits running at my ISP/DC.
Given that you're an early volunteer, I think you can approximate the constraints as if you are the only person running exits / bridges on those netblocks. That is, don't conflict with your own exits, and everything should be fine.
In the future, I guess the better answer will be "send me mail with your planned netblocks, and I'll let you know if your plans are going to produce any conflicts."
Thanks! --Roger
On Sat, Aug 11, 2012 at 06:25:03PM -0400, Roger Dingledine wrote:
The constraints are:
- 100mbit+ connectivity, though in practice I expect they will spend
most of their time doing far less than that.
- No more than 2 bridges per /24. If you're running fast (100mbit+)
exits (which is more important), exits on that /24 count toward this 2.
- No more than 7 bridges total per data center.
Hi,
We are DFRI [0] and we intend to set up fast and stable bridges.
Some questions: * How long lived do the IP addresses need to be in order to be considered stable? * About the 100mbit connectivity, do we need to be able to sustain 100mbit or is the ability to burst that good enough? * Is it ok to run 2 bridges on the same address?
Kind regards Johan Nilsson DFRI
tor-relays@lists.torproject.org