Re: [tor-dev] Call for a big fast bridge (to be the meek backend)

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Wed, Sep 17, 2014 at 09:05:39PM -0500, Tom Ritter wrote:
> On 15 September 2014 21:12, David Fifield <david@xxxxxxxxxxxxxxx> wrote:
> > Since meek works differently than obfs3, for example, it doesn't help us
> > to have hundreds of medium-fast bridges. We need one (or maybe two or
> > three) big fat fast relays, because all the traffic that is bounced
> > through App Engine or Amazon will be pointed at it.
> 
> A horrible idea Isis and I came up with was standing up two or more
> tor servers with the same keys, on an anycast-ed IP address. I'm not
> sure how the meek backend works, but if it's not set up already to
> support round-robining, you would likely be able to trick it into
> doing some by duplicating keys and doing DNS round-robining or other
> networking-layer tricks.

I'm really not too worried about capacity. Any single fast-ish bridge
will do for the kind of numbers we're seeing now. Even the current
bridge is more than enough for the time being. I'm just trying to make
the point that it's a different threat model: it's not helpful to have
hundreds of people running relays the way it is with obfs3.

Currently in the bundles we're not setting a bridge fingerprint, so
relays wouldn't have to share a key. You *would* have to make sure that
the same client always gets forwarded to the same relay, because your
logical Tor stream gets segmented into multiple HTTP requests and it
takes some bookkeeping on the relay side to reassemble them.

But we're a long way from needing to think about round-robining. One
good relay, of capacity similar to what the default obfs3 bridges have,
would cover us well into the future, I reckon, even if there were a big
increase in meek users. Look at the user graphs:
https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&start=2014-06-20&end=2014-09-18&transport=obfs3&transport=meek#userstats-bridge-transport
We're still a long long way from being limited by relay capacity. We'll
be worried about how to pay CDN fees long before relay capacity becomes
an issue.

A more reasonable reason to have more than one backend relay is if you
worry about that relay getting owned or its operator going rogue. That's
a reasonable thing to think about. It's really easy to use a different
bridge for each CDN, at least, and I think we'd do that before doing
anycast tricks.

David Fifield
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev