On 9 September 2014 09:29, Lee Azzarello <[email protected]> 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 _______________________________________________ Guardian-dev mailing list Post: [email protected] List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: [email protected] Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: [email protected]
