On Thu, Aug 29, 2013 at 4:07 AM, coderman wrote:

... as for ATM, SONET, satellite data terminals, metro wireless, and all other unusual or exotic transports...

i should have mentioned: metro Ethernet or municipal run fiber networks with peering are the best option for mesh traffic relaying like this. ATM is too expensive; IDSN, despite a proud origin story of the first data mix networks, is also expensive, and super slow. get rooftop access for radios in a Fresnel friendly internet exchange where you can simply forward traffic down a few floors over Ethernet and you're in the best of positions. consumer fiber to the home would be great, if ToS restrictions didn't make such forwarding risky. and the business upgrade for FTTP is pretty outrageous in almost every case. you could route through a VPN provider or dedi server of your own in this case, but tunneling may not be sufficiently covert depending on the amount of bandwidth used.

On Thu, Aug 29, 2013 at 10:25 AM, grarpamp wrote:

... because of our silly desire to not fill our pipes with chaff, we've made it easier in some cases for GPA's [...] to watch and connect the inputs/outputs across a relatively silent backbone...

active attacks are often even more effective at rapid traffic confirmation and analysis[0]; GPA is pretty tame perhaps! in any case the challenge you mention: thwarting or preventing traffic analysis without a full mix of constant traffic. if the datagram based system above existed, combine with: - stochastic fair queuing and re-ordering of egress traffic. by "clamping" the outbound rate of randomized, re-ordered datagrams to a broad "size/chunk" of capacity, you deter traffic confirmation, anonymity set reduction, and other traffic analysis attacks of various types. - client-side classification of application traffic into prioritized classes[1] for ingress / dgm proxy level active shaping by classful HTB queues before transiting the first hop and losing all visibility into the content and priority of message payloads. - integrate a lowest effort / unreliable background reliable multicast like bulk transport channel for resource and key pre-caching, network participant and performance information distribution, secure remote archives, random performance measurement/tests across peer groups, other low priority communications suited for this "filler" class of traffic. (consuming more or less filler traffic helps smooth out the effective throughput and efficiency when changing the broad "stochastic traffic capacity range" appropriate for a given peer.) - provide LEDBAT or AQM management of edge traffic to upstream(s) to prevent unnecessary latency in upstream buffers. this ensures that even at full utilization the responsiveness of the broadband link is excellent. - and the multi-path SCTP, IPsec, UDP NAT traversal and encapsulation, and other user space network stacks communicating across this overlay network as discussed above for requisite application and control communication support. these techniques combined allow you to use still not insignificant "stochastic traffic capacity ranges" instead of a constant fixed amount of traffic to protect against these attacks. these stochastic ranges can be adjusted up or down as network performance and capacity dictate. this protocol provides congestion control and TCP friendliness while greatly reducing the amount of bandwidth consumed relative to a traditional mix. --- at best (in theory), an attacker with local active and global passive methods on hand could discern anonymity sets for broad categories / scales of possible communication usage. E.g. anon set A exhibits traffic utilization on the order of 1Mbps to 5Mbps, while anon set B exhibits traffic utilization on the order of 5Mbps to 50Mbps, and anon set C exhibits traffic utilization on the order of 50Mbps to 1Gbps, etc. given this drawback, code a kick ass client with participation enabled by default if sufficient connectivity and resources are available. you've now made these broad traffic volume sets nearly useless in a practical / actionable sense. congratulations! you've now got a traffic analysis resistant low latency anonymity protocol, implementation, and network that nearly anyone can participate in and contribute to. for my next magic hand wave, a directory / route selection method that scales to billions of peers while leveraging geographic propinquity and social peer groups to constrain Sybil attacks and impact of bad actors. next grow network capacity in a way that continually applies implicit feedback from the network overall and peers directly and your deterrence to these attacks begins to improve further over time, perhaps even one day hitting a tipping point of prevalence and persistence for de-facto victory in most threat models... we can dream! --- perhaps someone should toss up a Bitcoin donation address to support work on detailed technical specifications, experimental prototypes, maintaining clouds for continuous builds, regression checks, load tests, and traffic analysis for quality measurement and security improvement[2], could also use donations for bounties for identifying or exploiting security or privacy vulnerabilities in the design and implementation of this final generation anonymous network. whoever sets this up should probably use an onion to coordinate development and distribute sources, other resources... calling all "tup" s, ... ;P --- 0. "From a Trickle to a Flood: Active Attacks on Several Mix Types" http://freehaven.net/doc/batching-taxonomy/taxonomy.pdf 1. i have mentioned the following classes before, with each in priority order for the HTB prioritization / shaping before traffic enters the network and becomes opaque: a. control and signalling traffic - always takes precedence. b. real-time and interactive communications, but not video. c. real-time video communication, if applicable. d. low priority bulk communication. torrents, archives, opportunistic caching e. filler / last-tier best effort unreliable traffic as mentioned above for filling in the remaining capacity at the current stochastic rx/tx rate center point. 2. instead of trying to research and author formal proofs of entropy bounds for various idealized models, cut straight to the chase and build the most aggressive, best in class developmental learning / deep learning systems for classification and identification of nodes, flows, protocols, identities in a test bed setup that provides full traffic visibility and active client edge MitM capability (E.g. simulate attack via rogue AP or cell tower for tagging? selective DoS? others,). malicious attacks performed by the remote end or injected by remote's upstream are not in scope for this traffic analysis and privacy assessment. however, passive capture of all exit communications and ORCHID hidden endpoint communications is in scope for analysis. then, see how effective this best scenario and tools attack is against a running implementation. did it fail catastrophically in flames or break wide open with trivial effort? keep improving... respectably hardened against the most aggressive machine learning and malicious active attacks you could conceive of and build? great! have a beer and then find the people who see the oversights and blind spots you don't. keep improving... rinse, repeat, ...