[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Proposal idea: User path configuration


On Mar 10, 2010, at 5:32 AM, Roger Dingledine wrote:


On Thu, Mar 04, 2010 at 04:24:30AM +0100, Sebastian Hahn wrote:

  Users can alter the default behavior for path selection with
configuration
options. In case of conflicts (excluding and requiring the same node) 
the
  "StrictNodes" option is used to determine behaviour. If a nodes is
both
excluded and required via a configuration option, the exclusion takes 
  preference.


I think we should work out the situations where strictnodes is needed,
and the situations where we want to honor the config option even without 
strictnodes 1.
For example, if you set entrynodes or exitnodes, then imo you should get one of the nodes you specified, or fail if none work. You asked for it, 
you get it. Similarly, if you set Excludenodes or excludeexitnodes, I
think that should trump any entrynodes or exitnodes you set. And if you exclude everything that's possible, then you fail to make a circuit. It's 
what you asked for. That's pretty much what I built in 0.2.2.7-alpha
(though I haven't finished the "excluding" part).
I think there's a misunderstanding here. I think we should make it clear that excluding trumps including, but it would be sad if we end up in a state where people cannot say "ExcludeExitNodes xy, y, z" and still have their hidden services work. This seems to be what you're trying to say below, and I had tried to capture it in my spec addition. "require" above is meant to mean "Tor requires this node because it is an intro point and all other intro points are down", for example, not that someone used ExcludeNodes and EntryNodes 
with overlapping nodes, for example.
So to make it clear, I want StrictNodes to only be considered at all when 
we have a special case for a non-exit circuit.


* What if Tor as a client wants to reach an introduction point for
a hidden service that the user asked to visit, but that intro point
is in excludenodes? The complex answer is to avoid the excluded intro
points unless that would exclude all of them, in which case, either fail 
if StrictNodes is 1 else choose one like normal. The simpler answer
coding-wise is to ignore ExcludeNodes when choosing which intro point
to contact, and then either fail or allow it depending on the value
of StrictNodes. I'm inclined toward the simpler answer here, because I
don't think you should care whether your Tor reaches some relay at the
end of your circuit, if that's all Tor uses the circuit for.
I don't think this is so controversial. We should do the complicated thing, 
at least according to how I wanted the spec change to be interpreted.
* If you ExcludeNodes a relay but your Tor wants to ask it for directory 
information, do we? I think the answer is no, a) because there's a
plausible client-enumeration attack a reasonable person could to be
trying to avoid by excluding it, and b) because the information should be available from a different relay. And if you exclude all the authorities 
and then fail to bootstrap, that's your own fault.


No, we don't ask that node, once again unless all nodes are excluded and
strictnodes is set.


* How do we handle foo.exit when AllowDotExit is 1 but foo is in
ExcludeNodes or ExcludeExitNodes? The user both asked for it and asked
for not it. We could allow it if StrictNodes is 0, and refuse it if
StrictNodes is 1. I'm inclined to just refuse it in both cases, to make 
the code (and spec) simpler.


Just refuse it always.


* If we would _implicitly_ append the .exit because of exit enclaving,
but the exit is excluded, then we definitely shouldn't append it.


Right.


What other scenarios have I missed?


  - If "ExitNodes" is provided, then every request requires an exit
node on


More precisely, "then every exit circuit requires"


  - When any of the *Nodes settings are changed, all circuits are
expired
    immediately, to prevent a situation where a previously built
circuit
    is used even though some of its nodes are now excluded.


Right, we do that as of 0.2.2.7-alpha.


Compatibility:

  The old Strict*Nodes options are deprecated, and the StrictNodes
option is
  new. Tor users may need to update their configuration file.
In the current (0.2.2.x) behavior, setting any Strict*Nodes is an alias 
for setting StrictNodes. That way we don't break torrc files as people
upgrade. (Periodically we run into folks like the Ubuntu people who want us to promise that if they give a newer version to their existing users, 
it won't break existing config files.)
I guess breaking the torrc format eventually isn't so bad, but doing this 
kind of fallback and warning about it seems ok for now?


--Roger


Thanks
Sebastian