|
@@ -1,106 +1,107 @@
|
|
|
-[First four are all equally first.
|
|
|
-Others follow in order of priority.]
|
|
|
|
|
|
-Patch well-known proxies to make them OR compliant
|
|
|
- Data stream anonymizing, HTTP/FTP (Privoxy, Squid), SMTP, etc.
|
|
|
- Packet Redirector, a la FreeBSD (DNS, authenticated connections, etc.)
|
|
|
+Legend:
|
|
|
+SPEC!! - Not specified
|
|
|
+SPEC - Spec not finalized
|
|
|
+ - Not done
|
|
|
+ * Top priority
|
|
|
+ . Partially done
|
|
|
+ o Done
|
|
|
+ D Deferred
|
|
|
+ X Abandoned
|
|
|
+
|
|
|
+
|
|
|
+ . Topics / circuits
|
|
|
+ o Implement topics
|
|
|
+ - Rotate circuits after N minutes?
|
|
|
+ - Circuits should expire when circuit->expire triggers
|
|
|
+ - Handle half-open connections
|
|
|
+ . Clean up the event loop (optimize and sanitize)
|
|
|
+ - Exit policies
|
|
|
+ - Path selection algorithms
|
|
|
+ - Let user request certain nodes
|
|
|
+ - And disallow certain nodes
|
|
|
+ - Choose path by jurisdiction, etc?
|
|
|
+ - Implement our own memory management, at least for common structs
|
|
|
+ . Appropriate logging
|
|
|
+ - Come up with convention for what log level means what
|
|
|
+ - Make code follow convention
|
|
|
+ . Terminology
|
|
|
+ o Circuits, topics, cells stay named that
|
|
|
+ - 'Connection' gets divided, or renamed, or something?
|
|
|
+ . DNS farm
|
|
|
+ o Distribute queries onto the farm, get answers
|
|
|
+ o Preemptively grow a new worker before he's needed
|
|
|
+ - Prune workers when too many are idle
|
|
|
+ - Keep track of which connections are in dns_wait
|
|
|
+ - Need to cache positives/negatives on the tor side
|
|
|
+ - Keep track of which queries have been asked
|
|
|
+ - Better error handling when
|
|
|
+ - An address doesn't resolve
|
|
|
+ - We have max workers running
|
|
|
+ . Directory servers
|
|
|
+ - Automated reputation management
|
|
|
+ - Include key in source; sign directories
|
|
|
+ - Have directories list recommended-versions
|
|
|
+ - Quit if running the wrong version
|
|
|
+ - Command-line option to override quit
|
|
|
+ . Add more information to directory server entries
|
|
|
+ - Exit policies
|
|
|
+ - jurisdiction? others?
|
|
|
+SPEC!! - Figure out how to do threshold directory servers
|
|
|
+ . Scrubbing proxies
|
|
|
+ - Find an smtp proxy?
|
|
|
+ - Find an ftp proxy? Figure out how that would work?
|
|
|
+ - Wait until there are packet redirectors for Linux
|
|
|
+ . Get socks4a support into Mozilla
|
|
|
+ . Get tor to act like a socks server
|
|
|
+ o socks4, socks4a
|
|
|
+ - socks5
|
|
|
+SPEC!! - Handle socks commands other than connect, eg, bind?
|
|
|
+ - Develop rendezvous points
|
|
|
+ D Implement reply onions
|
|
|
+ D Deploy and manage open source development site.
|
|
|
+ . Documentation
|
|
|
+ . Discussion of socks, tsocks, etc
|
|
|
+ - On-the-network protocol
|
|
|
+ - Onions
|
|
|
+ - Cells
|
|
|
+ . Better comments for functions!
|
|
|
+ - Tests
|
|
|
+ - Testing harness/infrastructure
|
|
|
+ - Unit tests
|
|
|
+ - System tests (how?)
|
|
|
+ - Performance tests, so we know when we've improved
|
|
|
+ . webload infrastructure (Bruce)
|
|
|
+ . httperf infrastructure (easy to set up)
|
|
|
+ . oprofile (installed in RH 8.0)
|
|
|
+ D Deploy a widespread network
|
|
|
+ . Router twins
|
|
|
+ o Choose twin if primary is down, when laying circuit
|
|
|
+ - Load balancing between twins
|
|
|
+ - Keep track of load over links/nodes, to
|
|
|
+ know who's hosed
|
|
|
+ - Daemonize and package
|
|
|
+ - Teach it to fork and background
|
|
|
+ - Red Hat spec file
|
|
|
+ - Debian spec file equivalent
|
|
|
+
|
|
|
+ . Autoconf
|
|
|
+ . Which .h files are we actually using? Port to:
|
|
|
+ o Linux
|
|
|
+ o BSD
|
|
|
+ . Solaris
|
|
|
+ . Windows
|
|
|
+ . Move away from openssl
|
|
|
+ o Abstract out crypto calls
|
|
|
+ - Look at ndss, others? Just include code?
|
|
|
+
|
|
|
+ . transition addr to sin_addr (huh?)
|
|
|
+
|
|
|
+ . Clean up the number of places that get to look at prkey
|
|
|
+SPEC!! - Non-clique topologies, clearer bandwidth management
|
|
|
+ . Look at OR handshake in more detail
|
|
|
+ - Spec it
|
|
|
+ - Merge OR and OP handshakes?
|
|
|
+ - Periodic link key rotation. Spec?
|
|
|
|
|
|
-Deploy and manage open source development site.
|
|
|
-Manage and maintain code, write documentation, design and write
|
|
|
- unit tests, handle patch submissions, make the autoconf work, etc
|
|
|
-
|
|
|
-Deploy a widespread network: manage deployment.
|
|
|
-Maintain and distribute directory/network state information etc. Keep
|
|
|
-operators and users happy.
|
|
|
-
|
|
|
-Test OR network for reliability and performance, with and without
|
|
|
- mechanisms for throttling, congestion control, padding, load balancing
|
|
|
- if applicable, etc.
|
|
|
- Use httperf and webload to get some performance stats
|
|
|
- Modify code as dictated by testing.
|
|
|
-
|
|
|
-Develop rendezvous points
|
|
|
-Implement reply onions
|
|
|
-Develop location protected servers idea
|
|
|
-
|
|
|
-Enhance router twins to do load balancing as well as DoS prevention
|
|
|
-
|
|
|
-Develop and deploy automated reputation management, directory servers,
|
|
|
-and directory/network state monitoring.
|
|
|
-
|
|
|
----
|
|
|
-
|
|
|
-debian / red hat spec file
|
|
|
-handle starting things as a system daemon
|
|
|
-transition addr to sin_addr
|
|
|
-get proxy to choose the same conn if it's open
|
|
|
-
|
|
|
-Obvious things I'd like to do that won't break anything:
|
|
|
-
|
|
|
-* Abstract out crypto calls (done), with the eventual goal of moving
|
|
|
- from openssl to something with a more flexible license.
|
|
|
-
|
|
|
-* Test suite. We need one.
|
|
|
-
|
|
|
-* 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?
|
|
|
-
|
|
|
-* Figure out what .h files we're actually using, and how portable
|
|
|
- those are.
|
|
|
-
|
|
|
-* 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 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? We can aim to make use of the directory servers that Mixminion
|
|
|
- deploys.
|
|
|
-
|
|
|
-* 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. Later.
|
|
|
-
|
|
|
-* Circuits should expire sometime, say, when circuit->expire triggers?
|
|
|
- Later.
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-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.)
|
|
|
-
|
|
|
-* 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-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
|
|
|
- one-hop-ack approach that Matej used.
|
|
|
-
|
|
|
-* Reply onions. Hrm.
|
|
|
|