From f9c541bfcf886248e809d198b19fb1e2e97b924e Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Tue, 18 Mar 2003 03:27:47 +0000 Subject: [PATCH] remove faq and hacking files too. they're now in doc. svn:r193 --- FAQ | 110 ---------------------------------------------------- HACKING | 117 -------------------------------------------------------- 2 files changed, 227 deletions(-) delete mode 100644 FAQ delete mode 100644 HACKING diff --git a/FAQ b/FAQ deleted file mode 100644 index 1c49f83628..0000000000 --- a/FAQ +++ /dev/null @@ -1,110 +0,0 @@ -The Onion Routing (TOR) Frequently Asked Questions --------------------------------------------------- - -1. General. - -1.1. What is tor? - -Tor is an implementation of version 2 of Onion Routing. - -Onion Routing is a connection-oriented anonymizing communication -service. Users build a layered block of asymmetric encryptions which -describes a source-routed path through a set of nodes. Those nodes -build a "virtual circuit," in which each node knows its predecessor and -successor, but no others. Traffic flowing down the circuit is unwrapped -by a symmetric key at each node which reveals the downstream node. - -Basically tor provides a distributed network of servers ('onion -routers'). Users bounce their tcp streams (web traffic, ftp, ssh, etc) -around the routers, and recipients, observers, and even the routers -themselves have difficulty tracking the source of the stream. - -1.2. Why's it called tor? - -Because tor is the onion routing system. I kept telling people I was -working on onion routing, and they said "Neat. Which one?" Even if onion -routing has become a standard household term, this is the actual onion -routing project, started out of the Naval Research Lab. - -(Theories about recursive acronyms are ok too.) - - -2. Compiling and installing. - -[Read the README file for now; check back here once we've got packages/etc -for you.] - - -3. Running tor. - -3.1. What's this about roles? What kind of server should I run? - -The same executable ("or") functions as both client and server, depending -on the value of the config variable named 'Role'. Role represents a -combination of which tasks this particular tor server will do. The default -Role (role 15) is an onion router: it listens for onion routers, listens -for onion proxies, listens for application proxies, and it connects to -all other onion routers it learns about. A directory server (role 63) -does all of the above and also serves directory requests. A simple -onion proxy, on the other hand (role 8), only listens for application -proxies. See part 3.1 of the HACKING document for more technical details. - -3.2. So I can just run a full onion router and join the network? - -No. Users should run just an onion proxy (use the 'oprc' config file). -If you start up a full onion router, the rest of the routers in the -system won't recognize you, so they will reject your handshake attempts. - -3.3. How do I join the network then? - -If you just want to use the onion routing network, you can run a proxy -and you're all set. If you want to run a router, you must convince -the directory server operators (currently arma@mit.edu) that you're a -trustworthy person. From there, the operators add you to the directory, -which propagates out to the rest of the network. All nodes will know -about you within an hour. - -3.4. I want to run a directory server too. - -If you run a very reliable node, you plan to be around for a long time, -and you want to spend some time ensuring that router operators are -people we know and like, we may want you to run a directory server -too. We must manually add you to the 'dirservers' file that's part of -the distribution; users will only know about you when they upgrade to -a new version. Of course, you can always just start up your router as a -directory server too --- but users won't know to ask you for directories, -and more importantly, you'll never learn from the real directory servers -about recently joined routers. - - -4. Development. - -4.1. Who's doing this? - -4.2. Can I help? - -4.3. I've got a bug. - - -5. Anonymity. - -5.1. So I'm totally anonymous if I use tor? - -5.2. Where can I learn more about anonymity? - - -6. Comparison to related projects. - -6.1. Onion Routing. - -Tor *is* onion routing. - -6.2. Freedom. - - -7. Protocol and application support. - -7.1. http? ftp? udp? socks? mozilla? - - - diff --git a/HACKING b/HACKING deleted file mode 100644 index 421b32f904..0000000000 --- a/HACKING +++ /dev/null @@ -1,117 +0,0 @@ - -0. Intro. -Onion Routing is still very much in development stages. This document -aims to get you started in the right direction if you want to understand -the code, add features, fix bugs, etc. - -Read the README file first, so you can get familiar with the basics. - -1. The programs. - -1.1. "or". This is the main program here. It functions as both a server -and a client, depending on which config file you give it. ... - -2. The pieces. - -2.1. Routers. Onion routers, as far as the 'or' program is concerned, -are a bunch of data items that are loaded into the router_array when -the program starts. After it's loaded, the router information is never -changed. When a new OR connection is started (see below), the relevant -information is copied from the router struct to the connection struct. - -2.2. Connections. A connection is a long-standing tcp socket between -nodes. A connection is named based on what it's connected to -- an "OR -connection" has an onion router on the other end, an "OP connection" has -an onion proxy on the other end, an "exit connection" has a website or -other server on the other end, and an "AP connection" has an application -proxy (and thus a user) on the other end. - -2.3. Circuits. A circuit is a single conversation between two -participants over the onion routing network. One end of the circuit has -an AP connection, and the other end has an exit connection. AP and exit -connections have only one circuit associated with them (and thus these -connection types are closed when the circuit is closed), whereas OP and -OR connections multiplex many circuits at once, and stay standing even -when there are no circuits running over them. - -2.4. Cells. Some connections, specifically OR and OP connections, speak -"cells". This means that data over that connection is bundled into 128 -byte packets (8 bytes of header and 120 bytes of payload). Each cell has -a type, or "command", which indicates what it's for. - - -3. Important parameters in the code. - -3.1. Role. - - -4. Robustness features. - -4.1. Bandwidth throttling. Each cell-speaking connection has a maximum -bandwidth it can use, as specified in the routers.or file. Bandwidth -throttling occurs on both the sender side and the receiving side. The -sending side sends cells at regularly spaced intervals (e.g., a connection -with a bandwidth of 12800B/s would queue a cell every 10ms). The receiving -side protects against misbehaving servers that send cells more frequently, -by using a simple token bucket: - -Each connection has a token bucket with a specified capacity. Tokens are -added to the bucket each second (when the bucket is full, new tokens -are discarded.) Each token represents permission to receive one byte -from the network --- to receive a byte, the connection must remove a -token from the bucket. Thus if the bucket is empty, that connection must -wait until more tokens arrive. The number of tokens we add enforces a -longterm average rate of incoming bytes, yet we still permit short-term -bursts above the allowed bandwidth. Currently bucket sizes are set to -ten seconds worth of traffic. - -The bandwidth throttling uses TCP to push back when we stop reading. -We extend it with token buckets to allow more flexibility for traffic -bursts. - -4.2. Data congestion control. Even with the above bandwidth throttling, -we still need to worry about congestion, either accidental or intentional. -If a lot of people make circuits into same node, and they all come out -through the same connection, then that connection may become saturated -(be unable to send out data cells as quickly as it wants to). An adversary -can make a 'put' request through the onion routing network to a webserver -he owns, and then refuse to read any of the bytes at the webserver end -of the circuit. These bottlenecks can propagate back through the entire -network, mucking up everything. - -To handle this congestion, each circuit starts out with a receive -window at each node of 100 cells -- it is willing to receive at most 100 -cells on that circuit. (It handles each direction separately; so that's -really 100 cells forward and 100 cells back.) The edge of the circuit -is willing to create at most 100 cells from data coming from outside the -onion routing network. Nodes in the middle of the circuit will tear down -the circuit if a data cell arrives when the receive window is 0. When -data has traversed the network, the edge node buffers it on its outbuf, -and evaluates whether to respond with a 'sendme' acknowledgement: if its -outbuf is not too full, and its receive window is less than 90, then it -queues a 'sendme' cell backwards in the circuit. Each node that receives -the sendme increments its window by 10 and passes the cell onward. - -In practice, all the nodes in the circuit maintain a receive window -close to 100 except the exit node, which stays around 0, periodically -receiving a sendme and reading 10 more data cells from the webserver. -In this way we can use pretty much all of the available bandwidth for -data, but gracefully back off when faced with multiple circuits (a new -sendme arrives only after some cells have traversed the entire network), -stalled network connections, or attacks. - -We don't need to reimplement full tcp windows, with sequence numbers, -the ability to drop cells when we're full etc, because the tcp streams -already guarantee in-order delivery of each cell. Rather than trying -to build some sort of tcp-on-tcp scheme, we implement this minimal data -congestion control; so far it's enough. - -4.3. Router twins. In many cases when we ask for a router with a given -address and port, we really mean a router who knows a given key. Router -twins are two or more routers that all share the same private key. We thus -give routers extra flexibility in choosing the next hop in the circuit: if -some of the twins are down or slow, it can choose the more available ones. - -Currently the code tries for the primary router first, and if it's down, -chooses the first available twin. -