[guardian-dev] Docker + Weave

[Lee Azzarello]

You are comparing apples to oranges. The Google home page is an
asynchronous HTTP request response cycle. VoIP applications are
synchronous and realtime. You seem to have contradicted your own
hypothesis in your list. "Annoy upstream" is not a scalable solution for
providing an anonymously signaled VoIP service on the IP layer of the
public Internet.

-lee

On 9/9/14, 12:50 PM, Tom Ritter wrote:
> On 9 September 2014 09:29, Lee Azzarello <lee at guardianproject.info> wrote:
>> I'll check out Weave, though as with any VoIP application, the added
>> latency of anonymity networks is typically prohibitive until the laws of
>> physics are mutable.
> 
> I'm not convinced this is the case.  Imagine the Google homepage. You
> load that very, very fast.  Google analyzed every single ms of every
> single process and connection to make it that fast.  I'm not aware of
> anyone doing the same rigorous examination for VOIP applications in an
> anonymity setting.  (I'm not faulting anyone - it's hard, takes time,
> and would be expensive.  But I think it's worthwhile.)
> 
> Specifically, I would imagine it going something like this. You decide
> the properties you want to hit are that (for example) Alice calls Bob,
> and Alice's provider doesn't know who she's calling, and Bob's
> provider doesn't know who's calling him.  (Modulo metadata exposed by
> SIP, which we assume is or can be protected with additional layering
> of encrypted data.)  So I'm imagining it like Tor, with 2 hops.  The
> anonymity goals are hit by hops in-between (that are exposed to
> metadata, like 'Alice is calling someone, connect me to IP x.y.z.w')
> that are operated by different providers and that you may want to
> build in some additional considerations regarding path building to
> avoid using (for example) all one ISP or whatever. I'm also assuming
> that for testing purposes, you're going to put two specific
> applications on either end, and examine those, along with controlling
> nearly _all_ the infrastructure in between (for now).
> 
> Now, from the moment sound input is received on one end, to the moment
> it is send to the speaker on the other, break down the latency of each
> hop:
> 
> 1 - Time for Application processing
> 2 - Time for OS networking stack
> 3 - Latency to when it exits a router you control
> 4 - Latency until it enters the routing infrastructure (the switch in
> the cabinet) of Hop #1, which you control
> 4.5 - Latency of transmission from the switch to the processing server
> 5 - Latency of Hop #1's Networking Stack on the way in
> 6 - Hop #1 Processing Time
> 7 - Latency of Hop #1 Network Stack on the way out
> 7.5 Same as 4.5
> 8 - Latency until it enters Hop #2's routing infrastructure
> 8.5 Latency of transmission from switch to the processing server
> 9 - Latency of Hop #2's Networking Stack on the way in
> 10 - Hop #2 Processing Time
> 11 - Latency of Hop #2's Network Stack on the way out
> 11.5 Same as 8.5
> 12 - Latency until it reaches a router for Bob you control
> 13 - Latency until it enter's Bob's network stack
> 14 - Time for Bob's OS' network stack
> 15 - Time for Application Processing
> 
> Now optimize, everything.  Starting with the slowest stuff.
> 
> 1, 15 - Can be improved by programming techniques in the App.  Make it
> native code, make it fast.
> 2, 14 - You're not going to be able to do much here, but you can look
> for tricks or better APIs, and annoy upstream for improvements.
> Document. Experiment and show what patches would make improvements.
> 3,13 - You're not going to be able to do much here. But you can, for
> example, make sure packets are not be excessively fragmented. Make
> sure things fit in MTUs.
> 4, 12 - Look at the tracert of this distance.  See how efficient it
> is.  Can you use another ISP in your datacenter for a faster path?
> Assuming we have a network of hops to choose our original path from,
> can you a) choose Hop #1 or Hop #2 to optimize this without b) harming
> the anonymity (significantly?)?
> 4.5, 7.5, 8.5, 11.5 - You're going to need to be looking very closely
> at configuration of networking equipment, and making sure it's an
> optimal as possible.  Things like network drivers matter here.
> 5, 7, 9, 11 - This is as technical as 2 and 14, but this time you
> control the OS.  You can configure and patch it as you see fit. Linux
> has tons of tunable TCP and UDP parameters for caching and what not.
> This is going to be different under heavy load and under no load.
> Acknowledge and understand you will need to monitor and tweak.
> 6, 10 - Same as 1, 15 - fast, optimized code.
> 8 - How are Hop #1 and #2 connected?  Same questions as 4 and 12, but
> consider some other items.  Can Hop #1 and #2 be located in the same
> Datacenter, and use different ISPs as their primary outbound links
> (for anonymity purposes)? Is that acceptable from the a privacy
> standpoint?
> 
> Try interesting experiments to.  What if Alice doesn't choose the
> path, because she has a flimsy smartphone. What if she trusts a
> supercomputer to weigh all the variables, including the entire
> database of hops accessible and the entire BGP routing table, and that
> supercomputer both does the encryption and the path selection.
> 
> Anyway, I don't mean to suggest that this is something I think anyone
> is negligent in not doing.  Rather I think it's a huge undertaking I
> would love to encourage people to think about, and maybe apply for
> funding for.  Google has tons of engineers dedicated to this sort of
> thing.  They make new protocols to replace TLS and deploy it in Chrome
> to run experiments.  One can achieve amazing results with a careful
> enough examination, and a belief that nothing _has_ to be accepted and
> one can improve _anything_.
> 
> -tom
>