README.1st

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