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
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
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.)
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
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.
|