[tor-dev] high latency hidden services

[grarpamp]

On Mon, Jan 5, 2015 at 2:17 PM, Michael Rogers <michael at briarproject.org> wrote:
> To be clear, are you suggesting that each relay and each client should
> pick some relays from the consensus and exchange chaff with them, and
> clients should also exchange chaff with their guards?

I'm saying you definitely have to have your guard link[s] filled
with a steady stream of ATM-like buckets, where you fill with your
wheat as needed but can achieve no more wheat throughput than the
fixed rate of the bucket stream. And so does every other edge node
to a depth of at least one hop inside the net. Beyond that... because
your blob might be the only one passing through your guard on a
quiet day/path (whose far side to the middle node is also observed),
every node on the net has to have its links filled. And since every
link has to be filled, you can just pick nodes out of the consensus
to peer with for additional fill purposes if negotiations with your
guards doesn't result in you filling the CAR of the overall tor
pipe on your machine. It'll help if you think of links to your
peers not just as a potential paths for building circuits, but as
bandwidth commitments before that. Since every node has its own
first hops and is doing their own fill there, you don't have to
worry about what they do, just cover your own and donate any excess
capacity you have to whatever node on the net comes asking for help
to fill theirs.

If you don't fill all the links, your fact of downloading, page
loading, keystroking are going to be passively observable as those
blobs enter, transit, and leave the net.

> If that's what you're suggesting, then what happens if a client wants
> to extend a circuit from relay A to relay B, but A and B aren't
> exchanging chaff with each other?

This doesn't happen. You have a lower layer of nodes doing fill
guided by knowledge of who their own guards are (in this model
relays must have notions of their own guards / first hops). Circuits
are then strung unaffected and unaware over that as usual. Relays
know the difference between their own action doing p2p for fill,
and non fill (circuit) data trying to leave them... so they can
make room in their existing first hop links, or negotiate new ones
with where that data is trying to go. Yes, if for some reason the
relay could not negotiate its underlying first hop bandwidth for
that, the circuit extension itself would die (perhaps EBUSY from
the circuit side) and the client would try another path.

> Are you saying that wheat can only be sent over links that have been
> chosen to carry chaff?

The point is to hide the fact that you're sending bytes (wheat),
at what time, in what amount, and with what properties, that might
be identifiably observed again tied your destination on the other
side of the net. So yes, of course, by definition of link filling.


Sorry I've no graphics or complete scheme yet, for that matter this
could all be rubbish.

If anyone knows of networks (whether active, defunct or discredited)
that have used link filling, I'd like a reference. Someone out there
has to have at least coded one for fun.