diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 84 |
1 files changed, 11 insertions, 73 deletions
@@ -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. - -* Add autoconf support. - Figure out what .h files we're actually using, and how portable +* 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 - solution is to have a separate process that we talk to. There are some - free software versions 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 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?) +* We currently block on gethostbyname at the exit. This is poor. We need + to set it up so we have a separate process that we talk to. There are + some free software versions we can use, but they'll still be tricky. * 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 - 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. +* ORs should rotate their link keys periodically. Later. * 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. - |