Proposal idea: User path configuration

[Sebastian Hahn]

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