Next Generation System

ORtNG (Onion Routing the Next Generation :-) is a huge leap forward from the original prototype system. Some of the improvements include:

• Switching to SSLeay for the crypto engine. BSAFE will still be supported for RSA operations (if desired).
• Integrated support for nCipher's nFast hardware accelerator to considerably speed up public key cryptography.
• Increased throughput and decreased circuit latency (increased cell sizes to 128bytes from 42 bytes, and bulk read/writes on virtual pipes).
• Breaking up the entire Onion Routing system into 7 functional elements:
  • Application Proxy (AP) -- This is the application specific proxy that handles interfacing into the Onion Routing Network. It also contains a (DB) since the (AP) now does route planning and onion creation (formerly done by the first (C), the trust for generating the onions has been moved closer to the user). We are currently planning (AP)s for HTTP/1.1-HTML/4.0, SMTP, FTP, RLOGIN, TELNET, NNTP, talk, finger, whois, gopher, WAIS, dns, nfs, RAW sockets, Virtual LANs, and SOCKS5.
  • Input Funnel (IF) -- This is an optional unit that is used to multiplex more (AP)s into one (C), or to span a firewall without having to reveal the network topology on the secure side of the firewall. (IF)s can be stacked as deep as necessary (no limit) between the (AP) and (C). Ultimately (IF)s will be able to load-balance between multiple (C)s.
  • Database Engine (DB) -- The (DB) is responsible for distributing and maintaining information about the entire network. It learns the public certificates for all nodes, the link state of the entire network graph, the exit access control policies for each node, and the current operational state of each node. This information is critical to designing an effective route through the network by the (AP).
  • Core (C) -- The (C) is the heart of Onion Routing. It moves cells along Anonymous Connections throughout the Onion Routing Network. Currently it is the only element that contains a Chaum MIX, but other elements could also have them added (ie, (IF), (AP), (OF))
  • Crypto Processor (CP) -- The (CP) is responsible for processing onions at each (C). The (CP) performs the necessary public-key decryption and prepares the onion for the next hop returning the result back to the (C). This unit is critical to prevent "burps" in processing at (C)s during costly public key operations.
  • Output Funnel (OF) -- The (OF) is responsible for de-multiplexing the circuits from the (C) to the (RP)s. Since there are multiple types of (RP)s, the (OF) must peek initially into the stream to determine which (RP) is most appropriate for a new circuit.
  • Responder Proxy (RP) -- There are number of different types of (RP)s which deal with different types of circuits:
    • Short Lived (RPSL) -- Short lived connections are things like HTTP.
    • Long Lived (RPLL) -- Long lived connection are things like RLOGIN or TELNET.
    • Reply Onion (RPRO) -- Any connection utilizing a reply onion must route through here or else all crypto will fail for that circuit.
    • Virtual LAN (RPVL) -- Specialized (RP) to handle VLANs.
• Ability to set access control policies on:
  • Who can enter at your node using what protocols (ie, NRL might say that only *.nrl.navy.mil can use the NRL Onion Router as the entry point into the Onion Routing Network).
  • Where you allow exiting connections to connect using what protocols (ie, NRL might say that you can only exit at the NRL Onion Router to sites in *.mil,*.gov using HTTP and SMTP, *.nrl.navy.mil for RLOGIN or TELNET, etc.)
• Multiple signing authorities for distribution of the public key certificates used by the core Onion Routers. No one central authority.
• Proxies for: HTTP, SMTP, FTP, RLOGIN, Telnet, NNTP, Talk, Finger, Whois, gopher, WAIS, DNS, NFS, VLANs, RAW connections (NRaD redirector), and SOCKS5.
• More info to come...

Historical page reflecting onion-router.net as of 2005, not regularly maintained. Address questions to Paul Syverson.