[or-cvs] add future task list to todo
arma at seul.org
Mon May 10 09:40:46 UTC 2004
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc
add future task list to todo
RCS file: /home/or/cvsroot/doc/TODO,v
retrieving revision 1.107
retrieving revision 1.108
diff -u -d -r1.107 -r1.108
--- TODO 2 May 2004 03:34:59 -0000 1.107
+++ TODO 10 May 2004 09:40:44 -0000 1.108
@@ -13,10 +13,10 @@
- - Windows port
- - works as client
+ . Windows port
+ o works as client
- deal with pollhup / reached_eof on all platforms
- - robust as a client
+ . robust as a client
- works as server
- can be configured
- robust as a server
@@ -29,8 +29,8 @@
cons of using it, why should I use it, etc.
- a howto tutorial with examples
- tutorial: how to set up your own tor network
- - (need to not hardcore dirservers file in config.c)
- - correct, update, polish spec
+ - (need to not hardcode dirservers file in config.c)
+ . correct, update, polish spec
- document the exposed function api?
- document what we mean by socks.
@@ -78,29 +78,106 @@
. Refactor: add own routerinfo to routerlist. Right now, only
router_get_by_nickname knows about 'this router', as a hack to
get circuit_launch_new to do the right thing.
- - preemptively build and start rendezvous circs
- - preemptively build n-1 hops of intro circs?
- - cannibalize general circs?
- - fix router_get_by_* functions so they can get ourselves too,
- and audit everything to make sure rend and intro points are
- just as likely to be us as not.
-In the distant future:
. Scrubbing proxies
- Find an smtp proxy?
. Get socks4a support into Mozilla
- - migrate to using IPv6 sizes everywhere
- - handle half-open tcp conns
- Extend by nickname/hostname/something, not by IP.
- Need a relay teardown cell, separate from one-way ends.
- Make it harder to circumvent bandwidth caps: look at number of bytes
sent across sockets, not number sent inside TLS stream.
- - Look at having smallcells and largecells
- D Advanced directory servers
- D Automated reputation management
- D Figure out how to do threshold directory servers
- D jurisdiction info in dirserver entries? other info?
- X On the fly compression of each stream
+ - fix router_get_by_* functions so they can get ourselves too,
+ and audit everything to make sure rend and intro points are
+ just as likely to be us as not.
+Rendezvous and hidden services:
+ make it fast:
+ - preemptively build and start rendezvous circs.
+ - preemptively build n-1 hops of intro circs?
+ - cannibalize general circs?
+ make it reliable:
+ - standby/hotswap/redundant services.
+ - store stuff to disk? dirservers forget service descriptors when
+ they restart; nodes offering hidden services forget their chosen
+ intro points when they restart.
+ make it robust:
+ - auth mechanisms to let midpoint and bob selectively choose
+ connection requests.
+ make it scalable:
+ - right now the hidserv store/lookup system is run by the dirservers;
+ this won't scale.
+ Relax clique assumptions.
+ Redesign how directories are handled.
+ - Separate running-routers lookup from descriptor list lookup.
+ - Resolve directory agreement somehow.
+ - Cache directory on all servers.
+ Find and remove bottlenecks
+ - Address linear searches on e.g. circuit and connection lists.
+ Reputation/memory system, so dirservers can measure people,
+ and so other people can verify their measurements.
+ - Need to measure via relay, so it's not distinguishable.
+ Bandwidth-aware path selection. So people with T3's are picked
+ more often than people with DSL.
+ Reliability-aware node selection. So people who are stable are
+ preferred for long-term circuits such as intro and rend circs,
+ and general circs for irc, aim, ssh, etc.
+ Let dissidents get to Tor servers via Tor users. ("Backbone model")
+ Is abandonding the circuit the only option when an extend fails, or
+ can we do something without impacting anonymity too much?
+ Is exiting from the middle of the circuit always a bad idea?
+ Helper nodes. Decide how to use them to improve safety.
+ DNS resolution: need to make tor support resolve requests. Need to write
+ a script and an interface (including an extension to the socks
+ protocol) so we can ask it to do resolve requests. Need to patch
+ tsocks to intercept gethostbyname, else we'll continue leaking it.
+ Improve path selection algorithms based on routing-zones paper. Be sure
+ to start and end circuits in different ASs. Ideally, consider AS of
+ source and destination -- maybe even enter and exit via nearby AS.
+ Intermediate model, with some delays and mixing.
+ Add defensive dropping regime?
+Make it more correct:
+ Handle half-open connections: right now we don't support all TCP
+ streams, at least according to the protocol. But we handle all that
+ we've seen in the wild.
+ Support IPv6.
+ Congestion control. Is our current design sufficient once we have heavy
+ use? Need to measure and tweak, or maybe overhaul.
+ Allow small cells and large cells on the same network?
+ Cell buffering and resending. This will allow us to handle broken
+ circuits as long as the endpoints don't break, plus will allow
+ connection (tls session key) rotation.
+ Implement Morphmix, so we can compare its behavior, complexity, etc.
+ Use cpuworker for more heavy lifting.
+ - Signing (and verifying) hidserv descriptors
+ - Signing (and verifying) intro/rend requests
+ - Signing (and verifying) router descriptors
+ - Signing (and verifying) directories
+ - Doing TLS handshake (this is very hard to separate out, though)
+ Buffer size pool: allocate a maximum size for all buffers, not
+ a maximum size for each buffer. So we don't have to give up as
+ quickly (and kill the thickpipe!) when there's congestion.
+ Exit node caching: tie into squid or other caching web proxy.
+ Other transport. HTTP, udp, rdp, airhook, etc. May have to do our own
+ link crypto, unless we can bully openssl into it.
+ Do all the scalability stuff above, first.
+ Incentives to relay. Not so hard.
+ Incentives to allow exit. Possibly quite hard.
+ Sybil defenses without having a human bottleneck.
+ How to gather random sample of nodes.
+ How to handle nodelist recommendations.
+ Consider incremental switches: a p2p tor with only 50 users has
+ different anonymity properties than one with 10k users, and should
+ be treated differently.
More information about the tor-commits