Create a dirauth DoS response procedure
We have the technical ability right now to rapidly rotate up to n-1 of the directory authorities to new IP addresses and new intermediate keys, simply by updating torrc files of dirauths. So long as at least one directory authority remains listening on its old IP address and is aware of the other directory authorities' new locations, it should still be possible to both produce a consensus and distribute it to new clients.
We should clearly document this procedure so we can execute it quickly if a majority of the Tor directory authorities fall victim to a DoS or compromise.
We should also consider altering client bundles to ship with a reduced consensus or descriptor set of ultra high-uptime directory mirrors, so that in the future we can rotate all n directory authorities without issue.
Activity
changed milestone to %Tor: unspecified
Trac:
Description: We have the technical ability right now to rotate up to n-1 of the directory authorities to new IP addresses, with new intermediate keys by updating torrc files of the other dirauths. So long as at least one directory authority remains listening on its old IP address and is aware of the other directory authorities' new locations, it should still be possible to both produce a consensus and distribute it to new clients.We should clearly document this procedure so we can execute it quickly if the Tor directory authorities fall victim to a DoS or widespread compromise.
We should also consider altering client bundles to ship with a reduced consensus or descriptor set of ultra high-uptime directory mirrors, so that in the future we can rotate all n directory authorities without issue.
to
We have the technical ability right now to rapidly rotate up to n-1 of the directory authorities to new IP addresses and new intermediate keys, simply by updating torrc files of dirauths. So long as at least one directory authority remains listening on its old IP address and is aware of the other directory authorities' new locations, it should still be possible to both produce a consensus and distribute it to new clients.
We should clearly document this procedure so we can execute it quickly if a majority of the Tor directory authorities fall victim to a DoS or compromise.
We should also consider altering client bundles to ship with a reduced consensus or descriptor set of ultra high-uptime directory mirrors, so that in the future we can rotate all n directory authorities without issue.
-
It appears Iran has just blocked the directory authorites, which may require us to distribute a list of super-stable dir mirrors to clients anyway. So I'm thinking we might even go for gold on this one.
If we design this right, we can protect the dirauths from DoS by allowing them to write iptables rules to block contact with anyone but eachother and the list of approved dir mirrors.
-
Instead of relocation, a lighter-weight alternative that should be easier to deploy in an emergency is to create a clique firewall topology, so the dirauths can only talk to each other and a set of high-bandwidth, high-uptime dir mirrors.
This might be easier to deploy as an emergency response. However, without at least one of the dirauths being publicly reachable, we'd still have no way to bootstrap new clients without shipping them with some kind of cached consensus.
-
#572 (moved) sounds like it would make the clique firewall idea work to keep the existing network running if fixed. I also created #6790 (moved) for the relay descriptor submission side.
-
I think the limit rule is a decent (but not perfect) option that we can use until it's possible to create a more resilient network topology. Right now though, module loading is disabled on turtles and the limit module is not currently loaded, so I need to reboot for that. I'll see about doing it on Monday.
mentioned in issue #2701 (moved)
mentioned in issue #6790 (moved)
moved to tpo/core/tor#2665 (closed)
mentioned in issue tpo/core/tor#6790 (closed)
