Re: architectural proposal & technical problems

[Johannes Renner <hannesrenner@xxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roger Dingledine wrote:
> I just added a new config option __DisablePredictedCircuits that
> should do what you want ..
> It simply doesn't build the preemptive "extra" circuits, so you don't
> have random circuits appearing. Is this what you had in mind?

Yes, that's exactly what I had in mind, thank you for introducing
this option. Maybe other developers of controllers will also be
glad to be able to switch this off to take over the construction
of circuits for client-use.

BTW: Where can I find a list of all of the "special" config options
that start with __*? Just to find out if there are more of them that
could be useful for my purposes, but I don't know about yet?

> I just implemented this:
> http://archives.seul.org/or/cvs/Apr-2007/msg00137.html
> 
> It's not quite what Johannes wanted, because we currently still refuse to
> attach to a 1-hop circuit, and now we also refuse to attach to the 1st
> hop of a circuit. This is to discourage people from using Tor as a one
> hop proxy, for the safety of our server operators (see paragraph 3 of
> http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#VariablePathLength).
> 
> Of course, it's not hard to change the code to take that check out
> on the client side; and if you're doing the tests from a server
> listed in the directory, the other Tor servers will likely let you
> use a one-hop circuit. Is that good enough, or should we revisit the
> client-disallows-single-hop-circuits-too idea?

That is also exactly what I want, thank you very much for that
modification, too. I hope all of you will also consider these two
additions useful. Unfortunately I will also need to do tests to the
first hop of a circuit, because I will be using the RTT_0-1 to compute
RTT_1-2 = RTT_0-2 - RTT_0-1. I really don't want to lessen the safety
of the server operators by this, but maybe you could revisit this idea.
Actually I don't really think that many people would be using Tor
as a one hop proxy only. And if they do, they also should consider
the risk to be traced more easily, or not? And since most of tor's
users want more security, they will be using two or more hops and
I don't think, that a lot of people will try to break into servers
to trace some lonely one-hop connections.
Otherwise I maybe would have to remove the check from the client-code
for a prototype or I would have to find another way to do the tests to
the first hop (e.g. connect to the first host directly without using
tor, which actually would be quite bad for anonymity and does not
include the time needed for crypto).

Nick Mathewson wrote:
> I guess we could have a controller feature that let you set extra
> flags values in descriptor.  For safety, we'd probably want them to
> start with "X-", like extension headers in email or http.
> There is an accepted proposal in progress of implementation that has a
> separate "extra info" document containing data that most users don't
> care about. Check out proposal 104 for more info on that.

That sounds good, I also think that this would be useful for everyone.
If we had such extra flags, we should eventually also be able to set
(and reset) them via a controller.

> For a while, we've been meaning to have _all_ routers, even routers
> that aren't directory caches, accept BEGIN_DIR commands to retrieve
> a limited amount of directory information via Tor connections.
> Caches would serve everything that they would serve normally;
> non-caches would only serve their own descriptor.
> Given this, I think you could just make any bandwidth information
> that you decide it's important to serve a separate document served
> this way.

I'm not sure if I understood this right. How can you serve a separate
document with this if you get either a single descriptor or the complete
network-status document? Do you mean instead of the descriptor in case
of a non-proxy?
I actually wanted to record the information within a controller that
serves this separate document to controllers of client-proxies who will
use the received information in routing. Of course it would be good to
finally include something like this into tor, which would make the
controller to record the data obsolete. But all recording and creation
of a document etc. has to be done within tor then, or am I wrong? At
the moment we are only researching which data would be useful at all and
how to design such a bandwidth document. I think in this testing phase
it would be good to use a controller that can optionally be installed
by participating server operators, since probably not everybody wants
his router to publish such information. And even later on you should
let the operators decide if they have got enough capacities to
additionally record data and serve a separate document (which could
also be done via a configuration option).

Thanks,
Johannes

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGN6LP1TFW0/n+aNgRAji+AJ4kzmbIt4C2WAerAvEmQdL4h0OVGgCghuzJ
0LYYWuve5ernUNc8HLL9c3g=
=ykNK
-----END PGP SIGNATURE-----