aboutsummaryrefslogtreecommitdiff
path: root/README.1st
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2018-01-02 02:57:33 +0100
committerChristian Grothoff <christian@grothoff.org>2018-01-02 11:57:11 +0100
commitee75675c6a80c76b7f083925874c8d8c824c6744 (patch)
tree454d71c1005319d0aad06a5e32d9e5be3b26cd23 /README.1st
parent4ffa88828d1f14aeef51a777d553e904549fb03e (diff)
downloadgnunet-ee75675c6a80c76b7f083925874c8d8c824c6744.tar.gz
gnunet-ee75675c6a80c76b7f083925874c8d8c824c6744.zip
add README.1st
Diffstat (limited to 'README.1st')
-rw-r--r--README.1st245
1 files changed, 245 insertions, 0 deletions
diff --git a/README.1st b/README.1st
new file mode 100644
index 000000000..d55709779
--- /dev/null
+++ b/README.1st
@@ -0,0 +1,245 @@
1The following is a list of issues with GNUnet 0.11.0 that will need to
2be addressed before we might consider GNUnet usable. Please keep this
3list in mind when trying out GNUnet 0.11.0! Help would of course be
4welcome, an estimate of how much work is needed and the main impact
5are given with each item.
6
7
8ats:
9* We currently select one transport per peer, but we should allow the
10use of multiple channels concurrently (i.e. UDP + TCP at the same
11time). Neither ATS nor transport support this today, and this requires
12a major change in the ATS plugins and the ATS API and the overall
13ATS/transport logic. [6-12 PM, robustness, performance]
14
15* The current proportional ATS heuristic does not devalue increasing
16the number of connections once we have reached saturation point,
17possibly resulting in an excessive number of connections.
18[1-3 PM, performance]
19
20* The mlp/ril ATS heuristics are highly unstable and keep crashing or
21worse, and have horrific code quality. [3-12 PM, stability,
22performance]
23
24
25transport: [12-48 PM overall]
26* We should move plugins into separate processes to break an overly
27complicated subsystem into more manageable bits. [maintainability]
28
29* Transport plugins are currently expected to be bi-directional; the
30API should be changed to make them uni-directional, so we could have
31say UDP for sending but receive via say SMTP, simply because NAT
32punching and other transports (especially SAT) simply are not
33bi-directional. Fragmentation and ACKs should then not be done in UDP
34plugin but at transport level. This should result in significantly:
35- better NAT traversal
36- faster transports (especially with the multi-transport of ATS)
37- simplified transport plugins
38[stability, robustness, performance]
39
40* Transport currently does not encrypt. This has the disadvantage that
41TCP/UDP traffic is easily identified as "GNUnet"-traffic. It would be
42better to_also use a simple cipher (ECDHE+AEAD) in a plugin-specific
43way (i.e. HTTPS is fine already) to minimize information leakage, even
44if for efficiency that cipher is is not replay-protected at this level
45(and leave true replay-protected OTR to CORE). [privacy, censorship-resistance]
46
47* transport's 'manipulation' functions should be moved into
48a plugin-proxy, simplifying the code. This may have
49modest implications for testbed due to the API change.
50[maintainability, security]
51
52* testcases are plenty but insufficiently systematic, the changes
53described above should also enable us to create more systematic tests.
54[maintainability, correctness]
55
56
57hello:
58* The current code may leak LAN IPs (in particular IPv6 with
59MAC) globally. We have started to put in some privisions to tag
60addresses as loopback/LAN/WAN, but need to systemtically ensure
61that addresses are only propagated in a useful scope and avoid
62leaking "sensitive" address data globally.
63[3-6 PM, privacy]
64
65
66core:
67* core needs to be able to communicate to other peers whether this
68peer is high-bandwidth or on battery and thus either great for
69relaying or really bad for relaying. Higher-level subsystems
70could then bias their peer selection to more capable peers --
71this is key for going on battery-operated systems.
72[1-3 PM, performance]
73
74* we currently use timestamps (based on roughly-synchronized clocks),
75challenge-response AND sequence numbers to protect against
76replay-protection. This is overkill, and the use of timestamps
77causes issues on OpenWRT where RTCs are often unavailable. We
78might want to increase the nonce for challenges and get rid of
79the roughly-synchronized clocks assumption, at least for CORE
80(we can't avoid it for NSE). [1-3 PM, usability]
81
82* once transport encrypts (ECDH+AES), we should simplify CORE level
83encryption to use ECDH+Twofish(+SHA512) instead of the current
84ECDH+AES+Twofish double-encryption.
85
86* Mobile peers currently allow adversaries to track their users as the
87peer's identity does not change with locations. We need a mechanism to
88notify a mobile peer about a location change and then systematically
89change the public key we use depending on our location. [6-12 PM,
90privacy]
91
92
93cadet:
94* needs more systematic testing, ideally with a mock up of DHT
95and core. [6-12 PM, correctness]
96
97* flow and congestion control implementation remains incomplete;
98should borrow more from net2o [3-6 PM, performance]
99
100* Various optimizations, such as key material pre-computation
101and avoiding unnecessary DHT queries should be implemented.
102[3-9 PM, performance]
103
104* Once transport/core use AES/Twofish for encryption, we should
105switch CADET to use KECCAK-AEAD.
106
107* Generally needs more benchmarking to identify performance
108bottlenecks tune accordingly. [3-12 PM, performance]
109
110
111nat:
112* many known NAT traversal methods are not yet supported
113[6-12 PM, connectivity, usability]
114
115
116dv:
117* dv is still not working, but currently based on SET and we
118should simplify the design to not use SET. [3-6 PM, connectivity,
119correctness]
120
121
122util:
123* Event loop instantiations for various event loops (like glib,
124libev, libevent, etc.) should be created (and tested). This
125will applications to be built with GNUnet using those various
126styles of event loop handling. General support for abstracting
127the event loop is new in 0.11.0, we just need to make broader use
128of it. [1-3 PM, performance, usability]
129
130* gnunet-service-resolver should use asynchronous DNS queries if
131available. This will ensure that name resolution is not super-slow
132when GNUnet makes various parallel DNS queries (rare, but DNS
133queries can happen to resolve peer IP addresses for visualization).
134[1 PM, performance, usability]
135
136
137dht:
138* various minor tweaks should be explored, but first we need to
139define and find a good benchmark to see where our performance
140bottlenecks really are today; datacache (IO subsystem) might
141be one of them. Here, picking appropriate transaction scopes
142and isolation levels should be an easy way to boost performance,
143but we also need more benchmarking logic. [3-12 PM, performance]
144
145
146set:
147* Current implementation is not yet Byzantine fault-tolerant
148against stuffing attack. [1-3 PM, fault-tolerance]
149
150
151topology:
152* quite a few different functions are squished together in one
153subsystem here, will require some changes to address changes
154to transport and hello discussed above [1-3 PM, correctness]
155
156* there are more robust known ways for maintaining a random mesh, we
157might want to explore using those [3-6 PM, robustness]
158
159
160fs:
161* The service should be split into two, one for user-specific and one
162for system-specific components [3-6 PM, security, usability]
163
164* Currently, data and files are stored in a disassociated way,
165resulting in search results that then fail to download; need OR/RPS
166(see below) before we can think about fixing this properly. [6-18 PM,
167usability]
168
169* datastore (IO subsystem) is bad at keeping the database within the
170 quota set by the user. [1-3 PM, correctness]
171
172
173conversation:
174* dropping 'silence' on large-buffers during replay should be
175used to avoid accumulating latency (standard VoIP technique,
176crucial to get it to work for real calls) [1-3 PM, usability]
177
178* needs ring tones [1 PM, usability]
179
180
181gns:
182* should support hijacking arbitrary gtlds [1 PM, usability]
183
184* should import ".fr" ccTLD and ensure implementation performs [3-6 PM]
185
186
187multicast:
188* implementation currently trivial and under-tested
189
190* still uses old NTR-style API, needs to transition to MQ API
191
192
193psyc:
194* implementation under-tested, database performance likely in
195need for optimization [3-12 PM]
196
197
198social:
199* code in need for clean up and more systematic testing [6-12 PM]
200
201
202rps:
203* Open research, still experimental. [3-24 PM]
204
205
206xolotl/lake/or:
207* Open research, still non-existent. Symmetric cipher should
208be CHACHA. [48-120 PM]
209
210
211No serious problems are known in:
212* statistics
213* nse
214* curl
215* revocation
216* scalarproduct
217* tun
218* testbed
219* block
220* fragmentation
221* consensus
222* secretsharing
223* pt
224* vpn
225* gns
226* gnsrecord
227* arm
228* dns
229* exit
230* identity
231* json
232* sq
233* my
234* namecache
235* namestore
236* testing
237* hostlist
238* zonemaster
239
240
241We reserve judgement (due to lack of data) on:
242* identity-provider
243* rest
244
245