torproject/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-06 19:41:15 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

prioritize and rearrange the TODO

Browse Source 
svn:r789
This commit is contained in:
Roger Dingledine
2003-11-11 07:50:12 +00:00
parent 08bdcca4c5
commit 5d9496ad77
2 changed files with 41 additions and 43 deletions
Download Patch File Download Diff File Expand all files Collapse all files
trunk/doc/TODO
+30 -31
View File
@@ -1,18 +1,5 @@
Issues identified while writing paper:
- Rotate tls-level connections -- make new ones, expire old ones.
- Dirserver shouldn't put you in running-routers list if you haven't
uploaded a descriptor recently
- Look at having smallcells and largecells
- separate trying to rebuild a circuit because you have none from trying
to rebuild a circuit because the current one is stale
<nickm> If I compromise a node, and streamIDs are sequential, I learn
how many streams have been open and closed on this circuit at this point.
> hm. you learn this for circuits too, do you not?
<nickm> True. But how-many-circuits-from-A-to-B only leaks how long
the connection from A to B has been alive and how much use it's seen.
> ok. needs more investigation.
Nick, can you remember why we wanted to do this?
Legend:
SPEC!! - Not specified
@@ -27,28 +14,36 @@ ARMA - arma claims
X Abandoned
Short-term:
- Rename ACI to circID
- Make tls connections tls_close intentionally
o Rename ACI to circID
. integrate rep_ok functions, see what breaks
- update tor faq
o obey SocksBindAddress, ORBindAddress
- warn if we're running as root
o make connection_flush_buf() more obviously obsolete
. let hup reread the config file, eg so we can get new exit
.* let hup reread the config file, eg so we can get new exit
policies without restarting
- use times(2) rather than gettimeofday to measure how long it
takes to process a cell
. Exit policies
- Separate trying to rebuild a circuit because you have none from trying
to rebuild a circuit because the current one is stale
- Continue reading from socks port even while waiting for connect.
.* Exit policies
o Spec how to write the exit policies
- Path selection algorithms
- Let user request certain nodes
-* More flexible policies (18.*, 18.0.0.0/8)
-* Path selection algorithms
-* Choose path more incrementally
-* Let user request first/last node
- And disallow certain nodes
D Choose path by jurisdiction, etc?
- Make relay end cells have failure status and payload attached
- Streams that fail due to exit policy must reextend to new node
- Add extend_wait state to edge connections, thumb through them
. Make relay end cells have failure status and payload attached
-* Streams that fail due to exit policy must reextend to new node
-* Add extend_wait state to edge connections, thumb through them
when the AP get an extended cell.
- let non-approved routers handshake.
- just list approved routers in directory.
-* let non-approved routers handshake.
-* just list approved routers in directory.
- Dirserver shouldn't put you in running-routers list if you haven't
uploaded a descriptor recently
. migrate to using nickname rather than addr:port for routers
o decide_aci_type
- generate onion skins
@@ -66,18 +61,19 @@ Short-term:
- connection_or_init_conn_from_router
- tag_pack, tag_unpack, connection_cpu_process_inbuf
- directory_initiate_command
. Move from onions to ephemeral DH
.* Move from onions to ephemeral DH
o incremental path building
o transition circuit-level sendmes to hop-level sendmes
o implement truncate, truncated
o move from 192byte DH to 128byte DH, so it isn't so damn slow
- exiting from not-last hop
- OP logic to decide to extend/truncate a path
- make sure exiting from the not-last hop works
- logic to find last *open* hop, not last hop, in cpath
- choose exit nodes by exit policies
- Remember address and port when beginning.
-* exiting from not-last hop
-* OP logic to decide to extend/truncate a path
-* make sure exiting from the not-last hop works
-* logic to find last *open* hop, not last hop, in cpath
-* choose exit nodes by exit policies
o Remember address and port when beginning.
- Extend by nickname/hostname/something, not by IP.
- Need a relay teardown cell, separate from one-way ends.
On-going
. Better comments for functions!
@@ -86,6 +82,9 @@ On-going
. Unit tests
Mid-term:
- Are there anonymity issues with sequential streamIDs? Sequential
circIDs? Eg an attacker can learn how many there have been.
- Look at having smallcells and largecells
. Redo scheduler
o fix SSL_read bug for buffered records
- make round-robining more fair
trunk/doc/tor-design.tex
+11 -12
View File
@@ -991,18 +991,17 @@ to slow down other users when they build new circuits.
% What about link-to-link rate limiting?
Attackers also have an opportunity to attack the Tor network by mounting
attacks on its hosts and network links. Disrupting a single circuit or
link breaks all currently open streams passing along that part of the
circuit. Indeed, this same loss of service occurs when a router crashes
or its operator restarts it. The current Tor design treats such attacks
as intermittent network failures, and depends on users and applications
to respond or recover as appropriate. A future design could use an
end-to-end TCP-like acknowledgment protocol, so that no streams are
lost unless the entry or exit point itself is disrupted. This solution
would require more buffering at the network edges, however, and the
performance and anonymity implications from this extra complexity still
require investigation.
Adversaries can also attack the Tor network's hosts and network
links. Disrupting a single circuit or link breaks all streams passing
along that part of the circuit. Indeed, this same loss of service
occurs when a router crashes or its operator restarts it. The current
Tor design treats such attacks as intermittent network failures, and
depends on users and applications to respond or recover as appropriate. A
future design could use an end-to-end TCP-like acknowledgment protocol,
so that no streams are lost unless the entry or exit point itself is
disrupted. This solution would require more buffering at the network
edges, however, and the performance and anonymity implications from this
extra complexity still require investigation.
\SubSection{Exit policies and abuse}
\label{subsec:exitpolicies}