1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
Obvious things I'd like to do that won't break anything:
* Abstract out crypto calls, 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.
|