org/roadmaps/Tor.md

-= Projects for the core Tor implementation: =
+# Projects for the core Tor implementation:
 
-== Overview ==
+## Overview
 
-The ''tor'' program implements the core client and server code for participating in the Tor network. The source is available at https://gitweb.torproject.org/tor.
+The _tor_ program implements the core client and server code for participating in the Tor network. The source is available at https://gitweb.torproject.org/tor.
 
-== Active Projects ==
+## Active Projects
 
   * Increase Tor's suitability as a circumvention tool based on designs stated in "Design of a blocking-resistant anonymity system" (sponsor A, deliverables 1 and 2)
   * Facilitate reconfiguration of clients to bridges (sponsor A, deliverable 3)
@@ -21,9 +21,9 @@ The ''tor'' program implements the core client and server code for participating
   * Make it harder to use exit nodes as one-hop proxies. (#1751) (Sponsor D, deliverable 3 for Sep 30)
   * Make it so all clients can get promoted to bridges. (#1752) (Sponsor D, deliverable 6 for Sep 30: design and initial progress)
   * Improve reliability for Windows relays. (#1753) (sponsor D, deliverable 20 for Sep 30: analysis and progress on bufferevents)
-  * [wiki:org/roadmaps/Tor/IPv6 IPv6 support in Tor]
+  * [IPv6 support in Tor](./org/roadmaps/Tor/IPv6)
 
-== Future ideas ==
+## Future ideas
 
   * Add support for advertising directory mirrors that have no DirPort, but only support BEGIN_DIR.
   * Make Tor able to relay more open-formed DNS requests to the exit node's DNS; expand DNSPort to handle TCP DNS requests as needed.
@@ -31,11 +31,11 @@ The ''tor'' program implements the core client and server code for participating
   * Perhaps, make all bridges also able to proxy connections to the Tor download site.
   * Switch to a UDP transport.
 
-== Imported future ideas from TODO.future ==
+## Imported future ideas from TODO.future
 
 Many of these may be stale.  Move them from here to the "Future Ideas" section if they're still desirable ideas.
 
-=== Later, unless people want to implement them now: ===
+### Later, unless people want to implement them now:
   * Actually use SSL_shutdown to close our TLS connections.
   * Include "v" line in networkstatus getinfo values.
     * [Nick: bridge authorities output a networkstatus that is missing version numbers. This is inconvenient if we want to make sure bridgedb gives out bridges with certain characteristics. -RD]
@@ -46,7 +46,7 @@ Many of these may be stale.  Move them from here to the "Future Ideas" section i
   * It would be potentially helpful to respond to https requests on the OR port by acting like an HTTPS server.
   * We should get smarter about handling address resolve failures, or addresses that resolve to local IPs. It would be neat to retry them since right now we just close the stream. But we need to make sure we don't retry them on the same exit as before. But if we mark the circuit, then any user who types "localhost" will cycle through circuits till they run out of retries. See bug #872.
 
-=== Can anybody remember why we wanted to do this and/or what it means? ===
+### Can anybody remember why we wanted to do this and/or what it means?
   * config option `__ControllerLimit` that hangs up if there are a limit of controller connections already.
     * [This was mwenge's idea. The idea is that a Tor controller can "fill" Tor's controller slot quota, so jerks can't do cross-protocol attacks like the HTTP form attack. -RD]
   * Bridge issues:
@@ -55,31 +55,31 @@ Many of these may be stale.  Move them from here to the "Future Ideas" section i
     * drop 'authority' queries if they're to our own identity key; accept them otherwise.
     * give extend_info_t a router_purpose again
 
-=== If somebody wants to do this in some version, they should: ===
+### If somebody wants to do this in some version, they should:
   * Create packages for Maemo/Nokia 800/810, requested by Chris Soghoian
     * Debian already makes ARM-arch debs, can maemo use these asks phobos?
   * More work on AvoidDiskWrites
   * Make DNSPort support TCP DNS.
 
-=== Roger, please sort these: ===
+### Roger, please sort these:
   * bridge communities with local bridge authorities:
   * clients who have a password configured decide to ask their bridge authority for a networkstatus
   * be able to have bridges that aren't in your torrc. save them in the state file, etc.
   * Consider if we can solve: the Tor client doesn't know what flags its bridge has (since it only gets the descriptor), so it can't make decisions based on Fast or Stable.
   * Some mechanism for specifying that we want to stop using a cached bridge.
 
-=== Future versions: ===
+### Future versions:
 
-=== Protocol: ===
+### Protocol:
   * Our current approach to block attempts to use Tor as a single-hop proxy is pretty lame; we should get a better one.
   * Allow small cells and large cells on the same network?
   * Cell buffering and resending. This will allow us to handle broken circuits as long as the endpoints don't break, plus will allow connection (TLS session key) rotation.
-  * Implement [http://freehaven.net/anonbib/#morphmix:wpes2002 MorphMix] ([http://freehaven.net/anonbib/#morphmix-fc2004 another paper]), so we can compare its behavior, complexity, etc.  But see [http://freehaven.net/anonbib/#morphmix:pet2006 paper breaking morphmix].
+  * Implement [MorphMix](http://freehaven.net/anonbib/#morphmix:wpes2002) ([another paper](http://freehaven.net/anonbib/#morphmix-fc2004)), so we can compare its behavior, complexity, etc.  But see [paper breaking morphmix](http://freehaven.net/anonbib/#morphmix:pet2006).
   * Other transport. HTTP, UDP, RDP, airhook, etc. May have to do our own link crypto unless we can bully DTLS into it.
   * Need a relay teardown cell, separate from one-way ends. (Pending a user who needs this)
   * Handle half-open connections: right now we don't support all TCP streams, at least according to the protocol. But we handle all that we've seen in the wild. (Pending a user who needs this)
 
-=== Directory system: ===
+### Directory system:
   * BEGIN_DIR items
     * handle connect-dir streams that don't have a chosen_exit_name set.
     * Have a "Faster" status flag that means it. Fast2, Fast4, Fast8?
@@ -91,17 +91,17 @@ Many of these may be stale.  Move them from here to the "Future Ideas" section i
     * `X` Have new people be in limbo and need to demonstrate the usefulness
       before we approve them.
 
-=== Hidden services: ===
+### Hidden services:
   * `d` Standby/hotswap/redundant hidden services: needs a proposal.
   * you can insert a hidserv descriptor via the controller.
   * auth mechanisms to let hidden service midpoint and responder filter connection requests: proposal 121.
   * Let each hidden service (or other things) specify its own OutboundBindAddress?
 
-=== Server operation: ===
+### Server operation:
   * If the server is spewing complaints about raising your ulimit -n, we should add a note about this to the server descriptor so other people can notice too.
   * When we hit a funny error from a dir request (eg 403 forbidden), but tor is working and happy otherwise, and we haven't seen many such errors recently, then don't warn about it.
 
-=== Controller: ===
+### Controller:
   * Implement missing status events and accompanying getinfos
     * DIR_REACHABLE
     * BAD_DIR_RESPONSE (Unexpected directory response; maybe we're behind a firewall.)
@@ -125,7 +125,7 @@ Many of these may be stale.  Move them from here to the "Future Ideas" section i
       * We need some way to adjust server status and to tell Tor not to download directories/network-status, and a way to force a download.
       * Make everything work with hidden services
 
-=== Performance/resources: ===
+### Performance/resources:
   * per-conn write buckets
   * separate config options for read vs write limiting. (It's hard to support read > write, since we need better congestion control to avoid overfull buffers there.  So, defer the whole thing.)
   * Rate limit exit connections to a given destination -- this helps us play nice with websites when Tor users want to crawl them; it also introduces DoS opportunities.
@@ -133,13 +133,13 @@ Many of these may be stale.  Move them from here to the "Future Ideas" section i
   * Handle full buffers without totally borking.
   * Rate-limit OR and directory connections overall and per-IP and maybe per subnet.
 
-=== Misc: ===
+### Misc:
   * Hold-open-until-flushed now works by accident; it should work by design.
   * Display the reasons in 'destroy' and 'truncated' cells under some circumstances?
   * Make router_is_general_exit() a bit smarter once we're sure what it's for.
   * Automatically determine what ports are reachable and start using those, if circuits aren't working and it's a pattern we recognize ("port 443 worked once and port 9001 keeps not working").
 
-=== Security: ===
+### Security:
   * some better fix for bug #516?
   * Directory guards
   * Mini-SoaT:
@@ -151,16 +151,16 @@ Many of these may be stale.  Move them from here to the "Future Ideas" section i
   * Do something to prevent spurious EXTEND cells from making middleman nodes connect all over. Rate-limit failed connections, perhaps?
   * DoS protection: TLS puzzles, public key ops, bandwidth exhaustion.
 
-=== Needs thinking: ===
-  * Now that we're avoiding exits when picking non-exit positions, we need to consider how to pick nodes for internal circuits. If we avoid exits for all positions, we skew the load balancing. If we accept exits for all positions, we leak whether it's an internal circuit at every step. If we accept exits only at the last hop, we reintroduce Lasse's attacks from [http://freehaven.net/anonbib/#hs-attack06 the Oakland paper].
+### Needs thinking:
+  * Now that we're avoiding exits when picking non-exit positions, we need to consider how to pick nodes for internal circuits. If we avoid exits for all positions, we skew the load balancing. If we accept exits for all positions, we leak whether it's an internal circuit at every step. If we accept exits only at the last hop, we reintroduce Lasse's attacks from [the Oakland paper](http://freehaven.net/anonbib/#hs-attack06).
 
-=== Windows server usability: ===
+### Windows server usability:
   * Solve the ENOBUFS problem.
     * make tor's use of OpenSSL operate on buffers rather than sockets, so we can make use of libevent's buffer paradigm once it has one.
     * make tor's use of libevent tolerate either the socket or the buffer paradigm; includes unifying the functions in connect.c.
   * We need a getrlimit equivalent on Windows so we can reserve some file descriptors for saving files, etc. Otherwise, we'll trigger asserts when we're out of file descriptors and crash.
 
-=== Documentation: ===
+### Documentation:
   * a way to generate the website diagrams from source, so we can translate them as UTF-8 text rather than with gimp. (SVG or ImageMagick?)
   * Flesh out options_description array in src/or/config.c
   * multiple samples torrc files
@@ -173,8 +173,8 @@ Many of these may be stale.  Move them from here to the "Future Ideas" section i
     * capitalize the first sentence in the Doxygen comment, except when you shouldn't.
     * avoid spelling errors and incorrect comments. ;)
 
-=== Packaging: ===
+### Packaging:
   * The Debian package now uses --verify-config when (re)starting, to distinguish configuration errors from other errors. Perhaps the RPM and other startup scripts should too?
   * Add a "default.action" file to the Tor/Vidalia bundle so we can fix the https thing in the default configuration: [https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#PrivoxyWeirdSSLPort">https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#PrivoxyWeirdSSLPort]
 
-== Blue-sky projects ==
\ No newline at end of file
+## Blue-sky projects
\ No newline at end of file