revised todo

svn:r60

TODO

@@ -6,9 +6,6 @@ Obvious things I'd like to do that won't break anything:
 
 * 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
@@ -16,56 +13,31 @@ Obvious things I'd like to do that won't break anything:
   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.
+* Figure out what .h files we're actually using, and how portable
-
-* Add autoconf support.
-  Figure out what .h files we're actually using, and how portable
   those are.
 
-* Since we're using a stream cipher, an adversary's cell arriving with the
-  same aci will forever trash our circuit. Since each side picks half
-  the aci, for each cell the adversary has a 1/256 chance of trashing a
-  circuit. This is really nasty. We want to make ACIs something reasonably
-  hard to collide with, such as 20 bytes.
-
-  While we're at it, I'd like more than 4 bits for Version. :)
-
 * Exit policies. Since we don't really know what protocol is being spoken,
   it really comes down to an IP range and port range that we
   allow/disallow. The 'application' connection can evaluate it and make
   a decision.
 
-* We currently block on gethostbyname in OR. This is poor. The complex
+* We currently block on gethostbyname at the exit. This is poor. We need
-  solution is to have a separate process that we talk to. There are some
+  to set it up so we have a separate process that we talk to. There are
-  free software versions we can use, but they'll still be tricky. The
+  some free software versions we can use, but they'll still be tricky.
-  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 doing sneaky things like 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.
+  lists? We can aim to make use of the directory servers that Mixminion
+  deploys.
 
-  We should look into a 'topology communication protocol'; there's one
+* ORs should rotate their link keys periodically. Later.
-  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'
 
-* Clean up the number of places that get to look at prkey.
+* Clean up the number of places that get to look at prkey. Later.
 
 * Circuits should expire sometime, say, when circuit->expire triggers?
+  Later.
 
 
 
@@ -75,44 +47,11 @@ 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. The ORs currently
-  send no padding cells between each other. 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
+  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
@@ -121,7 +60,7 @@ analysis before we can guess which approaches are good.)
   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
+  may want to switch to some sort of a two-way-destroy-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
@@ -129,4 +68,3 @@ analysis before we can guess which approaches are good.)
 
 * Reply onions. Hrm.
 
-