README.1st

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