OR partial todo file
arma at mit.edu
Wed Jun 26 10:18:18 UTC 2002
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.
* Test suite. We need one.
* Switch the "return -1" cases that really mean "you've got a bug"
into calls to assert().
* 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?
* Rewrite the OP to be non-blocking single-process.
* Add autoconf support.
Figure out what .h files we're actually using, and how portable
* 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.
* 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.
* 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?)
* I'd like a cleaner interface for the configuration files, keys, etc.
Perhaps the next step is a central repository where we download router
lists? Something that takes the human more out of the loop.
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.
* Should ORs rotate their link keys periodically?
* We probably want OAEP padding for RSA.
* The parts of the code that say 'FIXME' ought to get addressed too. :)
Non-obvious things I'd like to do:
(Many of these topics are inter-related. It's clear that we need more
analysis before we can guess which approaches are good.)
* Padding between ORs, and correct padding between OPs. Currently
the OP seems to send padding at a steady rate, but data cells can
come more quickly than that. This doesn't provide much protection
at all. I'd like to investigate a synchronous mixing approach, where
cells are sent at fixed intervals. We need to investigate the effects
of this on DoS resistance -- what do we do when we have too many
packets? One approach is to do traffic shaping rather than traffic
padding -- we gain a bit more resistance to DoS at the expense of some
anonymity. Can we compare this analysis to that of the Cottrell Mix,
and learn something new? We'll need to decide on exactly how the
traffic shaping algorithm works.
* 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.
* I'd like to add a scheduler of some sort. Currently we only need one
for sending out padding cells, and if these events are periodic and
synchronized, we don't yet need a scheduler per se, but rather we just
need to have poll return every so often and avoid sending cells onto
the sockets except at the appointed time. We're nearly ready to do
that as it is, with the separation of write_to_buf() and flush_buf().
Edge case: what do we do with circuits that receive a destroy
cell before all data has been sent out? Currently there's only one
(outgoing) buffer per connection, so since it's crypted, a circuit
can't recognize its own packet once it's been queued. We could mark
the circuits for destruction, and go through and cull them once the
buffer is entirely flushed; but with the synchronous approach above,
the buffer may never become empty. Perhaps I should implement a callback
system, so a function can get called when a particular cell gets sent
out. That sounds very flexible, but might also be overkill.
* Currently when a connection goes down, it generates a destroy cell
(either in both directions or just the appropriate one). When a
destroy cell arrives to an OR (and it gets read after all previous
cells have arrived), it delivers a destroy cell for the "other side"
of the circuit: if the other side is an OP or APP, it closes the entire
connection as well.
But by "a connection going down", I mean "I read eof from it". Yet
reading an eof simply means that it promises not to send any more
data. It may still be perfectly fine receiving data (read "man 2
shutdown"). In fact, some webservers work that way -- the client sends
his entire request, and when the webserver reads an eof it begins
its response. We currently don't support that sort of protocol; we
may want to switch to some sort of a two-way-destry-ripple technique
(where a destroy makes its way all the way to the end of the circuit
before being echoed back, and data stops flowing only when a destroy
has been received from both sides of the circuit); this extends the
one-hop-ack approach that Matej used.
* Reply onions. Hrm.
More information about the tor-dev