[guardian-dev] Docker + Weave

[Tom Ritter]

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