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 * Core should support protocol versioning for higher-level services
  99 [3 PM]
 100
 101
 102 cadet:
 103 * needs more systematic testing, ideally with a mock up of DHT
 104 and core. [6-12 PM, correctness]
 105
 106 * flow and congestion control implementation remains incomplete;
 107 should borrow more from net2o [3-6 PM, performance]
 108
 109 * Various optimizations, such as key material pre-computation
 110 and avoiding unnecessary DHT queries should be implemented.
 111 [3-9 PM, performance]
 112
 113 * Once transport/core use AES/Twofish for encryption, we should
 114 switch CADET to use KECCAK-AEAD.
 115
 116 * Generally needs more benchmarking to identify performance
 117 bottlenecks tune accordingly. [3-12 PM, performance]
 118
 119
 120 nat:
 121 * many known NAT traversal methods are not yet supported
 122 [6-12 PM, connectivity, usability]
 123
 124
 125 dv:
 126 * dv is still not working, but currently based on SET and we
 127 should simplify the design to not use SET. [3-6 PM, connectivity,
 128 correctness]
 129
 130
 131 util:
 132 * Event loop instantiations for various event loops (like glib,
 133 libev, libevent, etc.) should be created (and tested).  This
 134 allows applications to be built with GNUnet using those various
 135 styles of event loop handling.  General support for abstracting
 136 the event loop is new in 0.11.0, we just need to make broader use
 137 of it. [1-3 PM, performance, usability]
 138
 139 * gnunet-service-resolver should use asynchronous DNS queries if
 140 available.  This will ensure that name resolution is not super-slow
 141 when GNUnet makes various parallel DNS queries (rare, but DNS
 142 queries can happen to resolve peer IP addresses for visualization).
 143 [1 PM, performance, usability]
 144
 145
 146 dht:
 147 * various minor tweaks should be explored, but first we need to
 148 define and find a good benchmark to see where our performance
 149 bottlenecks really are today; datacache (IO subsystem) might
 150 be one of them.  Here, picking appropriate transaction scopes
 151 and isolation levels should be an easy way to boost performance,
 152 but we also need more benchmarking logic. [3-12 PM, performance]
 153
 154
 155 set:
 156 * Current implementation is not yet Byzantine fault-tolerant
 157 against stuffing attack.  [1-3 PM, fault-tolerance]
 158
 159
 160 topology:
 161 * quite a few different functions are squished together in one
 162 subsystem here, will require some changes to address changes
 163 to transport and hello discussed above [1-3 PM, correctness]
 164
 165 * there are more robust known ways for maintaining a random mesh, we
 166 might want to explore using those [3-6 PM, robustness]
 167
 168
 169 fs:
 170 * The service should be split into two, one for user-specific and one
 171 for system-specific components [3-6 PM, security, usability]
 172
 173 * Currently, data and files are stored in a disassociated way,
 174 resulting in search results that then fail to download; need OR/RPS
 175 (see below) before we can think about fixing this properly. [6-18 PM,
 176 usability]
 177
 178 * datastore (IO subsystem) is bad at keeping the database within the
 179   quota set by the user. [1-3 PM, correctness]
 180
 181
 182 conversation:
 183 * dropping 'silence' on large-buffers during replay should be
 184 used to avoid accumulating latency (standard VoIP technique,
 185 crucial to get it to work for real calls) [1-3 PM, usability]
 186
 187 * needs ring tones [1 PM, usability]
 188
 189
 190 gns:
 191 * should support hijacking arbitrary gtlds [1 PM, usability]
 192
 193 * should import ".fr" ccTLD and ensure implementation performs [3-6 PM]
 194
 195
 196 multicast:
 197 * implementation currently "trivial" (aka doing round-robin, not multicast)
 198   and under-tested
 199
 200 * still uses old NTR-style API, needs to transition to MQ API [DONE]
 201
 202
 203 psyc:
 204 * implementation under-tested, database performance likely in
 205 need for optimization [3-12 PM]
 206
 207
 208 social:
 209 * code in need for clean up and more systematic testing [6-12 PM]
 210
 211
 212 rps:
 213 * Open research, still experimental. [3-24 PM]
 214
 215
 216 xolotl/lake/or:
 217 * Open research, still non-existent. Symmetric cipher should
 218 be CHACHA. [48-120 PM]
 219
 220
 221 No serious problems are known in:
 222 * statistics
 223 * nse
 224 * curl
 225 * revocation
 226 * scalarproduct
 227 * tun
 228 * testbed
 229 * block
 230 * fragmentation
 231 * consensus
 232 * secretsharing
 233 * pt
 234 * vpn
 235 * gns
 236 * gnsrecord
 237 * arm
 238 * dns
 239 * exit
 240 * identity
 241 * json
 242 * sq
 243 * my
 244 * namecache
 245 * namestore
 246 * testing
 247 * hostlist
 248 * zonemaster
 249
 250
 251 We reserve judgement (due to lack of data) on:
 252 * reclaim
 253 * credential
 254 * abe
 255 * rest
 256