mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 14:23:30 +01:00
98 lines
3.9 KiB
Plaintext
98 lines
3.9 KiB
Plaintext
$Id$
|
|
|
|
Tor network discovery protocol
|
|
|
|
0. Scope
|
|
|
|
This document proposes a way of doing more distributed network discovery
|
|
while maintaining some amount of admission control. We don't recommend
|
|
you implement this as-is; it needs more discussion.
|
|
|
|
Terminology:
|
|
- Client: The Tor component that chooses paths.
|
|
- Server: A relay node that passes traffic along.
|
|
|
|
1. Goals.
|
|
|
|
We want more decentralized discovery for network topology and status.
|
|
In particular:
|
|
|
|
1a. We want to let clients learn about new servers from anywhere
|
|
and build circuits through them if they wish. This means that
|
|
Tor nodes need to be able to Extend to nodes they don't already
|
|
know about. This is already implemented, but see the 'Extend policy'
|
|
issue below.
|
|
|
|
1b. We want to provide a robust (available) and not-too-centralized
|
|
mechanism for tracking network status (which nodes are up and working)
|
|
and admission (which nodes are "recommended" for certain uses).
|
|
|
|
1c. [optional] We want to permit servers that can't route to all other
|
|
servers, e.g. because they're behind NAT or otherwise firewalled.
|
|
|
|
2. Assumptions.
|
|
|
|
People get the code from us, and they trust us (or our gpg keys, or
|
|
something down the trust chain that's equivalent).
|
|
|
|
Even if the software allows humans to change the client configuration,
|
|
most of them will use the default that's provided, so we should provide
|
|
one that is the right balance of robust and safe.
|
|
|
|
Assume that Sybil attackers can produce only a limited number of
|
|
independent-looking nodes.
|
|
|
|
Roger has only a limited amount of time for approving nodes, and doesn't
|
|
want to be the time bottleneck anyway.
|
|
|
|
We can trust servers to accurately report their characteristics (uptime,
|
|
capacity, exit policies, etc), as long as we have some mechanism for
|
|
notifying clients when we notice that they're lying.
|
|
|
|
There exists a "main" core Internet in which most locations can access
|
|
most locations. We'll focus on it first.
|
|
|
|
3. Some notes on how to achieve.
|
|
|
|
We ship with S (e.g. 3) seed keys.
|
|
We ship with N (e.g. 20) introducer locations and fingerprints.
|
|
We ship with some set of signed timestamped certs for those introducers.
|
|
|
|
Introducers serve signed network-status pages, listing their opinions
|
|
of network status and which routers are good.
|
|
|
|
They also serve descriptors in some way. These don't need to be signed by
|
|
the introducers, since they're self-signed and timestamped by each server.
|
|
|
|
A DHT is not so appropriate for distributing server descriptors as long
|
|
as we expect each client to plan to collect all of them periodically. It
|
|
would seem that each introducer might as well just keep its own
|
|
big pile of descriptors, and they synchronize (pull) from each other
|
|
periodically. Clients then get network-status pages from a threshold of
|
|
introducers, fetch enough of the server descriptors to make them happy,
|
|
and proceed as now. Anything wrong with this?
|
|
|
|
Notice that this doesn't preclude other approaches to discovering
|
|
different concurrent Tor networks. For example, a Tor network inside
|
|
China could ship Tor with a different torrc and poof, they're using
|
|
a different set of seed keys and a different set of introducers. Some
|
|
smarter clients could be made to learn about both networks, and be told
|
|
which nodes bridge the networks.
|
|
|
|
|
|
|
|
4. Unresolved:
|
|
- What new features need to be added to server descriptors so they
|
|
remain compact yet support new functionality?
|
|
- How do we compactly describe seeds, introducers, and certs? Does
|
|
Tor have built-in defaults still, that can be overridden?
|
|
- How much cert functionality do we want in our PKI? Can we revoke
|
|
introducers, or is that done by releasing a new version of the code?
|
|
- By what mechanism will new servers contact the humans who run
|
|
introducers, so they can be approved?
|
|
- Is our network growing because of peoples' trust in Roger? Will it
|
|
grow the same way, or as robustly, or more robustly, with no
|
|
figurehead?
|
|
- 'Extend policies' -- middleman doesn't really mean middleman, alas.
|
|
|