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
- 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),
- 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
- 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
- Virtual LAN (RPVL) -- Specialized (RP) to handle
- 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.