2
0

README.1st 8.2 KB

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