OR partial todo file
aas23 at hermes.cam.ac.uk
Thu Jun 27 14:35:00 UTC 2002
Ok, well if you have started a serious design thread, I will continue.
(My status: trying to sort out how I am going to run OR here in the lab
and getting 2 machines to an appropriate state)
> Obvious things I'd like to do that won't break anything:
> * Abstract out crypto calls, with the eventual goal of moving
> from openssl to something with a more flexible license.
Yes. Sigh. We want to be able to GPL this code.
<uncontroversial things deleted>
> * Since my OR can handle multiple circuits through a given OP,
> I think it's clear that the OP should pass new create cells through the
> same channel. Thus we can take advantage of the padding we're already
> getting. Does that mean the choose_onion functions should be changed
> to always pick a favorite OR first, so the OP can minimize the number
> of outgoing connections it must sustain?
The idea I had about this is that all connections from a particular OP go
to the first router (via the constant-padded OP -> OR_1 link) and can then
go via an arbitrary route to the destination. I think this is ok
> * Add autoconf support.
> Figure out what .h files we're actually using, and how portable
> those are.
You are replying on glibc 2.2, as I discovered while trying to install it
on an old machine...
> * I'd like more than 4 bits for Version. :) More generally, we may want
> to increase sizes of various things in the onion. I haven't looked
> much at the onion code yet.
Should not be a priority...
> * Exit policies. Since we don't really know what protocol is being spoken
> to the application, it really comes down to an IP range and port range
> that we allow/disallow (in various combinations). The 'application'
> connection can evaluate it and make a decision to accept or reject.
Do you really care that much about who the connection goes to?
> * We currently block on gethostbyname in OR. This is poor. The complex
> solution is to have a separate process that we talk to. There are some
> free software programs we can use, but they'll still be tricky. The
> better answer is to realize that the OP can do the resolution and
> simply hand the OR an IP directly.
> A) This prevents us from having the name resolve differently at the
> OR than at the OP. I'm ok with that.
> B) It actually just shunts the "dns lookups block" problem back onto the
> OP. But that's ok too, because the OP doesn't have to be as robust.
> (Heck, can we have the application proxy resolve it, even?)
Errr... If an OP does a gethostbyname call, it's about to make an
anonymous connection to that IP. This breaks anonymity (unless I am being
totally dense and not understanding something)
> We should look into a 'topology communication protocol'; there's one
> mentioned in the spec that Paul has, but I haven't looked at it to
> know how complete it is or how well it would work. This would also
> allow us to add new ORs on the fly. Directory servers, a la the ones
> we're developing for Mixminion (see http://mixminion.net/), are also
> a very nice approach to consider.
Well we need to decide how to solve the n^2 problem anyway... See later
chat about padding.
> * Should ORs rotate their link keys periodically?
> * We probably want OAEP padding for RSA.
> * Padding between ORs, and correct padding between OPs. Currently
I think this is a new thread, I'll post my reply to this in a separate
> * Make the connection buf's grow dynamically as needed. This won't
> really solve the fundamental problem above, though, that a buffer
> can be given an adversary-controlled number of cells.
> * Reply onions. Hrm.
Hrm. Leave for now. Complicated problems... You are the best-placed person
to solve them having done mixminion. Let's do the above first.
Cambridge CB3 9ET
More information about the tor-dev