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

made it clearer that the ORs currently don't support padding at all

Browse Source 
(it should be straightforward to add in -- but only once we decide how we
want to do it.)


svn:r7
This commit is contained in:
Roger Dingledine
2002-06-27 02:54:16 +00:00
parent c5006f9683
commit 92ef3ccae8
1 changed files with 16 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
trunk/TODO
+16 -11
View File
@@ -63,22 +63,27 @@ Obvious things I'd like to do that won't break anything:
* The parts of the code that say 'FIXME'
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. 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.
* 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