[guardian-dev] Docker + Weave

[Lee Azzarello]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Also, I appreciate your attention to detail but the problem is not on
the application or the OS level. The problem is on the network layer,
from IPv4 and below. Secure and anonymous realtime VoIP with
end-to-end key agreement cannot work on the existing public Internet
if the model of a "phone call" is used. So the option is to create a
new network which will no longer be challenged by the laws of physics
as they apply to IP networking. I really want to be proven wrong but
I'm convinced that this is how things work with the state of the art.
If you know of any research papers that address this subject, I would
love to read them.

- -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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUD+rlAAoJEKhL9IoSyjdlxMIQAKMt1UHu0LW/ociwJ1A2hBGc
SwheFivdkMU9eJl6+IxbowwNs36BTteX6xg6jTnLvoGn3V4o9nXPYlLMMPqOFfDA
elEihUfsqRelK+5sHmuNUg9zG0ovIvFJUREbr4ooP0JqjwtNmQqHvxFeSsIK2PCY
46ve4Xk+NBeWuktt01iESr983V1TNzS5fbM5OiANctUeOE8PVF8DIyjg6zIsJm+e
q7ZLgxJHz0aIHrfdkFLN8rxGZS222dSB8a6nQi/h+cCVqPygDENdJ9JAumDkmdET
Dv8hzDwE/smk6ttnweFldUC+tBj/lUJGFEpA8AVMeJPMXlyySVOiH3cgA1dJ2/UY
Xy16+jxJ+UKaud/IcbcL7vXIHYL5AF09bFtxOX9GnXer7BdMnklSIPCNmNyqcVtL
YHJjKbY/I17dCtB0oRqJi+x4haFmpXwafAGauUDPJ64XPY1xfPhWMcKj8473gigN
BgK0Tj0Wc8/xJieK7Kjo+FvlgmPFnUlDYEyYm1xIaladB+6FJaUWwzVcZeT9jR2G
q1EV61DBKl08BdLI965cPqnMQUZCl3qPxsMYK5d/fFnZdKHdSRl0VXL8TOema8oE
QBjwSRZjO1+pUyq6YOqez3P2BgbEd39iXF+aGsVYJI5ApSq16Cq/5I6/UFFL09h8
9NsI1cN+fNf60553xrSd
=ur17
-----END PGP SIGNATURE-----