[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
options. In case of conflicts (excluding and requiring the same node)
  "StrictNodes" option is used to determine behaviour. If a nodes is
excluded and required via a configuration option, the exclusion takes

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
(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.


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
    immediately, to prevent a situation where a previously built
    is used even though some of its nodes are now excluded.

Right, we do that as of


  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?